Network Working Group M. Handley
Request for Comments: 2887 S. Floyd
Category: Informational ACIRI
B. Whetten
Talarian
R. Kermode
Motorola
L. Vicisano
Cisco
M. Luby
Digital Fountain, Inc.
August 2000
The Reliable Multicast Design Space for Bulk Data Transfer
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
The design space for reliable multicast is rich, with many possible solutions having been devised. However, application requirements serve to constrain this design space to a relatively small solution space. This document provides an overview of the design space and the ways in which application constraints affect possible solutions.
多くの可能な解決策が考案されたもので、信頼性マルチキャストの設計空間は、豊富です。ただし、アプリケーションの要件は比較的小さい解空間に、この設計空間を制約するのに役立ちます。この文書では、設計空間とアプリケーションの制約が可能な解決策に影響を与えている方法の概要を説明します。
The term "general purpose reliable multicast protocol" is something of an oxymoron. Different applications have different requirements of a reliable multicast protocol, and these requirements constrain the design space in ways that two applications with differing requirements often cannot share a single solution. There are however many successful reliable multicast protocol designs that serve more special purpose requirements well.
用語「汎用信頼性の高いマルチキャストプロトコルは、」矛盾のようなものです。異なるアプリケーションが信頼できるマルチキャストプロトコルの異なる要件を持っており、これらの要件は、異なる要件を持つ2つのアプリケーションが、多くの場合、単一のソリューションを共有することはできません方法で、デザインスペースを制約します。よく、より特別な目的の要件を果たすしかし、多くの成功した信頼性の高いマルチキャストプロトコルのデザインがあります。
In this document we attempt to review the design space for reliable multicast protocols intended for bulk data transfer. The term bulk data transfer should be taken as having broad meaning - the main limitations are that the data stream is continuous and long lived - constraints necessary for the forms of congestion control we currently understand. The purpose of this review is to gather together an overview of the field and to make explicit the constraints imposed by particular mechanisms. The aim is to provide guidance to the standardization process for protocols and protocol building blocks. In doing this, we cluster potential solutions into a number of loose categories - real protocols may be composed of mechanisms from more than one of these clusters.
この文書では、バルクデータ転送のために意図され、信頼性マルチキャストプロトコルの設計空間を確認しようとします。用語バルクデータ転送は、広い意味を持つものとして取られるべきである - 私たちは現在、理解輻輳制御のフォームに必要な制約 - 主な制限は、データストリームが連続しており、長く住んでいたということです。このレビューの目的は、一緒にフィールドの概要を収集し、特定のメカニズムによって課される明示的な制約を作ることです。目的は、プロトコルとプロトコル・ビルディング・ブロックのための標準化プロセスへのガイダンスを提供することです。これを行うには、我々は緩いカテゴリの数に潜在的な解決策をクラスタ化 - 実際のプロトコルは、これらのクラスタの複数のメカニズムで構成されてもよいです。
The main constraint on solutions is imposed by the need to scale to large receiver sets. For small receiver sets the design space is much less restricted.
ソリューションの主な制約は、大きなレシーバセットに拡張する必要性によって課されます。小さな受信機の設計空間はあまり制限されている設定します。
Application requirements for reliable multicast (RM) are as broad and varied as the applications themselves. However, there are a set of requirements that significantly affect the design of an RM protocol. A brief list includes:
信頼性の高いマルチキャスト（RM）のアプリケーション要件は、アプリケーション自体のように広範かつ多様です。しかし、大幅にRMプロトコルの設計に影響を与える要件のセットがあります。簡単なリストが含まれています：
o Does the application need to know that everyone received the data?
oはアプリケーションは、誰もがデータを受け取ったことを知っておく必要がありますか？
o Does the application need to constrain differences between receivers?
Oアプリケーションは、受信機の違いを制約する必要がありますか？
o Does the application need to scale to large numbers of receivers?
Oアプリケーションは、受信機の多くに拡張する必要がありますか？
o Does the application need to be totally reliable?
Oアプリケーションは完全に信頼できる必要がありますか？
o Does the application need ordered data?
oは、データをアプリケーションのニーズ注文していますか？
o Does the application need to provide low-delay delivery?
oはアプリケーションでは、低遅延の配信を提供する必要がありますか？
o Does the application need to provide time-bounded delivery?
oはアプリケーションが時間制限送達を提供する必要がありますか？
o Does the application need many interacting senders?
oは、多くの相互作用の送信者がアプリケーション必要がありますか？
o Is the application data flow intermittent?
oは、アプリケーションデータが断続的に流れますか？
o Does the application need to work in the public Internet?
Oアプリケーションは、公共のインターネットで作業する必要がありますか？
o Does the application need to work without a return path (e.g. satellite)?
oはアプリケーションがリターンパス（例えば衛星）せずに作業する必要がありますか？
o Does the application need to provide secure delivery?
Oアプリケーションは、安全な送達を提供する必要がありますか？
In the context of standardizing bulk data transfer protocols, we can rule out applications with multiple interacting senders and intermittent data flows. It is not that these applications are unimportant, but that we do not yet have effective congestion control for such applications.
バルクデータ転送プロトコルを標準化の文脈において、我々は、複数の相互作用の送信者と間欠データフローを持つアプリケーションを除外することができます。これは、これらのアプリケーションは重要でないということではありませんが、我々はまだそのようなアプリケーションのための効果的な輻輳制御を持っていないこと。
In many applications a logically defined unit or units of data is to be delivered to multiple clients, e.g., a file or a set of files, a software package, a stock quote or package of stock quotes, an event notification, a set of slides, a frame or block from a video. An application data unit (ADU) is defined to be a logically separable unit of data that is useful to the application. In some cases, an application data unit may be short enough to fit into a single packet (e.g., an event notification or a stock quote), whereas in other cases an application data unit may be much longer than a packet (e.g., a software package).
多くのアプリケーションでは、論理的に定義されたユニットまたはデータの単位は、例えば、複数のクライアントに配信されるファイルまたはファイルのセット、ソフトウェアパッケージ、株価の株価やパッケージ、イベント通知、スライドのセットですビデオから、フレームまたはブロック。アプリケーション・データ・ユニット（ADU）は、アプリケーションに有用であり、データの論理的に分離可能なユニットであると定義されます。他のケースではアプリケーションデータユニットは、はるかに長いパケット（例えば、ソフトウェアよりも場合があるいくつかのケースでは、アプリケーションデータユニットは、（例えば、イベント通知や株価）単一のパケットに収まるほど短くてもよいですパッケージ）。
A protocol may optionally provide delivery confirmation to ensure reliable delivery, i.e., a mechanism for receivers to inform the sender when data has been delivered. There are two types of confirmation, at the application data unit level and at the packet level. Application data unit confirmation is useful at the application level, e.g., to inform the application about receiver progress and to decide when to stop sending packets about a particular application data unit. Packet confirmation is useful at the transport level, e.g., to inform the transport level when it can release buffer space being used for storing packets for which delivery has been confirmed.
プロトコルは、必要に応じて、すなわち、信頼できる配信を保証するために、データが配信されたときに受信機が送信者に通知するためのメカニズムを配信確認を提供してもよいです。確認には2つのタイプがアプリケーションデータ単位レベルで、パケットレベルで、あります。アプリケーション・データ・ユニットの確認は、例えば、受信機進捗についてアプリケーションに通知すると、特定のアプリケーション・データ・ユニットについてのパケットの送信を停止するタイミングを決定するために、アプリケーションレベルで有用です。パケット確認は、配信が確認されたパケットを格納するために使用されるバッファ・スペースを解放することができる場合にトランスポート・レベルを知らせるために、例えば、トランスポート・レベルで有用です。
Some applications have a strong requirement for confirmation that all the receivers got an ADU, or if not, to be informed of which specific receivers failed to receive the entire ADU. Examples include applications where receivers pay for data, and reliable file-system replication. Other applications do not have such a requirement. An example is the distribution of free software.
一部のアプリケーションでは、すべての受信機がADUを得た、またはされていない場合、特定の受信機が全体ADUを受け取るために失敗したが通知されるように、確認のための強力な要件を持っています。例としては、受信機がデータを支払うアプリケーション、および信頼性の高いファイル・システムの複製が含まれます。他のアプリケーションは、このような要件はありません。例では、フリーソフトウェアの配布です。
If the application does need to know that every receiver got the ADU, then a positive acknowledgment must be received from every receiver, although it may be possible to aggregate these acknowledgments. If the application needs to know precisely which receivers failed to get the ADU, additional constraints are placed on acknowledgment aggregation.
アプリケーションは、すべての受信機がADUを得たことを知っておく必要がない場合は、これらの確認応答を集約することは可能かもしれないが、その後、肯定応答は、すべての受信機から受信されなければなりません。アプリケーションは、受信機がADUを取得するために失敗した正確に知る必要がある場合、追加的な制約が承認集約の上に置かれています。
It should be noted that different mechanisms can be used for ADU-level confirmation and packet-level confirmation in the same application. For example, an ADU-level confirmation mechanism using positive acknowledgments may sit on top of a packet-level NACK or FEC-based transport. Typically this only makes sense when ADUs are significantly larger than a single packet.
異なるメカニズムが同じアプリケーション内ADUレベルの確認とパケットレベルの確認のために使用することができることに留意すべきです。例えば、肯定応答を使用してADUレベル確認機構は、パケットレベルのNACK又はFECベースのトランスポートの上に座ることができます。 ADUが単一のパケットよりも有意に大きい場合、通常、これはのみ意味があります。
Some applications need to constrain differences between receivers so that the data reception characteristics for all receivers falls within some range. An example is a stock price feed, where it is unacceptable for a receiver to suffer delivery that is delayed significantly more than any other receiver.
一部のアプリケーションでは、すべての受信機のデータ受信特性がある範囲内に収まるように受信機の間の違いを制約する必要があります。例では、受信機は、他の受信機よりも大幅に遅れているの配信を受けすることは受け入れられない株価フィード、です。
This requirement is difficult to satisfy without harming performance. Typically solutions involve not sending more than a limited amount of new data until positive acknowledgments have been received from all the receivers. Such a solution does not cope with network and end-system failures well.
この要件は、パフォーマンスを損なうことなく満足させることは困難です。通常のソリューションは、肯定応答は、すべての受信機から受信されるまで、新たなデータの限られた量よりも多くを送信しない伴います。このような溶液を十分にネットワークとエンドシステム障害に対応しておりません。
There are many applications for RM that do not need to scale to large numbers of receivers. For such applications, a range of solutions may be available that are not available for applications where scaling to large receiver sets is a requirement.
受信機の多くに拡張する必要はありませんRMのための多くのアプリケーションがあります。このような用途のために、ソリューションの範囲が大きい受信機セットへのスケーリングが要求される用途では使用できませんが利用可能であってもよいです。
A protocol must achieve good throughput of application data units to receivers. This means that most data that is delivered to receivers is useful in recovering the application data unit that they are trying to receive. A protocol must also provide good congestion control to fairly share the available network resources between all applications. Receiver set scaling is one of the most important constraints in meeting these requirements, because it strictly limits the mechanisms that can be used to achieve these requirements to those that will efficiently scale to a large receiver population. Acknowledgement packets have been employed by many systems to achieve these goals, but it is important to understand the strength and limitations of different ways of using such packets.
プロトコルは、受信機へのアプリケーション・データ・ユニットの優れたスループットを達成しなければなりません。これは、受信者に配信されるほとんどのデータは、彼らが受け取るしようとしているアプリケーション・データ・ユニットの回復に有用であることを意味します。また、このプロトコルは、かなりすべてのアプリケーション間で利用可能なネットワークリソースを共有するのが良い輻輳制御を提供する必要があります。それは厳密に効率的に大規模な受信機人口に拡張されますものにこれらの要件を達成するために用いることができるメカニズムを制限するための受信機セットスケーリングは、これらの要件を満たす上で最も重要な制約の1つです。謝辞パケットは、これらの目標を達成するために多くのシステムで採用されているが、そのようなパケットを使用してのさまざまな方法の強さと限界を理解することが重要です。
In a very small system, it may be acceptable to have the receivers acknowledge every packet. This approach provides the sender with the maximum amount of information about reception conditions at all the receivers, information that can be used both to achieve good throughput and to achieve congestion control.
非常に小さなシステムでは、受信機がすべてのパケットを認める持つように許容され得ます。このアプローチは、良好なスループットを達成し、輻輳制御を達成するために両方を使用することができる全ての受信、情報の受信状態に関する情報の最大量を持つ送信者に提供します。
For larger systems, such "flat ACK" schemes cause acknowledge implosions at the sender. Attempts have been made to reduce this problem by sending aggregate ACKs infrequently [RMWT98, BC94], but it is very difficult to incorporate effective congestion control into such protocols because of the spareceness of feedback.
大規模システムでは、そのような「フラットACK」スキームは、送信側で内破を確認起こします。試みは[RMWT98、BC94]まれに集約ACKを送信することによって、この問題を軽減する試みがなされてきたが、なぜならフィードバックのsparecenessのようなプロトコルに効果的な輻輳制御を組み込むことは非常に困難です。
Using negative acknowledgments (NACKs) instead of ACKs reduces this problem to one of NACK implosion (only from the receivers missing the packets), and because the sender really only needs to know that at least one receiver is missing data in order to achieve good throughput, various NACK suppression mechanisms can be applied.
代わりに、ACKの否定応答（NACKを）使用すると、NACK爆縮の一つに、この問題を軽減（パケットのみを未送信の受信から）、および送信者が実際には、少なくとも一つの受信機が良いスループットを達成するために、データが欠落していることを知っておく必要があるため、種々NACK抑制メカニズムを適用することができます。
An alternative to NACKs is ACK aggregation, which can be done by arranging the receivers into a logical tree, so that each leaf sends ACKs to its parent which aggregates them, and passes them on up the tree. Tree-based protocols scale well, but tree formation can be problematic.
NACKの代わりに、各リーフがそれらを集約し、その親にACKを送信し、ツリーまでそれらを通過するように、論理ツリーに受信機を配置することによって行うことができACK集約、です。ツリーベースのプロトコルは十分にスケーリングが、木の形成が問題となる可能性があります。
Other ACK topologies such as rings are also possible, but are often more difficult to form and maintain than trees are. An alternative strategy is to add mechanisms to routers so that they can help out in achieving good throughput or in reducing the cost of achieving good throughput.
このような環などの他のACKトポロジーも可能ですが、多くの場合、形成し、木があるよりも、維持することがより困難です。代替戦略は、彼らは良いスループットを達成するためにか、良いスループットを達成するためのコストを削減して助けることができるように、ルータにメカニズムを追加することです。
All these solutions improve receiver set scaling, but they all have limits of one form or another. One class of solutions scales to an infinite number of receivers by having no feedback channel whatsoever in order to achieve good throughput. These open-loop solutions take the initial data and encode it using an FEC-style mechanism. This encoded data is transmitted in a continuous stream. Receivers then join the session and receive packets until they have sufficient packets to decode the original data, at which point they leave the session.
すべてのこれらのソリューションは、受信機のセットのスケーリングを向上させる、それらはすべて一つの形態または別の制限があります。解決策の1つのクラスは良いスループットを達成するために、一切のフィードバックチャネルを持たないことにより、受信機の数が無限に拡張できます。これらの開ループソリューションは、初期データを取得し、FECスタイルのメカニズムを使用して、それをコードします。この符号化されたデータは、連続ストリームで送信されます。レシーバは、セッションに参加し、彼らがセッションを離れた時点で、元のデータをデコードするのに十分なパケットを持つまで、パケットを受信します。
Thus, it is clear that the intended scale of the session constrains the possible solutions. All solutions will work for very small sessions, but as the intended receive set increases, the range of possible solutions that can be deployed safely decreases.
したがって、セッションの意図したスケールが可能な解決策を制約することは明らかです。すべてのソリューションは、非常に小さなセッションのために動作しますが、意図した設定増加を受けて、展開することができる可能な解決策の範囲が安全に減少しています。
It should also be noted that hybrids of these mechanisms are possible, and that using one mechanism at the packet-level and a different (typically higher overhead) solution at the ADU level may also scale reasonably if the ADUs are large compared to packets.
また、これらのメカニズムのハイブリッドが可能であること、とのADUパケットに比べて大きい場合は、1つのパケット・レベルでのメカニズムとADUレベルで異なる（典型的にはより高いオーバーヘッド）溶液を使用することも合理的にスケーリングすることができることに留意すべきです。
Many applications require delivery of application data units to be totally reliable; if any of the application data unit is missing, none of the received portion of the application data unit is useful. File transfer applications are a good example of applications requiring total reliability.
多くのアプリケーションは完全に信頼性があると、アプリケーション・データ・ユニットの配信を必要とします。アプリケーション・データ・ユニットのいずれかが欠落している場合、アプリケーション・データ・ユニットの受信部のいずれも有用ではありません。ファイル転送アプリケーションは、全体の信頼性を必要とするアプリケーションの良い例です。
However, some applications do not need total reliability. An example is audio broadcasting, where missing packets reduce the quality of the received audio but do not render it unusable. Such applications can sometimes get by without any additional reliability over native IP reliability, but often having a semi-reliable multicast protocol is desirable.
ただし、一部のアプリケーションでは、総信頼性を必要としません。例では、欠落したパケットを受信した音声の品質を低下させるが、それは使用不能にしていない音声放送、です。このようなアプリケーションは、時々、ネイティブIPの信頼性の上に任意の追加の信頼性なしで取得するが、多くの場合、半信頼性マルチキャストプロトコルを持つことが望ましいことができます。
Many applications just require data to be delivered to the receivers as fast as possible. They have no absolute deadline for delivery.
多くのアプリケーションでは、単にできるだけ速く受信機に配信するデータを必要とします。彼らは、配信のための絶対的な期限を持っていません。
However, some applications have hard delivery constraints - if the data does not arrive at the receiver by a certain time, there is no point in delivering it at all. Such time-boundedness may be as a result of real-time constraints such as with audio or video streaming, or as the result of new data superseding old data. In both cases, the requirement is for the application to have a greater degree of control over precisely what the application sends at which time than might be required with applications such as file transfer.
ただし、一部のアプリケーションは、ハード配信制約を持っている - データが一定の時間で受信機に到着しない場合は、すべてでそれを提供しても意味がありません。このような時間有界は、オーディオやビデオストリーミングのように、または古いデータに取って代わる、新たなデータの結果として、リアルタイム制約の結果であってもよいです。アプリケーションは、アプリケーションがファイル転送などのアプリケーションで必要となる場合がありますよりも、その時点で送信し、正確に何を制御の大きな度合いを持っているため、両方のケースでは、要件があります。
Time-bounded delivery usually also implies a semi-reliable protocol, but the converse does not necessarily hold.
時間制限の配信は、通常、半信頼性の高いプロトコルを意味しますが、その逆は必ずしも成り立ちません。
The properties of the network in which the application is being deployed may themselves constrain the reliable multicast design space.
アプリケーションが配備されているネットワークの性質自体が信頼できるマルチキャストデザインスペースを制約することがあります。
In principle the Internet and intranets are the same. In practice however, the fact that an intranet is under one administration might allow for solutions to be configured that can not easily be done in the public Internet. Thus, if the data is of very high value, it might be appropriate to enhance the routers to provide assistance to a reliable multicast transport protocol. In the public Internet, it is less likely that the additional expense required to support this state in the routers would be acceptable.
原則的には、インターネットやイントラネットは同じです。しかし実際には、イントラネットが1人の管理下にあるという事実は簡単に公共のインターネットで行うことができないように構成するソリューションを可能にすることがあります。データは非常に高い値であればこのように、信頼性の高いマルチキャストトランスポートプロトコルへの支援を提供するために、ルータを強化するために適切な場合があります。公共のインターネットでは、ルータで、この状態をサポートするために必要な追加費用が許容可能である可能性は低いです。
In principle, when feedback is required from receivers, this feedback can be multicast or unicast. Multicast feedback has advantages, especially in NACK-based protocols where it is valuable for NACK suppression. However, it is not clear at this time whether all ISPs will allow all members of a session to send to that session. If multicast feedback is not allowed, then unicast feedback can almost always be substituted, although often at the expense of additional messages and mechanisms.
原理的には、フィードバックを受信機から要求された場合、このフィードバックは、マルチキャストまたはユニキャストすることができます。マルチキャストフィードバックは、特にそれがNACK抑制のために有用であるNACKベースのプロトコルで、利点を有します。しかし、すべてのISPは、セッションのすべてのメンバーがそのセッションに送信することを可能にするかどうか現時点では明らかではありません。マルチキャストフィードバックが許可されていない場合は、ユニキャストのフィードバックは、ほとんどの場合、追加のメッセージとメカニズムを犠牲にしているが、多くの場合、置換することができます。
Some networks may not allow any form of feedback however. The primary example of this occurs with satellite broadcasts where the back channel may be very narrow or even non-existent. For such networks the solution space is very constrained - only FEC-based encodings have any real chance of working. If the receivers are direct satellite receivers, then no congestion control is needed, but it is dangerous to make such assumptions because it is possible for a satellite hop to feed downstream networks. Thus, congestion control still needs to be considered with solutions that do not have a return path.
ネットワークによっては、しかし、フィードバックの任意のフォームを許可しない場合があります。これの主な例は、バックチャネルが非常に狭く、あるいは存在しないかもしれ衛星放送で発生します。解空間が非常に制約されているようなネットワークのために - 唯一のFECベースのエンコーディングは、作業の任意の本当のチャンスを持っています。受信機は、直接衛星受信機である場合、輻輳制御は必要ありませんが、衛星ホップが下流のネットワークを養うすることが可能であるため、そのような仮定をするのは危険です。このように、輻輳制御は、まだリターンパスを持っていないソリューションを検討する必要があります。
A reliable multicast protocol must involve mechanisms running in end hosts, and must involve routers forwarding multicast packets. However under some circumstances, it is possible to rely on some additional degree of assistance from network elements. Broadly speaking we can cluster RM protocols into four classes depending on the degree of support received from other network elements.
信頼できるマルチキャストプロトコルは、エンドホストで実行されているメカニズムを含む必要があり、マルチキャストパケットを転送するルータを含む必要があります。しかし、いくつかの状況下では、ネットワーク要素からの支援のいくつかの追加の程度に依存することが可能です。大まかに私たちは、他のネットワーク要素から受信した支援の程度に応じて4つのクラスにRMプロトコルをクラスタ化することができます話します。
No Additional Support The routers merely forward packets, and only the sender and receivers have any reliable multicast protocol state.
その他のサポートしないルータ単にパケットを転送んが、唯一の送信者と受信者は、任意の信頼できるマルチキャストプロトコルの状態を持っています。
Layered Approaches Data is split across multiple multicast groups. Receivers join appropriate groups to receive only the traffic they require. This may in some cases require fast join or leave functionality from the routers, and may require more forwarding state in the routers.
階層化は、データが複数のマルチキャストグループに分割されアプローチ。レシーバは、彼らが必要とするトラフィックだけを受信するために適切なグループに参加します。これは、いくつかのケースで必要と速く参加したり、残して機能をルータから、ルータでより多くの転送状態を必要とする場合があります。
Server-based Approaches Additional nodes are used to assist with data delivery or feedback aggregation. These additional nodes might not be normal senders or receivers, and may be present on the distribution or feedback tree only to provide assistance to the reliable multicast protocol. They would not otherwise receive the multicast traffic.
サーバーベースのアプローチの追加のノードは、データ配信やフィードバックの集約を支援するために使用されています。これらの追加ノードは、通常の送信者または受信できない場合があり、そして唯一の信頼できるマルチキャストプロトコルへの支援を提供するために配布またはフィードバックツリー上に存在してもよいです。彼らは、そうでない場合は、マルチキャストトラフィックを受信しません。
Router-based Approaches With router-based approaches, routers on the normal data distribution tree from the sender to the receivers assist in the delivery of data or feedback aggregation or suppression. As routers can directly influence multicast routing, they have more control over which traffic goes to which group members than server-based approaches. However routers do not normally have a large amount of spare memory or processing power, which restricts how much functionality can be placed in the routers. In addition, router code is normally more difficult to upgrade than application code, so router-based approaches need to be very general as they are more difficult to deploy and to change.
ルータ・ベースのアプローチとルータベースのアプローチは、受信機への送信者からの通常のデータ配信ツリー上のルータは、データまたはフィードバック凝集または抑制の送達を助けます。ルータが直接マルチキャストルーティングに影響を与えることができると、彼らはより多くの制御を持っている上でトラフィックがどのに行くのサーバーベースのアプローチよりも、グループのメンバー。しかし、ルータは通常のルータに配置することができますどのくらいの機能が制限され、スペアメモリや処理能力を大量に持っていません。また、ルータのコードは、アプリケーションのコードよりもアップグレードして、通常より困難であるので、彼らが展開すると変更することがより困難にしているとして、ルータベースのアプローチは非常に一般的である必要があります。
Two main concerns that a RM protocol must address are congestion control and good throughput. Packet loss plays a major role with respect to both concerns. The primary symptom of congestion in many networks is packet loss. The primary obstacle that must be overcome to achieve good throughput is packet loss. Thus, measuring and reacting to packet loss is crucial to address both concerns. RM solutions that address these concerns can be roughly categorized as using one or more of the following techniques:
RMプロトコルが対処しなければならない2つの主な懸念は、輻輳制御と良いスループットです。パケット損失は、両方の問題に関して大きな役割を果たしています。多くのネットワークの輻輳の主な症状は、パケット損失です。優れたスループットを達成するために克服しなければならない主要な障害は、パケット損失です。このように、測定し、パケットロスに反応させて、両方の懸念に対処することが重要です。これらの懸念に対処するRMソリューションは、大きく以下の技術のうちの1つ以上を使用してのように分類することができます。
o Data packet acknowledgment.
Oデータパケットの確認応答。
o Negative acknowledgment of missing data packets.
データパケットの欠落のO否定応答。
o Redundancy allowing not all packets to be received.
O冗長性が許可していないすべてのパケットが受信されます。
These techniques themselves can be usefully subdivided, so that we can examine the parts of the requirement space in which each mechanism can be deployed. In this section, we focus on using these mechanisms for achieving good throughput, and in the next section we focus on using these mechanisms for congestion control.
私たちは各機構を配備することができる要件スペースの一部を調べることができるように、これらの技術自体は有効に、細分化することができます。このセクションでは、我々は良いスループットを達成するためにこれらのメカニズムを使用することに焦点を当て、そして次のセクションでは、我々は、輻輳制御のためにこれらのメカニズムを使用することに焦点を当てます。
The simplest ACK-based mechanism involves every receiver sending an ACK packet for every data packet it receives and resending packets that are lost by any receiver. Such mechanisms are limited to very small receiver groups by the implosion of ACKs received at the sender, and for this reason they are impractical for most applications.
最も単純なACKベースのメカニズムは、すべての受信機が受信したすべてのデータパケットに対するACKパケットを送信し、任意の受信機によって失われたパケットを再送信することを含みます。このようなメカニズムはACKの爆縮によって非常に小さな受信機のグループに限定されている送信者で受信し、そしてこの理由のために、彼らはほとんどのアプリケーションには実用的でありません。
Putting multiple ACKs into a single data packet [RMWT98] reduces the implosion problem by a constant amount, allowing slightly larger receiver groups. However a limit is soon reached whereby feedback to the sender is too infrequent for sender-based congestion control mechanisms to work reliably.
単一のデータ・パケットに複数のACKを置くこと[RMWT98]若干大きいレシーバグループを可能に、一定量爆縮の問題を減少させます。送信元ベースの輻輳制御メカニズムが確実に動作するために、送信者へのフィードバックが非常にまれであることにより、ただし制限がすぐに達しています。
Arranging the receivers into a ring [WKM94] whereby an "ACK-token" is passed around the ring prevents the implosion problem for data. However ring creation and maintenance may itself be problematic. Also if ring creation does not take into account network topology (something which is difficult to achieve in practice), then the number of ACK packets crossing the network backbone for each data packet sent may increase O(n) with the number of receivers.
【WKM94「ACKトークン」は環の周囲を通過させるリングに受信機を配置することは、データのための爆縮の問題を防止します。しかし、リングの作成とメンテナンス自体が問題となる可能性があります。リングの作成がアカウントのネットワークトポロジ（実際に達成することは困難である何か）に入れていない場合も、その後、送られた各データパケットのためのネットワークバックボーンを横断するACKパケットの数は、受信機の数をO（n）を増加させてもよいです。
Arranging the receivers into a tree [MWB+98, KCW98] whereby receivers generate ACKs to a parent node, which aggregates those ACKs to its parent in turn, is both more robust and more easily configured than a ring. The ACK-tree is typically only used for ACK-aggregation - data packets are multicast from the sender to the receivers as normal. Trees are easier to construct than rings because more local information can be used in their construction. Also they can be more fault tolerant than rings because node failures only affect a subset of receivers, each of which can easily and locally decide to by-pass its parent and report directly to the node one level higher in the tree. With good ACK-tree formation, tree-based ACK mechanisms have the potential to be one of the most scalable RM solutions.
ツリーに受信機を配置する[MWB + 98、KCW98]は受信機が順番に親にそれらのACKを集約親ノードにACKを生成することにより、両方のより堅牢でより容易に構成されたリングよりなります。 ACKツリーは、典型的にのみACK凝集のために使用される - データパケットは通常通り受信機に送信者からマルチキャストです。より多くの地元の情報がその構築に使用することができますので、木はリングよりも構築が容易です。ノードの障害だけ簡単に、ローカルツリーの上位ノード1のレベルに直接その親との報告を渡すことにより、-に決めることができ、それぞれが、受信機のサブセットに影響を与えるため、また、彼らはリングよりもフォールトトレラントすることができます。良いACK-木の形成と、ツリーベースのACKメカニズムは、最もスケーラブルなRMソリューションの1つになる可能性があります。
To be simple to deploy, tree-based protocols must be self-organizing - the receivers must form the tree themselves using local information in a scalable manner. Such mechanisms are possible, but are not trivial. The main scaling limitations of tree-based protocols therefore come from the tree formation and maintenance mechanisms rather than from the use of ACKs. Without such a scalable and automatic tree-formation mechanism, tree-based protocols must rely on manual configuration, which significantly limits their applicability (often to intranets) and (due to the complexity of configuration) their scalability.
導入が簡単であるために、ツリーベースのプロトコルは、自己組織化でなければならない - 受信機は、スケーラブルな方法で地域情報を使用して自分自身をツリーを形成しなければなりません。このようなメカニズムは可能ですが、些細ではありません。ツリーベースのプロトコルの主なスケーリングの制限は、したがって、ツリーの形成および維持機構からではなく、ACKの使用から来ます。そのようなスケーラブルな自動ツリー生成機構なしで、ツリーベースのプロトコルは、有意に（多くの場合、イントラネット）及びそれらのスケーラビリティ（による構成の複雑さのために）それらの適用を制限する手動の構成に依存しなければなりません。
Orthogonal to the issue of tree formation is the issue of subtree retransmission. With appropriate router mechanisms, or the use of multiple multicast groups, it is possible to allow the intermediate tree nodes to retransmit missing data to the nodes below them in the tree rather than relying on the original sender to retransmit the data. This relies on there being a good correlation at the point of the intermediate node between the ACK tree and the actual data tree, as well as there being a mechanism to constrain the retransmission to the subtree. A good automatic tree formation mechanism combined with the use of administrative scoped multicast groups might provide such a solution. Without such tree formation mechanisms, subtree retransmission is difficult to deploy in large groups in the public internet. This could also be solved by the use of transport-level router mechanisms to assist or perform retransmission, although existing router mechanisms [FLST98] support NACK-based rather than ACK-based protocols.
木の形成の問題に直交するサブツリー再送の問題です。適切なルータメカニズム、または複数のマルチキャストグループを使用して、中間ツリーノードがツリーではなく、データを再送するために元の送信者に頼ってその下のノードに失われたデータを再送信させることができます。これはACKツリーと実際のデータツリーとの間の中間ノードの点で良好な相関であること、ならびにサブツリーに再送を制限するためのメカニズムが存在することが依存しています。管理スコープマルチキャストグループの使用と組み合わせ良い自動ツリー生成機構は、そのような解決策を提供するかもしれません。このようなツリー形成メカニズムがなければ、サブツリーの再送信は、公共のインターネットで大規模なグループに展開することは困難です。既存のルータのメカニズムが[FLST98]むしろACKベースのプロトコルよりもNACKベースのサポートが、これはまた、アシスト又は再送を実行するトランスポート・レベル・ルータ・メカニズムを使用することによって解決することができます。
Another important issue is the nature of the aggregation performed at interior nodes on the ACK-tree. Such nodes could:
もう一つの重要な問題は、ACK-ツリーの内部ノードで実行凝集の性質です。このようなノードができます。
1. aggregate ACKs by sending a single ACK when all their children have ACKed,
すべての子供たちがACKされていたときに、単一のACKを送信することにより、1.集計ACKを、
For data packets, 1. is clearly more scalable, and should be preferred. However if the sender needs to know exactly which receivers received the data, 2. and 3. provide this information. Fortunately, there is usually no need to do this on a per-packet basis, but rather on a per-ADU basis. Doing 1. on a per packet basis, and 3. on a per ADU basis is the most scalable solution for applications that need this information, and suffers virtually no disadvantage compared to the other solutions used on a per-packet basis.
データパケットの場合、1は明らかに、よりスケーラブルであり、好ましいする必要があります。送信者は受信機がデータを受信し、正確に知っている必要がある場合は、2と3は、この情報を提供します。幸いなことに、パケット単位ではなく、むしろあたり-ADUベースでこれを実行する必要は通常ありません。 ADUごとにパケットごとに1、および3を実行すると、この情報を必要とするアプリケーションのための最もスケーラブルなソリューションであり、パケット単位で使用される他のソリューションに比べて実質的には不利益を被ります。
Instead of sending an ACK for every data packet received, receivers can send a negative acknowledgment (NACK) for every data packet they discover they did not receive. This has a number of advantages over ACK-based mechanisms:
代わりに、すべてのデータパケットを受信するためにACKを送信する、受信機は、彼らが受け取っていない発見し、すべてのデータパケットの否定応答（NACK）を送信することができます。これは、ACKベースのメカニズムを超える多くの利点を有します。
o The sender no longer needs to know exactly how many receivers there are. This removes the topology-building phase needed for ring- or tree-style ACK-based algorithms.
O送信者は、もはや存在している正確にどのように多くの受信機を知っている必要はありません。これは、リング - またはツリースタイルのACKベースのアルゴリズムのために必要なトポロジー構築フェーズを削除します。
o Fault-tolerance is made somewhat simpler by making receivers responsible for reliability.
Oフォールトトレランスは、信頼性の責任受信機を作ることによって、やや簡単になります。
o Sender state can be significantly reduced because the sender does not need to keep track of the receivers state.
送信者が受信機の状態を追跡する必要がないため、O送信者の状態を大幅に低減することができます。
o Only a single NACK is needed from any receiver to indicate a packet that is missing by any number of receivers. Thus NACK suppression is possible.
OつだけNACKは受信機の任意の数で不足しているパケットを示すために、任意の受信機から必要とされています。したがって、NACK抑制が可能です。
The disadvantages are that it is more difficult for the sender to know that it can free transmission buffers, and that additional session level mechanisms are needed if the sender really needs to know if a particular receiver actually received all the data. However for many applications, neither of these is an issue.
欠点は、それが送信バッファを解放し、送信者が本当に特定の受信機は、実際にすべてのデータを受信しているかどうかを知る必要がある場合、追加のセッションレベルのメカニズムが必要であることができることを知って、送信者のために、より困難であることです。しかし、多くの用途のために、これらのいずれも問題です。
The key differences between NACK-based protocols is in how NACK-suppression is performed. The goal is for only one NACK to reach the sender (or a node that can resend the missing data) as soon as possible after the loss is first noticed, and for only one copy of the missing data to be received by those nodes needing retransmission.
NACKベースのプロトコルの主な違いは、NACK-抑制がどのように行われるかです。目標は一つだけNACKができるだけ早く損失が最初に注目された後、送信者（または欠落したデータを再送することができますノード）に到達すると、失われたデータの唯一のコピーのための再送信を必要とするこれらのノードが受信するためのものです。
Different mechanisms come close to satisfying these goals in different ways.
異なるメカニズムはさまざまな方法でこれらの目標を満たすことに近づきます。
o SRM [FJM95] uses random timers weighted by the round trip time between the sender and each node missing the data. This is effective, but requires computing the RTT to each receiver before suppression works properly.
O SRM [FJM95]送信者とデータの欠落、各ノード間の往復時間で重み付けランダムタイマーを使用しています。これは有効であるが、抑制が正常に動作する前に、各受信機にRTTを計算する必要があります。
o NTE [HC97] uses a sender-triggered mechanism based on random keys and sliding masks. This does not require random timers, and works for very large sessions, but makes it difficult to provide the constant low-level stream of feedback needed to perform congestion control.
O NTE [HC97]はランダムキーと摺動マスクに基づいて送信者トリガ機構を使用します。これは、ランダムなタイマーを必要とし、非常に大きなセッションのために動作しますが、それが困難な輻輳制御を実行するために必要なフィードバックの一定の低レベルのストリームを提供することができるものではありません。
o AAP [Ha99] uses exponentially distributed random timers and is effective for large sessions without needing to compute the RTT to each receiver.
O AAPは[Ha99】指数分布ランダムタイマを使用し、各受信機にRTTを計算することなく、大きなセッションのために有効です。
o PGM [FLST98] and LMS [PPV98] use additional mechanisms in routers to suppress duplicate NACKs. In the case of PGM, router assistance suppliments SRM-stype random timers and localizes the suppression so that the whole group does not need suppressing.
O PGM [FLST98]とLMSは、[PPV98]重複NACKを抑制するためにルータに追加のメカニズムを使用します。 PGMの場合は、ルータの援助はSRM-STYPEランダムタイマーをsupplimentsし、グループ全体が抑制必要がないように抑制することが局在化します。
The most general of these mechanisms is probably exponentially weighted random timers. Although SRM style timers can reduce feedback delay, they are harder to use correctly in situations where all the RTTs are not known, or where the number of respondees is unknown. In contrast, exponentially weighted random timers work well across a large range of session sizes with good worst case delay characteristics.
これらのメカニズムの中で最も一般的には、おそらく指数関数的に重み付けランダムタイマーです。 SRMスタイルタイマーがフィードバック遅延を減らすことができますが、それらはすべてのRTTが知られていない状況で、正しく使用が困難であるか、あるいはrespondeesの数は不明です。これとは対照的に、指数関数的に重み付けランダムタイマーが良い最悪の場合の遅延特性とのセッションサイズの大きな範囲でうまく動作します。
Either form of random timer based mechanism can be supplemented by router-support where it is available. Sender triggered NACK mechanisms (e.g. [HC97]) are more difficult to integrate with router-based support mechanisms.
ランダムタイマーベースのメカニズムのいずれかの形式は、それが利用可能であるルータのサポートによって補完することができます。送信者がNACKメカニズムをトリガー（例えば[HC97]）ルータベース支持機構と統合することがより困難です。
Some RM protocols can be designed so as to not need explicit reliability mechanisms except in comparatively rare cases. An example is in a multicast game, where the position of a moving object is continuously multicast. This positional stream does not require additional reliability because a new position superseding the old one will be sent before any retransmission could take place. However, when the moving object interacts with other objects or stops moving, then an explicit reliability mechanism is required to reliably send the interaction information or last position.
比較的まれなケースを除いて、明示的な信頼性のメカニズムを必要としないようにいくつかのRMプロトコルを設計することができます。例では、移動体の位置を連続的にマルチキャストされるマルチキャストゲーム、です。古いものに取って代わる新しい位置が起こり得る任意の再送信前に送信されますので、この位置ストリームは、追加的な信頼性を必要としません。移動オブジェクトが他のオブジェクトと相互作用又は移動停止した場合しかし、明示的な信頼性機構を確実に対話情報または最後の位置を送信する必要があります。
It is not just games that can be built in this manner - the NTE shared text editor[HC97] uses just such a mechanism with changes to a line of text. For every change the whole line is sent, and so long as the user keeps typing no explicit reliability mechanism is needed. The major advantage of replication is that it is not susceptible to spatially uncorrelated packet loss. With a traditional ACK or NACK based protocol, the probability of any particular packet being received by all the receivers in a large group can be very low. This leads to high retransmission rates. In contrast, replicated streams do not suffer as the size of the receiver group increases - different receivers lose different packets, but this does not increase network traffic.
それは、このように構築することができるだけのゲームではありません - NTE共有テキストエディタ[HC97]は、テキストの行への変更とちょうどそのようなメカニズムを使用しています。すべてのために行全体が送信され、ユーザーが明示的な信頼性メカニズムが必要とされていない入力を続ける限り、される変更。複製の主な利点は、それが空間的に相関しないパケットロスの影響を受けないということです。従来のACK又はNACKベースのプロトコルを用いて、大規模なグループ内のすべての受信機によって受信される任意の特定のパケットの確率が非常に低くすることができます。これは、高再送率につながります。異なる受信機が異なるパケットを失うが、これは、ネットワークトラフィックを増加させない - これとは対照的に、複製されたストリームは、受信グループのサイズが大きくなると苦しむことはありません。
Forward Error Correction (FEC) is a well known technique for protecting data against corruption. For reliable multicast it is most useful in the form of erasure codes.
前方誤り訂正（FEC）は、腐敗データを保護するための周知の技術です。信頼性の高いマルチキャストの場合には、消去コードの形で最も有用です。
The simplest form of packet-level FEC is to take a group of packets that is to be sent, and to XOR the packets together to form a newpacket which is also sent. If there were three original packets plus the XOR packet sent, then if a receiver is missing any one of the original data packets, but receives the XOR packet, then it can reproduce the missing original packet.
パケットレベルのFECの最も単純な形態は、送信されるパケットのグループを取るために、また、送信されるnewpacketを形成するために一緒にパケットをXORすることです。 3元のパケットプラスXORパケット送信さがあった場合は、受信機が、元のデータパケットのいずれかが欠けますが、XORパケットを受信した場合、その後、それが欠落している元のパケットを再生することができます。
More general erasure codes exist [BKKKLZ95], [Ri97], [LMSSS97] that allow the generation of n encoding packets from k original data packets. In such cases, so long as at least k of the n encoding packets are received, then the k original data packets can be reproduced.
より一般的な消去符号は、k個のオリジナルデータパケットからn個の符号化パケットの生成を可能にする[LMSSS97]、[Ri97]、[BKKKLZ95]存在します。このような場合には、n個の符号化パケットの限り、少なくともkは、その後、K元のデータパケットを再生することができ、受信されます。
To apply FEC the sender groups data packets into rounds, and encoding packets are produced based on all the data packets in a round. A round may consist of all data packets in an entire application data unit in some cases, whereas in other cases it may consist of a group of data packets that make up only a small portion of an application data unit.
ラウンド、及び符号化パケットにFEC送信者グループのデータ・パケットを適用するラウンドですべてのデータパケットに基づいて生成されます。他のケースでは、アプリケーションデータ部のわずかな部分を構成するデータ・パケットのグループから構成されてもよい一方ラウンドは、いくつかのケースでは、アプリケーション全体のデータユニット内のすべてのデータ・パケットから成ることができます。
Using erasure codes to repair packet loss is a significant improvement over simple retransmission because the dependency on which packets have been lost is removed. Thus, the amount of repair traffic required to repair spatially uncorrelated packet loss is considerably lessened.
パケットが失われているの依存関係が削除されるため、パケットロスを修復するために、消去コードを使用すると、単純な再送信を大幅に改善です。このように、空間的に相関しないパケット損失を修復するために必要な補修トラフィックの量が大幅に軽減されます。
We can divide packet-level FEC schemes into two categories: proactive FEC and reactive FEC. The difference between the two is that for proactive FEC the sender decides a priori how many encoding packets to send for each round of data packets, whereas for reactive FEC the sender initially transmits only the original data packets for each round. Then, the sender uses feedback from the receivers to compute how many packets were lost by the receiver that experienced the most loss in each round, and then only that number of additional encoding packets are sent for that round. These encoding packets will then also serve to repair loss at the other receivers that are missing fewer packets. The receivers report via ACKs or NACKs how many packets are missing from each round. With NACKs, only the receiver missing the most packets need send a NACK for this round, so this is used to weight the random timers in the NACK calculation.
積極的FECと反応FEC：我々は2つのカテゴリにパケットレベルのFECスキームを分割することができます。両者の違いは、プロアクティブFECのために、送信者は、反応FECのために、送信者は、最初に各ラウンドのためにのみ、元のデータ・パケットを送信するのに対し、多くの符号化パケットが、データパケットの各ラウンドのために送信する方法を先験的に決定することです。次に、送信者は各ラウンドで最も損失を経験した受信機によって失われた、その後、追加のエンコーディングパケットの唯一その数は、そのラウンドのために送信されますどのように多くのパケット計算するために受信機からのフィードバックを使用しています。これらの符号化パケットは、その後も、より少ないパケットが欠落している他の受信機での損失を修復するのに役立つであろう。受信機は、各ラウンドから欠落しているどのように多くのパケットのACKまたはNACKが経由して報告しています。 NACKでは、ほとんどのパケットは、このラウンドのためにNACKを送信する必要があるので、これはNACK計算におけるランダムタイマーを重み付けするために使用される唯一欠けている受信機。
Proactive and reactive FEC can be combined, e.g., a certain amount of proactive FEC can be sent for each round and if there are receivers that experience more loss than can be overcome by this for some rounds then they can request and receive additional encoding packets for these rounds.
プロアクティブと反応FECは、積極的なFECの一定量を各ラウンドのために送信することができ、いくつかのラウンドのために、このことによって克服することができる以上の損失が発生する受信機があるならば、彼らはのための追加の符号化パケットを要求し、受信することができ、例えば、組み合わせることができますこれらのラウンド。
FEC is very effective at reducing the repair traffic for packet loss. However, it requires that the data to be sent to be grouped into rounds, which can add to end-to-end latency. For bulk-data applications this is typically not a problem, but this may be an issue for interactive applications where replication may be a better solution.
FECは、パケット損失のために修理トラフィックを削減するのに非常に有効です。しかし、それはデータが、エンドツーエンドのレイテンシに追加することができますラウンド、に分類されるように送信することが必要です。バルク・データ・アプリケーションの場合、これは一般的に問題ではありませんが、これは複製がより良い解決策かもしれ対話型アプリケーションのための問題になることがあります。
An alternative use of packet level FEC is possible when data is spread across several multicast groups [RVC98], [BLMR98]. In such cases, the original k data packets are used to generate n encoding packets, where n is much larger than k. The n encoded packets are then striped across multiple multicast groups. When a receiver wishes to receive the original data it joins one or more of the multicast groups, and receives the encoding packets. Once it has received k different encoding packets, the receiver can then leave all the multicast groups and reconstruct the original data.
データは、いくつかのマルチキャストグループに分散されたときに、パケットレベルのFECの別の使用は、[BLMR98]、[RVC98]が可能です。このような場合、元のk個のデータパケットは、nはkよりもはるかに大きい場合、n個の符号化パケットを生成するために使用されます。 N個の符号化されたパケットは、複数のマルチキャストグループにわたってストライピングされます。受信機は、元のデータを受信したい場合には、マルチキャストグループの一つ以上を結合し、符号化パケットを受信します。それはK個の異なる符号化パケットを受信した後、受信機は、すべてのマルチキャストグループを離れて元のデータを再構成することができます。
The primary importance of such a layering is that it allows different receivers to be able to receive the traffic at different rates according to the available capacity. Such schemes do not require any form of feedback from the receivers to the sender to ensure good throughput, and therefore the need for good throughput does not constrain the size of the receiver set. However, to perform adequate network congestion control using receiver joins and leaves in this manner may require coordination between members that are behind the same congested link from the sender. As described in the next section, [RVC98] suggests such a layered congestion control scheme.
そのようなレイヤーの主要な重要性は、それが別の受信機が利用可能な容量に応じて異なる速度でトラフィックを受信できるようにすることができますということです。このようなスキームは、優れたスループットを確保するために、受信機から送信者へのフィードバックの任意のフォームを必要としないので、良いスループットの必要性は、受信機のセットのサイズを制限しません。しかし、参加するとこのように葉が送信者からの同じ混雑リンクの背後にあるメンバー間の調整を必要とするかもしれない受信機を使用して、適切なネットワークの輻輳制御を実行します。次のセクションで説明したように、[RVC98このような層状輻輳制御方式を提案します。
The basic delivery model of the Internet is best-effort service. No guarantees are given as to throughput, delay or packet loss. End-systems are expected to be adaptive, and to reduce their transmission rate to a level appropriate for the congestion state of the network. Although increasingly the Internet will start to support reserved bandwidth and differentiated service classes for specialist applications, unless an end-system knows explicitly that it has reserved bandwidth, it must still perform congestion control.
インターネットの基本的なデリバリー・モデルは、ベストエフォート型のサービスです。保証は、スループット、遅延やパケット損失にとして与えられていません。エンドシステムは適応すること、およびネットワークの輻輳状態のための適切なレベルに自分の伝送速度を減少させることが期待されています。ますますインターネットは、エンドシステムが明示的に帯域幅を予約したことを知っている場合を除き、専門家のアプリケーションのために予約された帯域幅と差別化されたサービスクラスをサポートするために開始しますが、それはまだ輻輳制御を実行する必要があります。
Broadly speaking, there are five classes of single-sender multicast congestion control solution:
大まかに言えば、単一の送信者のマルチキャスト輻輳制御ソリューションの5つのクラスがあります。
o Sender-controlled, one group.
O送信者制御、一つのグループ。
A single multicast group is used for data distribution. Feedback from the group members is used to control the rate of this group. The goal is to transmit at a rate dictated by the slowest receiver.
単一のマルチキャストグループは、データ配信のために使用されます。グループメンバーからのフィードバックは、このグループの速度を制御するために使用されます。目標は、最も遅い受信機によって決定されるレートで送信することです。
o Sender-controlled, multiple groups.
O送信者制御、複数のグループ。
One initial multicast group is adaptively subdivided into multiple subgroups with subdivisions centered on congestion points in the network. Application-level relays buffer data from a group nearer the original sender, and retransmit it at a slower rate into a group further from the original sender. In this way, different receivers can receiver the data at different rates. Sender-based congestion control takes place between the members of a subgroup and their relay.
一つの初期マルチキャストグループは、適応ネットワークにおける輻輳点を中心に細分化して複数のサブグループに細分されます。アプリケーションレベルのリレーは元の送信者に近いグループからのデータをバッファし、元の送信者から別の群に遅い速度でそれを再送信します。このように、異なる受信機は、異なる速度でデータを受信機することができます。送信者ベースの輻輳制御サブグループのメンバーとそのリレーの間で行われます。
o Receiver-controlled, one group.
O受信制御、一つのグループ。
A single multicast group is used for data distribution. The receivers determine if the sender is transmitting too rapidly for the current congestion state of the network, and they leave the group if this is the case.
単一のマルチキャストグループは、データ配信のために使用されます。送信者がネットワークの現在の輻輳状態のためにあまりにも急速に送信され、そしてこのような場合には、彼らがグループを離れる場合の受信機が決定します。
o Receiver-controlled, layered organization.
Oレシーバー制御、層状の組織。
A layered approach for how to combine this scheme with a congestion control protocol that requires no receiver feedback is described in [RVC98]. The sender stripes data across multiple multicast groups simultaneously. Receivers join and leave these layered groups depending on their measurements of the congestion state of the network, so that the amount of data being received is always appropriate. However, this scheme relies on receivers to join and leave the different multicast groups in a coordinated fashion behind a bottleneck link, and it has not yet been completely confirmed that this approach will scale in practice to the Internet. As a result, more work on this congestion control mechanism would be beneficial.
【RVC98]に記載されない受信機からのフィードバックを必要としない輻輳制御プロトコルを用いて、この方式を組み合わせる方法については階層化アプローチ。同時に複数のマルチキャストグループ間での送信者ストライプデータ。受信機は、参加して受信されるデータの量が常に適切であるように、ネットワークの輻輳状態のそれらの測定値に応じて、これらの層状基を残します。しかし、この方式では、ボトルネックリンクの後ろの協調で異なるマルチキャストグループに参加し、残すために受信機に依存している、まだ完全にこのアプローチがインターネットに実際に拡大することが確認されていません。その結果、この輻輳制御機構について、より多くの作業が有益であろう。
o Router-based congestion control.
Oルータベースの輻輳制御。
It is possible to add additional mechanisms to multicast routers to assist in multicast congestion control. Such mechanisms could include:
マルチキャスト輻輳制御を支援するためにマルチキャストルータに追加メカニズムを追加することが可能です。このようなメカニズムは含めることができます：
o Conditional joins (a multicast join that specifies a loss rate above which it is acceptable for the router to reject the join).
O条件は、（マルチキャストは、そのルータが参加を拒否することが許容されるその上ロス率を指定参加）加入します。
o Router filtering of traffic that exceeds a reasonable rate. This may include mechanisms for filtering traffic at different points in the network at different rates depending on local congestion conditions [LVS99].
合理的なレートを超えるトラフィックのOルータフィルタリング。これは、局所輻輳条件[LVS99]に応じて異なる速度でネットワーク内の異なる点でトラフィックをフィルタリングするためのメカニズムを含むことができます。
o Fair queuing schemes combined with end-to-end adaptation.
Oフェアは、エンドツーエンドの適応と組み合わせたスキームをキューイング。
Router-based schemes generally require more state in network routers than has traditionally been acceptable for backbone routers. Thus, in the near-term, such schemes are only likely to be applicable for intranet solutions.
ルータベースのスキームは、一般的に、伝統的バックボーンルータのために許容されているよりも、ネットワークルータでより多くの状態を必要とします。したがって、短期的には、そのような方式は、イントラネットソリューションの適用であることが唯一の可能性があります。
For reliable multicast protocols, it is important to consider congestion control at the same time as reliability is being considered. The same mechanisms that are used to provide reliability will sometimes be used to provide congestion control.
信頼性マルチキャストプロトコルのために、信頼性が検討されていると同時に、輻輳制御を考慮することが重要です。信頼性を提供するために使用されるのと同じメカニズムが時々輻輳制御を提供するために使用されます。
In the case of receiver-based congestion control, open-loop delivery using FEC is the likely choice for achieving good throughput for bulk- data transfer. This is because open-loop delivery requires no feedback from receivers, and thus it is a perfect match with a receiver-based congestion-control mechanism that operates without feedback from receivers.
レシーバベースの輻輳制御の場合には、FECを使用して開ループ送達はbulk-データ転送のための良好なスループットを達成するための可能性の高い選択です。開ループ配信が受信機からのフィードバックを必要とせず、従って、それが受信機からのフィードバックなしで動作する受信機ベースの輻輳制御機構と完全一致であるからです。
Generally speaking, security considerations have relatively little effect on constraining the design space for reliable multicast protocols. The primary issues constraining the design space are all related to receiver-set scaling. For authentication of the source and of data integrity, receiver-set scaling is not a significant issue. However, for data encryption, key distribution and particularly re-keying may be significantly affected by receiver-set scaling. Tree and graph based re-keying solutions[WHA98,WGL97] would appear to be appropriate solutions to these problems. It is not clear however that such re-keying solutions need to directly affect the design of the data distribution part of a reliable multicast protocol.
一般的に、セキュリティ上の考慮事項は、信頼性マルチキャストプロトコルの設計空間を制約上、比較的ほとんど影響を及ぼしません。設計空間を制約する主な問題は、すべてのスケーリングを設定受信機に関連しています。元のデータの整合性を認証するために、受信機セットスケーリングは重要な問題ではありません。しかし、データ暗号化、鍵配布および特に再キーイングを大幅受信機セットスケーリングによって影響を受ける可能性があります。ツリーグラフベースの再キーイングソリューション[WHA98は、WGL97]これらの問題に対する適切な解決策であるように思われます。このようなキーの再発行ソリューションは、直接信頼できるマルチキャストプロトコルのデータ配信部のデザインに影響を与える必要があることは明らかではありません。
The primary question to consider for the security of reliable multicast protocols is the role of third-parties. If nodes other than the original source of the data are allowed to send or resend data packets, then the security model for the protocol must take this into account. In particular, it must be clear whether such third parties are trusted or untrusted. A requirement for trusted third parties can make protocols difficult to deploy on the Internet.
信頼できるマルチキャストプロトコルのセキュリティのために考慮すべき主な問題は、サードパーティの役割です。データの元のソース以外のノードがデータパケットを送信または再送信が許可されている場合は、プロトコルのセキュリティモデルは、これを考慮に入れなければなりません。特に、そのような第三者が信頼できるか信頼できないされているかどうかを明確にする必要があります。信頼できるサードパーティのための要件は、インターネット上で展開するプロトコルを困難にすることができます。
Untrusted third parties (such as receivers that retransmit the data) may be used so long as the data authentication mechanisms take this into account. Typically this means that the original sender digitally signs and timestamps the data, and that the third parties resend this signed timestamped payload unmodified.
（そのようなデータを再送信する受信機などの）信頼できない第三者があれば、データ認証機構がこれを考慮に入れるように使用することができます。典型的には、これは元の送信者は、デジタル署名とデータをタイムスタンプすることを意味し、第三者は、これは非修飾タイムスタンプペイロードに署名したことを再送します。
Unlike unicast protocols, denial-of-service attacks on multicast transport state are easy if the protocol design does not take such attacks into account. This is because any receiver can join the session, and can then produce feedback that influences the progress of a session involving many other receivers. Hence protection against denial-of-service attacks on reliable multicast protocols must be carefully considered. A receiver that requests retransmission of every packet, or that refuses to acknowledge packets in an ACK-based protocol can potentially bring a reliable multicast session to a standstill. Senders must have appropriate policy to deal with such conditions, and if necessary, evict the receiver from the group. A single receiver masquerading as a large number of receivers may still be an issue under such circumstances with protocols that support NACK-like functionality. Providing unique "keys" to each NACKer when they first NACK using a unicast response might potentially prevent such attacks.
プロトコルの設計は、アカウントにこのような攻撃をとらない場合は、ユニキャストのプロトコルとは異なり、マルチキャスト転送状態にサービス拒否攻撃は簡単です。すべての受信機がセッションに参加することができ、その後、他の多くの受信機を含むセッションの進行に影響を与えるフィードバックを作り出すことができるからです。したがって、信頼性の高いマルチキャストプロトコルのサービス拒否攻撃に対する保護を慎重に検討する必要があります。すべてのパケットの再送を要求するか、それが潜在的に静止する信頼性の高いマルチキャストセッションをもたらすことができACKベースのプロトコルでパケットを認めることを拒否した受信機。送信者は、このような状況に対処する適切なポリシーを持って、必要に応じて、グループから受信機を追い出す必要があります。受信機の多数を装っ単一の受信機は依然としてNACKのような機能をサポートするプロトコルと、このような状況下で問題であってもよいです。彼らは最初のNACKが潜在的な攻撃を防ぐ可能性があるユニキャスト応答を使用して、各NACKerに固有の「キー」を提供します。
Denial-of-service attacks caused by traffic flooding are however somewhat easier to protect against than with unicast. Unwanted senders can simply be pruned from the distribution tree using the mechanisms implemented in IGMP v3[CDT99].
トラフィックフラッディングによって引き起こされるDoS攻撃は、しかし、ユニキャストと比べに対する保護がやや簡単です。不要な送信者は、単に、IGMP V3 [CDT99]で実装メカニズムを使用して配信ツリーからプルーニングすることができます。
In this document we present an overview of the design space for reliable multicast within the context of one-to-many bulk-data transfer. Other flavors of multicast application are not considered in this document, and hence the overview given should not be considered inclusive of the design space for protocols that fall outside the context of one-to-many bulk-data transfer. During the course of this overview, we have reaffirmed the notion that the process of reliable multicast protocol design is affected by a number of factors that render the generation of a "one size fits all solution" moot. These factors are then described to show how an application's needs serve to constrain the set of available techniques that may be used to create a reliable multicast protocol. We examined a number of basic techniques and to show how well they can meet the needs of certain types of applications.
この文書では、1対多のバルク・データ転送のコンテキスト内で信頼性の高いマルチキャストの設計空間の概要を提示します。マルチキャストアプリケーションの他のフレーバーは、この文書では考慮されていない、したがって、与えられた概要は、1対多のバルク・データ転送のコンテキストの範囲外のプロトコルの設計空間の包括的と考えるべきではありません。この概要の過程で、我々は信頼性の高いマルチキャストプロトコルの設計のプロセスは、議論の余地の世代「すべてのソリューションをワンサイズに合った」レンダリング多くの要因に影響されるという概念を再確認しています。これらの要因は、アプリケーションのニーズは、信頼できるマルチキャストプロトコルを作成するために使用することができる利用可能な技術の集合を制約するのに役立つ方法を示すために説明されています。私たちは、基本的なテクニックの数を調査し、それらがアプリケーションの特定の種類のニーズを満たすことができる方法も示すこと。
This document is intended to provide guidance to the IETF community regarding the standardization of reliable multicast protocols for bulk-data transfer. Given the degree to which application requirements constrain reliable multicast solutions, and the diverse set of applications that need to be supported, it should be clear that any standardization work should take great pains to be future-proof. This would seem to imply not standardizing complete reliable multicast transport protocols in one pass, but rather examining the degree to which such protocols are separable into functional building blocks, and standardizing these blocks separately to the maximum degree that makes sense. Such an approach allows for protocol evolution, and allows applications with new constraints to be supported with maximal reuse of existing and tested mechanisms.
この文書は、バルク・データ転送のための信頼できるマルチキャストプロトコルの標準化に関するIETFコミュニティにガイダンスを提供することを意図しています。アプリケーションの要件は、信頼性の高いマルチキャストソリューションを制約する程度、およびサポートする必要があるアプリケーションの多様なセットを考えると、任意の標準化作業は、将来性であることを苦心を取るべきであることは明らかです。これは、1回のパスで完全な信頼性の高いマルチキャストトランスポートプロトコルを標準化するのではなく、そのようなプロトコルは、機能的なビルディングブロックに分離され、かつ理にかなって最高度に分けて、これらのブロックを標準化する程度を調べていない意味すると思われます。このようなアプローチは、プロトコルの進化を可能にし、新しい制約のあるアプリケーションでは、既存およびテストのメカニズムの最大の再利用をサポートすることができます。
This document represents an overview of the reliable multicast design space. The ideas presented are not those of the authors, but are collected from the varied presentations and discussions in the IRTF Reliable Multicast Research Group. Although they are too numerous to list here, we thank everyone who has participated in these discussions for their contributions.
この文書では、信頼できるマルチキャストデザインスペースの概要を表しています。提示のアイデアは著者のそれらではありませんが、IRTF信頼性の高いマルチキャスト研究グループでは様々なプレゼンテーションや議論から収集されます。彼らはここに一覧表示するにはあまりにもたくさんありますが、我々は彼らの貢献のためにこれらの議論に参加しているすべての人に感謝します。
Mark Handley ATT Center for Internet Research at ICSI, International Computer Science Institute, 1947 Center Street, Suite 600, Berkeley, CA 94704, USA
ICSI、国際コンピュータサイエンス研究所、1947センターストリート、スイート600、バークレー、CA 94704、USAでのインターネットリサーチのためのマーク・ハンドリーATTセンター
EMail: mjh@aciri.org
メールアドレス：mjh@aciri.org
Sally Floyd ATT Center for Internet Research at ICSI, International Computer Science Institute, 1947 Center Street, Suite 600, Berkeley, CA 94704, USA
ICSI、国際コンピュータサイエンス研究所、1947センターストリート、スイート600、バークレー、CA 94704、USAでのインターネットリサーチのためのサリーフロイドATTセンター
EMail: floyd@aciri.org
メールアドレス：floyd@aciri.org
Brian Whetten Talarian Corporation, 333 Distel Circle, Los Altos, CA 94022, USA
ブライアンWhetten Talarian社、333 DISTELサークル、ロスアルトス、CA 94022、USA
EMail: whetten@talarian.com
メールアドレス：whetten@talarian.com
Roger Kermode Motorola Australian Research Centre Level 3, 12 Lord St, Botany NSW 2019, Australia
ロジャーKermodeモトローラオーストラリアの研究センターレベル3、12主の聖、ボタニーNSW 2019、オーストラリア
EMail: Roger.Kermode@motorola.com
メールアドレス：Roger.Kermode@motorola.com
Lorenzo Vicisano Cisco Systems, 170 West Tasman Dr. San Jose, CA 95134, USA
ロレンツォVicisanoシスコシステムズ、170西タスマン博士サンノゼ、CA 95134、USA
EMail: lorenzo@cisco.com
メールアドレス：lorenzo@cisco.com
Michael Luby Digital Fountain, Inc. 600 Alabama Street San Francisco, CA 94110
マイケル・ルビーデジタル噴水、Inc.の600アラバマストリート、サンフランシスコ、CA 94110
EMail: luby@digitalfountain.com
メールアドレス：luby@digitalfountain.com
[BC94] K. Birman, T. Clark. "Performance of the Isis Distributed Computing Toolkit." Technical Report TR-94-1432, Dept. of Computer Science, Cornell University.
[BC94] K.バーマン、T.クラーク。 「イシスのパフォーマンス・コンピューティング・ツールキットを配布しました。」テクニカルレポートTR-94から1432、コンピュータサイエンス学科、コーネル大学。
[BKKKLZ95] J. Bloemer, M. Kalfane, M. Karpinski, R. Karp, M. Luby, D. Zuckerman, "An XOR-based Erasure Resilient Coding Scheme", ICSI Technical Report No. TR-95-048, August 1995.
【BKKKLZ95] J. Bloemer、M. Kalfane、M. Karpinski、R.カープ、M.ルビー、D.ズッカーマン、 "符号化方式弾性XORベースの消去"、ICSIテクニカルレポートNo. TR-95から048年8月1995。
[BLMR98] J. Byers, M. Luby, M. Mitzenmacher, A. Rege, "A Digital Fountain Approach to Reliable Distribution of Bulk Data", Proc ACM SIGCOMM 98.
【BLMR98] J.バイヤーズ、M.ルビー、M. Mitzenmacher、A.レゲ、 "バルクデータの信頼性の分布にデジタルファウンテンアプローチ"、PROC ACM SIGCOMM 98。
[CDT99] Cain, B., Deering, S., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", Work in Progress.
[CDT99]カイン、B.、デアリング、S.、およびA. Thyagarajan、 "インターネットグループ管理プロトコル、バージョン3" が進行中で働いています。
[FLST98] Farinacci, D., Lin, S., Speakman, T. and A. Tweedly, "PGM reliable transport protocol specification", Work in Progress.
【FLST98]ファリナッチ、D.、リン、S.、スピークマン、T.及びA. Tweedly、 "PGM信頼できるトランスポートプロトコル仕様"、ProgressのWork。
[FJM95] S. Floyd, V. Jacobson, S. McCanne, "A Reliable Multicast Framework for Light-weight Sessions and Application Level Framing", Proc ACM SIGCOMM 95, Aug 1995 pp. 342-356.
【FJM95] S.フロイド、V. Jacobsonの、S. McCanne、 "軽量セッションの高信頼マルチキャストフレームワークとアプリケーションレベルフレーミング"、PROC ACM SIGCOMM 95、1995年8月頁342から356。
[Ha99] Handley, M., "Multicast address allocation protocol (AAP)", Work in Progress.
【Ha99]ハンドレー、M.、 "マルチキャストアドレス割り当てプロトコル（AAP）"、ProgressのWork。
[HC97] M. Handley and J. Crowcroft, "Network text editor (NTE) a scalable shared text editor for MBone," ACM Computer Communication Review, vol. 27, pp. 197-208, Oct. 1997. ACM SIGCOMM'97, Sept. 1997.
[HC97] M. HandleyのとJ.クロウクロフト、「ネットワークテキストエディタ（NTE）MBONEのスケーラブルな共有テキストエディタ、」ACMコンピュータコミュニケーションレビュー、巻。 27頁197から208まで、10月1997年ACM SIGCOMM'97、1997年9月。
[KCW98] Kadansky, M., Chiu, D. and J. Wesley, "Tree-based reliable multicast (TRAM)", Work in Progress.
【KCW98] Kadansky、M.、チウ、D.およびJ.ウェスリー、 "ツリーベースの信頼性の高いマルチキャスト（TRAM）"、進行中の作業。
[LMSSS97] M. Luby, M. Mitzenmacher, A. Shokrollahi, D. Spielman, V. Stemann, "Practical Loss-Resilient Codes", Proc ACM Symposium on Theory of Computing, 1997.
【LMSSS97] M.ルビー、M. Mitzenmacher、A.ショクロラヒ、D. Spielman、V. Stemann、 "実用的なロス弾性コード"、コンピューティング、1997の理論PROC ACMシンポジウム。
[MWB+98] Montgomery, T., Whetten, B., Basavaiah, M., Paul, S., Rastogi, N., Conlan, J. and T. Yeh, "THE RMTP-II PROTOCOL", Work in Progress.
[MWB + 98]モンゴメリー、T.、Whetten、B.、Basavaiah、M.、ポール、S.、Rastogi、N.、コンラン、J.及びT.葉、 "RMTP-IIプロトコル"、ProgressのWork 。
[PPV98] C. Papadopoulos, G. Parulkar, and G. Varghese, "An error control scheme for large-scale multicast applications," in Proceedings of the Conference on Computer Communications (IEEE Infocom), (San Francisco, California), p. 1188, March/April 1998.
コンピュータ通信会議（IEEEインフォコム）、（サンフランシスコ、カリフォルニア州）の議事録における[PPV98] C.パパドプロス、G. Parulkar、及びG. Varghese、「大規模なマルチキャストアプリケーションのための誤り制御方式」、P 。 1188年3月/ 1998年4月。
[Ri97] L. Rizzo, "Effective erasure codes for reliable computer communication protocols," ACM Computer Communication Review, vol. 27, pp. 24-36, Apr. 1997.
[Ri97] L.リゾー、「信頼性の高いコンピュータ通信プロトコルのための効果的な消去符号、」ACMコンピュータコミュニケーションレビュー、巻。 27頁24-36、1997年4月。
[RV97] L. Rizzo, L. Vicisano, "A Reliable Multicast data Distribution Protocol based on software FEC techniques", Proc. of The Fourth IEEE Workshop on the Architecture and Implementation of High Performance Communication Systems (HPCS'97), Sani Beach, Chalkidiki, Greece June 23-25, 1997.
"ソフトウェアFEC技術に基づいた信頼性の高いマルチキャストデータ配布プロトコル" [RV97] L.リゾー、L. Vicisano、PROC。高性能通信システムのアーキテクチャと実装第4回IEEEワークショップ（HPCS'97）、サニビーチ、ハルキディキ、ギリシャ6月23-25、1997年。
[RVC98] L. Rizzo, L. Vicisano, J. Crowcroft, "The RLC multicast congestion control algorithm", submitted to IEEE Network - special issue multicast.
[RVC98] L.リゾー、L. Vicisano、J.クロウクロフト、IEEEネットワークに提出し、 "RLCマルチキャスト輻輳制御アルゴリズム"、 - 特別号マルチキャスト。
[RMWT98] Robertson, K., Miller, K., White, M. and A. Tweedly, "StarBurst multicast file transfer protocol (MFTP) specification", Work in Progress.
【RMWT98]ロバートソン、K.、ミラー、K.、白、M.及びA. Tweedly、 "スターバーストマルチキャストファイル転送プロトコル（MFTP）仕様"、ProgressのWork。
[WHA98] Wallner, D., Hardler, E. and R. Agee, "Key Management for Multicast: Issues and Architectures", RFC 2627, June 1999.
[WHA98]ウォルナー、D.、Hardler、E.およびR.アゲ、 "マルチキャストのためのキー管理：問題とアーキテクチャ"、RFC 2627、1999年6月。
[WKM94] Brian Whetten, Simon Kaplan, and Todd Montgomery, "A high performance totally ordered multicast protocol," research memorandum, Aug. 1994.
[WKM94]ブライアンWhetten、サイモン・カプラン、およびトッド・モンゴメリー、「高性能全順序マルチキャストプロトコル、」研究の覚書、1994年8月。
[WGL97] C.K. Wong, M. Gouda, S. Lam, "Secure Group Communications Using Key Graphs," Technical Report TR 97-23, Department of Computer Sciences, The University of Texas at Austin, July 1997.
【WGL97] C.K.ウォン、M.ゴーダ、S.ラムは、「キーグラフを使用してグループ通信をセキュア、」テクニカルレポートTR 97から23、コンピュータ科学科、オースチン、1997年7月のテキサス大学。
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。