Network Working Group B. Adamson
Request for Comments: 3941 NRL
Category: Experimental C. Bormann
Universitaet Bremen TZI
M. Handley
UCL
J. Macker
NRL
November 2004
Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Building Blocks
否定応答（NACK）指向の信頼性の高いマルチキャスト（NORM）ビルディングブロック
Status of this Memo
このメモの位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This document discusses the creation of negative-acknowledgment (NACK)-oriented reliable multicast (NORM) protocols. The rationale for NORM goals and assumptions are presented. Technical challenges for NACK-oriented (and in some cases general) reliable multicast protocol operation are identified. These goals and challenges are resolved into a set of functional "building blocks" that address different aspects of NORM protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols.
この文書では、否定応答（NACK）の作成が信頼性の高いマルチキャスト（NORM）プロトコルを配向について説明します。 NORMの目標および仮定の根拠が提示されています。 NACK指向（と一般的ないくつかのケースでは）信頼性の高いマルチキャストプロトコル操作のための技術的な課題が特定されています。これらの目標と課題はNORMプロトコルの動作の異なる側面を扱う機能「ビルディング・ブロック」のセットに解決されます。これらのビルディングブロックは、信頼できるマルチキャストプロトコルの異なるインスタンスを生成するのに有用であろうことが予想されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Rationale. . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Delivery Service Model . . . . . . . . . . . . . . . . . 4
2.2. Group Membership Dynamics . . . . . . . . . . . . . . . . 5
2.3. Sender/Receiver Relationships . . . . . . . . . . . . . . 5
2.4. Group Size Scalability. . . . . . . . . . . . . . . . . . 6
2.5. Data Delivery Performance . . . . . . . . . . . . . . . . 6
2.6. Network Environments. . . . . . . . . . . . . . . . . . . 6
2.7. Router/Intermediate System Assistance . . . . . . . . . . 7
3. Functionality. . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. NORM Sender Transmission. . . . . . . . . . . . . . . . . 10
3.2. NORM Repair Process . . . . . . . . . . . . . . . . . . . 11
3.2.1. Receiver NACK Process Initiation . . . . . . . . . 11
3.2.2. NACK Suppression . . . . . . . . . . . . . . . . . 13
3.2.3. NACK Content . . . . . . . . . . . . . . . . . . . 17
3.2.3.1. NACK and FEC Repair Strategies. . . . . . 17
3.2.3.2. NACK Content Format . . . . . . . . . . . 20
3.2.4. Sender Repair Response . . . . . . . . . . . . . . 21
3.3. NORM Receiver Join Policies and Procedures. . . . . . . . 23
3.4. Reliable Multicast Member Identification. . . . . . . . . 24
3.5. Data Content Identification . . . . . . . . . . . . . . . 24
3.6. Forward Error Correction (FEC). . . . . . . . . . . . . . 26
3.7. Round-trip Timing Collection. . . . . . . . . . . . . . . 27
3.7.1. One-to-Many Sender GRTT Measurement. . . . . . . . 27
3.7.2. One-to-Many Receiver RTT Measurement . . . . . . . 29
3.7.3. Many-to-Many RTT Measurement . . . . . . . . . . . 29
3.7.4. Sender GRTT Advertisement. . . . . . . . . . . . . 30
3.8. Group Size Determination/Estimation . . . . . . . . . . . 31
3.9. Congestion Control Operation. . . . . . . . . . . . . . . 31
3.10 Router/Intermediate System Assistance . . . . . . . . . . 31
3.11 NORM Applicability. . . . . . . . . . . . . . . . . . . . 31
4. Security Considerations. . . . . . . . . . . . . . . . . . . . 32
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.1. Normative References. . . . . . . . . . . . . . . . . . . 33
6.2. Informative References. . . . . . . . . . . . . . . . . . 33
7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 35
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 36
Reliable multicast transport is a desirable technology for the efficient and reliable distribution of data to a group on the Internet. The complexities of group communication paradigms necessitate different protocol types and instantiations to meet the range of performance and scalability requirements of different potential reliable multicast applications and users [3]. This document addresses the creation of negative-acknowledgment (NACK)- oriented reliable multicast (NORM) protocols. While different protocol instantiations may be required to meet specific application and network architecture demands [4], there are a number of fundamental components that may be common to these different instantiations. This document describes the framework and common "building block" components relevant to multicast protocols based primarily on NACK operation for reliable transport. While this document discusses a large set of reliable multicast components and issues relevant to NORM protocol design, it specifically addresses in detail the following building blocks which are not addressed in other IETF documents:
信頼性の高いマルチキャストトランスポートは、インターネット上のグループへのデータの効率的で信頼性の高い配信のための望ましい技術です。グループ通信パラダイムの複雑さは、異なる潜在的信頼性の高いマルチキャストアプリケーションとユーザのパフォーマンスとスケーラビリティ要件の範囲[3]を満たすために、異なるプロトコルタイプとインスタンス化を必要とします。指向信頼性の高いマルチキャスト（NORM）プロトコル - このドキュメントは、否定応答（NACK）の作成に取り組んでいます。異なるプロトコルのインスタンス化は、特定のアプリケーションおよびネットワークアーキテクチャの要求を満たすために必要とされ得るが、[4]、これらの異なるインスタンスに共通とすることができる基本的な構成要素の数があります。この文書では、フレームワーク、主に信頼性の高い輸送用NACK操作に基づいて、マルチキャストプロトコルに関連する一般的な「ビルディングブロック」コンポーネントについて説明します。この文書はNORMプロトコルの設計に関連する信頼性の高いマルチキャストコンポーネントとの問題の大規模なセットを説明しながら、それを具体的に詳細に他のIETF文書で対処されていない以下のビルディングブロックを対処します。
1) NORM sender transmission strategies,
1）NORM送信者の伝送戦略、
2) NACK-oriented repair process with timer-based feedback suppression, and
2）タイマーベースのフィードバック抑制とNACK指向の修復プロセス、および
3) Round-trip timing for adapting NORM timers.
NORMタイマーを適合させるための3）往復タイミング。
The potential relationships to other reliable multicast transport building blocks (Forward Error Correction (FEC), congestion control) and general issues with NORM protocols are also discussed. This document is a product of the IETF RMT WG and follows the guidelines provided in RFC 3269 [5]. 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 BCP 14, RFC 2119 [1].
NORMプロトコルと他の信頼性の高いマルチキャストトランスポート・ビルディング・ブロック（前方誤り訂正（FEC）、輻輳制御）や一般的な問題への潜在的な関係も議論されています。この文書は、IETF RMT WGの製品であり、[5] RFC 3269に設けられたガイドラインに従います。この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[1]。
Statement of Intent
主旨書
This memo contains part of the definitions necessary to fully specify a Reliable Multicast Transport protocol in accordance with RFC 2357. As per RFC 2357, the use of any reliable multicast protocol in the Internet requires an adequate congestion control scheme.
このメモは、完全にRFC 2357を1としてRFC 2357.に従い、信頼性の高いマルチキャストトランスポートプロトコルを指定するために必要な定義の一部が含まれている、インターネットのいずれかの信頼できるマルチキャストプロトコルの使用は、適切な輻輳制御方式が必要です。
While waiting for such a scheme to be available, or for an existing scheme to be proven adequate, the Reliable Multicast Transport working group (RMT) publishes this Request for Comments in the "Experimental" category.
このようなスキームを待っているが利用できるようにする、または既存のスキームのための十分な証明することが、信頼性の高いマルチキャスト交通ワーキンググループ（RMT）は「実験」カテゴリ内のコメントのためにこの要求を発行しています。
It is the intent of RMT to re-submit this specification as an IETF Proposed Standard as soon as the above condition is met.
すぐに上記の条件が満たされたとしてIETFのProposed Standardとして、この明細書を再提出するRMTの意図です。
Each potential protocol instantiation using the building blocks presented here (and in other applicable building block documents) will have specific criteria that may influence individual protocol design. To support the development of applicable building blocks, it is useful to identify and summarize driving general protocol design goals and assumptions. These are areas that each protocol instantiation will need to address in detail. Each building block description in this document will include a discussion of the impact of these design criteria. The categories of design criteria considered here include:
ビルディングブロックを使用して、各潜在的なプロトコルのインスタンスは、ここに提示（および他の適用可能なビルディングブロックの文書に）個々のプロトコルの設計に影響を与える可能性がある特定の基準を持っています。該当ビルディング・ブロックの開発をサポートするために、識別して、一般的なプロトコルの設計目標と仮定を駆動要約すると便利です。これらは、各プロトコルのインスタンス化が詳細に対処する必要があります領域です。このドキュメントの各ビルディングブロックの説明は以下の設計基準の影響についての議論が含まれます。ここで考えて設計基準のカテゴリがあります。
1) Delivery Service Model, 2) Group Membership Dynamics, 3) Sender/receiver relationships, 4) Group Size Scalability, 5) Data Delivery Performance, 6) Network Environments, and 7) Router/Intermediate System Interactions.
1）デリバリーサービスモデル、2）グループメンバーシップダイナミックス、3）送信側/受信側の関係、4）グループサイズスケーラビリティ、5）データ配信パフォーマンス、6）ネットワーク環境、および7）ルータ/中級システムの相互作用。
All of these areas are at least briefly discussed. Additionally, other reliable multicast transport building block documents such as [9] have been created to address areas outside of the scope of this document. NORM protocol instantiations may depend upon these other building blocks as well as the ones presented here. This document focuses on areas that are unique to NORM but may be used in concert with the other building block areas. In some cases, a building block may be able address a wide range of assumptions, while in other cases there will be trade-offs required to meet different application needs or operating environments. Where necessary, building block features are designed to be parametric to meet different requirements. Of course, an underlying goal will be to minimize design complexity and to at least recommend default values for any such parameters that meet a general purpose "bulk data transfer" requirement in a typical Internet environment.
これらの領域の全ては、少なくとも簡単に説明されています。さらに、このような[9]など、他の信頼性の高いマルチキャストトランスポートビルディングブロックの文書がこの文書の範囲外の領域に対処するために作成されています。 NORMプロトコルのインスタンスは、これらの他のビルディング・ブロックと同様に、ここで提示したものに依存してもよいです。この文書では、NORMに固有のものですが、他のビルディングブロック領域と協調して使用することができる分野に焦点を当てています。他の場合には、異なるアプリケーションのニーズや動作環境を満たすために必要なトレードオフが存在するであろうしながらいくつかのケースでは、ビルディングブロックは、前提条件の広い範囲できるアドレスであってもよいです。必要な場合には、ビルディングブロックの機能は、さまざまな要件を満たすために、パラメトリックなるように設計されています。もちろん、基本的な目標は、設計の複雑さを最小限にし、少なくとも一般的なインターネット環境での汎用「バルクデータ転送」の要件を満たす任意のこのようなパラメータのデフォルト値を推奨することになります。
The implicit goal of a reliable multicast transport protocol is the reliable delivery of data among a group of members communicating using IP multicast datagram service. However, the specific service the application is attempting to provide can impact design decisions. A most basic service model for reliable multicast transport is that of "bulk transfer" which is a primary focus of this and other related
信頼できるマルチキャストトランスポートプロトコルの暗黙の目標は、IPマルチキャストデータグラムサービスを使用して通信を行うメンバーのグループ間でデータの信頼できる配信です。ただし、アプリケーションが提供しようとしている特定のサービスは、設計上の決定に影響を与えることができます。信頼性の高いマルチキャスト輸送のための最も基本的なサービスモデルは、これと関連する他の主要な焦点である「バルク転送」のことです
RMT working group documents. However, the same principles in protocol design may also be applied to other services models, e.g., more interactive exchanges of small messages such as with white-boarding or text chat. Within these different models there are issues such as the sender's ability to cache transmitted data (or state referencing it) for retransmission or repair. The needs for ordering and/or causality in the sequence of transmissions and receptions among members in the group may be different depending upon data content. The group communication paradigm differs significantly from the point-to-point model in that, depending upon the data content type, some receivers may complete reception of a portion of data content and be able to act upon it before other members have received the content. This may be acceptable (or even desirable) for some applications but not for others. These varying requirements drive the need for a number of different protocol instantiation designs. A significant challenge in developing generally useful building block mechanisms is accommodating even a limited range of these capabilities without defining specific application-level details.
RMTワーキンググループ文書。しかしながら、プロトコルの設計における同じ原理はまた、他のサービスモデル、例えば、そのようなホワイトボーディングまたはテキストチャットと同様に小さなメッセージのよりインタラクティブなやり取りにも適用することができます。これらの異なるモデルの中で再送信または修理のために（それを参照するか、状態）、このような送信者の送信したデータをキャッシュする機能などの問題があります。グループ内のメンバー間の順序及び/又は送信及び受信のシーケンスにおける因果関係の必要性は、データ内容に応じて異なっていてもよいです。グループ通信パラダイムは、その中のポイントツーポイントモデルとは大きく異なり、データコンテンツの種類に応じて、いくつかの受信機は、データコンテンツの部分の受信を完了し、他のメンバーがコンテンツを受信する前に、それに作用することができるかもしれません。これは、いくつかの用途のためにではなく、他の許容可能な（または望ましい）であってもよいです。これらの多様な要件は、異なるプロトコルのインスタンス化設計の数の必要性を駆動します。一般的に有用なビルディングブロック機構を開発する上で重要な課題は、特定のアプリケーションレベルの詳細を定義することなく、これらの機能も限られた範囲を収容しています。
One area where group communication can differ from point-to-point communications is that even if the composition of the group changes, the "thread" of communication can still exist. This contrasts with the point-to-point communication model where, if either of the two parties leave, the communication process (exchange of data) is terminated (or at least paused). Depending upon application goals, senders and receivers participating in a reliable multicast transport "session" may be able to join late, leave, and/or potentially rejoin while the ongoing group communication "thread" still remains functional and useful. Also note that this can impact protocol message content. If "late joiners" are supported, some amount of additional information may be placed in message headers to accommodate this functionality. Alternatively, the information may be sent in its own message (on demand or intermittently) if the impact to the overhead of typical message transmissions is deemed too great. Group dynamics can also impact other protocol mechanisms such as NACK timing, congestion control operation, etc.
グループ通信は、ポイントツーポイント通信とは異なることができる一つの領域は、グループの組成が変化しても、通信の「スレッド」が依然として存在することができることです。これは、二者のいずれかが去る場合、通信処理（データの交換）が終了する（または少なくとも一時停止）され、ポイント・ツー・ポイント通信モデルとは対照的です。信頼性の高いマルチキャストトランスポート「セッション」に参加したアプリケーションの目標、送信側と受信側に応じて、後半に参加したまま、および/または進行中のグループ通信「スレッド」はまだ機能と便利なまま潜在的に再参加することができるかもしれません。また、これは、プロトコルメッセージの内容に影響を与えることができることに注意してください。 「後半ジョイナは、」サポートされている場合は、追加情報の一部量は、この機能に対応するために、メッセージのヘッダーに配置することができます。典型的なメッセージ送信のオーバーヘッドに影響が大きすぎるとみなされる場合に代替的に、情報は、独自のメッセージ（要求に応じて又は断続的）に送信することができます。グループダイナミクスはまた、等NACKタイミング、輻輳制御動作、などの他のプロトコルメカニズムに影響を与える可能性
The relationship of senders and receivers among group members requires consideration. In some applications, there may be a single sender multicasting to a group of receivers. In other cases, there may be more than one sender or the potential for everyone in the group to be a sender _and_ receiver of data may exist.
グループのメンバー間の送信者と受信者の関係は考慮が必要です。いくつかの用途では、受信機のグループにマルチキャストする単一の送信者が存在してもよいです。他の場合には、そこに複数の送信者であってもよいし、データの送信元_and_受信するグループ内のすべての人の可能性が存在してもよいです。
Native IP multicast [2] may scale to extremely large group sizes. It may be desirable for some applications to scale along with the multicast infrastructure's ability to scale. In its simplest form, there are limits to the group size to which a NACK-oriented protocol can apply without NACK implosion problems. Research suggests that NORM group sizes on the order of tens of thousands of receivers may operate with modest feedback to the sender using probabilistic, timer-based suppression techniques [7]. However, the potential for router assistance and/or other NACK suppression heuristics may enable these protocols to scale to very large group sizes. In large scale cases, it may be prohibitive for members to maintain state on all other members (in particular, other receivers) in the group. The impact of group size needs to be considered in the development of applicable building blocks.
ネイティブIPマルチキャスト[2]は非常に大規模なグループサイズにスケーリングすることができます。いくつかのアプリケーションが拡大するマルチキャストインフラの能力と一緒に拡張することが望ましい場合があります。その最も単純な形態では、NACK指向プロトコルは、NACKの内破問題なく適用することができるためにグループサイズには限界があります。研究[7]十受信機の数千のオーダーのNORMグループサイズは確率的、タイマーベースの抑圧技術を使用して送信者に適度なフィードバックで動作することができることを示唆しています。しかし、ルータ案内および/またはその他のNACK抑制ヒューリスティックの可能性は非常に大規模なグループのサイズに拡大縮小するには、これらのプロトコルを有効にすることができます。メンバーは、グループ内のすべての他のメンバー（特に、他の受信機）上で状態を維持するために大規模な場合には、それは法外であってもよいです。グループサイズの影響は、適用可能なビルディング・ブロックの開発に検討する必要があります。
There is a trade-off between scalability and data delivery latency when designing NACK-oriented protocols. If probabilistic, timer-based NACK suppression is to be used, there will be some delays built into the NACK process to allow suppression to occur and for the sender of data to identify appropriate content for efficient repair transmission. For example, backoff timeouts can be used to ensure efficient NACK suppression and repair transmission, but this comes at a cost of increased delivery latency and increased buffering requirements for both senders and receivers. The building blocks SHOULD allow applications to establish bounds for data delivery performance. Note that application designers must be aware of the scalability trade-off that is made when such bounds are applied.
NACK指向のプロトコルを設計する際に、スケーラビリティおよびデータ配信の待ち時間の間にトレードオフがあります。確率論、タイマーベースのNACK抑制を使用する場合は、そこにNACKプロセスに組み込まれたいくつかの遅延が抑制が発生することができるようになり、データの送信者のための効率的な修復の伝送のための適切なコンテンツを識別するために。例えば、バックオフタイムアウトは、効率的なNACK抑制及び修復伝送を保証するために使用することができ、これは増加した配信待ち時間と送信側と受信側の両方に対して増大バッファリング要件を犠牲にしています。ビルディングブロックは、アプリケーションがデータ配信のパフォーマンスのための境界を確立できるようにする必要があります。アプリケーションの設計者は、このような境界が適用されたときに行われるスケーラビリティのトレードオフを認識しなければならないことに注意してください。
The Internet Protocol has historically assumed a role of providing service across heterogeneous network topologies. It is desirable that a reliable multicast protocol be capable of effectively operating across a wide range of the networks to which general purpose IP service applies. The bandwidth available on the links between the members of a single group today may vary between low numbers of kbit/s for wireless links and multiple Gbit/s for high speed LAN connections, with varying degrees of contention from other flows. Recently, a number of asymmetric network services including 56K/ADSL modems, CATV Internet service, satellite and other wireless communication services have begun to proliferate. Many of these are inherently broadcast media with potentially large "fan-out" to which IP multicast service is highly applicable. Additionally, policy and/or technical issues may result in topologies where multicast connectivity is limited to a single source multicast (SSM) model from a specific source [8]. Receivers in the group may be restricted to unicast feedback for NACKs and other messages. Consideration must be given, in building block development and protocol design, to the nature of the underlying networks.
インターネットプロトコルは、歴史的に異種ネットワークトポロジ全体にサービスを提供する役割を引き受けました。信頼できるマルチキャストプロトコルが有効汎用IPサービスが適用されるネットワークの広い範囲にわたって動作することが可能であることが望ましいです。単一グループのメンバー間のリンク上で利用可能な帯域幅は、今日、他のフローからの競合の程度を変化させて、無線リンク及び複数ギガビット/秒の高速LAN接続のためのキロビット/秒の少数の間で変化してもよいです。最近、56K / ADSLモデム、CATVインターネットサービス、衛星や他の無線通信サービスを含む非対称ネットワークサービスの数が増殖し始めています。これらの多くは、本質的にIPマルチキャストサービスは非常に適用可能な潜在的に大きな「ファンアウト」でメディアを放送しています。また、ポリシーおよび/または技術的な問題は、マルチキャスト接続が特定の送信元[8]から単一のソースマルチキャスト（SSM）モデルに限定されているトポロジをもたらし得ます。グループ内の受信機はNACKのと、他のメッセージのためのユニキャストのフィードバックに制限することができます。対価は、基礎となるネットワークの性質上、ブロックの開発とプロトコルの設計を構築する際に、与えられなければなりません。
While intermediate assistance from devices/systems with direct knowledge of the underlying network topology may be used to leverage the performance and scalability of reliable multicast protocols, there will continue to be a number of instances where this is not available or practical. Any building block components for NACK-oriented reliable multicast SHALL be capable of operating without such assistance. However, it is RECOMMENDED that such protocols also consider utilizing these features when available.
基礎となるネットワークトポロジーの直接的な知識を有するデバイス/システムからの中間支援が信頼できるマルチキャストプロトコルの性能とスケーラビリティを活用するために使用することができるが、これは使用可能または実用的でないインスタンスの数があるように続けます。 NACK指向の信頼性の高いマルチキャストのための任意のビルディング・ブロック・コンポーネントは、補助なしで動作可能でなければなりません。しかし、そのようなプロトコルも利用できるとき、これらの機能を利用することを検討することを推奨されます。
The previous section has presented the role of protocol building blocks and some of the criteria that may affect NORM building block identification/design. This section describes different building block areas applicable to NORM protocols. Some of these areas are specific to NACK-oriented protocols. Detailed descriptions of such areas are provided. In other cases, the areas (e.g., node identifiers, forward error correction (FEC), etc.) may be applicable to other forms of reliable multicast. In those cases, the discussion below describes requirements placed on those other general building block areas from the standpoint of NACK-oriented reliable multicast. Where applicable, other building block documents are referenced for possible contribution to NORM protocols.
前のセクションでは、プロトコルのビルディングブロックの役割とNORMビルディングブロック識別/デザインに影響を与える可能性の基準のいくつかを提示しました。このセクションでは、NORMプロトコルに適用される別のビルディングブロック領域について説明します。これらの領域の一部は、NACK指向のプロトコルに固有のものです。そのような地域の詳細な説明が提供されています。他の場合には、領域（例えば、ノード識別子、前方誤り訂正（FEC）など）が信頼できるマルチキャストの他の形態にも適用可能です。これらの場合、以下の議論は、NACK指向の信頼性の高いマルチキャストの観点から、それらの他の一般的なビルディングブロック領域上に配置された要件を記述する。該当する場合には、他のビルディングブロックの文書は、NORMプロトコルへの可能な貢献のために参照されています。
For each building block, a notional "interface description" is provided to illustrate any dependencies of one building block component upon another or upon other protocol parameters. A building block component may require some form of "input" from another building block component or other source to perform its function. Any "inputs" required by a building block component and/or any resultant "output" provided will be defined and described in each building block component's interface description. Note that the set of building blocks presented here do not fully satisfy each other's "input" and "output" needs. In some cases, "inputs" for the building blocks here must come from other building blocks external to this document (e.g., congestion control or FEC). In other cases NORM building block "inputs" must be satisfied by the specific protocol instantiation or implementation (e.g., application data and control).
各ビルディングブロックについて、概念的な「インタフェースの説明は、」別の時に又は他のプロトコルパラメータに一つの建物ブロックコンポーネントの依存関係を説明するために提供されます。ビルディングブロック構成要素は、その機能を実行するために別のビルディングブロック成分または他のソースからの「入力」のいくつかのフォームを必要とするかもしれません。ビルディングブロック成分及び/又は提供された得られた「出力」によって必要な「入力」は、各ビルディングブロックコンポーネントのインタフェースの記述で定義され、説明されます。ここで紹介するビルディングブロックのセットは完全にお互いの「入力」と「出力」のニーズを満たしていないことに注意してください。いくつかのケースでは、ここでのビルディングブロックのための「入力」は、この文書（例えば、輻輳制御またはFEC）への外部の他のビルディングブロックから来なければなりません。他の場合にはNORMビルディングブロック「入力は」特定のプロトコルインスタンスまたはインプリメンテーション（例えば、アプリケーションデータ及び制御）が満たさなければなりません。
The following building block components relevant to NORM are identified:
NORMに関連する以下のビルディング・ブロック・コンポーネントが識別されます。
(NORM-Specific) 1) NORM Sender Transmission 2) NORM Repair Process 3) NORM Receiver Join Policies (General Purpose) 4) Node (member) Identification 5) Data Content Identification 6) Forward Error Correction (FEC) 7) Round-trip Timing Collection 8) Group Size Determination/Estimation 9) Congestion Control Operation 10) Router/Intermediate System Assistance 11) Ancillary Protocol Mechanisms
（NORM固有）1）NORMセンダ変速機2）NORM修復プロセス3）NORMレシーバは、ポリシー（汎用）4）ノード（部材）識別5）データコンテンツID 6）前方誤り訂正（FEC）7）ラウンドトリップに参加しますコレクション8タイミング）グループサイズ決意/推定9）輻輳制御動作10）ルータ/中間システム支援11）付属議定書のメカニズム
Figure 1 provides a pictorial overview of these building block areas and some of their relationships. For example, the content of the data messages that a sender initially transmits depends upon the "Node Identification", "Data Content Identification", and "FEC" components while the rate of message transmission will generally depend upon the "Congestion Control" component. Subsequently, the receivers' response to these transmissions (e.g., NACKing for repair) will depend upon the data message content and inputs from other building block components. Finally, the sender's processing of receiver responses will feed back into its transmission strategy.
図1は、これらのビルディングブロック領域とその関係のいくつかの絵の概要を説明します。メッセージ送信の速度は、一般に「輻輳制御」成分に依存しながら、例えば、送信側が最初に送信するデータメッセージの内容は、「ノード識別」、「データコンテンツID」、および「FEC」成分に依存します。その後、これらの送信（例えば、修理のためNACKing）に受信者の応答は、他のビルディング・ブロック・コンポーネントからのデータメッセージの内容および入力に依存するであろう。最後に、受信応答の送信者の処理はその伝送戦略にフィードバックします。
Application Data and Control
|
v
.---------------------. .-----------------------.
| Node Identification |----------->| Sender Transmission |<------.
`---------------------' _.-' `-----------------------' |
.---------------------. _.-' .' | .--------------. |
| Data Identification |--' .'' | | Join Policy | |
`---------------------' .' ' v `--------------' |
.---------------------. .' ' .------------------------. |
.->| Congestion Control |-' ' | Receiver NACK | |
| `---------------------' .' | Repair Process | |
| .---------------------. .' | .------------------. | |
| | FEC |'. | | NACK Initiation | | |
| `---------------------'` `._ | `------------------' | |
| .---------------------. ``. `-._ | .------------------. | |
`--| RTT Collection |._` ` `->| | NACK Content | | |
`---------------------' .`- ` | `------------------' | |
.---------------------. \ `-`._ | .------------------. | |
| Group Size Est. |---.-`---`->| | NACK Suppression | | |
`---------------------'`. ` ` | `------------------' | |
.---------------------. ` ` ` `------------------------' |
| Other | ` ` ` | .-----------------. |
`---------------------' ` ` ` | |Router Assistance| |
`. ` ` v `-----------------' |
`.`' .-------------------------. |
`>| Sender NACK Processing |_____/
| and Repair Response |
`-------------------------'
^ ^
| |
.-----------------------------.
| (Security) |
`-----------------------------'
Fig. 1 - NORM Building Block Framework
図1 - 。NORMビルディングブロックフレームワーク
The components on the left side of this figure are areas that may be applicable beyond NORM. The most significant of these components are discussed in other building block documents such as [9]. A brief description of these areas and their role in the NORM protocol is given below. The components on the right are seen as specific to NORM protocols, most notably the NACK repair process. These areas are discussed in detail below. Some other components (e.g., "Security") impact many aspects of the protocol, and others such as "Router Assistance" may be more transparent to the core protocol processing. The sections below describe the "NORM Sender
この図の左側のコンポーネントは、NORMを超えて適用することができる領域です。これらの成分の最上位は、[9]のような他のビルディングブロックの文書に記載されています。簡単にこれらの領域の説明とNORMプロトコルにおけるその役割は以下のとおりです。右側のコンポーネントは、NORMプロトコル、最も顕著なNACK修復プロセスに固有と見られています。これらの領域は、以下に詳細に説明されています。いくつかの他の成分（例えば、「セキュリティ」）プロトコルの多くの側面に影響を与え、そのような「ルータ支援」などの他のものはコアプロトコル処理に対してより透明であってもよいです。以下のセクションでは、「NORMの送信者を記述する
Transmission", "NORM Repair Process", and "RTT Collection" building blocks in detail. The relationships to and among the other building block areas are also discussed, focusing on issues applicable to NORM protocol design. Where applicable, specific technical recommendations are made for mechanisms that will properly satisfy the goals of NORM transport for the Internet.
トランスミッション」、 『NORMの修復プロセス』、および 『RTTコレクション』詳細ビルディングブロック。NORMプロトコルの設計に適用される問題に焦点を当てにしても説明されている他のビルディングブロック領域間の関係、。適用、特定の技術的な提言がなされている場合適切にインターネット用NORM輸送の目標を満足させるための仕組み。
NORM senders will transmit data content to the multicast session. The data content will be application dependent. The sender will transmit data content at a rate, and with message sizes, determined by application and/or network architecture requirements. Any FEC encoding of sender transmissions SHOULD conform with the guidelines of [9]. When congestion control mechanisms are needed (REQUIRED for general Internet operation), NORM transmission SHALL be controlled by the congestion control mechanism. In any case, it is RECOMMENDED that all data transmissions from NORM senders be subject to rate limitations determined by the application or congestion control algorithm. The sender's transmissions SHOULD make good utilization of the available capacity (which may be limited by the application and/or by congestion control). As a result, it is expected there will be overlap and multiplexing of new data content transmission with repair content. Other factors related to application operation may determine sender transmission formats and methods. For example, some consideration needs to be given to the sender's behavior during intermittent idle periods when it has no data to transmit.
NORMの送信者は、マルチキャストセッションにデータ内容を送信します。データの内容は、アプリケーションに依存になります。送信者は速度で、アプリケーションおよび/またはネットワークアーキテクチャの要件によって決定されるメッセージサイズとデータコンテンツを送信します。送信者の送信のいずれかのFEC符号化は、[9]のガイドラインに準拠している必要があり。輻輳制御メカニズムが必要とされる場合NORM送信は輻輳制御機構によって管理されなければならない、（一般的なインターネット操作に必要）。いずれかの場合には、NORMの送信者からのすべてのデータの送信がアプリケーションまたは輻輳制御アルゴリズムによって決定される限界を評価の対象であることが推奨されます。送信者の送信は（アプリケーションによっておよび/または輻輳制御により制限される場合があります）利用可能な容量の優れた利用を行う必要があります。その結果、オーバーラップ及び修理内容を持つ新しいデータコンテンツ伝送の多重化が存在するであろうと予想されます。アプリケーションの動作に関連する他の要因は、送信者の送信フォーマットと方法を決定してもよいです。例えば、いくつかの考慮事項は、それが送信するデータがないとき、断続的アイドル期間中に送信者の行動に与える必要があります。
In addition to data content, other sender messages or commands may be employed as part of protocol operation. These messages may occur outside of the scope of application data transfer. In NORM protocols, reliability of such protocol messages may be attempted by redundant transmission when positive acknowledgement is prohibitive due to group size scalability concerns. Note that protocol design SHOULD provide mechanisms for dealing with cases where such messages are not received by the group. As an example, a command message might be redundantly transmitted by a sender to indicate that it is temporarily (or permanently) halting transmission. At this time, it may be appropriate for receivers to respond with NACKs for any outstanding repairs they require following the rules of the NORM NACK procedure. For efficiency, the sender should allow sufficient time between the redundant transmissions to receive any NACK-oriented responses from the receivers to this command.
データコンテンツに加えて、他の送信者のメッセージまたはコマンドは、プロトコル操作の一部として使用することができます。これらのメッセージは、アプリケーションデータ転送の範囲の外で起こり得ます。肯定応答が原因グループサイズのスケーラビリティの問題に法外である場合NORMプロトコルでは、そのようなプロトコル・メッセージの信頼性は、冗長送信によって試行されてもよいです。プロトコルの設計は、そのようなメッセージは、グループによって受信されない場合に対処するためのメカニズムを提供すべきであることに留意されたいです。一例として、コマンド・メッセージは、冗長送信を停止することが一時的に（または永続的）であることを示すために送信側によって送信されるかもしれません。受信機はNORM NACK手続きのルールに従って、彼らが必要とする卓越した修理のためのNACKで応答するため、この時点では、それが適切かもしれません。効率化のために、送信者は、このコマンドに受信機から任意のNACK指向の応答を受信する冗長送信の間に十分な時間を確保する必要があります。
In general, when there is any resultant NACK or other feedback operation, the timing of redundant transmission of control messages issued by a sender and other NORM protocol timeouts should be dependent upon the group greatest round trip timing (GRTT) estimate and any expected resultant NACK or other feedback operation. The NORM GRTT is an estimate of the worst-case round-trip timing from a sender to any receivers in the group. It is assumed that the GRTT interval is a conservative estimate of the maximum span (with respect to delay) of the multicast group across a network topology with respect to given sender. NORM instantiations SHOULD be able to dynamically adapt to a wide range of multicast network topologies.
任意の得られたNACK又は他のフィードバック動作、グループ最大往復タイミング（GRTT）推定値と任意期待得NACKに依存しなければならない送信者と他のNORMプロトコルタイムアウトによって発行された制御メッセージの冗長送信のタイミングが存在する場合、一般にまたはその他のフィードバック動作。 NORM GRTTは、グループ内の任意の受信機への送信者から最悪の場合の往復のタイミングの推定値です。 GRTT間隔が所与の送信者に対して、ネットワークトポロジ全体マルチキャストグループ（遅延に対して）最大スパンの控えめな見積もりであると仮定されます。 NORMのインスタンスを動的マルチキャストネットワークトポロジの広い範囲に適応することができるべきです。
Sender Transmission Interface Description
送信者送信インタフェースの説明
Inputs:
入力：
1) Application data and control 2) Sender node identifier 3) Data identifiers 4) Segmentation and FEC parameters 5) Transmission rate 6) Application controls 7) Receiver feedback messages (e.g., NACKs)
1）アプリケーションデータと制御2）送信側ノード識別子3）データ識別子4）セグメンテーション及びFECパラメータ5）伝送レート6）アプリケーションコントロール7）受信機フィードバックメッセージ（例えば、NACKの）
Outputs:
出力：
1) Controlled transmission of messages with headers uniquely identifying data or repair content within the context of the NORM session. 2) Commands indicating sender's status or other transport control actions to be taken.
1）ヘッダが一意NORMセッションのコンテキスト内でデータまたは修復コンテンツを識別してメッセージの送信を制御しました。 2）送信者の状態や取るべき他のトランスポート制御動作を示すコマンド。
A critical component of NORM protocols is the NACK repair process. This includes the receiver's role in detecting and requesting repair needs, and the sender's response to such requests. There are four primary elements of the NORM repair process:
NORMプロトコルの重要なコンポーネントは、NACK修復プロセスです。これは、修理の必要性を検出し、要求内の受信者の役割、およびそのような要求に、送信者の応答を含んでいます。 NORMの修復プロセスの4つの主要な要素があります。
1) Receiver NACK process initiation,
1）受信NACK処理開始、
3) NACK suppression,
3）NACK抑制、
2) NACK message content,
2）NACKメッセージ内容、
4) Sender NACK processing and response.
4）送信者NACK処理と応答。
The NORM NACK process (cycle) will be initiated by receivers that detect a need for repair transmissions from a specific sender to achieve reliable reception. When FEC is applied, a receiver should initiate the NACK process only when it is known its repair requirements exceed the amount of pending FEC transmission for a given coding block of data content. This can be determined at the end of the current transmission block (if it is indicated) or upon the start of reception of a subsequent coding block or transmission object. This implies the NORM data content is marked to identify its FEC block number and that ordinal relationship is preserved in order of transmission.
NORM NACKプロセス（サイクル）が確実に受信を達成するために、特定の送信者からの修理送信の必要性を検出する受信機によって開始されます。 FECが適用されるとき、受信機は、その修復要件は、データコンテンツの所定の符号化ブロックに対するFEC送信保留量を超えて知られているだけNACKプロセスを開始すべきです。これは、現在の伝送ブロックの終わり（それが示されている場合）で、または後続の符号化ブロック又は送信対象の受信開始時に決定することができます。これは、NORMデータコンテンツは、そのFECブロック番号を識別するためにマークされ、その順序関係が伝送のために保存されている意味しています。
Alternatively, if the sender's transmission advertises the quantity of repair packets it is already planning to send for a block, the receiver may be able to initiate the NACK processor earlier. Allowing receivers to initiate NACK cycles at any time they detect their repair needs have exceeded pending repair transmissions may result in slightly quicker repair cycles. However, it may be useful to limit NACK process initiation to specific events such as at the end-of-transmission of an FEC coding block or upon detection of subsequent coding blocks. This can allow receivers to aggregate NACK content into a smaller number of NACK messages and provide some implicit loose synchronization among the receiver set to help facilitate effective probabilistic suppression of NACK feedback. The receiver MUST maintain a history of data content received from the sender to determine its current repair needs. When FEC is employed, it is expected that the history will correspond to a record of pending or partially-received coding blocks.
送信者の送信が既にブロックに対して送信するように計画されたリペアパケットの量を通知した場合あるいは、受信機は、以前のNACK処理を開始することができるかもしれません。彼らは彼らの修理のニーズを検出する任意の時点でNACKサイクルを開始するための許可の受信機は修理送信保留少し速く修理サイクルをもたらす可能性を超えています。しかし、そのようなFEC符号化ブロックの終わりの送信時など、または後続の符号化ブロックの検出時に特定のイベントにNACK処理開始を制限することが有用であり得ます。これは、受信機がNACKメッセージの数が少ないにNACKコンテンツを集約し、NACKのフィードバックの効果的な確率的抑制を促進するために役立つ設定受信機のうちのいくつかの暗黙の緩い同期を提供することを可能にすることができます。受信機は、現在修理の必要性を決定するために、送信者から受信したデータの内容の履歴を維持しなければなりません。 FECが使用される場合には、履歴が保留中または部分的に受信された符号化ブロックの記録に対応することが期待されます。
For probabilistic, timer-base suppression of feedback, the NACK cycle should begin with receivers observing backoff timeouts. In conjunction with initiating this backoff timeout, it is important that the receivers record the current position in the sender's transmission sequence at which they initiate the NACK cycle. When the suppression backoff timeout expires, the receivers should only consider their repair needs up to this recorded transmission position in making the decision to transmit or suppress a NACK. Without this restriction, suppression is greatly reduced as additional content is received from the sender during the time a NACK message propagates across the network to the sender and other receivers.
フィードバックの確率論、タイマーベースの抑制のために、NACKサイクルは、バックオフタイムアウトを観察する受信機で始める必要があります。このバックオフタイムアウトを開始すると共に、受信機は、彼らがNACKサイクルを開始した時に送信側の送信シーケンス内の現在の位置を記録することが重要です。抑制バックオフタイムアウトが経過すると、受信機はその修復がNACKを送信するか、または抑制するための意思決定をするには、この記録の送信位置まで必要考慮すべきです。追加コンテンツは、NACKメッセージが送信者と他の受信機にネットワークを介して伝播時間の間、送信者から受信されるように、この制限はなく、抑制が大幅に低減されます。
Receiver NACK Process Initiation Interface Description
レシーバNACKプロセス開始インターフェイス説明
Inputs:
入力：
1) Sender data content with sequencing identifiers from sender transmissions. 2) History of content received from sender.
送信者の送信からのシーケンス識別子を持つ1）送信者のデータ内容。 2）コンテンツの歴史は、送信者から受信しました。
Outputs:
出力：
1) NACK process initiation decision 2) Recorded sender transmission sequence position.
1）NACK処理開始判定2）録画送信元送信シーケンス位置。
An effective NORM feedback suppression mechanism is the use of random backoff timeouts prior to NACK transmission by receivers requiring repairs [10]. Upon expiration of the backoff timeout, a receiver will request repairs unless its pending repair needs have been completely superseded by NACK messages heard from other receivers (when receivers are multicasting NACKs) or from some indicator from the sender. When receivers are unicasting NACK messages, the sender may facilitate NACK suppression by forwarding a representation of NACK content it has received to the group at large or provide some other indicator of the repair information it will be subsequently transmitting.
有効NORMフィードバック抑制機構は、ランダムバックオフの使用が修理を必要とする受信機によって前NACK送信にタイムアウトである[10]。その保留中の修理のニーズが完全に他のレシーバ（受信機はNACKをマルチキャストしている）から、または送信者からのいくつかの指標から聞いたNACKメッセージに取って代わられていない限り、バックオフタイムアウトが満了すると、受信機は、修理を依頼します。受信機はNACKメッセージをユニキャストしている場合、送信者は、それが大でグループに受信したNACKのコンテンツの表現を転送することによってNACK抑制を促進するか、その後に送信される修復情報のいくつかの他のインジケータを提供することができます。
For effective and scalable suppression performance, the backoff timeout periods used by receivers should be independently, randomly picked by receivers with a truncated exponential distribution [6]. This results in the majority of the receiver set holding off transmission of NACK messages under the assumption that the smaller number of "early NACKers" will supersede the repair needs of the remainder of the group. The mean of the distribution should be determined as a function of the current estimate of sender<->group GRTT and a group size estimate that is determined by other mechanisms within the protocol or preset by the multicast application.
効果的かつスケーラブルな抑圧性能のために、受信機によって使用されるバックオフタイムアウト期間は、独立して、ランダムに切り捨てられた指数分布[6]と受信機によってピックアップされるべきです。これは「早期NACKers」のより少ない数がグループの残りの修復ニーズに取って代わるであろうという仮定の下でNACKメッセージの送信をオフに保持し、受信機の大部分をもたらします。 < - >グループGRTT及びマルチキャストアプリケーションによるプロトコルまたはプリセット内の他のメカニズムによって決定されたグループサイズ推定値分布の平均値は、送信者の現在の推定値の関数として決定されるべきです。
A simple algorithm can be constructed to generate random backoff timeouts with the appropriate distribution. Additionally, the algorithm may be designed to optimize the backoff distribution given the number of receivers (R) potentially generating feedback. This "optimization" minimizes the number of feedback messages (e.g., NACK) in the worst-case situation where all receivers generate a NACK. The maximum backoff timeout (T_maxBackoff) can be set to control reliable delivery latency versus volume of feedback traffic. A larger value of T_maxBackoff will result in a lower density of feedback traffic for a given repair cycle. A smaller value of T_maxBackoff results in shorter latency which also reduces the buffering requirements of senders and receivers for reliable transport.
単純なアルゴリズムは、適切な分布を持つランダムバックオフタイムアウトを生成するように構成することができます。さらに、アルゴリズムは、潜在的フィードバックを生成する受信機（R）の数、所与のバックオフ分布を最適化するように設計されてもよいです。この「最適化は、」すべての受信機がNACKを生成し、最悪の場合の状況にフィードバックメッセージ（例えば、NACK）の数を最小限に抑えることができます。最大バックオフタイムアウト（T_maxBackoff）は、フィードバックトラフィックの量に対する信頼できる配信の待ち時間を制御するように設定することができます。 T_maxBackoffの大きな値は、所与の修復サイクルのフィードバックトラフィックの低い密度をもたらすであろう。 T_maxBackoffの値が小さいほど、また信頼性の高い輸送のための送信側と受信側のバッファリング要件を低減短いレイテンシーになります。
Given the receiver group size (R), and maximum allowed backoff timeout (T_maxBackoff), random backoff timeouts (t') with a truncated exponential distribution can be picked with the following algorithm:
以下のアルゴリズムを用いて取り出すことができる切頭指数分布を有する受信機のグループサイズ（R）、および最大許容バックオフタイムアウト（T_maxBackoff）、ランダムバックオフタイムアウト（T '）与えられました：
1) Establish an optimal mean (L) for the exponential backoff based on the group size:
1）グループサイズに基づいて、指数バックオフのための最適な平均値（L）を確立します。
L = ln(R) + 1
L = LN（R）+ 1
2) Pick a random number (x) from a uniform distribution over a range of:
2）の範囲に亘って一様分布からランダム数（X）をピック：
L L L
-------------------- to -------------------- + ----------
T_maxBackoff*(exp(L)-1) T_maxBackoff*(exp(L)-1) T_maxBackoff
3) Transform this random variate to generate the desired random backoff time (t') with the following equation:
3）以下の式を用いて、所望のランダムバックオフ時間（t '）を生成するために、このランダムな変量を変換します。
t' = T_maxBackoff/L * ln(x * (exp(L) - 1) * (T_maxBackoff/L))
T」= T_maxBackoff /のL * LN（X *（EXP（L） - 1）*（T_maxBackoff / L））
This C language function can be used to generate an appropriate random backoff time interval:
このC言語の関数は、適切なランダムバックオフ時間間隔を生成するために使用することができます。
double RandomBackoff(double maxTime, double groupSize)
{
double lambda = log(groupSize) + 1;
double x = UniformRand(lambda/maxTime) +
lambda / (maxTime*(exp(lambda)-1));
return ((maxTime/lambda) *
log(x*(exp(lambda)-1)*(maxTime/lambda)));
} // end RandomBackoff()
where UniformRand(double max) returns random numbers with a uniform distribution from the range of 0..max. For example, based on the POSIX "rand()" function, the following C code can be used:
UniformRand（二重max）は0..MAXの範囲の均一な分布を有する乱数を返す場合。たとえば、POSIX「ランド（）」関数に基づいて、以下のCコードを使用することができます。
double UniformRand(double max) { return (max * ((double)rand()/(double)RAND_MAX)); }
ダブルUniformRand（ダブルMAX）{リターン（最大*（（二重）のrand（）/（ダブル）RAND_MAX））。 }
The number of expected NACK messages generated (N) within the first round trip time for a single feedback event is approximately:
単一のフィードバックイベントの最初のラウンドトリップ時間内（N）生成された期待NACKメッセージの数は、およそ次のとおりです。
N = exp(1.2 * L / (2*T_maxBackoff/GRTT))
N = EXP（1.2 * L /（2 * T_maxBackoff / GRTT））
Thus the maximum backoff time can be adjusted to tradeoff worst-case NACK feedback volume versus latency. This is derived from [6] and assumes T_maxBackoff >= GRTT, and L is the mean of the distribution optimized for the given group size as shown in the algorithm above.
したがって、最大バックオフ時間は、レイテンシに対するトレードオフワーストケースNACKフィードバック量に調整することができます。これは、[6]に由来しT_maxBackoff> = GRTTを想定し、そして上記のアルゴリズムに示すように、Lが所定のグループサイズのために最適化された分布の平均です。
Note that other mechanisms within the protocol may work to reduce redundant NACK generation further. It is suggested that T_maxBackoff be selected as an integer multiple of the sender's current advertised GRTT estimate such that:
プロトコル内の他のメカニズムはさらに冗長NACKの発生を低減するために働くことができることに留意されたいです。 T_maxBackoffは、送信者の現在の公示GRTT見積りようの整数倍として選択することが示唆されています。
T_maxBackoff = K * GRTT ;where K >= 1
T_maxBackoff = K * GRTT;ここで、K> = 1
For general Internet operation, a default value of K=4 is RECOMMENDED for operation with multicast (to the group at large) NACK delivery and a value of K=6 for unicast NACK delivery. Alternate values may be used to for buffer utilization, reliable delivery latency and group size scalability tradeoffs.
一般的なインターネットの動作のために、K = 4のデフォルト値は、NACK配信とユニキャストNACK送達のためのK = 6の値（大でグループに）マルチキャストで動作することをお勧めします。代替値は、バッファの使用率、信頼性の高い配信待ち時間とグループサイズのスケーラビリティのトレードオフのために使用することができます。
Given that (K*GRTT) is the maximum backoff time used by the receivers to initiate NACK transmission, other timeout periods related to the NACK repair process can be scaled accordingly. One of those timeouts is the amount of time a receiver should wait after generating a NACK message before allowing itself to initiate another NACK backoff/transmission cycle (T_rcvrHoldoff). This delay should be sufficient for the sender to respond to the received NACK with repair messages. An appropriate value depends upon the amount of time for the NACK to reach the sender and the sender to provide a repair response. This MUST include any amount of sender NACK aggregation period during which possible multiple NACKs are accumulated to determine an efficient repair response. These timeouts are further discussed in the section below on "Sender NACK Processing and Repair Response".
（K * GRTT）がNACK送信を開始するために受信機によって使用される最大バックオフ時間であることを考えると、NACK修復プロセスに関連する他のタイムアウト期間は、それに応じてスケーリングすることができます。これらのタイムアウトの一つは、受信機は、それ自体が別のNACKバックオフ/送信周期（T_rcvrHoldoff）を開始することを可能にする前に、NACKメッセージを生成した後に待つべき時間の量です。送信者が修理のメッセージを受け取ったNACKに応答するためにこの遅延が十分でなければなりません。 NACKは、送信者と修復応答を提供するために、送信者に到達するために適切な値は、時間の量に依存します。これが可能な複数のNACKは、効率的な修復応答を決定するために蓄積されている間、送信者NACK集約期間の任意の量を含まなければなりません。これらのタイムアウトは、さらに、「送信者NACK処理および修復応答」に、以下のセクションで説明されています。
There are also secondary measures that can be applied to improve the performance of feedback suppression. For example, the sender's data content transmissions can follow an ordinal sequence of transmission. When repairs for data content occur, the receiver can note that the sender has "rewound" its data content transmission position by observing the data object, FEC block number, and FEC symbol identifiers. Receivers SHOULD limit transmission of NACKs to only when the sender's current transmission position exceeds the point to which the receiver has incomplete reception. This reduces premature requests for repair of data the sender may be planning to provide in response to other receiver requests. This mechanism can be very effective for protocol convergence in high loss conditions when transmissions of NACKs from other receivers (or indicators from the sender) are lost. Another mechanism (particularly applicable when FEC is used) is for the sender to embed an indication of impending repair transmissions in current packets sent. For example, the indication may be as simple as an advertisement of the number of FEC packets to be sent for the current applicable coding block.
フィードバック抑制のパフォーマンスを改善するために適用することができ、二次対策もあります。例えば、送信者のデータコンテンツの送信は、送信の順序シーケンスに従うことができます。データコンテンツの修理が発生した場合、受信機は、送信者が「巻き戻し」、そのデータ・オブジェクトを観察することにより、データコンテンツ送信位置、FECブロック番号、及びFECシンボル識別子を有することに注意することができます。受信機は、送信者の現在の送信位置は、受信機が不完全な受信を持つにポイントを超えた場合にのみにNACKの送信を制限する必要があります。これは、送信者が他の受信機の要求に応じて提供することを計画することができるデータの修復のために時期尚早の要求を低減します。他の受信機（または送信者からの指標）からNACKの送信が失われた場合、このメカニズムは、高損失状態におけるプロトコルの収束のために非常に有効であり得ます。送信者が送信された現在のパケット内の修復送信切迫の指標を埋め込むための別の機構（FECが使用される場合に特に適用可能）です。例えば、指示は、現在適用可能な符号化ブロックのために送信されるFECパケットの数の広告のように単純であってもよいです。
Finally, some consideration might be given to using the NACKing history of receivers to weight their selection of NACK backoff timeout intervals. For example, if a receiver has historically been experiencing the greatest degree of loss, it may promote itself to statistically NACK sooner than other receivers. Note this requires there is correlation over successive intervals of time in the loss experienced by a receiver. Such correlation MAY not be present in multicast networks. This adjustment of backoff timeout selection may require the creation of an "early NACK" slot for these historical NACKers. This additional slot in the NACK backoff window will result in a longer repair cycle process that may not be desirable for some applications. The resolution of these trade-offs may be dependent upon the protocol's target application set or network.
最後に、いくつかの考慮事項は、NACKのバックオフタイムアウト間隔の彼らの選択を重み付けする受信機のNACKing履歴を使用することができるかもしれません。受信機は、歴史的に損失の最大の程度を経験されている場合、例えば、それは、他の受信機よりも早くNACKを統計的に自分自身を促進することができます。これは、受信機によって経験される損失の時間の連続した間隔で相関がある必要注意。このような相関関係は、マルチキャストネットワーク内に存在することはできません。バックオフタイムアウト選択のこの調整は、これらの歴史的NACKersための「早期NACK」スロットを作成する必要があります。 NACKバックオフウィンドウのこの追加スロットは、いくつかの用途には望ましくないかもしれない長い修復サイクルプロセスをもたらすであろう。これらのトレードオフの分解能は、プロトコルのターゲットアプリケーションセットまたはネットワークに依存し得ます。
After the random backoff timeout has expired, the receiver will make a decision on whether to generate a NACK repair request or not (i.e., it has been suppressed). The NACK will be suppressed when any of the following conditions has occurred:
ランダムバックオフタイムアウトが満了した後、受信機はNACK修復要求を生成するか否かの決定を行うであろう（すなわち、それが抑制されています）。次のいずれかの条件が発生したとき、NACKが抑制されます。
1) The accumulated state of NACKs heard from other receivers (or forwarding of this state by the sender) is equal to or supersedes the repair needs of the local receiver. Note that the local receiver should consider its repair needs only up to the sender transmission position recorded at the NACK cycle initiation (when the backoff timer was activated).
1）NACKの蓄積状態が他の受信機（または送信者によってこの状態の転送から聞いた）に等しいか、またはローカル受信機の修理の必要性に取って代わります。ローカル受信機はその修復が唯一NACKサイクルの開始時に記録された送信者の送信位置（バックオフタイマーが作動した時）までの必要を検討する必要があることに注意してください。
2) The sender's data content transmission position "rewinds" to a point ordinally less than that of the lowest sequence position of the local receiver's repair needs. (This detection of sender "rewind" indicates the sender has already responded to other receiver repair needs of which the local receiver may not have been aware). This "rewind" event can occur any time between 1) when the NACK cycle was initiated with the backoff timeout activation and 2) the current moment when the backoff timeout has expired to suppress the NACK. Another NACK cycle must be initiated by the receiver when the sender's transmission sequence position exceeds the receiver's lowest ordinal repair point. Note it is possible that the local receiver may have had its repair needs satisfied as a result of the sender's response to the repair needs of other receivers and no further NACKing is required.
2）送信者のデータコンテンツの送信位置は、ローカル受信機の修理の必要性の最小配列位置よりもordinally少ない点に「巻き戻し」。 （送信者のこの検出は、送信者が既にローカル受信機が気づいていない可能性がありそのうち他の受信機の修理のニーズに応えていることを示し、「巻き戻し」）。 NACKサイクルがバックオフタイムアウト活性化を開始し、2）現在の瞬間バックオフタイムアウトがNACKを抑制するために有効期限が切れている場合、このとき「巻き戻し」イベントは、1）の間の任意の時間に起こり得ます。別のNACKサイクルは、送信者の送信順序位置は、受信機の最低序修理ポイントを超えた場合、受信機によって開始されなければなりません。地元の受信機は、他の受信機の修理のニーズとなし、さらにNACKingに送信者の応答の結果が必要とされるように、その修理が満たさ必要が持っている可能性があることに注意してください。
If these conditions have not occurred and the receiver still has pending repair needs, a NACK message is generated and transmitted. The NACK should consist of an accumulation of repair needs from the receiver's lowest ordinal repair point up to the current sender transmission sequence position. A single NACK message should be generated and the NACK message content should be truncated if it exceeds the payload size of single protocol message. When such NACK payload limits occur, the NACK content SHOULD contain requests for the ordinally lowest repair content needed from the sender.
これらの条件が発生していないと受信機がまだ修理のニーズを保留している場合は、NACKメッセージが生成されて送信されます。 NACKは、現在の送信者の送信順序位置に受信者の最低序修理ポイントアップから修理ニーズの蓄積で構成する必要があります。単一NACKメッセージが生成されるべきであり、それは、単一のプロトコルメッセージのペイロードサイズを超えた場合、NACKメッセージコンテンツが切り捨てられるべきです。このようNACKのペイロードの制限が発生した場合、NACKの内容は、送信者から必要なordinally最低修理コンテンツに対する要求を含むべきです。
NACK Suppression Interface Description
NACK抑制インターフェイス説明
Inputs:
入力：
1) NACK process initiation decision. 2) Recorded sender transmission sequence position. 3) Sender GRTT. 4) Sender group size estimate. 5) Application-defined bound on backoff timeout period. 6) NACKs from other receivers. 7) Pending repair indication from sender (may be forwarded NACKs). 8) Current sender transmission sequence position.
1）NACKプロセスの開始決定。 2）送信側送信シーケンス位置を記録しました。 3）送信者GRTT。 4）送信者グループサイズ推定。 5）アプリケーション定義のバックオフタイムアウト時間に結合しました。 6）他の受信機からNACKを。送信者から7）保留修復指示（NACKを転送することができます）。 8）現在の送信元、送信順序位置。
Outputs:
出力：
1) Yes/no decision to generate NACK message upon backoff timer expiration.
バックオフタイマーの満了時にNACKメッセージを生成するために、1）はい/いいえ決断ません。
The content of NACK messages generated by reliable multicast receivers will include information detailing their current repair needs. The specific information depends on the use and type of FEC in the NORM repair process. The identification of repair needs is dependent upon the data content identification (See Section 3.5 below). At the highest level the NACK content will identify the sender to which the NACK is addressed and the data transport object (or stream) within the sender's transmission that needs repair. For the indicated transport entity, the NACK content will then identify the specific FEC coding blocks and/or symbols it requires to reconstruct the complete transmitted data. This content may consist of FEC block erasure counts and/or explicit indication of missing blocks or symbols (segments) of data and FEC content. It should also be noted that NORM can be effectively instantiated without a requirement for reliable NACK delivery using the techniques discussed here.
信頼性の高いマルチキャスト受信機によって生成されたNACKメッセージの内容は、現在修理のニーズを詳細な情報が含まれます。具体的な情報は、NORM修復過程におけるFECの使用や種類によって異なります。修復の必要の識別は、データコンテンツ識別情報に依存している（以下のセクション3.5を参照）。最高レベルでNACK含量はNACKがアドレス指定された送信者と修理を必要と送信者の送信中のデータのトランスポート・オブジェクト（またはストリーム）を識別する。指示されたトランスポートエンティティに対して、NACKの含有量は、それが完全に送信されたデータを再構成する必要があり、特定のFEC符号化ブロックおよび/または記号を識別する。このコンテンツは、FECブロック消去カウントおよび/またはデータとFECコンテンツの失われたブロック又はシンボル（セグメント）の明示的な指示からなることができます。また、NORMが効果的にここで説明する技術を使用して、信頼性の高いNACKの配信を必要とせずにインスタンス化することができることに留意すべきです。
Where FEC-based repair is used, the NACK message content will minimally need to identify the coding block(s) for which repair is needed and a count of erasures (missing packets) for the coding block. An exact count of erasures implies the FEC algorithm is capable of repairing _any_ loss combination within the coding block.
FECベースの修復が使用される場合、NACKメッセージの内容は、最小符号化ブロックのために修復が必要とされる符号化ブロック（S）と消去の回数（欠落パケット）を特定する必要があります。消失の正確な数は、FECアルゴリズムは、符号化ブロック内_any_損失の組み合わせを修復することが可能である暗示します。
This count may need to be adjusted for some FEC algorithms. Considering that multiple repair rounds may be required to successfully complete repair, an erasure count also implies that the quantity of unique FEC parity packets the server has available to transmit is essentially unlimited (i.e., the server will always be able to provide new, unique, previously unsent parity packets in response to any subsequent repair requests for the same coding block). Alternatively, the sender may "round-robin" transmit through its available set of FEC symbols for a given coding block, and eventually affect repair. For a most efficient repair strategy, the NACK content will need to also _explicitly_ identify which symbols (information and/or parity) the receiver requires to successfully reconstruct the content of the coding block. This will be particularly true of small to medium size block FEC codes (e.g., Reed Solomon) that are capable of provided a limited number of parity symbols per FEC coding block.
このカウントは、いくつかのFECアルゴリズムのために調整する必要があるかもしれません。複数の修理ラウンドが正常に完了し、修理に必要なことを考慮すると、消去回数もユニークなFECパリティの量がサーバーにパケットことを意味し送信するために利用できる持っている本質的に無制限である（つまり、サーバは常に、新しいユニークなを提供することができるようになります同じ符号化ブロックのための任意の後続の修復要求）に応答して、以前に未送信パリティパケット。また、送信者は、「ラウンドロビン」は、与えられたブロック符号化のためのFEC記号のその使用可能なセットを介して送信することが可能で、最終的に修理に影響を与えます。最も効率的な修復戦略のために、NACKの含有量は、受信機が正常に符号化ブロックの内容を再構成するために必要とするシンボル（情報及び/又はパリティ）を識別_explicitly_する必要があります。これは、FEC符号化ブロック当たりのパリティシンボルの限定された数を提供することが可能な中型ブロックFEC符号（例えば、リードソロモン）に小の特に当てはまるであろう。
When FEC is not used as part of the repair process, or the protocol instantiation is required to provide reliability even when the sender has transmitted all available parity for a given coding block (or the sender's ability to buffer transmission history is exceeded by the delay*bandwidth*loss characteristics of the network topology), the NACK content will need to contain _explicit_ coding block and/or segment loss information so that the sender can provide appropriate repair packets and/or data retransmissions. Explicit loss information in NACK content may also potentially serve other purposes. For example, it may be useful for decorrelating loss characteristics among a group of receivers to help differentiate candidate congestion control bottlenecks among the receiver set.
FECは、修復プロセスの一部、またはプロトコルのインスタンスとして使用されていない場合*送信者は、所与のコードブロックのための利用可能なすべてのパリティを送信した（または送信履歴をバッファリングする送信者の能力は、遅延を超えた場合であっても信頼性を提供するために必要とされます送信者が適切な修復パケット及び/又はデータ再送信を提供することができるように、帯域幅、ネットワークトポロジの*損失特性）は、NACK含量が_explicit_符号化ブロック及び/又はセグメント損失情報を含む必要があります。 NACKコンテンツ内の明示的な損失情報も潜在的に他の目的を果たすことができます。例えば、受信機セットのうち候補輻輳制御のボトルネックを区別するために役立つ受信機のグループのうち、損失特性を非相関化するために有用であり得ます。
When FEC is used and NACK content is designed to contain explicit repair requests, there is a strategy where the receivers can NACK for specific content that will help facilitate NACK suppression and repair efficiency. The assumptions for this strategy are that sender may potentially exhaust its supply of new, unique parity packets available for a given coding block and be required to explicitly retransmit some data or parity symbols to complete reliable transfer. Another assumption is that an FEC algorithm where any parity packet can fill any erasure within the coding block (e.g., Reed Solomon) is used. The goal of this strategy is to make maximum use of the available parity and provide the minimal amount of data and repair transmissions during reliable transfer of data content to the group.
FECが使用され、NACKのコンテンツは、明示的な修理要求を含むように設計されている場合は、NACK抑制や修理の効率化を促進するのに役立ちます特定のコンテンツのための受信機ができNACK戦略があります。この戦略のための前提は、送信者が潜在的に与えられた符号化ブロックのために利用できる新しい、ユニークなパリティパケットのその供給を使い果たして、明示的に信頼性の高い転送を完了するためにいくつかのデータやパリティシンボルを再送信する必要があることです。別の仮定は、任意のパリティパケットが符号化ブロック（例えば、リードソロモン）内の任意の消去を満たすことができるFECアルゴリズムが使用されることです。この戦略の目標は、可能なパリティを最大限に活用し、グループへのデータコンテンツの信頼性の高い転送中のデータや修理送信の最小限の量を提供することです。
When systematic FEC codes are used, the sender transmits the data content of the coding block (and optionally some quantity of parity packets) in its initial transmission. Note that a systematic FEC coding block is considered to be logically made up of the contiguous set of data vectors plus parity vectors for the given FEC algorithm used. For example, a coding scheme that provides for 64 data symbols and 32 parity symbols per coding block would contain FEC symbol identifiers in the range of 0 to 95.
システマティックFEC符号が使用される場合、送信側は初期伝送に（及びパリティパケットの一部量をオプションとして）符号化ブロックのデータ内容を送信します。体系的FEC符号化ブロックを論理的に使用される所与のFECアルゴリズムのためのデータベクトルとパリティベクトルの連続したセットで構成されていると考えられることに注意してください。例えば、ブロック符号化あたり64個のデータ・シンボルと32個のパリティ・シンボルを提供する符号化方式は0〜95の範囲内のFEC記号識別子を含むであろう。
Receivers then can construct NACK messages requesting sufficient content to satisfy their repair needs. For example, if the receiver has three erasures in a given received coding block, it will request transmission of the three lowest ordinal parity vectors in the coding block. In our example coding scheme from the previous paragraph, the receiver would explicitly request parity symbols 64 to 66 to fill its three erasures for the coding block. Note that if the receiver's loss for the coding block exceeds the available parity quantity (i.e., greater than 32 missing symbols in our example), the receiver will be required to construct a NACK requesting all (32) of the available parity symbols plus some additional portions of its missing data symbols in order to reconstruct the block. If this is done consistently across the receiver group, the resulting NACKs will comprise a minimal set of sender transmissions to satisfy their repair needs.
レシーバは、その修理のニーズを満たすために十分なコンテンツを要求するNACKメッセージを構築することができます。受信機は、所与の受信ブロック符号化三の消去を有する場合、例えば、それは、符号化ブロック三個の最低順序のパリティベクトルの送信を要求します。前の段落からの符号化方式の例では、受信機は、明示的に符号化ブロックのためにその3つの消去を埋めるために64〜66パリティシンボルを要求します。符号化ブロックのための受信機の損失が可能なパリティ量を超えた場合（すなわち、この例では32より大きい行方不明の記号）は、受信機が利用できるパリティシンボルに加えていくつかの追加のすべて（32）を要求するNACKを構築するために必要とされることに注意してくださいブロックを再構築するために、その欠落データシンボルの部分。これは、受信グループ全体で一貫して行われた場合、結果としてのNACKは、彼らの修理のニーズを満たすために、送信者の送信の最小セットを含むことになります。
In summary, the rule is to request the lower ordinal portion of the parity content for the FEC coding block to satisfy the erasure repair needs on the first NACK cycle. If the available number of parity symbols is insufficient, the receiver will also request the subset of ordinally highest missing data symbols to cover what the parity symbols will not fill. Note this strategy assumes FEC codes such as Reed-Solomon for which a single parity symbol can repair any erased symbol. This strategy would need minor modification to take into account the possibly limited repair capability of other FEC types. On subsequent NACK repair cycles where the receiver may have received some portion of its previously requested repair content, the receiver will use the same strategy, but only NACK for the set of parity and/or data symbols it has not yet received. Optionally, the receivers could also provide a count of erasures as a convenience to the sender or intermediate systems assisting NACK operation.
要約すると、ルールは、最初のNACKサイクルで消去修復ニーズを満たすためにFEC符号化ブロックのパリティ量の低い順序の部分を要求することです。パリティシンボルの利用可能数が不足している場合、受信機は、パリティ記号が記入しませんどのようなカバーするordinally最高の欠落したデータシンボルのサブセットを要求します。この戦略は、単一のパリティシンボルは、任意の消去シンボルを修復することができたため、このようなリードソロモンとしてFECコードを前提としています。この戦略は、アカウントに他のFECタイプの可能性が制限され、修復機能を取るためにマイナーな変更が必要になります。受信機は、その以前に要求されたリペアのコンテンツの一部を受信している場合があり、その後のNACK修復サイクルで、受信機は、それがまだ受信していないパリティ及び/又はデータ・シンボルのセットに対してのみNACKしかし、同じ方法を使用します。必要に応じて、受信機はまた、NACK操作をアシスト送信者または中間システムへの便宜として消去の数を提供することができます。
After receipt and accumulation of NACK messages during the aggregation period, the sender can begin transmission of fresh (previously untransmitted) parity symbols for the coding block based on the highest receiver erasure count _if_ it has a sufficient quantity of parity symbols that were _not_ previously transmitted. Otherwise, the sender MUST resort to transmitting the explicit set of repair vectors requested. With this approach, the sender needs to maintain very little state on requests it has received from the group without need for synchronization of repair requests from the group. Since all receivers use the same consistent algorithm to express their explicit repair needs, NACK suppression among receivers is simplified over the course of multiple repair cycles. The receivers can simply compare NACKs heard from other receivers against their own calculated repair needs to determine whether they should transmit or suppress their pending NACK messages.
それは_not_以前に送信されたパリティシンボルの十分な量を有する_if_集計期間中にレシートとNACKメッセージの蓄積後、送信側は、最高受信消去回数に基づいて、符号化ブロックのための新鮮な（以前に未送信）パリティシンボルの送信を開始することができます。そうでなければ、送信者は、要求された修理ベクトルの明示的なセットを送信するに頼る必要があります。このアプローチでは、送信者は、それがグループからの修理依頼の同期を必要とせずにグループから受信した要求に非常に少ない状態を維持する必要があります。すべての受信機が、それらの明示的な修復の必要性を表現するために同じ一致アルゴリズムを使用するので、受信機のうちNACK抑制は、複数の補修サイクルにわたって単純化されます。受信機は、単にのNACKが自分の計算された修理に対して他の受信機から聞い比較することができ、彼らはその保留NACKメッセージを送信するか、抑制するかどうかを判断する必要があります。
The format of NACK content will depend on the protocol's data service model and the format of data content identification the protocol uses. This NACK format also depends upon the type of FEC encoding (if any) used. Figure 2 illustrates a logical, hierarchical transmission content identification scheme, denoting that the notion of objects (or streams) and/or FEC blocking is optional at the protocol instantiation's discretion. Note that the identification of objects is with respect to a given sender. It is recommended that transport data content identification is done within the context of a sender in a given session. Since the notion of session "streams" and "blocks" is optional, the framework degenerates to that of typical transport data segmentation and reassembly in its simplest form.
NACKコンテンツのフォーマットは、プロトコルのデータ・サービス・モデルおよびプロトコルが使用するデータコンテンツ識別の形式に依存するであろう。このNACKフォーマットも使用FEC符号化の種類（もしあれば）に依存します。図2は、オブジェクト（またはストリーム）の概念及び/又はFECブロックは、プロトコルインスタンスの裁量で任意選択であることを示す、論理的、階層化伝送コンテンツ識別方式を示します。オブジェクトの識別は、所与の送信者に対してであることに留意されたいです。トランスポートデータコンテンツの識別は、所与のセッションにおける送信元のコンテキスト内で行われることが推奨されます。セッション「ストリーム」と「ブロック」の概念は任意であるため、フレームワークは、その最も単純な形式で典型的なトランスポート・データ分割及び再組立のものに退化します。
Session_ \_ Sender_ \_ [Object/Stream(s)]_ \_ [FEC Blocks]_ \_ Symbols
Session_ \ _ Sender_ \ _ [オブジェクト/ストリーム（S）] _ \ _ [FECブロック] _ \ _シンボル
Fig. 2: NORM Data Content Identification Hierarchy
図2：NORMデータコンテンツの識別階層
The format of NACK messages should meet the following goals:
NACKメッセージの形式は、次の目標を満たしている必要があります。
1) Able to identify transport data unit transmissions required to repair a portion of the received content, whether it is an entire missing object/stream (or range), entire FEC coding block(s), or sets of symbols,
1））、それは全体欠落オブジェクト/ストリーム（または範囲であるか否かを、受信したコンテンツの部分を修復するために必要なトランスポート・データ・ユニットの送信を識別することができ、全体のFEC符号化ブロック（単数または複数）、または記号の集合、
2) Be simple to process for NACK aggregation and suppression,
2）NACK集約と抑制のために処理するために、単純なこと、
3) Be capable of including NACKs for multiple objects, FEC coding blocks and/or symbols in a single message, and
3）複数のオブジェクトのためのNACK、FEC符号化ブロックおよび/または単一のメッセージ内のシンボルを含む可能、及び
4) Have a reasonably compact format.
4）合理的にコンパクトな形式を持っています。
If the NORM transport object/stream is identified with an <objectId> and the FEC symbol being transmitted is identified with an <fecPayloadId>, the concatenation of <objectId::fecPayloadId> comprises a basic transport protocol data unit (TPDU) identifier for symbols from a given source. NACK content can be composed of lists and/or ranges of these TPDU identifiers to build up NACK messages to describe the receivers repair needs. If no hierarchical object delineation or FEC blocking is used, the TPDU is a simple linear representation of the data symbols transmitted by the sender. When the TPDU represents a hierarchy for purposes of object/stream delineation and/or FEC blocking, the NACK content unit may require flags to indicate which portion of the TPDU is applicable. For example, if an entire "object" (or range of objects) is missing in the received data, the receiver will not necessarily know the appropriate range of <sourceBlockNumbers> or <encodingSymbolIds> for which to request repair and thus requires some mechanism to request repair (or retransmission) of the entire unit represented by an <objectId>. The same is true if entire FEC coding blocks represented by one or a range of <sourceBlockNumbers> have been lost.
NORMトランスポート・オブジェクト/ストリームは<OBJECTID>で識別され、FECシンボルが送信される場合はシンボルの<fecPayloadId>、<OBJECTID :: fecPayloadId>の連結は、基本的なトランスポート・プロトコル・データ・ユニットを含む（TPDU）識別子で識別されます与えられたソースから。 NACKのコンテンツは、受信機の修理のニーズを記述するためにNACKメッセージを構築するためのリストおよび/またはこれらのTPDU識別子の範囲で構成することができます。何階層オブジェクトの描写又はFECブロックが使用されていない場合、TPDUは、送信者によって送信されたデータシンボルの単純な線形表現です。 TPDUオブジェクト/ストリーム描写及び/又はFECブロックの目的のための階層を表す場合、NACKコンテンツユニットが適用されるTPDUの部分を示すために、フラグを必要とし得ます。例えば、全体の「オブジェクト」（またはオブジェクトの範囲）、受信したデータに欠落している場合、受信機は、必ずしも<sourceBlockNumbers>の適切な範囲を知っているか<encodingSymbolIds>修理を要求する対象の、したがってに何らかの機構を必要としないであろう<OBJECTID>で表されるユニット全体の要求修復（または再送信）。同じことは、一つまたは<sourceBlockNumbers>の範囲によって表される全体FEC符号化ブロックが失われている場合は、trueです。
NACK Content Interface Description
NACKコンテンツインターフェイス説明
Inputs:
入力：
1) Sender identification. 2) Sender data identification. 3) Sender FEC Object Transmission Information. 4) Recorded sender transmission sequence position. 5) Current sender transmission sequence position. History of repair needs for this sender.
1）送信者の識別。 2）送信者データ識別。 3）送信者FECオブジェクト伝送情報。 4）送信側送信シーケンス位置を記録しました。 5）現在の送信元、送信順序位置。修理の歴史は、この送信者のために必要です。
Outputs:
出力：
1) NACK message with repair requests.
修理依頼を持つ1）NACKメッセージ。
Upon reception of a repair request from a receiver in the group, the sender will initiate a repair response procedure. The sender may wish to delay transmission of repair content until it has had sufficient time to accumulate potentially multiple NACKs from the receiver set. This allows the sender to determine the most efficient repair strategy for a given transport stream/object or FEC coding block. Depending upon the approach used, some protocols may find it beneficial for the sender to provide an indicator of pending repair transmissions as part of its current transmitted message content. This can aid some NACK suppression mechanisms. The amount of time to perform this NACK aggregation should be sufficient to allow for the maximum receiver NACK backoff window ("T_maxBackoff" from Section 3.2.2) and propagation of NACK messages from the receivers to the sender. Note the maximum transmission delay of a message from a receiver to the sender may be approximately (1*GRTT) in the case of very asymmetric network topology with respect to transmission delay. Thus, if the maximum receiver NACK backoff time is T_maxBackoff = K*GRTT, the sender NACK aggregation period should be equal to at least:
グループ内の受信機からの修理依頼を受信すると、送信者は、修復応答手順を開始します。送信者は、受信機セットから潜在的に複数のNACKを蓄積するのに十分な時間があったまで修復コンテンツの送信を遅延することを望むかもしれません。これは、送信者が与えられたトランスポートストリーム/オブジェクト又はFEC符号化ブロックのための最も効率的な修復戦略を決定することを可能にします。使用されるアプローチに応じて、いくつかのプロトコルは、それが有益送信者が現在送信されるメッセージの内容の一部として保留中の修復送信の指標を提供するために見つけることができます。これは、いくつかのNACK抑制メカニズムを支援することができます。このNACK集約を実行する時間は、受信機から送信側に最大受信NACKバックオフウィンドウ（セクション3.2.2から「T_maxBackoff」）とNACKメッセージの伝播を可能にするのに十分であるべきです。受信側から送信側へのメッセージの最大送信遅延は送信遅延に対して非常に非対称なネットワークトポロジの場合には約（1 * GRTT）であってもよい注意。したがって、最大受信NACKバックオフ時間がT_maxBackoff = K * GRTT、送信NACK集約期間は、少なくともに等しくなるべきである場合。
T_sndrAggregate = T_maxBackoff + 1*GRTT = (K+1)*GRTT
T_sndrAggregate = T_maxBackoff + 1 * GRTT =（K + 1）* GRTT
Immediately after the sender NACK aggregation period, the sender will begin transmitting repair content determined from the aggregate NACK state and continue with any new transmission. Also, at this time, the sender should observe a "holdoff" period where it constrains itself from initiating a new NACK aggregation period to allow propagation of the new transmission sequence position due to the repair response to the receiver group. To allow for worst case asymmetry, this "holdoff" time should be:
すぐに送信者NACKの集計期間の後に、送信者は、集約NACK状態から決定修理内容の送信を開始し、任意の新たな伝送を続けます。また、この時点では、送信者は、それが原因レシーバグループに修復応答に新しい送信シーケンス位置の伝播を可能にするための新しいNACK集約期間の開始から、それ自体を制約する「ホールドオフ」期間を観察する必要があります。最悪の非対称性を可能にするため、この「ホールドオフ」の時間は次のようになります。
T_sndrHoldoff = 1*GRTT
T_sndrHoldoff = 1 * GRTT
Recall that the receivers will also employ a "holdoff" timeout after generating a NACK message to allow time for the sender's response. Given a sender <T_sndrAggregate> plus <T_sndrHoldoff> time of (K+1)*GRTT, the receivers should use holdoff timeouts of:
受信機はまた、送信者の応答のための時間を確保するためにNACKメッセージを生成した後、「ホールドオフ」タイムアウトを採用することを思い出してください。 （K + 1）* GRTTの送信者<T_sndrAggregate>プラス<T_sndrHoldoff>時間を考えると、受信機は、のタイムアウトをホールドオフ使用する必要があります。
T_rcvrHoldoff = T_sndrAggregate + T_sndrHoldoff = (K+2)*GRTT
T_rcvrHoldoff = T_sndrAggregate + T_sndrHoldoff =（K + 2）* GRTT
This allows for a worst-case propagation time of the receiver's NACK to the sender, the sender's aggregation time and propagation of the sender's response back to the receiver. Additionally, in the case of unicast feedback from the receiver set, it may be useful for the sender to forward (via multicast) a representation of its aggregated NACK content to the group to allow for NACK suppression when there is not multicast connectivity among the receiver set.
これは、送信者、送信者の集合時間と戻って受信機に送信者の応答の伝播にレシーバのNACKの最悪の場合の伝播時間が可能になります。送信者が（マルチキャストを介して）グループへの集約NACKコンテンツの表現を転送するために、さらに、受信機セットからユニキャストフィードバックの場合には、受信機の間でマルチキャスト接続が存在しない場合にNACK抑制を可能にするために有用であり得ますセットする。
At the expiration of the <T_sndrAggregate> timeout, the sender will begin transmitting repair messages according to the accumulated content of NACKs received. There are some guidelines with regards to FEC-based repair and the ordering of the repair response from the sender that can improve reliable multicast efficiency:
<T_sndrAggregate>タイムアウトの満了時に、送信者は、NACKの蓄積コンテンツ受信に応じて補修メッセージの送信を開始します。 FECベースの修理および信頼性の高いマルチキャスト効率を向上させることができ、送信者からの修復応答の順序付けに関していくつかのガイドラインがあります。
1) When FEC is used, it is beneficial that the sender transmit previously untransmitted parity content as repair messages whenever possible. This maximizes the receiving nodes' ability to reconstruct the entire transmitted content from their individual subsets of received messages.
FECが使用される場合1）、可能な限り送信者が修理メッセージとして以前に未送信パリティ・コンテンツを送信することは有益です。これは、受信したメッセージの個々の部分集合からの全送信されたコンテンツを再構成する受信ノードの能力を最大化します。
2) The transmitted object and/or stream data and repair content should be indexed with monotonically increasing sequence numbers (within a reasonably large ordinal space). If the sender observes the discipline of transmitting repair for the earliest content (e.g., ordinally lowest FEC blocks) first, the receivers can use a strategy of withholding repair requests for later content until the sender once again returns to that point in the object/stream transmission sequence. This can increase overall message efficiency among the group and help work to keep repair cycles relatively synchronized without dependence upon strict time synchronization among the sender and receivers. This also helps minimize the buffering requirements of receivers and senders and reduces redundant transmission of data to the group at large.
2）送信されたオブジェクト及び/又はストリームデータ及び修理内容）が適度に大きい順序空間内（単調に増加するシーケンス番号で索引付けされるべきです。送信者は最古のコンテンツ（例えば、ordinally最低FECブロック）のために修理を送信する規律を観察した場合、送信者が再びオブジェクト/ストリームにそのポイントに戻るまで最初、レシーバは後でコンテンツの修理依頼を源泉徴収の戦略を使用することができます送信シーケンス。これは、グループの中で、全体的なメッセージの効率を高め、比較的送信者と受信機の間の厳密な時間同期に依存せずに同期修理サイクルを維持するために仕事をすることができます。また、これは受信機と送信側のバッファリング要件を最小限に抑えることができますし、大規模で、グループへのデータの冗長伝送を低減します。
Sender Repair Response Interface Description
送信者の修復応答インターフェイス説明
Inputs:
入力：
1) Receiver NACK messages 2) Group timing information
1）レシーバNACKメッセージ2）グループタイミング情報
Outputs
アウトプット
1) Repair messages (FEC and/or Data content retransmission) 2) Advertisement of current pending repair transmissions when unicast receiver feedback is detected.
1）修復メッセージ（FEC及び/又はデータコンテンツ再送）現在保留中の修復トランスミッションの2）広告ユニキャスト受信機からのフィードバックが検出されます。
Consideration should be given to the policies and procedures by which new receivers join a group (perhaps where reliable transmission is already in progress) and begin requesting repair. If receiver joins are unconstrained, the dynamics of group membership may impede the application's ability to meet its goals for forward progression of data transmission. Policies limiting the opportunities when receivers begin participating in the NACK process may be used to achieve the desired behavior. For example, it may be beneficial for receivers to attempt reliable reception from a newly-heard sender only upon non-repair transmissions of data in the first FEC block of an object or logical portion of a stream. The sender may also implement policies limiting the receivers from which it will accept NACK requests, but this may be prohibitive for scalability reasons in some situations. Alternatively, it may be desirable to have a looser transport synchronization policy and rely upon session management mechanisms to limit group dynamics that can cause poor performance, in some types of bulk transfer applications (or for potential interactive reliable multicast applications).
対価は、新たな受信機は、（信頼性の高い伝送がすでに進行中であるかもしれない）のグループに参加し、修理を依頼始めることにより、ポリシーや手順に与えられるべきです。受信機があるが、制約のない参加した場合、グループメンバーシップのダイナミクスは、データ伝送の前進のためにその目標を達成するために、アプリケーションの能力を妨げることがあります。受信機はNACKプロセスに参加し始める機会を制限するポリシーは、望ましい行動を達成するために使用することができます。受信機が唯一のオブジェクトまたはストリームの論理的な部分の最初のFECブロック内のデータの非修復送信時に新たに聞いた送信者からの信頼できる受信を試みるために、例えば、それは有益であり得ます。送信者はまた、NACK要求を受け入れますが、これは、いくつかの状況では、スケーラビリティの理由から法外かもしれそこから受信機を制限する政策を実施することができます。あるいは、バルク転送アプリケーションのいくつかのタイプに（または潜在的な対話信頼できるマルチキャストアプリケーションのために）、緩い輸送同期ポリシーを持ち、パフォーマンスの低下を引き起こす可能性があるグループダイナミクスを制限するためにセッション管理メカニズムに依存することが望ましい場合があります。
Group Join Policy Interface Description
グループポリシーのインターフェイス説明に参加
Inputs:
入力：
1) Current object/stream data/repair content and sequencing identifiers from sender transmissions.
送信者の送信から1）現在のオブジェクト/ストリームデータ/修理内容および配列識別子。
Outputs:
出力：
1) Receiver yes/no decision to begin receiving and NACKing for reliable reception of data
1）レシーバは、はい/いいえの決定は、信頼性の高いデータ受信するための受信やNACKingを開始しないように
In a NORM protocol (or other multicast protocols) where there is the potential for multiple sources of data, it is necessary to provide some mechanism to uniquely identify the sources (and possibly some or all receivers in some cases) within the group. Identity based on arriving packet source addresses is insufficient for several reasons. These reasons include routing changes for hosts with multiple interfaces that result in different packet source addresses for a given host over time, network address translation (NAT) or firewall devices, or other transport/network bridging approaches. As a result, some type of unique source identifier <sourceId> field should be present in packets transmitted by reliable multicast session members.
データの複数のソースの可能性があるNORMプロトコル（または他のマルチキャストプロトコル）には、一意のグループ内（おそらくいくつかのケース内の一部またはすべての受信機）のソースを識別するための何らかの機構を設ける必要があります。パケットの送信元アドレスを到着に基づくアイデンティティは、いくつかの理由では不十分です。これらの理由は、経時的な特定のホスト、ネットワークアドレス変換（NAT）またはファイアウォールデバイス、または他のトランスポート/ネットワークブリッジのアプローチのための異なるパケットの送信元アドレスにつながる複数のインタフェースを持つホストのルーティングの変更を含みます。その結果、固有のソース識別子のいくつかのタイプは、<ソースID>フィールドは、信頼性の高いマルチキャストセッションメンバーによって送信されたパケット内に存在しなければなりません。
The data and repair content transmitted by a NORM sender requires some form of identification in the protocol header fields. This identification is required to facilitate the reliable NACK-oriented repair process. These identifiers will also be used in NACK messages generated. This building block document assumes two very general types of data that may comprise bulk transfer session content. One type is static, discrete objects of finite size and the other is continuous non-finite streams. A given application may wish to reliably multicast data content using either one or both of these paradigms. While it may be possible for some applications to further generalize this model and provide mechanisms to encapsulate static objects as content embedded within a stream, there are advantages in many applications to provide distinct support for static bulk objects and messages with the context of a reliable multicast session. These applications may include content caching servers, file transfer, or collaborative tools with bulk content. Applications with requirements for these static object types can then take advantage of transport layer mechanisms (i.e., segmentation/reassembly, caching, integrated forward error correction coding, etc.) rather than being required to provide their own mechanisms for these functions at the application layer.
NORM送信者によって送信されたデータ及び修理内容は、プロトコルヘッダフィールドの識別のいくつかのフォームを必要とします。この識別は、信頼性がNACK指向の修復プロセスを容易にするために必要とされます。これらの識別子はまた、生成されたNACKメッセージで使用されます。このビルディングブロックの文書は、バルク転送セッションのコンテンツを含むことができるデータの2つの非常に一般的なタイプを想定しています。一つのタイプは有限の大きさの静的な、別個のオブジェクトであり、他方は連続的な非有限のストリームです。所与のアプリケーションは、1つ又はこれらのパラダイムの両方を使用することを確実にマルチキャストデータのコンテンツを望むかもしれません。いくつかのアプリケーションは、さらに、このモデルを一般化し、ストリーム内に埋め込まれたコンテンツとして、静的オブジェクトをカプセル化するメカニズムを提供することが可能かもしれないが、利点は、信頼性の高いマルチキャストの文脈で静的バルクオブジェクトやメッセージの明確なサポートを提供するために、多くのアプリケーションでありますセッション。これらのアプリケーションは、バルクコンテンツとコンテンツをキャッシュサーバ、ファイル転送、またはコラボレーション・ツールを含むことができます。これらの静的オブジェクトタイプの要件を持つアプリケーションは、次に、むしろアプリケーション層でこれらの機能のための独自のメカニズムを提供するために必要とされるよりもトランスポート層機構（すなわち、セグメント化/再アセンブリ、キャッシング、統合された順方向誤り訂正符号化、等）を活用することができ。
As noted, some applications may alternatively desire to transmit bulk content in the form of one or more streams of non-finite size. Example streams include continuous quasi-real-time message broadcasts (e.g., stock ticker) or some content types that are part of collaborative tools or other applications. And, as indicated above, some applications may wish to encapsulate other bulk content (e.g., files) into one or more streams within a multicast session.
述べたように、いくつかのアプリケーションは、代わりに、非有限の大きさの1つ以上のストリームの形で一括コンテンツを送信することを望むことができます。例えばストリームは、連続、準リアルタイムメッセージブロードキャスト（例えば、株式ティッカー）またはコラボレーションツールや他のアプリケーションの一部であるいくつかのコンテンツタイプを含みます。そして、上述したように、いくつかのアプリケーションは、マルチキャストセッション内で1つ以上のストリームに他のバルクコンテンツ（例えば、ファイル）をカプセル化することを望むかもしれません。
The components described within this building block document are envisioned to be applicable to both of these models with the potential for a mix of both types within a single multicast session. To support this requirement, the normal data content identification should include a field to uniquely identify the object or stream <objectId> within some reasonable temporal or ordinal interval. Note that it is _not_ expected that this data content identification will be globally unique. It is expected that the object/stream identifier will be unique with respect to a given sender within the reliable multicast session and during the time that sender is supporting a specific transport instance of that object or stream.
このビルディング・ブロック・ドキュメント内に記載された成分は、単一のマルチキャストセッション内で両方のタイプの混合のための可能性を有するこれらのモデルの両方に適用可能であることが想定されます。この要件をサポートするために、通常のデータ内容識別を一意にいくつかの合理的な時間的または序間隔内のオブジェクトまたはストリーム<OBJECTID>を識別するためのフィールドを含むべきです。 _not_このデータコンテンツの識別がグローバルに一意であることが予想されることに注意してください。オブジェクト/ストリーム識別子が信頼できるマルチキャストセッション内の送信者がそのオブジェクトまたはストリームの特定のトランスポート・インスタンスをサポートしている時間中に所与の送信者に対して一意であることが期待されます。
Since the "bulk" object/stream content usually requires segmentation, some form of segment identification must also be provided. This segment identifier will be relative to any object or stream identifier that has been provided. Thus, in some cases, NORM protocol instantiations may be able to receive transmissions and request repair for multiple streams and one or more sets of static objects in parallel. For protocol instantiations employing FEC the segment identification portion of the data content identifier may consist of a logical concatenation of a coding block identifier <sourceBlockNumber> and an identifier for the specific data or parity symbol <encodingSymbolId> of the code block. The FEC Building Block document [9] provides a standard message format for identifying FEC transmission content. NORM protocol instantiations using FEC SHOULD follow that document's guidelines.
「バルク」オブジェクト/ストリームコンテンツは、通常、セグメント化を必要とするため、セグメント識別の何らかの形も提供されなければなりません。このセグメント識別子が提供された任意のオブジェクトまたはストリーム識別子に対してであろう。したがって、いくつかのケースでは、NORMプロトコルインスタンスは、複数のストリームと並行して静的オブジェクトの1つまたは複数のセットのための送信要求修復を受信することであってもよいです。 FECを用いるプロトコルのインスタンスのためのデータコンテンツ識別子のセグメント識別部は、符号化ブロック識別子<sourceBlockNumber>の論理的連結及び<encodingSymbolId>コードブロックの特定のデータまたはパリティシンボルの識別子から構成されてもよいです。 FECビルディングブロック文献[9] FEC送信コンテンツを識別するための標準的なメッセージフォーマットを提供します。 FECを使用してNORMプロトコルのインスタンスは、その文書のガイドラインに従ってください。
Additionally, flags to determine the usage of the content identifier fields (e.g., stream vs. object) may be applicable. Flags may also serve other purposes in data content identification. It is expected that any flags defined will be dependent upon individual protocol instantiations.
また、コンテンツ識別子フィールド（オブジェクト対例えば、ストリーム）の使用を決定するためのフラグを適用することができます。フラグは、データコンテンツ識別における他の目的を果たすことができます。定義された任意のフラグは、個々のプロトコルのインスタンスに依存することが期待されます。
In summary, the following data content identification fields may be required for NORM protocol data content messages:
要約すると、次のデータコンテンツ識別フィールドはNORMプロトコル・データ・コンテンツ・メッセージのために必要とされてもよいです。
1) Source node identifier (<sourceId>)
1）ソースノード識別子（<ソースID>）
2) Object/Stream identifier (<objectId>), if applicable.
2）オブジェクト/ストリーム識別子（<OBJECTID>）、該当する場合。
3) FEC Block identifier (<sourceBlockNumber>), if applicable.
3）FECブロック識別子（<sourceBlockNumber>）、該当する場合。
4) FEC Symbol identifier (<encodingSymbolId>)
4）FECシンボル識別子（<encodingSymbolId>）
5) Flags to differentiate interpretation of identifier fields or identifier structure that implicitly indicates usage.
5）フラグ識別子フィールドまたは暗黙的に使用を示す識別子構造の解釈を区別します。
6) Additional FEC transmission content fields per FEC Building Block
FECビルディングブロックあたり6）追加のFEC送信コンテンツ分野
These fields have been identified because any generated NACK messages will use these identifiers in requesting repair or retransmission of data. NORM protocols that use these data content fields should also be compatible with support for intermediate system assistance to reliable multicast transport operation when available.
任意の生成されたNACKメッセージは、データの修理や再送信を要求する際にこれらの識別子を使用しますので、これらのフィールドは確認されています。これらのデータ内容フィールドを使用NORMプロトコルはまた、信頼性の高いマルチキャスト搬送動作可能な場合に、中間システムの支援のためのサポートと互換性があるべきです。
Multiple forward error correction (FEC) approaches have been identified that can provide great performance enhancements to the repair process of NACK-oriented and other reliable multicast protocols [11], [12], [13]. NORM protocols can reap additional benefits since FEC-based repair does not _generally_ require explicit knowledge of repair content within the bounds of its coding block size (in symbols). In NORM, parity repair packets generated will generally be transmitted only in response to NACK repair requests from receiving nodes. However, there are benefits in some network environments for transmitting some predetermined quantity of FEC repair packets multiplexed with the regular data symbol transmissions [14]. This can reduce the amount of NACK traffic generated with relatively little overhead cost when group sizes are very large or the network connectivity has a large delay*bandwidth product with some nominal level of expected packet loss. While the application of FEC is not unique to NORM, these sorts of requirements may dictate the types of algorithms and protocol approaches that are applicable.
複数の順方向誤り訂正（FEC）手法はNACK指向および他の信頼できるマルチキャストプロトコルの修復プロセスに大きな性能向上を提供することができることが確認されている[11]、[12]、[13]。 NORMプロトコルは、（記号で）そのコードブロックの大きさの範囲内で修理内容の明示的な知識を必要と_generally_ないFECベースの修復ので付加的な利点を享受することができます。 NORMでは、生成されたパリティリペアパケットは、一般的にのみ受信ノードからNACK修復要求に応答して送信されます。しかし、通常のデータシンボルの伝送と多重化FECリペアパケットの一部の所定量を送信するためのいくつかのネットワーク環境での利点が[14]があります。これは、グループのサイズが非常に大きいか、ネットワーク接続が予想されるパケット損失のいくつかの公称レベルで大きな遅延*帯域幅積を有する比較的少ないオーバーヘッドコストで生成されたNACKトラフィックの量を減らすことができます。 FECのアプリケーションはNORMに固有のものではないが、要件のこれらの種類は、アルゴリズムと適用可能なプロトコルのアプローチの種類を指示することができます。
A specific issue related to the use of FEC with NORM is the mechanism used to identify the portion(s) of transmitted data content to which specific FEC packets are applicable. It is expected that FEC algorithms will be based on generating a set of parity repair packets for a corresponding block of transmitted data packets. Since data content packets are uniquely identified by the concatenation of <sourceId::objectId::sourceBlockNumber::encodingSymbolId> during transport, it is expected that FEC packets will be identified in a similar manner. The FEC Building Block document [9] provides detailed recommendations concerning application of FEC and standard formats for related reliable multicast protocol messages.
NORMとFECの使用に関連する特定の問題は、特定のFECパケットが適用された送信データコンテンツの部分（単数または複数）を識別するために使用されるメカニズムです。 FECアルゴリズムは、送信されるデータパケットの対応するブロックに対するパリティ修復パケットのセットを生成するに基づくであろうことが予想されます。データコンテンツパケットを一意に輸送中に<ソースID :: OBJECTID :: sourceBlockNumber :: encodingSymbolId>の連結によって識別されるので、FECパケットは同様の方法で識別されることが期待されます。 FECビルディングブロック文献[9]に関連する信頼性の高いマルチキャストプロトコルメッセージのFEC及び標準フォーマットの適用に関する詳細な勧告を提供します。
The measurement of packet propagation round-trip time (RTT) among members of the group is required to support timer-based NACK suppression algorithms, timing of sender commands or certain repair functions, and congestion control operation. The nature of the round-trip information collected is dependent upon the type of interaction among the members of the group. In the case where only "one-to-many" transmission is required, it may be that only the sender require RTT knowledge of the greatest RTT (GRTT) among the receiver set and/or RTT knowledge of only a portion of the group. Here, the GRTT information might be collected in a reasonably scalable manner. For congestion control operation, it is possible that RTT information may be required by each receiver in the group. In this case, an alternative RTT collection scheme may be utilized where receivers collect individual RTT measurements with respect to the sender and advertise them to the group or sender. Where it is likely that exchange of reliable multicast data will occur among the group on a "many-to-many" basis, there are alternative measurement techniques that might be employed for increased efficiency [15]. And in some cases, there might be absolute time synchronization among hosts that may simplify RTT measurement. There are trade-offs in multicast congestion control design that require further consideration before a universal recommendation on RTT (or GRTT) measurement can be specified. Regardless of how the RTT information is collected (and more specifically GRTT) with respect to congestion control or other requirements, the sender will need to advertise its current GRTT estimate to the group for various timeouts used by receivers.
グループのメンバー間のパケットの伝搬往復時間（RTT）の測定は、タイマベースNACK抑制アルゴリズム、送信コマンド又は特定の修復機能、輻輳制御動作のタイミングをサポートするために必要とされます。収集往復情報の性質は、グループのメンバー間の相互作用の種類に依存しています。唯一の「1対多」の送信が要求される場合には、それだけで、送信者が受信機のセットおよび/またはグループの一部のみのRTTの知識のうち最大RTT（GRTT）のRTTの知識を必要とすることであってもよいです。ここでは、GRTT情報は、合理的にスケーラブルな方法で収集される可能性があります。輻輳制御動作のためには、RTT情報がグループ内の各受信機によって必要とされる可能性があります。受信機は、送信者に対して個々のRTT測定値を収集し、グループまたは送信者にそれらを広告する場合この場合には、別のRTT収集方式が利用されてもよいです。それが信頼性の高いマルチキャスト・データの交換は、「多対多」に基づいてグループ間で発生する可能性がある場合、増加した効率[15]のために使用されるかもしれない別の測定技術があります。そして、いくつかのケースでは、RTT測定を簡素化することがホスト間で絶対的な時刻同期があるかもしれません。測定を指定することができRTT（またはGRTT）のユニバーサル勧告前に、さらなる検討が必要なマルチキャスト輻輳制御設計のトレードオフがあります。かかわらず、RTT情報が収集される方法の（より具体的にGRTT）輻輳制御、または他の要件に関して、送信側は受信機によって使用される様々なタイムアウトのグループに現在のGRTT推定値をアドバタイズする必要があります。
The goal of this form of RTT measurement is for the sender to learn the GRTT among the receivers who are actively participating in NORM operation. The set of receivers participating in this process may be the entire group or some subset of the group determined from another mechanism within the protocol instantiation. An approach to collect this GRTT information follows.
送信者が積極的にNORM作業に参加している受信機の間でGRTTを学習するためのRTT測定のこの形式の目標です。このプロセスに参加する受信機のセットは、グループ全体またはプロトコルのインスタンス内の別の機構から決定基のサブセットであってもよいです。このGRTT情報を収集するためのアプローチは、以下の通りです。
The sender periodically polls the group with a message (independent or "piggy-backed" with other transmissions) containing a <sendTime> timestamp relative to an internal clock at the sender. Upon reception of this message, the receivers will record this <sendTime> timestamp and the time (referenced to their own clocks) at which it was received <recvTime>. When the receiver provides feedback to the sender (either explicitly or as part of other feedback messages depending upon protocol instantiation specification), it will construct a "response" using the formula:
メッセージを送信者が定期的にポーリング基（独立または「ピギーバック」他の送信で）送信者の内部クロックに<SENDTIME>タイムスタンプの相対を含みます。このメッセージを受信すると、受信機は、この<SENDTIME>タイムスタンプと、それは<recvTime>を受信した時（自分のクロックを基準に）時間を記録します。受信機は、（明示的に、またはプロトコルのインスタンスの仕様に応じて他のフィードバック・メッセージの一部として）送信者にフィードバックを提供する場合、それは、式を使用して、「応答」を構築します。
grttResponse = sendTime + (currentTime - recvTime)
getResponseは=送信時間+（現在の時間 - のrecv時間）
where the <sendTime> is the timestamp from the last probe message received from the source and the (<currentTime> - <recvTime>) is the amount of time differential since that request was received until the receiver generated the response.
<SENDTIME>ソースから受信した最後のプローブ・メッセージからのタイムスタンプがある場合（<CURRENTTIME> - <recvTime>）受信機が応答を生成するまで、その要求を受信してから時間差の量です。
The sender processes each receiver response by calculating a current RTT measurement for the receiver from whom the response was received using the following formula:
各受信応答応答は以下の式を使用して受信された人から受信するための現在のRTT測定値を計算することによって、送信者のプロセス。
RTT_rcvr = currentTime - grttResponse
RTT_rcvr = CURRENTTIME - grttResponse
During the each periodic GRTT probing interval, the source keeps the peak round trip timing measurement (RTT_peak) from the set of responses it has received. A conservative estimate of GRTT is kept to maximize the efficiency of redundant NACK suppression and repair aggregation. The update to the source's ongoing estimate of GRTT is done observing the following rules:
各周期GRTTプロービング間隔の間に、ソースは、受信した応答の集合からピーク往復タイミング測定（RTT_peak）を維持します。 GRTTの控えめな推定値は、冗長NACK抑制及び修復凝集の効率を最大化するために維持されます。 GRTTのソースの継続的な推定値に更新は以下のルールを観察して行われます。
1) If a receiver's response round trip time (RTT_rcvr) is greater than the current GRTT estimate, the GRTT is immediately updated to this new peak value:
1）受信機の応答往復時間（RTT_rcvr）は、現在のGRTT推定値よりも大きい場合、GRTTはすぐにこの新しいピーク値に更新されます。
GRTT = RTT_rcvr
GRTT = RTT_rcvr
2) At the end of the response collection period (i.e., the GRTT probe interval), if the recorded "peak" response RTT_peak) is less than the current GRTT estimate, the GRTT is updated to:
記録された「ピーク」応答RTT_peak）は現在のGRTT推定値未満である場合2）応答収集期間（すなわち、GRTTプローブ間隔）の終了時に、GRTTのように更新されます。
GRTT = MAX(0.9*GRTT, RTT_peak)
GRTT = MAX（0.9 * GRTT、RTT_peak）
3) If no feedback is received, the sender GRTT estimate remains unchanged.
何のフィードバックが受信されない場合3）、送信者GRTT推定値は変わりません。
4) At the end of the response collection period, the peak tracking value (RTT_peak) is reset to ZERO for subsequent peak detection.
4）応答収集期間の終わりに、ピークトラッキング値（RTT_peak）は、その後のピーク検出のためにゼロにリセットされます。
The GRTT collection period (i.e., period of probe transmission) could be fixed at a value on the order of that expected for group membership and/or network topology dynamics. For robustness, more rapid probing could be used at protocol startup before settling to a less frequent, steady-state interval. Optionally, an algorithm may be developed to adjust the GRTT collection period dynamically in response to the current GRTT estimate (or variations in it) and to an estimation of packet loss. The overhead of probing messages could then be reduced when the GRTT estimate is stable and unchanging, but be adjusted to track more dynamically during periods of variation with correspondingly shorter GRTT collection periods. GRTT collection may also be coupled with collection of other information for congestion control purposes.
GRTT収集期間（すなわち、プローブ伝送の期間）は、グループメンバーシップ及び/又はネットワークトポロジダイナミクスのために予想される程度の値に固定することができます。堅牢性のために、より迅速なプロービングはそれほど頻繁に、定常状態の間隔にセトリングする前に、プロトコルの起動時に使用することができます。必要に応じて、アルゴリズムは、現在のGRTT推定値に応じて動的にGRTT収集期間を調整するために開発された（またはバラツキ）およびパケット損失の推定にしてもよいです。 GRTT推定値が安定して不変であるが、それに対応短くGRTT収集期間と変動の期間中に、より動的に追跡するように調整されたときに、プロービングメッセージのオーバーヘッドは、その後減少させることができます。 GRTTコレクションはまた、輻輳制御の目的のために、他の情報の収集と結合することができます。
In summary, although NORM repair cycle timeouts are based on GRTT, it should be noted that convergent operation of the protocol does not _strictly_ depend on highly accurate GRTT estimation. The current mechanism has proved sufficient in simulations and in the environments where NORM-like protocols have been deployed to date. The estimate provided by the algorithm tracks the peak envelope of actual GRTT (including operating system effect as well as network delays) even in relatively high loss connectivity. The steady-state probing/update interval may potentially be varied to accommodate different levels of expected network dynamics in different environments.
NORM修理サイクルタイムアウトがGRTTに基づいているが要するに、プロトコルの収束動作を高精度GRTT推定に依存_strictly_ないことに留意すべきです。現在のメカニズムは、シミュレーション中とNORM-などのプロトコルは、これまでに展開されている環境では十分であることが判明しています。アルゴリズムによって提供される推定値は、比較的高損失の接続に（オペレーティングシステム効果ならびにネットワーク遅延を含む）実際のGRTTのピークエンベロープを追跡します。定常プローブ/更新間隔は、潜在的に異なる環境で予想されるネットワークのダイナミクスの異なるレベルに適応するように変化させることができます。
In this approach, receivers send messages with timestamps to the sender. To control the volume of these receiver-generated messages, a suppression mechanism similar to that described for NACK suppression my be used. The "age" of receivers' RTT measurement should be kept by receivers and used as a metric in competing for feedback opportunities in the suppression scheme. For example, receiver who have not made any RTT measurement or whose RTT measurement has aged most should have precedence over other receivers. In turn the sender may have limited capacity to provide an "echo" of the receiver timestamps back to the group, and it could use this RTT "age" metric to determine which receivers get precedence. The sender can determine the GRTT as described in 3.7.1 if it provides sender timestamps to the group. Alternatively, receivers who note their RTT is greater than the sender GRTT can compete in the feedback opportunity/suppression scheme to provide the sender and group with this information.
このアプローチでは、受信機は、送信者へのタイムスタンプとメッセージを送信します。これらの受信機で生成されたメッセージの量を制御するために、NACKの抑制のために記載したものと同様の抑制機構を使用することが私。レシーバのRTT計測の「年齢」は受信機によって保持され、抑圧方式でフィードバックの機会のために競合にメトリックとして使用されるべきです。例えば、RTT測定他の受信機よりも優先されなければならない最も老化した任意のRTT測定またはを行っていない受信機。ターンでは、送信者は、受信機が戻っグループにタイムスタンプの「エコー」を提供するために限られた能力を有していてもよく、それは受信機が優先され得るかを決定するために、このRTT「年齢」メトリック使用することができます。 3.7.1で説明したように、グループに送信者のタイムスタンプを提供する場合、送信者は、GRTTを決定することができます。また、彼らのRTTは、送信者GRTTよりも大きい場合に注意受信機は、この情報と送信者とグループを提供するために、フィードバック機会/抑制方式で競うことができます。
For reliable multicast sessions that involve multiple senders, it may be useful to have RTT measurements occur on a true "many-to-many" basis rather than have each sender independently tracking RTT. Some protocol efficiency can be gained when receivers can infer an approximation of their RTT with respect to a sender based on RTT information they have on another sender and that other sender's RTT with respect to the new sender of interest. For example, for receiver "a" and sender's "b" and "c", it is likely that:
複数の送信者を伴う信頼性の高いマルチキャストセッションの場合、RTTの測定値は真の「多対多」的に発生していなく、独立してRTTを追跡し、各送信者を持つことが有用である可能性があります。受信機は、彼らが興味の新しい送信者に関しては、別の送信者とそのほかの送信者のRTTに持ってRTT情報に基づいて、送信者に対する彼らのRTTの近似値を推測することができたときに、いくつかのプロトコル効率を得ることができます。例えば、受信機「」と送信者の「b」と「c」のために、それはその可能性があります：
RTT(a<->b) <= RTT(a<->c)) + RTT(b<->c)
RTT（< - > B）<= RTT（< - > C））+ RTT（B < - > C）
Further refinement of this estimate can be conducted if RTT information is available to a node concerning its own RTT to a small subset of other group members and RTT information among those other group members it learns during protocol operation.
RTT情報は、それがプロトコルの動作中に学習したもの、他のグループメンバーのうち、他のグループメンバーとRTT情報の小さなサブセットに独自のRTTに関するノードに利用可能である場合、この推定値の更なる改良を行うことができます。
To facilitate deterministic NORM protocol operation, the sender should robustly advertise its current estimation of GRTT to the receiver set. Common, robust knowledge of the sender's current operating GRTT estimate among the group will allow the protocol to progress in its most efficient manner. The sender's GRTT estimate can be robustly advertised to the group by simply embedding the estimate into all pertinent messages transmitted by the sender. The overhead of this can be made quite small by quantizing (compressing) the GRTT estimate to a single byte of information. The following C-language functions allows this to be done over a wide range (RTT_MIN through RTT_MAX) of GRTT values while maintaining a greater range of precision for small GRTT values and less precision for large values. Values of 1.0e-06 seconds and 1000 seconds are RECOMMENDED for RTT_MIN and RTT_MAX respectively. NORM applications may wish to place an additional, smaller upper limit on the GRTT advertised by senders to meet application data delivery latency constraints at the expense of greater feedback volume in some network environments.
決定論NORMプロトコルの動作を容易にするために、送信者が確実に受信機セットにGRTTの現在の推定を宣伝する必要があります。グループの中で、送信者の現在の動作GRTT推定値の一般的な、強力な知識は、プロトコルがその最も効率的な方法で進行することができます。送信者のGRTT推定値は確実に簡単に送信者によって送信されたすべての関連メッセージに見積もりを埋め込むことにより、グループにアドバタイズすることができます。このオーバーヘッドは、情報の単一バイトにGRTT推定値を量子化（圧縮）することによって、非常に小さくすることができます。以下のC言語の関数の小さなGRTT値と大きな値にはあまり精度のために精度のより大きな範囲を維持しながら、これはGRTT値の広い範囲（RTT_MAXスルーRTT_MIN）を介して行われることを可能にします。 1.0E-06秒、1000秒の値は、それぞれRTT_MINとRTT_MAXのために推奨されています。 NORMアプリケーションは、いくつかのネットワーク環境においてより大きなフィードバック音量を犠牲にして、アプリケーションデータ配信レイテンシ制約を満たすために、送信者によってアドバタイズGRTTの追加、より小さい上限を配置することを望むかもしれません。
unsigned char QuantizeGrtt(double grtt)
{
if (grtt > RTT_MAX)
grtt = RTT_MAX;
else if (grtt < RTT_MIN)
grtt = RTT_MIN;
if (grtt < (33*RTT_MIN))
return ((unsigned char)(grtt / RTT_MIN) - 1);
else
return ((unsigned char)(ceil(255.0-
(13.0 * log(RTT_MAX/grtt)))));
}
double UnquantizeRtt(unsigned char qrtt) { return ((qrtt <= 31) ? (((double)(qrtt+1))*(double)RTT_MIN) : (RTT_MAX/exp(((double)(255-qrtt))/(double)13.0))); }
二重UnquantizeRtt（unsigned char型のqrtt）{リターン（（qrtt <= 31）（（（ダブル）（qrtt + 1））*（ダブル）RTT_MIN）：（RTT_MAX / EXP（（（ダブル）（255-qrtt）） /(double)13.0）））。 }
Note that this function is useful for quantizing GRTT times in the range of 1 microsecond to 1000 seconds. Of course, NORM protocol implementations may wish to further constrain advertised GRTT estimates (e.g., limit the maximum value) for practical reasons.
この機能は、1000秒に1マイクロ秒の範囲でGRTT時間を量子化するために有用であることに注意してください。もちろん、NORMプロトコル実装は、さらに実用的な理由のためにアドバタイズGRTT推定値（例えば、最大値を制限する）拘束することを望むかもしれません。
When NORM protocol operation includes mechanisms that excite feedback from the group at large (e.g., congestion control), it may be possible to roughly estimate the group size based on the number of feedback messages received with respect to the distribution of the probabilistic suppression mechanism used. Note the timer-based suppression mechanism described in this document does not require a very accurate estimate of group size to perform adequately. Thus, a rough estimate, particularly if conservatively managed, may suffice. Group size may also be determined administratively. In absence of a group size determination mechanism a default group size value of 10,000 is RECOMMENDED for reasonable management of feedback given the scalability of expected NORM usage.
NORMプロトコルの動作が大きい（例えば、輻輳制御）でグループからのフィードバックを励起する機構を含む場合、概ね使用確率抑制機構の分布に関して、受信されたフィードバック・メッセージの数に基づいて、グループサイズを推定することも可能です。この文書で説明するタイマーベースの抑制機構が適切に実行するためにグループサイズの非常に正確な推定値を必要としません。このように、概算では、保守的に管理する場合は特に、十分です。グループのサイズも管理上決定することができます。グループサイズ決意機構の非存在下で10,000デフォルト・グループ・サイズ値は、期待されるNORMの使用のスケーラビリティ所定のフィードバックの合理的な管理のために推奨されます。
Congestion control that fairly shares available network capacity with other reliable multicast and TCP instantiations is REQUIRED for general Internet operation. The TCP-Friendly Multicast Congestion Control (TFMCC) [16] or Pragmatic General Multicast Congestion Control (PGMCC) techniques [17] may be applied to NORM operation to meet this requirement.
かなり株式は、他の信頼性の高いマルチキャストおよびTCPインスタンスで使用可能なネットワーク容量は、一般的なインターネットの操作に必要な輻輳制御。 TCPフレンドリーマルチキャスト輻輳制御（TFMCC）[16]又は実用一般マルチキャスト輻輳制御（PGMCC）技術[17]は、この要件を満たすために、NORM演算に適用されてもよいです。
NACK-oriented protocols may benefit from general purpose router assistance. In particular, additional NACK suppression where routers or intermediate systems can aggregate NACK content (or filter duplicate NACK content) from receivers as it is relayed toward the sender could enhance NORM group size scalability. For NORM protocols using FEC, it is possible that intermediate systems may be able to filter FEC repair messages to provide an intelligent "subcast" of repair content to different legs of the multicast topology depending on the repair needs learned from previous receiver NACKs. Both of these types of assist functions would require router interpretation of transport data unit content identifiers and flags.
NACK指向のプロトコルは、汎用ルータ支援から利益を得ることができます。特に、ルータ又は中間システムがNACKコンテンツを集約（またはフィルタNACKコンテンツを複製する）ことができ、付加的なNACK抑制受信機からそれが送信元に向けて中継されるようにするNORMグループサイズのスケーラビリティを高めることができます。 NORMプロトコルはFECを使用するためには、中間システムは、以前の受信機のNACKから学習修理の必要性に応じマルチキャストトポロジーの異なる脚に修復コンテンツのインテリジェント「subcast」を提供するFECリペアメッセージをフィルタリングすることができる可能性があります。支援機能のこれらのタイプの両方がトランスポートデータユニットのコンテンツ識別子とフラグのルータの解釈を必要とします。
The NORM building block applies to protocols wishing to employ negative acknowledgement to achieve reliable data transfer. Properly designed negative-acknowledgement (NACK)-oriented reliable multicast (NORM) protocols offer scalability advantages for applications and/or network topologies where, for various reasons, it is prohibitive to construct a higher order delivery infrastructure above the basic Layer 3 IP multicast service (e.g., unicast or hybrid unicast/multicast data distribution trees). Additionally, the scalability property of NACK-oriented protocols [18], [19] is applicable where broad "fan-out" is expected for a single network hop (e.g., cable-TV data delivery, satellite, or other broadcast communication services). Furthermore, the simplicity of a protocol based on "flat" group-wide multicast distribution may offer advantages for a broad range of distributed services or dynamic networks and applications. NORM protocols can make use of reciprocal (among senders and receivers) multicast communication under the Any-Source Multicast (ASM) model defined in RFC 1112 [2], and are capable of scalable operation in asymmetric topologies such as Single-Source Multicast (SSM) [8] where there may only be unicast routing service from the receivers to the sender(s).
NORMのビルディングブロックは、信頼性の高いデータ転送を実現するために否定応答を採用したいプロトコルに適用されます。適切に設計された否定応答（NACK）が（NORM）プロトコルは基本レイヤ3のIPマルチキャストサービスの上記上位配信インフラストラクチャを構築する様々な理由のために、それは法外であり、アプリケーションおよび/またはネットワークトポロジの拡張性の利点を提供する信頼性の高いマルチキャストを配向しました（例えば、ユニキャストまたはハイブリッドユニキャスト/マルチキャストデータ配信ツリー）。また、NACK指向のプロトコルのスケーラビリティ性[18]、[19]の広い「ファンアウト」が単一のネットワーク・ホップのために期待されている場合にも適用可能である（例えば、ケーブルTVデータ配信、衛星、または他の同報通信サービス） 。また、「フラット」グループ全体のマルチキャスト配信に基づくプロトコルの単純さは、分散サービスまたは動的ネットワークとアプリケーションの広い範囲のための利点を提供することができます。 NORMプロトコルは、RFC 1112で定義された、ソースマルチキャスト（ASM）モデル[2]の（送信者と受信者の間で）相互マルチキャスト通信を利用して、そのような単一ソースマルチキャスト（SSM非対称トポロジでスケーラブルな操作が可能であることができます）[8]ここでのみ受信機から送信者（複数可）にユニキャストルーティングサービスが存在してもよいです。
NORM operation is compatible with transport layer forward error correction coding techniques as described in [13] and congestion control mechanisms such as those described in [16] and [17]. A principal limitation of NORM operation involves group size scalability when network capacity for receiver feedback is very limited. NORM operation is also governed by implementation buffering constraints. Buffering greater than that required for typical point-to-point reliable transport (e.g., TCP) is recommended to allow for disparity in the receiver group connectivity and to allow for the feedback delays required to attain group size scalability.
NORM操作は、トランスポート層の順方向誤り訂正が[13]に記載のような技術をコーディングし、このような[16]及び[17]に記載されているような輻輳制御機構と互換性があります。受信機のフィードバックのためのネットワーク容量が非常に限られている場合NORM動作の主な制限は、グループサイズのスケーラビリティを伴います。 NORM動作も実装バッファリング制約によって支配されています。典型的なポイントツーポイント信頼性トランスポート（例えば、TCP）のために必要なものよりも大きいバッファが受信機グループ接続性の格差を可能にするために、グループサイズのスケーラビリティを達成するために必要なフィードバック遅延を可能にすることが推奨されます。
NORM protocols are expected to be subject to the same sort of security vulnerabilities as other IP and IP multicast protocols. NORM is compatible with IP security (IPsec) authentication mechanisms [20] that are RECOMMENDED for protection against session intrusion and denial of service attacks. A particular threat for NACK based protocols is that of NACK replay attacks that would prevent a NORM sender from making forward progress in transmission. Any standard IPsec mechanisms that can provide protection against such replay attacks are RECOMMENDED for use. Additionally, NORM protocol instantiations SHOULD consider providing support for their own NACK replay attack protection when network layer mechanisms are not available. The IETF Multicast Security (msec) Working Group is also developing solutions which may be applicable to NORM in the future.
NORMプロトコルは、他のIPとIPマルチキャストプロトコルなどのセキュリティ上の脆弱性と同じ種類の対象となることが期待されています。 NORMは、セッション侵入やサービス拒否攻撃に対する保護のために推奨されているIPセキュリティ（IPsec）の認証メカニズム[20]と互換性があります。 NACKベースのプロトコルのための特定の脅威は、順方向伝送における進歩を遂げてからNORMの送信者を妨げるNACKのリプレイ攻撃のことです。このようリプレイ攻撃に対する保護を提供することができる任意の標準のIPsecメカニズムを使用することをお勧めします。また、NORMプロトコルのインスタンスは、ネットワーク層メカニズムが利用できない場合、独自のNACKリプレイ攻撃からの保護のためのサポートを提供することを検討すべきです。 IETFマルチキャストセキュリティ（ミリ秒）ワーキンググループはまた、将来的にはNORMにも適用することができるソリューションを開発しています。
The authors would like to thank Rick Jones, and Joerg Widmer for their valuable comments on this document. The authors would also like to thank the RMT working group chairs, Roger Kermode and Lorenzo Vicisano, for their support in development of this specification, and Sally Floyd for her early inputs into this document.
作者はこのドキュメントの彼らの貴重なコメントのためにリック・ジョーンズ、そしてイェルクウィドマーに感謝したいと思います。著者らはまた、この文書に彼女の初期の入力に対してRMTワーキンググループチェア、ロジャーKermodeとロレンツォVicisano、この仕様の開発で彼らのサポートのために、とサリーフロイドに感謝したいと思います。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[2]デアリング、S.、 "IPマルチキャスティングのためのホスト拡大"、STD 5、RFC 1112、1989年8月。
[3] Mankin, A., Romanow, A., Bradner, S., and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
[3]マンキン、A.、Romanow、A.、ブラドナー、S.、およびV.パクソン、 "信頼できるマルチキャストトランスポート及びアプリケーションプロトコルを評価するためのIETF基準"、RFC 2357、1998年6月。
[4] Clark, D. and D. Tennenhouse, "Architectural Considerations for a New Generation of Protocols". In Proc. ACM SIGCOMM, pages 201--208, September 1990.
[4]クラーク、D.とD. Tennenhouse、「プロトコルの新世代のための建築に関する注意事項」。 PROCで。 ACM SIGCOMM、ページ201--208、1990年9月。
[5] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents", RFC 3269, April 2002.
[5] Kermode、R.とL. Vicisano、RFC 3269、2002年4月 "信頼できるマルチキャストトランスポート（RMT）ビルディングブロックとプロトコルのインスタンス文書の作者のガイドライン"。
[6] Nonnenmacher, J. and E. Biersack, "Optimal Multicast Feedback," in IEEE Infocom, San Francisco, California, p. 964, March/April 1998.
[6] Nonnenmacher、J.及びE. Biersack、IEEEインフォコム、サンフランシスコ、カリフォルニア、Pにおける "最適マルチキャストフィードバック"。 964年3月/ 1998年4月。
[7] Macker, J. and R. Adamson, "Quantitative Prediction of Nack Oriented Reliable Multicast (NORM) Feedback", Proc. IEEE MILCOM 2002, October 2002.
[7] Macker、J.及びR.アダムソン、 "指向NACKを定量予測高信頼マルチキャスト（NORM）フィードバック"、PROC。 IEEE MILCOM 2002、2002年10月。
[8] Holbrook, H., "A Channel Model for Multicast", Ph.D. Dissertation, Stanford University, Department of Computer Science, Stanford, California, August 2001.
[8]ホルブルック、H.、「マルチキャスト用チャネルモデル」、博士論文、スタンフォード大学、コンピュータサイエンス学部、スタンフォード大学、カリフォルニア州、2001年8月。
[9] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "Forward Error Correction (FEC) Building Block", RFC 3452, December 2002.
[9]ルビー、M.、Vicisano、L.、Gemmell、J.、リゾー、L.、ハンドレー、M.、およびJ.クロウクロフト、 "前方誤り訂正（FEC）ビルディングブロック"、RFC 3452、2002年12月。
[10] Floyd, S., Jacobson, V., McCanne, S., Liu, C., and L. Zhang. "A Reliable Multicast Framework for Light-weight Sessions and Application Level Framing", Proc. ACM SIGCOMM, August 1995.
[10]フロイド、S.、ヤコブソン、V.、McCanne、S.、劉、C.、およびL.チャン。 「信頼性の高い軽量のセッションのためのマルチキャストフレームワークとアプリケーションレベルフレーミング」、PROC。 ACM SIGCOMM、1995年8月。
[11] Metzner, J., "An Improved Broadcast Retransmission Protocol", IEEE Transactions on Communications, Vol. Com-32, No.6, June 1984.
[11] Metzner、J.、 "改善ブロードキャスト再送プロトコル"、通信に関するIEEEトランザクション、巻。 COM-32、6号、1984年6月。
[12] Macker, J., "Reliable Multicast Transport and Integrated Erasure-based Forward Error Correction", Proc. IEEE MILCOM 97, October 1997.
[12] Macker、J.、「信頼できるマルチキャストトランスポートと統合消去ベースの順方向誤り訂正」、PROC。 IEEE MILCOM 97、1997年10月。
[13] 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.
[13]ルビー、M.、Vicisano、L.、Gemmell、J.、リゾー、L.、ハンドレー、M.、およびJ.クロウクロフト、 "信頼できるマルチキャストの前方誤り訂正（FEC）の使用"、RFC 3453 、2002年12月。
[14] Gossink, D. and J. Macker, "Reliable Multicast and Integrated Parity Retransmission with Channel Estimation", IEEE GLOBECOM 98'.
[14] Gossink、D.とJ. Macker、 "チャネル推定を用いた高信頼マルチキャストおよび統合されたパリティ再送信"、IEEEのGLOBECOM 98' 。
[15] Ozdemir, V., Muthukrishnan, S., and I. Rhee, "Scalable, Low-Overhead Network Delay Estimation", NCSU/AT&T White Paper, February 1999.
[15] Ozdemir、V.、Muthukrishnan、S.、およびI.李承晩、 "スケーラブル、低オーバーヘッドのネットワーク遅延の推定"、NCSU / AT＆Tホワイトペーパー、1999年2月。
[16] Widmer, J. and M. Handley, "Extending Equation-Based Congestion Control to Multicast Applications", Proc ACM SIGCOMM 2001, San Diego, August 2001.
[16]ウィドマー、J.とM.ハンドレー、PROCのACM SIGCOMM 2001、サンディエゴ、2001年8月 "マルチキャストアプリケーションに式ベースの輻輳制御を拡張"。
[17] Rizzo, L., "pgmcc: A TCP-Friendly Single-Rate Multicast Congestion Control Scheme", Proc ACM SIGCOMM 2000, Stockholm, August 2000.
[17] Rizzo氏、L.、 "pgmcc：TCPフレンドリーシングルレートマルチキャスト輻輳制御方式"、PROC ACMのSIGCOMM 2000、ストックホルム、2000年8月。
[18] Pingali, S., Towsley, D., and J. Kurose, "A Comparison of Sender-Initiated and Receiver-Initiated Reliable Multicast Protocols". In Proc. INFOCOM, San Francisco, CA, October 1993.
[18] Pingali、S.、Towsley、D.、およびJ.黒瀬、「送信者開始の比較及び受信器で開始高信頼マルチキャストプロトコル」。 PROCで。インフォコム、サンフランシスコ、CA、1993年10月。
[19] B.N. Levine, J.J. Garcia-Luna-Aceves, "A Comparison of Known Classes of Reliable Multicast Protocols", Proc. International Conference on Network Protocols (ICNP-96), Columbus, Ohio, Oct 29--Nov 1, 1996.
[19] B。N.レヴァイン、J.J.ガルシア - ルナ - ACEVES、PROC、「信頼できるマルチキャストプロトコルの既知のクラスの比較」。国際ネットワークプロトコル上の会議（ICNP-96）、コロンバス、オハイオ州、1996年10月29日から11月1日まで。
[20] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[20]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
Brian Adamson Naval Research Laboratory Washington, DC 20375
ブライアン・アダムソン海軍研究所ワシントンD.C. 20375
EMail: adamson@itd.nrl.navy.mil
メールアドレス：adamson@itd.nrl.navy.mil
Carsten Bormann Universitaet Bremen TZI Postfach 330440 D-28334 Bremen, Germany
カルステンボルマンUniversitaetブレーメンTZI POSTFACH 330440 D-28334ブレーメン、ドイツ
EMail: cabo@tzi.org
メールアドレス：cabo@tzi.org
Mark Handley Department of Computer Science University College London Gower Street London WC1E 6BT UK
コンピュータサイエンス大学ロンドンガウアーストリートロンドンWC1E 6BT英国のマーク・ハンドリー部門
EMail: M.Handley@cs.ucl.ac.uk
メールアドレス：M.Handley@cs.ucl.ac.uk
Joe Macker Naval Research Laboratory Washington, DC 20375
ジョーMacker海軍研究所ワシントンD.C. 20375
EMail: macker@itd.nrl.navy.mil
メールアドレス：macker@itd.nrl.navy.mil
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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 IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 IETF文書の権利に関するIETFの手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。