RFC3170 日本語訳
3170 IP Multicast Applications: Challenges and Solutions. B. Quinn, K.Almeroth. September 2001. (Format: TXT=67207 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Quinn
Request for Comments: 3170 Celox Networks
Category: Informational K. Almeroth
UC-Santa Barbara
September 2001
コメントを求めるワーキンググループB.クイン要求をネットワークでつないでください: 3170Celoxはカテゴリをネットワークでつなぎます: 情報のK.Almeroth UC-サンタバーバラ2001年9月
IP Multicast Applications:
Challenges and Solutions
IPマルチキャストアプリケーション: 挑戦と解答
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 (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
Abstract
要約
This document describes the challenges involved with designing and implementing multicast applications. It is an introductory guide for application developers that highlights the unique considerations of multicast applications as compared to unicast applications.
このドキュメントはマルチキャストアプリケーションを設計して、実装するのにかかわる挑戦について説明します。 それはアプリケーション開発者のためのユニキャストアプリケーションと比べて、マルチキャストアプリケーションのユニークな問題を強調する紹介しているガイドです。
To this end, the document presents a taxonomy of multicast application I/O models and examples of the services they can support. It then describes the service requirements of these multicast applications, and the recent and ongoing efforts to build protocol solutions to support these services.
このために、ドキュメントはマルチキャストアプリケーション入出力モデルの分類学とそれらがサポートすることができるサービスの例を提示します。 そして、それは、これらのサービスをサポートするためにプロトコルソリューションを築き上げるためにこれらのマルチキャストアプリケーションに関するサービス要件、および最近の、そして、進行中の取り組みについて説明します。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Focus and Scope. . . . . . . . . . . . . . . . . . . . . . . 3
2. IP Multicast-enabled Network. . . . . . . . . . . . . . . . . . 3
2.1 Essential Protocol Components. . . . . . . . . . . . . . . . 4
2.1.1 Expedient Joins and Leaves . . . . . . . . . . . . . . . 5
2.1.2 Send without a Join. . . . . . . . . . . . . . . . . . . 5
3. IP Multicast Application Taxonomy . . . . . . . . . . . . . . . 6
3.1 One-to-Many Applications . . . . . . . . . . . . . . . . . . 8
3.2 Many-to-Many Applications. . . . . . . . . . . . . . . . . . 9
3.3 Many-to-One Applications . . . . . . . . . . . . . . . . . .10
4. Common Multicast Service Requirements . . . . . . . . . . . . .13
4.1 Bandwidth Requirements . . . . . . . . . . . . . . . . . . .13
1. 序論。 . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 動機. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2焦点と範囲。 . . . . . . . . . . . . . . . . . . . . . . 3 2. IPはネットワークをマルチキャストで可能にしました。 . . . . . . . . . . . . . . . . . 3 2.1 不可欠のプロトコルコンポーネント。 . . . . . . . . . . . . . . . 4 2.1 .1手段は接合して、.2がaなしで送る葉. . . . . . . . . . . . . . . 5 2.1は接合します。 . . . . . . . . . . . . . . . . . . 5 3. 多くへのIPマルチキャストアプリケーション分類学. . . . . . . . . . . . . . . 6 3.1 1つのアプリケーション. . . . . . . . . . . . . . . . . . 8 3.2の多くへの多くアプリケーション。 . . . . . . . . . . . . . . . . . 9 3.3 1つへの多くアプリケーション. . . . . . . . . . . . . . . . . .10 4。 一般的なマルチキャストサービス要件. . . . . . . . . . . . .13 4.1帯域幅要件.13………………
Quinn, et al. Informational [Page 1] RFC 3170 IP Multicast Applications September 2001
クイン、他 [1ページ]情報のRFC3170IPマルチキャストアプリケーション2001年9月
4.2 Delay Requirements . . . . . . . . . . . . . . . . . . . . .13
5. Unique Multicast Service Requirements . . . . . . . . . . . . .14
5.1 Address Management . . . . . . . . . . . . . . . . . . . . .16
5.2 Session Management . . . . . . . . . . . . . . . . . . . . .16
5.3 Heterogeneous Receiver Support . . . . . . . . . . . . . . .18
5.4 Reliable Data Delivery . . . . . . . . . . . . . . . . . . .20
5.5 Security . . . . . . . . . . . . . . . . . . . . . . . . . .21
5.6 Synchronized Play-Out. . . . . . . . . . . . . . . . . . . .23
6. Service APIs. . . . . . . . . . . . . . . . . . . . . . . . . .23
7. Security Considerations . . . . . . . . . . . . . . . . . . . .24
8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . .24
9. References. . . . . . . . . . . . . . . . . . . . . . . . . . .24
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .27
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . .28
4.2は要件. . . . . . . . . . . . . . . . . . . . .13 5を遅らせます。 ユニークなマルチキャストサービス要件. . . . . . . . . . . . .14 5.1アドレス管理. . . . . . . . . . . . . . . . . . . . .16 5.2セッション管理. . . . . . . . . . . . . . . . . . . . .16 5.3の異種の受信機サポート. . . . . . . . . . . . . . .18 5.4確実な資料配送. . . . . . . . . . . . . . . . . . .20 5.5セキュリティ. . . . . . . . . . . . . . . . . . . . . . . . . .21 5.6は、外でプレーするのが連動させました。 . . . . . . . . . . . . . . . . . . .23 6. APIを調整してください。 . . . . . . . . . . . . . . . . . . . . . . . . .23 7. セキュリティ問題. . . . . . . . . . . . . . . . . . . .24 8。 承認。 . . . . . . . . . . . . . . . . . . . . . . .24 9. 参照。 . . . . . . . . . . . . . . . . . . . . . . . . . .24 10. 作者のアドレス. . . . . . . . . . . . . . . . . . . . . .27 11。 完全な著作権宣言文.28………………
1. Introduction
1. 序論
IP Multicast will play a prominent role on the Internet in the coming years. It is a requirement, not an option, if the Internet is going to scale. Multicast allows application developers to add more functionality without significantly impacting the network.
IP Multicastは来たる年の間、インターネットで際立った役割を果たすでしょう。 インターネットが比例するなら、それはオプションではなく、要件です。 マルチキャストで、ネットワークにかなり影響を与えないで、アプリケーション開発者は、より多くの機能性を加えることができます。
Developing multicast-enabled applications is ostensibly simple. Having datagram access allows any application to send to a multicast address. A multicast application need only increase the Internet Protocol (IP) time-to-live (TTL) value to more than 1 (the default value) to allow outgoing datagrams to traverse routers. To receive a multicast datagram, applications join the multicast group, which transparently generates an [IGMPv2, IGMPv3] group membership report.
マルチキャストで可能にされたアプリケーションを開発するのは表面上簡単です。 データグラムアクセスを持っているのに、どんなアプリケーションもマルチキャストアドレスに発信します。 マルチキャストアプリケーションは、発信データグラムがルータを横断するのを許容するためには生きるインターネットプロトコル(IP)時間(TTL)値を1(デフォルト値)以上まで増強するだけでよいです。 マルチキャストデータグラムを受け取るために、アプリケーションはマルチキャストグループに加わります。(透過的に、それは、[IGMPv2、IGMPv3]グループ会員資格レポートを作ります)。
This apparent simplicity is deceptive, however. Enabling multicast support in applications and protocols that can scale well on a heterogeneous network is a significant challenge. Specifically, sending constant bit rate datastreams, reliable data delivery, security, and managing many-to-many communications all require special consideration. Some solutions are available, but many of these services are still active research areas.
しかしながら、この見かけの簡単さはあてになりません。異機種ネットワークでよく比例できるアプリケーションとプロトコルにおけるマルチキャストサポートを可能にするのは、重要な挑戦です。 明確に、送付固定ビットレートdatastreamsと、確実な資料配送と、保証と、多くへの多くコミュニケーションを管理するのは特別の配慮をすべて必要とします。 何らかの解決法は利用可能ですが、これらのサービスの多くがまだアクティブな研究領域です。
1.1 Motivation
1.1 動機
The purpose of this document is to provide a framework for understanding the challenges of designing and implementing multicast applications. In order to use multicast communications correctly, application developers must first understand the various I/O models and the network services (in addition to basic multicast communication) that are required. Secondly, application developers
このドキュメントの目的はマルチキャストアプリケーションを設計して、実装する挑戦を理解しているのにフレームワークを提供することです。 正しくマルチキャストコミュニケーションを使用するために、アプリケーション開発者は最初に、必要である様々な入出力モデルとネットワーク・サービス(基本のマルチキャストコミュニケーションに加えた)を理解しなければなりません。 第二にアプリケーション開発者
Quinn, et al. Informational [Page 2] RFC 3170 IP Multicast Applications September 2001
クイン、他 [2ページ]情報のRFC3170IPマルチキャストアプリケーション2001年9月
need to be aware of efforts underway to provide these services. Such efforts range in maturity from deployed commercial products to basic research efforts to evaluate feasibility.
これらのサービスを提供するためには進行中の取り組みを意識しているのが必要です。 そのような取り組みは、配布している商品から基礎研究取り組みまでの円熟のときに実行可能性を評価するために及びます。
Multicast-based applications and services will play an important role in the future of the Internet as continued multicast deployment encourages their use and development. It is important that developers be aware of the issues and solutions available--and especially of their limitations--in order to avoid protocols that negatively impact networks (thereby counter-acting the benefits of multicast) or wasting their efforts "re-inventing the wheel".
継続的なマルチキャスト展開が彼らの使用と開発を奨励するとき、マルチキャストベースのアプリケーションとサービスは将来、インターネットを重要な役割を果たすでしょう。 開発者が否定的に、ネットワーク(その結果、マルチキャストの利益を打ち消す)に影響を与えるプロトコルか「ホイールを再発明し」ながら無駄骨を折るのを避けるために、利用可能な問題とソリューション(そして、特に彼らの制限について)を意識しているのは、重要です。
The hope is that by raising developers' awareness, we can adjust their expectations of finding solutions and lead them to successful, scalable, and "network-friendly" development efforts.
望みは私たちが開発者の認識を提起することによって、調査結果解決への彼らの期待を調整して、それらをうまくいっていて、スケーラブルで、「ネットワークに優しい」開発努力に導くことができるということです。
1.2 Focus and Scope
1.2 焦点と範囲
Our initial premise is that the multicast infrastructure is transparent to applications, so it is not directly relevant to this discussion. Our focus here is on multicast application protocol services, so this document explicitly avoids any discussion of multicast routing issues. We identify and describe the multicast- specific issues involved with developing applications.
マルチキャストインフラストラクチャがアプリケーションに見え透いているという私たちの初期の前提があるので、それは直接この議論に関連していません。 マルチキャストアプリケーション・プロトコルサービスにはここの私たちの焦点があるので、このドキュメントは明らかにマルチキャストルーティング問題のどんな議論も避けます。 私たちは、展開しているアプリケーションにかかわるマルチキャストの特定の問題について、特定して、説明します。
We assume the reader has a general understanding of the mechanics of multicast, and in this respect we intend to compliment other introductory documents [BeauW, Maufer, Miller]. Since this is an introductory survey rather than a comprehensive examination, we refer readers to other multicast application requirements descriptions [RM, LSMA, Miller] for more detail.
私たちは、読者にはマルチキャストの整備士の一般的な意味解釈があると思います、そして、この点で、他の紹介しているドキュメント[BeauW、Maufer、ミラー]を賞賛するつもりです。 これが包括的な試験よりむしろ紹介している調査であるので、私たちはその他の詳細のための他のマルチキャストアプリケーション要件記述[RM、LSMA、ミラー]に読者を差し向けます。
In the remainder of this document we first define the term "IP multicast enabled network", the multicast infrastructure and essential multicast services. Next we describe the types of new functionality that multicast applications can enable and their requirements. We then examine the services that satisfy these requirements, the challenges they present, and provide a brief survey of the solutions available or under development. We wrap up with a discussion of application programming interfaces (APIs) for multicast services.
このドキュメントの残りでは、私たちは最初に、「IPマルチキャストはネットワークを可能にした」用語、マルチキャストインフラストラクチャ、および不可欠のマルチキャストサービスを定義します。 次に、私たちはマルチキャストアプリケーションが可能にすることができる新しい機能性のタイプとそれらの要件について説明します。 私たちは、次に、これらの要件を満たすサービス、それらが提示する挑戦を調べて、利用可能であるか開発中のソリューションの概略調査を提供します。 私たちはマルチキャストサービスのために、アプリケーションの議論でプログラミングインターフェース(API)を包みます。
2. IP Multicast Enabled Network
2. IPマルチキャストはネットワークを可能にしました。
An "IP multicast-enabled network" provides end-to-end services in the IP network infrastructure to allow any IP host to send datagrams to an IP multicast address that any number of other IP hosts widely dispersed can receive.
どんなIPホストもいずれも付番する広く分散している缶が受ける他のIPホストのIPマルチキャストアドレスにデータグラムを送るのを許容するために「IPはネットワークをマルチキャストで可能にしたこと」を終わりから終わりに対するサービスをIPネットワークインフラに提供します。
Quinn, et al. Informational [Page 3] RFC 3170 IP Multicast Applications September 2001
クイン、他 [3ページ]情報のRFC3170IPマルチキャストアプリケーション2001年9月
There are two kinds of multicast-enabled networks available. The first is based on the original multicast service model as defined in RFC 1112 [Deering]. In this model, a receiver simply joins the group and does not need to know the identity of the source(s). This model is known by a number of names including Internet Standard Multicast (ISM), Internet Traditional Multicast (ITM), Deering multicast, etc. The second kind of multicast modifies the original service model such that in addition to knowing the group address, a receiver must know the set of relevant sources. This type of multicast is called Source Specific Multicast (SSM) [SSM]. It becomes the application's responsibility to know what kind of multicast capability the network provides. Currently, the only way for an application to know the type of multicast is based on the group address. If the group is in the 232/8 range, the application should assume SSM is the service model. Otherwise, the application should assume source-generic multicast is the service model.
利用可能な2種類のマルチキャストで可能にされたネットワークがあります。 1番目はRFC1112[デアリング]で定義されるようにオリジナルのマルチキャストサービスモデルに基づいています。 このモデルでは、受信機は、単にグループに加わって、ソースのアイデンティティを知る必要はありません。 このモデルはインターネットStandard Multicast(ISM)、インターネットTraditional Multicast(ITM)、デアリングマルチキャストなどを含む多くの名前によって知られています。 2番目の種類のマルチキャストがオリジナルのサービスモデルを変更するので、グループアドレスを知っていることに加えて、受信機は関連ソースのセットを知らなければなりません。 このタイプのマルチキャストはSource Specific Multicast(SSM)[SSM]と呼ばれます。 ネットワークがどういうマルチキャスト能力を提供するかを知るのがアプリケーションの責任になります。 現在、アプリケーションがマルチキャストのタイプを知る唯一の方法がグループアドレスに基づいています。 グループが232/8範囲にあるなら、アプリケーションは、SSMがサービスモデルであると仮定するべきです。 さもなければ、アプリケーションは、ソースジェネリックマルチキャストがサービスモデルであると仮定するべきです。
At the time of this writing, end-to-end "global" multicast service is not yet available, but the size of the "multicast-enabled" Internet is growing. Recent development and deployment of interdomain multicast routing protocols and multicast-friendly Internet exchanges have enabled peering between major ISPs. This, along with the increasing availability of compelling content, is spurring deployment and availability of the IP Multicast Enabled Network.
この書くこと時点で、終わりから終わりに対するマルチキャスト「グローバルな」サービスはまだ利用可能ではありませんが、「マルチキャストで可能にされた」インターネットのサイズは成長しています。 interdomainマルチキャストルーティング・プロトコルとマルチキャストに優しいインターネット交換の最近の進展と展開は主要なISPの間のじっと見ることを可能にしました。 これは無視できない内容の増加する有用性と共にIP Multicast Enabled Networkの展開と有用性に拍車をかけています。
In the remainder of this document we assume that the multicast- enabled network is already ubiquitous. Since such a large and growing portion of the global Internet is IP multicast-enabled now, and many enterprise networks (intranets) are also, this perspective is relevant today.
このドキュメントの残りでは、私たちは、マルチキャストの可能にされたネットワークが既に遍在していると思います。 この見解は、世界的なインターネットのそのような大きくて増加している部分がIPが現在をマルチキャストで可能にしたということであり、また、多くの企業網(イントラネット)がことであるので、今日、関連しています。
2.1 Essential Protocol Components
2.1 不可欠のプロトコルコンポーネント
An IP multicast enabled network requires two essential protocol components:
IP、マルチキャストの可能にされたネットワークは2つの不可欠のプロトコルコンポーネントを必要とします:
1) An IP host-based protocol to allow a receiver application to
notify a local router(s) that it has joined the group, and
initiate the data flow from all sender(s) within the scope
1) 受信側アプリケーションがグループに加わったことをローカルルータに通知して、範囲の中のすべての送付者からデータフローを開始するのを許容するIPのホストベースのプロトコル
2) An IP router-based protocol to allow any routers with multicast
group members (receivers) on their local networks to communicate
with other routers to ensure that all datagrams sent to the
group address are forwarded to all receivers within the intended
scope
2) マルチキャストグループのメンバー(受信機)がそれらの企業内情報通信網の一員であることでのどんなルータもグループアドレスに送られたすべてのデータグラムが意図している範囲の中のすべての受信機に送られるのを保証するために他のルータとコミュニケートするのを許容するIPのルータベースのプロトコル
Quinn, et al. Informational [Page 4] RFC 3170 IP Multicast Applications September 2001
クイン、他 [4ページ]情報のRFC3170IPマルチキャストアプリケーション2001年9月
Ideally, these protocol components are transparent to multicast applications. However, there are two aspects of their functionality requirements that are worth mentioning specifically, since they affect application performance and design. These are the multicast application requirements for:
理想的に、これらのプロトコルコンポーネントはマルチキャストアプリケーションに透明です。 しかしながら、それらの明確に言及する価値がある機能性要件の2つの局面があります、アプリケーション性能とデザインに影響するので。 これらは以下のためのマルチキャストアプリケーション要件です。
- Expedient Joins and Leaves
- Sends without a Join
- 手段は、接合して、いなくなります--aなしで発信する、接合
2.1.1 Expedient Joins and Leaves
2.1.1 手段は、接合して、いなくなります。
Some applications require expedient group joins and leaves, as their usability or functionality are sensitive to the latency involved with joining and leaving a group.
それらのユーザビリティか機能性が接合にかかわる潜在に機密であるときに、接合して、いなくなって、グループを出て、いくつかのアプリケーションが好都合なグループを必要とします。
Join Latency: The time it takes for data to begin flowing after an
application issues a command to join a multicast group
潜在を接合してください: わざわざアプリケーションがマルチキャストグループに加わるコマンドを発行した後にそれがデータが流れ始める
Leave Latency: The time it takes for data to stop flowing after an
application issues a command to leave a multicast group
[IGMPv2,IGMPv3]
潜在を残してください: わざわざデータがアプリケーションがマルチキャストグループを出るコマンドを発行した後に流れるのをそれが止まる[IGMPv2、IGMPv3]
For example, using distributed a/v as a multicast-based "television" must allow users to "channel surf"--changing channels frequently. Each channel change generates a group leave and group join, so delays in either will affect usability. In a sense, this is more of a user requirement than an application requirement.
例えば、マルチキャストベースの「テレビ」が、頻繁にチャンネルを変えて、ユーザが「チャンエルサーフィンすること」を許容しなければならないので、使用は/vを分配しました。 各チャネル変化が、グループが休暇であることを作って、グループが加わるので、どちらかの遅れはユーザビリティに影響するでしょう。 ある意味で、これはアプリケーション要件よりユーザ要件です。
The functionality of distributed interactive simulations [DIS] is often sensitive to join/leave latency. This is particularly true when trying to exchange information to represent fast moving objects that quickly enter and exit the scope of a simulated environment (e.g., low-flying, fast-moving aircraft). If the join latency is too long, the information provided may be old by the time it is received.
分配された対話的なシミュレーション[DIS]の機能性は、潜在を接合するか、または残すためにしばしば機密です。 速くすばやくシミュレート環境(例えば、飛ばしていて低い、速く運動している航空機)の範囲に入って、出る物体を動かしながら表す情報を交換しようとするとき、これは特に本当です。 接合してください。潜在が長過ぎる、それが受け取られている時までに提供された情報は古くてもよいです。
A fast leave phase is highly desirable both for effective congestion control mechanisms, to stop undesirable flows quickly, and for the network in general, to better filter unwanted traffic [Rizzo]. Applications cannot affect control over either join or leave latency, but are dependent on the multicast infrastructure to enable expedient operations. This is a basic multicast service requirement.
速い休暇はすぐに、そして、および一般に、ネットワークのために有効な混雑がともにメカニズムを制御する停止好ましくない人に流れますフェーズが非常に望ましい、フィルタよりよく求められていないトラフィック[リゾー]に。 アプリケーションに影響できません。どちらかのコントロールは、潜在を接合するか、または残しますが、好都合な操作を可能にするマルチキャストインフラストラクチャに依存しています。 これは基本のマルチキャストサービス要件です。
2.1.2 Sends without a Join
2.1.2、発信、aがなければ、接合してください。
Applications that send to a multicast address should be able to start sending immediately, without having to join the destination group first. This is important for embedded devices and bursty-source applications with low-delay delivery requirements.
マルチキャストアドレスに発信するアプリケーションは、すぐに発信し始めることができるべきです、最初に目的地グループに加わる必要はなくて。 組み込み機器とbursty-ソースアプリケーションに、これは低い遅延配送要件によって重要です。
Quinn, et al. Informational [Page 5] RFC 3170 IP Multicast Applications September 2001
クイン、他 [5ページ]情報のRFC3170IPマルチキャストアプリケーション2001年9月
The current IGMP-based multicast host model and all current implementations allow senders to send to a group without joining it as a standard feature.
現在のIGMPベースのマルチキャストホストモデルとすべての現在の実装で、標準装備としてそれを接合しないで、送付者はグループに発信できます。
3. IP Multicast Application Taxonomy
3. IPマルチキャストアプリケーション分類学
With an IP multicast-enabled network available, some unique and powerful applications and application services are possible. "Multicast enables coordination - it is well suited to loosely coupled distributed systems (of people, servers, databases, processes, devices...)" [Estrin].
IPがマルチキャストで可能にされたネットワーク利用可能な状態で、いくつかのユニークで強力なアプリケーションとアプリケーション・サービスが可能です。 「マルチキャストはコーディネートを可能にします--緩く結合した分散システム(プロセス、人々、サーバ、データベースのデバイス…)によく合っている」[Estrin]。
A "multicast application" is simply defined as any application that sends to and/or receives from an IP multicast address. These may or may not also reference IP unicast addresses, as we describe later.
「マルチキャストアプリケーション」は単にIPマルチキャストアドレスから発信する、そして/または、受信されるどんなアプリケーションとも定義されます。 これらは私たちが後で説明するようにIPユニキャストが扱う参照もそうするかもしれません。
What differentiates IP multicast applications from one-to-one unicast applications are the other sender and receiver relationships multicast enables. There are three general categories of multicast applications:
1〜1つのユニキャストアプリケーションまでIPマルチキャストアプリケーションを区別することは、関係マルチキャストが可能にするもう片方の送付者と受信機です。 マルチキャストアプリケーションの3つの一般的なカテゴリがあります:
One-to-Many (1toM): A single host sending to two or more (n)
receivers
多くへの1(1toM): 2台以上の(n)受信機に発信する独身のホスト
Many-to-Many (MtoM): Any number of hosts sending to the same
multicast group address, as well as receiving from it
多くへの多く(MtoM): それから受信することと同様に同じマルチキャストグループアドレスに発信するいろいろなホスト
Many-to-One (Mto1): Any number of receivers sending data back to a
(source) sender via unicast or multicast
1つへの多く(Mto1): ユニキャストかマルチキャストで(ソース)送付者にデータを送り返すいろいろな受信機
Quinn, et al. Informational [Page 6] RFC 3170 IP Multicast Applications September 2001
クイン、他 [6ページ]情報のRFC3170IPマルチキャストアプリケーション2001年9月
+-----------------------------------+
| Host 2->n ("many") |
+-------------+---------------------+
| One-Way | Two-Way |
+-------------+---------------------|
| A B | C D E |
+-----------+-------------+---------------------+
| I/O | | S(m)/ S(u)/ S(m)/|
| Operations| S(m) R(m) | R(m) R(m) R(u) |
+-------+---+-----------+-------------+---------------------|
| | 1 | S(m) | 1toM | MtoM |
| Host | 2 | R(m) | Mto1 | MtoM |
| +---+-----------+-------------+ |
| 1 | 3 | S(m)/R(m) | Mto1 1toM MtoM |
| | 4 | S(m)/R(u) | Mto1 |
|("one")| 5 | S(u)/R(m) | Mto1 |
+-------+---+-----------+-----------------------------------+
+-----------------------------------+ | 2ホスト>n(「多く」の)| +-------------+---------------------+ | 一方向| ツーウェイ| +-------------+---------------------| | B| C D E| +-----------+-------------+---------------------+ | 入出力| | S(m)/ S(u)/ S(m)/| | 操作| S(m) R(m)| R(m) R(m) R(u)| +-------+---+-----------+-------------+---------------------| | | 1 | S(m)| 1toM| MtoM| | ホスト| 2 | R(m)| Mto1| MtoM| | +---+-----------+-------------+ | | 1 | 3 | S(m)/R(m)| Mto1 1toM MtoM| | | 4 | S(m)/R(u)| Mto1| |(「1つ」)| 5 | S(u)/R(m)| Mto1| +-------+---+-----------+-----------------------------------+
Legend: S: "Send" (u): "unicast"
------ R: "Receive" (m): "multicast"
伝説: S: 「発信してください」という(u): 「ユニキャスト」------ R: 「受信してください」という(m): 「マルチキャスト」
Table 1: Application types characterized by I/O relationships
and destination address types (multicast or unicast)
テーブル1: 入出力関係によって描写されたアプリケーションタイプと目的地アドレスタイプ(マルチキャストかユニキャスト)
Table 1 defines these application types in terms of the I/O relationships they represent. These categories are defined in terms of the combination of communication mechanisms they use. At the IP level, all multicast I/O is only 1toM or MtoM and unicast is always one-to-one (1to1). The Mto1 category, for example, refers to several possible combinations of IP-level relationships, including unicast. We created the Mto1 category to help differentiate between the many applications and services that use multicast.
テーブル1は彼らが表す入出力関係に関してこれらのアプリケーションタイプを定義します。 これらのカテゴリはそれらが使用するコミュニケーションメカニズムの組み合わせで定義されます。 いつも、ユニキャストは、1〜すべてのマルチキャスト入出力が、IPレベルにおいて、1toMかMtoMであるにすぎなく、1(1to1)です。 例えば、ユニキャストを含んでいて、Mto1カテゴリはIP-レベル関係のいくつかの可能な組み合わせについて言及します。 私たちは、マルチキャストを使用する多くのアプリケーションとサービスを区別するのを助けるためにMto1カテゴリを作成しました。
1toM: MtoM: Mto1:
R1 S1/R1 S1
/ / | \ \
S-R2 S2/R2-+-S3/R3 S2-R
\... \ | / .../
Rn Sn/Rn Sn
1toM: MtoM: Mto1: R1 S1/R1 S1 / /| \\S-R2 S2/R2+S3/R3 S2-R\… \ | / .../Rn Sn/Rn Sn
Legend: S: "Sender"
------ R: "Receiver"
伝説: S: 「送付者」------ R: 「受信機」
Figure 1: Generalization of the three application categories
図1: 3つのアプリケーションカテゴリの一般化
Figure 1 illustrates the general model for each of the three multicast application categories. Again it is worth emphasizing that Mto1 is an artificial category defined by the application-level
図1はそれぞれの3つのマルチキャストアプリケーションカテゴリのために一般的なモデルを例証します。 一方、Mto1がアプリケーションレベルによって定義された人工のカテゴリであると強調する価値があります。
Quinn, et al. Informational [Page 7] RFC 3170 IP Multicast Applications September 2001
クイン、他 [7ページ]情報のRFC3170IPマルチキャストアプリケーション2001年9月
relationship between sender(s) and receiver. At the IP-level, multicast does not provide an Mto1 I/O mechanism, since it does not allow senders to limit receivers, nor even know who they are. Receiver information and limitations are enabled at the application level, as required by the multicast application.
間の関係、送付者と受信機IP-レベルでは、マルチキャストはMto1入出力メカニズムを提供しません、送付者が受信機を制限するのを許容して、彼らがだれであるかを知ってさえいないので。 受信機情報と制限は必要に応じてアプリケーションレベルでマルチキャストアプリケーションで可能にされます。
We describe each of these general application types in more detail and provide application examples of each in the sub-sections below. The list of examples is not comprehensive, but attempts to define the prominent multicast application and service types in each of the three general categories. We reference the items in these lists in the remainder of this document as we describe their specific service requirements, define the challenges they present, and reference solutions available or under development.
私たちは、さらに詳細にこれらの一般的適用タイプ各人について説明して、それぞれに関するアプリケーションの例を以下の小区分に提供します。 例のリストは、包括的ではありませんが、際立ったマルチキャストアプリケーションを定義するのを試みます、そして、サービスはそれぞれの3つの一般的なカテゴリをタイプします。 それらの特定のサービス要件について説明して、それらが提示する挑戦を定義して、利用可能であるか開発中のソリューションに参照をつけるとき、私たちはこれらのリストでこのドキュメントの残りで項目に参照をつけます。
3.1 One-to-Many Applications
3.1 多くへの1つのアプリケーション
One-to-Many (1toM) applications have a single sender, and multiple simultaneous receivers. Entry B1 in Table 1 represents the classic 1toM relationship. Entry B3 differs only slightly, as the sender also acts as receiver (i.e., it has loopback enabled).
多くへの1つ(1toM)のアプリケーションには、独身の送付者、および複数の同時の受信機があります。 Table1のエントリーB1は古典的な1toM関係を表します。 また、送付者が受信機として務めるとき(すなわち、それで、ループバックを可能にします)、エントリーB3はわずかにだけ異なります。
When people think of multicast, they most often think of broadcast- based multimedia applications: television (video) and radio (audio). This is a reasonable analogy and indeed these are significant multicast applications, but these are far from the extent of applications that multicast can enable. Audio/Video distribution represents a fraction of the multicast application possibilities, and most do not have analogs in today's consumer broadcast industry.
人々がマルチキャストを考えるとき、彼らは放送のベースのマルチメディア応用をたいてい考えます: テレビ(ビデオ)とラジオ(オーディオ)。 これは合理的な類推です、そして、本当にこれらは重要なマルチキャストアプリケーションですが、これらはマルチキャストが可能にすることができるアプリケーションの範囲から遠いです。 オーディオ/ビデオ分配はマルチキャストアプリケーションの可能性の部分を表します、そして、大部分は今日の消費者放送産業でアナログを持っていません。
a) Scheduled audio/video (a/v) distribution: Lectures,
presentations, meetings, or any other type of scheduled event
whose multimedia coverage could benefit an audience (i.e.
television and radio "broadcasts"). One or more constant-bit-
rate (CBR) datastreams and relatively high-bandwidth demands
characterize these applications. When more than one datastream
is present--as with an audio/video combination--the two are
synchronized and one typically has a higher priority than the
other(s). For example, in an a/v combination it is more
important to ensure an intelligible audio stream, than perfect
video.
a) 予定されているオーディオ/ビデオ(/v)分配: 講演(マルチメディア適用範囲が聴衆(すなわち、テレビとラジオ「放送」)のためになることができたプレゼンテーション、ミーティング、またはいかなる他のタイプの予定されているイベントも)。 そして、1つ以上の一定のビット-レート(CBR)のdatastreams、比較的、高帯域要求はこれらのアプリケーションを特徴付けます。 1datastreamがオーディオ/ビデオ組み合わせのように存在しています--2が同期して、1つにもう片方の(s)より高い優先度が通常あるとき。 例えば、a/v組み合わせでは、明瞭なオーディオストリームを確実にするのは完全なビデオより重要です。
b) Push media: News headlines, weather updates, sports scores, or
other types of non-essential dynamic information. "Drip-feed",
relatively low-bandwidth data characterize these applications.
b) メディアを押してください: ニュース見出し、気象アップデートはスコア、または他のタイプの不要不急な動的情報を見せびらかします。 「したたりで食べてください」、比較的、低バンド幅データはこれらのアプリケーションを特徴付けます。
Quinn, et al. Informational [Page 8] RFC 3170 IP Multicast Applications September 2001
クイン、他 [8ページ]情報のRFC3170IPマルチキャストアプリケーション2001年9月
c) File Distribution and Caching: Web site content, executable
binaries, and other file-based updates sent to distributed
end-user or replication/caching sites
c) 分配とキャッシュをファイルしてください: ウェブサイト内容、実行可能な2種混合毒ガス、および分配されたエンドユーザか模写/キャッシュサイトに送られた他のファイルベースのアップデート
d) Announcements: Network time, multicast session schedules,
random numbers, keys, configuration updates, (scoped) network
locality beacons, or other types of information that are
commonly useful. Their bandwidth demands can vary, but
generally they are very low bandwidth.
d) 発表: ネットワーク時間、マルチキャストセッションスケジュール、乱数、キー(構成アップデート)は一般的に役に立つ場所標識、または他のタイプの情報をネットワークでつなぎます(見られます)。 彼らの帯域幅要求は異なることができますが、一般にそれらは非常に低い帯域幅です。
e) Monitoring: Stock prices, Sensor equipment (seismic activity,
telemetry, meteorological or oceanic readings), security
systems, manufacturing or other types of real-time information.
Bandwidth demands vary with sample frequency and resolution,
and may be either constant-bit-rate or bursty (if event-
driven).
e) モニターします: 株価、Sensor設備(地震活動、遠隔測定法、気象学の、または、海洋の読書)、セキュリティシステム、製造または他のタイプのリアルタイムの情報。 帯域幅要求は、サンプル頻度と解決に従って異なって、固定ビットレートかburstyのどちらかであるかもしれません(イベント駆動であるなら)。
3.2 Many-to-Many Applications
3.2 多くへの多くアプリケーション
In many-to-Many (MtoM) applications two or more of the receivers also act as senders. In other words, MtoM applications are characterized by two-way multicast communications.
また、多くへの多く(MtoM)アプリケーションでは、2台以上の受信機が送付者として機能します。 言い換えれば、MtoMアプリケーションは両用マルチキャストコミュニケーションによって特徴付けられます。
The many-to-many capabilities of IP multicast enable the most unique and powerful applications. Each host running an MtoM application may receive data from multiple senders while it also sends data to all of them. As a result, many-to-many applications often present complex coordination and management challenges.
多くへの多く、IPマルチキャストの能力は最もユニークで強力なアプリケーションを可能にします。 また、それらのすべてにデータを送る間、MtoMアプリケーションを実行する各ホストは複数の送付者からデータを受け取るかもしれません。 その結果、多くへの多くアプリケーションはしばしば複雑なコーディネートを提示します、そして、管理は挑戦します。
f) Multimedia Conferencing: Audio/Video and whiteboard comprise
the classic conference application. Having multiple
datastreams with different priorities characterizes this type
of application. Co-ordination issues--such as determining who
gets to talk when--complicate their development and usability.
There are common heuristics and "rules of play", but no
standards exist for managing conference group dynamics.
f) マルチメディア会議: オーディオ/ビデオとホワイトボードは古典的な会議アプリケーションを包括します。 異なったプライオリティがある複数のdatastreamsを持っていると、このタイプの適用は特徴とします。 だれが、いつを話し始めるかを決定などなどのコーディネーション問題はそれらの開発とユーザビリティを複雑にします。 一般的な発見的教授法があります、そして、「プレーの規則」が存在していますが、どんな規格も、会議グループ・ダイナミックスを管理するために存在していません。
g) Synchronized Resources: Shared distributed databases of any
type (schedules, directories, as well as traditional
Information System databases).
g) リソースを同期させます: いずれの共有された分散データベースは(スケジュール、ディレクトリ、および伝統的な情報システムデータベース)をタイプします。
h) Concurrent Processing: Distributed parallel processing.
h) 同時処理: 分配された並列処理。
i) Collaboration: Shared document editing.
i) 共同: 共有されたドキュメント編集。
j) Distance Learning: This is a one-to-many a/v distribution
application with "upstream" capability that allows receivers to
question the speaker(s).
j) 学習を遠ざけてください: これは受信機がスピーカーに質問できる「上流」の能力がある多くへの1つのa/v分配アプリケーションです。
Quinn, et al. Informational [Page 9] RFC 3170 IP Multicast Applications September 2001
クイン、他 [9ページ]情報のRFC3170IPマルチキャストアプリケーション2001年9月
k) Chat Groups: These are like text-based conferences, but may
also provide simulated representations ("avatars") for each
"speaker" in simulated environments.
k) チャットは分類されます: これらは、テキストを拠点とする会議に似ていますが、また、それぞれの「スピーカー」のシミュレートされた表現(「アバター」)をシミュレート環境に提供するかもしれません。
l) Distributed Interactive Simulations [DIS]: Each object in a
simulation multicasts descriptive information (e.g., telemetry)
so all other objects can render the object, and interact as
necessary. The bandwidth demands for these can be tremendous,
as the number of objects and the resolution of descriptive
information increases.
l) 分配された対話的なシミュレーション[けなします]: それぞれが、他のすべてのオブジェクトがオブジェクトをレンダリングして、必要に応じて相互作用できるようにシミュレーションマルチキャスト記述的な情報(例えば、遠隔測定法)で反対します。 オブジェクトの数と描写的である情報の解決が増加するのに従って、これらの帯域幅要求は物凄い場合があります。
m) Multi-player Games: Many multi-player games are simply
distributed interactive simulations, and may include chat group
capabilities. Bandwidth usage can vary widely, although
today's first-generation multi-player games attempt to minimize
bandwidth usage to increase the target audience (many of whom
still use dial-up modems).
m) マルチプレーヤーゲーム: 多くのマルチプレーヤーゲームが、単に分配された対話的なシミュレーションであり、チャットグループ能力を含むかもしれません。 帯域幅用法はばらつきが大きいことができます、今日の第一世代マルチプレーヤーゲームが、対象者(その多くがまだダイヤルアップモデムを使用している)を増強するために帯域幅用法を最小にするのを試みますが。
n) Jam Sessions: Shared encoded audio (e.g., music). The
bandwidth demands vary based on the encoding technique, sample
rate, sample resolution, number of channels, etc.
n) ジャム・セッション: 共有されたコード化されたオーディオ(例えば、音楽)。 帯域幅要求はコード化のテクニック、見本郵送料率、サンプル解決、チャンネルの数などに基づいて異なります。
3.3 Many-to-One Applications
3.3 1つへの多くアプリケーション
Unlike the one-to-many and many-to-many application categories, the many-to-one (Mto1) category does not represent a communications mechanism at the IP layer. Mto1 applications have multiple senders and one (or a few) receiver(s), as defined by the application layer. Table 1 shows that Mto1 applications can be one-way or use a two-way request/response type protocol, where either senders or receiver(s) may generate the request. Figure 2 characterizes the I/O relationship possibilities in Mto1 applications:
多くへの1と多くへの多くアプリケーションカテゴリ、1つへの多く、(Mto1)カテゴリはIP層にコミュニケーションメカニズムを表しません。 Mto1アプリケーションには、複数の送付者と1台(または、いくつか)の受信機が応用層のそばで定義されるようにあります。 テーブル1は、Mto1アプリケーションが一方向である、または両用要求/応答タイププロトコルを使用できるのを示します。(そこでは、送付者か受信機のどちらかが要求を生成するかもしれません)。 図2はMto1アプリケーションにおける入出力関係の可能性を特徴付けます:
Mto1 applications have many scaling issues. Too many simultaneous senders can potentially overwhelm receiver(s), a condition characterized as an "implosion problem". Another considerable scaling problem is the large amount of state in the network that having many multicast senders generates. This is largely transparent to applications and the effect may be diminished in the future with the use of bi-directional trees in multicast routing protocols, but nonetheless it should be considered by application designers.
Mto1アプリケーションには、多くのスケーリング問題があります。 あまりに多くの同時の送付者が潜在的に受信機、「内部破裂問題」として特徴付けられた状態を圧倒できます。 別のかなりのスケーリング問題が多くのマルチキャスト送付者がいると生成するネットワークで多量の状態です。 これはアプリケーションに主に透明です、そして、マルチキャストルーティング・プロトコルにおける双方向の木の使用に応じて、効果は将来、減少するかもしれませんが、それにもかかわらず、それはアプリケーション設計者によって考えられるべきです。
Quinn, et al. Informational [Page 10] RFC 3170 IP Multicast Applications September 2001
クイン、他 [10ページ]情報のRFC3170IPマルチキャストアプリケーション2001年9月
1) S1 2) S1 3) S1 4) S1
\ \ \ \
S2-R S2-R S2-R S2-R
.../ .../ .../ .../
Sn Sn Sn Sn
1) S1 2) S1 3) S1 4) S1\\\\S2-R S2-R S2-R S2-R…/ .../ .../ .../Sn Sn Sn Sn
Data(m) Request(m) Request(m) Request(u)
------> ----------> <---------- ---------->
Response(u) Response(u) Response(m)
<----------- -----------> <----------
データ(m)は(m) 要求(m)要求(u)を要求します。------>。----------><。---------- ---------->応答(u)応答(u)応答(m)<。----------- -----------><。----------
Figure 2: Characterization of Mto1 I/O possibilities
図2: Mto1入出力の可能性の特殊化
No standards yet exist for alternate and equivalent Mto1 application designs, but there are a number of possibilities to consider [HNRS]. Since the main advantage of using multicast in a Mto1 application is that senders need not know the receiver(s) unicast address(es), one alternative is for each receiver to advertise its unicast address via multicast. However, since this strategy still leaves the potential for implosion on each receiver, additional strategies may be needed to distribute the load. For example, it may be possible to increase the number of receivers (in a "flat" receiver topology) or establish localized receivers (in a "hierarchical" topology) as used in "local recovery" (section 5.3). Such methods have coordination issues, and since standard solutions have not yet been identified, Mto1 application developers should consider their alternatives carefully.
規格は全く代替の同等なMto1アプリケーション設計のためにまだ存在していませんが、考える多くの可能性[HNRS]があります。 Mto1アプリケーションでマルチキャストを使用する主な利点が送付者が受信機ユニキャストアドレス(es)を知る必要はないということであるので、1つの選択肢がマルチキャストでユニキャストアドレスの広告を出す各受信機のためのものです。 しかしながら、この戦略が各受信機の上にまだ内部破裂の可能性を残しているので、追加戦略が負荷を分配するのに必要であるかもしれません。 例えば、受信機(「平坦な」受信機トポロジーの)の数を増強するか、またはローカライズしている受信機(「階層的な」トポロジーの)を設立するのが「地方の回復」(セクション5.3)に使用されるように可能であるかもしれません。 そのようなメソッドには、コーディネート問題があります、そして、標準液がまだ特定されていないので、Mto1アプリケーション開発者は慎重に彼らの代替手段を考えるべきです。
o) Resource Discovery: Service Location, for example, leverages IP
Multicast to enable something like a "host anycasting service"
capability [AnyCast]: A multicast receiver to send a query to a
group address, to elicit responses from the closest host so
they can satisfy the request. The responses might also contain
information that allows the receiver to determine the most
appropriate (e.g., closest) service provider to use.
o) リソース発見: 例えば、サービスLocationは「ホストanycastingサービス」のように能力[AnyCast]を可能にするためにIP Multicastを利用します: グループアドレスに質問を送って、彼らが要望に応じることができるように最も近いホストから応答を聞き出すマルチキャスト受信機。 また、応答は受信機が決定できる中でサービスプロバイダー最も適切である(例えば、最も近い)情報を使用に含むかもしれません。
In Table 1, this application is entry D4. It is also
illustrated in Figure 2 by possibility number 3.
Alternately, the response could be to a multicast rather
than unicast address, although technically that would make
it an MtoM application type (this is how the Service
Location Protocol [SLP] operates, when a user agent attempts
to locate a directory agent).
Table1では、このアプリケーションはエントリーD4です。 また、それは図2で可能性No.3によって例証されます。 交互に、ユニキャストアドレスよりむしろマルチキャストには応答があるかもしれません、それはそれをMtoMアプリケーションタイプに技術的にするでしょうが(これがService Locationプロトコル[SLP]がどう作動するかということです、ユーザエージェントが、ディレクトリエージェントの居場所を見つけるのを試みるとき)。
p) Data Collection: This is the converse of a one-to-many
"monitoring" application described earlier. In this case there
may be any number of distributed "sensors" that send data to a
data collection host. The sensors might send updates in
response to a request from the data collector, or send
p) データ収集: これは、より早く説明された多くへの1つの「モニターしている」アプリケーションの逆です。 この場合、データ収集ホストにデータを送るいろいろな分配された「センサ」があるかもしれません。 センサは、データコレクタからの要求に対応してアップデートを送るか、または発信するかもしれません。
Quinn, et al. Informational [Page 11] RFC 3170 IP Multicast Applications September 2001
クイン、他 [11ページ]情報のRFC3170IPマルチキャストアプリケーション2001年9月
continuously at regular intervals, or send spontaneously when a
pre-defined event occurs. Bandwidth demands can vary based on
sample frequency and resolution.
連続、一定の間隔を置いて、事前に定義されたイベントが起こったら、自然に発信してください。 帯域幅要求はサンプル頻度と解決に基づいて異なることができます。
This is illustrated in Table 1 by entries A1 and A3, the only
difference being that A3 has a loopback interface. In Figure
2, this is possibility number 1. Since the number of receivers
can easily be more than one, this is really an MtoM
application.
これはTable1でエントリーのA1とA3によって例証されます、唯一の違いがA3にはループバックインタフェースがあるということであり。 図2では、これは可能性No.1です。 受信機の数が容易に1以上であることができるので、これは本当にMtoMアプリケーションです。
q) Auctions: The "auctioneer" starts the bidding by describing
whatever it is for sale (product or service or whatever), and
receivers send their bids privately or publicly (i.e., to a
unicast or multicast address).
q) オークション: それが販売(製品、サービスまたは何でも)のためのことなら何でもであるかと説明することによって、「競売人」は入札を始めます、そして、受信機は公的(すなわち、ユニキャストかマルチキャストアドレスに)に彼らの付け値を個人的に送ります。
This is possibility number 2 in Figure 2, and D5 in Table 1.
The response could be sent to a multicast address, although
technically that would make it an MtoM application.
これは図2、およびTable1のD5の可能性No.2です。 それはそれをMtoMアプリケーションに技術的にするでしょうが、マルチキャストアドレスに応答を送ることができました。
r) Polling: The "pollster" sends out a question, and the "pollees"
respond with answers. This is possibility number 2 in Figure
2, and could also be characterized as an MtoM application if
the response is to a multicast address.
r) 世論調査: 「世論調査員」は質問を出します、そして、「世論調査の対象者」は答えで応じます。 これは、図2の可能性No.2であり、また、マルチキャストアドレスに応答があるなら、MtoMアプリケーションとして特徴付けられるかもしれません。
s) Jukebox: Allows near-on-demand a/v playback. Receivers use an
"out-of-band" protocol mechanism (via web, email, unicast or
multicast requests, etc.) to send their playback request into a
scheduling queue [IMJ].
s) ジュークボックス: 近く要求次第のa/v再生を許容します。 受信機は、スケジューリング待ち行列[IMJ]に彼らの再生要求を送るのに、「バンドの外」というプロトコルメカニズム(ウェブやメールやユニキャストやマルチキャスト要求などを通した)を使用します。
This is characterized by possibility number 4 in Figure 2, and
entry D4 in Table 1. The initial unicast request is the only
difference between this type of application and a typical 1toM.
If that initial request were sent to a multicast address, this
would effectively be an MtoM application.
これは図2の可能性No.4、およびTable1のエントリーD4によって特徴付けられます。 初期のユニキャスト要求はこのタイプの適用と典型的な1toMの唯一の違いです。 その初期の要求をマルチキャストアドレスに送るなら、事実上、これはMtoMアプリケーションでしょうに。
t) Accounting: This is basically data collection but is worth
separating since it is such an important application. In some
multicast applications it is imperative to know information
about each receiver, possibly in real-time. But such
information can be overwhelming [MRM]. Current mechanisms,
like RTCP (which is actually MtoM since it is multicast but
could be made Mto1), use scaling techniques but trade-off
information granularity. As a group grows the total amount of
feedback is constant but each receiver sends less.
t) 会計: これは、それが非常に重要なアプリケーションであるので、基本的にデータ収集ですが、切り離す価値があります。 いくつかのマルチキャストアプリケーションでは、ことによるとリアルタイムでで各受信機の情報を知るのは必須です。 しかし、そのような情報は圧倒的である場合があります[MRM]。 RTCP(それ以来どれが実際にMtoMであるかはマルチキャストですが、人工のMto1であるかもしれない)のように、現在のメカニズムは尺度構成法にもかかわらず、トレードオフ情報粒状を使用します。 グループが成長するとき、フィードバックの総量は一定ですが、各受信機はそれほど発信しません。
Quinn, et al. Informational [Page 12] RFC 3170 IP Multicast Applications September 2001
クイン、他 [12ページ]情報のRFC3170IPマルチキャストアプリケーション2001年9月
4. Common Multicast Service Requirements
4. 一般的なマルチキャストサービス要件
Some multicast application service requirements are common to unicast network applications as well. We characterize two of them here-- bandwidth and delay requirements.
いくつかのマルチキャストアプリケーションサービス要件がまた、ユニキャストネットワーク応用に共通です。 私たちはここでそれらの2つを特徴付けます--帯域幅と遅れ要件。
4.1 Bandwidth Requirements
4.1 帯域幅要件
Figure 3 shows multicast applications approximate bandwidth requirements.
図3は、マルチキャストアプリケーションが帯域幅要件に近似するのを示します。
Unicast and multicast applications both need to design applications to adapt to the variability of network conditions. But as we describe in section 5.3, it is the need to accommodate multiple heterogeneous multicast receivers--with their diversity of bandwidth capacity and delivery delays--that presents the unique challenge for multicast applications to satisfy these requirements.
ユニキャストとマルチキャストアプリケーションは、ともにネットワーク状態の可変性に順応するようにアプリケーションを設計する必要があります。 しかし、私たちがセクション5.3で説明するように、マルチキャストアプリケーションがこれらの要件を満たすユニークな挑戦を提示するのは、それらの帯域幅容量と配送遅れの多様性がある複数の異種のマルチキャスト受信機を収容する必要性です。
|
1toM | b, d c, e a
|
MtoM | k g, i f, h, j, l, m, n
|
Mto1 | o, q, r p, t s
|
+-----------------------------------------------
Low Bandwidth High Bandwidth
| 1toM| b、d c、e a| MtoM| k g、i f、h、j、l、m、n| Mto1| o, q、r p、t s| +----------------------------------------------- 低い帯域幅高帯域
Figure 3: Bandwidth Requirements of applications
図3: アプリケーションの帯域幅Requirements
4.2 Delay Requirements
4.2 遅れ要件
Aside from those with time-sensitive data (e.g., stock prices, and real-time monitoring information), most one-to-many applications have a high tolerance for delay and delay variance (jitter). Constant bit-rate (CBR) data--such as streaming media (audio/video)--are sensitive to jitter, but applications commonly counteract the effects by buffering data and delaying playback.
時間極秘データ(例えば、株価、およびリアルタイムの監視情報)があるそれらは別として、ほとんどの多くへの1つのアプリケーションには、遅れと遅れ変化(ジター)のための高い寛容があります。 ストリーミング・メディア(オーディオ/ビデオ)などの一定のビット伝送速度(CBR)データはジターに機密ですが、アプリケーションは、データをバッファリングして、再生を遅らせることによって、効果を一般的に打ち消します。
Most many-to-one and many-to-many multicast applications are intolerant of delays because they are bidirectional, interactive and request/response dependent. As a result, delays should be minimized, since they can adversely affect the application's usability.
それらが双方向で、対話的で要求/応答に依存しているので、ほとんどの1つへの多く、多くへの多くマルチキャストアプリケーションが遅れで偏狭です。 その結果、アプリケーションのユーザビリティに悪影響を与えることができるので、遅れは最小にされるべきです。
This need to minimize delays is most evident in (two-way) conference applications, where users cannot converse effectively if the audio or video is delayed more than 500 milliseconds. For this and other
遅れを最小にするこの必要性は(両用)の会議アプリケーションで最も明白です。そこでは、オーディオかビデオが500ミリセカンド以上と同じくらい遅らせられるなら、ユーザが有効に話すことができません。 これともう一方のために
Quinn, et al. Informational [Page 13] RFC 3170 IP Multicast Applications September 2001
クイン、他 [13ページ]情報のRFC3170IPマルチキャストアプリケーション2001年9月
examples see Figure 4, which plots multicast applications on a (coarse) scale of sensitivity to delivery delays.
例は図4を見ます。(それは、感度の(粗い)のスケールで配送遅れにマルチキャストアプリケーションを企みます)。
|
1toM | b, c a, d e
|
MtoM | g, i, j, k f, h, l, m, n
|
Mto1 | r o, p, s, t q
|
+-----------------------------------------------
Delay Tolerant Delay Intolerant
| 1toM| b、c a、d e| MtoM| g、i、j、k f、h、l、m、n| Mto1| r o、p、s、t q| +----------------------------------------------- 遅れの許容性がある遅れ偏狭です。
Figure 4: Delay tolerance of application types
図4: アプリケーションタイプの遅れ寛容
For delay-intolerant multicast (or unicast) applications, quality of service (QoS) is the only option. IP networks currently provide only "best effort" delivery, so data are subject to variable router queuing delays and loss due to network congestion (router queue overflows). IP QoS standards do exist now [RSVP] and efforts to enable end-to-end QoS support in the Internet are underway [E2EQOS].
遅れ偏狭なマルチキャスト(または、ユニキャスト)アプリケーションのために、サービスの質(QoS)は唯一のオプションです。 IPネットワークが現在「ベストエフォート型」の配送だけを提供するので、データはネットワークの混雑(ルータ待ち行列オーバーフロー)による遅れと損失を列に並ばせる可変ルータを受けることがあります。 IP QoS規格は現在[RSVP]存在します、そして、インターネットで終わりから終わりへのQoSサポートを可能にする取り組みは進行中です[E2EQOS]。
However, QoS support is an IP network infrastructure consideration. Although there are multicast-specific challenges for implementing QoS in the network for multicast flows, they are beyond the control of applications, so further discussion of the QoS protocols and services is beyond the scope of this document.
しかしながら、QoSサポートはIPネットワークインフラの考慮です。 実装するマルチキャスト特有の挑戦がありますが、マルチキャストのためのネットワークにおけるQoSは流れます、彼らがアプリケーションのコントロールを超えています、したがって、QoSプロトコルの、そして、サービスのさらなる議論はこのドキュメントの範囲を超えています。
5. Unique Multicast Service Requirements
5. ユニークなマルチキャストサービス要件
The three application categories described earlier are very general in nature. Within each category and even among each of the application types, specific application instances have a variety of application requirements. One-to-many application types are relatively simple to develop, but as we pointed out there are challenges involved with developing many-to-one and many-to-many applications. Some of these have requirements bandwidth and delay requirements, similar to unicast applications.
より早く説明された3つのアプリケーションカテゴリが現実に非常に一般的です。 各カテゴリ以内と特定のアプリケーションインスタンスの中に、さまざまなアプリケーション要件があります。 多くへの1つのアプリケーションタイプが展開するために比較的純真ですが、私たちが指したので、1つへの展開している多く、多くへの多くアプリケーションにかかわる挑戦があります。 これらの或るものには、ユニキャストアプリケーションと同様の要件帯域幅と遅れ要件があります。
Multicast applications can be further differentiated from unicast applications and from each other by the services they require. In this section we provide a survey of the various services that have unique requirements for multicast applications.
ユニキャストアプリケーションと彼らが必要とするサービスによる互いからマルチキャストアプリケーションをさらに差別化できます。 このセクションに、私たちは色々とマルチキャストアプリケーションのためのユニークな要件があるサービスの調査を供給します。
Quinn, et al. Informational [Page 14] RFC 3170 IP Multicast Applications September 2001
クイン、他 [14ページ]情報のRFC3170IPマルチキャストアプリケーション2001年9月
+--------------------------------------------------------------+
| Multicast Application |
+--------------------------------------+ +-------------------+
+-------------------------------------+| |+--------++--------+
| Multicast Security || || || |
+----------------------+ +----------+| || System || |
+----------++---------+| |+---------+| || Time || Codecs |
| Reliable || Address || || Session || || || |
| Delivery || Mgt || || Mgt || || || |
+----------++---------++---++---------++---++--------++--------+
+----------------------------------------++--------------------+
| Basic IP Multicast Service || IP Unicast |
| (e.g., UDP and IGMPv2/v3) || Service |
+----------------------------------------++--------------------+
+--------------------------------------------------------------+ | マルチキャストアプリケーション| +--------------------------------------+ +-------------------+ +-------------------------------------+| |+--------++--------+ | マルチキャストセキュリティ|| || || | +----------------------+ +----------+| || システム|| | +----------++---------+| |+---------+| || 時間|| コーデック| | 信頼できる|| アドレス|| || セッション|| || || | | 配送|| Mgt|| || Mgt|| || || | +----------++---------++---++---------++---++--------++--------+ +----------------------------------------++--------------------+ | 基本的なIPマルチキャストサービス|| IPユニキャスト| | (例えば、UDPとIGMPv2/v3) || サービス| +----------------------------------------++--------------------+
Figure 5: Multicast service requirements summary
図5: マルチキャストサービス要件概要
Here's the list of multicast application service requirements:
ここに、マルチキャストアプリケーションサービス要件のリストがあります:
Address Management - Selection and coordinated of address
allocation. The need is to provide assurances against "address
collision" and to provide address ownership.
Managementを扱ってください--アドレス配分で選択で連携しています。 必要性は、「アドレス衝突」に対して保証を提供して、アドレス所有権を提供することです。
Session Management - Perform application-layer services on top of
multicast transport. These services depend heavily on the
application but include functions like session advertisement,
billing, group member monitoring, key distribution, etc.
セッションManagement--マルチキャスト輸送の上で応用層サービスを実行してください。 これらのサービスは、大いにアプリケーションによりますが、セッション広告、支払い、グループメンバーモニター、主要な分配などのように機能を含んでいます。
Heterogeneous Receiver Support - Sending to receivers with a wide
variety of bandwidth capacities, latency characteristics, and
network congestion requires feedback to monitor receiver
performance.
異種のReceiver Support--さまざまな帯域幅能力、潜在の特性、およびネットワークの混雑と共に受信機に発信するのは、受信機性能をモニターするためにフィードバックを必要とします。
Reliable Data Delivery - Ensuring that all data sent is received
by all receivers.
信頼できるData Delivery--すべてのデータが発信したのを確実にするのをすべての受信機は受け取ります。
Security - Ensuring content privacy among dynamic multicast group
memberships, and limiting senders.
セキュリティ--ダイナミックなマルチキャストグループ会員資格の中で満足しているプライバシーを確実にして、送付者を制限します。
Synchronized Play-Out - Allow multiple receivers to "replay" data
received in synchronized fashion.
外の連動しているPlay--複数の受信機が連動しているファッションで受け取られたデータを「再演すること」を許容してください。
In the remainder of this section, we describe each of these application services in more detail, the challenges they present, and the status of standardized solutions.
このセクションの残りでは、私たちは標準液のその他の詳細、それらが提示する挑戦、および状態でそれぞれのこれらのアプリケーション・サービスについて説明します。
Quinn, et al. Informational [Page 15] RFC 3170 IP Multicast Applications September 2001
クイン、他 [15ページ]情報のRFC3170IPマルチキャストアプリケーション2001年9月
5.1 Address Management
5.1 アドレス管理
One of the first questions facing a multicast application developer is what multicast address to use. Multicast addresses are not assigned to individual hosts, assignments can change dynamically, and addresses sometimes have semantics of their own (e.g., Admin Scoping). Multicast applications require an address management service that provides address allocation or assignment queries. There are a number of ways for applications to learn about multicast addresses:
マルチキャストアプリケーション開発者に面している最初の質問の1つはどんなマルチキャストアドレスを使用するかということです。 マルチキャストアドレスは個々のホストに割り当てられません、そして、課題はダイナミックに変化できます、そして、アドレスには、それら自身(例えば、Admin Scoping)の意味論が時々あります。 マルチキャストアプリケーションはアドレス配分か課題質問を提供するアドレス経営指導を必要とします。 アプリケーションがマルチキャストアドレスに関して学ぶ多くの方法があります:
Hard-Coded: Software configuration, encoded in a binary
executable, or burned into ROM in embedded devices. These
applications typically reference IANA statically allocated
multicast addresses (including relative addresses).
一生懸命コード化される: 実行可能であるか、組み込み機器でROMに燃えたバイナリーでコード化されたソフトウェア構成。 これらのアプリケーションは静的に割り当てられたマルチキャストが扱うIANAに通常参照をつけます(相対アドレスを含んでいて)。
Advertised: Session announcements (as described in the next
section), or via another "out-of-band" query or discovery protocol
mechanism.
広告を出される: 別の「バンドの外」という質問か発見プロトコルメカニズムを通してセッション発表(次のセクションで説明されるように)。
Algorithmically Derived: Using a programmatic algorithm to
allocate a statistically random (unused) address.
Algorithmicallyを派生させました: 統計的に無作為(未使用の)のアドレスを割り当てるのにプログラムに従ったアルゴリズムを使用します。
|
1toM | c, e a, b d
|
MtoM | f, j, k, n g, h, i, l, m
|
Mto1 | r o, p, s q, t
|
+-----------------------------------------------
Hard-Coded Advertised Algorithmic
| 1toM| c、e a、b d| MtoM| f、j、k、n g、h、i、l、m| Mto1| r o、p、s q、t| +----------------------------------------------- 一生懸命コード化される、広告を出す、アルゴリズム
Figure 6: Multicast address usage for application types
図6: アプリケーションタイプのためのマルチキャストアドレス用法
In almost all cases, application designers should assume that multicast addresses are to be dynamic. Very little of the multicast address space is available for static assignment by IANA [MADDR]. Also, given the host-specific addressing available with SSM, Internet-wide, static address assignment is expected to be very rare.
ほとんどすべての場合、アプリケーション設計者は、マルチキャストアドレスがダイナミックであることであると仮定するべきです。 マルチキャストアドレス空間のわずか、がIANA[MADDR]による静的な課題に利用可能です。 また、SSMと共に利用可能なホスト特有のアドレシングを考えて、インターネット全体的、そして、静的なアドレス課題が非常にまれであると予想されます。
5.2 Session Management
5.2 セッション管理
Session management is one of the most misunderstood services with respect to multicast. Most application developers assume that multicast will provide services like security, encryption, reliability, session advertisement, monitoring, billing, etc. In fact, multicast is simply a transport mechanism that provides end-
セッション管理はマルチキャストに関する最も誤解されたサービスの1つです。 ほとんどのアプリケーション開発者が、マルチキャストがセキュリティ、暗号化、信頼性、モニターしていて、請求しているセッション広告などのようなサービスを提供すると仮定します。 事実上、マルチキャストは単に終わりを提供する移送機構です。
Quinn, et al. Informational [Page 16] RFC 3170 IP Multicast Applications September 2001
クイン、他 [16ページ]情報のRFC3170IPマルチキャストアプリケーション2001年9月
to-end delivery. All of the other services are application-layer services that must be provided by each particular application. Furthermore, in most cases there are not defined standards for how these functions should be provided. The particular functions are dependent on the particular needs of the application, and no single method (or standard) can be made to be sufficient for all cases.
終わりまでの配送。 他のサービスのすべては各特定用途で提供しなければならない応用層サービスです。 その上、多くの場合、どうこれらの機能を提供するべきであるか規格は定義されません。 特定の機能はアプリケーションの特別の必要性に依存しています、そして、すべての場合に十分であることをどんなただ一つのメソッド(または、規格)も作ることができません。
While there are no generic solutions which provide all session management functions, there are some protocols and common techniques that provide support for some of the functions. Techniques for congestion control and heterogeneous receiver support are discussed in Section 5.3. Protocols for reliability are discussed in Section 5.4. Security considerations are discussed in Section 5.5.
すべてのセッション管理機能を提供するジェネリックソリューションが全くありませんが、いくつかの機能のサポートを提供するいくつかのプロトコルと一般的なテクニックがあります。 セクション5.3で輻輳制御と異種の受信機サポートのためのテクニックについて議論します。 セクション5.4で信頼性のためのプロトコルについて議論します。 セクション5.5でセキュリティ問題について議論します。
With respect to session advertisement, there are a number of mechanisms for advertising sessions. One commonly used technique is to advertise sessions via the WWW. Users can join a group by clicking on URLs, and then having a response returned to the user that includes the group address and maybe information about group source(s). Another mechanism is the session description protocol [SDP]. It provides a format for representing information about sessions, but it does not provide the transport for dissemination of these session descriptions, nor does it provide address allocation and management. SDP only provides the syntax for describing session attributes.
セッション広告に関して、多くのメカニズムが広告セッションの間、あります。 1つの一般的に使用されたテクニックは. ユーザが仲間に入ることができるWWWを通したURLをクリックして、次にグループアドレスを含んでいるユーザに応答を返すセッションと多分グループソースの情報の広告を出すことです。 別のメカニズムはセッション記述プロトコル[SDP]です。 これらのセッション記述の普及のための輸送を提供しません、そして、およそセッション情報を表すのに形式を提供しますが、それはアドレス配分と管理を提供しません。 SDPはセッション属性について説明するための構文を提供するだけです。
SDP session descriptions may be conveyed publicly or privately by means of any number of transports including web (HTTP) and MIME encoded email. The session announcement protocol [SAP] is the de facto standard transport and many multicast-enabled applications currently use it. SAP limits distribution via multicast scoping, but the current protocol definition has scaling issues that need to be addressed. Specifically, the initialization latency for a session directory can be quite long, and it increases in proportion to the number of session announcements. This is to an extent a multicast infrastructure issue, however, as this level of protocol detail should be transparent to applications.
SDPセッション記述はウェブ(HTTP)を含むいろいろな輸送によって公的か個人的に伝えられたかもしれません、そして、MIMEはメールをコード化しました。 セッション発表プロトコル[SAP]はデファクトスタンダード輸送です、そして、多くのマルチキャストで可能にされたアプリケーションが現在、それを使用します。 SAPはマルチキャストの見ることを通して分配を制限しますが、現在のプロトコル定義には、扱われる必要があるスケーリング問題があります。 明確に、セッションディレクトリのための初期化潜在はかなり長い場合があります、そして、それはセッション発表の数に比例して増加します。 このレベルのプロトコルの詳細がアプリケーションに見え透くべきであるので、しかしながら、これは程度マルチキャストインフラストラクチャ問題です。
The session management service needs to:
セッション経営指導は、以下のこと必要があります。
- Advertise scheduled sessions
- Provide a query mechanism for retrieving
information about session schedules
- 予定されているセッションの広告を出してください--セッションスケジュールの情報を検索するのに質問メカニズムを提供してください。
Quinn, et al. Informational [Page 17] RFC 3170 IP Multicast Applications September 2001
クイン、他 [17ページ]情報のRFC3170IPマルチキャストアプリケーション2001年9月
5.3 Heterogeneous Receiver Support
5.3 異種の受信機サポート
The Internet is a network of networks. IP's strength is its ability to enable seamless interoperability between hosts on disparate network media, the heterogeneous network.
インターネットはネットワークのネットワークです。 IPの強さは異種のネットワークメディアの異機種ネットワークのホストの間のシームレスの相互運用性を可能にするその性能です。
When two hosts communicate via unicast--one-to-one--across an IP network, it is relatively easy for senders to adapt to varying network conditions. The Transmission Control Protocol (TCP) provides reliable data transport, and is the model of "network friendly" adaptability.
IPネットワークの向こう側のユニキャスト(1〜1)で2人のホストが交信するとき、送付者が異なったネットワーク状態に順応するのは、比較的簡単です。 通信制御プロトコル(TCP)は、確実な資料輸送を提供して、「ネットワーク好意的な」適応性のモデルです。
TCP receivers send acknowledgements back to the sender for data delivered. A TCP sender detects data loss from the data sent that is not acknowledged. When it detects data loss, TCP infers that there is network congestion or a low-bandwidth link, and adapts by throttling down its send rate [SlowStart].
TCP受信機はデータのための送付者への後部が提供した承認を送ります。 TCP送付者はデータからの損失が送った承認されないデータを検出します。 データの損失を検出するとき、TCPがネットワークの混雑か低バンド幅リンクがあると推論して、減速することによって適合する、それ、レート[SlowStart]を送ってください。
User Datagram Protocol (UDP) does not enable a receiver feedback loop the way TCP does, since UDP does not provide reliable data delivery service. As a result, it also does not have a loss detection and adaptive congestion control mechanism as TCP does. However, it is possible for a unicast UDP application to enable similar adaptive algorithms to achieve the same result, or even improve on it.
ユーザー・データグラム・プロトコル(UDP)はUDPが確実な資料デリバリ・サービスを提供しないのでTCPがする方法で受信機フィードバックループを可能にしません。 その結果、また、それには、TCPとしての制御機構がする損失検出と適応型の混雑がありません。 しかしながら、ユニキャストUDPアプリケーションが、同様の適応型のアルゴリズムが同じ結果を獲得するか、またはそれを改良するのさえ可能にするのは、可能です。
A unicast UDP application that uses a feedback mechanism to detect data loss and adapt the send rate, can do so better than TCP. TCP automatically reduces the "congestion window" when data loss is detected, although the updated send rate may be slower than a CBR audio/video stream requires. When a UDP application detects loss, it can adapt the data itself to accommodate the lower send rate. For example, a UDP application can:
データの損失を検出して、適合するのにフィードバック・メカニズムを使用するユニキャストUDPアプリケーション、レートを送ってください、そして、TCPより良くて、そうすることができてください。 データの損失が検出されるとき、TCPが「混雑ウィンドウ」を自動的に減少させて、アップデートが発信しますが、レートはCBRオーディオ/ビデオストリームが必要とするより遅いかもしれません。 UDPアプリケーションが損失を検出するとき、それはデータ自体を適合させることができます。下側を収容するのはレートを送ります。 例えば、UDPアプリケーションはそうすることができます:
- Reduce the data resolution (e.g., send lower fidelity
audio/video by reducing sample frequency or frame rate) to
reduce data rate.
- データ信号速度を減少させるデータ解決(例えば、サンプル頻度かフレームレートを低下させることによって、下側の信義オーディオ/ビデオを送る)を抑えてください。
- Modify the data encoding to add redundant data (e.g., forward
error correction) offset in time to avoid fate sharing. This
could also be "layered", so a percentage of data loss will
simply reduce fidelity rather than corrupt the data.
- zデータの符号化を変更して、冗長データ(例えば、前進型誤信号訂正)が時間内に運命共有を避けるために相殺されると言い足してください。 また、これを「層にすることができた」ので、データの損失の割合はデータを崩壊させるより信義を単にむしろ減少させるでしょう。
- Reduce the send rate of one datastream in order to favor another
of higher priority (e.g., sacrifice video in order to ensure
audio delivery).
- 減少、 より高い優先度の別のものを支持するために1datastreamのレートを送ってください(例えば、オーディオ配送を確実にするためにビデオを犠牲にしてください)。
Quinn, et al. Informational [Page 18] RFC 3170 IP Multicast Applications September 2001
クイン、他 [18ページ]情報のRFC3170IPマルチキャストアプリケーション2001年9月
- Send data at a lower rate (i.e., with a different encoding) on a
separate multicast address and/or port number for high-loss
receivers.
- 高損失受信機のために別々のマルチキャストアドレス、そして/または、ポートナンバーの低料金(すなわち、異なったコード化がある)でデータを送ってください。
However, with multicast applications--one-to-many or many-to-many-- which have multiple receivers, the feedback loop design needs modification. If all receivers return data loss reports simultaneously, the sender is easily overwhelmed in the storm of replies. This is known as the "implosion problem".
しかしながら、複数の受信機を持っているマルチキャストアプリケーション(多くへの1か多くへの多く)で、フィードバックループデザインは変更を必要とします。 すべての受信機が同時にデータ損害報告を返すなら、送付者は回答の嵐で容易に圧倒されます。 これは「内部破裂問題」として知られています。
Another problem is that heterogeneous receiver capabilities can vary widely due to the wide range of (static) network media bandwidth capabilities and dynamically due to transient traffic conditions. If a sender adapts its send rate and data resolution based on the loss rate of its worst receiver(s), then it can only service the lowest common denominator. Hence, a single "crying baby" can spoil it for all other receivers.
別の問題は異種の受信機能力は広範囲の(静的)のネットワークメディア帯域幅能力のためばらつきが大きいことができ、ダイナミックに一時的な交通状況がばらつきが大きいということです。 送付者が適合する、それ、最も悪い受信機の損失率に基づくレートとデータ解決を送ってください、そして、次に、それは最小公分母を修理できるだけです。 したがって、単一の「号泣児」は他のすべての受信機のためにそれを損なうことができます。
Strategies exist for dealing with these heterogeneous receiver problems. Here are two examples:
戦略は、これらの異種の受信機問題に対処するために存在しています。ここに、2つの例があります:
Shared Learning - When loss is detected (i.e., a sequenced packet
isn't received), a receiver starts a random timer. If it
receives a data loss report sent by another receiver as it waits
for the timer to expire, it stops the timer and does not send a
report. Otherwise, it sends a report when the timer expires.
The Real-Time Protocol and its feedback-loop counterpart Real-
Time Control Protocol [RTP/RTCP] employ a strategy similar to
this to keep feedback traffic to 5 percent or less than the
overall session traffic. This technique was originally utilized
in IGMP.
共有されたLearning--損失が検出されるとき(すなわち、配列されたパケットは受け取られていません)、受信機は無作為のタイマを始動します。 それが、タイマが期限が切れるのを待っているので別の受信機によって送られたデータ損害報告を受け取るなら、それは、タイマを止めて、レポートを送りません。 さもなければ、タイマが期限が切れると、それはレポートを送ります。 総合的なセッショントラフィック5パーセントへの時間Controlプロトコル[RTP/RTCP]が保つのにこれと同様の戦略を使うレアル-時間プロトコルとそのフィードバックループ対応者レアルフィードバックトラフィックか以下。 このテクニックは元々、IGMPで利用されました。
Local Recovery - Some receivers may be designated as local
distribution points or "transcoders" that either re-send data
locally (possibly via unicast) when loss is reported or they re-
encode the data for lower bandwidth receivers before re-sending.
No standards exist for these strategies, although "local
recovery" is used by several reliable multicast protocols.
地方のRecovery--損失であるときに局所的(ことによるとユニキャストで)にデータを再送する局所分布ポイントか「トランスコーダ」が報告されるか、または再送の前に下側の帯域幅受信機のためのデータを再コード化するとき、いくつかの受信機が指定されるかもしれません。 「地方の回復」はいくつかの信頼できるマルチキャストプロトコルによって使用されますが、規格は全くこれらの戦略のために存在していません。
Adaptive multicast application design for heterogeneous receivers is still an active area of research. The fundamental requirements are to maximize application usability, while accommodating network conditions in a "network friendly" manner. In other words, congestion detection and avoidance are (at least) as important in protocol design as the user experience. The adaptive mechanisms must also be stable, so they do not adapt too quickly--changing encoding and rates based on too little information about what may be a transient condition--to avoid oscillation.
異種の受信機のための適応型のマルチキャストアプリケーション設計は研究の活動領域です。 基本的な要件は「ネットワーク好意的な」方法によるネットワーク状態を収容している間、アプリケーションユーザビリティを最大にすることです。 言い換えれば、混雑検出と回避はプロトコルデザインでユーザー・エクスペリエンスと(少なくとも)同じくらい重要です。 したがって、また、素早く順応しません--また、適応型のメカニズムも安定しているに違いない、変化は、一時的な状態であるかもしれないことのあまりに少ない情報コード化して、評価します--振動を避けるために。
Quinn, et al. Informational [Page 19] RFC 3170 IP Multicast Applications September 2001
クイン、他 [19ページ]情報のRFC3170IPマルチキャストアプリケーション2001年9月
This "feedback loop" service necessary for support of heterogeneous receivers is not illustrated in the services summary in Figure 4, although it could be added alongside "Reliable Transport" and the others. This service could be implemented within an application or accessed externally, as provided by the operating system or a third party. See [HNRS] for a taxonomy of strategies for providing feedback for multicast, with the ultimate goal of developing a common multicast feedback protocol.
異種の受信機のサポートに必要なこの「フィードバックループ」サービスは図4のサービス概要で例証されません、「信頼できる輸送」と他のものと並んでそれを加えることができましたが。 このサービスにアプリケーションの中で実装したか、または外部的にアクセスできました、オペレーティングシステムか第三者によって提供されるように。 フィードバックをマルチキャストに提供するための戦略の分類学に関して[HNRS]を見てください、一般的なマルチキャストフィードバックプロトコルを開発するという究極の目標のために。
5.4 Reliable Data Delivery
5.4 確実な資料配送
Many of the multicast application examples in our list--like audio/video distribution--have loss-tolerant data content. In other words, the data content itself can remain useful even if some of it is lost. For example, audio might have a short gap or lower fidelity but will remain intelligible despite some data loss.
オーディオ/ビデオ分配のような私たちのリストのマルチキャストアプリケーションの例の多くには、損失許容性があるデータ内容があります。 言い換えれば、それのいくつかが無くなっても、データ内容自体は役に立ったままで残ることができます。 例えば、オーディオは、短いギャップか下側の信義を持っているかもしれませんが、いくらかのデータの損失にもかかわらず、明瞭なままでしょう。
Other application examples--like caching and synchronized resources- -require reliable data delivery. They deliver content that must be complete, unchanged, in sequence, and without duplicates. The "Loss Intolerant" column in Figure 7 shows a list of applications with this requirement, while the others can tolerate varying levels of data loss. The tolerance levels are typically determined by the nature of the data and the encoding in use.
他のアプリケーションの例--キャッシュして、連動するように、リソースは確実な資料配送を必要とします。 彼らは連続して、そして、および写しなしで完全で、変わりがないに違いない内容を提供します。 図7の「損失偏狭な」コラムはこの要件でアプリケーションのリストを示しています、他のものが異なったレベルのデータの損失を黙認できますが。 許容レベルはデータの本質と使用におけるコード化で通常決定しています。
|
1toM | b a, d c, e
|
MtoM | f, j, k, l, m, n g, h, i
|
Mto1 | o, p, r, s, t q
|
+------------------------------------------------
Loss Tolerant Loss Intolerant
| 1toM| b a、d c、e| MtoM| f、j、k、l、m、n g、h、i| Mto1| o, p、r、s、t q| +------------------------------------------------ 損失の許容性がある損失偏狭です。
Figure 7: Reliability Requirements of Application types
図7: Applicationの信頼性のRequirementsはタイプします。
Some of the challenges involved with enabling reliable multicast transport are the same as those of sending to heterogeneous receivers, and some solutions are similar also. For example, many reliable multicast transport protocols avoid the implosion problem by using negative acknowledgements (NAKs) from receivers to indicate what was lost. They also use "shared learning" whereby receivers listen to others' NAKs and then listen for the resulting retransmission of data, rather than requesting retransmission by sending a NAK themselves.
信頼できるマルチキャスト輸送を可能にするのにかかわる挑戦のいくつかが異種の受信機に発信するものと同じです、そして、また、何らかの解決法も同様です。 例えば、多くの信頼できるマルチキャストトランスポート・プロトコルが、失われたことを示すのに、受信機から否定的承認(NAKs)を使用することによって、内部破裂問題を避けます。 また、彼らは受信機が他のもののNAKsを聞いて、次にNAKを送ることによって「再-トランスミッション」を要求するよりむしろデータ自体の結果として起こる「再-トランスミッション」を聞こうとする「共有された学習」を使用します。
Quinn, et al. Informational [Page 20] RFC 3170 IP Multicast Applications September 2001
クイン、他 [20ページ]情報のRFC3170IPマルチキャストアプリケーション2001年9月
Although reliable delivery cannot change the data sent--except, perhaps, to use a loss-less data compression algorithm--they can use other adaptive techniques like sending redundant data, or adjusting the send rate.
信頼できる配信は変化できませんでしたが、データは発信しました--恐らく除いて、損失なしのデータ圧縮アルゴリズムを使用してください--それらが冗長データを送るか、または適応するような他の適応型のテクニックを使用できる、レートを送ってください。
Although many reliable multicast protocol implementations exist [Obraczka], and a few are already available in commercial products, none of them are standardized. Work is ongoing in the "Reliable Multicast" research group of the Internet Research Task Force [IRTF] to provide a better definition of the problem, the multicast transport requirements, and protocol mechanisms.
多くの信頼できるマルチキャストプロトコル実装が存在しています、そして、[Obraczka]いくつかは商品の中で既に利用可能ですが、それらのいずれも標準化されません。 仕事は「信頼できるマルチキャスト」という問題の、より良い定義を提供するインターネットResearch Task Force[IRTF]、マルチキャスト輸送要件、およびプロトコルメカニズムの研究グループは進行中です。
Scalability is the paramount concern, and it implies the general need for "network friendly" protocols that detect and avoid congestion as they provide reliable delivery. Other considerations are protocol robustness, support for "late joins", group management and security (which we discuss next).
スケーラビリティは最高の関心です、そして、それは信頼できる配信を提供するとき、混雑を検出して、避ける「ネットワーク好意的な」プロトコルの一般的な必要性を含意します。 他の問題がプロトコル丈夫さ、サポートである、「遅く、接合する」、管理とセキュリティ(私たちが次に議論する)を分類してください。
The current consensus is that due to the wide variety of multicast application requirements--some of which are at odds--no single multicast transport will likely be appropriate for all applications. As a result, most believe that we will eventually standardize a number of reliable multicast protocols, rather than a single one [BULK, RMT].
広いバラエティーに関するマルチキャストアプリケーション要件のために現在のコンセンサスはそれ(それの或るものは不和である)です--どんなただ一つのマルチキャスト輸送もおそらくすべてのアプリケーションに適切にならないでしょう。 その結果、大部分は、私たちが結局ただ一つのもの[BULK、RMT]よりむしろ多くの信頼できるマルチキャストプロトコルを標準化するつもりであると信じています。
5.5 Security
5.5 セキュリティ
For any IP network application--unicast or multicast--security is necessary because networks comprise users with different levels of trust.
どんなIPネットワーク応用(ユニキャストかマルチキャスト)にも、ネットワークが異なったレベルの信頼でユーザを包括するので、セキュリティが必要です。
Network application security is challenging, even for unicast. And as the need for security increases--gauged by the risks of being without it--the challenges increase also. Security system complexity and overhead is commensurate with the protection it provides. "No one can guarantee 100% security. But we can work toward 100% risk acceptance...Strong cryptography can withstand targeted attacks up to a point--the point at which it becomes easier to get the information some other way...A good design starts with a threat model: what the system is designed to protect, from whom, and for how long." [Schneier]
ユニキャストにおいてさえ、ネットワーク応用セキュリティはやりがいがあります。 そして、セキュリティの必要性が大きくなるのに従って、それなしであるリスクによって測られて、また、挑戦は増加します。 セキュリティシステムの複雑さとオーバーヘッドはそれが提供する保護について等しいです。 「だれも100%のセキュリティを保証できません。」 しかし、私たちは100%のリスク承認に向かって取り組むことができます…強い暗号は狙っている攻撃にある程度耐えることができます--ある他の道に情報を得るのが、より簡単になるポイント良いデザインは脅威モデルから始まります: 「システムがだれと、どれくらい長い間保護するように設計されている何。」 [シュナイアー]
Multicast applications are no different than unicast applications with respect to their need for security, and they require the same basic security services: user authentication, data integrity, data privacy and user privacy (anonymity). However, enabling security for
マルチキャストアプリケーションは彼らのセキュリティの必要性に関してユニキャストアプリケーションと異なっていません、そして、彼らは同じ基本的なセキュリティー・サービスを必要とします: ユーザー認証、データ保全、データプライバシー、およびユーザプライバシー(匿名)。 しかしながら、セキュリティを可能にします。
Quinn, et al. Informational [Page 21] RFC 3170 IP Multicast Applications September 2001
クイン、他 [21ページ]情報のRFC3170IPマルチキャストアプリケーション2001年9月
multicast applications is even more of a challenge than for unicast. Having multiple receivers makes a difference, as does their heterogeneity and the dynamic nature of multicast group memberships.
マルチキャストアプリケーションはユニキャストより挑戦さえのものです。 複数の受信機を持っているのにそれらの異種性とマルチキャストグループ会員資格のダイナミックな本質のように効果があります。
Multicast security requirements can include any combination of the following services:
マルチキャストセキュリティ要件は以下のサービスのどんな組み合わせも含むことができます:
Limiting Senders - Controlling who can send to group addresses
だれがアドレスを分類するために発信できるかを制御して、Sendersを制限します。
Limiting Receivers - Controlling who can receive
だれが受信できるかを制御して、Receiversを制限します。
Limiting Access - Controlling who can "read" multicast content
either by encrypting content or limiting receivers (which isn't
possible yet)
だれが内容を暗号化するか、または受信機を制限することによってマルチキャスト内容を「読むことができるか」を制御して、Accessを制限します。(まだ可能ではありません)
Verifying Content - Ensuring that data originated from an
authenticated sender and was not altered en route
データが認証された送付者から発して、途中で変更されなかったのを確実にして、Contentについて確かめます。
Protecting Receiver Privacy - Controlling whether sender(s) or
other receivers know receiver identity
Receiver Privacyを保護します--制御して、送付者か他の受信機であることにかかわらず受信機のアイデンティティを知ってください。
Firewall Traversal - Proxying outgoing "join" requests through
firewalls, allowing incoming or outgoing traffic through, and
(possibly) authenticating receivers for filtering purposes and
security [Finlayson].
ファイアウォールTraversal--入って来るか外向的なトラフィックの通ることを許して、目的とセキュリティをフィルターにかけるために(ことによると)受信機を認証するファイアウォール[フィンリースン]を通した「接合してください」というProxyingの送信する要求。
This list is not comprehensive, but includes the most commonly needed security services. Different multicast applications and different application contexts can have very different needs with respect to these services, and others. Two main issues emerge, where the performance of current solutions leaves much to be desired [MSec].
このリストは、包括的ではありませんが、最も一般的に必要なセキュリティー・サービスを含んでいます。 異なったマルチキャストアプリケーションと異なったアプリケーション文脈はこれらのサービス、および他のものに関して非常に異なった必要性を持つことができます。 2つの本題(現在のソリューションの性能は遺憾な点が多いです[MSec])が現れます。
Individual authentication - how is sender identity verified for
each multicast datagram received?
個々の認証--どのようにそれぞれのマルチキャストデータグラムのために確かめられた送付者のアイデンティティを受け取りますか?
Membership revocation - how is further group access disabled for
group members that leave the group (e.g., encryption keys in their
possession disabled)?
会員資格取消し--さらなるグループアクセスは仲間から抜けるグループのメンバー(例えば、彼らの所有物身体障害者の暗号化キー)のためにどのように無効にされますか?
Performance is largely a factor when a user joins or leaves a group. For example, methods used to authenticate potential group members during joins or re-keying current members after a member leaves can involve significant processing and protocol overhead and result in significant delays that affect usability.
ユーザがグループを加わるか、または出るとき、パフォーマンスは主に要素です。 例えば、メンバーがいなくなった後に接合するか、または現在のメンバーを再合わせている間、潜在的グループのメンバーを認証するのに使用されるメソッドは重要な処理、プロトコルオーバーヘッド、および結果をユーザビリティに影響する重要な遅れに伴うことができます。
Quinn, et al. Informational [Page 22] RFC 3170 IP Multicast Applications September 2001
クイン、他 [22ページ]情報のRFC3170IPマルチキャストアプリケーション2001年9月
Like reliable multicast, secure multicast is also under investigation in the Internet Research Task Force [IRTF]. Protocol mechanisms for many of the most important of these services--such as limiting senders--have not yet been defined, let alone developed and deployed.
また、信頼できるマルチキャストのように、安全なマルチキャストもインターネットResearch Task Force[IRTF]で調査中です。 送付者を制限などなどのこれらのサービスで最も重要の多くのプロトコルメカニズムはまだ定義されていません、開発されて、配布されて。
As is true for reliable multicast, the current consensus is that no single security protocol will satisfy the wide diversity of sometimes-contradictory requirements among multicast applications. Hence, multicast security will also likely require a number of different protocols.
そのままで、信頼できるマルチキャストに本当であることで、現在のコンセンサスはどんなただ一つのセキュリティプロトコルもマルチキャストアプリケーションの中で時々相容れない要件の広い多様性を満たさないということです。 したがって、また、マルチキャストセキュリティはおそらく多くの異なったプロトコルを必要とするでしょう。
5.6 Synchronized Play-Out
5.6 外では、プレーします連動している。
This refers to having all receivers simultaneously play-out the multicast data they received. This may be necessary for fairness-- playing-out prices for auctions, or stock-prices--or to ensure synchronization with other receivers, such as when playing music.
これはすべての受信機に同時に彼らが受け取ったマルチキャストデータを展開させるのを参照します。 オークション、または株価、音楽を演奏しながらいつなどの他の受信機との同期を確実にするかために価格を終えて、これが公正に必要であるかもしれません。
Here is an analogy to illustrate: Imagine a multi-speaker stereo system that is wired throughout a home (via analog). With the stereo playing on all speaker sets, you will hear continuous music as you walk from room-to-room.
ここに、例証する類推があります: ホーム(アナログを通した)中で配線されるマルチスピーカーステレオ方式を想像してください。 ステレオがすべてのスピーカーセットで演奏されている状態で、余地から余地で歩くのに従って、あなたは連続した音楽を聞くでしょう。
Now imagine a house full of multi-media and network enabled computer systems. Although they will all receive the same music datastream simultaneously via multicast, they will provide discontinuous music playback as you walk room-to-room.
今度は、マルチメディアとネットワークでいっぱいの家がコンピュータ・システムを可能にしたと想像してください。彼らは皆、同時にマルチキャストで同じ音楽datastreamを受けるでしょうが、あなたが余地から余地を歩くとき、それらは不連続な音楽再生を前提とするでしょう。
To provide synchronized playback that would enable continuous music from room-to-room would require three things:
余地から余地で連続した音楽を可能にする連動している再生を提供するのは3つのものを必要とするでしょう:
1) system clocks on all systems should be synchronized
2) datastreams must be framed with timestamps
3) you must know the playback latency of the multimedia hardware
1) すべてのシステムの上のシステムクロックによる連動している2)datastreamsによるタイムスタンプ3)で縁どられて、あなたがマルチメディアハードウェアの再生潜在を知らなければならないということでなければならないということであるはずです。
The third of these is the most difficult to achieve at this time. Hardware and drivers don't provide any mechanism for retrieving this information, although different audio and video devices have a wide- range of performance.
これらの3番目はこのとき達成するのが最も難しいです。 ハードウェアとドライバーはこの情報を検索するのにどんなメカニズムも提供しません、異なったオーディオとビデオデバイスには、広範囲の性能がありますが。
6. Service APIs
6. サービスAPI
In some cases, the protocol services mentioned in this document can be enabled transparently by passive configuration mechanisms and "middleware". For example, it is conceivable that a UDP implementation could implicitly enable a reliable multicast protocol without the explicit interaction of the application.
いくつかの場合、透過的に受け身の構成メカニズムと「ミドルウェア」は本書では言及されたプロトコルサービスを可能にすることができます。 例えば、UDP実装がアプリケーションの明白な相互作用なしで信頼できるマルチキャストプロトコルをそれとなく可能にするかもしれないのが想像できます。
Quinn, et al. Informational [Page 23] RFC 3170 IP Multicast Applications September 2001
クイン、他 [23ページ]情報のRFC3170IPマルチキャストアプリケーション2001年9月
Sometimes, however, applications need explicit access to these services for flexibility and control. For example, an adaptive application sending to a heterogeneous group of receivers using RTP may need to process RTCP reports from receivers in order to adapt accordingly (by throttling send rate or changing data encoders, for example) [RTP API]. Hence, there is often a need for service APIs that allow an application to qualify and initiate service requests, and receive event notifications. In Figure 5, the top edge of the box for each service effectively represents its API.
しかしながら、時々、アプリケーションは柔軟性とコントロールのためのこれらのサービスへの明白なアクセスを必要とします。 例えば、RTPを使用することで受信機の種々雑多なグループに発信する適応型のアプリケーションは、それに従って、適合するように受信機からRTCPレポートを処理する必要があるかもしれません(阻止することによって、例えば、レートか変化データエンコーダを送ってください)[RTP API]。 したがって、しばしばアプリケーションがサービスのリクエストに資格を与えて、開始して、イベント通知を受け取るサービスAPIの必要があります。 図5では、事実上、各サービスのための箱の先頭の縁はAPIを表します。
Network APIs generally reflect the protocols they support. Their functionality and argument values are a (varying) subset of protocol message types, header fields and values. Although some protocol details and actions may not be exposed in APIs--since many protocol mechanics need not be exposed--others are crucial to efficient and flexible application operation.
一般に、ネットワークAPIはそれらがサポートするプロトコルを反映します。 それらの機能性とパラメータ値はプロトコルメッセージタイプ、ヘッダーフィールド、および値の(異なること)の部分集合です。 多くのプロトコル整備士がさらされる必要はないのでいくつかのプロトコルの詳細と動作がAPIで暴露されないかもしれませんが、--他のものは効率的でフレキシブルなアプリケーション操作に重要です。
A more complete examination of the application services described in this document might also identify the protocol features that could be mapped to define a (generic) API definition for that service. APIs are often controversial, however. Not only are there many language differences, but it is also possible to create different APIs by exposing different levels of detail in trade-offs between flexibility and simplicity.
また、本書では説明されたアプリケーション・サービスの、より完全な試験はそのサービスのための(ジェネリック)API定義を定義するために写像できたプロトコル機能を特定するかもしれません。 しかしながら、APIはしばしば論議を呼んでいます。また、多くの言語差があるだけではなく、柔軟性と簡単さの間でトレードオフにおける、異なったレベルの詳細を暴露することによって異なったAPIを作成するのも可能です。
7. Security Considerations
7. セキュリティ問題
See section 5.4
セクション5.4を見てください。
8. Acknowledgements
8. 承認
The authors would like to acknowledge and thank the following individuals for their helpful feedback: Ran Canetti, Brian Haberman, Eric A. Hall, Kenneth C. Miller, and Dave Thaler.
作者は、彼らの役立っているフィードバックについて以下の個人に承認して、感謝したがっています: カネッティ、ブライアン・ハーバーマン、エリックA.ホール、ケネス・C.ミラー、およびデーヴThalerを車で送りました。
9. References
9. 参照
[AnyCast] Partridge, C., Mendez, T. and W. Milliken, "Host
Anycasting Service", RFC 1546, November 1993.
[AnyCast] ヤマウズラとC.とメンデスとT.とW.ミリケン、「ホストAnycastingサービス」、RFC1546、1993年11月。
[BeauW] B. Williamson, "Developing IP Multicast Networks, Volume
I", (c) 2000 Cisco Press, Indianapolis IN, ISBN 1-57870-
077-9.
(c) [BeauW]B.ウィリアムソン、「IPマルチキャストネットワーク、ボリュームIを発生し」て、中にインディアナポリスがある状態で、2000年のコクチマスはISBN1-57870- 077-9を押します。
[BULK] Whetten, B., Vicisano, L., Kermode, R., Handley, M.,
Floyd, S. and M. Luby, "Reliable Multicast Transport
Building Blocks for One-to-Many Bulk-Data Transfer", RFC
3048, January 2001.
[大量] WhettenとB.とVicisanoとL.とカーモードとR.とハンドレーとM.とフロイドとS.とM.Luby、「多くへの1のための信頼できるマルチキャスト輸送ブロックバルク・データ転送」、RFC3048、2001年1月。
Quinn, et al. Informational [Page 24] RFC 3170 IP Multicast Applications September 2001
クイン、他 [24ページ]情報のRFC3170IPマルチキャストアプリケーション2001年9月
[Deering] Deering, S., "Host Extensions for IP Multicasting", STD
5, RFC 1112, August 1989.
[デアリング] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
[DIS] Pullen, J., Mytak, M. and C. Bouwens, "Limitations of
Internet Protocol Suite for Distributed Simulation in the
Large Multicast Environment", RFC 2502, February 1999.
[けなします] ピューレン、J.、Mytak、M.、およびC.Bouwens、「インターネットの制限は大きいマルチキャスト環境における分配されたシミュレーションのためにスイートについて議定書の中で述べます」、RFC2502、1999年2月。
[E2EQOS] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L.,
Speer, M., Braden, R. and B. Davie, "Integrated Services
Operation over Diffserv Networks", RFC 2998, November
2000.
[E2EQOS] Bernet(Y.、Yavatkar、R.、フォード、P.、ベイカー、F.、チャン、L.、シュペーア、M.、ブレーデン、R.、およびB.デイビー)は「Diffservネットワークの上でサービス操作を統合しました」、RFC2998、2000年11月。
[Estrin] D. Estrin, "Multicast: Enabler and Challenge", Caltech
Earthlink Seminar Series, April 22, 1998.
[Estrin]D.Estrin、「マルチキャスト:」 「イネーブラと挑戦」、1998年4月22日のカリフォルニア工科大学Earthlinkセミナーシリーズ。
[Finlayson] Finlayson, R., "IP Multicast and Firewalls", RFC 2588,
May 1999.
[フィンリースン] フィンリースンと、R.と、「IPマルチキャストとファイアウォール」(RFC2588)は1999がそうするかもしれません。
[HNRS] Hofman, Nonnenmacher, Rosenberg, Schulzrinne, "A Taxonomy
of Feedback for Multicast", June 1999, Work in Progress.
[HNRS] ホフマン、Nonnenmacher、ローゼンバーグ、Schulzrinne(「マルチキャストのためのフィードバックの分類学」、1999年6月)は進行中で働いています。
[IGMPv2] Fenner, B., "Internet Group Management Protocol, Version
2", RFC 2236, November 1997.
[IGMPv2] フェナー、B.、「インターネットグループ管理プロトコル、バージョン2インチ、RFC2236、11月1997。」
[IGMPv3] Cain, B., Deering, S., Kouvelas, I. and A. Thyagarajan,
"Internet Group Management Protocol, Version 3", Work in
Progress.
[IGMPv3] カイン、B.、デアリング、S.、Kouvelas、I.、およびA.Thyagarajan、「インターネットグループ管理プロトコル、バージョン3インチは進行中で働いています」。
[IMJ] K. Almeroth and M. Ammar, "The Interactive Multimedia
Jukebox (IMJ): A New Paradigm for the On-Demand Delivery
of Audio/Video", Proceedings of the Seventh International
World Wide Web Conference, Brisbane, AUSTRALIA, April
1998.
[IMJ] K.AlmerothとM.Ammar、「インタラクティブ・マルチメディアジュークボックス(IMJ):」 「オーディオ/ビデオの要求次第の配送のための新しい発想」、第7国際WWWコンファレンス(ブリスベーン(オーストラリア)1998年4月)の議事。
[IRTF] Weinrib, A. and J. Postel, "The IRTF Guidelines and
Procedures", BCP 8, RFC 2014, January 1996.
[IRTF] Weinrib、A.、J.ポステル、および「IRTFガイドラインと手順」、BCP8、RFC2014、1月1996日
[Kermode] Kermode, R., "MADCAP Multicast Scope Nesting State
Option", RFC 2907, September 2000.
[カーモード]カーモード、R.、「向こう見ずなマルチキャスト範囲巣篭もり州のオプション」、RFC2907、2000年9月。
[LSMA] Bagnall, P., Briscoe, R. and A. Poppitt, "Taxonomy of
Communication Requirements for Large-scale Multicast
Applications", RFC 2729, December 1999.
[LSMA] BagnallとP.とブリスコウとR.とA.Poppitt、「大規模なマルチキャストアプリケーションのためのコミュニケーション要件の分類学」、RFC2729、1999年12月。
[MADDR] Albanna, Z., Almeroth, K., Meyer, D. and M. Schipper,
"IANA Guidelines for IPv4 Multicast Address Assignments",
BCP 51, RFC 3171, August 2001.
[MADDR] Albanna、Z.、Almeroth、K.、マイヤー、D.、およびM.シペール、「IPv4マルチキャストのためのIANAガイドラインは課題を扱います」、BCP51、RFC3171、2001年8月。
Quinn, et al. Informational [Page 25] RFC 3170 IP Multicast Applications September 2001
クイン、他 [25ページ]情報のRFC3170IPマルチキャストアプリケーション2001年9月
[MASC] Estrin, D., Govindan, R., Handley, M., Kumar, S.,
Radoslavov, P. and D. Thaler, "The Multicast Address-Set
Claim (MASC) Protocol", RFC 2909, September 2000.
[MASC] EstrinとD.とGovindanとR.とハンドレーとM.とクマーとS.とラドスラーボフとP.とD.ターレル、「マルチキャストアドレスセットクレーム(MASC)プロトコル」、RFC2909、2000年9月。
[Maufer] T. Maufer, "Deploying IP Multicast in the Enterprise",
(c) 1998 Prentice Hall, Upper Saddle River NJ ISBN 0-13-
897687-2.
[Maufer]T.Maufer、(c) 1998年の新米のホールの、そして、上側の「エンタープライズでIPマルチキャストを配布します」サドルニュージャージーのISBN0-13- 897687-2川。
[Miller] C. K. Miller, "Multicast Networking and Applications",
(c) 1999 Addison Wesley Longman, Reading MA ISBN 0-201-
30979-3.
(c)1999アディソン・ウエスリー・ロングマンであって、閲読している[ミラー]C.K.ミラーと、「マルチキャストネットワークとアプリケーション」MA ISBN0-201- 30979-3。
[MADCAP] Hanna, S., Patel, B. and M. Shah, "Multicast Address
Dynamic Client Allocation Protocol (MADCAP)", RFC 2730,
December 1999.
[向こう見ずな] ハンナとS.とパテルとB.とM.シャー、「マルチキャストのアドレスのダイナミックなクライアント配分プロトコル(向こう見ず)」、RFC2730、1999年12月。
[MRM] K. Sarac, K. Almeroth, "Supporting Multicast Deployment
Efforts: A Survey of Tools for Multicast Monitoring",
Journal of High Speed Networking--Special Issue on
Management of Multimedia Networking, March 2001
[MRM]K.Sarac、K.Almeroth、「マルチキャスト展開が取り組みであるとサポートします:」 「マルチキャストモニターのためのツールの調査」、高速ネットワーキングのジャーナル--マルチメディアネットワークの管理、2001年3月の増刊
[MSec] Multicast Security (msec) IETF Working Group charter
[MSec]マルチキャストSecurity(msec)IETF作業部会特許
[MZAP] Handley, M., Thaler, D. and R. Kermode, "Multicast-Scope
Zone Announcement Protocol (MZAP)", RFC 2776, February
2000.
[MZAP]ハンドレーとM.とターレルとD.とR.カーモード、「マルチキャスト範囲ゾーン発表プロトコル(MZAP)」、RFC2776 2000年2月。
[Obraczka] K. Obraczka "Multicast Transport Mechanisms: A Survey and
Taxonomy", IEEE Communications Magazine, Vol. 36 No. 1,
January 1998.
[Obraczka]K.Obraczka、「マルチキャスト移送機構:」 IEEEコミュニケーション雑誌、1998年のVol.36 1月第No.1「A調査と分類学」
[Rizzo] L. Rizzo, "Fast Group management in IGMP", HIPPARC 98
workshop, June 1998, UCL London
http://www.iet.unipi.it/~luigi/hipparc98.ps.gz
[リゾー]L.リゾー、「IGMPでの速いGroup管理」、HIPPARC98ワークショップ、1998年6月、UCLロンドン http://www.iet.unipi.it/~luigi/hipparc98.ps.gz
[RM] Mankin, A., Romanow, A., Bradner, S. and V. Paxson,
"IETF Criteria for Evaluating Reliable Multicast
Transport and Application Protocols", RFC 2357, June
1998.
[RM] マンキン、A.、Romanow、A.、ブラドナー、S.、および「信頼できるマルチキャスト輸送とアプリケーション・プロトコルを評価するIETF評価基準」、RFC2357(1998年6月)対パクソン
[RSVP] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[RSVP] Wroclawski、J.、「IETFの統合サービスとのRSVPの使用」、RFC2210、1997年9月。
[RTP API] H. Schulzrinne, et al, "RTP Library API Specification,"
http://www.cs.columbia.edu/IRT/software/rtplib/rtplib-
1.0a1/rtp_api.html
[RTP API] H.Schulzrinne、他、「RTP図書館API仕様」、 http://www.cs.columbia.edu/IRT/software/rtplib/rtplib- 1.0a1/rtp_api.html
Quinn, et al. Informational [Page 26] RFC 3170 IP Multicast Applications September 2001
クイン、他 [26ページ]情報のRFC3170IPマルチキャストアプリケーション2001年9月
[RTP/RTCP] Schulzrinne, H., Casner, S., Frederick, R. and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", RFC 1889, January 1996.
[RTP/RTCP] Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC1889、1996年1月。
[SAP] Handley, M., Perkins, C. and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000.
[徐々に破壊します] ハンドレーとM.とパーキンスとC.とE.ウィーラン、「セッション発表プロトコル」、RFC2974、2000年10月。
[SDP] Handley, M., and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[SDP] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。
[Schneier] B. Schneier, "Why Cryptography Is Harder Than It Looks",
December 1996, http://www.counterpane.com/whycrypto.html
[シュナイアー]B.シュナイアー、「暗号がそれより確実である理由は見る」1996年12月、 http://www.counterpane.com/whycrypto.html
[SlowStart] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast
Retransmit, and Fast Recovery Algorithms", RFC 2001,
January 1997.
[SlowStart] スティーブンスと、W.と、「遅れた出発、輻輳回避が速く再送するTCP、および速い回復アルゴリズム」、RFC2001、1月1997日
[SLP] Veizades, J., Guttman, E., Perkins, C. and S. Kaplan,
"Service Location Protocol", RFC 2165, June 1997.
[SLP] VeizadesとJ.とGuttmanとE.とパーキンスとC.とS.キャプラン、「サービス位置のプロトコル」、RFC2165、1997年6月。
[SSM] Holbrook, H. and B. Cain, "Specific Multicast for IP",
Work in Progress.
[SSM] 「IPのための特定のマルチキャスト」というホルブルック、H.、およびB.カインは進行中で働いています。
10. Authors' Addresses
10. 作者のアドレス
Bob Quinn Celox Networks 2 Park Central Drive Southborough, MA 01772
ボブクインCeloxネットワーク2はSouthborough、中央のDrive MA 01772を駐車します。
Phone: +1 508 305 7000 EMail: bquinn@celoxnetworks.com
以下に電話をしてください。 +1 7000年の508 305メール: bquinn@celoxnetworks.com
Kevin Almeroth Department of Computer Science University of California Santa Barbara, CA 93106-5110
ケビン・Almerothコンピュータサイエンス学部のカリフォルニア大学のサンタバーバラ、カリフォルニア93106-5110
Phone: +1 805 893 2777 EMail: almeroth@cs.ucsb.edu
以下に電話をしてください。 +1 2777年の805 893メール: almeroth@cs.ucsb.edu
Quinn, et al. Informational [Page 27] RFC 3170 IP Multicast Applications September 2001
クイン、他 [27ページ]情報のRFC3170IPマルチキャストアプリケーション2001年9月
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Quinn, et al. Informational [Page 28]
クイン、他 情報[28ページ]
一覧
スポンサーリンク
