[要約] RFC 2357は、信頼性のあるマルチキャストトランスポートとアプリケーションプロトコルを評価するためのIETFの基準を提供しています。このRFCの目的は、信頼性のあるマルチキャスト通信の実装と評価を支援することです。
Network Working Group A. Mankin
Request for Comments: 2357 USC/ISI
Category: Informational A. Romanow
MCI
S. Bradner
Harvard University
V. Paxson
LBL
With the TSV
Area Directorate
June 1998
IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols
信頼性の高いマルチキャストトランスポートおよびアプリケーションプロトコルを評価するためのIETF基準
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 (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Abstract
概要
This memo describes the procedures and criteria for reviewing reliable multicast protocols within the Transport Area (TSV) of the IETF. Within today's Internet, important applications exist for a reliable multicast service. Some examples that are driving reliable multicast technology are collaborative workspaces (such as whiteboard), data and software distribution, and (more speculatively) web caching protocols. Due to the nature of the technical issues, a single commonly accepted technical solution that solves all the demands for reliable multicast is likely to be infeasible [RMMinutes 1997].
このメモは、IETFのトランスポートエリア（TSV）内の信頼できるマルチキャストプロトコルを確認するための手順と基準について説明しています。今日のインターネット内には、信頼性の高いマルチキャストサービスのための重要なアプリケーションが存在します。信頼性の高いマルチキャストテクノロジーを推進しているいくつかの例は、コラボレーションワークスペース（ホワイトボードなど）、データとソフトウェアの配布、および（より推測的に）Webキャッシュプロトコルです。技術的な問題の性質上、信頼性の高いマルチキャストに対するすべての要求を解決する、一般に受け入れられている単一の技術的解決策は実行不可能である可能性が高い[RMMinutes 1997]。
A number of reliable multicast protocols have already been developed to solve a variety of problems for various types of applications. [Floyd97] describes one widely deployed example. How should these protocols be treated within the IETF and how should the IETF guide the development of reliable multicast in a direction beneficial for the general Internet? The TSV Area Directors and their Directorate have outlined a set of review procedures that address these questions and set criteria and processes for the publication as RFCs of Internet-Drafts on reliable multicast transport protocols.
さまざまなタイプのアプリケーションのさまざまな問題を解決するために、信頼できるマルチキャストプロトコルがすでにいくつか開発されています。 [Floyd97]は、広く展開されている1つの例を説明しています。これらのプロトコルをIETF内でどのように処理する必要があり、IETFは一般的なインターネットに有益な方向で信頼できるマルチキャストの開発をどのようにガイドする必要がありますか？ TSVエリアディレクターとそのディレクターは、これらの質問に対処し、公開の基準とプロセスを設定する一連のレビュー手順を、信頼できるマルチキャストトランスポートプロトコルに関するインターネットドラフトのRFCとして概説しています。
In the IETF, work in an area is directed and managed by the Area Directors (ADs), who have authority over the chartering of working groups (WGs).
IETFでは、エリアでの作業は、ワーキンググループ（WG）のチャーターに対する権限を持つエリアディレクター（AD）によって指示および管理されます。
In addition, ADs review individually submitted (not by WGs) Internet-Drafts about work that is relevant to their areas prior to publication as RFCs (Experimental, Informational or, in rare cases, Standards Track). The review is done according to the guidelines set out in the Internet Standards Process, RFC 2026 [InetStdProc96].
さらに、ADは、RFC（実験的、情報的、またはまれにスタンダードトラック）として公開される前に、各分野に関連する作業について（WGではなく）インターネットドラフトを個別に提出してレビューします。レビューは、インターネット標準プロセス、RFC 2026 [InetStdProc96]に記載されているガイドラインに従って行われます。
The purpose of this document is to present the criteria that will be used by the TSV ADs in reviewing reliable multicast Internet-Drafts for any form of RFC publication.
このドキュメントの目的は、あらゆる形式のRFC公開について、信頼できるマルチキャストインターネットドラフトをレビューする際にTSV ADが使用する基準を提示することです。
For I-Ds submitted for Standards Track publication, these criteria must be met or else the ADs will decline to support publication of the document, which suffices to prevent publication. For I-Ds submitted as Experimental or Informational, these criteria must be met or else, at a minimum, the Ads will recommend publishing the I-D with an IESG note prepended stating that the protocol fails to comply with these criteria.
Standards Trackの発行のために提出されたI-Dの場合、これらの基準を満たす必要があります。満たしていない場合、ADはドキュメントの発行をサポートしないため、発行を防止できます。実験的または情報として送信されたI-Dの場合、これらの基準を満たす必要があります。そうでない場合、広告では、プロトコルがこれらの基準に準拠していないことを示すIESGメモを前に付けてI-Dを公開することをお勧めします。
There is a strong application demand for reliable multicast. Widespread use of the Internet makes the economy of multicast transport attractive. The current Internet multicast model offers best-effort many-to-many delivery service and offers no guarantees. One-to-many and few-to-few services may become more important in the future. Reliable multicast transports add delivery guarantees, not necessarily like those of reliable unicast TCP, to the group-delivery model of multicast. A panel of some major users of the Internet, convened at the 38th IETF, articulated reliable bulk transfer multicast as one of their most critical requirements [DiffServBOF97]. Examples of applications that could use reliable bulk multicast transfer include collaborative tools, distributed virtual reality, and software upgrade services.
信頼性の高いマルチキャストに対するアプリケーションの強い需要があります。インターネットの普及は、マルチキャスト転送の経済性を魅力的なものにします。現在のインターネットマルチキャストモデルは、ベストエフォートの多対多の配信サービスを提供し、保証はありません。 1対多および数対数のサービスは、将来、より重要になる可能性があります。信頼性の高いマルチキャストトランスポートは、マルチキャストのグループ配信モデルに、必ずしも信頼性の高いユニキャストTCPとは異なる配信保証を追加します。第38回IETFで開催されたインターネットの主要なユーザーのパネルは、最も重要な要件の1つとして信頼性の高いバルク転送マルチキャストを明確にしました[DiffServBOF97]。信頼性の高いバルクマルチキャスト転送を使用できるアプリケーションの例には、コラボレーションツール、分散仮想現実、ソフトウェアアップグレードサービスなどがあります。
To meet the growing demand for reliable multicast, there is a large number of protocol proposals. A few were published as RFCs before the impact of congestion from reliable multicast was fully appreciated, and these should be deprecated [DeprRFCs]. Two surveys of other publications are [DiotCrow97], [Obraczka98].
信頼性の高いマルチキャストに対する需要の増大に対応するために、多数のプロトコルが提案されています。信頼性の高いマルチキャストによる輻輳の影響が十分に認められる前に、RFCとしていくつか公開されましたが、これらは非推奨になっているはずです[DeprRFCs]。他の出版物の2つの調査は[DiotCrow97]、[Obraczka98]です。
As we discuss in Section 3, the issues raised by reliable multicast are considerably more complex than those related to reliable unicast. In particular, in today's Internet, reliable multicast protocols could do great damage through causing congestion disasters if they are widely used and do not provide adequate congestion control.
セクション3で説明するように、信頼性の高いマルチキャストによって引き起こされる問題は、信頼性の高いユニキャストに関連する問題よりもかなり複雑です。特に、今日のインターネットでは、信頼性の高いマルチキャストプロトコルが広く使用されており、適切な輻輳制御を提供していない場合、信頼性の高いマルチキャストプロトコルは輻輳災害を引き起こすことで大きな損害を与える可能性があります。
Because of the complexity of the technical issues, and the abundance of proposed solutions, we are putting in place review procedures that are more explicit than usual. We compare this action with an IESG action taken in 1991, RFC 1264 [Routing91], when community experience with standard Internet dynamic routing protocols was still limited, and extra review was deemed necessary to assure that the protocols introduced would be effective, correct and robust.
技術的な問題の複雑さ、および提案されたソリューションの豊富さのため、通常よりも明確なレビュー手順を導入しています。このアクションを、標準のインターネットダイナミックルーティングプロトコルのコミュニティエクスペリエンスがまだ制限されており、導入されたプロトコルが効果的で正確かつ堅牢であることを保証するために追加のレビューが必要であると判断された1991年のRFC 1264 [Routing91]のIESGアクションと比較します。 。
Section 3 describes in detail the nature of the particular challenges posed by reliable multicast. Section 4 describes the process for considering reliable multicast solutions. Section 5 details the additional requirements that need to be met by proposals to be published as Standards Track RFCs.
セクション3では、信頼性の高いマルチキャストがもたらす特定の課題の性質について詳しく説明します。セクション4では、信頼性の高いマルチキャストソリューションを検討するプロセスについて説明します。セクション5では、Standards Track RFCsとして公開される提案が満たす必要のある追加の要件について詳しく説明します。
Two aspects of reliable multicast make standardization particularly challenging. First, the meaning of reliability varies in the context of different applications. Secondly, if special care is not taken, reliable multicast protocols can cause a particular threat to the operation of today's global Internet. These issues are discussed in detail in this section.
信頼性の高いマルチキャストには2つの側面があるため、標準化は特に困難です。まず、信頼性の意味は、アプリケーションによって異なります。次に、特別な注意が払われない場合、信頼性の高いマルチキャストプロトコルは、今日のグローバルインターネットの運用に特定の脅威を引き起こす可能性があります。これらの問題については、このセクションで詳しく説明します。
Unlike reliable unicast, where a single transport protocol (TCP) is currently used to meet the reliable delivery needs of a wide range of applications, reliable multicast does not necessarily lend itself to a single application interface or to a single underlying set of mechanisms. For unicast transport, the requirements for reliable, sequenced data delivery are fairly general. TCP, the primary transport protocol for reliable unicast, is a mature protocol with delivery semantics that suit a wide range of applications.
信頼性の高いユニキャストとは異なり、単一のトランスポートプロトコル（TCP）が現在、幅広いアプリケーションの信頼性の高い配信ニーズを満たすために使用されていますが、信頼性の高いマルチキャストは、必ずしも単一のアプリケーションインターフェイスまたは単一の基になるメカニズムセットに適しているわけではありません。ユニキャストトランスポートの場合、信頼性の高いシーケンスデータ配信の要件はかなり一般的です。信頼性の高いユニキャストの主要なトランスポートプロトコルであるTCPは、幅広いアプリケーションに適した配信セマンティクスを持つ成熟したプロトコルです。
In contrast, different multicast applications have widely different requirements for reliability. For example, some applications require that message delivery obey a total ordering while others do not. Some applications have many or all the members sending data while others have only one data source. Some applications have replicated data, for example in an n-redundant file store, so that several members are capable of transmitting a data item, while for others all data originates at a single source. Some applications are restricted to small fixed-membership multicast groups, while other applications need to scale dynamically to thousands or tens of thousands of members (or possibly more). Some applications have stringent delay requirements, while others do not. Some applications such as file-transfer are high-bandwidth, while other applications such as interactive collaboration tools are more likely to be bursty but use low bandwidth overall. Some applications will sometimes trade off less than complete reliability for more timely delivery. These requirements each impact the design of reliable multicast protocols in a different way.
対照的に、マルチキャストアプリケーションが異なれば、信頼性の要件も大きく異なります。たとえば、一部のアプリケーションでは、メッセージの配信が完全な順序に従うことを必要としますが、他のアプリケーションはそうではありません。一部のアプリケーションでは、多くのメンバーまたはすべてのメンバーがデータを送信しますが、他のアプリケーションではデータソースが1つだけです。一部のアプリケーションは、たとえばn冗長ファイルストアにデータを複製しているため、複数のメンバーがデータアイテムを送信できる一方で、他のすべてのデータは単一のソースから発信されます。一部のアプリケーションは、固定メンバーシップの小さなマルチキャストグループに制限されていますが、他のアプリケーションは、数千または数万（またはそれ以上）のメンバーに動的にスケーリングする必要があります。一部のアプリケーションには厳しい遅延要件がありますが、他のアプリケーションにはありません。ファイル転送などの一部のアプリケーションは高帯域幅ですが、インタラクティブコラボレーションツールなどの他のアプリケーションはバースト性が高いですが、全体的に低帯域幅を使用します。一部のアプリケーションでは、完全な信頼性ではなく、よりタイムリーな配信が得られる場合があります。これらの要件はそれぞれ、信頼できるマルチキャストプロトコルの設計に異なる方法で影響を与えます。
In addition, even for a specific application where the application's requirements for reliable multicast are well understood, there are many open questions about the underlying mechanisms for providing reliable multicast. A key question concerns the robustness of the underlying reliable multicast mechanisms as the number of senders or the membership of the multicast group grows.
さらに、信頼性の高いマルチキャストに対するアプリケーションの要件が十分に理解されている特定のアプリケーションであっても、信頼性の高いマルチキャストを提供するための基本的なメカニズムについては多くの未解決の問題があります。重要な質問は、送信者の数またはマルチキャストグループのメンバーシップの増加に伴う、基になる信頼性の高いマルチキャストメカニズムの堅牢性に関するものです。
One challenge to the IETF is to end up with the right match between applications' requirements and reliable multicast mechanisms. While there is general agreement that a single reliable multicast protocol or framework is not likely to meet the needs of all Internet applications, there is less understanding and agreement about the exact relationship between application-specific requirements and more generic underlying reliable mutlicast protocols or mechanisms. There are also open questions about the appropriate integration between an application and an underlying reliable multicast framework, and the potential generality of a single applications interface for that framework.
IETFの課題の1つは、アプリケーションの要件と信頼性の高いマルチキャストメカニズムを適切に一致させることです。単一の信頼できるマルチキャストプロトコルまたはフレームワークがすべてのインターネットアプリケーションのニーズを満たす可能性は低いという一般的な合意がありますが、アプリケーション固有の要件と、より一般的な基礎となる信頼できるマルチキャストプロトコルまたはメカニズムとの正確な関係についての理解と合意はあまりありません。また、アプリケーションと基盤となる信頼性の高いマルチキャストフレームワークとの適切な統合、およびそのフレームワークの単一のアプリケーションインターフェイスの一般性についても未解決の問題があります。
A particular concern for the IETF is the impact of reliable multicast traffic on other traffic in the Internet in times of congestion, in particular the effect of reliable multicast traffic on competing TCP traffic. The success of the Internet relies on the fact that best-effort traffic responds to congestion on a link (currently as indicated by packet drops) by reducing the load presented to the network. Congestion collapse in today's Internet is prevented only by the congestion control mechanisms in TCP, standardized by RFC 2001 [CongAvoid97, Jacobson88].
IETFの特別な懸念は、輻輳時のインターネット内の他のトラフィックに対する信頼できるマルチキャストトラフィックの影響、特に競合するTCPトラフィックに対する信頼できるマルチキャストトラフィックの影響です。インターネットの成功は、ベストエフォートトラフィックがネットワークの負荷を軽減することにより、リンクの輻輳（現在はパケットドロップで示される）に応答するという事実に依存しています。今日のインターネットにおける輻輳の崩壊は、RFC 2001 [CongAvoid97、Jacobson88]によって標準化されたTCPの輻輳制御メカニズムによってのみ防止されます。
There are a number of reasons to be particularly attentive to the congestion-related issues raised by reliable multicast proposals. Multicast applications in general have the potential to do more congestion-related damage to the Internet than do unicast applications. One factor is that a single multicast flow can be distributed along a large, global multicast tree reaching throughout the entire Internet.
信頼性の高いマルチキャストプロポーザルによって発生する輻輳関連の問題に特に注意を払う理由はいくつかあります。マルチキャストアプリケーションは一般に、ユニキャストアプリケーションよりも、輻輳に関連するインターネットへの損害をもたらす可能性があります。 1つの要因は、単一のマルチキャストフローをインターネット全体に到達する大規模なグローバルマルチキャストツリーに沿って分散できることです。
Unreliable multicast applications such as audio and video are, at the moment, usually accompanied by a person at the receiving end, and people typically unsubscribe from a multicast group if congestion is so heavy that the audio or video stream is unintelligible. Reliable multicast applications such as group file transfer applications, on the other hand, are likely to be between computers, with no humans in attendance monitoring congestion levels.
現在、オーディオやビデオなどの信頼性の低いマルチキャストアプリケーションには、通常、受信側の人が同行します。通常、混雑が非常に激しく、オーディオまたはビデオストリームが理解できない場合、人々はマルチキャストグループから退会します。一方、グループファイル転送アプリケーションなどの信頼性の高いマルチキャストアプリケーションは、混雑レベルを監視する人間がいないコンピュータ間である可能性があります。
In addition, reliable multicast applications do not necessarily have the natural time limitations typical of current unreliable multicast applications. For a file transfer application, for example, the data transfer might continue until all of the data is transferred to all of the intended receivers, resulting in a potentially-unlimited duration for an individual flow. Reliable multicast applications also have to contend with a potential explosion of complex patterns of control traffic (e.g., ACKs, NACKs, status messages). The design of congestion control mechanisms for reliable multicast for large multicast groups is currently an area of active research.
さらに、信頼性の高いマルチキャストアプリケーションには、現在の信頼性の低いマルチキャストアプリケーションに典型的な自然な時間制限があるとは限りません。たとえば、ファイル転送アプリケーションの場合、データ転送は、すべてのデータが目的のすべてのレシーバーに転送されるまで続行され、個々のフローの期間が無制限になる可能性があります。信頼性の高いマルチキャストアプリケーションは、制御トラフィックの複雑なパターン（ACK、NACK、ステータスメッセージなど）の爆発的な増加にも対処する必要があります。大規模なマルチキャストグループの信頼性の高いマルチキャストのための輻輳制御メカニズムの設計は、現在活発に研究されている領域です。
The challenge to the IETF is to encourage research and implementations of reliable multicast, and to enable the needs of applications for reliable multicast to be met as expeditiously as possible, while at the same time protecting the Internet from the congestion disaster or collapse that could result from the widespread use of applications with inappropriate reliable multicast mechanisms. Because of the setbacks and costs that could result from the widespread deployment of reliable multicast with inadequate congestion control, the IETF must exercise care in the standardization of a reliable multicast protocol that might see widespread use.
IETFの課題は、信頼性の高いマルチキャストの調査と実装を促進し、信頼性の高いマルチキャストのアプリケーションのニーズに可能な限り迅速に対応できるようにすると同時に、結果として生じる可能性のある輻輳災害または崩壊からインターネットを保護することです。信頼性の高い不適切なマルチキャストメカニズムを備えたアプリケーションの広範な使用から。輻輳制御が不十分な信頼性の高いマルチキャストの広範な展開から生じる可能性のある後退とコストのため、IETFは、広く使用される可能性のある信頼性の高いマルチキャストプロトコルの標準化に注意を払う必要があります。
The careful review and cautious acceptance procedures for proposals submitted as Internet-Drafts reflects our concern to meet the challenges described here.
インターネットドラフトとして提出された提案の慎重なレビューと慎重な承認手順は、ここで説明する課題に対処するための私たちの懸念を反映しています。
4. IETF Process for Review and Publication of Reliable Multicast Protocol Specifications
4. 信頼できるマルチキャストプロトコル仕様のレビューと公開のためのIETFプロセス
In the general case of individually submitted Internet-Drafts (proposals not produced by an IETF WG), the process of publication as some type of RFC is described in RFC 2026 (4.2.3) [InetStdProc96]. This specifies that if the submitted Internet-Draft is closely related to work being done or expected to be done in the IETF, the ADs may recommend that the document be brought within the IETF and progressed in the IETF context. Otherwise, the ADs may recommend that the Internet-Draft be published as an Experimental or Informational RFC, with or without an IESG annotation of its relationship to the IETF context.
個別に提出されたインターネットドラフト（IETF WGによって作成されていない提案）の一般的なケースでは、ある種のRFCとしての公開のプロセスはRFC 2026（4.2.3）[InetStdProc96]で説明されています。これは、提出されたインターネットドラフトがIETFで行われている、または行われる予定の作業に密接に関連している場合、ADがドキュメントをIETF内に持ち込み、IETFコンテキストで進めることを推奨する可能性があることを指定します。そうでない場合、ADは、IETFコンテキストとの関係に関するIESGアノテーションの有無にかかわらず、インターネットドラフトを試験的または情報的RFCとして公開することを推奨する場合があります。
The procedure for Reliable Multicast proposal publication will have as its default RFC status Experimental, when the technical criteria listed in Section 5 are deemed to be fulfilled. Both the criteria and the procedure reflect the AD's technical assessment of the current state of reliable multicast technology. It does not reflect the origins of the proposals, which we expect will be equally from commercial vendors with initial products and from researchers.
セクション5に記載されている技術的基準が満たされていると見なされる場合、Reliable Multicastプロポーザル公開の手順は、デフォルトのRFCステータスがExperimentalになります。基準と手順の両方が、信頼できるマルチキャストテクノロジーの現在の状態に関するADの技術評価を反映しています。提案の起源は反映されていません。これは、最初の製品を提供する商用ベンダーと研究者のどちらからも同じように予想されます。
Work on the development and engineering of protocols that may eventually meet the review criteria could take place either in the IRTF Reliable Multicast Research Group (http://www.irtf.org) or a focused short IETF WG with an Experimental product.
最終的にレビュー基準を満たす可能性のあるプロトコルの開発とエンジニアリングに関する作業は、IRTF Reliable Multicast Research Group（http://www.irtf.org）または実験的な製品を使用した集中的なIETF WGのいずれかで行うことができます。
When the work in reliable multicast technology has matured enough to be considered for standardization within the IETF, the TSV Area may charter appropriate working groups to develop standards track documents. The criteria for evaluation of standards track technology will be at least as stringent as those described herein (next section).
信頼性の高いマルチキャストテクノロジでの作業がIETF内での標準化を検討するのに十分成熟した場合、TSVエリアは適切なワーキンググループを設立し、標準化追跡ドキュメントを開発する場合があります。スタンダードトラックテクノロジーの評価基準は、少なくともここで説明するものと同じくらい厳しくなります（次のセクション）。
The Internet-Draft must (in itself or a companion draft):
インターネットドラフトは（それ自体またはコンパニオンドラフトで）必要があります。
a. Analyze the behavior of the protocol. The vulnerabilities and performance problems must be shown through analysis. Especially the protocol behavior must be explained in detail with respect to scalability, congestion control, error recovery, and robustness.
a. プロトコルの動作を分析します。脆弱性とパフォーマンスの問題は、分析を通じて示す必要があります。特に、プロトコルの動作は、スケーラビリティ、輻輳制御、エラー回復、および堅牢性に関して詳細に説明する必要があります。
For example the following questions should be answered:
たとえば、次の質問に答える必要があります。
How scalable is the protocol to the number of senders or receivers in a group, the number of groups, and wide dispersion of group members?
プロトコルは、グループ内の送信者または受信者の数、グループの数、およびグループメンバーの幅広い分散に対してどの程度拡張可能ですか？
Identify the mechanisms which limit scalability and estimate those limits.
スケーラビリティを制限するメカニズムを特定し、それらの制限を推定します。
How does the protocol protect the Internet from congestion? How well does it perform? When does it fail? Under what circumstances will the protocol fail to perform the functions needed by the applications it serves? Is there a congestion control mechanism? How well does it perform? When does it fail? Note that congestion control mechanisms that operate on the network more aggressively than TCP will face a great burden of proof that they don't threaten network stability.
プロトコルはどのようにしてインターネットを輻輳から保護しますか？それはどれくらいうまく機能しますか？いつ失敗しますか？どのような状況で、プロトコルは、プロトコルが提供するアプリケーションに必要な機能を実行できませんか？輻輳制御メカニズムはありますか？それはどれくらいうまく機能しますか？いつ失敗しますか？ TCPよりも積極的にネットワーク上で動作する輻輳制御メカニズムは、ネットワークの安定性を脅かさないという証拠の大きな負担に直面することに注意してください。
b. Include a description of trials and/or simulations which support the development of the protocol and the answers to the above questions.
b. プロトコルの開発をサポートする試験および/またはシミュレーションの説明と上記の質問への回答を含めます。
c. Include an analysis of whether the protocol has congestion avoidance mechanisms strong enough to cope with deployment in the Global Internet, and if not, clearly document the circumstances in which congestion harm can occur. How are these circumstances to be prevented?
c. プロトコルに、グローバルインターネットでの展開に対処するのに十分な強さの輻輳回避メカニズムがあるかどうかの分析を含め、そうでない場合は、輻輳の害が発生する可能性がある状況を明確に文書化します。これらの状況はどのように防止されますか？
d. Include a description of any mechanisms which contain the traffic within limited network environments. If the analysis in a or c shows that the protocol has potential to damage the Internet, then the analysis must include a discussion of ways to limit the scope or otherwise contain the protocol. We recognize that the confinement of Internet applications is an open research area.
d. 限られたネットワーク環境内のトラフィックを含むメカニズムの説明を含めます。 aまたはcの分析で、プロトコルがインターネットに損傷を与える可能性があることが示された場合、分析には、範囲を制限する方法またはプロトコルを含める方法の説明を含める必要があります。インターネットアプリケーションの制限は、オープンな研究分野であると認識しています。
e. Reliable multicast protocols must include an analysis of how they address a number of security and privacy concerns. If the protocol can be used in different modes of secure operation, then each mode must be analyzed.
e. 信頼性の高いマルチキャストプロトコルには、セキュリティとプライバシーに関する多くの問題に対処する方法の分析が含まれている必要があります。プロトコルが安全な動作の異なるモードで使用できる場合、各モードを分析する必要があります。
The analysis must document which of the various parties -- senders, routers (more generally, data forwarders), receivers, retransmission sources -- must be trusted in order to ensure secure operation and privacy of the transmitted data, to what degree, and why. (One issue to address here are "man-in-the-middle" attacks.)
分析では、送信されたデータの安全な運用とプライバシーを保証するために、送信者、ルーター（より一般的には、データフォワーダー）、受信者、再送信元など、さまざまな関係者のどれが、どの程度、なぜ信頼されているかを文書化する必要があります。 。 （ここで対処する1つの問題は「中間者」攻撃です。）
To what degree can data be manipulated so that at least a subset of the receivers receive different copies? Does the protocol allow a group of receivers to determine whether they all received the same data?
受信者の少なくともサブセットが異なるコピーを受信するように、データをどの程度操作できますか？このプロトコルでは、受信者のグループが、すべてが同じデータを受信したかどうかを判断できますか？
What limitations are placed on the retransmission mechanism to prevent it from being abused to flood network links with excessive traffic? Which parties must be trusted to ensure this, and to what degree, and why? The presumption will be that either a congestion control mechanism will inherently limit the volume of retransmission traffic, and that this limiting influence is robust under concerted attack; or that retransmission requests will be signed in a cryptographically strong manner so that abuses of the mechanism can be traced back to their source. Protocols that do not provide either of these forms of protection face a great burden of proof that they don't threaten network stability.
過度のトラフィックでネットワークリンクをフラッディングするために再送信メカニズムが悪用されるのを防ぐために、再送信メカニズムにはどのような制限がありますか？これを確実にするためにどの当事者を信頼する必要があり、どの程度、なぜですか？推定は、輻輳制御メカニズムが本質的に再送信トラフィックの量を制限し、この制限の影響が協調攻撃の下で強固であるということです。または、メカニズムの悪用をその送信元までたどることができるように、再送要求は暗号的に強力な方法で署名されます。これらの保護のいずれの形式も提供しないプロトコルは、ネットワークの安定性を脅かさないことを証明する大きな負担に直面します。
What sort of key management does the protocol require, and provide for?
プロトコルはどのような種類のキー管理を必要とし、提供しますか？
This memo specifies in Section 5.e. that reliable multicast Internet-Drafts reviewed by the Transport Area Directors must explicitly explore the security aspects of the proposed design.
このメモは、セクション5.eで指定されています。トランスポートエリアディレクターによってレビューされた信頼性の高いマルチキャストインターネットドラフトは、提案された設計のセキュリティ面を明示的に調査する必要があります。
Sally Floyd, Steve McCanne, Mark Handley, Steve Bellovin and Mike Reiter gave especially helpful comments on drafts of this document.
Sally Floyd、Steve McCanne、Mark Handley、Steve Bellovin、Mike Reiterは、このドキュメントのドラフトに対して特に役立つコメントをしました。
[RMMinutes 1997] Minutes the Second Reliable Multicast Research
Group Meeting. September 1997. http://www.east.isi.edu/rm
[Floyd97] Floyd, S., Jacobson, V., Liu, C., McCanne, S., and Zhang, L., A Reliable Multicast Framework for Light-weight Sessions and Application Level Framing. IEEE/ACM Transactions on Networking, December 1997 An online version of the paper is at http://ee.lbl.gov/floyd/srm-paper.html.
[Floyd97] Floyd、S.、Jacobson、V.、Liu、C.、McCanne、S.、およびZhang、L.、軽量セッションおよびアプリケーションレベルフレーミング用の信頼性の高いマルチキャストフレームワーク。 IEEE / ACM Transactions on Networking、1997年12月論文のオンライン版はhttp://ee.lbl.gov/floyd/srm-paper.htmlにあります。
[InetStdProc96] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, October 1996.
[InetStdProc96] Bradner、S.、「インターネット標準プロセス-リビジョン3」、RFC 2026、1996年10月。
[DiffServBOF97] [6] http://www.ietf.org/proceedings/97apr - Transport Area - FDDIFS BOF, April 1997.
[DiffServBOF97] [6] http://www.ietf.org/proceedings/97apr-Transport Area-FDDIFS BOF、1997年4月。
[DeprRFCs] Freier, A., "Multicast Transport Protocol", RFC 1301, February 1992. and Braudes, R., and S. Zabele, "Requirements for Multicast Protocols", RFC 1458, May 1993.
[DeprRFCs] Freier、A。、「Multicast Transport Protocol」、RFC 1301、1992年2月。Braudes、R。、およびS. Zabele、「Requirements for Multicast Protocols」、RFC 1458、1993年5月。
[DiotCrow97] Diot, C., Crowcroft, J., Multicast Transport Survey. Journal of Selected Areas in Communications, 1997.
[DiotCrow97] Diot、C.、Crowcroft、J.、Multicast Transport Survey。通信の選択された領域のジャーナル、1997年。
[Obraczka98] Obraczka, K., Multicast Transport Mechanisms: A Survey and Taxonomy. To appear in IEEE Communications, 1998.
[Obraczka98] Obraczka、K.、マルチキャストトランスポートメカニズム：調査と分類。 IEEE Communications、1998年に出演します。
[Routing91] Hinden, R., and Internet Engineering Task Force, "Internet Routing Protocol Standardization Criteria", RFC 1264, October 1991.
[Routing91] Hinden、R.、およびInternet Engineering Task Force、「Internet Routing Protocol Standardization Criteria」、RFC 1264、1991年10月。
[CongAvoid97] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms", RFC 2001, January 1997.
[CongAvoid97] Stevens、W。、「TCPスロースタート、輻輳回避、高速再送信、および高速回復アルゴリズム」、RFC 2001、1997年1月。
[Jacobson 1988] Jacobson, V., Congestion Avoidance and Control, Proceedings of SIGCOMM '88, August 1988, pp. 314-329. An updated version of this paper is available at "ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z".
[Jacobson 1988] Jacobson、V。、輻輳回避および制御、SIGCOMM '88の議事録、1988年8月、ページ314-329。このペーパーの更新版は、「ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z」から入手できます。
Allison Mankin - Past TSV Area Director USC/ISI East 4350 N. Fairfax Dr., Suite 620 Arlington VA 22203 USA
Allison Mankin-元TSVエリアディレクターUSC / ISI East 4350 N. Fairfax Dr.、Suite 620 Arlington VA 22203 USA
Phone: 703 812 3706 EMail: mankin@east.isi.edu
電話：703 812 3706メール：mankin@east.isi.edu
Allyn Romanow - Past TSV Area Director MCI Corporation 2560 North First Street San Jose, CA 9531 USA
Allyn Romanow-MCI Corporation元TSVエリアディレクター2560 North First Street San Jose、CA 9531 USA
Phone: 408 922 7143 EMail: allyn@mci.net
電話：408 922 7143メール：allyn@mci.net
Scott Bradner - TSV Co-Area Director Harvard University 1350 Mass. Ave., Rm. 876 Cambridge MA 02138 USA
スコットブラドナー-ハーバード大学TSVコエリアディレクター1350 Mass。Ave.、Rm。 876 Cambridge MA 02138 USA
Phone: 617 495 3864 EMail: sob@harvard.edu
電話：617 495 3864メール：sob@harvard.edu
Vern Paxson - TSV Co-Area Director MS 50B/2239 Lawrence Berkeley National Laboratory University of California Berkeley, CA 94720 USA
Vern Paxson-TSVコエリアディレクターMS 50B / 2239ローレンスバークレー国立研究所カリフォルニア大学バークレー、カリフォルニア94720米国
Phone: 510-486-7504 EMail: vern@ee.lbl.gov
電話：510-486-7504メール：vern@ee.lbl.gov
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。