RFC1458 日本語訳
1458 Requirements for Multicast Protocols. R. Braudes, S. Zabele. May 1993. (Format: TXT=48106 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Braudes
Request for Comments: 1458 S. Zabele
TASC
May 1993
Braudesがコメントのために要求するワーキンググループR.をネットワークでつないでください: 1458秒間Zabele TASC1993年5月
Requirements for Multicast Protocols
マルチキャストプロトコルのための要件
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。
Summary
概要
Multicast protocols have been developed over the past several years to address issues of group communication. Experience has demonstrated that current protocols do not address all of the requirements of multicast applications. This memo discusses some of these unresolved issues, and provides a high-level design for a new multicast transport protocol, group address and membership authority, and modifications to existing routing protocols.
マルチキャストプロトコルはグループコミュニケーションの問題を記述する過去数年間開発されています。 経験は、現在のプロトコルがマルチキャストアプリケーションの要件のすべてを記述しないのを示しました。 このメモは、これらの未解決問題のいくつかについて議論して、新しいマルチキャストトランスポート・プロトコル、グループアドレス、および会員資格権威のための高位設計、および既存のルーティング・プロトコルへの変更を提供します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Image Communication Problem . . . . . . . . . . . . . 2
2.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . 3
3. Review of Existing Multicast Protocols . . . . . . . . . . 4
3.1 IP/Multicast . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 XTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3 ST-II . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4 MTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Reliable Adaptive Multicast Service . . . . . . . . . . . 9
4.1 The Multicast Group Authority . . . . . . . . . . . . . . 9
4.1.1 Address Management . . . . . . . . . . . . . . . . . . . . 9
4.1.2 Service Registration, Requests, Release, and Group
Membership Maintenance . . . . . . . . . . . . . . . . . . 10
4.2 The Reliable Adaptive Multicast Protocol (RAMP) . . . . . 11
4.2.1 Quality of Service Levels . . . . . . . . . . . . . . . . 12
4.2.2 Error Recovery . . . . . . . . . . . . . . . . . . . . . . 12
4.2.3 Flow Control . . . . . . . . . . . . . . . . . . . . . . . 13
4.3 Routing Support . . . . . . . . . . . . . . . . . . . . . 14
4.3.1 Path Set-up . . . . . . . . . . . . . . . . . . . . . . . 14
4.3.2 Path Tear-down . . . . . . . . . . . . . . . . . . . . . . 15
1. 序論. . . . . . . . . . . . . . . . . . . . . . . 2 2。 範囲.22.2のイメージ意思疎通の問題. . . . . . . . . . . . . 2 2.1要件. . . . . . . . . . . . . . . . . . . . . . . 3 3。 既存のマルチキャストプロトコル. . . . . . . . . . 4 3.1IP/マルチキャスト. . . . . . . . . . . . . . . . . . . . . . . 4 3.2XTP. . . . . . . . . . . . . . . . . . . . . . . . . . . 5標準時3.3II.63.4MTP. . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.5概要. . . . . . . . . . . . . . . . . . . . . . . . . 8 4のレビュー。 信頼できる適応型のマルチキャストは.94.1にマルチキャストグループ権威. . . . . . . . . . . . . . 9 4.1.1アドレス管理. . . . . . . . . . . . . . . . . . . . 9 4.1.2サービス登録、要求、リリース、およびグループ会員資格維持. . . . . . . . . . . . . . . . . . 10 4.2を修理します。信頼できる適応型のマルチキャストプロトコル(斜面。). . . . . 11 4.2; 1 サービスレベル. . . . . . . . . . . . . . . . 12 4.2.2エラー回復. . . . . . . . . . . . . . . . . . . . . . 12 4.2.3フロー制御. . . . . . . . . . . . . . . . . . . . . . . 13 4.3ルート設定サポート. . . . . . . . . . . . . . . . . . . . . 14 4.3.1経路セットアップ. . . . . . . . . . . . . . . . . . . . . . . 14 4.3.2経路分解. . . . . . . . . . . . . . . . . . . . . . 15の品質
Braudes & Zabele [Page 1] RFC 1458 Requirements for Multicast Protocols May 1993
マルチキャストプロトコル1993年5月のためのBraudes&Zabele[1ページ]RFC1458要件
4.3.3 Multicast Routing Based on Quality of Service . . . . . . 15 4.3.4 Quality of Service Based Packet Loss . . . . . . . . . . . 15 5. Interactions Among the Components: An Example . . . . . . 15 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Security Considerations . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
4.3.3 マルチキャストルート設定は.4のサービスの質のベースのパケット損失. . . . . . . . . . . 15 5をサービスの質. . . . . . 15 4.3に基礎づけました。 コンポーネントの中の相互作用: 例の.15の承認. . . . . . . . . . . . . . . . . . . . . . . . 18参照. . . . . . . . . . . . . . . . . . . . . . . . . . . 18セキュリティ問題. . . . . . . . . . . . . . . . . . . . 19作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
1. 序論
Multicast protocols have been developed to support group communications. These protocols use a one-to-many paradigm for transmission, typically using class D Internet Protocol (IP) addresses to specify specific multicast groups. While designing network services for reliable transmission of very large imagery as part of the DARPA-sponsored ImNet program, we have reviewed existing multicast protocols and have determined that none meet all of the requirements of image communications [3]. This RFC reviews the current state of multicast protocols, highlights the missing features, and motivates the design and development of an enhanced multicast protocol.
サポートグループコミュニケーションにマルチキャストプロトコルを開発してあります。 これらのプロトコルはトランスミッションに多くへの1つのパラダイムを使用します、特定のマルチキャストグループを指定するのにクラスDインターネットプロトコル(IP)アドレスを通常使用して。 DARPAによって後援されたImNetプログラムの一部として非常に大きいイメージの信頼できる送信のためのネットワーク・サービスを設計している間、私たちは、既存のマルチキャストプロトコルを見直して、なにもイメージコミュニケーション[3]の要件のすべてに会わないと決心しています。 このRFCはマルチキャストプロトコルの現状について調査して、なくなった特徴を目立たせて、高められたマルチキャストプロトコルのデザインと開発を動機づけます。
First, the requirements for network services and underlying protocols related to image communications are presented. Existing protocols are then reviewed, and an analysis of each protocol against the requirements is presented. The analyses identify the need for a new multicast protocol. Finally, the features of an ideal reliable multicast protocol that adapts to network congestion in the transmission of large data volumes are presented. Additional network components needed to fully support the new protocol, including a Multicast Group Authority and modifications to existing routing protocols, are also introduced.
まず最初に、イメージコミュニケーションに関連するネットワーク・サービスと基本的なプロトコルのための要件は提示されます。 次に、既存のプロトコルは見直されます、そして、要件に対するそれぞれのプロトコルの分析は提示されます。 分析は新しいマルチキャストプロトコルの必要性を特定します。 最終的に、大きいデータボリュームの送信におけるネットワークの混雑に順応する理想的な信頼できるマルチキャストプロトコルの特徴は提示されます。 追加ネットワーク要素をMulticast Group Authorityと既存のルーティング・プロトコルへの変更を含んで、新しいプロトコルを完全にサポートするのが必要であり、また、導入します。
2. The Image Communications Problem
2. イメージコミュニケーション問題
2.1 Scope
2.1 範囲
Image management and communications systems are evolving from film- based systems toward an all-digital environment where imagery is acquired, transmitted, analyzed, and stored using digital computer and communications technologies. The throughput required for communicating large numbers of very large images is extremely large, consisting of thousands of terabytes of imagery per day. Temporal requirements for capture and dissemination of single images are stringent, ranging from seconds to at most several minutes. Imagery will be viewed by hundreds of geographically distributed users who will require on-demand, interactive access to the data.
画像管理と通信網はフィルムのベースのシステムからイメージがディジタルコンピュータと通信技術を使用することで取得されて、伝えられて、分析されて、格納されるオールデジタルの環境に向かって発展しています。 多くの非常に大きいイメージを伝えるのに必要であるスループットは非常に大きいです、1日あたりのイメージの何千ものテラバイトから成って。 秒から高々数分まで及んで、ただ一つのイメージの捕獲と普及のための時の要件は厳しいです。 イメージは要求次第の、そして、対話的なデータへのアクセスを必要とする何百人もの地理的に分配されたユーザによって見られるでしょう。
Braudes & Zabele [Page 2] RFC 1458 Requirements for Multicast Protocols May 1993
マルチキャストプロトコル1993年5月のためのBraudes&Zabele[2ページ]RFC1458要件
Traditional imaging applications involve images on the order of 512 by 512 pixels. In contrast, a single image used for remote sensing can have tens of thousands of pixels on a side. Multiplying the data volume associated with remotely sensed images by even a small number of users clearly motivates moving beyond the current suite of reliable protocols.
伝統的なイメージアプリケーションは512×512画素の注文に関するイメージにかかわります。 対照的に、遠隔探査に使用されるただ一つのイメージは側に何万画素を持つことができます。 明確に少ない数のユーザでさえ離れて感じられたイメージに関連しているデータ量を掛けると、信頼できるプロトコルの現在のスイートを超えた動きは動機づけられます。
Basic image communication applications involve distribution of individual images to multiple users for both individual and collaborative analyses, and network efficiency requires the use of multicast protocols. Areas where multicasting offers significant advantages include real-time image acquisition and dissemination, distribution of annotated image-based reports, and image conferencing. Images are viewed on a heterogeneous set of workstations with differing processing and display capabilities, traveling over a heterogeneous network with bandwidths varying by up to six orders of magnitude between the initial down link and the slowest end user.
基本的なイメージコミュニケーションアプリケーションは個々のものと同様に協力的な分析のために個々のイメージの分配に複数のユーザにかかわります、そして、ネットワーク効率はマルチキャストプロトコルの使用を必要とします。 マルチキャスティングが重要な利点を示す領域がリアルタイムの画像収集と普及を含んで、注釈されることの分配がイメージベースのレポートであり、イメージは会議です。 イメージズは異なった処理と表示能力がある種々雑多なセットのワークステーションの上で見られます、帯域幅が初期の下にリンクと最も遅いエンドユーザの間の最大6桁で異なって異機種ネットワークの上を旅行して。
2.2 Requirements
2.2 要件
Multicast protocols used for image communications must address several requirements. Setting up a multicast group first requires assigning a multicast group address. All multicast traffic is then delivered to this address, which implies that all members of the group must be listening for traffic with this address.
イメージコミュニケーションに使用されるマルチキャストプロトコルはいくつかの要件を記述しなければなりません。 最初にマルチキャストグループを設立するのは、マルチキャストグループアドレスを割り当てるのを必要とします。 そして、すべてのマルチキャスト交通をこのアドレスに提供します。(それは、グループのすべてのメンバーがこのアドレスで交通の聞こうとしなければならないのを含意します)。
Within an image communications architecture such as that used for the ImNet program, diversity and adaptability can be accommodated by trading quality of service (i.e., image quality) with speed of transmission. Multicast support for quality-speed trades can be realized either through the use of different multicast groups, where each group receives a different image quality, or through the use of a single hierarchical stream with routers (or users) extracting relevant portions.
中と、サービスの質(すなわち、画質)をトランスミッションの速度に取り引きすることによって、ImNetプログラム、多様性、および適応性に使用されるそれなどのイメージコミュニケーション構造に対応できます。 異なったマルチキャストグループの使用を通して、または、ルータ(または、ユーザ)が関連部分を抽出しているただ一つの階層的な流れの使用を通して上質の速度取り引きのマルチキャストサポートを実現できます。そこでは、各グループが異なった画質を受けます。
Due to the current inability of routers to support selective transmission of partial streams, a multiple stream approach is being used within ImNet. Efficient operation using a multiple stream approach requires that users be able to switch streams very quickly, and that streams with no listeners not be disseminated. Consequently, rapid configuration of multicast groups and rapid switching between multicast groups switching is essential.
ルータが部分的な流れ、倍数の選択式変速機を支持できない現在のことのため、流れのアプローチはImNetの中で使用されています。 複数の流れのアプローチを使用する効率的な操作は、ユーザが非常に急速に流れを切り換えることができて、リスナーのいない流れが広められないのを必要とします。 その結果、マルチキャストグループの間のマルチキャストグループと急速な切り換えが切り替わる急速な構成は不可欠です。
Inevitably, network congestion or buffer overruns result in packet loss. A full range of transport reliability is required within an image communications framework. For some applications such as image conferencing, packet loss does not present a problem as dropped mouse
必然的に、ネットワークの混雑かバッファ超過がパケット損失をもたらします。 最大限の範囲の輸送の信頼性がイメージコミュニケーション枠組みの中で必要です。 イメージ会議などのいくつかのアプリケーションのために、パケット損失は低下しているマウスとして問題を提示しません。
Braudes & Zabele [Page 3] RFC 1458 Requirements for Multicast Protocols May 1993
マルチキャストプロトコル1993年5月のためのBraudes&Zabele[3ページ]RFC1458要件
movements can be discarded with no meaningful degradation in utility. However, for functions such as image archiving or detailed image analysis, transport must be completely reliable, where any dropped packets must be retransmitted by the sender. Additionally, several hierarchical image compression methods can provide useful, albeit degraded, imagery using a semi-reliable service, where higher level data is transmitted reliably and the lower level data is transmitted unreliably.
ユーティリティにおける重要な退行なしで動きを捨てることができます。 しかしながら、イメージの格納しているか詳細な画像解析などの機能において、輸送は完全に信頼できなければなりません、送付者がどんな低下しているパケットも再送しなければならないところで。 さらに、いくつかの階層的な画像圧縮方法が準信頼できるサービスを利用する役に立って、それにしても、降格しているイメージを供給できます。そこでは、より高い平らなデータが確かに送られて、下のレベルデータは当てにならずに送られます。
In support of reliable transport, image communications services must also support adaptation to network congestion using flow control mechanisms. Flow control regulates the quantity of data placed on the network per unit time interval, thereby increasing network efficiency by reducing the number of dropped packets and avoiding the need for large numbers of retransmissions.
また、信頼できる輸送を支持して、イメージ情報提供サービスは、フロー制御メカニズムを使用することでネットワークの混雑への適合を支持しなければなりません。フロー制御はユニット時間間隔あたりのネットワークに置かれたデータの量を規制します、その結果、低下しているパケットの数を減少させて、多くの「再-トランスミッション」の必要性を避けることによって、ネットワーク効率を増加させます。
3. Review of Existing Multicast Protocols
3. 既存のマルチキャストプロトコルのレビュー
Several existing protocols provide varying levels of support for multicasting, including IP/Multicast [5], the Xpress Transfer Protocol (XTP) [11], and Experimental Internet Stream Protocol Version 2 (ST-II) [10]. While the Versatile Message Transaction Protocol (VMTP) [4] also supports multicast, it has been designed to support the transfer of small packets, and so is not appropriate for large image communications. Additionally, a specification exists for the Multicast Transport Protocol (MTP) [2].
いくつかの既存のプロトコルがマルチキャスティングのための異なったレベルのサポートを提供します、IP/マルチキャスト[5]、エクスプレスTransferプロトコル(XTP)[11]、およびExperimentalインターネットStreamプロトコルバージョン2(ST-II)[10]を含んでいて。 また、Versatile Message Transactionプロトコル(VMTP)[4]はマルチキャストを支持しますが、大きいイメージコミュニケーションには、それは、小型小包の転送を支持するように設計されているので、適切ではありません。 さらに、仕様はMulticast Transportプロトコル(MTP)[2]のために存在しています。
The image communication requirements for a multicast protocol include multicast group address assignment, group set-up, membership maintenance (i.e., join, drop, and switch membership), group tear- down, error recovery, and flow control, as presented above. The remainder of this section discusses how well each of the existing protocols meets these requirements.
マルチキャストプロトコルのためのイメージコミュニケーション要件はグループ裂け目マルチキャストグループアドレス課題、グループセットアップ、会員資格維持(すなわち、接合してください、そして、低下してください、そして、会員資格を切り換える)、下である、エラー回復、およびフロー制御を含んでいます、上に提示されるように。 このセクションの残りは、それぞれの既存のプロトコルがこれらの必要条件をどれくらいよく満たすかと議論します。
3.1 IP/Multicast
3.1 IP/マルチキャスト
IP/Multicast is an extension to the standard IP network-level protocol that supports multicast traffic. IP/Multicast has no address allocation mechanism, with addresses assigned either by an outside authority or by each application. This has the potential for address contention among multiple applications, which would result in the traffic from the different groups becoming commingled.
IP/マルチキャストはマルチキャスト交通を支持する標準のIPネットワークレベルプロトコルへの拡大です。 IP/マルチキャストには、アドレスが外の権威か各アプリケーションで割り当てられているアドレス配分メカニズムが全くありません。 これは複数のアプリケーションの中にアドレス主張の可能性を持っています。アプリケーションは混ぜ合わせられるようになる異なったグループからの交通をもたらすでしょう。
There is no true set-up processing for IP/Multicast; once an address is determined, the sender simply transmits packets to that address with routers determining the path(s) taken by the data. The receiver side is only slightly more complex, as an application must issue an add membership request for IP to listen to traffic destined to the
IP/マルチキャストのためのどんな本当のセットアップ処理もありません。 アドレスがいったん決定するようになると、送付者は、データによって取られた経路を決定しながら、ルータで単にそのアドレスにパケットを伝えます。 受信機側はわずかにだけ複雑です、アプリケーションが発行しなければならないようにIPが運命づけられた交通を聞くという会員資格要求を加えてください。
Braudes & Zabele [Page 4] RFC 1458 Requirements for Multicast Protocols May 1993
マルチキャストプロトコル1993年5月のためのBraudes&Zabele[4ページ]RFC1458要件
desired address. If this is the first member of a group, IP multicasts the request to routers on the local network using the Internet Group Multicast Protocol (IGMP) for inclusion in routing tables. Multicast packets are then routed like all other IP packets, with receivers accepting traffic addressed to joined groups in addition to the normal host address.
必要なアドレス。 これが第1代グループのメンバーであるなら、経路指定テーブルでの包含に、インターネットGroup Multicastプロトコル(IGMP)を使用する地方のルータへの要求がネットワークでつなぐIPマルチキャストです。 次に、マルチキャストパケットは他のすべてのIPパケットのように発送されます、受信機が正常なホスト・アドレスに加えた接合グループに記述された交通を受け入れていて。
A major problem with the IP/Multicast set-up approach is informing hosts of multicast group addresses. If addresses are dynamically allocated, then a mechanism must be established for informing receivers which addresses have been assigned to which groups. This requires a minimum of one round trip time, with an address requested from a server and then returned to the receiver.
IP/マルチキャストセットアップアプローチに関する大した問題はマルチキャストグループアドレスについてホストに知らせています。 ダイナミックにアドレスを割り当てるなら、どのアドレスがどのグループに配属されたかを受信機に知らせるためにメカニズムを確立しなければなりません。 これは最低1周遊旅行時間を必要とします、アドレスをサーバから要求して、次に、受信機に返していて。
Dropping membership in a group involves issuing a request to the local IP, which decrements the count of members in the IP tables. However, no special action is taken when group membership goes to zero. Instead, a heartbeat mechanism is used in which hosts are periodically polled for active groups, and routers stop forwarding group traffic to a network only after several polls receive no activity requests for that group to ensure that a membership report is not lost or corrupted in transit. This causes the problem of unneeded traffic being transmitted, due to a long periodicity for the heartbeat (minimum of one minute between polls); consequently there is no method for quickly dropping a group over a given path, impeding attempts to react to network congestion in real-time.
グループで会員資格を落とすのは、ローカルアイピーに要求を出すことを伴います。(ローカルアイピーはIPテーブルでのメンバーのカウントを減少させます)。 しかしながら、グループ会員資格がゼロまで行くとき、どんな特別な行動も取りません。 代わりに、どのホストが活動的なグループのために定期的に投票されるかで鼓動メカニズムは使用されます、そして、ルータはいくつかの投票がそのグループが会員資格レポートがトランジットで失われてもいませんし、改悪もされないのを保証するという活動要求を全く受け取らなかった後にだけグループ交通をネットワークに送るのを止めます。 これは伝えられる不要な交通の問題を引き起こします、鼓動(投票の間の1分の最小限)のための長い周期性のため。 その結果、すばやく与えられた経路の上にグループを落とすための方法が全くありません、リアルタイムでにおけるネットワークの混雑に反応する試みを妨害して。
Finally, there is no transport level protocol compatible with IP/Multicast that is both reliable and implements a flow control mechanism.
最終的に、ともに信頼できて、フロー制御メカニズムを実行するIP/マルチキャストがあるプロトコルコンパチブルどんな輸送レベルもありません。
3.2 XTP
3.2 XTP
XTP is a combined network and transport level protocol that offers significant support for multicast transfers. As with IP/Multicast, XTP offers no inherent address management scheme, so that an outside authority is required.
XTPは合併しているネットワークであり、輸送レベルはマルチキャスト転送の重要なサポートを提供するプロトコルです。 IP/マルチキャストのように、XTPがどんな固有のアドレス管理計画も提供しないので、外の権威が必要です。
XTP is also similar to IP/Multicast as there is no explicit set-up processing between the sender and the receivers prior to the establishment of group communications. While there is implicit processing in key management, an external mechanism is required for passing the multicast group address to the receivers. The receivers must have established "filters" for the address prior to transmission in order to receive the data, and suffers the same problems as IP/Multicast.
また、グループコミュニケーションの確立の前に、送付者と受信機の間にどんな明白なセットアップ処理もないとき、XTPもIP/マルチキャストと同様です。 かぎ管理における暗黙の処理がある間、外部のメカニズムが、マルチキャストグループアドレスを受信機に通過するのに必要です。 受信機は、データを受信して、トランスミッションの前にアドレスのために「フィルタ」を設立したに違いなくて、IP/マルチキャストと同じ問題を受けます。
In contrast to IP/Multicast, XTP does require explicit handshaking
IP/マルチキャストと対照して、XTPは明白なハンドシェイクを必要とします。
Braudes & Zabele [Page 5] RFC 1458 Requirements for Multicast Protocols May 1993
マルチキャストプロトコル1993年5月のためのBraudes&Zabele[5ページ]RFC1458要件
between the sender and receivers that wish to join an existing group; however, there is no parallel communication for receivers dropping out of groups, and the only mechanism for a sender to know if there are any receivers is the polling scheme used for error control and recovery. This causes the same problems with sending traffic to groups without members discussed under IP/Multicast.
既存のグループに加わるという送付者と受信機の間でその願望。 しかしながら、グループを落第する受信機のためのどんな平行なコミュニケーションもありません、そして、何か受信機があれば、送付者が知る唯一のメカニズムは誤り制御と回復に使用される世論調査計画です。 これはIP/マルチキャストの下で議論したメンバーなしで送付交通に関する同じ問題をグループに引き起こします。
The XTP specification does not address how routers distribute a multicast stream among different connected networks; however it does include a discussion of the optional bucket, damping, slotting, and cloning algorithms to reduce duplicate multicast traffic within a local network.
XTP仕様はルータがどう異なった接続ネットワークにマルチキャストの流れを広げるかを記述しません。 しかしながら、任意のバケツの議論を含んでいます、湿気、企業内情報通信網の中で写しマルチキャスト交通を抑えるためにアルゴリズムに溝をつけて、クローンを作って。
The specification allows the user to determine whether multicast transfers are unreliable or semi-reliable, where semi-reliable transfers are defined to provide a "high-probability of success [9]" of delivery to all receivers. Reliability cannot be guaranteed due to the fact that XTP does not maintain the cardinality of the receiver set, and so cannot know that the data has been received by all hosts.
仕様で、ユーザは、準信頼できる転送が「成功[9]の高い確率」を提供するために定義されるところで、マルチキャスト転送がすべての受信機への配送で頼り無いか、または準信頼できるかを決心できます。 信頼性がXTPが、受信機の基数がセットしたと主張しないという事実のため保証できないで、非常に知ることができないので、データはすべてのホストによって受け取られました。
XTP recovers from errors using a go-back-n approach (assuming that the bucket algorithm has been implemented) by retransmitting dropped packets to all members of the multicast group, as group members are unknown. This has the potential of flooding the network if only a single receiver dropped a packet. If all dropped packets belong to a single network on an internet, with traffic generated over the entire connected network.
nを支持しに行っているアプローチを使用することで(バケツアルゴリズムが実行されたと仮定して)XTPはマルチキャストグループのすべてのメンバーに低下しているパケットを再送することによって、エラーを回復します、グループのメンバーが未知であるときに。 これには、単一の受信機だけがパケットを落としたならネットワークをあふれさせる可能性があります。 すべてがパケットを落としたなら、交通が全体の接続ネットワークの上で発生しているインターネットでただ一つのネットワークに属してください。
3.3 ST-II
標準時3.3II
ST-II is another network protocol that provides support for multicast communications. Similar to IP/Multicast and XTP, ST-II requires a separate application-specific protocol for assigning and communicating multicast group addresses.
ST-IIはマルチキャストコミュニケーションのサポートを提供する別のネットワーク・プロトコルです。 IP/マルチキャストとXTPと同様であることで、ST-IIは、マルチキャストグループアドレスを割り当てて、伝えるために別々のアプリケーション特有のプロトコルを必要とします。
While ST-II is a network level protocol, it guarantees end-to-end bandwidth and delay, and so obviates the need for many of the functions of a transport protocol. The guarantee is provided by requiring bandwidth reservations for all connections, which are made at set-up time, and ensuring that the requested bandwidth is available throughout the lifetime of the connection. The enforcement policy ensures that the same path is followed for all transmissions, and prohibits new connections over the network unless there is sufficient bandwidth to accommodate the expected traffic. This is accomplished by maintaining the state of all connections in the network routers, trading the overhead of this connection set-up for the performance guarantees.
ST-IIはネットワークレベルプロトコルですが、それは、終わりから終わりへの帯域幅と遅れを保証するので、トランスポート・プロトコルの機能の多くの必要性を取り除きます。 すべての接続の帯域幅の予約を必要として、要求された帯域幅が接続の生涯の間中利用可能であることを確実にすることによって、保証を提供します。接続はセットアップ時にさせられます。 実施方針は、同じ経路がすべてのトランスミッションのために続かれているのを確実にして、予想された交通に対応できるくらいの帯域幅がない場合、ネットワークの上の新しい接続を禁止します。 これはネットワークルータにおけるすべての接続の状態を維持することによって、達成されます、契約履行保証のためのこの接続セットアップのオーバーヘッドを取り引きして。
Braudes & Zabele [Page 6] RFC 1458 Requirements for Multicast Protocols May 1993
マルチキャストプロトコル1993年5月のためのBraudes&Zabele[6ページ]RFC1458要件
Connection set-up involves negotiation of the bandwidth and delay parameters and path between the sender, intermediate routers, and receivers. If the requested resources cannot be made available, the sender is given the option of either accepting what is available or canceling the connection request.
接続セットアップは送付者と、中間的ルータと、受信機との帯域幅、遅れパラメタ、および経路の交渉を伴います。 要求されたリソースを利用可能にすることができないなら、利用可能なものを受け入れるか、または接続要求を中止しながら、どちらかのオプションを送付者に与えます。
To add a new user to an existing group, the new receiver must first communicate directly with the sender using a different protocol to exchange relevant information such as the group address. The sender then requests ST-II to add the new receiver, with the basic connection set-up processing invoked as before with the new connection completed only if there is sufficient bandwidth to process the user.
新しいユーザを既存のグループに追加するために、新しい受信機は最初に、グループアドレスなどの関連情報を交換するのに異なったプロトコルを使用することで直接送付者とコミュニケートしなければなりません。 次に、送付者は、新しい受信機を加えるようST-IIに要求します、基本接続セットアップ処理が従来と同様ユーザを処理できるくらいの帯域幅がある場合にだけ終了する新しい接続と共に呼び出されている状態で。
While the resource guarantee system imposed by ST-II tries to prevent network congestion from occurring, there are situations where priority traffic must be introduced into the network. ST-II makes this very expensive, as the resource requirements for existing connections must be adjusted, which can only be accomplished by the origin of each stream. This must be completed prior to the connection set-up for the priority stream, introducing a large delay before the important data can be transmitted.
ST-IIによって課されたリソース保証システムは、ネットワークの混雑が起こるのを防ごうとしますが、状況が優先権交通がネットワークに取り入れられなければならないところにあります。 ST-IIはこれを非常に高価にします、既存の接続のためのリソース要件(それぞれの流れの起源で達成できるだけである)を調整しなければならないとき。 優先権の流れのための接続セットアップの前にこれを完成しなければなりません、重要なデータを送ることができる前に大きい遅れを導入して。
ST-II connections can be closed by either the sender or the receiver. When the last receiver along a path has been removed, the resources allocated over that path are released. When all receivers have been removed, the sender in informed and has the option of either adding a new receiver or tearing down the group.
送付者か受信機のどちらかでST-II接続を閉店させられることができます。経路に沿った最後の受信機が取り外されたとき、その経路の上に割り当てられたリソースは発表されます。 すべての受信機が取り外されたとき、送付者は、中に新しい受信機を加えるか、またはグループを取りこわすオプションを知らせて、持っています。
3.4 MTP
3.4 MTP
MTP is a transport level protocol designed to support efficient, reliable multicast transmissions on top of existing network protocols such as IP/Multicast. It is based on the notion of a multicast "master" which controls all aspects of group communications.
MTPは平らなプロトコルがIP/マルチキャストなどの既存のネットワーク・プロトコルの上で効率的で、信頼できるマルチキャスト送信を支持するように設計した輸送です。 それはグループコミュニケーションの全面を制御するマルチキャスト「マスター」の概念に基づいています。
Allocation of a specific group address, or network service access point, is not considered part of MTP, and as with the other multicast protocols requires the use of an outside addressing authority. The MTP specification does require the master to make a "robust effort [2]" to ensure the address selected is not already in use by trying to join an existing group at that address, but the problems described above remain.
MTP、他のマルチキャストプロトコルで外のアドレシング権威の使用を必要とするとき、特定のグループアドレス、またはネットワークサービスアクセスポイントの配分は考えられた部分ではありません。 MTP仕様は、マスターが選択されたアドレスが確実にそのアドレスの既存のグループに加わろうとすることによって既に使用中にならないようにするための「体力を要している努力[2]」を作るのを必要としますが、上で説明された問題は残っています。
Once the address is established, receivers issue a request to join the existing group using a unique connection identifier that is pre- assigned. The MTP specification addresses neither how the identifier is allocated nor how the receivers learn its value, but is assumed to
アドレスがいったん確立されると、受信機はあらかじめ割り当てられるユニークな接続識別子を使用することで既存のグループに加わるという要求を出します。 MTP仕様は、受信機がどちらもどう識別子を割り当てるか、そして、どう値を学ぶかを記述しますが、想定されます。
Braudes & Zabele [Page 7] RFC 1458 Requirements for Multicast Protocols May 1993
マルチキャストプロトコル1993年5月のためのBraudes&Zabele[7ページ]RFC1458要件
be handled through an external protocol. The join request specifies whether the receiver wishes to be a producer of information or only a receiver, whether the connection should be reliable or best effort, whether the receiver is able to accept multiple senders of information, the minimum throughput desired, and the maximum data packet size. If the request can be granted, then the master replies with an ACK with a multicast connection identifier; otherwise a NAK is returned.
外部のプロトコルを通して扱われてください。 接合してください。要求は、情報のプロデューサーかそれとも受信機が受信機であるだけでありたいかどうか指定します、接続が信頼できるか、またはベストエフォート型であるべきであることにかかわらず、受信機が情報の複数の送付者、望まれていた最小のスループット、および最大のデータ・パケットサイズを受け入れることができるか否かに関係なく。 要求を承諾できるなら、マスターはACKと共にマルチキャスト接続識別子で返答します。 さもなければ、NAKを返します。
Dropping membership in a group is coordinated through the master. The specification does not address what action the master should take when the group is reduced to a single member, but a logical action would be to stop distributing transmit tokens if there are no active receivers.
グループで会員資格を落とすのはマスターを通して調整されます。 仕様はどんなアドレスもしません。どんなアクティブな受信機もなければ、マスターがグループが独身のメンバーに減少しますが、論理的な動きが分配するのを止めることであるならどんな行動を取るべきであるかが象徴を伝えます。
One of the major features in MTP is the ordering of received data. The master distributes transmit tokens to data producers in the group, which allow data to be provided at a specified rate. Rate control provides flow control within the protocol, with members that cannot maintain a minimum flow requested to leave the group.
MTPの主要な特徴の1つは受信データの注文です。 マスターが分配する、グループでデータプロデューサーに象徴を伝えてください。(それは、データが指定されたレートで提供されるのを許容します)。 速度制御はプロトコルの中でフロー制御を提供します、仲間から抜けるよう要求された最小の流れを維持できないメンバーと共に。
Error recovery utilizes a NAK-based selective retransmission scheme. Senders are required to maintain data for a time period specified by the master, and to be able to retransmit this data when requested by members of the group. These retransmissions are multicast to the entire group, requiring receivers to be able to cope with duplicate packets. If a retransmission request arrives after the data has been released, the sender must NAK the request.
エラー回復はNAKベースの選択している「再-トランスミッション」計画を利用します。 送付者は、期間のデータがマスターで指定したと主張して、グループのメンバーによって要求されると、このデータを再送できなければなりません。 受信機が写しパケットに対処できるのが必要であることで、これらの「再-トランスミッション」は全体のグループへのマルチキャストです。 「再-トランスミッション」要求が到着するなら、後に、データは発表されて、送付者必須NAKは要求です。
A potential problem with MTP is the significant amount of overhead associated with the protocol, with virtually all control traffic flowing through the master. The extra delay and congestion makes MTP inappropriate for the image dissemination applications.
MTPの潜在的な問題はプロトコルに関連しているオーバーヘッドのかなりの量です、ほとんどすべてのコントロール交通がマスターを通して流れていて。 余分な遅れと混雑で、MTPはイメージ普及のアプリケーションに不適当になります。
3.5 Summary
3.5 概要
Our analysis has determined that there are significant problems with all of the major multicast protocols for the reliable, adaptive multicast transport of large data items. The problems include inadequate address management, excessive processing of control information, poor response to network congestion, inability to handle high priority traffic, and suboptimal error recovery and retransmission procedures. We have developed a high-level notion of the requirements for a service that addresses these issues, which we now discuss.
私たちの分析は、大きいデータ項目の信頼できて、適応型のマルチキャスト輸送のための主要なマルチキャストプロトコルのすべてに関する重大な問題があることを決定しました。問題は不十分なアドレス管理を含んでいます、制御情報の過度の処理、ネットワークの混雑への応答不良、高い優先権交通、準最適のエラー回復、および「再-トランスミッション」手順を扱うことができないこと。 私たちは私たちが現在議論するこれらの問題を記述するサービスのための要件のハイレベルの概念を発生しました。
Braudes & Zabele [Page 8] RFC 1458 Requirements for Multicast Protocols May 1993
マルチキャストプロトコル1993年5月のためのBraudes&Zabele[8ページ]RFC1458要件
4. Protocol Suite for Reliable, Adaptive Multicast
4. 信頼できて、適応型のマルチキャストのためのプロトコル群
We present an integrated set of three basic components required to provide a reliable multicast service: the Multicast Group Authority (MGA); the Reliable, Adaptive Multicast Protocol (RAMP); and modified routing algorithms. These components are designed to be compatible with, and take full advantage of, reservation systems such as RSVP [12].
私たちは信頼できるマルチキャストサービスを提供するのに必要である3つの基本的なコンポーネントの統合セットを寄贈します: マルチキャストグループ権威(MGA)。 信頼できて、適応型のマルチキャストプロトコル(斜面)。 そして、変更されたルーティング・アルゴリズムこれらのコンポーネントはRSVP[12]などの互換性があって、最大限の利点を活用するために設計された予約システムです。
In this discussion, we have broadened the definition of the term "Quality of Service (QOS)." There are many applications where the information content of the underlying data can be reduced through data compression techniques. For example, a 1,024 x 1,024 pixel image can be sub-sampled down to 512 x 512 pixels. This degradation results in a lower quality of service for the end user, while reducing the traditional network QOS requirements for the transfer.
この議論では、私たちは「サービスの質(QOS)」という用語の定義を広げました。 多くの利用がデータ圧縮のテクニックで基本的なデータに関する情報量を減らすことができるところにあります。 例えば、1,024x1,024画素のイメージはサブ抽出された512x512まで画素であるかもしれません。 この退行は転送のための伝統的ネットワークQOS要件を減らしている間、エンドユーザのための下側のサービスの質をもたらします。
4.1 The Multicast Group Authority
4.1 マルチキャストグループ権威
The Multicast Group Authority (MGA) provides services related to managing the multicast address space and high-level management support to existing multicast groups. The MGA has three primary responsibilities: address management, service registration, and group membership maintenance.
Multicast Group Authority(MGA)はマルチキャストアドレス空間とハイレベルの管理サポートを既存のマルチキャストグループに管理すると関連するサービスを提供します。 MGAには、3つの責務があります: 管理、サービス登録、およびグループ会員資格維持に演説してください。
The MGA is hierarchical in nature, similar to the Internet Domain Name System (DNS) [7]. Requests for service are directed to an MGA agent on the local workstation, which are propagated upwards as required.
MGAはインターネットドメインネームシステム(DNS)[7]と現実に階層的であって、同様です。 サービスを求める要求はローカルワークステーションにMGAエージェントに向けられます(必要に応じて上向きに伝播されます)。
4.1.1 Address Management
4.1.1 アドレス管理
The MGA is responsible for the allocation and deallocation of addresses within the Internet Class D address space. Address requests received from application processes or other MGA nodes result in a block of addresses being assigned to the requesting MGA node. The size of the address block allocated is dependent on the position of the requester in the MGA hierarchy, to reduce the number of address requests propagated through the MGA tree.
MGAはインターネットClass Dアドレス空間の中でアドレスの配分と反配分に責任があります。 アドレス要求は割り当てられるアドレスのブロックのアプリケーション・プロセスか他のMGAノード結果から要求しているMGAノードまで受信されました。 割り当てられたあて先ブロックのサイズは、MGA木を通して伝播されたアドレス要求の数を減少させるためにMGA階層構造でリクエスタの位置に依存しています。
Figure 1 can be used to show what happens when an application requests a multicast address from the authority at node 1.1.1. Assuming that this is the first request from this branch of the MGA, node 1.1.1 issues a request to its parent, node 1.1, which propagates the request to node 1. Node 1 passes this request to the root, which issues a block of, say, 30 class D addresses. Of these 30, 10 are returned to node 1.1, with the remaining 20 reserved for requests from node 1's other children. Similarly, node 1.1 passes 3 addresses
アプリケーションがノードの権威からマルチキャストアドレスを要求するとき、何が起こるかを示すのに図1を使用できる、1.1、.1 仮定して、これがこのMGA、ノード1.1.1人のブランチからの最初の要求であることは親、ノード1に要求を伝播するノード1.1に要求を出します。 ノード1はこの要求に根に合格します。(それは、たとえば1ブロックの30のクラスDアドレスを発行します)。 これらの30では、ノード1.1に10を返して、ノード1からの要求のために残っている20で予約されているのは、他の子供です。 同様に、ノード1.1は3つのアドレスを通過します。
Braudes & Zabele [Page 9] RFC 1458 Requirements for Multicast Protocols May 1993
マルチキャストプロトコル1993年5月のためのBraudes&Zabele[9ページ]RFC1458要件
to node 1.1.1, reserving the other 7 for future requests. Finally, node 1.1.1 answers the applications request for an address, keeping the remaining 2 addresses for future use.
今後の要求のために他の7を予約するノード1.1.1に。 最終的に今後の使用のための残っている2つのアドレスを保管して、アプリケーションがアドレスのために要求するノード1.1.1の答え。
--------
| root |
--------
/ | \
/ | \
-------- --------
| 1 | ... | n |
-------- --------
/ | \
/ | \
-------- --------
| 1.1 | ... | 1.n |
-------- --------
/ | \
/ | \
-------- --------
|1.1.1 | ... |1.1.n |
-------- --------
-------- | 根| -------- / | \ / | \ -------- -------- | 1 | ... | n| -------- -------- / | \ / | \ -------- -------- | 1.1 | ... | 1. n| -------- -------- / | \ / | \ -------- -------- |1.1.1 | ... |1.1. n| -------- --------
Figure 1. Sample MGA Hierarchy
図1。 サンプルMGA階層構造
When the root exhausts the address space, a request is made to the children for reclamation of unused addresses. This request propagates down the tree, with unused addresses passed back through the hierarchy and returned to the address pool. If the entire address space is in use, then requests for additional addresses are not honored.
アドレス空間が根でくたくたになるとき、要求は未使用のアドレスの改善のために子供に出されます。 この要求は木の下側に未使用のアドレスを階層構造を通して戻して、アドレスプールに返していて伝播されます。 全体のアドレス空間が使用中であるなら、追加アドレスを求める要求は光栄に思っていません。
When an application no longer requires an address, it is returned to the local MGA node, which keeps it until either it is requested by another application, it is requested by its parent, or the node is terminated. At node termination, all available addresses are returned to the parent. Parents periodically send heartbeat requests to their children to ensure connectivity, and local nodes similarly poll applications, with addresses recalled if the queries are not answered.
アプリケーションがもうアドレスを必要としないとき、ローカルのMGAノードにそれを返します。(それが別のアプリケーションで要求されているか、それが親によって要求されているか、またはノードが終えられるまで、それは、それを保ちます)。 ノード終了では、すべての利用可能なアドレスを親に返します。 両親は接続性を確実にするために定期的に鼓動要求を彼らの子供に送ります、そして、ローカルのノードは同様にアプリケーションに投票します、質問が答えられないなら思い出されたアドレスで。
4.1.2 Service Registration, Requests, Release, and Group Membership
Maintenance
4.1.2 サービス登録、要求、リリース、およびグループ会員資格メインテナンス
The MGA maintains the state of all registered multicast services and receivers. State information includes the number of members associated with each group by requested QOS reliability, which is updated as services are offered or rescinded and as members join or
MGAはすべての登録されたマルチキャストサービスと受信機の状態を維持します。 または州の情報がサービスを提供するか、または無効にして、メンバーが加わるときアップデートされる要求されたQOSの信頼性で各グループに関連している会員数を含んでいる。
Braudes & Zabele [Page 10] RFC 1458 Requirements for Multicast Protocols May 1993
マルチキャストプロトコル1993年5月のためのBraudes&Zabele[10ページ]RFC1458要件
leave a group. The state information is used to ensure that there is at least one group member listening to each multicast transfer.
グループを出てください。 州の情報は、各マルチキャストが移されるのを聞く少なくとも1人のグループのメンバーがいるのを保証するのに使用されます。
Servers register the availability of service, specifying whether reliable service is available [section 4.2.2] and optionally the number of qualities of service offered [section 4.2.1]. A multicast group address is allocated from the address pool and the service is assigned an identifier as required. If a reservation protocol that requires information from the server (such as RSVP) is in use, then the MGA notifies the reservation system of the service with any required parameters. The service registration is propagated through the MGA, so that potential clients can discover service availability. However, servers do not begin data transfers until directed to do so by the MGA.
サーバはサービスの有用性を示します、信頼できるサービスが利用可能であり[セクション4.2.2]、任意に、サービスの品質の数が[セクション4.2.1]を提供したかどうか指定して。 アドレスプールからマルチキャストグループアドレスを割り当てます、そして、必要に応じて識別子をサービスに割り当てます。 サーバ(RSVPなどの)からの情報を必要とする予約プロトコルが使用中であるなら、MGAはどんな必要なパラメタでもサービスの保留制に通知します。 サービス登録は、可能なクライアントがサービスの有用性を発見できるように、MGAを通して伝播されます。 しかしながら、MGAでそうするよう指示されるまで、サーバはデータ転送を始めません。
Client requests for service are also processed through the MGA. Service requests specify a service, a desired quality of service, and a reliability indication. If the request is for a service that has been registered, then the routing support is directed to add a route for the new user [section 4.3.1]. If necessary, the MGA also notifies the reservation protocol. If either the requested QOS is not being provided or it is provided unreliably and the request is for reliable transport, then the service provider is also notified. If the service has not yet been registered, an identifier for the service is assigned and the request is queued for when the service is registered. In either case, a response is sent to the requester.
また、サービスを求めるクライアント要求はMGAを通して処理されます。 サービスのリクエストはサービス、必要なサービスの質、および信頼性の指示を指定します。 要求が登録されたサービスのためのものであるなら、ルーティングサポートが新しいユーザ[セクション4.3.1]のためにルートを加えるよう指示されます。 必要なら、また、MGAは予約プロトコルに通知します。 また、要求されたQOSが提供されていないか、それを当てにならずに提供して、要求が信頼できる輸送のためのものであるなら、サービスプロバイダーは通知されます。 サービスがまだ登録されていないなら、サービスのための識別子は割り当てられます、そして、要求はサービスが登録されている時の間、列に並ばせられます。 どちらの場合ではも、応答をリクエスタに送ります。
Requests for termination of group membership are also sent to the MGA. If the request originates at a client, the MGA notifies the routing function and reservation protocol of the termination in case the route should be released [section 4.3.2]. If termination results in a given QOS no longer having any recipients, the service provider is notified that the QOS is no longer required and should not be transmitted. Server-directed group terminations follow a similar procedure, with all clients of the group notified, and the service offering is removed from the MGA state tables.
また、グループ会員資格の終了を求める要求をMGAに送ります。 要求がクライアントで起因するなら、ルートがリリースされるといけないので[セクション4.3.2]、MGAは終了の経路選択機能と予約プロトコルに通知します。 終了がどんな受取人ももういない与えられたQOSをもたらすなら、サービスプロバイダーにQOSはもう必要でないように通知して、伝えるべきではありません。 サーバで指示されたグループ終了はグループのすべてのクライアントが通知されている同様の手順に従います、そして、サービス提供はMGAステートテーブルから取り外されます。
4.2 The Reliable Adaptive Multicast Protocol (RAMP)
4.2 信頼できる適応型のマルチキャストプロトコル(斜面)
RAMP is a transport-level protocol designed to provide reliable multicast service on top of a network protocol such as IP/Multicast, with unreliable transport also available. RAMP is build on the premise that applications can request one quality of service (using our extended definition), but only require reliable transmission at a lower level of quality. For example, consider the transmission of hierarchical image data, in which a base spatial resolution is transmitted, followed by higher resolution data. An application may require the base data to be sent reliably, but can tolerate dropped
RAMPはIP/マルチキャストなどのネットワーク・プロトコルの上で信頼できるマルチキャストサービスを提供するように設計された輸送レベルプロトコルです、また、頼り無い輸送も利用可能な状態で。 RAMPは建てることです、そして、アプリケーションは1つのサービスの質を要求できますが(私たちの拡張定義を使用して)、品質の下のレベルで信頼できるトランスミッションを単に必要としてください。 例えば、ベース空間分解能が伝えられる階層的なイメージデータの伝達が、より高い解決データで続いたと考えてください。 低下しますベースデータが確かに送られるのが必要であるかもしれませんが、アプリケーションが、許容できる。
Braudes & Zabele [Page 11] RFC 1458 Requirements for Multicast Protocols May 1993
マルチキャストプロトコル1993年5月のためのBraudes&Zabele[11ページ]RFC1458要件
packets for the higher resolution by using interpolation or pixel replication from the base level to approximate the missing data. Similar methods can be applied to other data types, such as audio or video.
欠測値に近似するのに基準面から挿入か画素模写を使用するのによる、より高い解像度のためのパケット。 オーディオかビデオなどの他のデータ型に同様のメソッドを適用できます。
4.2.1 Quality of Service Levels
4.2.1 サービスの質レベル
RAMP allows a multicast service to be provided at multiple qualities of service, with all or some of these levels transmitted reliably. These QOS can be distributed across different groups using different class D addresses, or in the simplest case be transmitted in individual groups. Single packets can be used for either a single QOS, or may be applicable to multiple qualities of service.
RAMPは、マルチキャストサービスが複数のサービスの品質で提供されるのを許容します、これらのレベルのすべてかいくつかが確かに伝えられている状態で。 これらのQOSを異なったグループの向こう側に異なったクラスDアドレスを使用することで分配するか、または個々のグループで最も簡単な場合で伝えることができます。 単一のパケットは、独身のQOSに使用できるか、または複数のサービスの品質に適切であるかもしれません。
When a data packet is transmitted, a header field indicates the QOS level(s) associated with that packet. In the old IP implementations, the Type of Service field can be used as a bit field with one bit for each applicable QOS, although this is incompatible with RFC 1349 [1]. If a packet is required for multiple QOS, then multiple values are encoded in the field. The RAMP host receiver protocol only accepts those packets addressed to a group in which an application has requested membership and that has a QOS value which is in the set of values requested by the receivers.
データ・パケットが伝えられるとき、ヘッダーフィールドはそのパケットに関連しているQOSレベルを示します。 古いIP実装では、それぞれの適切なQOSのために1でビットを少しさばくとき、Service分野のTypeを使用できます、これはRFC1349[1]と非互換ですが。 パケットが複数のQOSに必要であるなら、複数の値がその分野でコード化されます。 RAMPホスト受信機プロトコルはアプリケーションが会員資格を要求したグループに扱われたそれらのパケットを受け入れるだけです、そして、それには、受信機によって要求された値のセットにあるQOS値があります。
The quality of service requested within a flow can be modified during the life of the flow. QOS modification requests are forwarded to the MGA, which reduces the number of receivers in the original QOS group and increments the count for the requested QOS. These changes are propagated through the MGA hierarchy, with the server notified if either the original QOS has no remaining receivers or if the new QOS is not currently being served; similarly, the routers are notified if routing changes are required.
流れの寿命の間、流れの中で要求されたサービスの質は変更できます。 QOS変更要求をMGAに転送します。(MGAはオリジナルのQOSグループで受信機の数を減少させて、要求されたQOSのためにカウントを増加します)。 これらの変化はMGA階層構造を通して伝播されます、オリジナルのQOSでは残っている受信機が全くないか、または新しいQOSが現在役立たれていないなら通知されたサーバで。 同様に、ルーティング変化が必要であるなら、ルータに通知されます。
4.2.2 Error Recovery
4.2.2 エラー回復
Sequence numbers are used in RAMP to determine the ordering of packets within a multicast group. Mechanisms for ordering packets transmitted from different senders is a current research topic [2, 6], and an appropriate sequencing algorithm will be incorporated within the protocol.
一連番号は、マルチキャストグループの中でパケットの注文を決定するのにRAMPで使用されます。 異なった送付者からパケットを伝えるよう命令するためのメカニズムは現在の研究話題[2、6]です、そして、適切な配列アルゴリズムはプロトコルの中に組み込むでしょう。
Applications exist that do not require in-order delivery of data; for example, some image servers include position identification information in each packet. To enhance the efficiency of such schemes, RAMP includes an option to allow out-or-order delivery of packets to a receiver.
オーダーにおける、データの配送を必要としない利用が存在しています。 例えば、いくつかのイメージサーバが各パケットに位置の識別情報を含んでいます。 そのような体系の効率を高めるなら、RAMPは、パケットのアウトか注文配送を受信機に許容するためにオプションを含んでいます。
Braudes & Zabele [Page 12] RFC 1458 Requirements for Multicast Protocols May 1993
マルチキャストプロトコル1993年5月のためのBraudes&Zabele[12ページ]RFC1458要件
A NAK-based selective retransmission scheme is used in RAMP to minimize the protocol overhead associated with ACK-based schemes. When a receiver notices that one or more packets have not been received, and the transmission is reliable, a request is sent to the sender for the span of packets which are missing.
NAKベースの選択している「再-トランスミッション」体系は、ACKベースの体系に関連しているプロトコルオーバーヘッドを最小にするのにRAMPで使用されます。 受信機が、1つ以上のパケットが受け取られていないのに気付いて、トランスミッションが信頼できるとき、なくなったパケットの長さのために要求を送付者に送ります。
RAMP at the sender aggregates retransmission requests for the time specified by the retransmission hold timer [section 4.2.3]. After this time, the requests are evaluated to determine if sufficient receivers dropped a given packet to make multicasting the retransmission worthwhile by comparing it to a threshold value. All packets that have received a number of retransmission requests greater than the threshold are multicast to the group address, with other packets unicast to the individual requesters. The proposed retransmission scheme is a compromise between the extremes of multicasting and unicasting all retransmissions. The rationale is that multicasting a request issued by a single sender unnecessarily floods networks which had no packet loss, while unicasting to a large number of receivers floods the entire network. The optimal approach, dynamically constructing a new multicast group for each dropped packet, is currently too costly in terms of group set-up time.
送付者のRAMPは「再-トランスミッション」保持タイマ[セクション4.2.3]によって指定された時間を求める「再-トランスミッション」要求に集めます。 今回以降、要求は、十分な受信機がマルチキャスティングをそれを閾値と比較することによって価値がある「再-トランスミッション」にするように与えられたパケットを下げたかどうか決定するために評価されます。 敷居より大きい多くの「再-トランスミッション」要求を受け取ったすべてのパケットがグループアドレスへのマルチキャストです、個々のリクエスタへの他のパケットユニキャストで。 提案された「再-トランスミッション」体系はマルチキャスティングとすべての「再-トランスミッション」をunicastingする極端の間の感染です。 原理は要求が独身の送付者で発行したマルチキャスティングが多くの受信機洪水に全体のネットワークをunicastingしている間にパケット損失を全く持っていなかったネットワークを不必要にあふれさせるということです。 それぞれの下げられたパケットのためにダイナミックに新しいマルチキャストグループを構成して、最適のアプローチは現在、グループセットアップ時間で高価過ぎます。
For those cases where the service provider is unable to retransmit the data due to released or overwritten buffers, the protocol delivers NAK responses using either multicast or unicast based on the number of retransmission requests received.
サービスプロバイダーがリリースされたか上書きされたバッファのためデータを再送できないそれらのケースのために、プロトコルは、要求が受けた「再-トランスミッション」の数に基づくマルチキャストかユニキャストのどちらかを使用することで応答をNAKに提供します。
4.2.3 Flow Control
4.2.3 フロー制御
RAMP utilizes a rate-based flow control mechanism that derives rate reductions from requests for retransmission or router back-off requests (i.e., ICMP source quench messages), and derives rate increases from the number of packets transmitted without retransmission requests. When a retransmission request is received, the protocol uses the number of packets requested to compute a rate reduction factor. Similarly, a different reduction factor is computed upon receipt of a router-generated squelch request. The rate reduction factors are then used to compute a reduced rate of transmission.
RAMPは「再-トランスミッション」を求める要求かルータ下に後部要求(すなわち、ICMPソース焼き入れメッセージ)からレート減少を得て、増税に「再-トランスミッション」要求なしで伝えられたパケットの数に由来しているレートベースのフロー制御メカニズムを利用します。 「再-トランスミッション」要求が受信されているとき、プロトコルはレート減少要素を計算するよう要求されたパケットの数を使用します。 同様に、異なった減少要素はルータで発生しているスケルチ要求を受け取り次第計算されます。 そして、レート減少要素は、割引料金の送信を計算するのに使用されます。
When a given number of packets have been transmitted without packet loss, the rate of transmission is incrementally increased. The size of the increase will always be smaller than the size of the smallest rate decrease, in order to minimize throttling.
与えられた数のパケットがパケット損失なしで伝えられたとき、トランスミッションの速度は増加して増強されます。 増加のサイズは最も小さいレート減少のサイズよりいつもさらに小さくなるでしょう、阻止を最小にするために。
The retransmission hold timer is modified according to both application requests and network state. As the number of retransmission requests rises, the hold timer is incremented to
アプリケーション要求とネットワーク状態の両方に従って、「再-トランスミッション」保持タイマは変更されます。 「再-トランスミッション」要求の上昇、タイマが増加される保持の数として
Braudes & Zabele [Page 13] RFC 1458 Requirements for Multicast Protocols May 1993
マルチキャストプロトコル1993年5月のためのBraudes&Zabele[13ページ]RFC1458要件
minimize the number of duplicate retransmissions. Similarly, the timer is decremented as the number of retransmission requests drops.
写し「再-トランスミッション」の数を最小にしてください。 同様に、「再-トランスミッション」要求の数が低下するのに従って、タイマは減少します。
RAMP allows for priority traffic, which is marked in the packet header. The protocol transmits a variable number of packets from each sending process in proportion to the priority of the flow.
RAMPは優先権トラフィックを考慮します。(それは、パケットのヘッダーでマークされます)。 プロトコルは流れの優先権に比例してそれぞれの送付プロセスから可変数のパケットを伝えます。
4.3 Routing Support
4.3 ルート設定サポート
The protocol suite requires routing support for four functions: path set-up, path tear-down, forwarding based on QOS values, and prioritized packet loss due to congestion. The support must be integrated into routers and network-level protocols in a similar fashion to IGMP [8].
プロトコル群は、4つの機能のサポートを発送するのを必要とします: 経路セットアップ、経路分解、QOS値に基づく推進、および最優先するパケット損失は混雑がそうします。 同様にIGMP[8]へのルータとネットワークレベルプロトコルとサポートを統合しなければなりません。
Partial support comes as a direct consequence of using reservation protocols such as RSVP. This RFC does not mandate the means of implementing the required functions, and the specified protocols are compatible with known reservation protocols.
RSVPなどの予約プロトコルを使用することの直接の結果として部分的なサポートは来ます。 このRFCは必要な機能を実装する手段を強制しません、そして、指定されたプロトコルは知られている予約プロトコルと互換性があります。
The routers state tables must maintain both the multicast group address and the QOS level(s) requested for each group on each outbound interface in order to make appropriate routing decisions [section 4.3.3]. Therefore, the router state tables are updated whenever group membership changes, including QOS changes.
ルータステートテーブルは、両方が適切なルーティングを決定[セクション4.3.3]にして、それぞれの外国行きのインタフェースに関する各グループのために要求されたマルチキャストグループアドレスとQOSレベルであることを支持しなければなりません。 したがって、QOS変化を含んでいて、グループ会員資格が変化するときはいつも、ルータステートテーブルをアップデートします。
4.3.1 Path Set-up
4.3.1 経路セットアップ
Routers receive path set-up requests from the MGA as required when new members join a multicast group, which specifies the incoming and outgoing interfaces, the group address, and the QOS associated with the request. When the message is received, the router establishes a path between the server and the receiver, and subsequently updates the multicast group state table. The mechanism used to discern the network interfaces is not specified, but may take advantage of other protocols such as the RSVP path and reservation mechanism.
新しいメンバーがマルチキャストグループ(送受信のインタフェース、グループアドレス、および要求に関連しているQOSを指定する)に加わるとき、ルータは必要に応じてMGAから経路セットアップ要求を受け取ります。 メッセージが受信されているとき、ルータは、サーバと受信機の間の経路を確立して、次に、マルチキャストグループステートテーブルをアップデートします。 ネットワーク・インターフェースについて明察するのに使用されるメカニズムは、指定されませんが、RSVP経路や予約メカニズムなどの他のプロトコルを利用するかもしれません。
4.3.2 Path Tear-down
4.3.2 経路分解
Path tear-down requests are also propagated through the routers by the MGA when group membership changes or QOS changes no longer require data to be sent over a given route. These are used to inform routers of both deletions of QOS for a given path and deletions of entire paths. The purpose of the message is to explicitly remove route table entries in order to minimize the time required to stop forwarding multicast data across networks once the path is no longer required.
また、グループ会員資格変化かQOS変化が、もうデータが与えられたルートの上に送られるのを必要としないとき、経路分解要求はルータを通してMGAによって伝播されます。 これらは、与えられた経路へのQOSの削除と全体の経路の削除の両方のルータを知らせるのに使用されます。 メッセージの目的は経路がもういったん必要でないとネットワークの向こう側にマルチキャストデータを転送するのを止めるのに必要である時間を最小にするために明らかにルートテーブルエントリーを取り除くことです。
Braudes & Zabele [Page 14] RFC 1458 Requirements for Multicast Protocols May 1993
マルチキャストプロトコル1993年5月のためのBraudes&Zabele[14ページ]RFC1458要件
4.3.3 Multicast Routing Based on Quality of Service
4.3.3 サービスの質に基づくマルチキャストルート設定
Traditional multicast routing formulates route/don't route decisions based on the destination address in the packet header, with packets duplicated as necessary to reach all destinations. In the proposed new protocol suite, routers also consult the QOS field for each packet as different paths may have requested different qualities of service. Packets are only forwarded if the group address has been requested and the quality of service specified in the header is requested in the state table entry for a given interface.
パケットのヘッダーで送付先アドレスに基づく決定を発送しないで、すべての目的地に達するように必要に応じてパケットでコピーされて、伝統的なマルチキャストルーティングはルート/を定式化します。 また、提案された新しいプロトコル群では、異なった経路が異なったサービスの品質を要求したとき、ルータが各パケットのためにQOS分野に相談します。 グループアドレスを要求した場合にだけ、パケットを進めます、そして、与えられたインタフェースのためのステートテーブルエントリーでヘッダーで指定されたサービスの質を要求します。
4.3.4 Quality of Service Based Packet Loss
4.3.4 サービスの質はパケット損失を基礎づけました。
Network congestion causes router queues to overflow, and as a result packet loss occurs. The QOS and priority indications in the packet headers can be used to prioritize the order in which packets are dropped. First, packets with the priority field set in the header are dropped last. Within packets of equal priority, packets are dropped in order of QOS, with the highest QOS packets dropped first. The rationale is that other packets with lower QOS may be usable by receivers, while packets with high QOS may not be usable without the lower QOS data.
ルータ待ち行列はネットワークの混雑であふれます、そして、その結果、パケット損失は起こります。 パケットが下げられるオーダーを最優先させるのにパケットのヘッダーでのQOSと優先権指摘を使用できます。 まず最初に、ヘッダーに設定された優先権分野があるパケットは最後に下げられます。 等しい優先権のパケットの中では、パケットはQOSの順に下げられて、最も高いQOSと共に、パケットは最初に、低下しました。 原理は下側のQOSがある他のパケットが受信機で使用可能であるかもしれないということです、高いQOSがあるパケットが低いQOSデータなしで使用可能でないかもしれませんが。
5. Interactions Among the Components: An Example
5. コンポーネントの中の相互作用: 例
The MGA, RAMP, and routing support functions all cooperate in the multicast process. As an example, assume that a network exists with a single server (S), three routers (R1, R2, and R3), and two clients (C1 and C2). The path between S and C1 goes through R1 and R2, while the path between S and C2 goes through R1, R2, and R3. The network is shown in figure 2.
ムガ、RAMP、およびルーティング支援機能はすべて、マルチキャストプロセスに協力します。 例として、ネットワークがただ一つのサーバ(S)、3つのルータ(R1、R2、およびR3)、および2人のクライアント(C1とC2)と共に存在すると仮定してください。 SとC1の間の経路はR1とR2を通ります、SとC2の間の経路はR1、R2、およびR3を通りますが。 ネットワークは2が中で計算するのが示されます。
S ------- R1 -------- R2 -------- R3
| |
C1 C2
S------- R1-------- R2-------- R3| | C1 C2
Figure 2. Sample Network Configuration
図2。 サンプルネットワーク・コンフィギュレーション
Service Registration
サービス登録
When S is initiated, it registers a service with the MGA node in the local workstation, offering reliable service at two qualities of service, Q1 and Q2. As this is the first multicast offering on the workstation, the local MGA requests a block of multicast addresses from the hierarchy, and assigns an address and service identifier to S. If the RSVP reservation protocol is in operation, the local MGA node in S notifies RSVP to send a RpathS message out for the service, which goes through R1, R2, and R3,
Sが開始されるとき、ローカルワークステーションでMGAノードにサービスを登録します、サービス、Q1、およびQ2の2つの品質で信頼できるサービスを提供して。 これがワークステーションの上の最初のマルチキャスト提供であるので、地方のMGAは階層構造から1ブロックのマルチキャストアドレスを要求して、RpathSメッセージを送るプロトコルが操作、SのローカルのMGAノードにあるというRSVP条件がRSVPに通知するS.Ifへのアドレスとサービス識別子をサービスのための外に割り当てます。(サービスはR1、R2、およびR3を通ります)。
Braudes & Zabele [Page 15] RFC 1458 Requirements for Multicast Protocols May 1993
マルチキャストプロトコル1993年5月のためのBraudes&Zabele[15ページ]RFC1458要件
reaching the RSVP nodes on C1 and C2. The service and its characteristics are propagated throughout the MGA hierarchy, ultimately reaching the MGA nodes resident on C1 and C2. The service is now available throughout the network.
C1とC2の上のRSVPノードに達します。 サービスとその特性はMGA階層構造中で伝播されます、結局C1とC2の上のMGAノードの居住者に届いて。 サービスは現在、ネットワーク中で利用可能です。
Service Request and Path Set-up
サービスのリクエストと経路セットアップ
The client C1 requests reliable service from S at QOS Q1, by issuing a request to the MGA node in C1. If a reservation protocol is in use, then it is used to reserve bandwidth and establish a path between the sender and receiver, going through R1 and R2; otherwise, the path is established through R1 and R2 by the routing protocol. R1 now forwards all packets from S with QOS Q1 along the path to R2, which routes them to C1. In concert with the path set-up, the add membership request is propagated through MGA to the server workstation. The local MGA tables are checked and it is noted that the service is not currently being offered, so the server is notified to begin reliable distribution of the service at Q1.
クライアントC1はQOS Q1でSから信頼できるサービスを要求します、C1のMGAノードに要求を出すことによって。 予約プロトコルが使用中であるなら、それは送付者と受信機の間で帯域幅を控えて、経路を証明するのに使用されます、R1とR2を通って。 さもなければ、経路はR1とR2を通してルーティング・プロトコルによって確立されます。 R1は現在、経路に沿ってQOS Q1があるSからR2まですべてのパケットを進めます。(R2はそれらをC1に発送します)。 経路と協力してセットアップしてください、会員資格要求がMGAを通してサーバワークステーションに伝播されると言い足してください。 地方のMGAテーブルはチェックされます、そして、サーバがQ1で信頼できるサービスの分配を始めるように通知されて、サービスが現在提供されていないことに注意されます。
Initial Delivery
初期の配送
The server now begins transmitting Q1 data which is observed by R1. R1 inspects the header and notes that the packet has QOS Q1. The routing tables specify that QOS Q1 for this address are only forwarded along the interface leading to R2, and R1 acts accordingly. Similarly, R2 routes the packet to C1. When the data arrives at C1, the RAMP node inspects the QOS and destination address fields in the header, accepts the packet, and forwards it to the C1 client process.
サーバは現在、R1によって観測されるQ1データを送り始めます。 R1はヘッダーとパケットにはQOS Q1があるというメモを点検します。 経路指定テーブルは、R2に通じながらインタフェースに沿ってこのアドレスのためのQOS Q1を進めるだけであり、R1が善処すると指定します。 同様に、R2はパケットをC1に発送します。 データがC1に到着するとき、RAMPノードは、C1クライアントプロセスにヘッダーでQOSと目的地アドレス・フィールドを点検して、パケットを受け入れて、それを送ります。
Error Recovery
エラー回復
During transmission, if the RAMP node in C1 realizes that packets have been dropped, a retransmission request is returned to the server identifying spans of the missing packets. The RAMP node accepts the packet, builds the retransmission packets, and sets the retransmission hold timer. When the timer expires, the number of retransmission requests for each missing packet is compared against the threshold, and the packets are either unicast directly to the requesters or multicast to the entire group. As in this case there is only requester, the threshold is not exceeded and the packets are retransmitted to C1Us unicast address.
トランスミッションの間、C1のRAMPノードが、パケットが下げられたとわかるなら、なくなったパケットの長さを特定するサーバに「再-トランスミッション」要求を返します。 RAMPノードは、パケットを受け入れて、「再-トランスミッション」パケットを建てて、「再-トランスミッション」保持タイマを設定します。 タイマが期限が切れるとき、それぞれのなくなったパケットを求める「再-トランスミッション」要求の数は敷居に対してたとえられます、そして、パケットは直接全体のグループへのリクエスタかマルチキャストへのどちらかのユニキャストです。 この場合、リクエスタしかないとき、敷居は超えられていません、そして、パケットはC1Usユニキャストアドレスに再送されます。
Group Membership Addition
グループ会員資格追加
Client C2 now joins the group, requesting reliable transmission at QOS Q2. Following the process used for C1, the request propagates
QOS Q2で信頼できるトランスミッションを要求して、クライアントC2は今、グループに加わります。 C1に使用されるプロセスに続いて、要求は伝播されます。
Braudes & Zabele [Page 16] RFC 1458 Requirements for Multicast Protocols May 1993
マルチキャストプロトコル1993年5月のためのBraudes&Zabele[16ページ]RFC1458要件
through the MGA (and potentially reservation protocol) hierarchy. Upon completion of the request processing, R1 routes packets for QOS Q1 and Q2 to R2, while R2 forwards QOS Q1 packets to C1 and Q2 packets to R3; client C1 only accepts packets marked as Q1 while C2 only accepts Q2 packets. The server is notified that it now has clients for Q2, and begins serving that QOS in addition to Q1.
MGA(そして、潜在的に予約プロトコル)階層構造を通して。 要求処理の完成のときに、R1はQOS Q1とQ2のためにパケットをR2に発送します、R2はC1へのパケットとR3へのQ2パケットをQOS Q1に送りますが。 クライアントC1はC2がQ2パケットを受け入れるだけですが、Q1としてマークされたパケットを受け入れるだけです。 サーバは現在、クライアントがQ2のためにいて、Q1に加えてそのQOSに役立ち始めるように通知されます。
QOS Based Routing
QOSはルート設定を基礎づけました。
First, assume that QOS Q1 data is independent of QOS Q2 data. When the server sends a packet with Q1 marked in the header, the packet is received by R1 and is forwarded to R2. R2 receives the packet, and sends it out the interface to C1, but not to R3. Next, the server delivers a packet for Q2. R1 receives the packet and sends it to R2, which forwards it to R3 but not to C1. R3 accepts the packet, and forwards it to C2.
まず最初に、QOS Q1データがQOS Q2データから独立していると仮定してください。 Q1がヘッダーでマークされている状態でサーバがパケットを送るとき、パケットをR1が受け取って、R2に送ります。 R2はインタフェースからC1にパケットを受けて、それを送りますが、R3に送るというわけではありません。 次に、サーバはQ2のためにパケットを提供します。 R1はR2にパケットを受けて、それを送りますが、C1に送るというわけではありません。(R2はそれをR3に送ります)。 R3はパケットを受け入れて、それをC2に送ります。
Now, assume that either Q2 is a subset of Q1, or that receivers of Q1 data also require Q2 data as in conditional compression schemes. Therefore, all Q2 packets are marked for both Q1 and Q2, while the remaining Q1 packets only have Q1 set in the header. Q1-only packets are routed as before, following the path S -> R1 -> R2 -> C1. However, Q2 packets are now routed from S to R1 to R2, at which point R2 duplicates the packets and sends them to both C1 and R3, with R3 forwarding them to C2. At C1, these packets have Q1 marked, and so are accepted, while at C2 the packet is accepted as the Q2 bit is verified.
今度は、Q2がQ1の部分集合であるかまた、Q1データの受信機が条件付きの圧縮技術のようにQ2データを必要とすると仮定してください。 したがって、すべてのQ2パケットがQ1とQ2の両方のためにマークされます、ヘッダーで残っているQ1パケットでQ1を用意ができさせるだけですが。 経路S->R1->R2->C1に続いて、Q1だけパケットは従来と同様発送されます。 しかしながら、Q2パケットは現在SからR1までR2に発送されます、R3がそれらをC2に送っていて。(そこでは、ポイントR2はC1とR3の両方にパケットをコピーして、それらを送ります)。 C1では、Q1をマークさせるので、これらのパケットを受け入れます、Q2ビットについて確かめるとき、C2でパケットを受け入れますが。
Group Membership Deletion
グループ会員資格削除
When C1 issues a drop membership request, the MGA on the client workstation is notified, and the request is propagated through the MGA hierarchy back to the server MGA node. In parallel, the routers are notified to close the path, as it is no longer required, possibly through the reservation protocol. As this is the last client for the Q1 QOS, the server is informed to stop transmitting Q1 data, with Q2 data unaffected. A similar process occurs when C2 drops membership from the group, leaving the server idle. At this point, the server has the option of shutting down and returning the group address to the MGA, or to continue in an idle state until another client requests service.
C1が低下会員資格要求を出すとき、クライアントワークステーションの上のMGAは通知されます、そして、要求はMGA階層構造を通してサーバMGAノードに伝播して戻されます。 平行では、ルータが経路を閉じるように通知されます、それはもう必要でないように、ことによると予約プロトコルを通して。 これがQ1 QOSのための最後のクライアントであるので、サーバはQ1データを送るのを止めるために知らされます、Q2データが影響を受けない状態で。 サーバを活動していないままにして、C2がグループから会員資格を下げると、同様のプロセスは起こります。 ここに、サーバには、グループアドレスをMGAに止めて、返すオプションがあるか、または活動していない状態で別のクライアントまで続くのはサービスを要求します。
Acknowledgements
承認
This research was supported in part by the Defense Research Projects Agency (DARPA) under contract number F19618-91-C-0086.
この研究は契約番号F19618 91C0086の下でDefense Research Projects Agency(DARPA)によって一部サポートされました。
Braudes & Zabele [Page 17] RFC 1458 Requirements for Multicast Protocols May 1993
マルチキャストプロトコル1993年5月のためのBraudes&Zabele[17ページ]RFC1458要件
References
参照
[1] Almquist, P., "Type of Service in the Internet Protocol Suite",
RFC 1349, Consultant, July 1992.
[1]Almquist、P.、「インターネットプロトコル群のサービスのタイプ」、RFC1349、コンサルタント、1992年7月。
[2] Armstrong, S., Freier, A., and K. Marzullo, "Multicast Transport
Protocol", RFC 1301, Xerox, Apple, Cornell University, February
1992.
[2] アームストロングとS.とフライア、A.とK.Marzullo、「マルチキャストトランスポート・プロトコル」、RFC1301、ゼロックス、アップル、コーネル大学、1992年2月。
[3] Braudes, R., and S. Zabele, "A Reliable, Adaptive Multicast
Service for High-Bandwidth Image Dissemination", submitted to ACM
SIGCOMM '93.
[3] ACM SIGCOMM93年に提出されたBraudes、R.とS.Zabele、「高帯域イメージ普及のための信頼できて、適応型のマルチキャストサービス。」
[4] Cheriton, D., "VMTP: Versatile Message Transaction Protocol", RFC
1045, Stanford University, February 1988.
[4]Cheriton、D.、「VMTP:」 「多能なメッセージトランザクションプロトコル」、RFC1045、スタンフォード大学、1988年2月。
[5] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
1112, Stanford University, August 1989.
[5] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、スタンフォード大学、1989年8月。
[6] Mayer, E., "An Evaluation Framework for Multicast Ordering
Protocols", Proceedings ACM SIGCOMM '92, Baltimore, Maryland, pp.
177-187.
[6] マイヤー、E.、「マルチキャスト注文プロトコルのための評価フレームワーク」、Proceedings ACM SIGCOMM92年、ボルチモア(メリーランド)のページ 177-187.
[7] Mockapetris, P., "Domain Names - Concepts and Facilities," STD
13, RFC 1034, USC/Information Sciences Institute, November 1987.
[7]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、科学が設けるUSC/情報、11月1987日
[8] Postel, J., "Internet Control Message Protocol - DARPA Internet
Program Protocol Specification", STD 5, RFC 792, USC/Information
Sciences Institute, September 1981.
[8] ポステル、J.、「インターネットはメッセージプロトコルを制御します--DARPAインターネットプログラムプロトコル仕様」、STD5、RFC792、科学が設けるUSC/情報、1981年9月。
[9] Strayer, W., Dempsey, B., and A. Weaver, "XTP: The Xpress
Transfer Protocol", Addison-Wesley Publishing Co., Reading, MA,
1992.
[9] 迷い人、W.、デンプシー、B.、およびA.ウィーバー、「XTP:」 アディソン-ウエスリーは社、読書、MA、1992を発行して「エクスプレスはプロトコルを移す」。
[10] Topolcic, C., Editor, "Experimental Internet Stream Protocol,
Version 2 (ST- II)", RFC 1190, CIP Working Group, October 1990.
[10]Topolcic、C.、エディタ、「実験インターネットストリームプロトコル、バージョン2、(第II)、」、RFC1190、CIP作業部会、10月1990
[11] "XTP Protocol Definition Revision 3.6", Protocol Engines
Incorporated, PEI 92-10, Mountain View, CA, 11 January 1992.
[11] 「XTPは何3.6インチも、プロトコルエンジンが取り入れた定義改正、PEI92-10、マウンテンビュー(カリフォルニア)1992年1月11日について議定書の中で述べます」。
[12] Zhang, L., Deering, S., Estrin, D., Shenker, S., and D. Zappala,
"RSVP: A New Resource ReSerVation Protocol", Work in Progress,
March 1993.
[12] チャン、L.、デアリング、S.、Estrin、D.、Shenker、S.、およびD.Zappala、「RSVP:」 「新しい資源予約プロトコル」、進行中の仕事、1993年3月。
Braudes & Zabele [Page 18] RFC 1458 Requirements for Multicast Protocols May 1993
マルチキャストプロトコル1993年5月のためのBraudes&Zabele[18ページ]RFC1458要件
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Authors' Addresses
作者のアドレス
Bob Braudes TASC 55 Walkers Brook Drive Reading, MA 01867
ボブBraudes TASC55歩行者ブルックはMA 読書、01867を追い立てます。
Phone: (617) 942-2000 EMail: rebraudes@tasc.com
以下に電話をしてください。 (617) 942-2000 メールしてください: rebraudes@tasc.com
Steve Zabele TASC 55 Walkers Brook Drive Reading, MA 01867
スティーブZabele TASC55歩行者ブルックはMA 読書、01867を追い立てます。
Phone: (617) 942-2000 EMail: gszabele@tasc.com
以下に電話をしてください。 (617) 942-2000 メールしてください: gszabele@tasc.com
Braudes & Zabele [Page 19]
Braudes&Zabele[19ページ]
一覧
スポンサーリンク
