[要約] 要約：RFC 3170は、IPマルチキャストアプリケーションの課題と解決策についての情報を提供しています。 目的：このRFCの目的は、IPマルチキャストアプリケーションの実装と運用に関連する問題を理解し、解決策を提供することです。
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
IPマルチキャストアプリケーション：課題とソリューション
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.
Copyright（c）The Internet Society（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）の時間からの時間（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.
しかし、この明らかなシンプルさは欺cept的です。不均一なネットワークでうまくスケーリングできるアプリケーションとプロトコルでマルチキャストサポートを有効にすることは、重要な課題です。具体的には、一定のビットレートのデータストリームを送信し、信頼できるデータ配信、セキュリティ、および多くのコミュニケーションの管理にはすべて特別な検討が必要です。いくつかのソリューションが利用可能ですが、これらのサービスの多くは依然としてアクティブな研究分野です。
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.
読者はマルチキャストのメカニズムを一般的に理解していると仮定しており、この点で他の入門書[Beau、Maufer、Miller]を補完するつもりです。これは包括的な試験ではなく入門調査であるため、詳細については、読者を他のマルチキャストアプリケーション要件の説明[RM、LSMA、Miller]に紹介します。
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 Multicast対応ネットワーク」という用語、マルチキャストインフラストラクチャ、および重要なマルチキャストサービスを定義します。次に、マルチキャストアプリケーションが有効にできる新しい機能とその要件について説明します。次に、これらの要件を満たすサービス、彼らが提示する課題を調べ、利用可能または開発中のソリューションの簡単な調査を提供します。マルチキャストサービス用のアプリケーションプログラミングインターフェイス（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種類あります。1つ目は、RFC 1112 [ディアリング]で定義されている元のマルチキャストサービスモデルに基づいています。このモデルでは、受信機が単にグループに参加するだけで、ソースの身元を知る必要はありません。このモデルは、インターネット標準マルチキャスト（ISM）、インターネット伝統的なマルチキャスト（ITM）、ディアリングマルチキャストなど、多くの名前で知られています。レシーバーは、関連するソースのセットを知っている必要があります。このタイプのマルチキャストは、ソース固有のマルチキャスト（SSM）[SSM]と呼ばれます。ネットワークが提供するマルチキャスト機能の種類を知ることは、アプリケーションの責任になります。現在、アプリケーションがマルチキャストのタイプを知る唯一の方法は、グループアドレスに基づいています。グループが232/8の範囲にある場合、アプリケーションはSSMがサービスモデルであると仮定する必要があります。それ以外の場合、アプリケーションはソースGenericマルチキャストがサービスモデルであると想定する必要があります。
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
LATENCYに参加：アプリケーションがマルチキャストグループに参加するコマンドを発行した後にデータが流れ始めるのにかかる時間
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.
効果的な輻輳制御メカニズムのために、望ましくない流れを迅速に停止するための高速休暇段階の両方が非常に望ましいものであり、ネットワークが一般的に望ましくないトラフィックをよりよくフィルタリングするためには非常に望ましい[Rizzo]。アプリケーションは、結合またはレイテンシのいずれかの制御に影響を与えることはできませんが、適切な操作を有効にするためのマルチキャストインフラストラクチャに依存します。これは、基本的なマルチキャストサービス要件です。
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マルチキャスト対応ネットワークが利用可能で、ユニークで強力なアプリケーションとアプリケーションサービスが可能です。「マルチキャストが調整を可能にします - ゆるく結合した分散システム（人、サーバー、データベース、プロセス、デバイスなど）に適しています」[エストリン]。
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:
IPマルチキャストアプリケーションを1対1のユニキャストアプリケーションと区別するのは、マルチキャストが有効にする他の送信者と受信者関係です。マルチキャストアプリケーションには3つの一般的なカテゴリがあります。
One-to-Many (1toM): A single host sending to two or more (n) receivers
1対Many（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）：ユニキャストまたはマルチキャストを介して（ソース）送信者にデータを送信するレシーバーの数
+-----------------------------------+
| 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のみであり、ユニキャストは常に1対1（1to1）です。たとえば、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は、送信者と受信機の間のアプリケーションレベルの関係によって定義される人工カテゴリであることを強調する価値があります。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).
1対Many（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) スケジュールされたオーディオ/ビデオ（A/V）配信：講義、プレゼンテーション、会議、またはマルチメディアのカバレッジが視聴者に利益をもたらす可能性のあるその他のタイプのスケジュールされたイベント（つまり、テレビやラジオの「放送」）。1つ以上の一定のビット率（CBR）データストリームと比較的高い帯域幅の要求がこれらのアプリケーションを特徴づけています。オーディオ/ビデオの組み合わせのように、複数のDataStreamが存在する場合、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.
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ディストリビューションアプリケーションです。
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) マルチプレイヤーゲーム：多くのマルチプレイヤーゲームは、単純に分散されたインタラクティブシミュレーションであり、チャットグループ機能が含まれる場合があります。帯域幅の使用量は大きく異なる場合がありますが、今日の第1世代のマルチプレイヤーゲームは、帯域幅の使用を最小限に抑えてターゲットオーディエンスを増やしようとしています（その多くはまだダイヤルアップモデムを使用しています）。
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:
1対多で多数のアプリケーションカテゴリとは異なり、多くの（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
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アプリケーションでマルチキャストを使用する主な利点は、送信者が受信機ユニキャストアドレス（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) リソースの発見：サービスの場所：たとえば、IPマルチキャストを活用して「ホストのaycastingサービス」機能のようなものを有効にします[anycast]：マルチキャストレシーバーはグループアドレスにクエリを送信し、最も近いホストから応答を引き出して満たすことができますリクエスト。応答には、受信者が使用できる最も適切な（最も近い）サービスプロバイダーを決定できる情報も含まれている場合があります。
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).
表1では、このアプリケーションはエントリD4です。また、図2に可能な番号3で示されています。代わりに、応答はユニキャストアドレスではなくマルチキャストに対するものである可能性がありますが、技術的にはMTOMアプリケーションタイプになります（これはサービスロケーションプロトコル[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 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によって表1に示されています。唯一の違いは、A3にループバックインターフェイスがあることです。図2では、これは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の2番目、表1のD5の可能性があります。応答はマルチキャストアドレスに送信できますが、技術的には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の可能性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) Jukebox：需要が近いA/Vの再生が許可されています。受信者は、「帯域外」プロトコルメカニズム（Web、電子メール、ユニキャスト、またはマルチキャストリクエストなど）を使用して、再生リクエストをスケジューリングキュー[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の可能性4、表1のエントリ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であるためMTOMである）のような現在のメカニズムは、スケーリング手法を使用しますが、情報の粒度をトレードオフします。グループが拡大すると、フィードバックの合計量は一定ですが、各受信機の送信は少なくなります。
Some multicast application service requirements are common to unicast network applications as well. We characterize two of them here-- bandwidth and delay requirements.
一部のマルチキャストアプリケーションサービス要件は、ユニキャストネットワークアプリケーションにも共通しています。これらの2つは、帯域幅と遅延要件の2つを特徴づけています。
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対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:
マルチキャストアプリケーション開発者が直面している最初の質問の1つは、使用するマルチキャストアドレスです。マルチキャストアドレスは個々のホストに割り当てられておらず、割り当ては動的に変更でき、アドレスには独自のセマンティクスがある場合があります（たとえば、管理者のスコープ）。マルチキャストアプリケーションには、アドレスの割り当てまたは割り当てクエリを提供するアドレス管理サービスが必要です。アプリケーションがマルチキャストアドレスについて学ぶ方法はいくつかあります。
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.
ほとんどすべての場合、アプリケーション設計者は、マルチキャストアドレスが動的であると仮定する必要があります。IANA [MADDR]による静的割り当てには、マルチキャストアドレススペースがほとんど使用できません。また、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をクリックしてグループに参加してから、グループアドレスとグループソースに関する情報を含むユーザーに返信を返すことができます。別のメカニズムは、セッション説明プロトコル[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セッションの説明は、Web（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人のホストがUnicastを介して通信する場合、1対1で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はネットワークの輻輳または低帯域幅リンクがあることを推測し、送信金利[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.
- データエンコーディングを変更して、冗長データ（例：フォワードエラー補正）オフセットを時間内に追加して、運命の共有を避けます。これも「階層化」する可能性があるため、データの損失の割合は、データを破損するのではなく、単に忠実度を軽減します。
- 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つの多くの、または多目的）では、フィードバックループ設計には変更が必要です。すべてのレシーバーがデータ損失レポートを同時に返す場合、送信者は返信の嵐で簡単に圧倒されます。これは「爆発問題」と呼ばれます。
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).
スケーラビリティは最重要の懸念であり、信頼できる配信を提供するために混雑を検出および回避する「ネットワークに優しい」プロトコルの一般的なニーズを意味します。その他の考慮事項は、プロトコルの堅牢性、「Late Goinins」のサポート、グループ管理とセキュリティ（次に説明）です。
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].
現在のコンセンサスは、多種多様なマルチキャストアプリケーション要件（一部が対立するもの）により、単一のマルチキャストトランスポートはすべてのアプリケーションに適していない可能性があります。その結果、ほとんどの人は、単一の[バルク、RMT]ではなく、最終的に多くの信頼できるマルチキャストプロトコルを標準化すると考えています。
For any IP network application--unicast or multicast--security is necessary because networks comprise users with different levels of trust.
ネットワークがさまざまなレベルの信頼を持つユーザーを構成するため、IPネットワークアプリケーション（UnicastまたはMulticast）のセキュリティが必要です。
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].
ファイアウォールトラバーサル - ファイアウォールを介して発信「参加」要求をプロキシし、着信または発信トラフィックを可能にし、（おそらく）フィルタリング目的とセキュリティのためにレシーバーを認証する[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].
このリストは包括的ではありませんが、最も一般的に必要なセキュリティサービスが含まれています。さまざまなマルチキャストアプリケーションとさまざまなアプリケーションコンテキストは、これらのサービスやその他に関して非常に異なるニーズを持つことができます。現在のソリューションのパフォーマンスが望まれる[MSEC]を残す2つの主な問題が発生します。
Individual authentication - how is sender identity verified for each multicast datagram received?
個別認証 - マルチキャストデータグラムごとに送信者IDはどのように確認されますか？
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.
信頼性の高いマルチキャストと同様に、Secure Multicastはインターネットリサーチタスクフォース[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.
これは、すべての受信機が受け取ったマルチキャストデータを同時に再生することを指します。これは、公平性 - オークションまたは株価の価格を再生するために、または音楽を演奏するときなど、他のレシーバーと同期するために必要になる場合があります。
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:
部屋から部屋への継続的な音楽を可能にする同期された再生を提供するには、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）データストリームはタイムスタンプに囲まれている必要があります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番目は、現時点で達成するのが最も困難です。ハードウェアとドライバーは、この情報を取得するためのメカニズムを提供しませんが、さまざまなオーディオデバイスやビデオデバイスには幅広いパフォーマンスがあります。
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.
著者は、Ran Canetti、Brian Haberman、Eric A. Hall、Kenneth C. Miller、Dave Thalerの有益なフィードバックについて、次の個人に感謝し、感謝したいと思います。
[AnyCast] Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
[Anycast] Partridge、C.、Mendez、T。and W. Milliken、「Host Anycasting Service」、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. Williamson、「IPマルチキャストネットワークの開発、ボリュームI」、（c）2000 Cisco Press、Indianapolis in、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.、Handley、M.、Floyd、S。、およびM. Luby、「1対多くのバルクデータ転送用の信頼できるマルチキャスト輸送ビルディングブロック」、RFC 3048、2001年1月。
[Deering] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[Deering] Deering、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] Pullen、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.、Ford、P.、Baker、F.、Zhang、L.、Speer、M.、Braden、R。、およびB. Davie、「Diffserv Networksを介した統合サービス操作」、RFC 2998、2000年11月。
[Estrin] D. Estrin, "Multicast: Enabler and Challenge", Caltech Earthlink Seminar Series, April 22, 1998.
[エストリン] D.エストリン、「マルチキャスト：イネーブラーとチャレンジ」、Caltech EarthLinkセミナーシリーズ、1998年4月22日。
[Finlayson] Finlayson, R., "IP Multicast and Firewalls", RFC 2588, May 1999.
[Finlayson] Finlayson、R。、「IPマルチキャストとファイアウォール」、RFC 2588、1999年5月。
[HNRS] Hofman, Nonnenmacher, Rosenberg, Schulzrinne, "A Taxonomy of Feedback for Multicast", June 1999, Work in Progress.
[HNRS] Hofman、Nonnenmacher、Rosenberg、Schulzrinne、1999年6月、「マルチキャストのフィードバックの分類法」、作業進行中。
[IGMPv2] Fenner, B., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[Igmpv2] Fenner、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] Cain、B.、Deering、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 and M. Ammar、「インタラクティブマルチメディアジュークボックス（IMJ）：オーディオ/ビデオのオンデマンド配信のための新しいパラダイム」、オーストラリア、ブリスベン、セブンスインターナショナルワールドワイドウェブカンファレンスの議事録、4月1998年。
[IRTF] Weinrib, A. and J. Postel, "The IRTF Guidelines and Procedures", BCP 8, RFC 2014, January 1996.
[IRTF] Weinrib、A。およびJ. Postel、「IRTFガイドラインと手順」、BCP 8、RFC 2014、1996年1月。
[Kermode] Kermode, R., "MADCAP Multicast Scope Nesting State Option", RFC 2907, September 2000.
[Kermode] Kermode、R。、「Madcap Multicast Scope Nesting State Option」、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.、Briscoe、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.、Meyer、D。、およびM. Schipper、「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.、Govindan、R.、Handley、M.、Kumar、S.、Radoslavov、P。and D. Thaler、「マルチキャストアドレスセットクレーム（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.
[Maufer] T. Maufer、「エンタープライズにIPマルチキャストの展開」、（c）1998 Prentice Hall、アッパーサドルリバー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.
[Miller] C. K. Miller、「マルチキャストネットワーキングとアプリケーション」、（c）1999 Addison Wesley Longman、Reading 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] Hanna、S.、Patel、B。、およびM. Shah、「マルチキャストアドレスダイナミッククライアント割り当てプロトコル（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、「マルチキャスト展開の取り組みのサポート：マルチキャストモニタリングのためのツールの調査」、Journal of High Speed Networking-マルチメディアネットワーキングの管理に関する特別な問題、2001年3月
[MSec] Multicast Security (msec) IETF Working Group charter
[MSEC]マルチキャストセキュリティ（MSEC）IETFワーキンググループチャーター
[MZAP] Handley, M., Thaler, D. and R. Kermode, "Multicast-Scope Zone Announcement Protocol (MZAP)", RFC 2776, February 2000.
[MZAP] Handley、M.、Thaler、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 Communications Magazine、Vol。36 No. 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
[Rizzo] L. Rizzo、「IGMPの高速グループ管理」、Hipparc 98ワークショップ、1998年6月、UCL London 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] Mankin、A.、Romanow、A.、Bradner、S。、およびV. Paxson、「信頼できるマルチキャストトランスポートおよびアプリケーションプロトコルを評価するためのIETF基準」、RFC 2357、1998年6月。
[RSVP] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RSVP] Wroclawski、J。、「IETF統合サービスでのRSVPの使用」、RFC 2210、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、et al、 "RTP Library 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.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、RFC 1889、1996年1月。
[SAP] Handley, M., Perkins, C. and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[SAP] Handley、M.、Perkins、C。and E. Whelan、「セッションアナウンスプロトコル」、RFC 2974、2000年10月。
[SDP] Handley, M., and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[SDP] Handley、M。、およびV. Jacobson、「SDP：セッション説明プロトコル」、RFC 2327、1998年4月。
[Schneier] B. Schneier, "Why Cryptography Is Harder Than It Looks", December 1996, http://www.counterpane.com/whycrypto.html
[Schneier] B. Schneier、「なぜ暗号化は見た目よりも難しい」、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] Stevens、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.、Guttman、E.、Perkins、C。およびS. Kaplan、「Service Location Protocol」、RFC 2165、1997年6月。
[SSM] Holbrook, H. and B. Cain, "Specific Multicast for IP", Work in Progress.
[SSM] Holbrook、H。およびB. Cain、「IP用の特定のマルチキャスト」、進行中の作業。
Bob Quinn Celox Networks 2 Park Central Drive Southborough, MA 01772
ボブ・クイン・セロックス・ネットワーク2パーク・セントラル・ドライブサウスボロー、マサチューセッツ州01772
Phone: +1 508 305 7000
EMail: bquinn@celoxnetworks.com
Kevin Almeroth Department of Computer Science University of California Santa Barbara, CA 93106-5110
カリフォルニア州カリフォルニア大学コンピュータサイエンス大学サンタバーバラ、カリフォルニア州93106-5110のケビンアルメロス局
Phone: +1 805 893 2777
EMail: almeroth@cs.ucsb.edu
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。