RFC2357 日本語訳

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

コメントを求めるワーキンググループA.マンキンの要求をネットワークでつないでください: 2357年のUSC/ISIカテゴリ: TSV領域管理職1998年6月がある情報のA.のMCI S.ブラドナーハーバード大学V.パクソンRomanow LBL

       IETF Criteria for Evaluating Reliable Multicast Transport
                       and Application Protocols

信頼できるマルチキャスト輸送とアプリケーション・プロトコルを評価するIETF評価基準

Status of this Memo

この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)インターネット協会(1998)。 All rights reserved。

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のTransport Area(TSV)の中で信頼できるマルチキャストプロトコルを見直す手順と評価基準について説明します。 今日のインターネットの中では、重要な利用は信頼できるマルチキャストサービスのために存在しています。 運転する信頼できるマルチキャスト技術であるいくつかの例が、協力的なワークスペース(ホワイトボードなどの)と、データと、ソフトウェア配布と、(より投機的)ウェブキャッシュプロトコルです。 専門的な問題の本質のために、信頼できるマルチキャストのすべての要求を解決するただ一つの一般的に受け入れられた技術的解決法は実行不可能である[RMMinutes1997]傾向があります。

   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?

様々なタイプのアプリケーションのためのさまざまな問題を解決するために既に多くの信頼できるマルチキャストプロトコルを開発してあります。 [Floyd97]は1つの広く配備された例について説明します。 これらのプロトコルはIETFの中でどのように扱われるべきであるか、そして、IETFはどのように一般的なインターネットに、有益な方向への信頼できるマルチキャストの開発を案内するはずですか?

Mankin, et. al.              Informational                      [Page 1]

RFC 2357             Evaluating Reliable Multicast             June 1998

etマンキン、アル。 信頼できるマルチキャスト1998年6月を評価する情報[1ページ]のRFC2357

   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.

TSV Areaディレクターと彼らのDirectorateはインターネット草稿のRFCsとして信頼できるマルチキャストトランスポート・プロトコルに公表にこれらの質問を記述して、評価基準と過程を設定する1セットのレビュー手順について概説しました。

1.0 Background on IETF Processes and Procedures

1.0 IETFの過程と手順に関するバックグラウンド

   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では、領域での仕事は、Areaディレクター(ADs)によって指示されて、管理されます。(そのディレクターは、ワーキンググループ(WGs)の特許の上で権限があります)。

   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].

さらに、ADsレビューが公表の前にRFCsとしてそれらの領域に関連している仕事に関して個別にインターネット草稿を提出した、(どんなWGsでも、そうしません)(実験的である、InformationalかたまにはStandards Track) インターネットStandards Process、RFC2026[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 ADsによって使用される評価基準を提示することです。

   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-Dsに関してはこれらの評価基準を満たさなければならない、さもなければ、ADsは公表を防ぐために十分であるドキュメントの公表を支持するのを断るでしょう。 ExperimentalかInformationalとして提出されたI-Dsに関してはこれらの評価基準を満たさなければならない、最小限で、さもなければ、プロトコルがこれらの評価基準に従わないと述べながら、AdsはIESG注意がprependedされている状態でI-Dを発行することを勧めるでしょう。

2.0 Introduction

2.0 序論

   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のものが必ずマルチキャストのグループ配送モデルに好きであるのではなく、配送保証を加えます。 第38IETFで召集されたインターネットの何人かの大口使用者の委員会は彼らの最も批判的な要件[DiffServBOF97]の1つとして信頼できるバルク転送マルチキャストについて明確に話しました。 信頼できる大量のマルチキャスト転送を使用できたアプリケーションに関する例は協力的なツール、分配されたバーチャルリアリティ、およびソフトウェアの更新サービスを含んでいます。

   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

信頼できるマルチキャストを求める高まる需要を満たすために、多くのプロトコル提案があります。 信頼できるマルチキャストからの混雑の影響が完全に発行される前にいくつかはRFCsとして発行されました。

Mankin, et. al.              Informational                      [Page 2]

RFC 2357             Evaluating Reliable Multicast             June 1998

etマンキン、アル。 信頼できるマルチキャスト1998年6月を評価する情報[2ページ]のRFC2357

   appreciated, and these should be deprecated [DeprRFCs].  Two surveys
   of other publications are [DiotCrow97], [Obraczka98].

感謝、これらは非難されるべきです[DeprRFCs]。 [Obraczka98]、他の刊行物の2つの調査が[DiotCrow97]です。

   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.

専門的な問題の複雑さ、および提案された解決策の豊富のために、私たちはいつもより明白なレビュー手順を適所に置いています。 標準のインターネットダイナミックルーティングプロトコルの共同体経験がまだ制限されていて、余分なレビューが保証するのに必要であると考えられたときのプロトコルが導入したRFC1264[Routing91]は、私たちが1991年に取られた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として発行されるという提案で会われる必要がある追加要件を詳しく述べます。

3.0 Issues in Reliable Multicast

3.0 信頼できるマルチキャストにおける問題

   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つの局面で、標準化は特にやりがいがあるようになります。 まず最初に、信頼性の意味は異なったアプリケーションの文脈で異なります。 第二に、特別な注意が払われないなら、信頼できるマルチキャストプロトコルは今日の世界的なインターネットの操作への特定の脅威を引き起こす場合があります。 このセクションで詳細にこれらの問題について議論します。

3.1 One or Many Reliable Multicast Protocols or Frameworks?

3.1 1、多くの信頼できるマルチキャストプロトコルであるまたは枠組みですか?

   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)が現在さまざまなアプリケーションの信頼できる配信需要を満たすのに使用されるところで信頼できるマルチキャストは必ず単一のアプリケーション・インターフェース、または、基本的な1セットのメカニズムにそれ自体を貸すというわけではありません。ユニキャスト輸送において、信頼できて、配列されたデータ配送のための要件はかなり一般的です。 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

対照的に、異なったマルチキャストアプリケーションには、信頼性のためのはなはだしく異なった要件があります。 例えば、いくつかのアプリケーションが、メッセージ配送が他のものが注文していない間に注文される合計に従うのを必要とします。 いくつかのアプリケーションで、他のものが1個のデータ送信端末しか持っていない間、多くかすべてのメンバーがデータを送ります。 いくつかのアプリケーションが模写してあります。

Mankin, et. al.              Informational                      [Page 3]

RFC 2357             Evaluating Reliable Multicast             June 1998

etマンキン、アル。 信頼できるマルチキャスト1998年6月を評価する情報[3ページ]のRFC2357

   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.

例えば、n余分なファイル店のデータであって、数人のメンバーがデータ項目を伝えることができますが、すべてのデータが他のもののために単独のソースで由来します。 いくつかのアプリケーションが小さい固定会員資格マルチキャストグループに制限されます、他のアプリケーションは、ダイナミックに数千か何万人ものメンバー(ことによるとさらに)に比例する必要がありますが。 いくつかのアプリケーションには、厳しい遅れ要件がありますが、他のものはそうしません。 ファイル転送などのいくつかの応用が高帯域です、対話的な共同ツールなどの他のアプリケーションは、burstyですが、全体的に見て低い帯域幅をより使用しそうですが。 いくつかのアプリケーションが、よりタイムリーな配送のために信頼性を完成するより時々以下を交換するでしょう。 これらの要件はそれぞれ異なった方法で信頼できるマルチキャストプロトコルのデザインに影響を与えます。

   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つの挑戦がアプリケーションの要件と信頼できるマルチキャストメカニズムとの右の照合で終わることになっています。ただ一つの信頼できるマルチキャストプロトコルか枠組みがそうでない一般協定がすべてのインターネットアプリケーションの需要を満たしそうな状態でありますが、アプリケーション決められた一定の要求と、より一般的な基本的な信頼できるmutlicastプロトコルかメカニズムとの正確な関係に関する、より少ない理解と協定があります; アプリケーションと基本的な信頼できるマルチキャスト枠組みの間の適切な統合、およびその枠組みのための単一のアプリケーションインタフェースの潜在的一般性に関する未決問題もあります。

3.2 Congestion Control

3.2 輻輳制御

   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交通への信頼できるマルチキャスト交通の効果です。 インターネットの成功は、ネットワークに提示された負荷を減少させることによって、最も良い努力交通がリンクの上に混雑に応じるという(現在、パケット滴によって示されるように)事実を当てにします。 今日のインターネットでの混雑崩壊はRFC2001[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

特に注意深く信頼できるマルチキャスト提案で提起された混雑関連の問題になる多くの理由があります。 一般に、マルチキャストアプリケーションには、さらにする可能性があります。

Mankin, et. al.              Informational                      [Page 4]

RFC 2357             Evaluating Reliable Multicast             June 1998

etマンキン、アル。 信頼できるマルチキャスト1998年6月を評価する情報[4ページ]のRFC2357

   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.

さらに、高信頼のマルチキャストアプリケーションで、自然な期間制限は必ず現在の頼り無いマルチキャストアプリケーションの典型になるというわけではありません。 ファイル転送アプリケーションのために、例えば、データ転送はデータのすべてを所定の受信者のすべてに移すまで続くかもしれません、個々の流れのための潜在的に無期限をもたらして。 高信頼のマルチキャストアプリケーションもコントロール交通(例えば、ACKs、NACKs、ステータスメッセージ)の複雑なパターンの潜在的爆発を競争しなければなりません。 現在、大きいマルチキャストグループにおいて、信頼できるマルチキャストのための混雑制御機構のデザインは活発な研究の領域です。

   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

個別に提出されたインターネット草稿(IETF WGによって起こされなかった提案)の一般的な場合では、RFCのタイプとしての公表の過程がRFC2026で説明される、(4.2、.3、)、[InetStdProc96。] 提出されたインターネット草稿が密接に行われる仕事に関連されるか、またはIETFですると予想されるなら、これはそれを指定します。

Mankin, et. al.              Informational                      [Page 5]

RFC 2357             Evaluating Reliable Multicast             June 1998

etマンキン、アル。 信頼できるマルチキャスト1998年6月を評価する情報[5ページ]のRFC2357

   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.

ADsはドキュメントがIETFの範囲内に収められて、IETF文脈で進行されることを勧めるかもしれません。 さもなければ、ADsは、インターネット草稿がExperimentalかInformational RFCとして発表されることを勧めるかもしれません、IETF文脈との関係のIESG注釈のあるなしにかかわらず。

   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.

Reliable Multicast提案公表のための手順にデフォルトRFC状態としてExperimentalがあるでしょう、セクション5に記載された技術的な評価基準が実現すると考えられるとき。 評価基準と手順の両方がAD'sの信頼できるマルチキャスト技術の現状の技術的な査定を反映します。 それは初期の製品をもっている商業業者と研究者から提案の起源を反映しません。(私たちは等しくそうになると起源を予想します)。

   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でExperimental製品で行われることができました。

   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 Areaは、標準化過程ドキュメントを開発するために適切なワーキンググループをチャーターするかもしれません。 標準化過程技術の評価基準はものがここに(次のセクション)説明したのと少なくとも同じくらい厳しいでしょう。

5. Technical Criteria for Reliable Multicast

5. 信頼できるマルチキャストの技術的な評価基準

   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?

プロトコルは混雑からインターネットをどのように保護しますか? それはどれくらいよく働きますか? それはいつ失敗しますか?

Mankin, et. al.              Informational                      [Page 6]

RFC 2357             Evaluating Reliable Multicast             June 1998

etマンキン、アル。 信頼できるマルチキャスト1998年6月を評価する情報[6ページ]のRFC2357

         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。 プロトコルで輻輳回避メカニズムがGlobalインターネットで展開に対処できるくらい強くなるかどうかに関する分析を含めてください、そして、そうでなければ、明確に、混雑害が起こることができる事情を記録してください。 これらの事情によってどのように防がれることになっていますか?

   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.)

色々とをパーティーへ行かせる必須が記録する分析--送付者、ルータ、(より多く、一般にデータ混載業者、)、受信機、「再-トランスミッション」ソース--信じなければならないのは伝えられたデータの安全な操作とプライバシーを確実にします、どの程度に、そして、なぜであるか。 (ここに記述するある問題がそうである、「中の男性、-、-、中央、」、攻撃)。

         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

どんな制限が、それが過度の交通とのネットワークリンクをあふれさせるように乱用されるのを防ぐために「再-トランスミッション」メカニズムに置かれますか? どのパーティーがこれを確実にすると信じられて、どの程度になぜでなければならないか、そして、なぜですか? 推定は混雑制御機構が本来「再-トランスミッション」交通のボリュームを制限するということであるだろう、それはこの制限です。

Mankin, et. al.              Informational                      [Page 7]

RFC 2357             Evaluating Reliable Multicast             June 1998

etマンキン、アル。 信頼できるマルチキャスト1998年6月を評価する情報[7ページ]のRFC2357

         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.

影響は協定している攻撃で体力を要します。 または、その「再-トランスミッション」は、暗号で、それが乱用するメカニズムのそうが強い方法であることができることがサインされたコネがaであるつもりであったなら彼らのソースを突きとめたよう要求します。 これらのフォームのどちらの保護表面にも彼らが脅かさないすばらしい立証責任を提供しないプロトコルが安定性をネットワークでつなぎます。

         What sort of key management does the protocol require, and
         provide for?

プロトコルは、どういうかぎ管理を必要であり、備えますか?

6. Security Considerations

6. セキュリティ問題

   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.でTransport Areaディレクターによって見直された信頼できるマルチキャストインターネット草稿が明らかに提案されたデザインのセキュリティ局面を探検しなければならないと指定します。

7. Acknowledgments

7. 承認

   Sally Floyd, Steve McCanne, Mark Handley, Steve Bellovin and Mike
   Reiter gave especially helpful comments on drafts of this document.

サリー・フロイド、スティーブMcCanne、マーク・ハンドレー、スティーブBellovin、およびマイクReiterはこのドキュメントの草稿のときに特に役に立つコメントを与えました。

8. References

8. 参照

   [RMMinutes 1997]  Minutes the Second Reliable Multicast Research
   Group Meeting.  September 1997.  http://www.east.isi.edu/rm

[RMMinutes1997]は第2信頼できるマルチキャスト研究グループ会議を書き留めます。 9月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]フロイドとS.とジェーコブソンとV.とリュウとC.とMcCanne、S.とチャン、L.、信頼できるマルチキャスト枠組み。 Networkingの上のIEEE/ACM Transactionsであり、紙の1997年12月のAnのオンラインバージョンが http://ee.lbl.gov/floyd/srm-paper.html にあります。

   [InetStdProc96]  Bradner, S., "The Internet Standards Process --
   Revision 3", RFC 2026, October 1996.

[InetStdProc96] ブラドナー、S.、「改正3インチ、RFC2026、1996年インターネット標準化過程--10月。」

   [DiffServBOF97]  [6] http://www.ietf.org/proceedings/97apr -
   Transport Area - FDDIFS BOF, April 1997.

[DiffServBOF97][6] http://www.ietf.org/proceedings/97apr --領域を輸送してください--FDDIFS転炉、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]フライア(A.、「マルチキャストトランスポート・プロトコル」、RFC1301(1992年2月)、およびBraudes、R.とS.Zabele、「マルチキャストプロトコルのための要件」RFC1458)は、1993がそうするかもしれません。

   [DiotCrow97] Diot, C., Crowcroft, J., Multicast Transport Survey.
   Journal of Selected Areas in Communications, 1997.

[DiotCrow97] Diot、C.、クロウクロフト、J.、マルチキャスト輸送調査。 コミュニケーション、1997年の選択された領域のジャーナル。

   [Obraczka98] Obraczka, K., Multicast Transport Mechanisms: A Survey
   and Taxonomy.  To appear in IEEE Communications, 1998.

[Obraczka98] Obraczka、K.、マルチキャスト移送機構: 調査と分類学。 IEEE Communications、1998に現れるように。

Mankin, et. al.              Informational                      [Page 8]

RFC 2357             Evaluating Reliable Multicast             June 1998

etマンキン、アル。 信頼できるマルチキャスト1998年6月を評価する情報[8ページ]のRFC2357

   [Routing91] Hinden, R., and Internet Engineering Task Force,
   "Internet Routing Protocol Standardization Criteria", RFC 1264,
   October 1991.

[Routing91] Hinden、R.とインターネット・エンジニアリング・タスク・フォース、「インターネットルーティング・プロトコル標準化評価基準」、RFC1264、1991年10月。

   [CongAvoid97] Stevens, W., "TCP Slow Start, Congestion Avoidance,
   Fast Retransmit, and Fast Recovery Algorithms", RFC 2001, January
   1997.

[CongAvoid97] スティーブンスと、W.と、「遅れた出発、輻輳回避が速く再送するTCP、および速い回復アルゴリズム」、RFC2001、1月1997日

   [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".

SIGCOMM88年、1988年8月、ページの[ジェーコブソン1988]ジェーコブソンとV.とCongestion AvoidanceとControl、Proceedings 314-329. この紙のアップデートされたバージョンは" ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z "で利用可能です。

Mankin, et. al.              Informational                      [Page 9]

RFC 2357             Evaluating Reliable Multicast             June 1998

etマンキン、アル。 信頼できるマルチキャスト1998年6月を評価する情報[9ページ]のRFC2357

9. Authors' Addresses

9. 作者のアドレス

   Allison Mankin - Past TSV Area Director
   USC/ISI East
   4350 N. Fairfax Dr., Suite 620
   Arlington VA 22203
   USA

TSV USC/ISI東4350N.フェアファクスAreaディレクタースイート620アーリントンヴァージニア22203博士(米国)の先のアリソン・マンキン

   Phone: 703 812 3706
   EMail: mankin@east.isi.edu

以下に電話をしてください。 3706年の703 812メール: mankin@east.isi.edu

   Allyn Romanow - Past TSV Area Director
   MCI Corporation
   2560 North First Street
   San Jose, CA 9531
   USA

TSV領域ディレクターMCI社2560の北の最初に、通りサンノゼ(カリフォルニア)9531米国の先のアリンRomanow

   Phone: 408 922 7143
   EMail: allyn@mci.net

以下に電話をしてください。 7143年の408 922メール: allyn@mci.net

   Scott Bradner - TSV Co-Area Director
   Harvard University
   1350 Mass. Ave., Rm. 876
   Cambridge MA 02138
   USA

スコット・ブラドナー--TSV共同領域ディレクターハーバード大学1350マサチューセッツ州 Ave、Rm。 876 ケンブリッジMA02138米国

   Phone: 617 495 3864
   EMail: sob@harvard.edu

以下に電話をしてください。 3864年の617 495メール: sob@harvard.edu

   Vern Paxson - TSV Co-Area Director
   MS 50B/2239
   Lawrence Berkeley National Laboratory
   University of California
   Berkeley, CA 94720
   USA

バーン・パクソン--国家の研究所カリフォルニア大学バークレー、TSV共同領域のディレクターMS50B/2239ローレンス・カリフォルニア94720米国バークレー

   Phone: 510-486-7504
   EMail: vern@ee.lbl.gov

以下に電話をしてください。 510-486-7504 メールしてください: vern@ee.lbl.gov

Mankin, et. al.              Informational                     [Page 10]

RFC 2357             Evaluating Reliable Multicast             June 1998

etマンキン、アル。 信頼できるマルチキャスト1998年6月を評価する情報[10ページ]のRFC2357

10.  Full Copyright Statement

10. 完全な著作権宣言文

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Copyright(C)インターネット協会(1998)。 All rights reserved。

   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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Mankin, et. al.              Informational                     [Page 11]

etマンキン、アル。 情報[11ページ]