Network Working Group B. Adamson
Request for Comments: 5401 Naval Research Laboratory
Obsoletes: 3941 C. Bormann
Category: Standards Track Universitaet Bremen TZI
M. Handley
University College London
J. Macker
Naval Research Laboratory
November 2008
Multicast Negative-Acknowledgment (NACK) Building Blocks
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2008 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/ライセンス情報）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Abstract
抽象
This document discusses the creation of reliable multicast protocols that utilize negative-acknowledgment (NACK) feedback. The rationale for protocol design goals and assumptions are presented. Technical challenges for NACK-based (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 reliable multicast protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols. This document obsoletes RFC 3941.
この文書では、否定応答（NACK）フィードバックを利用信頼できるマルチキャストプロトコルの作成について説明します。プロトコルの設計目標および仮定の根拠が提示されています。 NACKベース（及び一般的ないくつかのケースで）信頼できるマルチキャストプロトコル操作のための技術的な課題が識別されます。これらの目標や課題は、信頼できるマルチキャストプロトコルの動作の異なる側面を扱う機能「ビルディング・ブロック」のセットに解決されます。これらのビルディングブロックは、信頼できるマルチキャストプロトコルの異なるインスタンスを生成するのに有用であろうことが予想されます。この文書はRFC 3941を廃止します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Requirements Language ......................................4
2. Rationale .......................................................4
2.1. Delivery Service Model .....................................5
2.2. Group Membership Dynamics ..................................6
2.3. Sender/Receiver Relationships ..............................6
2.4. Group Size Scalability .....................................6
2.5. Data Delivery Performance ..................................7
2.6. Network Environments .......................................7
2.7. Intermediate System Assistance .............................8
3. Functionality ...................................................8
3.1. Multicast Sender Transmission .............................11
3.2. NACK Repair Process .......................................13
3.3. Multicast Receiver Join Policies and Procedures ...........26
3.4. Node (Member) Identification ..............................26
3.5. Data Content Identification ...............................27
3.6. Forward Error Correction (FEC) ............................28
3.7. Round-Trip Timing Collection ..............................29
3.8. Group Size Determination/Estimation .......................33
3.9. Congestion Control Operation ..............................34
3.10. Intermediate System Assistance ...........................34
4. NACK-Based Reliable Multicast Applicability ....................35
5. Security Considerations ........................................36
6. Changes from RFC 3941 ..........................................38
7. Acknowledgements ...............................................38
8. References .....................................................39
8.1. Normative References ......................................39
8.2. Informative References ....................................39
Reliable multicast transport is a desirable technology for 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 (see [RFC2357]). This document addresses the creation of reliable multicast protocols that utilize negative-acknowledgment (NACK) feedback. NACK-based protocols generally entail less frequent feedback messaging than reliability protocols based on positive acknowledgment (ACK). The less frequent feedback messaging helps simplify the problem of feedback implosion as group size grows larger. While different protocol instantiations may be required to meet specific application and network architecture demands [ArchConsiderations], there are a number of fundamental components that may be common to these different instantiations.
信頼性の高いマルチキャストトランスポートは、インターネット上のグループへのデータの効率的で信頼性の高い配信のための望ましい技術です。グループ通信パラダイムの複雑さが異なる可能性信頼性の高いマルチキャストアプリケーションとユーザのパフォーマンスとスケーラビリティ要件の範囲を満たすために、異なるプロトコルタイプとインスタンス化を必要とする（[RFC2357]を参照）。この文書では、否定応答（NACK）フィードバックを利用信頼できるマルチキャストプロトコルの作成に取り組んでいます。 NACKベースのプロトコルは、一般に、肯定応答（ACK）に基づいて、信頼性プロトコルより少ない頻度のフィードバックメッセージを伴います。それほど頻繁にフィードバックメッセージは、グループのサイズが大きくなるようなフィードバック内部破裂の問題を簡素化することができます。異なるプロトコルのインスタンス化は、特定のアプリケーションおよびネットワークアーキテクチャの要求[ArchConsiderations]を満たすために必要とされ得るが、これらの異なるインスタンスに共通とすることができる基本的な構成要素の数があります。
This document describes the framework and common "building block" components relevant to multicast protocols that are based primarily on NACK operation for reliable transport. While this document discusses a large set of reliable multicast components and issues relevant to NACK-based reliable multicast protocol design, it specifically addresses in detail the following building blocks, which are not addressed in other IETF documents:
この文書では、フレームワーク、主に信頼性の高い輸送用NACK操作に基づいているマルチキャストプロトコルに関連する一般的な「ビルディングブロック」コンポーネントについて説明します。このドキュメントは、NACKベースの高信頼マルチキャストプロトコルの設計に関連する信頼性の高いマルチキャストコンポーネントとの問題の大規模なセットを説明しながら、それを具体的に詳細に他のIETF文書で対処されていない以下のビルディングブロックを、対処します。
NACK-based reliable multicast implementations SHOULD make use of Forward Error Correction (FEC) erasure coding techniques, as described in the FEC Building Block [RFC5052] document. Packet-level erasure coding allows missing packets from a given FEC block to be recovered using the parity packets instead of classical, individualized retransmission of original source data content. For this reason, this document refers to the protocol mechanisms for reliability as a "repair process." Note that NACK-based protocols can reactively provide the parity packets in response to receiver requests for repair rather than just proactively sending added FEC parity content as part of the original transmission. Hybrid proactive/reactive use of FEC content is also possible with the mechanisms described in this document. Some classes of FEC coding, such as Maximal Separable Distance (MDS) codes, allow senders to dynamically implement deterministic, highly efficient receiver group repair strategies as part of a NACK-based, selective automated repeat-request (ARQ) scheme.
FECビルディングブロック[RFC5052]の文書に記載されているようにNACKベースの高信頼マルチキャストの実装は、前方誤り訂正（FEC）消去符号化技術を利用するべきです。パケットレベルの消去符号化は、所与のFECブロックから欠落パケットではなく、元のソース・データ・コンテンツの古典的な、個別再送のパリティパケットを使用して回収されることを可能にします。この理由のため、この文書はとしての信頼性のためのプロトコルメカニズムを指し、「修復プロセス。」 NACKベースのプロトコルは、反応性だけ積極的に元の送信の一部として追加FECパリティコンテンツを送信するのではなく、修理のために受信機の要求に応じてパリティパケットを提供することができることに留意されたいです。 FECコンテンツのハイブリッド積極的/反応性の使用は、この文書で説明したメカニズムでも可能です。こうした最大分離可能距離（MDS）コードのようなFEC符号化のいくつかのクラスは、送信者が動的にNACKベース、選択的自動再送要求（ARQ）スキームの一部として、決定論的、高効率のレシーバグループ修復戦略を実行することができます。
The potential relationships to other reliable multicast transport building blocks (e.g., FEC, congestion control) and general issues with NACK-based reliable multicast protocols are also discussed. This document follows the guidelines provided in [RFC3269].
NACKに基づく信頼性の高いマルチキャストプロトコルと他の信頼できるマルチキャスト移送ビルディングブロック（例えば、FEC、輻輳制御）、および一般的な問題への潜在的な関係も議論されています。この文書では、[RFC3269]で提供されるガイドラインに従っています。
Statement of Intent
主旨書
This memo contains descriptions of building blocks that can be applied in the design of reliable multicast protocols utilizing negative-acknowledgement (NACK) feedback. [RFC3941] contains a previous description of this specification. RFC 3941 was published in the "Experimental" category. It was the stated intent of the Reliable Multicast Transport (RMT) working group at that time to resubmit this specification as an IETF Proposed Standard in due course.
このメモは否定応答（NACK）フィードバックを活用し、信頼性マルチキャストプロトコルの設計に適用することができビルディング・ブロックの記述が含まれています。 [RFC3941]は、本明細書の前の記述を含みます。 RFC 3941には、「実験」カテゴリに掲載されました。それはやがて標準提案IETFとしてこの仕様書を再提出し、その時点で信頼性の高いマルチキャストトランスポート（RMT）ワーキンググループの意図述べました。
This Proposed Standard specification is thus based on [RFC3941] and has been updated according to accumulated experience and growing protocol maturity since the publication of RFC 3941. Said experience applies both to this specification itself and to congestion control strategies related to the use of this specification.
この提案された標準仕様は、このように[RFC3941]に基づいており、RFC 3941.の出版経験は、本明細書自体に、本明細書の使用に関連する輻輳制御戦略の両方に適用される前記ので、蓄積された経験と成長プロトコル成熟度に応じて更新されています。
The differences between [RFC3941] and this document are listed in Section 6.
[RFC3941]と、この文書の違いはセクション6に記載されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
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:
ビルディングブロックを使用して、各潜在的なプロトコルのインスタンスは、ここに提示（および他の適用可能なビルディングブロックの文書に）個々のプロトコルの設計に影響を与える可能性がある特定の基準を持っています。該当ビルディング・ブロックの開発をサポートするために、識別して、一般的なプロトコルの設計目標と仮定を駆動要約すると便利です。これらは、各プロトコルのインスタンス化が詳細に対処する必要があります領域です。このドキュメントの各ビルディングブロックの説明は以下の設計基準の影響についての議論が含まれます。ここで考えて設計基準のカテゴリがあります。
All of these areas are at least briefly discussed. Additionally, other reliable multicast transport building block documents, such as [RFC5052], have been created to address areas outside of the scope of this document. NACK-based reliable multicast 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 NACK-based reliable multicast but may be used in concert with the other building block areas. In some cases, a building block may be able to 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. The forms of "bulk data transfer" covered here include reliable transport of bulky, fixed-length, a priori static content and also transmission of non-predetermined, perhaps streamed, content of indefinite length. Section 3.5 discusses these different forms of bulk data content in further detail.
これらの領域の全ては、少なくとも簡単に説明されています。さらに、このような[RFC5052]などの他の信頼性の高いマルチキャストトランスポートビルディングブロックの文書は、この文書の範囲外の領域に対処するために作成されています。 NACKベースの高信頼マルチキャストプロトコルのインスタンスは、これらの他のビルディング・ブロックと同様に、ここで提示したものに依存してもよいです。この文書では、NACKベースの高信頼マルチキャストに固有のものであるが、他のビルディングブロック領域と協調して使用することができる分野に焦点を当てています。他の場合には、異なるアプリケーションのニーズや動作環境を満たすために必要なトレードオフが存在するであろうしながらいくつかのケースでは、ビルディングブロックは、前提条件の広い範囲に対処することができるかもしれません。必要な場合には、ビルディングブロックの機能は、さまざまな要件を満たすために、パラメトリックなるように設計されています。もちろん、基本的な目標は、設計の複雑さを最小限にし、少なくとも一般的なインターネット環境での汎用「バルクデータ転送」の要件を満たす任意のこのようなパラメータのデフォルト値を推奨することになります。ここで覆われた「バルクデータ転送」の形態はかさばる、固定長、アプリオリ静的コンテンツとも不定長さの非一定、おそらくストリーミング、コンテンツの送信の信頼性の高いトランスポートを含みます。 3.5節では、さらに詳細に大量のデータコンテンツのこれらの異なる形式について説明します。
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. The most basic service model for reliable multicast transport is that of "bulk transfer", which is a primary focus of this and other related RMT working group documents. However, the same principles in protocol design may also be applied to other service 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.
信頼できるマルチキャストトランスポートプロトコルの暗黙の目標は、IPマルチキャストデータグラムサービスを使用して通信を行うメンバーのグループ間でデータの信頼できる配信です。ただし、アプリケーションが提供しようとしている特定のサービスは、設計上の決定に影響を与えることができます。信頼性の高いマルチキャスト輸送のための最も基本的なサービスモデルは、これと他の関連RMTワーキンググループ文書の主要な焦点である「バルク転送」、のことです。しかしながら、プロトコルの設計における同じ原理はまた、他のサービスモデルにホワイトボーディングやテキストチャットと同様に小さなメッセージの、例えば、よりインタラクティブな交流を印加することができます。これらの異なるモデルの中で再送信または修理のために（それを参照するか、状態）、このような送信者の送信したデータをキャッシュする機能などの問題があります。グループ内のメンバー間の順序及び/又は送信及び受信のシーケンスにおける因果関係の必要性は、データ内容に応じて異なっていてもよいです。グループ通信パラダイムは、その中のポイントツーポイントモデルとは大きく異なり、データコンテンツの種類に応じて、いくつかの受信機は、データコンテンツの部分の受信を完了し、他のメンバーがコンテンツを受信する前に、それに作用することができるかもしれません。これは、いくつかの用途のためにではなく、他の許容可能な（または望ましい）であってもよいです。これらの多様な要件は、異なるプロトコルのインスタンス化設計の数の必要性を駆動します。一般的に有用なビルディングブロック機構を開発する上で重要な課題は、特定のアプリケーションレベルの詳細を定義することなく、これらの機能も限られた範囲を収容しています。
Another factor impacting the delivery service model is the potential for different receivers in the multicast group to have significantly differing quality of network connectivity. This may involve receivers with very limited goodput due to connection rate or substantial packet loss. NACK-based protocol implementations may wish to provide policies by which extremely poor-performing receivers are excluded from the main group or migrated to a separate delivery group. Note that some application models may require that the entire group be constrained to the performance of the "weakest member" to satisfy operational requirements. In either case, protocol designs should consider this aspect of the reliable multicast delivery service model.
配信サービスモデルに影響を与えるもう一つの要因は、ネットワーク接続のかなり異なる品質を持っているために、マルチキャストグループ内の異なる受信機の可能性です。これは、接続レートまたはかなりのパケット損失に起因する非常に限られたグッドプットと受信機を含むことができます。 NACKベースのプロトコルの実装は非常に悪い行う受信機は、メイングループから除外され、または別の配信グループに移行されるポリシーを提供することを望むかもしれません。いくつかのアプリケーションモデルは、グループ全体の運用要件を満たすために「最弱部材」のパフォーマンスに制約されることを必要とするかもしれないことに注意してください。いずれの場合も、プロトコルの設計は、信頼性の高いマルチキャスト配信サービスモデルのこの側面を考慮する必要があります。
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.
グループのメンバー間の送信者と受信者の関係は考慮が必要です。いくつかの用途では、受信機のグループにマルチキャストする単一の送信者が存在してもよいです。他の場合には、そこに複数の送信者であってもよいし、データの送信側と受信側であるため、グループ内のすべての人の可能性が存在してもよいです。
Native IP multicast [RFC1112] 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-based protocol can be applied without the potential for the volume of NACK feedback messages to overwhelm network capacity. This is often referred to as "feedback implosion". Research suggests that NACK-based reliable multicast group sizes on the order of tens of thousands of receivers may operate with acceptable levels of feedback to the sender using probabilistic, timer-based suppression techniques [NormFeedback]. Instead of receivers immediately transmitting feedback messages when loss is detected, these techniques specify use of purposefully-scaled, random back-off timeouts such that some potential NACKing receivers can self-suppress their feedback upon hearing messages from other receivers that have selected shorter random timeout intervals. However, there may be additional NACK suppression heuristics that can be applied to enable these protocols to scale to even larger 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マルチキャスト[RFC1112]は、非常に大規模なグループのサイズにスケーリングすることができます。いくつかのアプリケーションが拡大するマルチキャストインフラの能力と一緒に拡張することが望ましい場合があります。その最も単純な形態では、NACKベースのプロトコルは、ネットワーク容量を圧倒するNACKフィードバックメッセージのボリュームの電位ことなく適用可能なグループサイズには限界があります。これは、しばしば「フィードバック爆縮」と呼ばれています。研究では、数十の受信機の数千のオーダーのNACKに基づく信頼性の高いマルチキャストグループサイズは[NormFeedback】確率、タイマーベースの抑圧技術を使用して送信側にフィードバックの許容レベルで動作することができることを示唆しています。代わりに、すぐに損失が検出されたときに、これらの技術は、意図的にスケーリングされ、ランダムバックオフタイムアウトの使用を指定フィードバックメッセージを送信し、受信機のいくつかの潜在的なNACKing受信機は短いランダムタイムアウトを選択している他の受信者からのメッセージを聞いて自分の意見を自己抑制することができるように間隔。しかし、より大きなグループサイズにスケーリングするために、これらのプロトコルを有効に適用することができる付加的なNACK抑制ヒューリスティックがあってもよいです。メンバーは、グループ内のすべての他のメンバー（特に、他の受信機）上で状態を維持するために大規模な場合には、それは法外であってもよいです。グループサイズの影響は、適用可能なビルディング・ブロックの開発に検討する必要があります。
Group size scalability may also be aided by intermediate system assistance; see section 2.7 below.
グループのサイズの拡張性は、中間システムの支援によって支援することができます。以下のセクション2.7を参照してください。
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 to allow the sender of data to identify appropriate content for efficient repair transmission. For example, back-off timeouts can be used to ensure efficient NACK suppression and repair transmission, but this comes at the 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 source-specific multicast (SSM) model from a specific source [RFC4607]. Receivers in the group may be
インターネットプロトコルは、歴史的に異種ネットワークトポロジ全体にサービスを提供する役割を引き受けました。信頼できるマルチキャストプロトコルが有効汎用IPサービスが適用されるネットワークの広い範囲にわたって動作することが可能であることが望ましいです。単一グループのメンバー間のリンク上で利用可能な帯域幅は、今日、他のフローからの競合の程度を変化させて、無線リンク及び複数ギガビット/秒の高速LAN接続のためのキロビット/秒の少数の間で変化してもよいです。最近、56K / ADSLモデム、CATVインターネットサービス、衛星、および他の無線通信サービスを含む非対称ネットワークサービスの数が増殖し始めています。これらの多くは、本質的にIPマルチキャストサービスは非常に適用可能な潜在的に大きな「ファンアウト」でメディアを放送しています。また、ポリシーおよび/または技術的な問題は、マルチキャスト接続が特定のソース[RFC4607]のソース固有マルチキャスト（SSM）モデルに限定されているトポロジをもたらし得ます。グループのレシーバであってもよいです
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.
NACKおよび他のメッセージのためのユニキャストのフィードバックに限定。対価は、基礎となるネットワークの性質上、ブロックの開発とプロトコルの設計を構築する際に、与えられなければなりません。
Intermediate assistance from devices/systems with direct knowledge of the underlying network topology may be used to increase the performance and scalability of NACK-based reliable multicast protocols. Feedback aggregation and filtering of sender repair data may be possible with NACK-based protocols using FEC-based repair strategies as described in the present and other reliable multicast transport building block documents. However, there will continue to be a number of instances where intermediate system assistance 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ベースの信頼できるマルチキャストプロトコルの性能とスケーラビリティを増加させるために使用されてもよいです。センダリペアデータのフィードバックの集約とフィルタリングが存在し、他の信頼できるマルチキャスト移送ビルディングブロックの文書に記載されているようにFECベースの修復戦略を用いて、NACKベースのプロトコルを用いて可能です。しかし、中間システムの支援が利用可能または実用的でないインスタンスの数があるように続けます。 NACK指向の信頼性の高いマルチキャストのための任意のビルディング・ブロック・コンポーネントは、補助なしで動作可能でなければなりません。しかし、そのようなプロトコルも利用できるとき、これらの機能を利用することを検討することを推奨されます。
The previous section has presented the role of protocol building blocks and some of the criteria that may affect NACK-based reliable multicast building block identification/design. This section describes different building block areas applicable to NACK-based reliable multicast protocols. Some of these areas are specific to NACK-based 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 general building block areas from the standpoint of NACK-based reliable multicast. Where applicable, other building block documents are referenced for possible contribution to NACK-based reliable multicast protocols.
前のセクションでは、プロトコルのビルディングブロックの役割とNACKベースの高信頼マルチキャストビルディングブロック識別/デザインに影響を与える可能性の基準のいくつかを提示しました。このセクションでは、NACKベースの高信頼マルチキャストプロトコルに適用可能な別のビルディングブロック領域について説明します。これらの領域の一部は、NACKベースのプロトコルに固有のものです。そのような地域の詳細な説明が提供されています。他の場合には、領域（例えば、ノード識別子、前方誤り訂正（FEC）など）が信頼できるマルチキャストの他の形態にも適用可能です。これらの場合、以下の議論は、NACKに基づく信頼性の高いマルチキャストの観点からこれらの一般的なビルディングブロック領域上に配置された要件を記述する。該当する場合には、他のビルディングブロックの文書は、NACKベースの高信頼マルチキャストプロトコルへの可能な貢献のために参照されています。
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 NACK- based reliable multicast building block "inputs" must be satisfied by the specific protocol instantiation or implementation (e.g., application data and control).
各ビルディングブロックについて、概念的な「インタフェースの説明は、」別の時に又は他のプロトコルパラメータに一つの建物ブロックコンポーネントの依存関係を説明するために提供されます。ビルディングブロック構成要素は、その機能を実行するために別のビルディングブロック成分または他のソースからの「入力」のいくつかのフォームを必要とするかもしれません。ビルディングブロック成分及び/又は提供された得られた「出力」によって必要な「入力」は、各ビルディングブロックコンポーネントのインタフェースの記述で定義され、説明されます。ここで紹介するビルディングブロックのセットは完全にお互いの「入力」と「出力」のニーズを満たしていないことに注意してください。いくつかのケースでは、ここでのビルディングブロックのための「入力」は、この文書（例えば、輻輳制御またはFEC）への外部の他のビルディングブロックから来なければなりません。他の場合NACK-基づいて信頼性の高いマルチキャストビルディングブロック「入力」で特定のプロトコルのインスタンスまたはインプリメンテーション（例えば、アプリケーションデータ及び制御）が満たさなければなりません。
The following building block components relevant to NACK-based reliable multicast are identified:
NACKベースの高信頼マルチキャストに関連する以下のビルディング・ブロック・コンポーネントが識別されます。
NORM (NACK-Oriented Reliable Multicast)-Specific
NORM（NACK指向信頼性マルチキャスト）特異的
General Purpose
一般的用途
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）に受信者の応答は、他のビルディング・ブロック・コンポーネントからのデータメッセージの内容および入力に依存するであろう。最後に、受信応答の送信者の処理はその伝送戦略にフィードバックします。
The components on the left side of this figure are areas that may be applicable beyond NACK-based reliable multicast. The more significant of these components are discussed in other building block documents, such as the FEC Building Block [RFC5052]. Brief
この図の左側のコンポーネントは、NACKベースの信頼できるマルチキャストを超えて適用することができる領域です。これらの成分のより重要には、このようなFECビルディングブロック[RFC5052]などの他のビルディングブロック文書に記載されています。ブリーフ
descriptions of these areas and their roles in NACK-based reliable multicast protocols are given below, and "RTT Collection" is discussed in detail in Section 3.7 of this document.
これらの領域とNACKベースの高信頼マルチキャストプロトコルにおけるその役割の説明は以下の通りである、と「RTTコレクション」このドキュメントのセクション3.7で詳しく説明されています。
The components on the right are seen as specific to NACK-based reliable multicast protocols, most notably the NACK repair process. These areas are discussed in detail below (most notably, "Multicast Sender Transmission" and "NACK Repair Process" in Sections 3.1 and 3.2). Some other components (e.g., "Security") impact many aspects of the protocol, and others may be more transparent to the core protocol processing. Where applicable, specific technical recommendations are made for mechanisms that will properly satisfy the goals of NACK-based reliable multicast transport for the Internet.
右側のコンポーネントは、最も顕著なのNACK修復プロセスNACKベースの高信頼マルチキャストプロトコルに固有と見られています。これらの領域は、（特に、「マルチキャスト送信者送信」とセクション3.1および3.2で「NACK修復プロセス」）以下に詳細に説明します。いくつかの他の成分（例えば、「セキュリティ」）プロトコルの多くの側面に影響を与え、そして他のものはコアプロトコル処理に対してより透明であってもよいです。該当する場合には、特定の技術的な勧告は、適切にインターネットのためのNACKベースの高信頼マルチキャスト伝送の目標を満足させる仕組みのために作られています。
Application Data and Control
|
v
.---------------------. .-----------------------.
| Node Identification |-------+-->| Sender Transmission |<---.
`---------------------' | `-----------------------' |
.---------------------. | | .------------------. |
| Data Identification |-------+ | | Rcvr Join Policy | |
`---------------------' | V `------------------' |
.---------------------. | .----------------------. |
.->| Congestion Control |-------+ | Receiver NACK | |
| `---------------------' | | Repair Process | |
| .---------------------. | | .------------------. | |
| | |-------' | | NACK Initiation | | |
| | FEC |-----. | `------------------' | |
| | |--. | | .------------------. | |
| `---------------------' | | | | NACK Content | | |
| .---------------------. | | | `------------------' | |
`--| RTT Collection |--|--+---->| .------------------. | |
| |--+ | | | NACK Suppression | | |
`---------------------' | | | `------------------' | |
.---------------------. | | `----------------------' |
| Group Size Est. |--|--' | .-----------------. |
| |--+ | | Intermediate | |
`---------------------' | | | System Assist | |
.---------------------. | v `-----------------' |
| Other | | .-------------------------. |
`---------------------' `------->| Sender NACK Processing |--'
| and Repair Response |
`-------------------------'
^ ^
| |
.-----------------------------.
| (Security) |
`-----------------------------'
Figure 1: NACK-Based Reliable Multicast Building Block Framework
図1：NACKベースのリライアブルマルチキャストビルディングブロックフレームワーク
Reliable multicast 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 the FEC Building Block [RFC5052]. When congestion control mechanisms are needed (REQUIRED for general Internet operation), the sender transmission rate SHALL be controlled by the congestion control mechanism. In any case, it is RECOMMENDED that all data transmissions from multicast 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.
信頼性の高いマルチキャスト送信者がマルチキャストセッションにデータ内容を送信します。データの内容は、アプリケーションに依存になります。送信者は速度で、アプリケーションおよび/またはネットワークアーキテクチャの要件によって決定されるメッセージサイズとデータコンテンツを送信します。送信者の送信のいずれかのFEC符号化は、FECビルディングブロック[RFC5052]のガイドラインに準拠している必要があり。輻輳制御メカニズムは（一般的なインターネット操作に必要）が必要とされている場合、送信元送信レートは、輻輳制御機構によって管理されなければなりません。いずれかの場合には、マルチキャスト送信者からのすべてのデータの送信がアプリケーションまたは輻輳制御アルゴリズムによって決定される限界を評価の対象であることが推奨されます。送信者の送信は（アプリケーションによっておよび/または輻輳制御により制限される場合があります）利用可能な容量の優れた利用を行う必要があります。その結果、オーバーラップ及び修理内容を持つ新しいデータコンテンツ伝送の多重化が存在するであろうと予想されます。アプリケーションの動作に関連する他の要因は、送信者の送信フォーマットと方法を決定してもよいです。例えば、いくつかの考慮事項は、それが送信するデータがないとき、断続的アイドル期間中に送信者の行動に与える必要があります。
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 NACK-based reliable multicast 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 NACK procedure. For efficiency, the sender should allow sufficient time between the redundant transmissions to receive any NACK responses from the receivers to this command.
データコンテンツに加えて、他の送信者のメッセージまたはコマンドは、プロトコル操作の一部として使用することができます。これらのメッセージは、アプリケーションデータ転送の範囲の外で起こり得ます。肯定応答が原因グループサイズのスケーラビリティの問題に法外である場合にNACKベースの高信頼マルチキャストプロトコルでは、そのようなプロトコル・メッセージの信頼性は、冗長送信によって試行されてもよいです。プロトコルの設計は、そのようなメッセージは、グループによって受信されない場合に対処するためのメカニズムを提供すべきであることに留意されたいです。一例として、コマンド・メッセージは、冗長送信を停止することが一時的に（または永続的）であることを示すために送信側によって送信されるかもしれません。受信機は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 NACK-based reliable multicast protocol timeouts should be dependent upon the group greatest round-trip timing (GRTT) estimate and any expected resultant NACK or other feedback operation. The sender GRTT is an estimate of the worst-case round-trip timing from a given 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 a given sender. NACK-based reliable multicast instantiations SHOULD be able to dynamically adapt to a wide range of multicast network topologies.
任意の得られたNACK又は他のフィードバック動作、グループ最大往復タイミング（GRTT）の推定値に依存しなければならない送信者と他のNACKベースの信頼できるマルチキャストプロトコルのタイムアウトによって発行された制御メッセージの冗長送信のタイミングが存在する場合、一般にそして任意の予想結果NACKまたはその他のフィードバック動作。送信者GRTTは、グループ内の任意の受信機に与えられた送信者から最悪のケースの往復タイミングの推定値です。 GRTT間隔が所与の送信者に対して、ネットワークトポロジ全体マルチキャストグループ（遅延に対して）最大スパンの控えめな見積もりであると仮定されます。 NACKベースの高信頼マルチキャストのインスタンスを動的にマルチキャストネットワークトポロジの広い範囲に適応することができるべきです。
Inputs:
入力：
Outputs:
出力：
1. Controlled transmission of messages with headers uniquely identifying data or repair content within the context of the reliable multicast session.
1.ヘッダが一意信頼できるマルチキャストセッションのコンテキスト内でデータまたは修復コンテンツを識別してメッセージの送信を制御しました。
2. Commands indicating sender's status or other transport control actions to be taken.
送信者の状況や他の搬送制御動作を示す2.コマンドを取られます。
A critical component of NACK-based reliable multicast protocols is the NACK repair process. This includes both 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 NACK repair process:
NACKベースの高信頼マルチキャストプロトコルの重要なコンポーネントは、NACK修復プロセスです。これは、修理の必要性を検出し、要求内の受信者の役割と、そのような要求への送信者の応答の両方を含んでいます。 NACKの修復プロセスの4つの主要な要素があります。
The 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 sender data content is marked to identify its FEC block number and that ordinal relationship is preserved in order of transmission.
NACKプロセス（サイクル）が確実に受信を達成するために、特定の送信者からの修理送信の必要性を検出する受信機によって開始されます。 FECが適用されるとき、受信機は、その修復要件は、データコンテンツの所定の符号化ブロックに対するFEC送信保留量を超えて知られているだけNACKプロセスを開始すべきです。これは、現在の伝送ブロックの終わり（それが示されている場合）で、または後続の符号化ブロック又は送信対象の受信開始時に決定することができます。これは、送信側のデータ内容は、その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 process 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-based 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 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メッセージが送信者と他の受信機にネットワークを介して伝播時間の間、送信者から受信されるように、この制限はなく、抑制が大幅に低減されます。
Inputs:
入力：
1. Sender data content with sequencing identifiers from sender transmissions.
送信者の送信からのシーケンス識別子を持つ1.送信者のデータ内容。
Outputs:
出力：
An effective feedback suppression mechanism is the use of random backoff timeouts prior to NACK transmission by receivers requiring repairs [SrmFramework]. 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 by providing some other indicator of the repair information it will be subsequently transmitting.
効果的なフィードバック抑制機構は、修理[SrmFramework]を必要と受信機によって前NACK送信にランダムバックオフタイムアウトを使用することです。その保留中の修理のニーズが完全に他のレシーバ（受信機は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 [McastFeedback]. 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 the sender's GRTT assessment and a group size estimate that is either determined by other mechanisms within the protocol or is preset by the multicast application.
効果的かつスケーラブルな抑圧性能のために、受信機によって使用されるバックオフタイムアウト期間は、独立して、ランダムに切り捨てられた指数分布[McastFeedback]と受信機によってピックアップされるべきです。これは「早期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」の結果の値が小さいほど。
In the functions below, the "log()" function specified refers to the "natural logarithm" and the "exp()" function is similarly based upon the mathematical constant 'e' (a.k.a. Euler's number) where "exp(x)" corresponds to '"e"' raised to the power of '"x"'. Given the receiver group size ("groupSize") and maximum allowed backoff timeout ("T_maxBackoff"), random backoff timeouts ("t'") with a truncated exponential distribution can be picked with the following algorithm:
以下の機能で、「ログ（）」は、特定の機能は、「自然対数」と「EXP（）」関数は同様に数学定数「E」（別名オイラー数）に基づいていることをいう「EXP（X）」 「『E』」「に対応する 『X』」乗。以下のアルゴリズムを用いて取り出すことができる切頭指数分布を有する受信機のグループサイズ（「GROUPSIZE」）および最大許容バックオフタイムアウト（「T_maxBackoff」）、ランダムバックオフタイムアウト（「T "を」）与えられました：
1. Establish an optimal mean ("L") for the exponential backoff based on the "groupSize":
1.「GROUPSIZE」に基づく指数バックオフのための最適な平均値（「L」）を確立します。
L = log(groupSize) + 1
L =ログ（GROUPSIZE）+ 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 * log(x * (exp(L) - 1) * (T_maxBackoff/L))
T」= T_maxBackoff / Lの*ログ（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 T_maxBackoff, double groupSize)
{
double lambda = log(groupSize) + 1;
double x = UniformRand(lambda/T_maxBackoff) +
lambda / (T_maxBackoff*(exp(lambda)-1));
return ((T_maxBackoff/lambda) *
log(x*(exp(lambda)-1)*(T_maxBackoff/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));
}
The number of expected NACK messages generated ("N") within the first round-trip time for a single feedback event is approximately:
単一のフィードバックイベントの最初のラウンドトリップ時間内に生成された期待NACKメッセージ（「N」）の数は、およそ次のとおりです。
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 trade off worst-case NACK feedback volume versus latency. This is derived from the equations given in [McastFeedback] 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. 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: T_maxBackoff = K * GRTT; where K >= 1
したがって、最大バックオフ時間は、レイテンシに対する最悪の場合のNACKフィードバック量をトレードオフするように調整することができます。これは、[McastFeedback]で与えられた式から誘導されると「T_maxBackoff> = GRTT」、及び「L」を前提としている上記のアルゴリズムに示すように、所定のグループサイズのために最適化された分布の平均です。プロトコル内の他のメカニズムはさらに冗長NACKの発生を低減するために働くことができることに留意されたいです。それは「T_maxBackoff」は送信者の現在のアドバタイズGRTT推定ようの整数倍として選択されることが示唆されている：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; a value of "K=6" is the RECOMMENDED default for unicast NACK delivery. Alternate values may be used to achieve desired buffer utilization, reliable delivery latency, and group size scalability trade-offs.
一般的なインターネットの動作のために、「= 4 K」のデフォルト値は、NACK送達（大でグループに）マルチキャストを使用して操作に推奨されます。 「K = 6」の値は、ユニキャストNACK送達のための推奨されるデフォルトです。代替値は、所望のバッファ使用率、信頼性の高い配信の待ち時間、およびグループサイズのスケーラビリティのトレードオフを達成するために使用されてもよいです。
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 Section 3.2.4.
（「K * GRTT」）がNACKの送信を開始するために受信機によって使用される最大バックオフ時間であることを考えると、NACK修復プロセスに関連する他のタイムアウト期間は、それに応じてスケーリングすることができます。これらのタイムアウトの一つは、受信機が別のNACKバックオフ/送信周期（「T_rcvrHoldoff」）を開始するために自分自身を許可する前にNACKメッセージを生成した後に待つべき時間の量です。送信者が修理のメッセージを受け取ったNACKに応答するためにこの遅延が十分でなければなりません。 NACKは、送信者と修復応答を提供するために、送信者に到達するために適切な値は、時間の量に依存します。これが可能な複数のNACKは、効率的な修復応答を決定するために蓄積されている間、送信者NACK集約期間の任意の量を含まなければなりません。これらのタイムアウトはさらに、セクション3.2.4で説明されています。
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 bias 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 correlation over successive intervals of time in the loss experienced by a receiver. Such correlation MAY not always 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最低修理コンテンツに対する要求を含むべきです。
Inputs:
入力：
Outputs:
出力：
1. Yes/no decision to generate NACK message upon backoff timer expiration.
1.バックオフタイマーの満了時にNACKメッセージを生成するために、はい/いいえ決定。
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 NACK 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 NACK-based reliable multicast can be effectively instantiated without a requirement for reliable NACK delivery using the techniques discussed here.
信頼性の高いマルチキャスト受信機によって生成されたNACKメッセージの内容は、現在修理のニーズを詳細な情報が含まれます。具体的な情報は、NACK修復過程におけるFECの使用や種類によって異なります。修復の必要の識別は、データコンテンツ識別情報に依存している（以下のセクション3.5を参照）。最高レベルでは、NACK含量はNACKがアドレス指定された送信者と修理を必要と送信者の送信中のデータのトランスポート・オブジェクト（またはストリーム）を識別する。指示されたトランスポートエンティティに対して、NACKの含有量は、それが完全に送信されたデータを再構成する必要があり、特定のFEC符号化ブロックおよび/または記号を識別する。このコンテンツは、FECブロック消去カウントおよび/またはデータとFECコンテンツの失われたブロック又はシンボル（セグメント）の明示的な指示からなることができます。また、NACKに基づく信頼性の高いマルチキャストを効果的にここで説明する技術を使用して、信頼性の高い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. This count may need to be adjusted for some FEC algorithms.
FECベースの修復が使用される場合、NACKメッセージの内容は、最小符号化ブロックのために修復が必要とされる符号化ブロック（S）と消去の回数（欠落パケット）を特定する必要があります。消失の正確な数は、FECアルゴリズムは、符号化ブロック内の任意の損失の組み合わせを修復することが可能である暗示します。このカウントは、いくつかのFECアルゴリズムのために調整する必要があるかもしれません。
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 effect repair. For the 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 [FecSchemes]) that are capable of providing a limited number of parity symbols per FEC coding block.
複数の修理ラウンドが正常に完了し、修理に必要なことを考慮すると、消去回数もユニークなFECパリティの量がサーバーにパケットことを意味し送信するために利用できる持っている本質的に無制限である（つまり、サーバは常に、新しいユニークなを提供することができるようになります同じ符号化ブロックのための任意の後続の修復要求）に応答して、以前に未送信パリティパケット。代替的に、送信者は、「ラウンドロビン」は、所定の符号化ブロックに対するFEC記号のその利用可能なセットを介して送信してもよく、最終的に修理を行います。最も効率的な修復戦略について、NACKの内容も明示的に受信機が正常に符号化ブロックの内容を再構築するために必要とするシンボル（情報および/またはパリティ）を特定する必要があります。これは、FEC符号化ブロック当たりのパリティシンボルの限定された数を提供することができる中型ブロックFEC符号（例えば、リード・ソロモン[FecSchemes]）に小規模の特に当てはまるであろう。
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コンテンツが明示的な符号化ブロック及び/又はセグメント損失情報を含む必要があります。 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 the 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 source data vectors plus parity vectors for the given FEC algorithm used. For example, a systematic 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 receive 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.
要約すると、ルールは、最初のNACKサイクルで消去修復ニーズを満たすためにFEC符号化ブロックのパリティ量の低い順序の部分を要求することです。パリティシンボルの利用可能数が不足している場合、受信機は、パリティ記号が記入しませんどのようなカバーするordinally最高の欠落したデータシンボルのサブセットを要求します。この戦略は、単一のパリティシンボルは、任意の消去シンボルを修復することができたため、このようなリードソロモンとしてFECコードを前提としています。この戦略は、アカウントに他のFECタイプの可能性が制限され、修復機能を取るためにマイナーな変更が必要になります。受信機は、その以前に要求されたリペアのコンテンツの一部を受信することが、その後のNACK修復サイクルで、受信機は、それがまだ受信していないパリティ及び/又はデータ・シンボルのセットに対してのみNACKしかし、同じ方法を使用します。必要に応じて、受信機はまた、送信者の便宜のために消去の回数を提供することができます。
Other types of FEC schemes may require alteration to the NACK and repair strategy described here. For example, some of the large block or expandable FEC codes described in [RFC3453] may be less deterministic with respect to defining optimal repair requests by receivers or repair transmission strategies by senders. For these types of codes, it may be sufficient for receivers to NACK with an estimate of the quantity of additional FEC symbols required to complete reliable reception and for the sender to respond accordingly. This apparent disadvantage, as compared to codes such as Reed Solomon, may be offset by the reduced computational requirements and/or ability to support large coding blocks for increased repair efficiency that these codes can offer.
FECスキームの他のタイプは、NACKと、ここで説明した補修戦略に変更が必要な場合があります。例えば、[RFC3453]に記載の大きなブロックまたは拡張可能なFECコードの一部は、受信機または送信者によって修復送信戦略によって、最適な修理要求を定義に関してあまり決定的であり得ます。コードのこれらのタイプのために、それは確実な受信を完了すると、送信者はそれに応じて応答するために必要な追加のFEC符号量の推定値と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.
それは以前に送信されなかったパリティシンボルの十分な量を持っている場合、集計期間中にレシートと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
Figure 2: Reliable Multicast Data Content Identification Hierarchy
図2：信頼性の高いマルチキャストデータ内容の識別階層
The format of NACK messages should enable the following:
NACKメッセージの形式は、次を有効にする必要があります。
1. Identification of transport data units required to repair the received content, whether this is an entire missing object/stream (or range), entire FEC coding block(s), or sets of symbols,
1.これは全体の欠落オブジェクト/ストリーム（または範囲）であるか否かを、受信したコンテンツを修復するために必要なトランスポート・データ・ユニットの識別、全体FEC符号化ブロック（単数または複数）、またはシンボルのセット
3. Inclusion of NACKs for multiple objects, FEC coding blocks, and/or symbols in a single message, and
3.複数のオブジェクト、FEC符号化ブロック、および/または単一のメッセージ内のシンボルのためのNACKの包含、及び
If the reliable multicast 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 receiver's 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.
信頼性の高いマルチキャストトランスポート・オブジェクト/ストリームは<OBJECTID>で識別され、FECシンボルが送信される場合は、<fecPayloadId>、<OBJECTID :: fecPayloadId>の連結は、基本的なトランスポート・プロトコル・データ・ユニットを含む（TPDU）識別子で識別されます与えられたソースからのシンボル。 NACKのコンテンツは、受信機の修理ニーズを記述するためにNACKメッセージを構築するためのリストおよび/またはこれらのTPDU識別子の範囲で構成することができます。何階層オブジェクトの描写又はFECブロックが使用されていない場合、TPDUは、送信者によって送信されたデータシンボルの単純な線形表現です。 TPDUオブジェクト/ストリーム描写及び/又はFECブロックの目的のための階層を表す場合、NACKコンテンツユニットが適用されるTPDUの部分を示すために、フラグを必要とし得ます。例えば、全体の「オブジェクト」（またはオブジェクトの範囲）、受信したデータに欠落している場合、受信機は、必ずしも<sourceBlockNumbers>の適切な範囲を知っているか<encodingSymbolIds>修理を要求する対象の、したがってに何らかの機構を必要としないであろう<OBJECTID>で表されるユニット全体の要求修復（または再送信）。同じことは、一つまたは<sourceBlockNumbers>の範囲によって表される全体FEC符号化ブロックが失われている場合は、trueです。
Inputs:
入力：
5. Current sender transmission sequence position. History of repair needs for this sender.
5.現在の送信者の送信順序位置。修理の歴史は、この送信者のために必要です。
Outputs:
出力：
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 "hold-off" 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 "hold-off" time should be:
すぐに送信者NACKの集計期間の後に、送信者は、集約NACK状態から決定修理内容の送信を開始し、任意の新たな伝送を続けます。また、この時、送信側は、それが原因受信グループに修復応答に新しい送信シーケンス位置の伝播を可能にする新しいNACK集約期間の開始からそれ自体を制約する「ホールドオフ」期間を観察すべきです。最悪の非対称性を可能にするため、この「ホールドオフ」の時間は次のようになります。
T_sndrHoldoff = 1*GRTT
T_sndrHoldoff = 1 * GRTT
Recall that the receivers will also employ a "hold-off" 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 hold-off 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ベースの修理および信頼性の高いマルチキャスト効率を向上させることができ、送信者からの修復応答の順序付けに関していくつかのガイドラインがあります。
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が使用される場合、可能な限り、送信者が修理メッセージとして以前に未送信のパリティコンテンツを送信することは有益です。これは、受信したメッセージの個々の部分集合からの全送信されたコンテンツを再構成する受信ノードの能力を最大化します。
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 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.
送信されたオブジェクト及び/又はストリームデータ及び修理内容が単調に（合理大序空間内に）シーケンス番号を増加させることで索引付けされるべきです。送信者は最古のコンテンツ（例えば、ordinally最低FECブロック）のために修理を送信する規律を観察した場合、送信者が再びオブジェクト/ストリームにそのポイントに戻るまで最初、レシーバは後でコンテンツの修理依頼を源泉徴収の戦略を使用することができます送信シーケンス。これは、グループの中で、全体的なメッセージの効率を高め、比較的送信者と受信機の間の厳密な時間同期に依存せずに同期修理サイクルを保つのを助けることができます。また、これは受信機と送信側のバッファリング要件を最小限に抑えることができますし、大規模で、グループへのデータの冗長伝送を低減します。
Inputs:
入力：
Outputs:
出力：
2. Advertisement of current pending repair transmissions when unicast receiver feedback is detected.
ユニキャスト受信機のフィードバックが検出された現在係属中の修復送信の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 that limit the opportunities for receivers to 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要求を受け入れますが、これは、いくつかの状況では、スケーラビリティの理由から法外かもしれそこから受信機を制限する政策を実施することができます。あるいは、緩い輸送同期ポリシーを有することが望ましいこと、および（または潜在的な対話信頼できるマルチキャストアプリケーションのための）バルク転送アプリケーションのいくつかのタイプにおけるパフォーマンスの低下を引き起こす可能性があるグループダイナミクスを制限するためにセッション管理メカニズムに依存してもよいです。
Inputs:
入力：
1. Current object/stream data/repair content and sequencing identifiers from sender transmissions.
送信者の送信から1 Currentオブジェクト/ストリームデータ/修理内容および配列識別子。
Outputs:
出力：
1. Receiver yes/no decision to begin receiving and NACKing for reliable reception of data.
1.レシーバー、信頼性の高いデータ受信するための受信やNACKingを開始するには、yes / noの決定。
In a NACK-based reliable multicast 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) within the group. Receivers that send NACK messages to the group will need to identify the sender to which the NACK is intended. 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.
データの複数のソースの可能性があるNACKベースの信頼できるマルチキャストプロトコル（または他のマルチキャストプロトコル）には、一意のグループ内のソース（およびおそらくいくつかの又は全ての受信機）を同定するための何らかの機構を設ける必要があります。グループにNACKメッセージを送信する受信機はNACKが意図されている送信者を特定する必要があります。パケットの送信元アドレスを到着に基づくアイデンティティは、いくつかの理由では不十分です。これらの理由は、経時的な特定のホスト、ネットワークアドレス変換（NAT）またはファイアウォールデバイス、または他のトランスポート/ネットワークブリッジのアプローチのための異なるパケットの送信元アドレスにつながる複数のインタフェースを持つホストのルーティングの変更を含みます。その結果、固有のソース識別子のいくつかのタイプは、<ソースID>フィールドは、信頼性の高いマルチキャストセッションメンバーによって送信されたパケットで存在すべきです。
The data and repair content transmitted by a NACK-based reliable multicast 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.
NACKに基づく信頼性の高いマルチキャスト送信側によって送信されたデータ及び修理内容は、プロトコルヘッダフィールドの識別のいくつかのフォームを必要とします。この識別は、信頼性が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 (e.g., <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>）オブジェクトまたはストリームを識別するためのフィールドを含むべきです。このデータコンテンツの識別がグローバルに一意であることが予想されていないことに注意してください。オブジェクト/ストリーム識別子が信頼できるマルチキャストセッション内の送信者がそのオブジェクトまたはストリームの特定のトランスポート・インスタンスをサポートしている時間中に所与の送信者に対して一意であることが期待されます。
Since "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, NACK-based reliable multicast 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 Basic Schemes building block [FECSchemes] and descriptions of additional FEC schemes that may be documented later provide a standard message format for identifying FEC transmission content. NACK-based reliable multicast protocol instantiations using FEC SHOULD follow such guidelines.
「バルク」オブジェクト/ストリームコンテンツは、通常、セグメント化を必要とするため、セグメント識別の何らかの形も提供されなければなりません。このセグメント識別子が提供された任意のオブジェクトまたはストリーム識別子に対してであろう。したがって、いくつかの場合には、NACKベースの信頼できるマルチキャストプロトコルのインスタンスは、複数のストリームと並行して静的オブジェクトの1つまたは複数のセットのための送信要求修復を受信することであってもよいです。 FECを用いるプロトコルのインスタンス化のために、データコンテンツ識別子のセグメント識別部は、符号化ブロック識別子<sourceBlockNumber>の論理的連結及び<encodingSymbolId>コードブロックの特定のデータまたはパリティシンボルの識別子から構成されてもよいです。 FEC基本スキームビルディングブロックは、[FECSchemes]以降に文書化されてもよい付加的なFEC方式の説明は、FEC送信コンテンツを識別するための標準的なメッセージフォーマットを提供します。 FECを使用したNACKに基づく信頼性の高いマルチキャストプロトコルのインスタンスは、このようなガイドラインに従ってください。
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 NACK-based reliable multicast protocol data content messages:
要約すると、次のデータコンテンツ識別フィールドは、NACKベースの信頼できるマルチキャストプロトコル・データ・コンテンツ・メッセージのために必要とされてもよいです。
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.
任意の生成されたNACKメッセージは、データの修理や再送信を要求する際にこれらの識別子を使用しますので、これらのフィールドは確認されています。
Multiple forward error correction (FEC) approaches using erasure coding techniques have been identified that can provide great performance enhancements to the repair process of NACK-oriented and other reliable multicast protocols [FecBroadcast], [RmFec],
複数の順方向誤り訂正（FEC）消去符号化技術を使用して近づく、[RmFec]、[FecBroadcast] NACK指向および他の信頼できるマルチキャストプロトコルの修復プロセスに大きな性能向上を提供することができることが確認されています
[RFC3453]. NACK-based reliable multicast 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 NACK-based reliable multicast, 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 [FecHybrid]. 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 NACK-based reliable multicast, these sorts of requirements may dictate the types of algorithms and protocol approaches that are applicable.
[RFC3453]。 FECベースの修復は、一般的に（シンボルに）、そのコードブロックの大きさの範囲内で修理内容の明示的な知識を必要としないので、NACKに基づく信頼性の高いマルチキャストプロトコルは、付加的な利点を享受することができます。 NACKベースの高信頼マルチキャストでは、生成されたパリティリペアパケットは、一般的にのみ受信ノードからNACK修復要求に応答して送信されます。しかし、通常のデータシンボル送信【FecHybrid]と多重化FECリペアパケットの一部の所定量を送信するためのいくつかのネットワーク環境において利点があります。グループのサイズが非常に大きいか、ネットワーク接続が予想されるパケット損失のいくつかの公称レベルを持つ大規模な「遅延*帯域幅」の製品を持っているとき、これは比較的少ないオーバーヘッドコストで生成されたNACKトラフィックの量を減らすことができます。 FECのアプリケーションは、NACKベースの高信頼マルチキャストに固有のものではないが、要件のこれらの種類は、アルゴリズムと適用可能なプロトコルのアプローチの種類を指示することができます。
A specific issue related to the use of FEC with NACK-based reliable multicast 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 [RFC5052] provides detailed recommendations concerning application of FEC and standard formats for related reliable multicast protocol messages.
NACKベースの信頼できるマルチキャストとFECの使用に関連する特定の問題は、特定のFECパケットが適用された送信データコンテンツの部分（単数または複数）を識別するために使用されるメカニズムです。 FECアルゴリズムは、送信されるデータパケットの対応するブロックに対するパリティ修復パケットのセットを生成するに基づくであろうことが予想されます。データコンテンツパケットを一意に輸送中に<ソースID :: OBJECTID :: sourceBlockNumber :: encodingSymbolId>の連結によって識別されるので、FECパケットは同様の方法で識別されることが期待されます。 FECビルディングブロック文献[RFC5052]に関連する信頼性の高いマルチキャストプロトコルメッセージの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 of "one-to-many" transmission, it may be that only the sender requires RTT knowledge of the GRTT 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 each receiver in the group may need knowledge of its individual RTT. In this case, an alternative RTT collection scheme may be utilized where receivers collect individual RTT measurements with respect to the sender(s) and advertise them to the group or sender(s). 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 [DelayEstimation]. In some cases, there might be absolute time synchronization available among the participating 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 NACK timeouts used by receivers.
グループのメンバー間のパケットの伝搬往復時間（RTT）の測定は、タイマベースNACK抑制アルゴリズム、送信コマンド又は特定の修復機能、輻輳制御動作のタイミングをサポートするために必要とされます。収集往復情報の性質は、グループのメンバー間の相互作用の種類に依存しています。 「1対多」の送信の場合には、それだけ送信者がグループの一部のみのGRTT及び/又はRTT知識のRTTの知識を必要とすることであってもよいです。ここでは、GRTT情報は、合理的にスケーラブルな方法で収集される可能性があります。輻輳制御動作のためには、グループ内の各受信機は、その個々のRTTの知識を必要とする可能性があります。受信機は、送信者（複数可）に対する個々のRTT測定値を収集し、グループまたは送信者（複数可）にそれらをアドバタイズ場合この場合には、別のRTT収集方式が利用されてもよいです。それが信頼性の高いマルチキャスト・データの交換は、「多対多」に基づいてグループ間で発生する可能性がある場合、[DelayEstimation】効率向上のために使用されるかもしれない別の測定技術があります。いくつかのケースでは、RTT測定を単純化することができる参加ホスト間で利用可能な絶対時間同期があるかもしれません。測定を指定することができRTT（またはGRTT）のユニバーサル勧告前に、さらなる検討が必要なマルチキャスト輻輳制御設計のトレードオフがあります。かかわらず、RTT情報が収集される方法の（より具体的にGRTT）輻輳制御、または他の要件に関して、送信側は受信機によって使用される様々なNACKタイムアウトのグループに現在のGRTT推定値をアドバタイズする必要があります。
The goal of this form of RTT measurement is for the sender to estimate the GRTT among the receivers who are actively participating in NACK-based reliable multicast 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.
RTT測定のこの形式の目標は、積極的にNACKベースの高信頼マルチキャスト操作に参加している受信機の間でGRTTを推定する送信者のためです。このプロセスに参加する受信機のセットは、グループ全体またはプロトコルのインスタンス内の別の機構から決定基のサブセットであってもよいです。この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 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推定値よりも小さい場合、応答収集期間（すなわち、GRTTプローブ間隔）の終わりに2は、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 estimate of GRTT (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 NACK repair cycle timeouts are based on GRTT, it should be noted that convergent operation of the protocol does not depend upon highly accurate GRTT estimation. The current mechanism has proved sufficient in simulations and in the environments where NACK-based reliable multicast protocols have been deployed to date. The estimate provided by the given 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.
NACK修理サイクルタイムアウトがGRTTに基づいているが要するに、プロトコルの収束動作を高精度GRTT推定に依存しないことに留意すべきです。現在のメカニズムは、シミュレーション中とNACKベースの高信頼マルチキャストプロトコルがこれまでに展開されている環境では十分であることが判明しています。所定のアルゴリズムによって提供される推定値は、比較的高損失の接続に（オペレーティングシステム効果ならびにネットワーク遅延を含む）実際の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 senders "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 with respect to a small subset of other group members and if information concerning RTT among those other group members is learned by the node during protocol operation.
これらの他のグループのメンバー間RTTに関する情報は、プロトコル動作中にノードにより学習された他のグループメンバーの小さなサブセットに対して及び場合RTT情報が自身のRTTに関するノードに利用可能である場合、この推定値の更なる改良を行うことができます。
To facilitate deterministic 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 allow 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 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. NACK-based reliable multicast 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.
決定論的なプロトコルの動作を容易にするために、送信者が確実に受信機セットに「GRTT」の現在の推定を宣伝する必要があります。グループの中で、送信者の現在の動作GRTT推定値の一般的な、強力な知識は、プロトコルがその最も効率的な方法で進行することができます。送信者のGRTT推定値は確実に簡単に送信者によって送信されたすべての関連メッセージに見積もりを埋め込むことにより、グループにアドバタイズすることができます。このオーバーヘッドは、情報の単一バイトにGRTT推定値を量子化（圧縮）することによって、非常に小さくすることができます。以下のC言語の関数が小さな値と大きな値にはあまり精度のために精度のより大きな範囲を維持しながら、これはGRTT値の広い範囲（「RTT_MAX」から「RTT_MIN」）を介して行われることを可能にします。 1.0E-06秒、1000秒の値は、それぞれ「RTT_MIN」と「RTT_MAX」のために推奨されています。 NACKに基づく信頼性の高いマルチキャストアプリケーションは、いくつかのネットワーク環境においてより大きなフィードバック音量を犠牲にして、アプリケーションデータ配信レイテンシ制約を満たすために、送信者によってアドバタイズ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, NACK-based reliable multicast protocol implementations may wish to further constrain advertised GRTT estimates (e.g., limit the maximum value) for practical reasons.
この機能は、1000秒に1マイクロ秒の範囲でGRTT時間を量子化するために有用であることに注意してください。もちろん、NACKベースの信頼できるマルチキャストプロトコル実装は、さらに実用的な理由のためにアドバタイズGRTT推定値（例えば、最大値を制限する）拘束することを望むかもしれません。
When NACK-based reliable multicast 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 any group size determination mechanism, a default group size value of 10,000 is RECOMMENDED for reasonable management of feedback given the scalability of expected NACK-based reliable multicast usage. This conservative estimate (over-estimate) of group size in the algorithms described above will result in some added latency to the NACK repair process if the actual group size is smaller but with a guarantee of feedback implosion protection. The study of the timer-based feedback suppression mechanism described in [McastFeedback] and [NormFeedback] showed that the group size estimate need only be with an order-of-magnitude to provide effective suppression performance.
NACKベースの信頼できるマルチキャストプロトコルの動作（例えば、輻輳制御）大でグループからのフィードバックを励起する機構を含む場合おおよその分布に関してフィードバック・メッセージの数に基づいて、グループサイズを推定受信し、それが可能であってもよいです確率的抑制メカニズムを使用します。この文書で説明するタイマーベースの抑制機構が適切に実行するためにグループサイズの非常に正確な推定値を必要としません。このように、概算では、保守的に管理する場合は特に、十分です。グループのサイズも管理上決定することができます。任意のグループサイズ決意機構の非存在下で、10,000デフォルト・グループ・サイズ値は、予想されるNACKに基づく信頼性の高いマルチキャストの使用のスケーラビリティ所与のフィードバックの合理的な管理のために推奨されます。実際のグループのサイズが小さいが、フィードバック爆縮保護の保証である場合、上述のアルゴリズムにおけるグループサイズの（過剰推定）この保守的な推定値は、NACK修復プロセスにいくつかの追加の待ち時間をもたらすであろう。記載のタイマーに基づくフィードバック抑制機構の研究[McastFeedback]及び[NormFeedback]は、グループサイズの見積もりのみ桁違いの効果的な抑圧性能を提供することであればよいことを示しました。
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) [TfmccPaper] or Pragmatic General Multicast Congestion Control (PGMCC) [PgmccPaper] techniques can be applied to NACK-based reliable multicast operation to meet this requirement. The former technique has been further documented in [RFC4654] and has been successfully applied in the NACK-Oriented Reliable Multicast Protocol (NORM) [RFC3940].
かなり株式は、他の信頼性の高いマルチキャストおよびTCPインスタンスで使用可能なネットワーク容量は、一般的なインターネットの操作に必要な輻輳制御。 TCPフレンドリーマルチキャスト輻輳制御（TFMCC）TfmccPaper]又は実用一般マルチキャスト輻輳制御（PGMCC）PgmccPaper]技術は、この要件を満たすために、NACKベースの信頼性の高いマルチキャスト動作に適用することができます。前者の技術は、さらに、[RFC4654]に記載されており、正常NACK指向高信頼マルチキャストプロトコル（NORM）[RFC3940]に適用されています。
NACK-based multicast protocols may benefit from general purpose intermediate system assistance. In particular, additional NACK suppression where 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 NACK-based reliable multicast 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. Similarly, intermediate systems could monitor receiver NACKs and provide repair transmissions on-demand in response if sufficient state on the content being transmitted was being maintained. This can reduce the latency and volume of repair transmissions when the intermediate system is associated with a network link that is particularly problematic with respect to packet loss. These types of assist functions would require intermediate system interpretation of transport data unit content identifiers and flags. NACK-based protocol designs should consider the potential for intermediate system assistance in the specification of protocol messages and operations. It is likely that intermediate systems assistance will be more pragmatic if message parsing requirements are modest and if the amount of state an intermediate system is required to maintain is relatively small.
NACKベースのマルチキャストプロトコルは汎用中間システム支援の恩恵を受けることができます。それは、送信者に向けて中継されるように受信機から特定の中間システムがNACKコンテンツを集約（またはフィルタNACKコンテンツを複製する）ことができ、付加的なNACK抑制するNORMグループサイズのスケーラビリティを高めることができます。 FECを使用したNACKに基づく信頼性の高いマルチキャストプロトコルのために、中間システムは、以前受信機から学習修理の必要性に応じマルチキャストトポロジーの異なる脚に修復コンテンツのインテリジェント「subcast」を提供するFECリペアメッセージをフィルタリングすることができる可能性がありますNACKが。同様に、中間システムは、受信機NACKを監視し、送信されている内容に十分な状態が維持されていた場合に応答して、オンデマンド修復送信を提供することができます。中間システムはパケット損失に対して特に問題であるネットワークリンクに関連付けられている場合、これは修復送信の待ち時間と体積を減らすことができます。アシスト機能これらのタイプのトランスポートデータユニットのコンテンツ識別子とフラグの中間システムの解釈を必要とするであろう。 NACKベースのプロトコルの設計は、プロトコルメッセージと操作の仕様で中間システム支援の可能性を考慮すべきです。中間システムの支援がメッセージの解析要件は控えめであり、中間システムを維持するために必要とされる状態の量が比較的小さい場合ならば、より実用的になる可能性が高いです。
The Multicast NACK building block applies to protocols wishing to employ negative acknowledgement to achieve reliable data transfer. Properly designed NACK-based reliable multicast 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 multicast scalability property of NACK-based protocols [RmComparison], [RmClasses] 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. NACK-based reliable multicast protocols can make use of reciprocal (among senders and receivers) multicast communication under the any-source multicast (ASM) model defined in RFC 1112 [RFC1112], and are capable of scalable operation in asymmetric topologies, such as source-specific multicast (SSM) [RFC4607], where there may only be unicast routing service from the receivers to the sender(s).
マルチキャストNACKのビルディングブロックは、信頼性の高いデータ転送を実現するために否定応答を採用したいプロトコルに適用されます。適切NACKベースの信頼できるマルチキャストプロトコルは、様々な理由のため、基本的なレイヤ3のIPマルチキャストサービス（例えば、ユニキャストまたはハイブリッドユニキャスト/上記高次配信インフラストラクチャを構築するために法外であり、アプリケーションおよび/またはネットワークトポロジの拡張性の利点を提供するように設計マルチキャストデータ配信ツリー）。幅広い「ファンアウト」が単一のネットワーク・ホップ（例えば、ケーブルTVデータ配信、衛星、または他の同報通信サービスのために期待されている場合に加えて、NACKベースのプロトコルのマルチキャストスケーラビリティプロパティは、[RmComparison]、[RmClasses]適用可能です）。また、「フラット」グループ全体のマルチキャスト配信に基づくプロトコルの単純さは、分散サービスまたは動的ネットワークとアプリケーションの広い範囲のための利点を提供することができます。 NACKに基づく信頼性の高いマルチキャストプロトコルは、RFC 1112 [RFC1112]で定義された任意のソースマルチキャスト（ASM）モデルの下でマルチキャスト通信（送信者と受信者の間で）相互を使用すること、およびそのようなソースとして非対称トポロジにスケーラブルな操作が可能であることができます唯一の受信機から送信者（複数可）にユニキャストルーティングサービスが存在し得る特異的マルチキャスト（SSM）[RFC4607]。
NACK-based reliable multicast protocol operation is compatible with transport layer forward error correction coding techniques as described in [RFC3453] and congestion control mechanisms such as those described in [TfmccPaper] and [PgmccPaper]. A principal limitation of NACK-based reliable multicast operation involves group size scalability when network capacity for receiver feedback is very limited. It is possible that, with proper protocol design, the intermediate system assistance techniques mentioned in Section 2.4 and described further in Section 3.10 can allow NACK-based approaches to scale to larger group sizes. NACK-based reliable multicast 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.
NACKベースの信頼できるマルチキャストプロトコルの動作は、[PgmccPaper] [TfmccPaper]および記載されたものとして[RFC3453]及び輻輳制御メカニズムで説明したように、トランスポート層の順方向誤り訂正符号化技術と互換性があります。受信機のフィードバックのためのネットワーク容量が非常に限られている場合にNACKベースの信頼性の高いマルチキャスト動作の主な制限は、グループサイズのスケーラビリティを伴います。適切なプロトコル設計と、3.10で2.4節で述べ、さらに説明中間システム支援技術は、NACKベースのアプローチは、より大きなグループサイズに拡張させることができる、ということが可能です。 NACKベースの信頼性の高いマルチキャスト動作も実装バッファリング制約によって支配されています。典型的なポイントツーポイント信頼性トランスポート（例えば、TCP）のために必要なものよりも大きいバッファが受信機グループ接続性の格差を可能にするために、グループサイズのスケーラビリティを達成するために必要なフィードバック遅延を可能にすることが推奨されます。
Prior experimental work included various protocol instantiations that implemented some of the concepts described in this building block document. This includes the Pragmatic General Multicast (PGM) protocol described in [RFC3208] as well as others that were documented or deployed outside of IETF activities. While the PGM protocol specification and some other approaches encompassed many of the goals of bulk data delivery as described here, this NACK-based building block provides a more generalized framework so that different application needs can be met by different protocol instantiation variants. The NACK-based building block approach described here includes compatibility with the other protocol mechanisms including FEC and congestion control that are described in other IETF reliable multicast building block documents. The NACK repair process described in this document can provide performance advantages compared to PGM when both are deployed on a pure end-to-end basis without intermediate system assistance. The round-trip timing estimation described here and its use in the NACK repair process allow protocol operation to more automatically adapt to different network environments or operate within environments where connectivity is dynamic. Use of the FEC payload identification techniques described in the FEC building block [RFC5052] and specific FEC instantiations allow protocol instantiations more flexibility as FEC techniques evolve than the specific sequence number data identification scheme described in the PGM specification. Similar flexibility is expected if protocol instantiations are designed to modularly invoke (at design time, if not run-time) the appropriate congestion control building block for different application or deployment purposes.
先行実験研究は、このビルディングブロックの文書に記載された概念のいくつかを実装し、様々なプロトコルのインスタンスを含んでいました。これは、実用的な一般的なマルチキャスト（PGM）[RFC3208]に記載されているプロトコル、ならびに文書またはIETF活動の外側に展開された他のものを含みます。ここで説明したようにPGMプロトコル仕様及びいくつかの他のアプローチは、バルクデータ配信の目標の多くを包含しながら、異なるアプリケーションのニーズが異なるプロトコルインスタンス化変異体によって満たすことができるように、このNACKベースのビルディングブロックは、より一般的なフレームワークを提供します。ここで説明NACKベースのビルディング・ブロック・アプローチは、他のIETF高信頼マルチキャストビルディングブロックの文書に記載されているFEC及び輻輳制御を含む他のプロトコルメカニズムとの互換性を有しています。この文書に記載されNACK修復プロセスは、両方の中間システムの支援なしに、純粋なエンドツーエンドベースで展開されているPGMに比べて性能上の利点を提供することができます。往復タイミング推定は、ここで説明するとNACK修復プロセスにおけるその使用は、プロトコルの動作をより自動的に異なるネットワーク環境に適応するまたは接続が動的な環境内で動作することを可能にします。 FEC技術は、PGMの明細書に記載された特定のシーケンス番号データ識別方式より進化としてFECビルディングブロック[RFC5052]と特定FECインスタンスに記載FECペイロード識別技術の使用は、プロトコルインスタンスをより柔軟性を可能にします。プロトコルのインスタンスが（実行時ではない場合は、設計時に）モジュール式異なるアプリケーションまたはデプロイメントの目的のために適切な輻輳制御ビルディングブロックを起動するように設計されている場合は同様の柔軟性が期待されています。
NACK-based reliable multicast protocols are expected to be subject to the same security vulnerabilities as other IP and IP multicast protocols. However, unlike point-to-point (unicast) transport protocols, it is possible that one badly behaving participant can impact the transport service experience of others in the group. For example, a malicious receiver node could intentionally transmit NACK messages to cause the sender(s) to unnecessarily transmit repairs instead of making forward progress with reliable transfer. Also, group-wise messaging to support congestion control or other aspects of protocol operation may be subject to similar vulnerabilities. Thus, it is highly RECOMMENDED that security techniques such as authentication and data integrity checks be applied for NACK-based reliable multicast deployments. Protocol instantiations using this building block MUST identify approaches to security that can be used to address these and other security considerations.
NACKベースの高信頼マルチキャストプロトコルは、他のIPとIPマルチキャストプロトコルと同じセキュリティ上の脆弱性の対象となることが期待されています。しかしながら、ポイントツーポイント（ユニキャスト）トランスポートプロトコルとは異なり、1人の悪い行動参加者は、グループ内の他のトランスポート・サービスの経験に影響を与えることが可能です。たとえば、悪意のある受信ノードは、意図的に不必要代わりに信頼性の高い転送に前進を作るの修理を送信する送信者（複数可）を引き起こすためにNACKメッセージを送信することができます。また、プロトコル操作の輻輳制御、または他の側面をサポートするグループごとメッセージングは、同様の脆弱性の対象とすることができます。したがって、非常にそのような認証やデータの整合性チェックなどのセキュリティ技術がNACKに基づく信頼性の高いマルチキャスト展開に適用されることが推奨されます。このビルディングブロックを使用してプロトコルのインスタンス化は、これらおよび他のセキュリティ上の考慮事項に対処するために使用することができ、セキュリティへのアプローチを特定しなければなりません。
NACK-based reliable multicast is compatible with IP security (IPsec) authentication mechanisms [RFC4301] 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, which could prevent a multicast sender from making forward progress in transmission. Any standard IPsec mechanisms that can provide protection against such replay attacks are RECOMMENDED for use. The IETF Multicast Security (MSEC) Working Group has developed a set of recommendations in its "Multicast Extensions to the Security Architecture for the Internet Protocol" [IpsecExtensions] that can be
NACKベースの高信頼マルチキャストセッションの侵入やサービス拒否攻撃に対する保護のために推奨されているIPセキュリティ（IPsec）の認証メカニズム[RFC4301]と互換性があります。 NACKベースのプロトコルのための特定の脅威は、順方向伝送における進歩を遂げてから、マルチキャスト送信者を防ぐことができた、NACKのリプレイ攻撃のことです。このようリプレイ攻撃に対する保護を提供することができる任意の標準のIPsecメカニズムを使用することをお勧めします。 IETFマルチキャストセキュリティ（MSEC）ワーキンググループができること[IpsecExtensions]その「インターネットプロトコルのためのセキュリティー体系へのマルチキャスト拡張機能」の推奨事項のセットを開発しました。
applied to appropriately extend IPsec mechanisms to multicast operation. An appendix of this document specifically addresses the NACK-Oriented Reliable Multicast protocol service model. As complete support for IPsec multicast operation may potentially follow reliable multicast deployment, NACK-based reliable multicast protocol instantiations SHOULD consider providing support for their own NACK replay attack protection when network layer mechanisms are not available. This MAY be necessary when IPsec implementations are used that do not provide multicast replay attack protection when multiple sources are present.
適切マルチキャスト動作のIPsecメカニズムを拡張するために適用されます。このドキュメントの付録では、具体的NACK指向リライアブルマルチキャストプロトコルサービスモデルに対応しています。 IPsecのマルチキャスト動作のための完全なサポートは、潜在的に信頼性の高いマルチキャスト展開をたどることができるよう、NACKベースの高信頼マルチキャストプロトコルのインスタンスは、ネットワーク層メカニズムが利用できない場合、独自のNACKリプレイ攻撃からの保護のためのサポートを提供することを検討すべきです。 IPsec実装が使用されているとき、これは複数のソースが存在する場合、マルチキャストリプレイ攻撃に対する保護を提供しないことが必要な場合があります。
For NACK-based multicast deployments with large receiver groups using IPsec, approaches might be developed that use shared, common keys for receiver-originated protocol messages to maintain a practical number of IPsec Security Associations (SAs). However, such group-based authentication may not be sufficient unless the receiver population can be completely trusted. Additionally, this can make identification of badly behaving (although authenticated) receiver nodes problematic as such nodes could potentially masquerade as other receivers in the group. In deployments such as this, one SHOULD consider use of source-specific multicast (SSM) instead of any-source multicast (ASM) models of multicast operation. SSM operation can simplify security challenges in a couple of ways:
IPsecを使用して大型レシーバ基を有するNACKベースのマルチキャスト展開の接近は、IPsecセキュリティアソシエーション（SA）の実用的な数を維持するために、受信機から発信プロトコルメッセージの共有、共通鍵を使用するように開発されるかもしれません。レシーバ集団が完全に信頼することができない限り、しかし、そのようなグループベースの認証では十分ではないかもしれません。そのようなノードとして問題の受信ノードの潜在的にグループ内の他の受信機になりすますことができた（認証さはあるが）また、これは悪い行動の識別を行うことができます。このような展開では、一方がソース固有マルチキャスト（SSM）の代わりに、任意のソースマルチキャスト（ASM）マルチキャスト動作のモデルの使用を考慮すべきです。 SSM操作は、いくつかの方法でセキュリティ上の課題を簡素化することができます。
1. A NACK-based protocol supporting SSM operation can eliminate direct receiver-to-receiver signaling. This dramatically reduces the number of security associations that need to be established.
SSMの動作をサポート1. A NACKベースのプロトコルは、直接受信機に受信機シグナリングを排除することができます。これは劇的に確立する必要があるセキュリティアソシエーションの数を減らすことができます。
2. The SSM sender(s) can provide a centralized management point for secure group operation for its respective data flow as the sender alone is required to conduct individual host authentication for each receiver when group-based authentication does not suffice or is not pragmatic to deploy.
2. SSM送信者（複数可）は、単独で、送信者としてのそのそれぞれのデータフローのための安全なグループ操作のための集中管理ポイントを提供することができるグループベースの認証が十分でない場合、各受信機のために個々のホストの認証を行うために必要なまたはそれに実用的ではありません展開。
When individual host authentication is required, then it is possible receivers could use a digital signature on the IPsec Encapsulating Security Protocol (ESP) payload as described in [RFC4359]. Either an identity-based signature system or a group-specific public key infrastructure could avoid per-receiver state at the sender(s). Additionally, implementations MUST also support policies to limit the impact of extremely or exceptionally poor-performing (due to bad behavior or otherwise) receivers upon overall group operation if this is acceptable for the relevant application.
個々のホスト認証が要求される場合、[RFC4359]に記載されるように受信機は、IPSecカプセル化セキュリティプロトコル（ESP）ペイロードにデジタル署名を使用することが可能です。アイデンティティに基づく署名方式またはグループ固有の公開鍵インフラストラクチャのどちらかは、送信側（S）でごとの受信状態を避けることができました。これは、関連するアプリケーションのために許容可能である場合に加えて、実装はまた、グループ全体の動作時に受信機（これは悪い行動にまたは他の方法で）非常にまたは非常に悪い実行の影響を制限するポリシーをサポートしなければなりません。
As described in Section 3.4, deployment of NACK-based reliable multicast in some network environments may require identification of group members beyond that of IP addressing. If protocol-specific security mechanisms are developed, then it is RECOMMENDED that protocol group member identifiers are used as selectors (as defined in [RFC4301]) for the applicable security associations. When IPsec is used, it is RECOMMENDED that the protocol implementation verify that the source IP addresses of received packets are valid for the given protocol source identifier in addition to usual IPsec authentication. This would prevent a badly behaving (although authorized) member from spoofing messages from other legitimate members, provided that individual host authentication is supported.
セクション3.4で説明したように、いくつかのネットワーク環境におけるNACKベースの信頼性の高いマルチキャストの展開は、IPアドレス指定のものを超えるグループのメンバーの識別を必要とするかもしれません。プロトコル固有のセキュリティメカニズムが開発されている場合、（[RFC4301]で定義されるように）プロトコルグループメンバー識別子が該当のセキュリティアソシエーションのためのセレクタとして使用されることが推奨されます。 IPsecを使用する場合には、プロトコルの実装は、受信パケットの送信元IPアドレスは、通常のIPsec認証に加えて、特定のプロトコルソース識別子について有効であることを検証することが推奨されます。これは、他の正当なメンバーからのメッセージをスプーフィングからの悪い行動（許可が）部材を防止個々のホスト認証がサポートされていることを条件とするであろう。
The MSEC Working Group has also developed automated group keying solutions that are applicable to NACK-based reliable multicast security. For example, to support IPsec or other security mechanisms, the Group Secure Association Key Management Protocol [RFC4535] MAY be used for automated group key management. The technique it identifies for "Group Establishment for Receive-Only Members" may be application NACK-based reliable multicast SSM operation.
MSECワーキンググループはまた、NACKベースの高信頼マルチキャストのセキュリティに適用される自動化されたグループキーイングソリューションを開発してきました。例えば、IPSecまたは他のセキュリティ・メカニズムをサポートするために、グループセキュア協会鍵管理プロトコル[RFC4535]は自動化されたグループ鍵管理のために使用されるかもしれません。それは、「受信専用メンバーのグループ設立」のために識別する技術は、アプリケーションNACKベースの信頼性の高いマルチキャストSSMの操作であってもよいです。
This section lists the changes between the Experimental version of this specification, [RFC3941], and this version:
このセクションでは、本明細書の実験のバージョンとの間の変更、[RFC3941]、およびこのバージョンを示しています。
1. Change of title to avoid confusion with NORM Protocol specification,
NORMプロトコル仕様との混同を避けるために、タイトルの1の変更、
2. Updated references to related, updated RMT Building Block documents, and
関連、更新RMTビルディングブロックの文書へ2.参照を更新して、
(and these are not Negative)
（これらはマイナスではありません）
The authors would like to thank George Gross, 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、この仕様の開発で彼らのサポートのために、とサリーフロイドに感謝したいと思います。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]デアリング、S.、STD 5、RFC 1112 "IPマルチキャスティングのためのホスト拡大"、1989年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607]ホルブルック、H.、およびB.カイン、 "IPのためのソース固有のマルチキャスト"、RFC 4607、2006年8月。
[ArchConsiderations] Clark, D. and D. Tennenhouse, "Architectural Considerations for a New Generation of Protocols", Proc. ACM SIGCOMM, pp. 201-208, September 1990.
[ArchConsiderations]クラーク、D.とD. Tennenhouse、 "プロトコルの新世代のための建築に関する注意事項"、PROC。 ACM SIGCOMM、頁201〜208、1990年9月。
[DelayEstimation] Ozdemir, V., Muthukrishnan, S., and I. Rhee, "Scalable, Low-Overhead Network Delay Estimation", NCSU/AT&T White Paper, February 1999.
[DelayEstimation] Ozdemir、V.、Muthukrishnan、S.、およびI.李承晩、 "スケーラブル、低オーバーヘッドのネットワーク遅延の推定"、NCSU / AT＆Tホワイトペーパー、1999年2月。
[FECSchemes] Watson, M., "Basic Forward Error Correction (FEC) Schemes", Work in Progress, July 2008.
[FECSchemes]ワトソン、M.、 "基本的な前方誤り訂正（FEC）スキーム"、進歩、2008年7月に作業。
[FecBroadcast] Metzner, J., "An Improved Broadcast Retransmission Protocol", IEEE Transactions on Communications Vol. Com-32, No. 6, June 1984.
【FecBroadcast] Metzner、J.、「改善ブロードキャスト再送プロトコル」、通信巻に関するIEEEトランザクション。 COM-32、第6号、1984年6月。
[FecHybrid] Gossink, D. and J. Macker, "Reliable Multicast and Integrated Parity Retransmission with Channel Estimation", IEEE Globecomm 1998, 1998.
[FecHybrid] Gossink、D.とJ. Macker、 "チャネル推定を用いた高信頼マルチキャストおよび統合されたパリティ再送信"、IEEE Globecomm 1998、1998。
[FecSchemes] Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo, "Reed-Solomon Forward Error Correction (FEC) Schemes", Work in Progress, November 2007.
[FecSchemes]ラカン、J.、ロカ、V.、Peltotalo、J.、およびS. Peltotalo、 "リード・ソロモン前方誤り訂正（FEC）スキーム"、進歩、2007年11月に作業。
[IpsecExtensions] Weis, B., Gross, G., and D. Ignjatic, "Multicast Extensions to the Security Architecture for the Internet Protocol", Work in Progress, June 2008.
[IpsecExtensions]ヴァイス、B.、グロス、G.、およびD. Ignjatic、「インターネットプロトコルのためのセキュリティー体系へのマルチキャスト拡張機能」、進歩、2008年6月の作業。
[McastFeedback] Nonnenmacher, J. and E. Biersack, "Optimal Multicast Feedback", IEEE Infocom p. 964, March/April 1998.
【McastFeedback] Nonnenmacher、J.及びE. Biersack、 "最適マルチキャストフィードバック"、IEEEインフォコムのP。 964年3月/ 1998年4月。
[NormFeedback] Adamson, B. and J. Macker, "Quantitative Prediction of NACK-Oriented Reliable Multicast (NORM) Feedback", IEEE MILCOM 2002, October 2002.
【NormFeedback]アダムソン、B.及びJ. Macker、 "NACK指向高信頼マルチキャスト（NORM）フィードバックの定量的予測"、IEEE MILCOM 2002、2002年10月。
[PgmccPaper] Rizzo, L., "pgmcc: A TCP-Friendly Single-Rate Multicast Congestion Control Scheme", ACM SIGCOMM 2000, August 2000.
[PgmccPaper] Rizzo氏、L.、 "pgmcc：TCPフレンドリーシングルレートマルチキャスト輻輳制御方式"、ACM SIGCOMM 2000、2000年8月。
[RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
[RFC2357]マンキン、A.、ロマノフ、A.、RFC 2357、1998年6月ブラドナーの、S.、およびV.パクソン、 "信頼性の高いマルチキャストトランスポートとアプリケーションプロトコルを評価するためのIETF基準"。
[RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci, D., Lin, S., Leshchiner, D., Luby, M., Montgomery, T., Rizzo, L., Tweedly, A., Bhaskar, N., Edmonstone, R., Sumanasekera, R., and L. Vicisano, "PGM Reliable Transport Protocol Specification", RFC 3208, December 2001.
[RFC3208]スピークマン、T.、クロウクロフト、J.、Gemmell、J.、ファリナッチ、D.、リン、S.、Leshchiner、D.、ルビー、M.、モンゴメリー、T.、リゾー、L.、Tweedly、 A.、Bhaskar、N.、Edmonstone、R.、Sumanasekera、R.、およびL. Vicisano、 "PGM信頼できるトランスポートプロトコル仕様"、RFC 3208、2001年12月。
[RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents", RFC 3269, April 2002.
[RFC3269] Kermode、R.とL. Vicisano、RFC 3269、2002年4月 "信頼できるマルチキャストトランスポート（RMT）ビルディングブロックとプロトコルのインスタンス文書の作者のガイドライン"。
[RFC3453] 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.
[RFC3453]ルビー、M.、Vicisano、L.、Gemmell、J.、リゾー、L.、ハンドレー、M.、およびJ.クロウクロフト、 "信頼できるマルチキャストの前方誤り訂正（FEC）の使用"、RFC 3453 、2002年12月。
[RFC3940] Adamson, B., Bormann, C., Handley, M., and J. Macker, "Negative-acknowledgment (NACK)- Oriented Reliable Multicast (NORM) Protocol", RFC 3940, November 2004.
[RFC3940]アダムソン、B.、ボルマン、C.、ハンドレー、M.、およびJ. Macker、 "否定応答（NACK） - 指向高信頼マルチキャスト（NORM）プロトコル"、RFC 3940、2004年11月。
[RFC3941] Adamson, B., Bormann, C., Handley, M., and J. Macker, "Negative-Acknowledgment (NACK)- Oriented Reliable Multicast (NORM) Building Blocks", RFC 3941, November 2004.
[RFC3941]アダムソン、B.、ボルマン、C.、ハンドレー、M.、およびJ. Macker、 "否定応答（NACK） - 指向高信頼マルチキャスト（NORM）ビルディングブロック"、RFC 3941、2004年11月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4359, January 2006.
[RFC4359]ヴァイス、B.、RFC 4359、2006年1月 "カプセル化セキュリティペイロード（ESP）と認証ヘッダー（AH）内のRSA / SHA-1署名の使用"。
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006.
[RFC4535]はハーニー、H.、メタ、U.、Colegrove、A.、およびG.グロスは、：RFC 4535、2006年6月、 "GSAKMPグループは、協会の鍵管理プロトコルをセキュア"。
[RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification", RFC 4654, August 2006.
[RFC4654]ウィドマー、J.とM.ハンドリー、 "TCPフレンドリーマルチキャスト輻輳制御（TFMCC）：プロトコル仕様"、RFC 4654、2006年8月。
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction (FEC) Building Block", RFC 5052, August 2007.
[RFC5052]ワトソン、M.、ルビー、M.、およびL. Vicisano、 "前方誤り訂正（FEC）ビルディングブロック"、RFC 5052、2007年8月。
[RmClasses] Levine, B. and J. Garcia-Luna-Aceves, "A Comparison of Known Classes of Reliable Multicast Protocols", Proc. International Conference on Network Protocols (ICNP-96) Columbus, OH, October 1996.
【RmClasses]レヴァイン、B.及びJ.ガルシア - ルナ - ACEVES、PROC、「高信頼マルチキャストプロトコルの既知のクラスの比較」。ネットワークプロトコルに関する国際会議（ICNP-96）オハイオ州コロンバス、1996年10月。
[RmComparison] Pingali, S., Towsley, D., and J. Kurose, "A Comparison of Sender-Initiated and Receiver-Initiated Reliable Multicast Protocols", Proc. INFOCOMM San Francisco, CA, October 1993.
【RmComparison] Pingali、S.、Towsley、D.、およびJ.黒瀬、「送信者開始の比較及び受信器で開始高信頼マルチキャストプロトコル」、PROC。インフォコムサンフランシスコ、CA、1993年10月。
[RmFec] Macker, J., "Reliable Multicast Transport and Integrated Erasure-based Forward Error Correction", IEEE MILCOM 1997, October 1997.
[RmFec] Macker、J.、 "信頼性の高いマルチキャストトランスポートと統合された消去ベースの前方誤り訂正"、IEEE MILCOM 1997、1997年10月。
[SrmFramework] 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.
【SrmFramework]フロイド、S.、ヤコブソン、V.、McCanne、S.、劉、C.、およびL.チャン、 "軽量セッションの高信頼マルチキャストフレームワークとアプリケーションレベルフレーミング"、PROC。 ACM SIGCOMM、1995年8月。
[TfmccPaper] Widmer, J. and M. Handley, "Extending Equation-Based Congestion Control to Multicast Applications", ACM SIGCOMM 2001, August 2001.
【TfmccPaper]ウィドマー、J.とM.ハンドレー、ACM SIGCOMM 2001、2001年8月「マルチキャストアプリケーションに式ベースの輻輳制御を拡張」。
Authors' Addresses
著者のアドレス
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 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