Internet Engineering Task Force (IETF) M. Luby
Request for Comments: 5775 M. Watson
Obsoletes: 3450 L. Vicisano
Category: Standards Track Qualcomm, Inc.
ISSN: 2070-1721 April 2010
Internet Engineering Task Force (IETF) M. Luby
Request for Comments: 5775 M. Watson
Obsoletes: 3450 L. Vicisano
Category: Standards Track Qualcomm, Inc.
ISSN: 2070-1721 April 2010
Asynchronous Layered Coding (ALC) Protocol Instantiation
异步分层编码（ALC）协议实例化
Abstract
摘要
This document describes the Asynchronous Layered Coding (ALC) protocol, a massively scalable reliable content delivery protocol. Asynchronous Layered Coding combines the Layered Coding Transport (LCT) building block, a multiple rate congestion control building block and the Forward Error Correction (FEC) building block to provide congestion controlled reliable asynchronous delivery of content to an unlimited number of concurrent receivers from a single sender. This document obsoletes RFC 3450.
本文档描述了异步分层编码（ALC）协议，这是一种可大规模扩展的可靠内容交付协议。异步分层编码结合了分层编码传输（LCT）构建块、多速率拥塞控制构建块和前向纠错（FEC）构建块，以从单个发送方向无限多个并发接收方提供拥塞控制的可靠异步内容交付。本文件淘汰RFC 3450。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5775.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5775.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Delivery Service Models . . . . . . . . . . . . . . . . . 4
1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Environmental Requirements and Considerations . . . . . . 5
2. Architecture Definition . . . . . . . . . . . . . . . . . . . 5
2.1. LCT Building Block . . . . . . . . . . . . . . . . . . . . 7
2.2. Multiple Rate Congestion Control Building Block . . . . . 9
2.3. FEC Building Block . . . . . . . . . . . . . . . . . . . . 10
2.4. Session Description . . . . . . . . . . . . . . . . . . . 11
2.5. Packet Authentication Building Block . . . . . . . . . . . 12
3. Conformance Statement . . . . . . . . . . . . . . . . . . . . 12
4. Functionality Definition . . . . . . . . . . . . . . . . . . . 13
4.1. Packet Format Used by ALC . . . . . . . . . . . . . . . . 13
4.2. LCT Header Extension Fields . . . . . . . . . . . . . . . 14
4.3. Sender Operation . . . . . . . . . . . . . . . . . . . . . 15
4.4. Receiver Operation . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
5.1. Baseline Secure ALC Operation . . . . . . . . . . . . . . 18
5.1.1. IPsec Approach . . . . . . . . . . . . . . . . . . . . 18
5.1.2. IPsec Requirements . . . . . . . . . . . . . . . . . . 19
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
8. Changes from RFC 3450 . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . . 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Delivery Service Models . . . . . . . . . . . . . . . . . 4
1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Environmental Requirements and Considerations . . . . . . 5
2. Architecture Definition . . . . . . . . . . . . . . . . . . . 5
2.1. LCT Building Block . . . . . . . . . . . . . . . . . . . . 7
2.2. Multiple Rate Congestion Control Building Block . . . . . 9
2.3. FEC Building Block . . . . . . . . . . . . . . . . . . . . 10
2.4. Session Description . . . . . . . . . . . . . . . . . . . 11
2.5. Packet Authentication Building Block . . . . . . . . . . . 12
3. Conformance Statement . . . . . . . . . . . . . . . . . . . . 12
4. Functionality Definition . . . . . . . . . . . . . . . . . . . 13
4.1. Packet Format Used by ALC . . . . . . . . . . . . . . . . 13
4.2. LCT Header Extension Fields . . . . . . . . . . . . . . . 14
4.3. Sender Operation . . . . . . . . . . . . . . . . . . . . . 15
4.4. Receiver Operation . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
5.1. Baseline Secure ALC Operation . . . . . . . . . . . . . . 18
5.1.1. IPsec Approach . . . . . . . . . . . . . . . . . . . . 18
5.1.2. IPsec Requirements . . . . . . . . . . . . . . . . . . 19
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
8. Changes from RFC 3450 . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . . 23
This document describes a massively scalable reliable content delivery protocol, Asynchronous Layered Coding (ALC), for multiple rate congestion controlled reliable content delivery. The protocol is specifically designed to provide massive scalability using IP multicast as the underlying network service. Massive scalability in this context means the number of concurrent receivers for an object is potentially in the millions, the aggregate size of objects to be delivered in a session ranges from hundreds of kilobytes to hundreds of gigabytes, each receiver can initiate reception of an object asynchronously, the reception rate of each receiver in the session is the maximum fair bandwidth available between that receiver and the sender, and all of this can be supported using a single sender.
本文档描述了一种大规模可扩展的可靠内容交付协议，即异步分层编码（ALC），用于多速率拥塞控制的可靠内容交付。该协议专门设计用于使用IP多播作为底层网络服务提供大规模可扩展性。在这种情况下，大规模可扩展性意味着一个对象的并发接收器数量可能达到数百万，会话中要交付的对象的总大小从数百KB到数百GB不等，每个接收器都可以异步启动对象的接收，会话中每个接收器的接收速率是该接收器和发送器之间可用的最大公平带宽，并且使用单个发送器可以支持所有这些。
Because ALC is focused on reliable content delivery, the goal is to deliver objects as quickly as possible to each receiver while at the same time remaining network friendly to competing traffic. Thus, the congestion control used in conjunction with ALC should strive to maximize use of available bandwidth between receivers and the sender while at the same time backing off aggressively in the face of competing traffic.
由于ALC专注于可靠的内容交付，其目标是尽可能快地向每个接收者交付对象，同时保持对竞争流量的网络友好性。因此，与ALC结合使用的拥塞控制应努力最大限度地利用接收器和发送器之间的可用带宽，同时在面临竞争流量时积极后退。
The sender side of ALC consists of generating packets based on objects to be delivered within the session and sending the appropriately formatted packets at the appropriate rates to the channels associated with the session. The receiver side of ALC consists of joining appropriate channels associated with the session, performing congestion control by adjusting the set of joined channels associated with the session in response to detected congestion, and using the packets to reliably reconstruct objects. All information flow in an ALC session is in the form of data packets sent by a single sender to channels that receivers join to receive data.
ALC的发送方包括基于会话中要传递的对象生成数据包，并以适当的速率将适当格式化的数据包发送到与会话相关联的信道。ALC的接收器端包括加入与会话相关联的适当信道，通过响应于检测到的拥塞调整与会话相关联的加入信道集来执行拥塞控制，以及使用分组可靠地重构对象。ALC会话中的所有信息流都以数据包的形式存在，数据包由单个发送方发送到接收方加入以接收数据的通道。
ALC does specify the Session Description needed by receivers before they join a session, but the mechanisms by which receivers obtain this required information is outside the scope of ALC. An application that uses ALC may require that receivers report statistics on their reception experience back to the sender, but the mechanisms by which receivers report back statistics is outside the scope of ALC. In general, ALC is designed to be a minimal protocol instantiation that provides reliable content delivery without unnecessary limitations to the scalability of the basic protocol.
ALC确实指定了接收者在加入会话之前所需的会话描述，但是接收者获取所需信息的机制不在ALC的范围之内。使用ALC的应用程序可能要求接收者向发送者报告其接收体验的统计信息，但接收者报告统计信息的机制不在ALC的范围之内。通常，ALC被设计成一个最小的协议实例化，它提供可靠的内容交付，而不会对基本协议的可伸缩性造成不必要的限制。
This document is a product of the IETF RMT WG and follows the general guidelines provided in [RFC3269].
本文件是IETF RMT工作组的产品，遵循[RFC3269]中提供的一般指南。
A previous version of this document was published in the "Experimental" category as [RFC3450] and is obsoleted by this document.
本文件的前一版本作为[RFC3450]以“实验性”类别发布，已被本文件淘汰。
This Proposed Standard specification is thus based on and backwards compatible with the protocol defined in [RFC3450] updated according to accumulated experience and growing protocol maturity since its original publication. Said experience applies both to this specification itself and to congestion control strategies related to the use of this specification.
因此，本拟议标准规范基于[RFC3450]中定义的协议，并与之向后兼容，该协议根据其原始发布以来积累的经验和不断增长的协议成熟度进行更新。上述经验既适用于本规范本身，也适用于与本规范使用相关的拥塞控制策略。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、[RFC2119]中所述进行解释。
ALC can support several different reliable content delivery service models as described in [RFC5651].
ALC可以支持多种不同的可靠内容交付服务模型，如[RFC5651]所述。
Massive scalability is a primary design goal for ALC. IP multicast is inherently massively scalable, but the best effort service that it provides does not provide session management functionality, congestion control, or reliability. ALC provides all of this on top of IP multicast without sacrificing any of the inherent scalability of IP multicast. ALC has the following properties:
大规模可扩展性是ALC的主要设计目标。IP多播本质上是大规模可扩展的，但它提供的尽力而为服务不提供会话管理功能、拥塞控制或可靠性。ALC在IP多播的基础上提供所有这些功能，而不会牺牲IP多播固有的可伸缩性。ALC具有以下属性：
o To each receiver, it appears as if there is a dedicated session from the sender to the receiver, where the reception rate adjusts to congestion along the path from sender to receiver.
o 对于每个接收者来说，似乎有一个从发送者到接收者的专用会话，在该会话中，接收速率根据从发送者到接收者的路径上的拥塞情况进行调整。
o To the sender, there is no difference in load or outgoing rate if one receiver or a million (or any number of) receivers are joined to the session, independent of when the receivers join and leave.
o 对于发送方来说，如果一个接收方或一百万（或任意数量的）接收方加入会话，则无论接收方何时加入和离开，负载或传出速率都没有差异。
o No feedback packets are required from receivers to the sender.
o 从接收者到发送者不需要反馈数据包。
o Almost all packets in the session that pass through a bottleneck link are utilized by downstream receivers, and the session shares the link with competing flows fairly in proportion to their utility.
o 会话中通过瓶颈链路的几乎所有数据包都被下游接收器利用，并且会话与竞争流按照其效用的比例公平地共享链路。
Thus, ALC provides a massively scalable content delivery transport that is network friendly.
因此，ALC提供了网络友好的大规模可扩展内容交付传输。
ALC intentionally omits any application-specific features that could potentially limit its scalability. By doing so, ALC provides a minimal protocol that is massively scalable. Applications may be built on top of ALC to provide additional features that may limit the scalability of the application. Such applications are outside the scope of this document.
ALC故意省略可能限制其可伸缩性的任何特定于应用程序的功能。通过这样做，ALC提供了一个可大规模扩展的最小协议。应用程序可以构建在ALC之上，以提供可能限制应用程序可扩展性的附加功能。此类应用不在本文件的范围内。
All of the environmental requirements and considerations that apply to the LCT building block [RFC5651], the FEC building block [RFC5052], the multiple rate congestion control building block, and to any additional building blocks that ALC uses also apply to ALC.
适用于LCT构建块[RFC5651]、FEC构建块[RFC5052]、多速率拥塞控制构建块以及ALC使用的任何其他构建块的所有环境要求和注意事项也适用于ALC。
The IP multicast model defined in [RFC1112] is commonly known as Any-Source Multicast (ASM), in contrast to Source-Specific Multicast (SSM) which is defined in [RFC3569]. One issue that is specific to ALC with respect to ASM is the way the multiple rate congestion control building block interacts with ASM. The congestion control building block may use the measured difference in time between when a join to a channel is sent and when the first packet from the channel arrives in determining the receiver reception rate. The congestion control building block may also use packet sequence numbers per channel to measure losses, and this is also used to determine the receiver reception rate. These features raise two concerns with respect to ASM: The time difference between when the join to a channel is sent and when the first packet arrives can be significant due to the use of Rendezvous Points (RPs) and the Multicast Source Discovery Protocol (MSDP) [RFC3618] protocol, and packets can be lost in the switch over from the (*,G) join to the RP and the (S,G) join directly to the sender. Both of these issues could potentially substantially degrade the reception rate of receivers. To ameliorate these concerns, it is recommended during deployment to ensure that the RP be as close to the sender as possible. SSM does not share these same concerns. For a fuller consideration of these issues, consult the multiple rate congestion control building block.
[RFC1112]中定义的IP多播模型通常称为任意源多播（ASM），与[RFC3569]中定义的源特定多播（SSM）相反。关于ASM，ALC特有的一个问题是多速率拥塞控制构建块与ASM交互的方式。拥塞控制构建块可以使用在发送到信道的加入和来自信道的第一分组到达之间测量的时间差来确定接收机接收速率。拥塞控制构建块还可以使用每个信道的分组序列号来测量损耗，并且这也用于确定接收机接收速率。这些特性引起了ASM方面的两个问题：由于使用了集合点（RPs）和多播源发现协议（MSDP）[RFC3618]协议，发送到通道的连接和第一个数据包到达之间的时间差可能很大，并且数据包可能在从（*，G）的切换中丢失连接到RP和（S，G）直接连接到发送方。这两个问题都可能严重降低接收机的接收速率。为了改善这些问题，建议在部署期间确保RP尽可能靠近发送方。SSM没有这些相同的担忧。要更全面地考虑这些问题，请参考多速率拥塞控制构建块。
ALC uses the LCT building block [RFC5651] to provide in-band session management functionality. ALC uses a multiple rate congestion control building block that is compliant with [RFC2357] to provide congestion control that is feedback free. Receivers adjust their reception rates individually by joining and leaving channels associated with the session. ALC uses the FEC building block [RFC5052] to provide reliability. The sender generates encoding symbols based on the object to be delivered using FEC codes and sends them in packets to channels associated with the session. Receivers
ALC使用LCT构建块[RFC5651]提供带内会话管理功能。ALC使用符合[RFC2357]的多速率拥塞控制构建块来提供无反馈的拥塞控制。接收机通过加入和离开与会话相关的频道来单独调整接收速率。ALC使用FEC构建块[RFC5052]提供可靠性。发送方使用FEC码基于要传送的对象生成编码符号，并将它们以分组的形式发送到与会话相关联的信道。接受者
simply wait for enough packets to arrive in order to reliably reconstruct the object. Thus, there is no request for retransmission of individual packets from receivers that miss packets in order to assure reliable reception of an object, and the packets and their rate of transmission out of the sender can be independent of the number and the individual reception experiences of the receivers.
只需等待足够的数据包到达即可可靠地重建对象。因此，不存在为了确保对象的可靠接收而错过分组的接收机对单个分组的重传的请求，并且分组及其从发送方发送出去的速率可以独立于接收机的数目和单个接收体验。
The definition of a session for ALC is the same as it is for LCT. An ALC session comprises multiple channels originating at a single sender that are used for some period of time to carry packets pertaining to the transmission of one or more objects that can be of interest to receivers. Congestion control is performed over the aggregate of packets sent to channels belonging to a session. The fact that an ALC session is restricted to a single sender does not preclude the possibility of receiving packets for the same objects from multiple senders. However, each sender would be sending packets to a different session to which congestion control is individually applied. Although receiving concurrently from multiple sessions is allowed, how this is done at the application level is outside the scope of this document.
ALC会话的定义与LCT会话的定义相同。ALC会话包括源自单个发送方的多个信道，这些信道在一段时间内用于承载与一个或多个对象的传输有关的数据包，这些对象可能是接收方感兴趣的。拥塞控制是在发送到属于会话的信道的数据包的集合上执行的。ALC会话仅限于单个发送方的事实并不排除从多个发送方接收相同对象的数据包的可能性。然而，每个发送方将向单独应用拥塞控制的不同会话发送数据包。尽管允许从多个会话同时接收，但如何在应用程序级别执行此操作超出了本文档的范围。
ALC is a protocol instantiation as defined in [RFC3048]. This document describes version 1 of ALC, which MUST use version 1 of LCT described in [RFC5651]. Like LCT, ALC is designed to be used with the IP multicast network service. This specification defines ALC as payload of the UDP transport protocol [RFC0768] that supports the IP multicast delivery of packets.
ALC是[RFC3048]中定义的协议实例化。本文件描述了ALC版本1，该版本必须使用[RFC5651]中所述的LCT版本1。与LCT一样，ALC设计用于IP多播网络服务。本规范将ALC定义为UDP传输协议[RFC0768]的有效负载，该协议支持数据包的IP多播传送。
The ALC packet format is illustrated in Figure 1. An ALC packet header immediately follows the IP/UDP header and consists of the default LCT header that is described in [RFC5651] followed by the FEC Payload ID that is described in [RFC5052]. The Congestion Control Information field within the LCT header carries the required Congestion Control Information that is described in the multiple rate congestion control building block specified that is compliant with [RFC2357]. The packet payload that follows the ALC packet header consists of encoding symbols that are identified by the FEC Payload ID as described in [RFC5052].
ALC数据包格式如图1所示。ALC数据包报头紧跟在IP/UDP报头之后，由[RFC5651]中描述的默认LCT报头和[RFC5052]中描述的FEC有效负载ID组成。LCT报头中的拥塞控制信息字段包含所需的拥塞控制信息，该信息在符合[RFC2357]的指定的多速率拥塞控制构建块中描述。ALC数据包报头后面的数据包有效载荷由编码符号组成，编码符号由FEC有效载荷ID标识，如[RFC5052]所述。
+----------------------------------------+
| IP Header |
+----------------------------------------+
| UDP Header |
+----------------------------------------+
| LCT Header |
+----------------------------------------+
| FEC Payload Id |
+----------------------------------------+
| Encoding Symbols |
+----------------------------------------+
+----------------------------------------+
| IP Header |
+----------------------------------------+
| UDP Header |
+----------------------------------------+
| LCT Header |
+----------------------------------------+
| FEC Payload Id |
+----------------------------------------+
| Encoding Symbols |
+----------------------------------------+
Figure 1: ALC Packet Format
图1:ALC数据包格式
Each receiver is required to obtain a Session Description before joining an ALC session. As described later, the Session Description includes out-of-band information required for the LCT, FEC, and the multiple rate congestion control building blocks. The FEC Object Transmission Information specified in the FEC building block [RFC5052] required for each object to be received by a receiver can be communicated to a receiver either out-of-band or in-band using a Header Extension. The means for communicating the Session Description and the FEC Object Transmission Information to a receiver is outside the scope of this document.
要求每个接收器在加入ALC会话之前获得会话描述。如下文所述，会话描述包括LCT、FEC和多速率拥塞控制构建块所需的带外信息。接收机接收的每个对象所需的FEC构造块[RFC5052]中指定的FEC对象传输信息可以使用报头扩展在带外或带内传送给接收机。用于将会话描述和FEC对象传输信息传送到接收机的装置不在本文档的范围内。
LCT requires receivers to be able to uniquely identify and demultiplex packets associated with an LCT session, and ALC inherits and strengthens this requirement. A Transport Session Identifier (TSI) MUST be associated with each session and MUST be carried in the LCT header of each ALC packet. The TSI is scoped by the sender IP address, and the (sender IP address, TSI) pair MUST uniquely identify the session.
LCT要求接收器能够唯一地识别和解复用与LCT会话相关的数据包，ALC继承并加强了这一要求。传输会话标识符（TSI）必须与每个会话相关联，并且必须在每个ALC数据包的LCT报头中携带。TSI的范围由发送方IP地址确定，并且（发送方IP地址，TSI）对必须唯一标识会话。
The LCT header contains a Congestion Control Information (CCI) field that MUST be used to carry the Congestion Control Information from the specified multiple rate congestion control protocol. There is a field in the LCT header that specifies the length of the CCI field, and the multiple rate congestion control building block MUST uniquely identify a format of the CCI field that corresponds to this length.
LCT标头包含一个拥塞控制信息（CCI）字段，该字段必须用于从指定的多速率拥塞控制协议传输拥塞控制信息。LCT标头中有一个字段指定CCI字段的长度，多速率拥塞控制构建块必须唯一标识与此长度对应的CCI字段格式。
The LCT header contains a Codepoint field that MAY be used to communicate to a receiver the settings for information that may vary during a session. If used, the mapping between settings and Codepoint values is to be communicated in the Session Description, and this mapping is outside the scope of this document. For example, the FEC Encoding ID that is part of the FEC Object Transmission
LCT报头包含一个代码点字段，该字段可用于将会话期间可能发生变化的信息的设置传达给接收器。如果使用，设置和代码点值之间的映射将在会话描述中传达，并且此映射不在本文档的范围内。例如，作为FEC对象传输的一部分的FEC编码ID
Information, as specified in the FEC building block [RFC5052], could vary for each object carried in the session, and the Codepoint value could be used to communicate the FEC Encoding ID to be used for each object. The mapping between FEC Encoding IDs and Codepoints could be, for example, the identity mapping.
如FEC构建块[RFC5052]中所规定的，对于会话中携带的每个对象，信息可能会有所不同，并且可以使用代码点值来传递要用于每个对象的FEC编码ID。例如，FEC编码ID和代码点之间的映射可以是身份映射。
If more than one object is to be carried within a session, then the Transmission Object Identifier (TOI) MUST be used in the LCT header to identify which packets are to be associated with which objects. In this case, the receiver MUST use the TOI to associate received packets with objects. The TOI is scoped by the IP address of the sender and the TSI, i.e., the TOI is scoped by the session. The TOI for each object is REQUIRED to be unique within a session, but is not required be unique across sessions. Furthermore, the same object MAY have a different TOI in different sessions. The mapping between TOIs and objects carried in a session is outside the scope of this document.
如果一个会话中要承载多个对象，则必须在LCT报头中使用传输对象标识符（TOI）来标识哪些数据包将与哪些对象关联。在这种情况下，接收器必须使用TOI将接收到的数据包与对象相关联。TOI由发送方和TSI的IP地址确定范围，即，TOI由会话确定范围。每个对象的TOI在会话中必须是唯一的，但在会话之间不必是唯一的。此外，同一对象在不同会话中可能具有不同的TOI。TOI和会话中携带的对象之间的映射不在本文档的范围内。
If only one object is carried within a session, then the TOI MAY be omitted from the LCT header.
如果一个会话中只携带一个对象，则可以从LCT头中省略TOI。
The LCT header from version 1 of the LCT building block [RFC5651] MUST be used.
必须使用LCT构造块[RFC5651]版本1中的LCT标头。
The LCT Header includes a two-bit Protocol Specific Indication (PSI) field in bits 6 and 7 of the first word of the LCT header. These two bits are used by ALC as follows:
LCT报头在LCT报头的第一个字的第6位和第7位中包括两位协议特定指示（PSI）字段。ALC使用这两位，如下所示：
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+ ...|X|Y|... +-+-+
01 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 7 8 9 0 1 2 3 4 6 7 8 9 0 1+/-+…|X | Y |+-+-+
Figure 2: PSI Bits within LCT Header
图2:LCT头中的PSI位
PSI bit X - Source Packet Indicator (SPI)
PSI位X-源数据包指示符（SPI）
PSI bit Y - Reserved
PSI位Y-保留
The Source Packet Indicator is used with systematic FEC Schemes which define a different FEC Payload ID format for packets containing only source data compared to the FEC Payload ID format for packets containing repair data. For such FEC Schemes, the SPI MUST be set to 1 when the FEC Payload ID format for packets containing only source data is used, and the SPI MUST be set to zero when the FEC Payload ID for packets containing repair data is used. In the case of FEC
源分组指示符与系统FEC方案一起使用，系统FEC方案为仅包含源数据的分组定义不同的FEC有效载荷ID格式，而为包含修复数据的分组定义不同的FEC有效载荷ID格式。对于此类FEC方案，当使用仅包含源数据的分组的FEC有效载荷ID格式时，SPI必须设置为1，并且当使用包含修复数据的分组的FEC有效载荷ID时，SPI必须设置为零。在FEC的情况下
Schemes that define only a single FEC Payload ID format, the SPI MUST be set to zero by the sender and MUST be ignored by the receiver.
在仅定义单个FEC有效负载ID格式的方案中，发送方必须将SPI设置为零，接收方必须忽略SPI。
Support of two FEC Payload ID formats allows FEC Payload ID information that is only of relevance when FEC decoding is to be performed to be provided in the FEC Payload ID format for packets containing repair data. This information need not be processed by receivers that do not perform FEC decoding (either because no FEC decoding is required or because the receiver does not support FEC decoding).
对两种FEC有效载荷ID格式的支持允许以FEC有效载荷ID格式为包含修复数据的分组提供仅在执行FEC解码时相关的FEC有效载荷ID信息。不执行FEC解码的接收机不需要处理该信息（因为不需要FEC解码，或者因为接收机不支持FEC解码）。
At a minimum, implementations of ALC MUST support [RFC3738]. Note that [RFC3738] has been published in the "Experimental" category and thus has lower maturity level than the present document. Caution should be used since it may be less stable than this document.
ALC的实现至少必须支持[RFC3738]。请注意，[RFC3738]已在“实验”类别中发布，因此其成熟度低于本文件。应谨慎使用，因为它可能不如本文件稳定。
Congestion control MUST be applied to all packets within a session independently of which information about which object is carried in each packet. Multiple rate congestion control is specified because of its suitability to scale massively and because of its suitability for reliable content delivery. [RFC3738] specifies in-band Congestion Control Information (CCI) that MUST be carried in the CCI field of the LCT header.
拥塞控制必须应用于会话中的所有数据包，而与每个数据包中携带的对象相关的信息无关。指定多速率拥塞控制是因为它适合大规模扩展，并且适合可靠的内容交付。[RFC3738]指定必须在LCT标头的CCI字段中携带的带内拥塞控制信息（CCI）。
Alternative multiple rate congestion control building blocks MAY be supported, but only a single congestion control building block may be used in a given ALC session. The congestion control building block to be used in an ALC session is specified in the Session Description (see Section 2.4). A multiple rate congestion control building block MAY specify more than one format for the CCI field, but it MUST specify at most one format for each of the possible lengths 32, 64, 96, or 128 bits. The value of C in the LCT header that determines the length of the CCI field MUST correspond to one of the lengths for the CCI defined in the multiple rate congestion control building block; this length MUST be the same for all packets sent to a session, and the CCI format that corresponds to the length as specified in the multiple rate congestion control building block MUST be the format used for the CCI field in the LCT header.
可以支持替代的多速率拥塞控制构建块，但在给定的ALC会话中只能使用单个拥塞控制构建块。ALC会话中使用的拥塞控制构建块在会话描述中有详细说明（参见第2.4节）。多速率拥塞控制构建块可以为CCI字段指定多个格式，但它必须为每个可能的长度32、64、96或128位指定最多一种格式。LCT头中确定CCI字段长度的C值必须对应于多速率拥塞控制构建块中定义的CCI长度之一；对于发送到会话的所有数据包，该长度必须相同，并且与多速率拥塞控制构建块中指定的长度相对应的CCI格式必须是LCT头中CCI字段使用的格式。
When using a multiple rate congestion control building block, a sender sends packets in the session to several channels at potentially different rates. Then, individual receivers adjust their reception rate within a session by adjusting to which set of channels they are joined at each point in time depending on the available bandwidth between the receiver and the sender, but independent of other receivers.
当使用多速率拥塞控制构建块时，发送方将会话中的数据包以可能不同的速率发送到多个通道。然后，单个接收机通过调整在每个时间点加入的信道集来调整会话内的接收速率，这取决于接收机和发送方之间的可用带宽，但与其他接收机无关。
The FEC building block [RFC5052] provides reliable object delivery within an ALC session. Each object sent in the session is independently encoded using FEC codes as described in [RFC3453], which provide a more in-depth description of the use of FEC codes in reliable content delivery protocols. All packets in an ALC session MUST contain an FEC Payload ID in a format that is compliant with the FEC Scheme in use. The FEC Payload ID uniquely identifies the encoding symbols that constitute the payload of each packet, and the receiver MUST use the FEC Payload ID to determine how the encoding symbols carried in the payload of the packet were generated from the object as described in the FEC building block.
FEC构建块[RFC5052]在ALC会话中提供可靠的对象传递。会话中发送的每个对象都使用[RFC3453]中所述的FEC代码进行独立编码，这为在可靠内容交付协议中使用FEC代码提供了更深入的描述。ALC会话中的所有数据包都必须包含FEC有效负载ID，其格式符合所使用的FEC方案。FEC有效载荷ID唯一地标识构成每个分组的有效载荷的编码符号，并且接收机必须使用FEC有效载荷ID来确定分组的有效载荷中携带的编码符号是如何从FEC构建块中描述的对象生成的。
As described in [RFC5052], a receiver is REQUIRED to obtain the FEC Object Transmission Information for each object for which data packets are received from the session. In the context of ALC, the FEC Object Transmission Information includes:
如[RFC5052]中所述，接收器需要获得从会话接收数据包的每个对象的FEC对象传输信息。在ALC的上下文中，FEC对象传输信息包括：
o The FEC Encoding ID.
o FEC编码ID。
o If an Under-Specified FEC Encoding ID is used, then the FEC Instance ID associated with the FEC Encoding ID.
o 如果使用未充分指定的FEC编码ID，则与FEC编码ID关联的FEC实例ID。
o For each object in the session, the transfer length of the object in bytes.
o 对于会话中的每个对象，以字节为单位的对象传输长度。
Additional FEC Object Transmission Information may be required depending on the FEC Scheme that is used (identified by the FEC Encoding ID).
根据所使用的FEC方案（由FEC编码ID标识），可能需要额外的FEC对象传输信息。
Some of the FEC Object Transmission Information MAY be implicit based on the FEC Scheme and/or implementation. As an example, source block lengths may be derived by a fixed algorithm from the object length. As another example, it may be that all source blocks are the same length and this is what is passed out-of-band to the receiver. As another example, it could be that the full-sized source block length is provided, and this is the length used for all but the last source block, which is calculated based on the full source block length and the object length. As another example, it could be that the same FEC Encoding ID and FEC Instance ID are always used for a particular application, and thus the FEC Encoding ID and FEC Instance ID are implicitly defined.
基于FEC方案和/或实现，一些FEC对象传输信息可以是隐式的。例如，源块长度可以通过固定算法从对象长度导出。作为另一个示例，所有源块的长度可能相同，这就是传递到接收机的带外数据。作为另一个示例，可能是提供了完整大小的源块长度，这是用于除最后一个源块以外的所有源块的长度，该长度是基于完整源块长度和对象长度计算的。作为另一个示例，可能是相同的FEC编码ID和FEC实例ID始终用于特定应用程序，因此FEC编码ID和FEC实例ID被隐式定义。
Sometimes the objects that will be sent in a session are completely known before the receiver joins the session, in which case the FEC Object Transmission Information for all objects in the session can be communicated to receivers before they join the session. At other
有时，将在会话中发送的对象在接收器加入会话之前是完全已知的，在这种情况下，会话中所有对象的FEC对象传输信息可以在接收器加入会话之前传送给接收器。另外
times, the objects may not know when the session begins, receivers may join a session in progress and may not be interested in some objects for which transmission has finished, or receivers may leave a session before some objects are even available within the session. In these cases, the FEC Object Transmission Information for each object may be dynamically communicated to receivers at or before the time packets for the object are received from the session. This may be accomplished using an out-of-band mechanism, in-band using the Codepoint field or a Header Extension, or any combination of these methods. How the FEC Object Transmission Information is communicated to receivers is outside the scope of this document.
有时，对象可能不知道会话何时开始，接收机可能加入正在进行的会话，并且可能对传输已完成的一些对象不感兴趣，或者接收机可能在会话中甚至有一些对象可用之前离开会话。在这些情况下，每个对象的FEC对象传输信息可以在从会话接收对象的分组时或之前动态地传送给接收机。这可以使用带外机制、带内使用码点字段或报头扩展或这些方法的任何组合来实现。如何将FEC对象传输信息传送给接收机不在本文档的范围内。
Before a receiver can join an ALC session, the receiver needs to obtain a Session Description that contains the following information:
在接收器可以加入ALC会话之前，接收器需要获得包含以下信息的会话描述：
o The multiple rate congestion control building block to be used for the session;
o 用于会话的多速率拥塞控制构建块；
o The sender IP address;
o 发送方IP地址；
o The number of channels in the session;
o 会话中的频道数；
o The address and port number used for each channel in the session;
o 会话中每个通道使用的地址和端口号；
o The Transport Session ID (TSI) to be used for the session;
o 用于会话的传输会话ID（TSI）；
o An indication of whether or not the session carries packets for more than one object;
o 指示会话是否承载多个对象的分组；
o If Header Extensions are to be used, the format of these Header Extensions.
o 如果要使用标题扩展名，则这些标题扩展名的格式。
o Enough information to determine the packet authentication scheme being used, if one is being used.
o 足够的信息来确定正在使用的数据包身份验证方案（如果正在使用）。
How the Session Description is communicated to receivers is outside the scope of this document.
会话描述如何传达给接收者超出了本文档的范围。
The Codepoint field within the LCT portion of the header CAN be used to communicate in-band some of the dynamically changing information within a session. To do this, a mapping between Codepoint values and the different dynamic settings MUST be included within the Session Description, and then settings to be used are communicated via the Codepoint value placed into each packet. For example, it is possible that multiple objects are delivered within the same session and that a different FEC encoding algorithm is used for different types of
报头的LCT部分内的Codepoint字段可用于在会话内传送带内一些动态变化的信息。为此，必须在会话描述中包含代码点值和不同动态设置之间的映射，然后通过放入每个数据包中的代码点值传递要使用的设置。例如，可能在同一会话中传递多个对象，并且对不同类型的会话使用不同的FEC编码算法
objects. Then the Session Description could contain the mapping between Codepoint values and FEC Encoding IDs. As another example, it is possible that a different packet authentication scheme is used for different packets sent to the session. In this case, the mapping between the packet authentication scheme and Codepoint values could be provided in the Session Description. Combinations of settings can be mapped to Codepoint values as well. For example, a particular combination of a FEC Encoding ID and a packet authentication scheme could be associated with a Codepoint value.
物体。然后，会话描述可以包含代码点值和FEC编码ID之间的映射。作为另一示例，可能对发送到会话的不同分组使用不同分组认证方案。在这种情况下，可以在会话描述中提供分组认证方案和码点值之间的映射。设置的组合也可以映射到代码点值。例如，FEC编码ID和分组认证方案的特定组合可以与码点值相关联。
The Session Description could also include, but is not limited to:
会话描述还可以包括但不限于：
o The mappings between combinations of settings and Codepoint values;
o 设置和代码点值组合之间的映射；
o The data rates used for each channel;
o 每个通道使用的数据速率；
o The length of the packet payload;
o 分组有效载荷的长度；
o Any information that is relevant to each object being transported, such as the Object Transmission Information for each object, when the object will be available within the session, and for how long.
o 与正在传输的每个对象相关的任何信息，例如每个对象的对象传输信息、该对象在会话中何时可用以及可用多长时间。
The Session Description could be in a form such as the Session Description Protocol (SDP) as defined in [RFC4566], XML metadata as defined in [RFC3023], or HTTP/MIME headers as defined in [RFC2616], etc. It might be carried in a session announcement protocol such as SAP as defined in [RFC2974], obtained using a proprietary session control protocol, located on a web page with scheduling information, or conveyed via email or other out-of-band methods. Discussion of Session Description formats and methods for communication of Session Descriptions to receivers is beyond the scope of this document.
会话描述可以是[RFC4566]中定义的会话描述协议（SDP）、[RFC3023]中定义的XML元数据或[RFC2616]中定义的HTTP/MIME头等形式。它可以在会话公告协议（如[RFC2974]中定义的SAP）中携带，该协议使用专有会话控制协议获得，位于包含日程安排信息的网页上，或通过电子邮件或其他带外方法传达。关于会话描述格式和向接收者传达会话描述的方法的讨论超出了本文档的范围。
It is RECOMMENDED that implementors of ALC use some packet authentication scheme to protect the protocol from attacks. Suitable schemes are described in [RFC5776] and [RMT-SIMPLE].
建议ALC的实现者使用一些包认证方案来保护协议免受攻击。[RFC5776]和[RMT-SIMPLE]中描述了合适的方案。
This Protocol Instantiation document, in conjunction with the LCT building block [RFC5651], the FEC building block [RFC5052], and [RFC3738] completely specifies a working reliable multicast transport protocol that conforms to the requirements described in [RFC2357].
本协议实例化文件与LCT构建块[RFC5651]、FEC构建块[RFC5052]和[RFC3738]一起，完全规定了符合[RFC2357]中所述要求的工作可靠多播传输协议。
This section describes the format and functionality of the data packets carried in an ALC session as well as the sender and receiver operations for a session.
本节介绍ALC会话中携带的数据包的格式和功能，以及会话的发送方和接收方操作。
The packet format used by ALC is the UDP header followed by the LCT header followed by the FEC Payload ID followed by the packet payload. The LCT header is defined in the LCT building block [RFC5651] and the FEC Payload ID is described in the FEC building block [RFC5052]. The Congestion Control Information field in the LCT header contains the required Congestion Control Information that is described in the multiple rate congestion control building block used. The packet payload contains encoding symbols generated from an object. If more than one object is carried in the session, then the Transmission Object ID (TOI) within the LCT header MUST be used to identify from which object the encoding symbols are generated. Within the scope of an object, encoding symbols carried in the payload of the packet are identified by the FEC Payload ID as described in the FEC building block.
ALC使用的数据包格式是UDP报头、LCT报头、FEC有效负载ID和数据包有效负载。LCT头在LCT构建块[RFC5651]中定义，FEC有效负载ID在FEC构建块[RFC5052]中描述。LCT标头中的拥塞控制信息字段包含所使用的多速率拥塞控制构建块中描述的所需拥塞控制信息。数据包有效负载包含从对象生成的编码符号。如果会话中携带了多个对象，则必须使用LCT报头中的传输对象ID（TOI）来标识从哪个对象生成编码符号。在对象的范围内，分组的有效载荷中携带的编码符号由FEC构建块中描述的FEC有效载荷ID标识。
The version number of ALC specified in this document is 1. The version number field of the LCT header MUST be interpreted as the ALC version number field. This version of ALC implicitly makes use of version 1 of the LCT building block defined in [RFC5651].
本文档中指定的ALC版本号为1。LCT标头的版本号字段必须解释为ALC版本号字段。此版本的ALC隐式使用了[RFC5651]中定义的LCT构建块的版本1。
The overall ALC packet format is depicted in Figure 3. The packet is an IP packet, either IPv4 or IPv6, and the IP header precedes the UDP header. The ALC packet format has no dependencies on the IP version number.
整个ALC数据包格式如图3所示。该数据包是一个IP数据包，可以是IPv4或IPv6，IP报头位于UDP报头之前。ALC数据包格式不依赖于IP版本号。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Header |
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| LCT Header |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Payload ID |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol(s) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Header |
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| LCT Header |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Payload ID |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol(s) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Overall ALC Packet Format
图3：ALC数据包的总体格式
In some special cases an ALC sender may need to produce ALC packets that do not contain any payload. This may be required, for example, to signal the end of a session or to convey congestion control information. These data-less packets do not contain the FEC Payload ID either, but only the LCT header fields. The total datagram length, conveyed by outer protocol headers (e.g., the IP or UDP header), enables receivers to detect the absence of the ALC payload and FEC Payload ID.
在某些特殊情况下，ALC发送方可能需要生成不包含任何有效负载的ALC数据包。这可能是必需的，例如，用于发出会话结束的信号或传送拥塞控制信息。这些无数据包也不包含FEC有效负载ID，只包含LCT报头字段。由外部协议报头（例如，IP或UDP报头）传送的总数据报长度使接收器能够检测到ALC有效负载和FEC有效负载ID的缺失。
For ALC, the length of the TSI field within the LCT header is REQUIRED to be non-zero. This implies that the sender MUST NOT set both the LCT flags S and H to zero.
对于ALC，LCT头中TSI字段的长度要求为非零。这意味着发送方不能将LCT标志S和H都设置为零。
This specification defines a new LCT Header Extension, "EXT_FTI", for the purpose of communicating the FEC Object Transmission Information in association with data packets of an object. The LCT Header Extension Type for EXT_FTI is 64.
本规范定义了新的LCT报头扩展“EXT_FTI”，用于与对象的数据分组相关联地传送FEC对象传输信息。EXT_FTI的LCT标头扩展类型为64。
The Header Extension Content (HEC) field of the EXT_FTI LCT Header Extension contains the encoded FEC Object Transmission Information as defined in [RFC5052]. The format of the encoded FEC Object Transmission Information is dependent on the FEC Scheme in use and so is outside the scope of this document.
EXT_FTI LCT标头扩展的标头扩展内容（HEC）字段包含[RFC5052]中定义的编码FEC对象传输信息。编码的FEC对象传输信息的格式取决于所使用的FEC方案，因此不在本文档的范围内。
The sender operation, when using ALC, includes all the points made about the sender operation when using the LCT building block [RFC5651], the FEC building block [RFC5052], and the multiple rate congestion control building block.
使用ALC时的发送方操作包括使用LCT构建块[RFC5651]、FEC构建块[RFC5052]和多速率拥塞控制构建块时有关发送方操作的所有要点。
A sender using ALC should make available the required Session Description as described in Section 2.4. A sender should also make available the required FEC Object Transmission Information as described in Section 2.3.
使用ALC的发送方应提供第2.4节所述的所需会话描述。发送方还应提供第2.3节所述的所需FEC对象传输信息。
Within a session, a sender transmits a sequence of packets to the channels associated with the session. The ALC sender MUST obey the rules for filling in the CCI field in the packet headers, and it MUST send packets at the appropriate rates to the channels associated with the session as dictated by the multiple rate congestion control building block.
在会话中，发送方向与会话相关联的信道发送数据包序列。ALC发送方必须遵守在数据包头中填写CCI字段的规则，并且必须按照多速率拥塞控制构建块的指示，以适当的速率向与会话相关联的信道发送数据包。
The ALC sender MUST use the same TSI for all packets in the session. Several objects MAY be delivered within the same ALC session. If more than one object is to be delivered within a session, then the sender MUST use the TOI field. Each object MUST be identified by a unique TOI within the session, and the sender MUST use corresponding TOI for all packets pertaining to the same object. The FEC Payload ID MUST correspond to the encoding symbol(s) for the object carried in the payload of the packet.
ALC发送方必须对会话中的所有数据包使用相同的TSI。在同一ALC会话中可以传递多个对象。如果一个会话中要传递多个对象，则发送方必须使用TOI字段。每个对象必须由会话中唯一的TOI标识，并且发送方必须对属于同一对象的所有数据包使用相应的TOI。FEC有效载荷ID必须对应于数据包有效载荷中所携带对象的编码符号。
It is RECOMMENDED that packet authentication be used. If packet authentication is used, then the Header Extensions described in Section 4.2 MAY be used to carry the authentication.
建议使用数据包身份验证。如果使用分组认证，则第4.2节中描述的报头扩展可用于承载认证。
The receiver operation, when using ALC, includes all the points made about the receiver operation when using the LCT building block [RFC5651], the FEC building block [RFC5052], and the multiple rate congestion control building block.
使用ALC时的接收器操作包括使用LCT构建块[RFC5651]、FEC构建块[RFC5052]和多速率拥塞控制构建块时关于接收器操作的所有要点。
To be able to participate in a session, a receiver needs to obtain the required Session Description as listed in Section 2.4. How receivers obtain a Session Description is outside the scope of this document.
为了能够参与会话，接收者需要获得第2.4节中列出的所需会话描述。接收者如何获得会话描述超出了本文档的范围。
As described in Section 2.3, a receiver needs to obtain the required FEC Object Transmission Information for each object for which the receiver receives and processes packets.
如第2.3节所述，接收器需要获得接收器接收和处理数据包的每个对象所需的FEC对象传输信息。
Upon receipt of each packet, the receiver proceeds with the following steps in the order listed.
在接收到每个分组后，接收器按照所列顺序进行以下步骤。
1. The receiver MUST parse the packet header and verify that it is a valid header. If it is not valid, then the packet MUST be discarded without further processing.
1. 接收方必须解析数据包报头并验证它是有效的报头。如果无效，则必须丢弃该数据包，无需进一步处理。
2. The receiver MUST verify that the sender IP address together with the TSI carried in the header matches one of the (sender IP address, TSI) pairs that was received in a Session Description and to which the receiver is currently joined. If there is not a match, then the packet MUST be silently discarded without further processing. The remaining steps are performed within the scope of the (sender IP address, TSI) session of the received packet.
2. 接收方必须验证发送方IP地址以及标头中携带的TSI是否与会话描述中接收到的且接收方当前加入的（发送方IP地址，TSI）对之一匹配。如果不存在匹配项，则必须在无需进一步处理的情况下悄悄丢弃数据包。其余步骤在所接收数据包的（发送方IP地址，TSI）会话范围内执行。
3. The receiver MUST process and act on the CCI field in accordance with the multiple rate congestion control building block.
3. 接收方必须按照多速率拥塞控制构建块处理CCI字段并对其采取行动。
4. If more than one object is carried in the session, the receiver MUST verify that the TOI carried in the LCT header is valid. If the TOI is not valid, the packet MUST be discarded without further processing.
4. 如果会话中携带了多个对象，则接收方必须验证LCT标头中携带的TOI是否有效。如果TOI无效，则必须丢弃数据包，无需进一步处理。
5. The receiver SHOULD process the remainder of the packet, including interpreting the other header fields appropriately, and using the FEC Payload ID and the encoding symbol(s) in the payload to reconstruct the corresponding object.
5. 接收机应处理包的剩余部分，包括适当地解释其他报头字段，并使用有效载荷中的FEC有效载荷ID和编码符号来重构相应的对象。
It is RECOMMENDED that packet authentication be used. If packet authentication is used, then it is RECOMMENDED that the receiver immediately check the authenticity of a packet before proceeding with step (3) above. If immediate checking is possible and if the packet fails the check, then the receiver MUST silently discard the packet.
建议使用数据包身份验证。如果使用分组认证，则建议接收机在继续进行上述步骤（3）之前立即检查分组的真实性。如果可以立即检查并且数据包未通过检查，则接收方必须悄悄地丢弃数据包。
The same security considerations that apply to the LCT, FEC, and the multiple rate congestion control building blocks also apply to ALC.
适用于LCT、FEC和多速率拥塞控制构建块的相同安全注意事项也适用于ALC。
ALC is especially vulnerable to denial-of-service attacks by attackers that try to send forged packets to the session, which would prevent successful reconstruction or cause inaccurate reconstruction of large portions of the object by receivers. ALC is also particularly affected by such an attack because many receivers may receive the same forged packet. There are two ways to protect against such attacks, one at the application level and one at the packet level. It is RECOMMENDED that prevention be provided at both levels.
ALC特别容易受到攻击者的拒绝服务攻击，攻击者试图向会话发送伪造数据包，这将阻止成功重建或导致接收者不准确地重建大部分对象。ALC也特别受到这种攻击的影响，因为许多接收者可能会收到相同的伪造数据包。有两种方法可以防止此类攻击，一种是在应用程序级别，另一种是在数据包级别。建议在这两个层面进行预防。
At the application level, it is RECOMMENDED that an integrity check on the entire received object be done once the object is reconstructed to ensure it is the same as the sent object. Moreover, in order to obtain strong cryptographic integrity protection, a digital signature verifiable by the receiver SHOULD be used to provide this application-level integrity check. However, if even one corrupted or forged packet is used to reconstruct the object, it is likely that the received object will be reconstructed incorrectly. This will appropriately cause the integrity check to fail and in this case, the inaccurately reconstructed object SHOULD be discarded. Thus, the acceptance of a single forged packet can be an effective denial-of-service attack for distributing objects, but an object integrity check at least prevents inadvertent use of inaccurately reconstructed objects. The specification of an application-level integrity check of the received object is outside the scope of this document.
在应用程序级别，建议在重构对象后对整个接收对象进行完整性检查，以确保其与发送对象相同。此外，为了获得强大的密码完整性保护，应使用可由接收器验证的数字签名来提供此应用程序级完整性检查。但是，如果使用一个损坏或伪造的数据包来重建对象，则很可能会错误地重建接收到的对象。这将适当地导致完整性检查失败，在这种情况下，应丢弃重建不准确的对象。因此，接受单个伪造数据包可能是分发对象的有效拒绝服务攻击，但对象完整性检查至少可以防止无意中使用不准确的重构对象。接收对象的应用程序级完整性检查规范不在本文档范围内。
At the packet level, it is RECOMMENDED that a packet-level authentication be used to ensure that each received packet is an authentic and uncorrupted packet containing data for the object arriving from the specified sender. Packet-level authentication has the advantage that corrupt or forged packets can be discarded individually and the received authenticated packets can be used to accurately reconstruct the object. Thus, the effect of a denial-of-service attack that injects forged packets is proportional only to the number of forged packets, and not to the object size. [RMT-SIMPLE]and [RFC5776] described packet level authentication schemes that can be used with the ALC protocol.
在数据包级别，建议使用数据包级别的身份验证，以确保每个接收到的数据包都是真实且未损坏的数据包，其中包含来自指定发送方的对象数据。数据包级身份验证的优点是可以单独丢弃损坏或伪造的数据包，并且可以使用接收到的经过身份验证的数据包准确地重建对象。因此，注入伪造数据包的拒绝服务攻击的效果仅与伪造数据包的数量成正比，而与对象大小无关。[RMT-SIMPLE]和[RFC5776]描述了可与ALC协议一起使用的数据包级身份验证方案。
In addition to providing protection against reconstruction of inaccurate objects, packet-level authentication can also provide some protection against denial-of-service attacks on the multiple rate congestion control. Attackers can try to inject forged packets with incorrect congestion control information into the multicast stream, thereby potentially adversely affecting network elements and receivers downstream of the attack, and much less significantly the rest of the network and other receivers. Thus, it is also RECOMMENDED that packet-level authentication be used to protect against such attacks. Timed Efficient Stream Loss-Tolerant Authentication (TESLA) [RFC5776] can also be used to some extent to limit the damage caused by such attacks. However, with TESLA, a receiver can only determine if a packet is authentic several seconds after it is received, and thus an attack against the congestion control protocol can be effective for several seconds before the receiver can react to slow down the session reception rate.
除了针对不准确对象的重建提供保护外，数据包级身份验证还可以针对多速率拥塞控制上的拒绝服务攻击提供一些保护。攻击者可以尝试向多播流中注入带有不正确拥塞控制信息的伪造数据包，从而可能对攻击下游的网络元素和接收器产生不利影响，更不用说对网络其余部分和其他接收器产生不利影响了。因此，还建议使用数据包级身份验证来防止此类攻击。定时高效流丢失容忍认证（TESLA）[RFC5776]也可以在一定程度上用于限制此类攻击造成的损害。然而，对于TESLA，接收器只能在接收到数据包几秒钟后确定其是否真实，因此对拥塞控制协议的攻击可以有效几秒钟，然后接收器才能作出反应以降低会话接收速率。
Some packet authentication schemes such as TESLA [RFC5776] do not allow an immediate authenticity check. In this case, the receiver
一些数据包认证方案，如特斯拉[RFC5776]不允许立即进行真实性检查。在这种情况下，接收器
SHOULD check the authenticity of a packet as soon as possible, and if the packet fails the check, then it MUST be silently discarded before Step 5 above. It is RECOMMENDED that if receivers detect many packets that fail authentication checks within a session, the above procedure should be modified for this session so that Step 3 is delayed until after the authentication check and only performed if the check succeeds.
应尽快检查数据包的真实性，如果该数据包未通过检查，则必须在上述步骤5之前将其悄悄丢弃。建议如果接收器在一个会话中检测到许多未通过身份验证检查的数据包，则应针对该会话修改上述过程，以便将步骤3延迟到身份验证检查之后，并且仅在检查成功时执行。
Reverse Path Forwarding checks SHOULD be enabled in all network routers and switches along the path from the sender to receivers to limit the possibility of a bad agent injecting forged packets into the multicast tree data path.
反向路径转发检查应在从发送方到接收方的所有网络路由器和交换机中启用，以限制坏代理将伪造数据包注入多播树数据路径的可能性。
This section describes a baseline mode of secure ALC protocol operation based on application of the IPsec security protocol. This approach is documented here to provide a reference of an interoperable secure mode of operation. However, additional approaches to ALC security, including other forms of IPsec application, MAY be specified in the future. For example, the use of the EXT_AUTH Header Extension could enable ALC-specific authentication or security encapsulation headers similar to those of IPsec to be specified and inserted into the ALC/LCT protocol message headers. This would allow header compression techniques to be applied to IP and ALC protocol headers when needed in a similar fashion to that of RTP [RFC3550] and as preserved in the specification for Secure Real Time Protocol (SRTP) [RFC3711].
本节描述基于IPsec安全协议应用的安全ALC协议操作的基线模式。本文记录了此方法，以提供可互操作的安全操作模式的参考。但是，将来可能会指定ALC安全的其他方法，包括其他形式的IPsec应用程序。例如，使用EXT_AUTH头扩展可以指定特定于ALC的身份验证或安全封装头，类似于IPsec的身份验证或安全封装头，并将其插入ALC/LCT协议消息头中。这将允许在需要时以与RTP[RFC3550]类似的方式将报头压缩技术应用于IP和ALC协议报头，并保留在安全实时协议（SRTP）[RFC3711]规范中。
The baseline approach described is applicable to ALC operation configured for SSM (or SSM-like) operation where there is a single sender. The receiver set would maintain a single IPsec Security Association (SA) for each ALC sender.
描述的基线方法适用于为SSM（或类似SSM）操作配置的ALC操作，其中只有一个发送器。接收方集将为每个ALC发送方维护一个IPsec安全关联（SA）。
To support this baseline form of secure ALC one-to-many SSM operation, each node SHALL be configured with a transport mode IPsec Security Association and corresponding Security Policy Database (SPD) entry. This entry will be used for sender-to-group multicast packet authentication and optionally encryption.
为了支持这种安全ALC一对多SSM操作的基线形式，每个节点应配置一个传输模式IPsec安全关联和相应的安全策略数据库（SPD）条目。此条目将用于发送方到组的多播数据包身份验证和可选加密。
The ALC sender SHALL use an IPsec SA configured for Encapsulating Security Payload (ESP) protocol [RFC4303] operation with the option for data origination authentication enabled. It is also RECOMMENDED that this IPsec ESP SA be also configured to provide confidentiality protection for IP packets containing ALC protocol messages. This is suggested to make the realization of complex replay attacks much more
ALC发送方应使用配置用于封装安全有效负载（ESP）协议[RFC4303]操作的IPsec SA，并启用数据发起验证选项。还建议将此IPsec ESP SA配置为为为包含ALC协议消息的IP数据包提供机密性保护。这有助于更有效地实现复杂的重放攻击
difficult. The encryption key for this SA SHALL be preplaced at the sender and receiver(s) prior to ALC protocol operation. Use of automated key management is RECOMMENDED as a rekey SHALL be required prior to expiration of the sequence space for the SA. This is necessary so that receivers may use the built-in IPsec replay attack protection possible for an IPsec SA with a single source (the ALC sender). Thus, the receivers SHALL enable replay attack protection for this SA used to secure ALC sender traffic. The sender IPsec SPD entry MUST be configured to process outbound packets to the destination address and UDP port number of the applicable ALC session.
困难的在ALC协议操作之前，此SA的加密密钥应预先放置在发送方和接收方。建议使用自动密钥管理，因为SA的序列空间到期之前需要重新密钥。这是必要的，以便接收方可以使用内置的IPsec重播攻击保护，该保护可能用于具有单个源（ALC发送方）的IPsec SA。因此，接收器应为用于保护ALC发送方通信的SA启用重放攻击保护。必须将发送方IPsec SPD条目配置为处理到适用ALC会话的目标地址和UDP端口号的出站数据包。
The ALC receiver(s) MUST be configured with the SA and SPD entry to properly process the IPsec-secured packets from the sender. Note that use of ESP confidentiality, as RECOMMENDED, for secure ALC protocol operation makes it more difficult for adversaries to conduct effective replay attacks that may mislead receivers on content reception. This baseline approach can be used for ALC protocol sessions with multiple senders if a distinct SA is established for each sender.
ALC接收器必须配置SA和SPD条目，以正确处理来自发送方的IPsec安全数据包。请注意，建议使用ESP机密性进行安全ALC协议操作，这会使对手更难进行有效的重播攻击，从而在内容接收上误导接收者。如果为每个发送方建立了不同的SA，则此基线方法可用于具有多个发送方的ALC协议会话。
In early deployments of this baseline approach to ALC security, it is anticipated that key management will be conducted out-of-band with respect to ALC protocol operation. For ALC unidirectional operation, it is possible that receivers may retrieve keying information from a central server via out-of-band (with respect to ALC) communication as needed or otherwise conduct group key updates with a similar centralized approach. However, it may be possible with some key management schemes for rekey messages to be transmitted to the group as a message or transport object within the ALC reliable transfer session. An additional specification is necessary to define an in-band key management scheme for ALC sessions perhaps using the mechanisms of the automated group key management specifications cited in this document.
在ALC安全性基线方法的早期部署中，预计密钥管理将在ALC协议操作的带外进行。对于ALC单向操作，接收机可以根据需要通过带外（关于ALC）通信从中央服务器检索密钥信息，或者以类似的集中式方法执行组密钥更新。然而，通过一些密钥管理方案，可以在ALC可靠传输会话内将密钥更新消息作为消息或传输对象发送到组。可能使用本文档中引用的自动组密钥管理规范的机制，需要一个附加规范来定义ALC会话的带内密钥管理方案。
In order to implement this secure mode of ALC protocol operation, the following IPsec capabilities are required.
为了实现ALC协议操作的这种安全模式，需要以下IPsec功能。
The implementation MUST be able to use the source address, destination address, protocol (UDP), and UDP port numbers as selectors in the SPD.
实现必须能够使用源地址、目标地址、协议（UDP）和UDP端口号作为SPD中的选择器。
IPsec in transport mode MUST be supported. The use of IPsec [RFC4301] processing for secure ALC traffic SHOULD also be REQUIRED such that unauthenticated packets are not received by the ALC protocol implementation.
必须支持传输模式下的IPsec。还应要求使用IPsec[RFC4301]处理安全ALC通信，以便ALC协议实现不会接收未经验证的数据包。
An automated key management scheme for group key distribution and rekeying such as the Group Domain of Interpretation (GDOI) [RFC3547], Group Secure Association Key Management Protocol (GSAKMP) [RFC4535], or Multimedia Internet KEYing (MIKEY) [RFC3830] SHOULD be used. Relatively short-lived ALC sessions MAY be able to use Manual Keying with a single, preplaced key, particularly if Extended Sequence Numbering (ESN) [RFC4303] is available in the IPsec implementation used. It should also be noted that it may be possible for key update messages (e.g., the GDOI GROUPKEY-PUSH message) to be included in the ALC application reliable data transmission as transport objects if appropriate interfaces were available between the ALC application and the key management daemon.
应使用用于组密钥分发和密钥更新的自动密钥管理方案，例如组解释域（GDOI）[RFC3547]、组安全关联密钥管理协议（GSAKMP）[RFC4535]或多媒体互联网密钥更新（MIKEY）[RFC3830]。寿命相对较短的ALC会话可能能够使用带有单个预放置密钥的手动密钥，特别是在使用的IPsec实现中存在扩展序列编号（ESN）[RFC4303]的情况下。还应注意，如果ALC应用程序和密钥管理守护程序之间有适当的接口，则密钥更新消息（例如，GDOI GROUPKEY-PUSH消息）可以作为传输对象包含在ALC应用程序可靠数据传输中。
Receivers SHOULD accept connections only from the designated, authorized sender(s). It is expected that appropriate key management will provide encryption keys only to receivers authorized to participate in a designated session. The approach outlined here allows receiver sets to be controlled on a per-sender basis.
接收者应只接受指定的、授权的发送者的连接。预期适当的密钥管理将仅向授权参与指定会话的接收者提供加密密钥。这里概述的方法允许在每个发送方的基础上控制接收方集。
Large ALC group sizes may necessitate some form of key management that does rely upon shared secrets. The GDOI and GSAKMP protocols mentioned here allow for certificate-based authentication. These certificates SHOULD use IP addresses for authentication. However, it is likely that available group key management implementations will not be ALC-specific.
较大的ALC组大小可能需要某种形式的密钥管理，这种管理依赖于共享机密。这里提到的GDOI和GSAKMP协议允许基于证书的身份验证。这些证书应使用IP地址进行身份验证。但是，可用的组密钥管理实现可能不是特定于ALC的。
The IPsec requirements profile outlined here is commonly available on many potential ALC hosts. The principal issue is that configuration and operation of IPsec typically requires privileged user authorization. Automated key management implementations are typically configured with the privileges necessary to allow the needed system IPsec configuration.
此处概述的IPsec需求概要文件通常可在许多潜在的ALC主机上使用。主要问题是IPsec的配置和操作通常需要特权用户授权。自动密钥管理实现通常配置有允许所需系统IPsec配置所需的特权。
This specification registers one value in the LCT Header Extensions Types namespace as follows:
此规范在LCT标头扩展类型命名空间中注册一个值，如下所示：
+-------+---------+--------------------+
| Value | Name | Reference |
+-------+---------+--------------------+
| 64 | EXT_FTI | This specification |
+-------+---------+--------------------+
+-------+---------+--------------------+
| Value | Name | Reference |
+-------+---------+--------------------+
| 64 | EXT_FTI | This specification |
+-------+---------+--------------------+
This specification is substantially based on RFC 3450 [RFC3450] and thus credit for the authorship of this document is primarily due to the authors of RFC 3450: Mike Luby, Jim Gemmel, Lorenzo Vicisano, Luigi Rizzo, and Jon Crowcroft. Vincent Roca, Justin Chapweske, and Roger Kermode also contributed to RFC 3450. Additional thanks are due to Vincent Roca and Rod Walsh for contributions to this update to Proposed Standard.
本规范基本上基于RFC 3450[RFC3450]，因此本文件的作者资格主要归功于RFC 3450的作者：Mike Luby、Jim Gemmel、Lorenzo Vicisano、Luigi Rizzo和Jon Crowcroft。文森特·罗卡、贾斯汀·查普韦斯克和罗杰·克莫德也为RFC3450捐款。另外还要感谢Vincent Roca和Rod Walsh为本次标准更新做出的贡献。
This section summarizes the changes that were made from the "Experimental" version of this specification published as RFC 3450 [RFC3450]:
本节总结了本规范“实验性”版本（RFC 3450[RFC3450]）所做的更改：
o Updated all references to the obsoleted RFC 2068 to RFC 2616.
o 将所有废弃RFC 2068的参考资料更新为RFC 2616。
o Removed the 'Statement of Intent' from the introduction. (The Statement of Intent was meant to clarify the "Experimental" status of RFC 3450.)
o 从介绍中删除“意向声明”。（意向声明旨在澄清RFC 3450的“实验”状态。）
o Removed the 'Intellectual Property Issues' Section and replaced with a standard IPR Statement.
o 删除“知识产权问题”部分，并替换为标准的知识产权声明。
o Removed material duplicated in LCT.
o 已删除LCT中重复的材料。
o Updated references in this document to new versions of the LCT Building Block and the FEC Building Block, and aligned this document with changes in the new version of the FEC Building Block.
o 更新了本文档中对LCT构建块和FEC构建块新版本的引用，并使本文档与FEC构建块新版本中的更改保持一致。
o Split normative and informative references.
o 将规范性参考和信息性参考分开。
o Material applicable in a general LCT context, not just for ALC has been moved to LCT.
o 适用于一般LCT环境的材料（不仅仅适用于ALC）已移至LCT。
o The first bit of the "Protocol-Specific Indication" in the LCT Header is defined as a "Source Packet Indication". This is used in the case that an FEC Scheme defines two FEC Payload ID formats, one of which is for packets containing only source symbols that can be processed by receivers that do not support FEC Decoding.
o LCT报头中“协议特定指示”的第一位被定义为“源数据包指示”。这在FEC方案定义两种FEC有效载荷ID格式的情况下使用，其中一种用于仅包含可由不支持FEC解码的接收机处理的源符号的分组。
o Definition and IANA registration of the EXT_FTI LCT Header Extension.
o EXT_FTI LCT头扩展的定义和IANA注册。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]Deering，S.，“IP多播的主机扩展”，STD 5，RFC11121989年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023]Murata，M.，St.Laurent，S.，和D.Kohn，“XML媒体类型”，RFC 3023，2001年1月。
[RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate Control (WEBRC) Building Block", RFC 3738, April 2004.
[RFC3738]Luby，M.和V.Goyal，“基于波动和方程的速率控制（WEBRC）构造块”，RFC 3738，2004年4月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction (FEC) Building Block", RFC 5052, August 2007.
[RFC5052]Watson，M.，Luby，M.，和L.Vicisano，“前向纠错（FEC）构建块”，RFC 5052，2007年8月。
[RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding Transport (LCT) Building Block", RFC 5651, October 2009.
[RFC5651]Luby，M.，Watson，M.，和L.Vicisano，“分层编码传输（LCT）构建块”，RFC 5651，2009年10月。
[RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
[RFC2357]Mankin，A.，Romanov，A.，Bradner，S.，和V.Paxson，“IETF评估可靠多播传输和应用协议的标准”，RFC 2357，1998年6月。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974]Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，RFC 2974，2000年10月。
[RFC3048] 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.
[RFC3048]Whetten，B.，Vicisano，L.，Kermode，R.，Handley，M.，Floyd，S.，和M.Luby，“一对多批量数据传输的可靠多播传输构建块”，RFC 3048，2001年1月。
[RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents", RFC 3269, April 2002.
[RFC3269]Kermode，R.和L.Vicisano，“可靠多播传输（RMT）构建块和协议实例化文档的作者指南”，RFC 3269，2002年4月。
[RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J. Crowcroft, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 3450, December 2002.
[RFC3450]Luby，M.，Gemmell，J.，Vicisano，L.，Rizzo，L.，和J.Crowcroft，“异步分层编码（ALC）协议实例化”，RFC 3450，2002年12月。
[RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "The Use of Forward Error Correction (FEC) in Reliable Multicast", RFC 3453, December 2002.
[RFC3453]Luby，M.，Vicisano，L.，Gemmell，J.，Rizzo，L.，Handley，M.，和J.Crowcroft，“在可靠多播中使用前向纠错（FEC）”，RFC 3453，2002年12月。
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3547]Baugher，M.，Weis，B.，Hardjono，T.，和H.Harney，“解释的集团领域”，RFC 3547，2003年7月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC3569] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003.
[RFC3569]Bhattacharyya，S.，“源特定多播（SSM）概述”，RFC 3569，2003年7月。
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[RFC3618]Fenner，B.和D.Meyer，“多播源发现协议（MSDP）”，RFC3618，2003年10月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[RFC3830]Arkko，J.，Carrara，E.，Lindholm，F.，Naslund，M.，和K.Norrman，“米奇：多媒体互联网键控”，RFC 3830，2004年8月。
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006.
[RFC4535]Harney，H.，Meth，U.，Colegrove，A.，和G.Gross，“GSAKMP：组安全关联密钥管理协议”，RFC 45352006年6月。
[RFC5776] Roca, V., Francillon, A., and S. Faurite, "Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols", RFC 5776, April 2010.
[RFC5776]Roca，V.，Francillon，A.，和S.Faurite，“在异步分层编码（ALC）和面向NACK的可靠多播（NORM）协议中使用定时高效流丢失容忍认证（TESLA）”，RFC 5776，2010年4月。
[RMT-SIMPLE] Roca, V., "Simple Authentication Schemes for the ALC and NORM Protocols", Work in Progress, October 2009.
[RMT-SIMPLE]Roca，V.“ALC和NORM协议的简单认证方案”，正在进行的工作，2009年10月。
Authors' Addresses
作者地址
Michael Luby Qualcomm, Inc. 3165 Kifer Road Santa Clara, CA 95051 US
Michael Luby Qualcomm，Inc.美国加利福尼亚州圣克拉拉基弗路3165号，邮编95051
EMail: luby@qualcomm.com
EMail: luby@qualcomm.com
Mark Watson Qualcomm, Inc. 3165 Kifer Road Santa Clara, CA 95051 US
美国加利福尼亚州圣克拉拉基弗路3165号马克·沃森高通公司，邮编95051
EMail: watson@qualcomm.com
EMail: watson@qualcomm.com
Lorenzo Vicisano Qualcomm, Inc. 3165 Kifer Road Santa Clara, CA 95051 US
美国加利福尼亚州圣克拉拉基弗路3165号洛伦佐·维西萨诺高通公司，邮编95051
EMail: vicisano@qualcomm.com
EMail: vicisano@qualcomm.com