[要約] RFC 2887は、大容量データ転送のための信頼性のあるマルチキャストの設計に関する要約です。このRFCの目的は、信頼性のあるマルチキャストの設計の概要を提供し、大容量データ転送における効果的なソリューションを探求することです。
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.
Copyright（c）The Internet Society（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? 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.
o アプリケーションは安全な配送を提供する必要がありますか？バルクデータ転送プロトコルの標準化のコンテキストでは、複数の相互作用する送信者と断続的なデータフローを使用してアプリケーションを除外できます。これらのアプリケーションが重要ではないということではなく、そのようなアプリケーションにはまだ効果的な混雑制御がないということではありません。
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」スキームは、送信者への崩壊を認めます。集合体Acksを頻繁に送信することにより、この問題を軽減する試みがなされました[RMWT98、BC94]が、フィードバックの極度のため、そのようなプロトコルに効果的な輻輳制御を組み込むことは非常に困難です。
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爆発の1つに減少します（受信機がパケットを欠いていることからのみ）。、さまざまな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.
NACKSの代替品はACK集約です。これは、受信機を論理ツリーに配置することで実行できます。そのため、各葉はそれらを集計する親にAcksを送信し、ツリーの上に渡すことができます。ツリーベースのプロトコルはよく拡張されますが、ツリーの形成には問題があります。
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.
また、これらのメカニズムのハイブリッドが可能であり、パケットレベルで1つのメカニズムを使用すると、ADUレベルで異なる（通常はより高いオーバーヘッド）溶液を使用すると、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.
信頼性の高いマルチキャストプロトコルには、エンドホストで実行されるメカニズムを含む必要があり、マルチキャストパケットを転送するルーターが必要です。ただし、状況によっては、ネットワーク要素からの追加の支援に頼ることができます。大まかに言えば、他のネットワーク要素から受け取ったサポートの程度に応じて、RMプロトコルを4つのクラスにクラスター化できます。
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の爆発により、非常に小さな受信機グループに限定されており、このため、ほとんどのアプリケーションでは非現実的です。
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.
複数のAcksを単一のデータパケット[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凝集にのみ使用されます - データパケットは、通常どおり送信者から受信機へのマルチキャストです。より多くのローカル情報を建設に使用できるため、木はリングよりも構築しやすいです。また、ノードの障害は受信機のサブセットにのみ影響するため、リングよりも障害耐性があります。各レシーバーは、親を簡単かつローカルで親に迂回し、ツリー内の1レベルの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:
もう1つの重要な問題は、ACKツリーの内部ノードで実行される集約の性質です。そのようなノードは：
1. aggregate ACKs by sending a single ACK when all their children have ACKed,
1. すべての子供がACKを使用したときに単一のACKを送信することにより、Ackを集計します。
2. aggregate ACKs by listing all the children that have ACKed,
2. Ackedしたすべての子供をリストすることにより、Acksを集計します。
3. send an aggregated ACK with a NACK-like exception list.
3. NACKのような例外リストを使用して集約された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ごとにこれを行う必要はありません。1.パケットごとに、3。ADUごとに、この情報を必要とするアプリケーションに対して最もスケーラブルなソリューションがあり、パケットごとに使用される他のソリューションと比較して事実上不利な点はありません。
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 任意の数の受信機が欠いているパケットを示すために、レシーバーから必要な1つの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-Suppressionの実行方法です。目標は、1つのNACKのみが送信者（または欠落データを再送信できるノード）に到達することです。損失が最初に注目された後、できるだけ早く、そして再送信が必要なノードが受信する欠落データのコピーは1つだけです。
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ランダムタイマーと抑制をローカライズして、グループ全体が抑制を必要としないようにします。
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が不明な状況や回答者の数が不明な状況では、正しく使用するのが困難です。対照的に、指数関数的に重み付けされたランダムタイマーは、最悪のケース遅延特性を備えたセッションサイズの広い範囲でうまく機能します。
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の最も単純な形式は、送信されるパケットのグループを採取し、パケットを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.
より一般的な消去コードが存在します[Bkklz95]、[RI97]、[LMSS97]は、K元のデータパケットからNエンコードパケットの生成を可能にします。このような場合、少なくともkのnエンコードパケットが受信される限り、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とリアクティブFECの2つのカテゴリに分割できます。2つの違いは、プロアクティブなFECの場合、送信者は、データパケットの各ラウンドに送信するエンコードパケットの数を先験的に決定するのに対し、リアクティブFECの場合、送信者は最初に各ラウンドの元のデータパケットのみを送信することです。次に、送信者はレシーバーからのフィードバックを使用して、各ラウンドで最も損失を経験したレシーバーによって失われたパケットの数を計算し、その数の追加エンコードパケットのみがそのラウンドに送信されます。これらのエンコードパケットは、パケットが少ない他の受信機で損失を修復するのにも役立ちます。レシーバーは、各ラウンドから欠落しているパケットの数をAcksまたはNacksでレポートします。NACKSを使用すると、ほとんどのパケットを欠いているレシーバーのみがこのラウンドに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.
いくつかのマルチキャストグループ[RVC98]、[BLMR98]にデータが広がると、パケットレベルFECの代替使用が可能です。このような場合、元のKデータパケットは、nがkよりもはるかに大きいnエンコードパケットを生成するために使用されます。次に、nエンコードされたパケットは、複数のマルチキャストグループに縞模様になります。受信者が元のデータを受信したい場合、マルチキャストグループの1つ以上に結合し、エンコーディングパケットを受信します。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 送信者制御、1つのグループ。
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.
1つの初期マルチキャストグループは、ネットワーク内の輻輳ポイントを中心とした区画を持つ複数のサブグループに適応的に細分化されています。アプリケーションレベルのリレーは、元の送信者に近いグループからのバッファデータをバッファーし、元の送信者からさらにゆっくりと速度でグループに再送信します。このようにして、異なる受信機は異なるレートでデータを受信できます。送信者ベースの混雑制御は、サブグループのメンバーとそのリレーの間で行われます。
o Receiver-controlled, one group.
o レシーバー制御、1つのグループ。
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]に記載されています。Sender Stripesデータは、複数のマルチキャストグループのデータを同時に渡ります。受信者は、ネットワークの輻輳状態の測定に応じてこれらの層状グループに参加して残し、受信されるデータの量が常に適切です。ただし、このスキームは、レシーバーに依存して、ボトルネックリンクの背後にあるさまざまなマルチキャストグループを調整された方法で留めておくために、このアプローチが実際にインターネットに拡大することをまだ完全に確認していません。その結果、この混雑制御メカニズムに関するより多くの作業が有益です。
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を使用したオープンループ配信は、バルクデータ転送のための優れたスループットを達成するための選択肢です。これは、オープンループ配信にレシーバーからのフィードバックが不要なため、受信機からのフィードバックなしで動作するレシーバーベースの混雑制御メカニズムと完全に一致するためです。
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を使用したときに、各ナッカーに一意の「キー」を提供すると、そのような攻撃を防ぐ可能性があります。
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].
ただし、交通洪水によって引き起こされるサービス拒否攻撃は、ユニキャストよりも保護するのがやや簡単です。不要な送信者は、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対多くのバルクデータ転送のコンテキストの外側にあるプロトコルの設計スペースを含むと見なされるべきではありません。この概要の過程で、信頼できるマルチキャストプロトコル設計のプロセスは、「すべてのソリューションに適合する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.
このドキュメントは、BULK-DATA転送用の信頼できるマルチキャストプロトコルの標準化に関する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のインターネット研究のためのマークハンドリーATTセンター、国際コンピューターサイエンス研究所、1947年センターストリート、スイート600、バークレー、カリフォルニア州94704、米国
EMail: 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
Sally Floyd ATT ICSIのインターネット研究センター、国際コンピューターサイエンス研究所、1947年センターストリート、スイート600、バークレー、カリフォルニア州94704、米国
EMail: floyd@aciri.org
Brian Whetten Talarian Corporation, 333 Distel Circle, Los Altos, CA 94022, USA
ブライアン・ウェッテン・タリアン・コーポレーション、333ディステル・サークル、ロス・アルトス、カリフォルニア州94022、米国
EMail: whetten@talarian.com
Roger Kermode
Motorola Australian Research Centre
Level 3, 12 Lord St,
Botany NSW 2019,
Australia
EMail: Roger.Kermode@motorola.com
Lorenzo Vicisano Cisco Systems, 170 West Tasman Dr. San Jose, CA 95134, USA
Lorenzo Vicisano Cisco Systems、170 West Tasman Dr. San Jose、CA 95134、米国
EMail: lorenzo@cisco.com
Michael Luby Digital Fountain, Inc. 600 Alabama Street San Francisco, CA 94110
Michael Luby Digital Fountain、Inc。600アラバマストリートサンフランシスコ、カリフォルニア94110
EMail: 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。クラーク。「ISIS分散コンピューティングツールキットのパフォーマンス。」テクニカルレポート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。Karp、M。Luby、D。Zuckerman、「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. Byers、M。Luby、M。Mitzenmacher、A。Rege、「バルクデータの信頼できる分布へのデジタル噴水アプローチ」、Proc ACM SigComm 98。
[CDT99] Cain, B., Deering, S., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", Work in Progress.
[CDT99] Cain、B.、Deering、S。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、Work in Progress。
[FLST98] Farinacci, D., Lin, S., Speakman, T. and A. Tweedly, "PGM reliable transport protocol specification", Work in Progress.
[FLST98] Farinacci、D.、Lin、S.、Speakman、T。およびA. Tweedly、「PGM信頼できる輸送プロトコル仕様」、作業進行中。
[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. Floyd、V。Jacobson、S。McCanne、「軽量セッションとアプリケーションレベルのフレーミングのための信頼できるマルチキャストフレームワーク」、Proc ACM Sigcomm 95、1995年8月pp。342-356。
[Ha99] Handley, M., "Multicast address allocation protocol (AAP)", Work in Progress.
[HA99] Handley、M。、「マルチキャストアドレス割り当てプロトコル（AAP）」、作業進行中。
[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. Crowcroft、「ネットワークテキストエディター（NTE）MBONEのスケーラブルな共有テキストエディター」、ACM Computer Communication Review、Vol。27、pp。197-208、1997年10月。ACMSIGCOMM'97、1997年9月。
[KCW98] Kadansky, M., Chiu, D. and J. Wesley, "Tree-based reliable multicast (TRAM)", Work in Progress.
[KCW98] Kadansky、M.、Chiu、D。、およびJ. Wesley、「樹木ベースの信頼できるマルチキャスト（TRAM）」、Work in Progress。
[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. Luby、M。Mitzenmacher、A。Shokrollahi、D。Spielman、V。Stemann、「実用的な損失依頼性コード」、Croc ACM Symposium on Computing、1997。
[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] Montgomery、T.、Whetten、B.、Basavaiah、M.、Paul、S.、Rastogi、N.、Conlan、J。and T. Yeh、「RMTP-IIプロトコル」、進行中の作業。
[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.
[PPV98] C. Papadopoulos、G。Parulkar、およびG. Varghese、「大規模なマルチキャストアプリケーションのエラー制御スキーム」、コンピューター通信会議（IEEE Infocom）の議事録、（カリフォルニア州サンフランシスコ）、P。1188、1998年3月/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. Rizzo、「信頼できるコンピューター通信プロトコルの効果的な消去コード」、ACM Computer Communication Review、Vol。27、pp。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.
[Rv97] L. Rizzo、L。Vicisano、「ソフトウェアFEC技術に基づく信頼できるマルチキャストデータ分布プロトコル」、Proc。1997年6月23〜25日、ギリシャ、チャルキディキ、サニビーチ、高性能通信システム（HPCS'97）のアーキテクチャと実装に関する第4回IEEEワークショップのうち。
[RVC98] L. Rizzo, L. Vicisano, J. Crowcroft, "The RLC multicast congestion control algorithm", submitted to IEEE Network - special issue multicast.
[RVC98] L. Rizzo、L。Vicisano、J。Crowcroft、「RLCマルチキャスト輻輳制御アルゴリズム」、IEEEネットワーク - 特別号マルチキャストに提出。
[RMWT98] Robertson, K., Miller, K., White, M. and A. Tweedly, "StarBurst multicast file transfer protocol (MFTP) specification", Work in Progress.
[RMWT98] Robertson、K.、Miller、K.、White、M.、A。Tweedly、「Starburst Multicast File Transfer Protocol（MFTP）仕様」、作業進行中。
[WHA98] Wallner, D., Hardler, E. and R. Agee, "Key Management for Multicast: Issues and Architectures", RFC 2627, June 1999.
[WHA98] Wallner、D.、Hardler、E。and R. Agee、「マルチキャストの重要な管理：問題とアーキテクチャ」、RFC 2627、1999年6月。
[WKM94] Brian Whetten, Simon Kaplan, and Todd Montgomery, "A high performance totally ordered multicast protocol," research memorandum, Aug. 1994.
[WKM94] Brian Whetten、Simon Kaplan、およびTodd Montgomery、「高性能で完全に注文されたマルチキャストプロトコル」、Research Memorandum、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.Wong、M。Gouda、S。Lam、「キーグラフを使用した安全なグループコミュニケーション」、テクニカルレポートTR 97-23、テキサス大学オースティン校、1997年7月。
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。