Network Working Group B. Quinn
Request for Comments: 3170 Celox Networks
Category: Informational K. Almeroth
UC-Santa Barbara
September 2001
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.
版权所有（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
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
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.
开发支持多播的应用程序表面上很简单。数据报访问允许任何应用程序发送到多播地址。多播应用程序只需将Internet协议（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.
然而，这种明显的简单性是有欺骗性的。在能够在异构网络上良好扩展的应用程序和协议中实现多播支持是一个重大挑战。具体而言，发送恒定比特率数据流、可靠的数据传输、安全性和管理多对多通信都需要特别考虑。有些解决方案是可用的，但其中许多服务仍然是活跃的研究领域。
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
本文档的目的是提供一个框架，用于理解设计和实现多播应用程序所面临的挑战。为了正确使用多播通信，应用程序开发人员必须首先了解所需的各种I/O模型和网络服务（以及基本多播通信）。第二，应用程序开发人员
need to be aware of efforts underway to provide these services. Such efforts range in maturity from deployed commercial products to basic research efforts to evaluate feasibility.
需要了解为提供这些服务正在进行的努力。这些工作的成熟程度从部署的商业产品到评估可行性的基础研究工作不等。
Multicast-based applications and services will play an important role in the future of the Internet as continued multicast deployment encourages their use and development. It is important that developers be aware of the issues and solutions available--and especially of their limitations--in order to avoid protocols that negatively impact networks (thereby counter-acting the benefits of multicast) or wasting their efforts "re-inventing the wheel".
基于多播的应用和服务将在互联网的未来发挥重要作用，因为持续的多播部署鼓励了它们的使用和发展。开发人员必须了解可用的问题和解决方案，特别是它们的局限性，以避免协议对网络产生负面影响（从而抵消多播的好处），或浪费他们的精力“重新发明轮子”。
The hope is that by raising developers' awareness, we can adjust their expectations of finding solutions and lead them to successful, scalable, and "network-friendly" development efforts.
希望通过提高开发人员的意识，我们可以调整他们寻找解决方案的期望，并引导他们进行成功、可扩展和“网络友好”的开发工作。
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，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多播的网络”、多播基础设施和基本多播服务。接下来，我们将描述多播应用程序可以启用的新功能的类型及其需求。然后，我们检查满足这些需求的服务、它们所面临的挑战，并简要介绍可用或正在开发的解决方案。最后，我们讨论了多播服务的应用程序编程接口（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.
有两种支持多播的网络可用。第一种是基于RFC 1112[Deering]中定义的原始多播服务模型。在这个模型中，接收者只是加入组，不需要知道源的身份。该模型有许多名称，包括Internet标准多播（ISM）、Internet传统多播（ITM）、Deering多播等。第二种多播修改了原始服务模型，除了知道组地址外，接收方还必须知道相关源的集合。这种类型的多播称为源特定多播（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多播，而且许多企业网络（内部网）也启用了IP多播，因此这一观点在今天是相关的。
An IP multicast enabled network requires two essential protocol components:
启用IP多播的网络需要两个基本的协议组件：
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:
理想情况下，这些协议组件对多播应用程序是透明的。但是，它们的功能需求有两个方面值得特别提及，因为它们会影响应用程序性能和设计。以下是多播应用程序的要求：
- 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.
快速离开阶段对于有效的拥塞控制机制、快速停止不需要的流以及对于整个网络来说都是非常理想的，以便更好地过滤不需要的流量[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多播的网络，一些独特而强大的应用程序和应用程序服务成为可能。“多播支持协调-它非常适合松散耦合的分布式系统（人员、服务器、数据库、进程、设备……）”[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多播地址接收的任何应用程序。正如我们后面所描述的，这些可能也可能不引用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多播应用程序与一对一单播应用程序的区别在于多播启用的其他发送方和接收方关系。多播应用程序一般分为三类：
One-to-Many (1toM): A single host sending to two or more (n) receivers
一对多（1toM）：一台主机发送到两个或多个（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 |
+-------+---+-----------+-----------------------------------+
+-----------------------------------+
| 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"
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）。例如，Mto1类别指IP级别关系的几种可能组合，包括单播。我们创建了Mto1类别，以帮助区分使用多播的许多应用程序和服务。
1toM: MtoM: Mto1:
R1 S1/R1 S1
/ / | \ \
S-R2 S2/R2-+-S3/R3 S2-R
\... \ | / .../
Rn Sn/Rn Sn
1toM: MtoM: Mto1:
R1 S1/R1 S1
/ / | \ \
S-R2 S2/R2-+-S3/R3 S2-R
\... \ | / .../
Rn Sn/Rn Sn
Legend: S: "Sender"
------ R: "Receiver"
Legend: S: "Sender"
------ R: "Receiver"
Figure 1: Generalization of the three application categories
图1：三个应用程序类别的概括
Figure 1 illustrates the general model for each of the three multicast application categories. Again it is worth emphasizing that Mto1 is an artificial category defined by the application-level
图1展示了三个多播应用程序类别中每一个的通用模型。同样值得强调的是，Mto1是由应用程序级别定义的人工类别
relationship between sender(s) and receiver. At the IP-level, multicast does not provide an Mto1 I/O mechanism, since it does not allow senders to limit receivers, nor even know who they are. Receiver information and limitations are enabled at the application level, as required by the multicast application.
发送方和接收方之间的关系。在IP级别，多播不提供Mto1 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.
我们将更详细地描述每种通用应用程序类型，并在下面的小节中提供每种类型的应用程序示例。示例列表并不全面，但试图在三个一般类别中分别定义突出的多播应用程序和服务类型。我们在本文档的其余部分中引用了这些列表中的项目，因为我们描述了它们的特定服务需求，定义了它们所面临的挑战，并参考了可用或正在开发的解决方案。
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) 预定音频/视频（a/v）分发：讲座、演示、会议或任何其他类型的预定活动，其多媒体覆盖可使观众受益（即电视和广播“广播”）。一个或多个恒定比特率（CBR）数据流和相对较高的带宽需求是这些应用的特点。当存在多个数据流时（如音频/视频组合），这两个数据流是同步的，其中一个数据流的优先级通常高于另一个数据流。例如，在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) 文件分发和缓存：发送到分布式最终用户或复制/缓存站点的网站内容、可执行二进制文件和其他基于文件的更新
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）应用中，两个或多个接收器也充当发送器。换句话说，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) 远程学习：这是一个一对多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显示，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)
<----------- -----------> <----------
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应用程序设计，还没有标准，但是有许多可能性考虑[HNR]。由于在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多播来启用类似“主机选播服务”的功能[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
p) 数据收集：这与前面描述的一对多“监控”应用程序相反。在这种情况下，可能有任意数量的分布式“传感器”向数据采集主机发送数据。传感器可能会根据数据采集器的请求发送更新，或者
continuously at regular intervals, or send spontaneously when a pre-defined event occurs. Bandwidth demands can vary based on sample frequency and resolution.
定期连续发送，或在预定义事件发生时自动发送。带宽需求可能因采样频率和分辨率而异。
This is illustrated in Table 1 by entries A1 and A3, the only difference being that A3 has a loopback interface. In Figure 2, this is possibility number 1. Since the number of receivers can easily be more than one, this is really an MtoM application.
表1中的条目A1和A3说明了这一点，唯一的区别是A3有一个环回接口。在图2中，这是可能性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) 自动存储塔：允许近按需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) 会计：这基本上是数据收集，但值得分离，因为它是如此重要的应用程序。在一些多播应用中，必须了解每个接收器的信息，可能是实时的。但这样的信息可能是压倒性的。当前的机制，如RTCP（实际上是MtoM，因为它是多播的，但可以成为Mto1），使用缩放技术，但要权衡信息粒度。随着一个组的增长，反馈的总量是恒定的，但每个接收器发送的反馈更少。
Some multicast application service requirements are common to unicast network applications as well. We characterize two of them here-- bandwidth and delay requirements.
一些多播应用程序服务需求对于单播网络应用程序也是通用的。我们在这里描述了其中的两个特性——带宽和延迟需求。
Figure 3 shows multicast applications approximate bandwidth requirements.
图3显示了多播应用程序的大致带宽需求。
Unicast and multicast applications both need to design applications to adapt to the variability of network conditions. But as we describe in section 5.3, it is the need to accommodate multiple heterogeneous multicast receivers--with their diversity of bandwidth capacity and delivery delays--that presents the unique challenge for multicast applications to satisfy these requirements.
单播和多播应用程序都需要设计应用程序以适应网络条件的变化。但是，正如我们在第5.3节中所描述的，适应多个异构多播接收器的需求——其带宽容量和交付延迟的多样性——为多播应用程序提供了满足这些需求的独特挑战。
|
1toM | b, d c, e a
|
MtoM | k g, i f, h, j, l, m, n
|
Mto1 | o, q, r p, t s
|
+-----------------------------------------------
Low Bandwidth High Bandwidth
|
1toM | b, d c, e a
|
MtoM | k g, i f, h, j, l, m, n
|
Mto1 | o, q, r p, t s
|
+-----------------------------------------------
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.
除了那些具有时间敏感数据（例如股票价格和实时监控信息）的应用程序外，大多数一对多应用程序对延迟和延迟变化（抖动）有很高的容忍度。恒定比特率（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.
大多数多对一和多对多组播应用程序都不能容忍延迟，因为它们是双向的、交互的和依赖于请求/响应的。因此，延迟应该最小化，因为它们会对应用程序的可用性产生负面影响。
This need to minimize delays is most evident in (two-way) conference applications, where users cannot converse effectively if the audio or video is delayed more than 500 milliseconds. For this and other
这种最小化延迟的需求在（双向）会议应用中最为明显，在这种应用中，如果音频或视频延迟超过500毫秒，用户将无法进行有效对话。为了这个和那个
examples see Figure 4, which plots multicast applications on a (coarse) scale of sensitivity to delivery delays.
示例请参见图4，它以对交付延迟敏感的（粗略）尺度绘制了多播应用程序。
|
1toM | b, c a, d e
|
MtoM | g, i, j, k f, h, l, m, n
|
Mto1 | r o, p, s, t q
|
+-----------------------------------------------
Delay Tolerant Delay Intolerant
|
1toM | b, c a, d e
|
MtoM | g, i, j, k f, h, l, m, n
|
Mto1 | r o, p, s, t q
|
+-----------------------------------------------
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.
前面描述的三个应用程序类别本质上是非常通用的。在每个类别中，甚至在每个应用程序类型中，特定的应用程序实例都有各种应用程序需求。一对多应用程序类型的开发相对简单，但正如我们所指出的，开发多对一和多对多应用程序存在挑战。其中一些具有带宽和延迟要求，类似于单播应用。
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 |
+----------------------------------------++--------------------+
+--------------------------------------------------------------+
| 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
|
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.
结束交付。所有其他服务都是必须由每个特定应用程序提供的应用程序层服务。此外，在大多数情况下，对于如何提供这些功能没有明确的标准。特定的功能取决于应用程序的特定需求，没有一种方法（或标准）可以满足所有情况。
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.
关于会话广告，有许多用于广告会话的机制。一种常用的技术是通过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.
当两台主机通过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）不像TCP那样启用接收器反馈循环，因为UDP不提供可靠的数据传递服务。因此，它也不像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).
- 降低一个数据流的发送速率，以利于另一个优先级更高的数据流（例如，牺牲视频以确保音频传输）。
- 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".
然而，对于具有多个接收器的多播应用程序（一对多或多对多），反馈环路设计需要修改。如果所有接收者同时返回数据丢失报告，那么发送者很容易在回复风暴中不知所措。这就是所谓的“内爆问题”。
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:
存在处理这些异构接收器问题的策略。以下是两个例子：
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
|
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].
目前的共识是，由于多种多样的多播应用程序需求——其中一些需求存在分歧——没有一种单一的多播传输可能适用于所有应用程序。因此，大多数人相信，我们最终将标准化一些可靠的多播协议，而不是单一的[批量，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%的风险接受度……强大的加密技术可以在一定程度上抵御有针对性的攻击——在这一点上，以其他方式获取信息变得更加容易……一个好的设计从一个威胁模型开始：系统旨在保护什么，保护谁，保护多长时间。”[Schneier]
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]。
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.
这是指让所有接收器同时播放他们接收的多播数据。这可能是为了公平——为拍卖或股票价格播放价格——或确保与其他接收者同步（如播放音乐时）所必需的。
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.
其中第三项是目前最难实现的。硬件和驱动程序不提供任何检索此信息的机制，尽管不同的音频和视频设备具有广泛的性能。
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.
[选播]帕特里奇，C.，门德斯，T.和W.米利肯，“主持选播服务”，RFC 15461993年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多播网络，第一卷”，（c）2000年思科出版社，印第安纳波利斯，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.
[批量]Whetten，B.，Vicisano，L.，Kermode，R.，Handley，M.，Floyd，S.和M.Luby，“一对多批量数据传输的可靠多播传输构建块”，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，“区分服务网络上的综合业务运营”，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.
[Finlayson]Finlayson，R.，“IP多播和防火墙”，RFC2581999年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和M.Ammar，“交互式多媒体光盘机（IMJ）：按需提供音频/视频的新范例”，第七届国际万维网会议记录，澳大利亚布里斯班，1998年4月。
[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多播作用域嵌套状态选项”，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 27292999年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.和D.Thaler，“多播地址集声明（MASC）协议”，RFC 29092000年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年新泽西州上鞍河普伦蒂斯大厅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，阅读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）”，RFC2730，1999年12月。
[MRM] K. Sarac, K. Almeroth, "Supporting Multicast Deployment Efforts: A Survey of Tools for Multicast Monitoring", Journal of High Speed Networking--Special Issue on Management of Multimedia Networking, March 2001
[MRM]K.Sarac，K.Almeroth，“支持多播部署工作：多播监控工具的调查”，《高速网络杂志——多媒体网络管理专刊》，2001年3月
[MSec] Multicast Security (msec) IETF Working Group charter
[MSec]多播安全（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 27762000年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
[Rizzo] L. Rizzo, "Fast Group management in IGMP", HIPPARC 98
workshop, June 1998, 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.，“RSVP与IETF综合服务的使用”，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 Specification,"
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.和E.Whelan，“会话公告协议”，RFC 29742000年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, "Why Cryptography Is Harder Than It Looks",
December 1996, 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，“服务位置协议”，RFC 21651997年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号Bob Quinn Celox Networks邮编01772
Phone: +1 508 305 7000
EMail: bquinn@celoxnetworks.com
Phone: +1 508 305 7000
EMail: bquinn@celoxnetworks.com
Kevin Almeroth Department of Computer Science University of California Santa Barbara, CA 93106-5110
凯文，加利福尼亚大学计算机科学系，圣塔巴巴拉，CA 93106—51
Phone: +1 805 893 2777
EMail: almeroth@cs.ucsb.edu
Phone: +1 805 893 2777
EMail: 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编辑功能的资金目前由互联网协会提供。