Network Working Group B. Quinn
Request for Comments: 3170 Celox Networks
Category: Informational K. Almeroth
UC-Santa Barbara
September 2001
IP Multicast Applications:
Challenges and Solutions
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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.
この目的を達成するために、文書は、マルチキャストアプリケーションのI / Oモデルとそれらがサポートできるサービスの例の分類法を提示しています。その後、これらのマルチキャストアプリケーション、およびこれらのサービスをサポートするために、プロトコル・ソリューションを構築するための最近の継続的な努力のサービス要件について説明します。
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
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
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マルチキャストは、今後数年間で、インターネット上で重要な役割を果たします。インターネットが拡大しようとしている場合は、必要条件ではなく、オプションです。マルチキャストは、アプリケーション開発者が大幅にネットワークに影響を与えることなく、より多くの機能を追加することができます。
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）の生存時間以上1（デフォルト値）に（TTL）値を増やす必要があります。マルチキャストデータグラムを受信するために、アプリケーションは透過[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.
この明らかなシンプルさは、しかし、欺瞞です。異種ネットワーク上でうまくスケールできるアプリケーションとプロトコルでマルチキャストサポートを有効にすると、重要な課題です。具体的には、一定のビットレートのデータストリーム、信頼性の高いデータ配信、セキュリティを送信し、そしてすべてが特別な配慮を必要とする多対多の通信を管理します。いくつかのソリューションが用意されていますが、これらのサービスの多くは、依然として活発な研究分野です。
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 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.
このドキュメントの目的は、マルチキャストアプリケーションの設計および実装の課題を理解するためのフレームワークを提供することです。正しくマルチキャスト通信を使用するためには、アプリケーション開発者は、最初に必要とされている（基本的なマルチキャスト通信に加えて）、各種I / Oモデルとネットワークサービスを理解する必要があります。第二に、アプリケーション開発者は、これらのサービスを提供するために、進行中の努力を認識する必要があります。このような努力が展開され、市販の製品から実現可能性を評価するための基本的な研究努力に成熟度の範囲です。
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.
希望は、開発者の意識を高めることによって、我々は解決策を見つけることの彼らの期待を調整することができますし、成功スケーラブル、および 『ネットワークにやさしい』の開発努力にそれらを導くことです。
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）の議論を包みます。
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ネットワークインフラストラクチャ内のエンドツーエンドのサービスを提供しています。
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種類があります。 RFC 1112で定義されるように最初は[デアリング]元のマルチキャスト・サービス・モデルに基づいています。このモデルでは、受信機は、単にグループに参加し、ソース（S）の身元を知る必要はありません。このモデルは、マルチキャストの二種類が元のサービスモデルを修正するなどのインターネット標準のマルチキャスト（ISM）、インターネット伝統的なマルチキャスト（ITM）、デアリングマルチキャスト、を含む名前の数で知られているようにグループアドレスを知ることに加えて、受信機は、関連するソースのセットを知っている必要があります。マルチキャストのこのタイプは、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.
この記事の執筆時点では、エンド・ツー・エンドの「グローバル」マルチキャストサービスはまだ利用できませんが、「マルチキャスト対応」インターネットの大きさが増加しています。最近の開発およびドメイン間マルチキャストルーティングプロトコルおよびマルチキャストフレンドリーインターネット交流の展開は主要なISP間のピアリングを有効にしています。これは、魅力的なコンテンツの増加可用性と一緒に、IPマルチキャスト対応ネットワークの展開と可用性に拍車をかけています。
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マルチキャスト対応し、多くの企業ネットワーク（イントラネット）もあるされているので、この視点は今日関連しています。
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ルータベースのプロトコル
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
- 好都合なジョインや葉 - 参加せずに送信します。
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.
例えば、マルチキャストベースとして配布されたA / 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.
高速脱退フェーズは[リゾー】迅速望ましくない流れを停止するために、両方の効果的な輻輳制御機構のために非常に望ましい、そして一般的にネットワークのために、より良好な不要なトラフィックをフィルタリングします。参加やレイテンシを残しますが、便宜の操作を可能にするために、マルチキャストインフラストラクチャに依存しているのいずれかを介してアプリケーションは、コントロールに影響を与えることができません。これは、基本的なマルチキャストサービスの要件です。
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.
マルチキャストアドレスに送信するアプリケーションは、最初の宛先グループに参加しなくても、すぐに送信を開始することができるはずです。これは、低遅延の配信要件を持つ組み込みデバイスとバースト性のソースアプリケーションのために重要です。
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ベースのマルチキャストホストモデルとすべての現在の実装では、送信者が標準機能として、それに参加することなく、グループに送信することができます。
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
一対多（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
多対一（Mto1）：ユニキャストまたはマルチキャストを介して送信側（ソース）に戻ってデータを送信し、受信機の任意の数
+-----------------------------------+
| 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 |
+-------+---+-----------+-----------------------------------+
Legend: S: "Send" (u): "unicast"
------ R: "Receive" (m): "multicast"
Table 1: Application types characterized by I/O relationships and destination address types (multicast or unicast)
表1：I / O関係によって特徴付けられるアプリケーションの種類と宛先アドレスタイプ（マルチキャストまたはユニキャスト）
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は、それらが表すI / O関係の観点から、これらのアプリケーションの種類を定義します。これらのカテゴリは、彼らが使用する通信メカニズムの組み合わせで定義されています。 IPレベルでは、すべてのマルチキャストは、I / Oは1toMまたはMTOMおよびユニキャスト（1to1）は、常に1対1です。 Mto1カテゴリは、例えば、ユニキャストを含むIPレベルの関係のいくつかの可能な組み合わせを指します。私たちは、マルチキャストを使用する多くのアプリケーションやサービスを区別するために役立つMto1カテゴリを作成しました。
1toM: MtoM: Mto1:
R1 S1/R1 S1
/ / | \ \
S-R2 S2/R2-+-S3/R3 S2-R
\... \ | / .../
Rn Sn/Rn Sn
Legend: S: "Sender"
------ R: "Receiver"
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 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.
図1は、3つのマルチキャストアプリケーションカテゴリの各々のための一般的なモデルを示します。再びそれはMto1送信者（S）と受信機との間のアプリケーションレベルの関係によって定義された人工的なカテゴリであることを強調する価値があります。 IP-レベルでは、マルチキャストは、送信者が受信者を制限することができないので、Mto1 I / Oメカニズムを提供し、またしても彼らが誰であるかを知りません。マルチキャストアプリケーションによって必要とされる受信者情報および制限は、アプリケーションレベルで有効になっています。
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つの一般的なカテゴリのそれぞれに顕著なマルチキャストアプリケーションとサービスタイプを定義することを試みます。我々は彼らの特定のサービス要件を記述するように、この文書の残りの部分でこれらのリスト内の項目を参照して利用できるまたは開発の下で、彼らが提示する課題、およびリファレンス・ソリューションを定義します。
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).
一対多（1toM）アプリケーションは、単一の送信者、および複数の同時受信機を持っています。表1のエントリ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）の分布：講義、プレゼンテーション、会議、またはマルチメディア報道観客（すなわち、テレビやラジオ「放送」という。）利益を得ることができるスケジュールされたイベントの他のタイプ。一つ以上の定ビットレート（CBR）データストリームと、比較的高い帯域幅の要求は、これらのアプリケーションを特徴付けます。オーディオ/ビデオの組み合わせと同様に - - 複数のデータストリームが存在するときに、2つが同期され、1つは、典型的には、（複数の）他のより高い優先度を有しています。例えば、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）のメディアを押してください。 「ドリップ・フィード」、比較的低帯域幅のデータは、これらのアプリケーションを特徴づけます。
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）ファイル配布およびキャッシュ：Webサイトのコンテンツ、実行可能なバイナリ、および分散エンドユーザーまたは複製/キャッシングサイトに送信された他のファイルベースの更新
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）のモニタリング：株価、センサー機器（地震活動、遠隔測定、気象や海洋の測定値）、セキュリティシステム、製造業やリアルタイム情報の他のタイプ。帯域幅要求は、サンプル周波数と分解能に応じて変化し、一定のビットレートまたは（イベントドリブンの場合）バーストのいずれであってもよいです。
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）はマルチメディア会議：オーディオ/ビデオとホワイトボードには、古典的な会議アプリケーションを含みます。優先度の異なる複数のデータストリームを持つことは、このタイプのアプリケーションを特徴づけます。コーディネーションの問題 - その開発とユーザビリティを複雑に - な時に話すことを誰が決定するなど。そこ共通ヒューリスティックと「遊びのルールは」ですが、何の基準は会議グループダイナミクスを管理するために存在しません。
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.
ⅰ）コラボレーション：共有ドキュメント編集。
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配信アプリケーションです。
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）は、インタラクティブなシミュレーション[DIS]を分散します。これらの帯域幅要求は、オブジェクトの数と説明情報が増加の解像度として、途方もないことができます。
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）はジャムセッション：共有符号化されたオーディオ（例えば、音楽）。帯域幅要求が等符号化技術、サンプルレート、サンプル分解能、チャネルの数に基づいて変化し
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:
一対多および多対多のアプリケーションカテゴリとは異なり、多対一（Mto1）カテゴリは、IPレイヤで通信メカニズムを表すものではありません。アプリケーション層によって定義されるようMto1アプリケーションは、複数の送信者および1つ（または少数の）受信機（複数可）を有します。表1は、Mto1アプリケーションが一方向であるか、送信者または受信機（複数可）のいずれかが要求を生成することができる双方向リクエスト/レスポンス型プロトコルを使用することができることを示しています。図2は、Mto1アプリケーションでI / O関係の可能性を特徴付けます：
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アプリケーションは、多くのスケーリングの問題があります。あまりにも多くの同時の送信者は、潜在的に、受信機（複数可）、「内破問題」として特徴付けられる状態を圧倒することができます。別のかなりのスケーリング問題が有する多くのマルチキャスト送信者が生成し、ネットワーク内の状態の大きい量です。これは、アプリケーションへの大部分は透明であり、効果は、マルチキャストルーティングプロトコルで双方向の木を使用して、将来的に減少することができるが、それにもかかわらず、それはアプリケーション設計者によって考慮されるべきです。
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)
<----------- -----------> <----------
Figure 2: Characterization of Mto1 I/O possibilities
図2：Mto1 I / Oの可能性のキャラクタリゼーション
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アプリケーションでマルチキャストを使用することの主な利点は、送信者が受信機（複数の）ユニキャストアドレスを知る必要がないことであるため、一つの代替は、マルチキャストを介してユニキャストアドレスをアドバタイズするために、各受信機のためのものです。この戦略は、まだ各受信機の爆縮の可能性を残ししかし、さらなる戦略を負荷を分散するために必要とされ得ます。例えば、「ローカル回復」（セクション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）資源発見：マルチキャストレシーバをグループアドレスにクエリを送信するために、彼らはので、最も近いホストからの応答を引き出すために：サービスの場所は、例えば、「ホストエニーキャストサービス」機能[エニーキャスト]のようなものを有効にするには、IPマルチキャストを活用します要求を満たすことができます。応答は、受信機が使用する最も適切な（例えば、最も近い）サービスプロバイダを決定することを可能にする情報が含まれている場合があります。
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).
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 continuously at regular intervals, or send spontaneously when a pre-defined event occurs. Bandwidth demands can vary based on sample frequency and resolution.
P）データ収集：これは、前述の1対多の「監視」アプリケーションの逆です。この場合、データ収集ホストにデータを送信する分散型「センサ」の任意の数が存在してもよいです。センサはデータコレクタからの要求に応じて更新を送信する、または一定の間隔で連続的に送信し、または事前定義されたイベントが発生したときに自発的に送信するかもしれません。帯域幅要求は、サンプル周波数と分解能に基づいて変えることができます。
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.
これは、エントリA1とA3、A3は、ループバック・インターフェースを有することがある唯一の違いにより、表1に示されています。図2では、これは受信機の数を容易つ以上とすることができるので、これは本当にMTOMアプリケーションである可能性番号1です。
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.
これは技術的にMTOM適用するであろうことが、表1の応答は、マルチキャストアドレスに送信することができ、図2に可能性の数2であり、及びD5。
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）ポーリング：「世論調査員は、」質問を送信し、「polleesは」答えを応答します。これは、図2の可能性の数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.
これは、最初のユニキャスト要求がアプリケーションのこのタイプの典型的な1toM間の唯一の違いであり、表1に、図2、及びエントリD4に可能性の数4によって特徴付けられます。その最初の要求は、マルチキャストアドレスに送信された場合、これは効果的に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.
トン）会計：これは、基本的にはデータ収集であるが、それは重要なアプリケーションであるため、分離する価値があります。いくつかのマルチキャストアプリケーションでは、おそらくリアルタイムで、各受信機についての情報を知ることが不可欠です。しかし、そのような情報は[MRM]圧倒的なことができます。 （それはマルチキャストであるため、実際にMTOMあるがMto1作ることができる）RTCP等現在のメカニズムは、スケーリング技術が、トレードオフ情報粒度を使用します。グループが大きくなるようなフィードバックの総量は一定であるが、各受信機は以下を送ります。
Some multicast application service requirements are common to unicast network applications as well. We characterize two of them here-- bandwidth and delay requirements.
いくつかのマルチキャストアプリケーションサービスの要件は、同様に、ユニキャストネットワークアプリケーションに共通しています。我々は彼らの2つのhere--帯域幅と遅延の要件を特徴づけます。
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
Figure 3: Bandwidth Requirements of applications
図3：アプリケーションの帯域幅の要件
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 examples see Figure 4, which plots multicast applications on a (coarse) scale of sensitivity to delivery delays.
遅延を最小限に抑えるために、この必要性は、オーディオやビデオが500以上のミリ秒遅延した場合、ユーザーが効果的に会話することはできません（双方向）会議アプリケーションにおいて最も明白です。この及び他の実施例の配信遅延に対する感度の（粗い）スケール上のマルチキャストアプリケーションをプロット図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
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プロトコルとサービスのように更なる議論は、この文書の範囲を超えて、アプリケーションの制御を超えています。
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の開発に関わる課題や多対多のアプリケーションがあります。これらのいくつかは、ユニキャストアプリケーションに同様の要件帯域幅と遅延の要件を持っています。
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.
マルチキャストアプリケーションは、さらに、それらが必要とするサービスでユニキャストアプリケーションから、互いに区別することができます。このセクションでは、マルチキャストアプリケーションのための独自の要件を持っているさまざまなサービスの調査結果を提供します。
+--------------------------------------------------------------+
| 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 |
+----------------------------------------++--------------------+
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.
アドレス管理 - 選択とアドレス割り当てのコーディネート。必要性は、「アドレス衝突」に対する保証を提供し、アドレスの所有権を提供することです。
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.
セッション管理 - マルチキャスト輸送の上にアプリケーション層のサービスを実行します。これらのサービスは、アプリケーションに大きく依存しますが、セッションなどの広告、課金、グループのメンバーの監視、鍵配布、などの機能が含まれます
Heterogeneous Receiver Support - Sending to receivers with a wide variety of bandwidth capacities, latency characteristics, and network congestion requires feedback to monitor receiver performance.
ヘテロジニアスレシーバーサポート - 帯域幅容量、レイテンシーの特性、およびネットワークの混雑の多種多様な受信機への送信は、受信機の性能を監視するためのフィードバックが必要です。
Reliable Data Delivery - Ensuring that all data sent is received by all receivers.
信頼性の高いデータ配信 - 送信されたすべてのデータは、すべての受信機で受信されることを保証します。
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.
同期したプレイアウト - 複数の受信機は、「リプレイ」のデータが同期して受信できるようにします。
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.
このセクションの残りの部分では、我々は、より詳細にそれらが存在課題、標準化されたソリューションの状況をこれらのアプリケーション・サービスのそれぞれについて説明します。
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:
マルチキャストアプリケーション開発者が直面する最初の質問の一つは、マルチキャストアドレスを使用するものです。マルチキャストアドレスは、個々のホストに割り当てられていない、割り当てを動的に変更することができ、およびアドレスは、時には自分自身のセマンティクス（例えば、管理スコーピング）を持っています。マルチキャストアプリケーションでは、アドレスの割り当てまたは割り当てのクエリを提供したアドレス管理サービスを必要とします。マルチキャストアドレスを学ぶアプリケーションのためのいくつかの方法があります。
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.
アルゴリズム派生：統計的にランダムな（未使用）のアドレスを割り当てるためのプログラムのアルゴリズムを使用しました。
|
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
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.
ほとんどの場合、アプリケーション設計者は、マルチキャストアドレスが動的であることをしていることを前提とすべきです。マルチキャストアドレス空間の非常に少ない[MADDR] IANAによって静的割り当てのために利用可能です。また、ホスト固有のSSMで利用可能なアドレス指定を与えられ、インターネット全体で、静的アドレスの割り当ては非常にまれであることが期待されます。
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- 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.
セッション管理は、マルチキャストに関して最も誤解サービスの1つです。ほとんどのアプリケーション開発者は、マルチキャストは、実際にはなど、セキュリティ、暗号化、信頼性、セッション広告、モニタリング、課金、のようなサービスを提供することを前提とし、マルチキャストは、単にエンドツーエンドの配信を提供し、トランスポート・メカニズムです。他のすべてのサービスは、各特定のアプリケーションによって提供されなければならないアプリケーション層サービスです。さらに、ほとんどの場合、これらの機能が提供されるべきかについての基準が定義されていません。特定の機能は、アプリケーションの特定のニーズに依存しており、単一の方法（または標準）は、すべての場合に十分なことが行われないことができます。
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をクリックした後、グループアドレスと、おそらくグループのソース（S）に関する情報が含まれてユーザーに返さ応答を有することにより、グループに参加することができます。別のメカニズムは、セッション記述プロトコル[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
- スケジュールされたセッションを宣伝 - セッションのスケジュールについての情報を取得するためのクエリメカニズムを提供します
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.
一対一 - - 2つのホストが、ユニキャストを介して通信する際にIPネットワークを介して送信者は、様々なネットワーク条件に適応することが比較的容易です。伝送制御プロトコル（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は、ネットワークの輻輳や低帯域幅のリンクがあることを推測し、その送信レート[スロースタート]を下に絞ることによって適応します。
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よりもとても良く行うことができます。データの損失が検出されたときに更新され、送信レートはCBRオーディオ/ビデオストリームを要求するよりも遅いかもしれないが、TCPは自動的に、「輻輳ウィンドウ」を軽減します。 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.
- 冗長データ運命の共有を避けるために、時間的にオフセット（例えば、順方向誤り訂正）を追加するデータのエンコードを変更します。データ損失の割合は、単純に忠実ではなく、破損以外のデータを削減しますので、これはまた、「レイヤード」である可能性があります。
- 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).
- （例えば、オーディオ配信を確保するためにビデオを犠牲に）より高い優先順位の他に有利にするために、1つのデータストリームの送信速度を低下させます。
- 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対多、または多対many--複数の受信機を持って、フィードバック・ループのデザインは変更を必要とします。すべての受信機が同時にデータ損失レポートを返した場合、送信者は回答の嵐で簡単に圧倒され。これは、「内破問題」として知られています。
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.
共有学習 - 損失が検出された場合（すなわち、配列決定されたパケットを受信していない）は、受信機は、ランダムタイマを起動します。それが期限切れになるようにタイマーを待ちなどの別の受信機によって送信されたデータの損失の報告を受けた場合は、タイマーを停止し、レポートを送信しません。それ以外の場合は、タイマーが満了したレポートを送信します。リアルタイムプロトコルとそのフィードバック・ループの対応リアルタイム制御プロトコル[RTP / RTCP] 5パーセントまたは全体のセッショントラフィック未満にフィードバックトラフィックを維持するためにこれと同様の戦略を採用しています。この技術は、もともと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.
ローカルリカバリ - のいずれかで再送信データ喪失を再送信する前に、低帯域幅受信機のためのデータを報告したり、再エンコードされている場合、一部の受信機は、（おそらく、ユニキャストを介して）ローカルに、ローカル配布ポイントまたは「トランスコーダ」として指定することができます。 「ローカル回復は」いくつかの信頼できるマルチキャストプロトコルによって使用されているが何の基準は、これらの戦略のために存在しません。
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.
異種の受信機のための適応型マルチキャストアプリケーションの設計は、まだ研究の活発な領域です。 「ネットワークフレンドリー」な方法でネットワークの状況に適応しながら、基本的な要件は、アプリケーションの使いやすさを最大化することです。換言すれば、輻輳検出及び回避は、（少なくとも）ユーザーエクスペリエンスなどのプロトコルの設計における重要なようです。適応メカニズムも安定していなければならないので、彼らはあまりにも迅速に適応していない - 発振を避けるために - 過渡状態であるかもしれないものについてあまりにも少ない情報に基づいて変更するエンコーディングや料金。
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]を参照してください。
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
Figure 7: Reliability Requirements of Application types
図7：アプリケーションの種類の信頼性要件
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.
信頼性の高いマルチキャストトランスポートを有効にするにかかわる課題のいくつかは、異種の受信者に送信するのと同じであり、いくつかの解決策にも似ています。例えば、多くの信頼性の高いマルチキャストトランスポートプロトコルは、失われたものを示すために、受信機から否定応答（NAKを）使って、内破問題を回避します。彼らはまた、受信機が他人のNAKに耳を傾け、その後、データの結果として再送を聞くことにより、「共有学習」ではなく、NAK自分自身を送信することにより、再送を要求を使用します。
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]が存在し、そしていくつかは商用製品ですでに利用可能であるが、それらのどれも標準化されていません。作業は、問題のより良い定義、マルチキャストトランスポート要件、およびプロトコルメカニズムを提供するために、インターネットリサーチタスクフォース[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]を標準化すると確信しています。
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 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
送信者を制限 - グループアドレスに送信できるユーザーを制御します
Limiting Receivers - Controlling who can receive
レシーバを制限する - 受信できるユーザーを制御
Limiting Access - Controlling who can "read" multicast content either by encrypting content or limiting receivers (which isn't possible yet)
アクセスの制限 - 制御（まだ不可能である）受信機を、コンテンツを暗号化するか、制限することにより、いずれかのマルチキャストコンテンツを「読む」ことができます
Verifying Content - Ensuring that data originated from an authenticated sender and was not altered en route
データは、認証済みの送信者から発信し、途中で変更されていないことを確認 - コンテンツの確認
Protecting Receiver Privacy - Controlling whether sender(s) or other receivers know receiver identity
レシーバプライバシーを保護する - 送信者（複数可）または他の受信機が受信機のアイデンティティを知っているかどうかを制御します
Firewall Traversal - Proxying outgoing "join" requests through firewalls, allowing incoming or outgoing traffic through, and (possibly) authenticating receivers for filtering purposes and security [Finlayson].
ファイアウォール越え - 、ファイアウォールを介して発信「結合」リクエストをプロキシを介して、着信または発信トラフィックを許可し、（おそらく）フィルタリングの目的及びセキュリティ【フィンレイソン]のための受信機を認証します。
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].
このリストは包括的ではありませんが、最も一般的に必要なセキュリティサービスを含んでいます。異なるマルチキャストアプリケーションと異なるアプリケーションコンテキストは、これらのサービス、および他の人に対して非常に異なるニーズを持つことができます。二つの主要な問題は、現在のソリューションのパフォーマンスは[ミリ秒]まだ十分とは言えないところ、出てきます。
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.
パフォーマンスは、主にユーザーがグループに参加するか、葉の要因です。例えば、方法は、参加または再キーイング部材の葉の後に現在のメンバーは、オーバーヘッドかなりの処理及びプロトコルを含む、使い勝手に影響を与える重大な遅延をもたらす可能性が中電位グループメンバーを認証するために使用されます。
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.
信頼性の高いマルチキャストのように、安全なマルチキャストは、インターネットリサーチタスクフォース[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.
信頼性の高いマルチキャストのために真であるとして、現在のコンセンサスは単一のセキュリティプロトコルは、マルチキャストアプリケーションの中で、時には、相反する要求の広い多様性を満たしていないということです。したがって、マルチキャストセキュリティもおそらく多数の異なるプロトコルが必要になります。
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.
これは、すべての受信機が同時に遊ぶアウト、彼らが受信したマルチキャストデータを持つを指します。これはfairness--プレイアウトオークションの価格、または株式の価格のために必要があるかもしれない - あるいは、そのような音楽を演奏するときなど、他の受信機との同期を確保するために。
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.
今、マルチメディア、ネットワーク対応のコンピュータ・システムの完全な家を想像してみてください。彼らはすべてのマルチキャスト経由で同時に同じ音楽データ・ストリームを受信しますが、あなたが部屋ツー部屋を歩くと、彼らは不連続な音楽再生を実現します。
To provide synchronized playback that would enable continuous music from room-to-room would require three things:
部屋ツー部屋からの連続音楽を可能にする同期再生を提供するために三つのことが必要になります。
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）データストリームは、タイムスタンプで囲まれなければならない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分の1は、この時点で達成することが最も困難です。さまざまなオーディオおよびビデオデバイスは、パフォーマンスの広い範囲を持っているが、ハードウェアとドライバは、この情報を取得するための任意のメカニズムを提供しません。
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実装は、暗黙的にアプリケーションを明示的に相互作用することなく、信頼性の高いマルチキャストプロトコルを有効にすることが考えられます。
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を作成することも可能です。
See section 5.4
5.4節を参照してください。
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. Miller氏、およびデーブターラーを実行しました。
[AnyCast] Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
[ANYCAST]ウズラ、C.、メンデス、T.およびW.ミリケン、 "ホストエニーキャストサービス"、RFC 1546、1993年11月。
[BeauW] B. Williamson, "Developing IP Multicast Networks, Volume I", (c) 2000 Cisco Press, Indianapolis IN, ISBN 1-57870- 077-9.
[BeauW] B.ウィリアムソン、 "IPマルチキャストネットワークを開発し、ボリュームI"、（C）2000 Cisco Pressでは、インディアナ州インディアナポリス、ISBN 1-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.
[BULK] Whetten、B.、Vicisano、L.、Kermode、R.、ハンドレー、M.、フロイド、S.及びM.ルビー、 "一対多バルクデータ転送のための信頼できるマルチキャストトランスポート・ビルディング・ブロック"、 RFC 3048、2001年1月。
[Deering] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[デアリング]デアリング、S.、 "IPマルチキャスティングのためのホスト拡大"、STD 5、RFC 1112、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.
【DIS】プーレン、J.、Mytak、M.とC. Bouwens、「大規模マルチキャスト環境における分散シミュレーションのためのインターネットプロトコルスイートの制限」、RFC 2502、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のネットワークの上の統合サービス操作" 、RFC 2998、2000年11月。
[Estrin] D. Estrin, "Multicast: Enabler and Challenge", Caltech Earthlink Seminar Series, April 22, 1998.
[Estrin] D. Estrin、 "マルチキャスト：イネーブラと挑戦"、カリフォルニア工科大学アースリンクセミナーシリーズ、1998年4月22日。
[Finlayson] Finlayson, R., "IP Multicast and Firewalls", RFC 2588, May 1999.
[フィンレイソン]フィンレイソン、R.、 "IPマルチキャストとファイアウォール"、RFC 2588、1999年5月。
[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"、RFC 2236、1997年11月。
[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.アマル、「インタラクティブマルチメディアジュークボックス（IMJ）：オーディオ/ビデオのオンデマンド配信のための新しいパラダイム」、第7回国際ワールドワイドウェブ会議、ブリスベンの議事録、AUSTRALIA、4月1998。
[IRTF] Weinrib, A. and J. Postel, "The IRTF Guidelines and Procedures", BCP 8, RFC 2014, January 1996.
【IRTF] Weinrib、A.およびJ.ポステル、 "IRTFガイドラインおよび手順"、BCP 8、RFC 2014、1996年1月。
[Kermode] Kermode, R., "MADCAP Multicast Scope Nesting State Option", RFC 2907, September 2000.
[Kermode] Kermode、R.、 "MADCAPマルチキャストスコープネストstateオプション"、RFC 2907、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、 "大規模なマルチキャストアプリケーションのための分類コミュニケーションの要件"、RFC 2729、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ガイドライン"、BCP 51、RFC 3171、2001年8月。
[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.、ゴヴィンダン、R.、ハンドレー、M.、クマー、S.、Radoslavov、P。およびD.ターレル、 "マルチキャストアドレスセットクレーム（MASC）プロトコル"、RFC 2909、2000年9月。
[Maufer] T. Maufer, "Deploying IP Multicast in the Enterprise", (c) 1998 Prentice Hall, Upper Saddle River NJ ISBN 0-13- 897687-2.
"企業におけるIPマルチキャストの展開" [Maufer] T. Maufer、（c）は1998年プレンティスホール、アッパーサドルリバーNJ ISBN 0-13- 897687から2。
[Miller] C. K. Miller, "Multicast Networking and Applications", (c) 1999 Addison Wesley Longman, Reading MA ISBN 0-201- 30979-3.
【ミラー】C. K.ミラー、「マルチキャストネットワークと応用」、（C）1999アディソンウェズレー・ロングマン、読書MA ISBN 0-201- 30979から3。
[MADCAP] Hanna, S., Patel, B. and M. Shah, "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.
【MADCAP]ハンナ、S.、パテル、B.及びM.シャー、 "マルチキャストアドレス動的クライアント割り当てプロトコル（MADCAP）"、RFC 2730、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
[ミリ秒]マルチキャストセキュリティ（ミリ秒）IETFワーキンググループのチャーター
[MZAP] Handley, M., Thaler, D. and R. Kermode, "Multicast-Scope Zone Announcement Protocol (MZAP)", RFC 2776, February 2000.
【MZAP]ハンドレー、M.、ターラー、D.およびR. Kermode、 "マルチキャストスコープゾーン発表プロトコル（MZAP）"、RFC 2776、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通信誌、巻。 36第1号、1998年1月。
[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における高速グループ経営"、HIPPARC 98ワークショップ、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.とV.パクソン、 "信頼性の高いマルチキャストトランスポートとアプリケーションプロトコルを評価するためのIETF基準"、RFC 2357、1998年6月。
[RSVP] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RSVP] Wroclawski、J.、RFC 2210、1997年9月 "IETF統合サービスとRSVPの使用"。
[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
[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. Jacobson氏、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、RFC 1889、1996年1月。
[SAP] Handley, M., Perkins, C. and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[SAP]ハンドリー、M.、パーキンス、C.とE.ウィーラン、 "セッションアナウンスメントプロトコル"、RFC 2974、2000年10月。
[SDP] Handley, M., and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[SDP]ハンドリー、M.、およびV.ヤコブソン、 "SDP：セッション記述プロトコル"、RFC 2327、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.
[スロースタート]スティーブンス、W.、 "TCPスロースタート、輻輳回避、高速再送、および高速リカバリアルゴリズム"、RFC 2001、1997年1月。
[SLP] Veizades, J., Guttman, E., Perkins, C. and S. Kaplan, "Service Location Protocol", RFC 2165, June 1997.
[SLP] Veizades、J.、ガットマン、E.、パーキンス、C.及びS.カプラン、 "サービス・ロケーション・プロトコル"、RFC 2165、1997年6月。
[SSM] Holbrook, H. and B. Cain, "Specific Multicast for IP", Work in Progress.
[SSM]ホルブルック、H.、およびB.カイン、 "IPのための具体的マルチキャスト" が進行中で働いています。
Bob Quinn Celox Networks 2 Park Central Drive Southborough, MA 01772
ボブ・クインCelox Networksの2パークセントラルドライブサウスボロ、MA 01772
Phone: +1 508 305 7000 EMail: bquinn@celoxnetworks.com
電話：+1 508 305 7000 Eメール：bquinn@celoxnetworks.com
Kevin Almeroth Department of Computer Science University of California Santa Barbara, CA 93106-5110
カリフォルニア州サンタバーバラのコンピュータサイエンス大学のケビン・Almeroth部門、CA 93106-5110
Phone: +1 805 893 2777 EMail: almeroth@cs.ucsb.edu
電話：+1 805 893 2777 Eメール：almeroth@cs.ucsb.edu
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。