Network Working Group B. Whetten
Request for Comments: 3048 Talarian
Category: Informational L. Vicisano
Cisco
R. Kermode
Motorola
M. Handley
ACIRI 9
S. Floyd
ACIRI
M. Luby
Digital Fountain
January 2001
Network Working Group B. Whetten
Request for Comments: 3048 Talarian
Category: Informational L. Vicisano
Cisco
R. Kermode
Motorola
M. Handley
ACIRI 9
S. Floyd
ACIRI
M. Luby
Digital Fountain
January 2001
Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer
用于一对多批量数据传输的可靠多播传输构建块
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 a framework for the standardization of bulk-data reliable multicast transport. It builds upon the experience gained during the deployment of several classes of contemporary reliable multicast transport, and attempts to pull out the commonalities between these classes of protocols into a number of building blocks. To that end, this document recommends that certain components that are common to multiple protocol classes be standardized as "building blocks". The remaining parts of the protocols, consisting of highly protocol specific, tightly intertwined functions, shall be designated as "protocol cores". Thus, each protocol can then be constructed by merging a "protocol core" with a number of "building blocks" which can be re-used across multiple protocols.
本文档描述了批量数据可靠多播传输的标准化框架。它以部署几类当代可靠多播传输过程中获得的经验为基础，并试图将这几类协议之间的共性归纳为若干构建块。为此，本文件建议将多个协议类通用的某些组件标准化为“构建块”。协议的其余部分，由高度协议特定、紧密交织的功能组成，应指定为“协议核心”。因此，可以通过将“协议核心”与多个“构建块”合并来构建每个协议，这些“构建块”可以跨多个协议重用。
Table of Contents
目录
1 Introduction .................................................. 2
1.1 Protocol Families ........................................... 5
2 Building Blocks Rationale ..................................... 6
2.1 Building Blocks Advantages .................................. 6
2.2 Building Block Risks ........................................ 7
2.3 Building Block Requirements ................................. 8
3 Protocol Components ........................................... 8
3.1 Sub-Components Definition ................................... 9
4 Building Block Recommendations ................................ 12
4.1 NACK-based Reliability ...................................... 13
4.2 FEC coding .................................................. 13
4.3 Congestion Control .......................................... 13
4.4 Generic Router Support ...................................... 14
4.5 Tree Configuration .......................................... 14
4.6 Data Security ............................................... 15
4.7 Common Headers .............................................. 15
4.8 Protocol Cores .............................................. 15
5 Security ...................................................... 15
6 IANA Considerations ........................................... 15
7 Conclusions ................................................... 16
8 Acknowledgements .............................................. 16
9 References .................................................... 16
10 Authors' Addresses ........................................... 19
11 Full Copyright Statement ..................................... 20
1 Introduction .................................................. 2
1.1 Protocol Families ........................................... 5
2 Building Blocks Rationale ..................................... 6
2.1 Building Blocks Advantages .................................. 6
2.2 Building Block Risks ........................................ 7
2.3 Building Block Requirements ................................. 8
3 Protocol Components ........................................... 8
3.1 Sub-Components Definition ................................... 9
4 Building Block Recommendations ................................ 12
4.1 NACK-based Reliability ...................................... 13
4.2 FEC coding .................................................. 13
4.3 Congestion Control .......................................... 13
4.4 Generic Router Support ...................................... 14
4.5 Tree Configuration .......................................... 14
4.6 Data Security ............................................... 15
4.7 Common Headers .............................................. 15
4.8 Protocol Cores .............................................. 15
5 Security ...................................................... 15
6 IANA Considerations ........................................... 15
7 Conclusions ................................................... 16
8 Acknowledgements .............................................. 16
9 References .................................................... 16
10 Authors' Addresses ........................................... 19
11 Full Copyright Statement ..................................... 20
RFC 2357 lays out the requirements for reliable multicast protocols that are to be considered for standardization by the IETF. They include:
RFC 2357列出了IETF考虑标准化的可靠多播协议的要求。这些措施包括：
o Congestion Control. The protocol must be safe to deploy in the widespread Internet. Specifically, it must adhere to three mandates: a) it must achieve good throughput (i.e., it must not consistently overload links with excess data or repair traffic), b) it must achieve good link utilization, and c) it must not starve competing flows.
o 拥塞控制。该协议必须能够安全地部署在广泛分布的Internet上。具体地说，它必须遵守三项规定：a）必须实现良好的吞吐量（即，它不能始终使用过量的数据或修复流量使链路过载），b）必须实现良好的链路利用率，以及c）不能使竞争流挨饿。
o Scalability. The protocol should be able to work under a variety of conditions that include multiple network topologies, link speeds, and the receiver set size. It is more important to have a good understanding of how and when a protocol breaks than when it works.
o 可伸缩性。该协议应能在多种条件下工作，包括多种网络拓扑、链路速度和接收器集大小。更好地理解协议如何以及何时中断比协议何时工作更重要。
o Security. The protocol must be analyzed to show what is necessary to allow it to cope with security and privacy issues. This includes understanding the role of the protocol in data confidentiality and sender authentication, as well as how the protocol will provide defenses against denial of service attacks.
o 安全必须对协议进行分析，以显示允许它处理安全和隐私问题所需的内容。这包括了解该协议在数据保密性和发送方身份验证中的作用，以及该协议如何针对拒绝服务攻击提供防御。
These requirements are primarily directed towards making sure that any standards will be safe for widespread Internet deployment. The advancing maturity of current work on reliable multicast congestion control (RMCC) [HFW99] in the IRTF Reliable Multicast Research Group (RMRG) has been one of the events that has allowed the IETF to charter the RMT working group. RMCC only addresses a subset of the design space for reliable multicast. Fortuitously, the requirements it addresses are also the most pressing application and market requirements.
这些要求主要是为了确保任何标准对于广泛的互联网部署都是安全的。IRTF可靠多播研究小组（RMRG）目前关于可靠多播拥塞控制（RMCC）[HFW99]的工作日趋成熟，这是IETF得以组建RMT工作小组的事件之一。RMCC只处理可靠多播设计空间的一个子集。幸运的是，它解决的需求也是最紧迫的应用和市场需求。
A protocol's ability to meet the requirements of congestion control, scalability, and security is affected by a number of secondary requirements that are described in a separate document [RFC2887]. In summary, these are:
协议满足拥塞控制、可扩展性和安全性要求的能力受到单独文档[RFC2887]中描述的许多次要要求的影响。总之，这些是：
o Ordering Guarantees. A protocol must offer at least one of either source ordered or unordered delivery guarantees. Support for total ordering across multiple senders is not recommended, as it makes it more difficult to scale the protocol, and can more easily be implemented at a higher level.
o 订购保证。协议必须提供至少一种源有序或无序交付保证。不建议支持跨多个发送方的总排序，因为这会使协议更难扩展，并且更容易在更高级别上实现。
o Receiver Scalability. A protocol should be able to support a "large" number of simultaneous receivers per transport group. A typical receiver set could be on the order of at least 1,000 - 10,000 simultaneous receivers per group, or could even eventually scale up to millions of receivers in the large Internet.
o 接收器可伸缩性。协议应该能够支持每个传输组的“大量”同时接收器。一个典型的接收器集可以是每组至少1000-10000个同时接收器，或者甚至可以最终在大型互联网上扩展到数百万个接收器。
o Real-Time Feedback. Some versions of RMCC may require soft real-time feedback, so a protocol may provide some means for this information to be measured and returned to the sender. While this does not require that a protocol deliver data in soft real-time, it is an important application requirement that can be provided easily given real-time feedback.
o 实时反馈。RMCC的某些版本可能需要软实时反馈，因此协议可以提供一些方法来测量这些信息并将其返回给发送方。虽然这并不要求协议以软实时的方式交付数据，但这是一个重要的应用需求，可以轻松地提供实时反馈。
o Delivery Guarantees. In many applications, a logically defined unit or units of data is to be delivered to multiple clients, e.g., a file or a set of files, a software package, a stock quote or package of stock quotes, an event notification, a set of slides, a frame or block from a video. An application data unit is defined to be a logically separable unit of data that is useful to the application. In some cases, an application data unit may be short enough to fit into a single packet (e.g., an event
o 交货保证。在许多应用程序中，逻辑定义的一个或多个数据单元将被传送到多个客户端，例如，一个文件或一组文件、软件包、股票报价或股票报价包、事件通知、一组幻灯片、来自视频的帧或块。应用程序数据单元被定义为对应用程序有用的逻辑上可分离的数据单元。在某些情况下，应用数据单元可能短到足以装入单个数据包（例如，事件）
notification or a stock quote), whereas in other cases an application data unit may be much longer than a packet (e.g., a software package). A protocol must provide good throughput of application data units to receivers. This means that most data that is delivered to receivers is useful in recovering the application data unit that they are trying to receive. A protocol may optionally provide delivery confirmation, i.e., a mechanism for receivers to inform the sender when data has been delivered. There are two types of confirmation, at the application data unit level and at the packet level. Application data unit confirmation is useful at the application level, e.g., to inform the application about receiver progress and to decide when to stop sending packets about a particular application data unit. Packet confirmation is useful at the transport level, e.g., to inform the transport level when it can release buffer space being used for storing packets for which delivery has been confirmed. Packet level confirmation may also aid in application data unit confirmation.
通知或股票报价），而在其他情况下，应用程序数据单元可能比数据包（例如软件包）长得多。协议必须为接收器提供良好的应用程序数据单元吞吐量。这意味着，交付给接收器的大多数数据在恢复他们试图接收的应用程序数据单元时非常有用。协议可以可选地提供传递确认，即，接收方在数据已经传递时通知发送方的机制。有两种类型的确认，应用程序数据单元级别和数据包级别。应用程序数据单元确认在应用程序级别是有用的，例如，通知应用程序关于接收器的进度，并决定何时停止发送关于特定应用程序数据单元的分组。数据包确认在传输级别是有用的，例如，当传输级别可以释放用于存储已确认发送的数据包的缓冲空间时，通知传输级别。包级确认也可有助于应用数据单元确认。
o Network Topologies. A protocol must not break the network when deployed in the full Internet. However, we recognize that intranets will be where the first wave of deployments happen, and so are also very important to support. Thus, support for satellite networks (including those with terrestrial return paths or no return paths at all) is encouraged, but not required.
o 网络拓扑。协议在整个Internet中部署时不得中断网络。然而，我们认识到，内部网将是第一波部署的地方，因此支持内部网也是非常重要的。因此，支持卫星网络（包括那些有地面返回路径或根本没有返回路径的网络）是受鼓励的，但不是必需的。
o Group Membership. The group membership algorithms must be scalable. Membership can be anonymous (where the sender does not know the list of receivers), or fully distributed (where the sender receives a count of the number of receivers, and optionally a list of failures).
o 小组成员。组成员算法必须是可伸缩的。成员资格可以是匿名的（发送方不知道接收方列表），也可以是完全分布的（发送方接收接收方数量的计数，还可以是失败列表）。
o Example Applications. Some of the applications that a RM protocol could be designed to support include multimedia broadcasts, real time financial market data distribution, multicast file transfer, and server replication.
o 示例应用程序。RM协议可以支持的一些应用程序包括多媒体广播、实时金融市场数据分发、多播文件传输和服务器复制。
In the rest of this document the following terms will be used with a specific connotation: "protocol family", "protocol component", "building block", "protocol core", and "protocol instantiation". A "protocol family" is a broad class of RM protocols which share a common characteristic. In our classification, this characteristic is the mechanism used to achieve reliability. A "protocol component" is a logical part of the protocol that addresses a particular functionality. A "building block" is a constituent of a protocol that implements one, more than one or a part of a component. A "protocol core" is the set of functionality required for the
在本文件的其余部分中，将使用具有特定含义的以下术语：“协议族”、“协议组件”、“构建块”、“协议核心”和“协议实例化”。“协议族”是一类广泛的RM协议，它们具有共同的特征。在我们的分类中，该特征是用于实现可靠性的机制。“协议组件”是协议的逻辑部分，用于处理特定功能。“构建块”是实现组件的一个、多个或一部分的协议的组成部分。“协议核心”是协议所需的一组功能
instantiation of a complete protocol, that is not specified by any building block. Finally a "protocol instantiation" is an actual RM protocol defined in term of building blocks and a protocol core.
未由任何构建块指定的完整协议的实例化。最后，“协议实例化”是根据构建块和协议核心定义的实际RM协议。
The design-space document [RFC2887] also provides a taxonomy of the most popular approaches that have been proposed over the last ten years. After congestion control, the primary challenge has been that of meeting the requirement for ensuring good throughput in a way that scales to a large number of receivers. For protocols that include a back-channel for recovery of lost packets, the ability to take advantage of support of elements in the network has been found to be very beneficial for supporting good throughput for a large numbers of receivers. Other protocols have found it very beneficial to transmit coded data to achieve good throughput for large numbers of receivers.
设计空间文件[RFC2887]还提供了过去十年中提出的最流行方法的分类。在拥塞控制之后，主要的挑战是满足以可扩展到大量接收器的方式确保良好吞吐量的要求。对于包括用于恢复丢失分组的反向信道的协议，已经发现利用网络中元素的支持的能力对于支持大量接收机的良好吞吐量是非常有益的。其他协议发现，传输编码数据以实现大量接收机的良好吞吐量非常有益。
This taxonomy breaks proposed protocols into four families. Some protocols in the family provide packet level delivery confirmation that may be useful to the transport level. All protocols in all families can be supplemented with higher level protocols that provide delivery confirmation of application data units.
这种分类法将提议的协议分为四个家族。该系列中的一些协议提供可能对传输级别有用的数据包级别的传递确认。所有系列中的所有协议都可以使用更高级别的协议进行补充，以提供应用程序数据单元的交付确认。
1 NACK only. Protocols such as SRM [FJM95] and MDP2 [MA99] attempt to limit traffic by only using NACKs for requesting packet retransmission. They do not require network infrastructure.
1只NACK。SRM[FJM95]和MDP2[MA99]等协议试图通过仅使用NACK请求数据包重传来限制流量。它们不需要网络基础设施。
2 Tree based ACK. Protocols such as RMTP [LP96, PSLM97], RMTP-II [WBPM98] and TRAM [KCW98], use positive acknowledgments (ACKs). ACK based protocols reduce the need for supplementary protocols that provide delivery confirmation, as the ACKS can be used for this purpose. In order to avoid ACK implosion in scaled up deployments, the protocol can use servers placed in the network.
2基于树的ACK。诸如RMTP[LP96、PSLM97]、RMTP-II[WBPM98]和TRAM[KCW98]等协议使用肯定确认（ACKs）。基于ACK的协议减少了对提供交付确认的补充协议的需求，因为ACK可用于此目的。为了避免扩展部署中的ACK内爆，协议可以使用放置在网络中的服务器。
3 Asynchronous Layered Coding (ALC). These protocols (examples include [RV97] and [BLMR98]) use sender-based Forward Error Correction (FEC) methods with no feedback from receivers or the network to ensure good throughput. These protocols also used sender-based layered multicast and receiver-driven protocols to join and leave these layers with no feedback to the sender to achieve scalable congestion control.
3异步分层编码（ALC）。这些协议（示例包括[RV97]和[BLMR98]）使用基于发送方的前向纠错（FEC）方法，无需来自接收方或网络的反馈，以确保良好的吞吐量。这些协议还使用基于发送方的分层多播和接收方驱动的协议来加入和离开这些层，而不向发送方反馈，以实现可伸缩的拥塞控制。
4 Router assist. Like SRM, protocols such as PGM [FLST98] and [LG97] also use negative acknowledgments for packet recovery. These protocols take advantage of new router software to do constrained negative acknowledgments and retransmissions. Router assist protocols can also provide other functionality more efficiently than end to end protocols. For example, [LVS99] shows
4路由器辅助。与SRM一样，PGM[FLST98]和[LG97]等协议也使用否定确认进行数据包恢复。这些协议利用新的路由器软件进行受限的否定确认和重传。路由器辅助协议还可以比端到端协议更有效地提供其他功能。例如，[LVS99]显示
how router assist can provide fine grained congestion control for ALC protocols. Router assist protocols can be designed to complement all protocol families described above.
路由器辅助如何为ALC协议提供细粒度拥塞控制。路由器辅助协议可设计为补充上述所有协议系列。
Note that the distinction in protocol families in not necessarily precise and mutually exclusive. Actual protocols may use a combination of the mechanisms belonging to different classes. For example, hybrid NACK/ACK based protocols (such as [WBPM98]) are possible. Other examples are protocols belonging to class 1 through 3 that take advantage of router support.
请注意，协议族中的区别不一定精确且相互排斥。实际协议可能使用属于不同类别的机制的组合。例如，基于NACK/ACK的混合协议（例如[WBPM98]）是可能的。其他示例是属于类别1到类别3的协议，它们利用了路由器支持。
As specified in RFC 2357 [MRBP98], no single reliable multicast protocol will likely meet the needs of all applications. Therefore, the IETF expects to standardize a number of protocols that are tailored to application and network specific needs. This document concentrates on the requirements for "one-to-many bulk-data transfer", but in the future, additional protocols and building-blocks are expected that will address the needs of other types of applications, including "many-to- many" applications. Note that bulk-data transfer does not refer to the timeliness of the data, rather it states that there is a large amount of data to be transferred in a session. The scope and approach taken for the development of protocols for these additional scenarios will depend upon large part on the success of the "building-block" approach put forward in this document.
正如RFC 2357[MRBP98]中所规定的那样，没有一个可靠的多播协议可能满足所有应用程序的需求。因此，IETF希望标准化一系列根据应用和网络特定需求定制的协议。本文件集中于“一对多批量数据传输”的要求，但在未来，预计附加协议和构建块将满足其他类型应用的需求，包括“多对多”应用。请注意，批量数据传输并不是指数据的及时性，而是指在会话中要传输大量数据。为这些附加场景制定协议的范围和方法在很大程度上取决于本文件中提出的“构建块”方法的成功。
Building a large piece of software out of smaller modular components is a well understood technique of software engineering. Some of the advantages that can come from this include:
用较小的模块化组件构建大型软件是软件工程的一项广为理解的技术。由此带来的一些优势包括：
o Specification Reuse. Modules can be used in multiple protocols, which reduces the amount of development time required.
o 规范重用。模块可以在多个协议中使用，这减少了所需的开发时间。
o Reduced Complexity. To the extent that each module can be easily defined with a simple API, breaking a large protocol in to smaller pieces typically reduces the total complexity of the system.
o 降低了复杂性。在某种程度上，每个模块都可以用简单的API轻松定义，因此将大型协议分解为较小的部分通常可以降低系统的总体复杂性。
o Reduced Verification and Debugging Time. Reduced complexity results in reduced time to debug the modules. It is also usually faster to verify a set of smaller modules than a single larger module.
o 减少了验证和调试时间。降低复杂性可缩短调试模块的时间。验证一组较小的模块通常比验证单个较大的模块更快。
o Easier Future Upgrades. There is still ongoing research in reliable multicast, and we expect the state of the art to continue to evolve. Building protocols with smaller modules allows them to be more easily upgraded to reflect future research.
o 更容易的未来升级。可靠多播的研究仍在进行中，我们预计最新技术将继续发展。使用更小的模块构建协议可以更容易地升级，以反映未来的研究。
o Common Diagnostics. To the extent that multiple protocols share common packet headers, packet analyzers and other diagnostic tools can be built which work with multiple protocols.
o 常见诊断。在多个协议共享公共数据包头的情况下，可以构建使用多个协议的数据包分析器和其他诊断工具。
o Reduces Effort for New Protocols. As new application requirements drive the need for new standards, some existing modules may be reused in these protocols.
o 减少新协议的工作量。由于新的应用需求推动了对新标准的需求，一些现有模块可能会在这些协议中重用。
o Parallelism of Development. If the APIs are defined clearly, the development of each module can proceed in parallel.
o 发展的并行性。如果API定义明确，则每个模块的开发可以并行进行。
Like most software specification, this technique of breaking down a protocol in to smaller components also brings tradeoffs. After a certain point, the disadvantages outweigh the advantages, and it is not worthwhile to further subdivide a problem. These risks include:
与大多数软件规范一样，这种将协议分解为更小组件的技术也带来了权衡。在某一点之后，弊大于利，不值得进一步细分问题。这些风险包括：
o Delaying Development. Defining the API for how each two modules inter-operate takes time and effort. As the number of modules increases, the number of APIs can increase at more than a linear rate. The more tightly coupled and complex a component is, the more difficult it is to define a simple API, and the less opportunity there is for reuse. In particular, the problem of how to build and standardize fine grained building blocks for a transport protocol is a difficult one, and in some cases requires fundamental research.
o 拖延发展。定义两个模块如何相互操作的API需要时间和精力。随着模块数量的增加，API的数量可以以线性速率增加。组件的耦合越紧密、越复杂，定义简单的API就越困难，重用的机会就越少。特别是，如何为传输协议构建和标准化细粒度构建块是一个困难的问题，在某些情况下需要进行基础研究。
o Increased Complexity. If there are too many modules, the total complexity of the system actually increases, due to the preponderance of interfaces between modules.
o 增加了复杂性。如果模块太多，由于模块之间的接口占优势，系统的总体复杂性实际上会增加。
o Reduced Performance. Each extra API adds some level of processing overhead. If an API is inserted in to the "common case" of packet processing, this risks degrading total protocol performance.
o 性能降低。每个额外的API都会增加一定程度的处理开销。如果在数据包处理的“常见情况”中插入API，则可能会降低协议的总体性能。
o Abandoning Prior Work. The development of robust transport protocols is a long and time intensive process, which is heavily dependent on feedback from real deployments. A great deal of work has been done over the past five years on components of protocols such as RMTP-II, SRM, and PGM. Attempting to dramatically re-engineer these components risks losing the benefit of this prior work.
o 放弃先前的工作。健壮传输协议的开发是一个漫长而耗时的过程，在很大程度上依赖于实际部署的反馈。在过去的五年中，在RMTP-II、SRM和PGM等协议组件方面做了大量工作。试图大幅重新设计这些组件可能会失去先前工作的好处。
Given these tradeoffs, we propose that a building block must meet the following requirements:
考虑到这些权衡，我们建议构建块必须满足以下要求：
o Wide Applicability. In order to have confidence that the component can be reused, it should apply across multiple protocol families and allow for the component's evolution.
o 广泛适用性。为了确信组件可以重用，它应该跨多个协议族应用，并允许组件的演化。
o Simplicity. In order to have confidence that the specification of the component APIs will not dramatically slow down the standards process, APIs must be simple and straight forward to define. No new fundamental research should be done in defining these APIs.
o 简单为了确信组件API的规范不会显著降低标准过程的速度，API必须简单直接地定义。在定义这些API时，不应进行新的基础研究。
o Performance. To the extent possible, the building blocks should attempt to avoid breaking up the "fast track", or common case packet processing.
o 表演在可能的范围内，构建块应尽量避免打破“快车道”或常见情况下的数据包处理。
This section proposes a functional decomposition of RM bulk-data protocols from the perspective of the functional components provided to an application by a transport protocol. It also covers some components that while not necessarily part of the transport protocol, are directly impacted by the specific requirements of a reliable multicast transport. The next section then specifies recommended building blocks that can implement these components.
本节从传输协议提供给应用程序的功能组件的角度，提出RM批量数据协议的功能分解。它还涵盖了一些组件，这些组件虽然不一定是传输协议的一部分，但直接受到可靠多播传输的特定要求的影响。下一节将指定可以实现这些组件的推荐构建块。
Although this list tries to cover all the most common transport-related needs of one-to-many bulk-data transfer applications, new application requirements may arise during the process of standardization, hence this list must not be interpreted as a statement of what the transport layer should provide and what it should not. Nevertheless, it must be pointed out that some functional components have been deliberately omitted since they have been deemed irrelevant to the type of application considered (i.e., one-to-many bulk-data transfer). Among these are advanced message ordering (i.e., those which cannot be implemented through a simple sequence number) and atomic delivery.
尽管此列表试图涵盖一对多批量数据传输应用程序的所有最常见的传输相关需求，但在标准化过程中可能会出现新的应用程序需求，因此此列表不得解释为传输层应提供什么和不应提供什么的声明。然而，必须指出的是，一些功能组件被故意省略，因为它们被认为与所考虑的应用类型无关（即一对多批量数据传输）。其中包括高级消息排序（即无法通过简单序列号实现的消息排序）和原子传递。
It is also worth mentioning that some of the functional components listed below may be required by other functional components and not directly by the application (e.g., membership knowledge is usually required to implement ACK-based reliability).
还值得一提的是，下面列出的一些功能组件可能是其他功能组件所需要的，而不是应用程序直接需要的（例如，通常需要成员资格知识来实现基于ACK的可靠性）。
The following list covers various transport functional components and splits them in sub-components.
下表涵盖了各种运输功能组件，并将其拆分为子组件。
o Data Reliability (ensuring good throughput) | | - Loss Detection/Notification | - Loss Recovery | - Loss Protection
o 数据可靠性（确保良好的吞吐量）| |-丢失检测/通知|-丢失恢复|-丢失保护
o Congestion Control | | - Congestion Feedback | - Rate Regulation | - Receiver Controls
o 拥塞控制| |-拥塞反馈|-速率调节|-接收器控制
o Security
o 安全
o Group membership | | - Membership Notification | - Membership Management
o 组成员资格| |-成员资格通知|-成员资格管理
o Session Management | | - Group Membership Tracking | - Session Advertisement | - Session Start/Stop | - Session Configuration/Monitoring
o 会话管理| |-组成员身份跟踪|-会话播发|-会话开始/停止|-会话配置/监视
o Tree Configuration
o 树配置
Note that not all components are required by all protocols, depending upon the fully defined service that is being provided by the protocol. In particular, some minimal service models do not require many of these functions, including loss notification, loss recovery, and group membership.
请注意，并非所有协议都需要所有组件，这取决于协议提供的完全定义的服务。特别是，一些最小服务模型不需要这些功能中的许多功能，包括丢失通知、丢失恢复和组成员资格。
Loss Detection/Notification. This includes how missing packets are detected during transmission and how knowledge of these events are propagated to one or more agents which are designated to recover from the transmission error. This task raises major scalability issues and can lead to feedback implosion and poor throughput if not properly handled. Mechanisms based on TRACKs (tree-based positive acknowledgements) or NACKs (negative acknowledgements) are the most widely used to perform this function. Mechanisms based on a combination of TRACKs and NACKs are also possible.
损失检测/通知。这包括在传输过程中如何检测丢失的数据包，以及如何将这些事件的知识传播到指定从传输错误中恢复的一个或多个代理。此任务会引发重大的可伸缩性问题，如果处理不当，可能会导致反馈内爆和吞吐量降低。基于轨迹（基于树的肯定确认）或NACK（否定确认）的机制是执行此功能最广泛使用的机制。基于轨迹和NACK组合的机制也是可能的。
Loss Recovery. This function responds to loss notification events through the transmission of additional packets, either in the form of copies of those packets lost or in the form of FEC packets. The manner in which this function is implemented can significantly affect the scalability of a protocol.
损失恢复。此函数通过传输附加数据包（以丢失数据包的副本或FEC数据包的形式）来响应丢失通知事件。此功能的实现方式会显著影响协议的可伸缩性。
Loss Protection. This function attempts to mask packet-losses so that they don't become Loss Notification events. This function can be realized through the pro-active transmission of FEC packets. Each FEC packet is created from an entire application data unit [LMSSS97] or a portion of an application data unit [RV97], [BKKKLZ95], a fact that allows a receiver to recover from some packet loss without further retransmissions. The number of losses that can be recovered from without requiring retransmission depends on the amount of FEC packets sent in the first place. Loss protection can also be pushed to the extreme when good throughput is achieved without any Loss Detection/Notification and Loss Recovery functionality, as in the ALC family of protocols defined above.
损失保护。此函数尝试屏蔽数据包丢失，以便它们不会成为丢失通知事件。该功能可以通过FEC数据包的主动传输来实现。每个FEC分组是从整个应用数据单元[LMSSS97]或应用数据单元[RV97]、[BKKKLZ95]的一部分创建的，这一事实允许接收机从一些分组丢失中恢复，而无需进一步重传。无需重新传输即可恢复的丢失数量取决于首先发送的FEC数据包的数量。当在没有任何丢失检测/通知和丢失恢复功能的情况下实现良好吞吐量时，也可以将丢失保护推到极致，如上文定义的ALC协议系列中所述。
Congestion Feedback. For sender driven congestion control protocols, the receiver must provide some type of feedback on congestion to the sender. This typically involves loss rate and round trip time measurements.
拥塞反馈。对于发送方驱动的拥塞控制协议，接收方必须向发送方提供某种类型的拥塞反馈。这通常涉及损失率和往返时间测量。
Rate Regulation. Given the congestion feedback, the sender then must adjust its rate in a way that is fair to the network. One proposal that defines this notion of fairness and other congestion control requirements is [Whetten99].
利率调节。考虑到拥塞反馈，发送方必须以对网络公平的方式调整其速率。定义公平性概念和其他拥塞控制要求的一个建议是[Whetten99]。
Receiver Controls. In order to avoid allowing a receiver that has an extremely slow connection to the sender to stop all progress within single rate schemes, a congestion control algorithm will often require receivers to leave groups. For multiple rate approaches, receivers of all connection speeds can have data delivered to them according to the rate of their connection without slowing down other receivers.
接收器控制。为了避免让与发送方连接极慢的接收方停止单速率方案中的所有进程，拥塞控制算法通常要求接收方离开组。对于多速率方法，所有连接速度的接收器都可以根据其连接速率向其发送数据，而不会减慢其他接收器的速度。
Security. Security for reliable multicast contains a number of complex and tricky issues that stem in large part from the IP multicast service model. In this service model, hosts do not send traffic to another host, but instead elect to receive traffic from a multicast group. This means that any host may join a group and receive its traffic. Conversely, hosts may also leave a group at any time. Therefore, the protocol must address how it impacts the following security issues:
安全可靠多播的安全性包含许多复杂而棘手的问题，这些问题在很大程度上源于IP多播服务模型。在此服务模型中，主机不向另一台主机发送流量，而是选择从多播组接收流量。这意味着任何主机都可以加入组并接收其流量。相反，主机也可以随时离开组。因此，协议必须解决其如何影响以下安全问题：
o Sender Authentication (since any host can send to a group),
o 发送方身份验证（因为任何主机都可以发送到组），
o Data Encryption (since any host can join a group)
o 数据加密（因为任何主机都可以加入组）
o Transport Protection (denial of service attacks, through corruption of transport state, or requests for unauthorized resources)
o 传输保护（拒绝服务攻击、传输状态损坏或请求未经授权的资源）
o Group Key Management (since hosts may join and leave a group at any time) [WHA98]
o 组密钥管理（因为主机可以随时加入和离开组）[WHA98]
In particular, a transport protocol needs to pay particular attention to how it protects itself from denial of service attacks, through mechanisms such as lightweight authentication of control packets [HW99].
特别是，传输协议需要特别注意如何通过控制数据包的轻量级身份验证等机制保护自身免受拒绝服务攻击[HW99]。
With Source Specific Multicast service model (SSM), a host joins specifically to a sender and group pair. Thus, SSM offers more security against hosts receiving traffic from a denial of service attack where an arbitrary sender sends packets that hosts did not specifically request to receive. Nevertheless, it is recommended that additional protections against such attacks should be provided when using SSM, because the protection offered by SSM against such attacks may not be enough.
使用特定于源的多播服务模型（SSM），主机专门加入发送方和组对。因此，SSM为从拒绝服务攻击接收流量的主机提供了更高的安全性，在拒绝服务攻击中，任意发送方发送的数据包不是主机专门请求接收的。然而，建议在使用SSM时提供额外的攻击防护，因为SSM针对此类攻击提供的防护可能不够。
Sender Authentication, Data Encryption, and Group Key Management. While these functions are not typically part of the transport layer per se, a protocol needs to understand what ramifications it has on data security, and may need to have special interfaces to the security layer in order to accommodate these ramifications.
发件人身份验证、数据加密和组密钥管理。虽然这些功能通常不是传输层本身的一部分，但协议需要了解其对数据安全的影响，并且可能需要与安全层有特殊接口，以适应这些影响。
Transport Protection. The primary security task for a transport layer is that of protecting the transport layer itself from attack. The most important function for this is typically lightweight authentication of control packets in order to prevent corruption of state and other denial of service attacks.
运输保护。传输层的主要安全任务是保护传输层本身免受攻击。这方面最重要的功能通常是控制数据包的轻量级身份验证，以防止状态损坏和其他拒绝服务攻击。
Membership Notification. This is the function through which the data source--or upper level agent in a possible hierarchical organization--learns about the identity and/or number of receivers or lower level agents. To be scalable, this typically will not provide total knowledge of the identity of each receiver.
成员通知。这是数据源（或可能的分层组织中的上层代理）了解接收方或下层代理的身份和/或数量的功能。为了可伸缩，这通常不会提供每个接收器的身份的全部知识。
Membership Management. This implements the mechanisms for members to join and leave the group, to accept/refuse new members, or to terminate the membership of existing members.
会员管理。这实现了成员加入和离开组、接受/拒绝新成员或终止现有成员的成员资格的机制。
Group Membership Tracking. As an optional feature, a protocol may interface with a component which tracks the identity of each receiver in a large group. If so, this feature will typically be implemented out of band, and may be implemented by an upper level protocol. This may be useful for services that require tracking of usage of the system, billing, and usage reports.
组成员跟踪。作为可选功能，协议可以与跟踪大组中每个接收器的身份的组件接口。如果是这样，该特性通常将在带外实现，并且可以通过上层协议实现。这对于需要跟踪系统使用情况、计费和使用情况报告的服务可能很有用。
Session Advertisement. This publishes the session name/contents and the parameters needed for its reception. This function is usually performed by an upper layer protocol (e.g., [HPW99] and [HJ98]).
会议广告。这将发布会话名称/内容及其接收所需的参数。此功能通常由上层协议执行（例如，[HPW99]和[HJ98]）。
Session Start/Stop. These functions determine the start/stop time of sender and/or receivers. In many cases this is implicit or performed by an upper level application or protocol. In some protocols, however, this is a task best performed by the transport layer due to scalability requirements.
会话开始/停止。这些功能确定发送方和/或接收方的开始/停止时间。在许多情况下，这是隐式的，或者由上层应用程序或协议执行。然而，在某些协议中，由于可伸缩性要求，这是一项最好由传输层执行的任务。
Session Configuration/Monitoring. Due to the potentially far reaching scope of a multicast session, it is particularly important for a protocol to include tools for configuring and monitoring the protocol's operation.
会话配置/监视。由于多播会话的范围可能非常广泛，因此协议中包含用于配置和监视协议操作的工具尤为重要。
Tree Configuration. For protocols which include hierarchical elements (such as PGM and RMTP-II), it is important to configure these elements in a way that has approximate congruence with the multicast routing topology. While tree configuration could be included as part of the session configuration tools, it is clearly better if this configuration can be made automatic.
树配置。对于包含分层元素（如PGM和RMTP-II）的协议，必须以与多播路由拓扑大致一致的方式配置这些元素。虽然可以将树配置作为会话配置工具的一部分，但如果可以将此配置设置为自动，显然会更好。
The families of protocols introduced in section 1.1 generally use different mechanisms to implement the protocol functional components described in section 3. This section tries to group these mechanisms in macro components that define protocol building blocks.
第1.1节中介绍的协议系列通常使用不同的机制来实现第3节中描述的协议功能组件。本节尝试在定义协议构建块的宏组件中对这些机制进行分组。
A building block is defined as "a logical protocol component that results in explicit APIs for use by other building blocks or by the protocol client."
构建块被定义为“一个逻辑协议组件，它生成显式API供其他构建块或协议客户端使用。”
Building blocks are generally specified in terms of the set of algorithms and packet formats that implement protocol functional components. A building block may also have API's through which it communicates to applications and/or other building blocks. Most building blocks should also have a management API, through which it communicates to SNMP and/or other management protocols.
构建块通常根据实现协议功能组件的一组算法和数据包格式来指定。构建块还可以具有API，通过API与应用程序和/或其他构建块进行通信。大多数构建块还应该有一个管理API，通过它与SNMP和/或其他管理协议进行通信。
In the following section we will list a number of building blocks which, at this stage, seem to cover most of the functional components needed to implement the protocol families presented in section 1.1. Nevertheless this list represents the "best current guess", and as such it is not meant to be exhaustive. The actual building block decomposition, i.e., the division of functional components into building blocks, may also have to be revised in the future.
在下一节中，我们将列出一些构建块，在本阶段，这些构建块似乎涵盖了实现第1.1节中所述协议系列所需的大部分功能组件。然而，该列表代表了“当前最佳猜测”，因此并不意味着详尽无遗。实际的构建块分解，即将功能组件划分为构建块，也可能需要在将来进行修改。
This building block defines NACK-based loss detection/notification and recovery. The major issues it addresses are implosion prevention (suppression) and NACK semantics (i.e., how packets to be retransmitted should be specified, both in the case of selective and FEC loss repair). Suppression mechanisms to be considered are:
此构建块定义了基于NACK的丢失检测/通知和恢复。它解决的主要问题是内爆预防（抑制）和NACK语义（即，在选择性和FEC丢失修复的情况下，应如何指定要重新传输的数据包）。需要考虑的抑制机制包括：
o Multicast NACKs o Unicast NACKs and Multicast confirmation
o 多播nack o单播nack与多播确认
These suppression mechanisms primarily need to both minimize delay while also minimizing redundant messages. They may also need to have special weighting to work with Congestion Feedback.
这些抑制机制主要需要最小化延迟，同时最小化冗余消息。它们可能还需要有特殊的权重来处理拥塞反馈。
This building block is concerned with packet level FEC information when FEC codes are used either proactively or as repairs in reaction to lost packets. It specifies the FEC codec selection and the FEC packet naming (indexing) for both reactive FEC repair and pro-active FEC.
当FEC代码被主动使用或作为对丢失的数据包的修复时，此构建块与数据包级别的FEC信息有关。它为被动FEC修复和主动FEC指定FEC编解码器选择和FEC数据包命名（索引）。
There will likely be multiple versions of this building block, corresponding to different design policies in addressing congestion control. Two main approaches are considered for the time being: a source-based rate regulation with a single rate provided to all the receivers in the session, and a multiple rate receiver-driven approach with different receivers receiving at different rates in the same session. The multiple rate approach may use multiple layers of multicast traffic [VRC98] or router filtering of a single layer [LVS99]. The multiple rate approach is most applicable for ALC protocols.
该构建块可能有多个版本，对应于解决拥塞控制的不同设计策略。目前主要考虑两种方法：基于源的速率调节，向会话中的所有接收机提供单一速率；多速率接收机驱动的方法，不同接收机在同一会话中以不同速率接收。多速率方法可使用多层多播通信量[VRC98]或单层路由器过滤[LVS99]。多速率方法最适用于ALC协议。
Both approaches are still in the phase of study, however the first seems to be mature enough [HFW99] to allow the standardization process to begin.
这两种方法仍处于研究阶段，但第一种方法似乎已经足够成熟[HFW99]，可以开始标准化过程。
At the time of writing this document, a third class of congestion control algorithm based on router support is beginning to emerge in the IRTF RMRG [LVS99]. This work may lead to the future standardization of one or more additional building blocks for congestion control.
在撰写本文档时，基于路由器支持的第三类拥塞控制算法开始出现在IRTF RMRG[LVS99]中。这项工作可能会导致未来一个或多个用于拥塞控制的附加构件的标准化。
The task of designing RM protocols can be made much easier by the presence of some specific support in routers. In some application-specific cases, the increased benefits afforded by the addition of special router support can justify the resulting additional complexity and expense [FLST98].
由于路由器中存在一些特定的支持，设计RM协议的任务可以变得容易得多。在某些特定于应用的情况下，增加特殊路由器支持带来的好处可以证明由此产生的额外复杂性和费用是合理的[FLST98]。
Functional components which can take advantage of router support include feedback aggregation/suppression (both for loss notification and congestion control) and constrained retransmission of repair packets. Another component that can take advantage of router support is intentional packet filtering to provide different rates of delivery of packets to different receivers from the same multicast packet stream. This could be most advantageous when combined with ALC protocols [LVS99].
可利用路由器支持的功能组件包括反馈聚合/抑制（用于丢失通知和拥塞控制）和修复数据包的受限重传。可以利用路由器支持的另一个组件是有意的数据包过滤，以从同一多播数据包流向不同的接收器提供不同的数据包交付速率。当与ALC协议结合时，这可能是最有利的[LVS99]。
The process of designing and deploying these mechanisms inside routers can be much slower than the one required for end-host protocol mechanisms. Therefore, it would be highly advantageous to define these mechanisms in a generic way that multiple protocols can use if it is available, but do not necessarily need to depend on.
在路由器内设计和部署这些机制的过程可能比终端主机协议机制所需的过程慢得多。因此，以通用方式定义这些机制将是非常有利的，如果可用，多个协议可以使用这些机制，但不一定需要依赖这些机制。
This component has two halves, a signaling protocol and actual router algorithms. The signaling protocol allows the transport protocol to request from the router the functions that it wishes to perform, and the router algorithms actually perform these functions. It is more urgent to define the signaling protocol, since it will likely impact the common case protocol headers.
这个组件有两部分，一个信令协议和实际的路由器算法。信令协议允许传输协议向路由器请求它希望执行的功能，路由器算法实际执行这些功能。更迫切的是定义信令协议，因为它可能会影响常见情况下的协议头。
An important component of the signaling protocol is some level of commonality between the packet headers of multiple protocols, which allows the router to recognize and interpret the headers.
信令协议的一个重要组成部分是多个协议的数据包报头之间的某种程度的通用性，这允许路由器识别和解释报头。
It has been shown that the scalability of RM protocols can be greatly enhanced by the insertion of some kind of retransmission or feedback aggregation agents between the source and receivers. These agents are then used to form a tree with the source at (or near) the root, the receivers at the leaves of the tree, and the aggregation/local repair nodes in the middle. The internal nodes can either be dedicated software for this task, or they may be receivers that are performing dual duty.
研究表明，通过在源和接收器之间插入某种重传或反馈聚合代理，可以极大地提高RM协议的可扩展性。然后使用这些代理来形成树，树的根位于（或接近）根，树的叶子上的接收器，中间的聚集/局部修复节点。内部节点可以是该任务的专用软件，也可以是执行双重任务的接收器。
The effectiveness of these agents to assist in the delivery of data is highly dependent upon how well the logical tree they use to communicate matches the underlying routing topology. The purpose of
这些代理协助数据交付的有效性在很大程度上取决于它们用于通信的逻辑树与底层路由拓扑的匹配程度。目的
this building block would be to construct and manage the logical tree connecting the agents. Ideally, this building block would perform these functions in a manner that adapts to changes in session membership, routing topology, and network availability.
此构建块将用于构造和管理连接代理的逻辑树。理想情况下，此构建块将以适应会话成员资格、路由拓扑和网络可用性变化的方式执行这些功能。
At the time of writing, the security issues are the subject of research within the IRTF Secure Multicast Group (SMuG). Solutions for these requirements will be standardized within the IETF when ready.
在撰写本文时，安全问题是IRTF安全多播组（SMuG）研究的主题。这些需求的解决方案将在IETF中标准化。
As pointed out in the generic router support section, it is important to have some level of commonality across packet headers. It may also be useful to have common data header formats for other reasons. This building block would consist of recommendations on fields in their packet headers that protocols should make common across themselves.
正如通用路由器支持部分所指出的，在包头之间具有某种程度的通用性是很重要的。出于其他原因，使用通用数据头格式也可能很有用。这个构建块将包括对其数据包头中的字段的建议，这些字段的协议应该在它们之间通用。
The above building blocks consist of the functional components listed in section 3 that appear to meet the requirements for being implemented as building blocks presented in section 2.
上述构建块由第3节中列出的功能组件组成，这些组件似乎满足第2节中提出的作为构建块实施的要求。
The other functions from section 3, which are not covered above, should be implemented as part of "protocol cores", specific to each protocol standardized.
上文未涉及的第3节中的其他功能应作为“协议核心”的一部分实施，具体到每个标准化协议。
RFC 2357 specifically states that "reliable multicast Internet-Drafts reviewed by the Transport Area Directors must explicitly explore the security aspects of the proposed design." Specifically, RMT building block works in progress must examine the denial-of-service attacks that can be made upon building blocks and affected by building blocks upon the Internet at large. This requirement is in addition to any discussions regarding data-security, that is the manipulation of or exposure of session information to unauthorized receivers. Readers are referred to section 5.e of RFC 2357 for further details.
RFC 2357明确规定，“经运输区域主管审查的可靠多播互联网草案必须明确探讨拟议设计的安全方面。”具体而言，正在进行的RMT构建块工作必须检查在构建块上可能发生的拒绝服务攻击，以及在整个互联网上受构建块影响的拒绝服务攻击。此要求是对任何有关数据安全的讨论的补充，即对未经授权的接收者操纵或暴露会话信息。读者可参考RFC 2357第5.e节了解更多详情。
There will be more than one building block, and possibly multiple versions of individual building blocks as their designs are refined. For this reason, the creation of new building blocks and new building block versions will be administered via a building block registry
随着设计的完善，将有不止一个构建块，并且可能有多个版本的单个构建块。因此，新构建块和新构建块版本的创建将通过构建块注册表进行管理
that will be administered by IANA. Initially, this registry will be empty, since the building blocks described in sections 4.1 to 4.3 are presented for example and design purposes. The requested IANA building block registry will be populated from specifications as they are approved for RFC publication (using the "Specification Required" policy as described in RFC 2434 [RFC2434]). A registration will consist of a building block name, a version number, a brief text description, a specification RFC number, and a responsible person, to which IANA will assign the type number.
这将由IANA管理。最初，该注册表将为空，因为第4.1节至第4.3节中描述的构建块仅用于示例和设计目的。请求的IANA构建块注册表将根据批准用于RFC发布的规范进行填充（使用RFC 2434[RFC2434]中所述的“所需规范”策略）。注册将包括构建块名称、版本号、简要文本描述、规范RFC号和负责人，IANA将向其分配类型号。
In this document, we briefly described a number of building blocks that may be used for the generation of reliable multicast protocols to be used in the application space of one-to-many reliable bulk-data transfer. The list of building blocks presented was derived from considering the functions that a protocol in this space must perform and how these functions should be grouped. This list is not intended to be all-inclusive but instead to act as guide as to which building blocks are considered during the standardization process within the Reliable Multicast Transport WG.
在本文档中，我们简要描述了可用于生成可靠多播协议的若干构建块，这些协议将在一对多可靠批量数据传输的应用空间中使用。给出的构建块列表源于考虑此空间中的协议必须执行的功能以及这些功能应如何分组。此列表并不包含所有内容，而是作为可靠多播传输工作组标准化过程中考虑哪些构建块的指南。
This document represents an overview of a number of building blocks for one to many bulk data transfer that may be ready for standardization within the RMT working group. The ideas presented are not those of the authors, rather they are a summarization of many years of research into multicast transport combined with the varied presentations and discussions in the IRTF Reliable Multicast Research Group. Although they are too numerous to list here, we thank everyone who has participated in these discussions for their contributions.
本文件概述了一对多批量数据传输的若干构建块，这些构建块可能已准备好在RMT工作组内进行标准化。本文提出的观点并不是作者的观点，而是多年来对多播传输研究的总结，结合了IRTF可靠多播研究小组的各种陈述和讨论。虽然它们太多，无法在此列出，但我们感谢所有参与这些讨论的人所作的贡献。
[BKKKLZ95] J. Bloemer, M. Kalfane, M. Karpinski, R. Karp, M. Luby, D. Zuckerman, "An XOR-based Erasure Resilient Coding Scheme," ICSI Technical Report No. TR-95-048, August 1995.
[BKKLZ95]J.Bloemer，M.Kalfine，M.Karpinski，R.Karp，M.Luby，D.Zuckerman，“基于XOR的擦除弹性编码方案”，ICSI技术报告TR-95-048号，1995年8月。
[BLMR98] J. Byers, M. Luby, M. Mitzenmacher, A. Rege, "A Digital Fountain Approach to Reliable Distribution of Bulk Data," Proc ACM SIGCOMM 98.
[BLMR98]J.Byers，M.Luby，M.Mitzenmacher，A.Rege，“批量数据可靠分发的数字喷泉方法”，Proc ACM SIGCOMM 98。
[FJM95] S. Floyd, V. Jacobson, S. McCanne, "A Reliable Multicast Framework for Light-weight Sessions and Application Level Framing," Proc ACM SIGCOMM 95, Aug 1995 pp. 342-356.
[FJM95]S.Floyd，V.Jacobson，S.McCanne，“用于轻量级会话和应用程序级帧的可靠多播框架”，Proc ACM SIGCOMM 95，1995年8月，第342-356页。
[FLST98] D. Farinacci, S. Lin, T. Speakman, and A. Tweedly, "PGM reliable transport protocol specification," Work in Progress.
[FLST98]D.Farinaci，S.Lin，T.Speakman和A.Tweedly，“PGM可靠传输协议规范”，正在进行中。
[HFW99] M. Handley, S. Floyd, B. Whetten, "Strawman Specification for TCP Friendly (Reliable) Multicast Congestion Control (TFMCC)," Work in Progress.
[HFW99]M.Handley，S.Floyd，B.Whetten，“TCP友好（可靠）多播拥塞控制（TFMCC）的斯特劳曼规范”，正在进行的工作。
[HJ98] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[HJ98]Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[HPW99] M. Handley, C. Perkins, E. Whelan, "Session Announcement Protocol," Work in Progress, June 1999.
[HPW99]M.Handley，C.Perkins，E.Whelan，“会议公告协议”，正在进行的工作，1999年6月。
[HW99] T. Hardjorno, B. Whetten, "Security Requirements for RMTP-II," Work in Progress, June 1999.
[HW99]T.Hardjorno，B.Whetten，“RMTP-II的安全要求”，在建工程，1999年6月。
[RFC2887] Handley, M., Whetten, B., Kermode, R., Floyd, S., Vicisano, L. and M. Luby, "The Reliable Multicast Design Space for Bulk Data Transfer", RFC 2887, August 2000.
[RFC2887]Handley，M.，Whetten，B.，Kermode，R.，Floyd，S.，Vicisano，L.和M.Luby，“批量数据传输的可靠多播设计空间”，RFC 2887，2000年8月。
[KCW98] M. Kadansky, D. Chiu, and J. Wesley, "Tree-based reliable multicast (TRAM)," Work in Progress.
[KCW98]M.Kadansky，D.Chiu和J.Wesley，“基于树的可靠多播（TRAM）”，正在进行中。
[Kermode98] R. Kermode, "Scoped Hybrid Automatic Repeat Request with Forward Error Correction," Proc ACM SIGCOMM 98, Sept 1998.
[Kermode98]R.Kermode，“带前向纠错的作用域混合自动重复请求”，Proc ACM SIGCOMM 981998年9月。
[LDW98] M. Lucas, B. Dempsey, A. Weaver, "MESH: Distributed Error Recovery for Multimedia Streams in Wide-Area Multicast Networks".
[LDW98]M.Lucas，B.Dempsey，A.Weaver，“网格：广域多播网络中多媒体流的分布式错误恢复”。
[LESZ97] C-G. Liu, D. Estrin, S. Shenkar, L. Zhang, "Local Error Recovery in SRM: Comparison of Two Approaches," USC Technical Report 97-648, Jan 1997.
[LESZ97]刘志光，D.Estrin，S.Shenkar，L.Zhang，“SRM中的局部错误恢复：两种方法的比较”，USC技术报告97-648，1997年1月。
[LG97] B.N. Levine, J.J. Garcua-Luna-Aceves, "Improving Internet Multicast Routing with Routing Labels," IEEE International Conference on Network Protocols (ICNP-97), Oct 28-31, 1997, p.241-250.
[LG97]B.N.Levine，J.J.Garcua Luna Aceves，“使用路由标签改进Internet多播路由”，IEEE国际网络协议会议（ICNP-97），1997年10月28-31日，第241-250页。
[LP96] K. Lin and S. Paul. "RMTP: A Reliable Multicast Transport Protocol," IEEE INFOCOMM 1996, March 1996, pp. 1414-1424.
[LP96]K.Lin和S.Paul。“RMTP：一种可靠的多播传输协议”，IEEE INFOCOMM 1996，1996年3月，第1414-1424页。
[LMSSS97] M. Luby, M. Mitzenmacher, A. Shokrollahi, D. Spielman, V. Stemann, "Practical Loss-Resilient Codes", Proc ACM Symposium on Theory of Computing, 1997.
[LMSSS97]M.Luby，M.Mitzenmacher，A.Shokrollahi，D.Spielman，V.Stemann，“实用的抗损失代码”，Proc ACM计算理论研讨会，1997年。
[LVS99] M. Luby, L. Vicisano, T. Speakman. "Heterogeneous multicast congestion control based on router packet filtering", RMT working group, June 1999, Pisa, Italy.
[LVS99]M.Luby，L.Vicisano，T.Speakman。“基于路由器包过滤的异构多播拥塞控制”，RMT工作组，1999年6月，意大利Pisa。
[MA99] J. Macker, B. Adamson. "Multicast Dissemination Protocol version 2 (MDPv2)," Work in Progress, http://manimac.itd.nrl.navy.mil/MDP
[MA99]J.Macker，B.Adamson。“多播传播协议版本2（MDPv2）”，正在进行中，http://manimac.itd.nrl.navy.mil/MDP
[MRBP98] Mankin, A., Romanow, A., Brander, S. and V.Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
[MRBP98]Mankin，A.，Romanow，A.，Brander，S.和V.Paxson，“评估可靠多播传输和应用协议的IETF标准”，RFC 2357，1998年6月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[OXB99] O. Ozkasap, Z. Xiao, K. Birman. "Scalability of Two Reliable Multicast Protocols", Work in Progress, May 1999.
[OXB99]O.Ozkasap，Z.Xiao，K.Birman。“两个可靠多播协议的可扩展性”，正在进行的工作，1999年5月。
[PSLB97] "Reliable Multicast Transport Protocol (RMTP)," S. Paul, K. K. Sabnani, J. C. Lin, and S. Bhattacharyya, IEEE Journal on Selected Areas in Communications, Vol. 15, No. 3, April 1997.
[PSLB97]“可靠多播传输协议（RMTP）”，S.Paul，K.K.Sabnani，J.C.Lin和S.Bhattacharyya，IEEE通信选定领域杂志，第15卷，第3期，1997年4月。
[RV97] L. Rizzo, L. Vicisano, "A Reliable Multicast Data Distribution Protocol Based on Software FEC Techniques," Proc. of The Fourth IEEE Workshop on the Architecture and Implementation of High Performance Communication Systems (HPCS'97), Sani Beach, Chalkidiki, Greece June 23-25, 1997.
[RV97]L.Rizzo，L.Vicisano，“基于软件FEC技术的可靠多播数据分发协议”，Proc。第四届IEEE高性能通信系统体系结构和实施研讨会（HPCS'97），1997年6月23日至25日，希腊Chalkidiki萨尼海滩。
[VRC98] L. Vicisano, L. Rizzo, J. Crowcroft, "TCP-Like Congestion Control for Layered Multicast Data Transfer", Proc. of IEEE Infocom'98, March 1998.
[VRC98]L.Vicisano，L.Rizzo，J.Crowcroft，“分层多播数据传输的类TCP拥塞控制”，Proc。IEEE Infocom'98，1998年3月。
[WBPM98] B. Whetten, M. Basavaiah, S. Paul, T. Montgomery, N. Rastogi, J. Conlan, and T. Yeh, "THE RMTP-II PROTOCOL," Work in Progress.
[WBPM98]B.Whetten、M.Basavaih、S.Paul、T.Montgomery、N.Rastogi、J.Conlan和T.Yeh，“RMTP-II协议”，正在进行中。
[WHA98] D. Wallner, E. Hardler, R. Agee, "Key Management for Multicast: Issues and Architectures," Work in Progress.
[WHA98]D.Wallner，E.Hardler，R.Agee，“多播的密钥管理：问题和体系结构”，正在进行中。
[Whetten99] B. Whetten, "A Proposal for Reliable Multicast
Congestion Control Requirements," Work in Progress.
http://www.talarian.com/rmtp-ii/overview.htm
[Whetten99] B. Whetten, "A Proposal for Reliable Multicast
Congestion Control Requirements," Work in Progress.
http://www.talarian.com/rmtp-ii/overview.htm
Brian Whetten Talarian Corporation, 333 Distel Circle, Los Altos, CA 94022, USA
Brian Whetten Talarian公司，美国加利福尼亚州洛斯阿尔托斯市Distel Circle 333号，邮编94022
EMail: whetten@talarian.com
EMail: whetten@talarian.com
Lorenzo Vicisano Cisco Systems, 170 West Tasman Dr. San Jose, CA 95134, USA
Lorenzo Vicisano Cisco Systems，170 West Tasman Dr.San Jose，CA 95134，美国
EMail: lorenzo@cisco.com
EMail: lorenzo@cisco.com
Roger Kermode Motorola Australian Research Centre Level 3, 12 Lord St, Botany NSW 2019, Australia
Roger Kermode摩托罗拉澳大利亚研究中心3楼，地址：澳大利亚新南威尔士州植物学街12号，邮编：2019
EMail: Roger.Kermode@motorola.com
EMail: Roger.Kermode@motorola.com
Mark Handley, Sally Floyd ATT Center for Internet Research at ICSI, International Computer Science Institute, 1947 Center Street, Suite 600, Berkeley, CA 94704, USA
MarkHandley，Sally Floyd ATT互联网研究中心，ICSI，国际计算机科学研究所，1947年，美国加利福尼亚州伯克利中心街600号，邮编94704
EMail: mjh@aciri.org, floyd@aciri.org
EMail: mjh@aciri.org, floyd@aciri.org
Michael Luby 600 Alabama Street San Francisco, CA 94110 Digital Fountain, Inc.
Michael Luby 600阿拉巴马街旧金山，CA 94110数码喷泉，Inc.。
EMail: luby@digitalfountain.com
EMail: luby@digitalfountain.com
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编辑功能的资金目前由互联网协会提供。