Network Working Group M. Luby
Request for Comments: 3450 Digital Fountain
Category: Experimental J. Gemmell
Microsoft
L. Vicisano
Cisco
L. Rizzo
Univ. Pisa
J. Crowcroft
Cambridge Univ.
December 2002
Network Working Group M. Luby
Request for Comments: 3450 Digital Fountain
Category: Experimental J. Gemmell
Microsoft
L. Vicisano
Cisco
L. Rizzo
Univ. Pisa
J. Crowcroft
Cambridge Univ.
December 2002
Asynchronous Layered Coding (ALC) Protocol Instantiation
异步分层编码（ALC）协议实例化
Status of this Memo
本备忘录的状况
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
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.
本文档描述了异步分层编码（ALC）协议，这是一种可大规模扩展的可靠内容交付协议。异步分层编码结合了分层编码传输（LCT）构建块、多速率拥塞控制构建块和前向纠错（FEC）构建块，以从单个发送方向无限多个并发接收方提供拥塞控制的可靠异步内容交付。
Table of Contents
目录
1. Introduction.................................................2
1.1 Delivery service models...................................3
1.2 Scalability...............................................5
1.3 Environmental Requirements and Considerations.............6
2. Architecture Definition......................................8
2.1 LCT building block........................................9
2.2 Multiple rate congestion control building block..........10
2.3 FEC building block.......................................11
2.4 Session Description......................................13
1. Introduction.................................................2
1.1 Delivery service models...................................3
1.2 Scalability...............................................5
1.3 Environmental Requirements and Considerations.............6
2. Architecture Definition......................................8
2.1 LCT building block........................................9
2.2 Multiple rate congestion control building block..........10
2.3 FEC building block.......................................11
2.4 Session Description......................................13
2.5 Packet authentication building block.....................14
3. Conformance Statement.......................................14
4. Functionality Definition....................................14
4.1 Packet format used by ALC................................15
4.2 Detailed Example of Packet format used by ALC............16
4.3 Header-Extension Fields..................................23
4.4 Sender Operation.........................................26
4.5 Receiver Operation.......................................27
5. Security Considerations.....................................29
6. IANA Considerations.........................................31
7. Intellectual Property Issues................................31
8. Acknowledgments.............................................31
9. References..................................................31
Authors' Addresses.............................................33
Full Copyright Statement.......................................34
2.5 Packet authentication building block.....................14
3. Conformance Statement.......................................14
4. Functionality Definition....................................14
4.1 Packet format used by ALC................................15
4.2 Detailed Example of Packet format used by ALC............16
4.3 Header-Extension Fields..................................23
4.4 Sender Operation.........................................26
4.5 Receiver Operation.......................................27
5. Security Considerations.....................................29
6. IANA Considerations.........................................31
7. Intellectual Property Issues................................31
8. Acknowledgments.............................................31
9. References..................................................31
Authors' Addresses.............................................33
Full Copyright Statement.......................................34
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
ALC的发送方包括基于会话中要传递的对象生成数据包，并以适当的速率将适当格式化的数据包发送到与会话相关联的信道。ALC的接收器侧包括加入与会话相关联的适当信道，通过响应于检测到的拥塞而调整与会话相关联的加入信道集来执行拥塞控制，以及
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 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 RFC 3269 [8].
本文件是IETF RMT工作组的产品，遵循RFC 3269[8]中提供的一般指南。
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, RFC 2119 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[2]中的描述进行解释。
Statement of Intent
意向书
This memo contains part of the definitions necessary to fully specify a Reliable Multicast Transport protocol in accordance with RFC2357. As per RFC2357, the use of any reliable multicast protocol in the Internet requires an adequate congestion control scheme.
本备忘录包含根据RFC2357完全指定可靠多播传输协议所需的部分定义。根据RFC2357，在互联网上使用任何可靠的多播协议都需要适当的拥塞控制方案。
While waiting for such a scheme to be available, or for an existing scheme to be proven adequate, the Reliable Multicast Transport working group (RMT) publishes this Request for Comments in the "Experimental" category.
在等待此类方案可用或现有方案被证明足够时，可靠多播传输工作组（RMT）在“实验性”类别中发布此评论请求。
It is the intent of RMT to re-submit this specification as an IETF Proposed Standard as soon as the above condition is met.
RMT的目的是，一旦满足上述条件，立即将本规范作为IETF建议的标准重新提交。
ALC can support several different reliable content delivery service models. Some examples are briefly described here.
ALC可以支持多种不同的可靠内容交付服务模式。这里简要介绍一些例子。
Push service model.
推送服务模式。
A push model is a sender initiated concurrent delivery of objects to a selected set of receivers. A push service model can be used for example for reliable delivery of a large object such as a 100 GB file. The sender could send a Session Description announcement to a
推送模型是发送方发起的将对象并发交付给选定的一组接收方的模型。例如，推送服务模型可用于可靠地交付大型对象，例如100GB文件。发件人可以将会话说明通知发送给
control channel and receivers could monitor this channel and join a session whenever a Session Description of interest arrives. Upon receipt of the Session Description, each receiver could join the session to receive packets until enough packets have arrived to reconstruct the object, at which point the receiver could report back to the sender that its reception was completed successfully. The sender could decide to continue sending packets for the object to the session until all receivers have reported successful reconstruction or until some other condition has been satisfied. In this example, the sender uses ALC to generate packets based on the object and send packets to channels associated with the session, and the receivers use ALC to receive packets from the session and reconstruct the object.
控制通道和接收器可以监视此通道，并在感兴趣的会话描述到达时加入会话。在接收到会话描述后，每个接收器都可以加入会话以接收数据包，直到有足够的数据包到达以重构对象，此时接收器可以向发送者报告其接收已成功完成。发送方可以决定继续向会话发送对象的数据包，直到所有接收方都报告成功重建，或者直到满足某些其他条件。在此示例中，发送方使用ALC基于对象生成分组并将分组发送到与会话相关联的信道，接收方使用ALC从会话接收分组并重构对象。
There are several features ALC provides to support the push model. For example, the sender can optionally include an Expected Residual Time (ERT) in the packet header that indicates the expected remaining time of packet transmission for either the single object carried in the session or for the object identified by the Transmission Object Identifier (TOI) if there are multiple objects carried in the session. This can be used by receivers to determine if there is enough time remaining in the session to successfully receive enough additional packets to recover the object. If for example there is not enough time, then the push application may have receivers report back to the sender to extend the transmission of packets for the object for enough time to allow the receivers to obtain enough packets to reconstruct the object. The sender could then include an ERT based on the extended object transmission time in each subsequent packet header for the object. As other examples, the LCT header optionally can contain a Close Session flag that indicates when the sender is about to end sending packet to the session and a Close Object flag that indicates when the sender is about to end sending packets to the session for the object identified by the Transmission Object ID. However, these flags are not a completely reliable mechanism and thus the Close Session flag should only be used as a hint of when the session is about to close and the Close Object flag should only be used as a hint of when transmission of packets for the object is about to end.
ALC提供了几个功能来支持推送模式。例如，发送方可以可选地在分组报头中包括预期剩余时间（ERT），该预期剩余时间指示会话中承载的单个对象或由传输对象标识符（TOI）标识的对象（如果会话中承载多个对象）的分组传输的预期剩余时间。接收者可以使用它来确定会话中是否有足够的剩余时间来成功接收足够的附加数据包以恢复对象。例如，如果没有足够的时间，则推送应用程序可使接收器向发送器报告，以将对象的分组的传输延长足够的时间，以允许接收器获得足够的分组来重构对象。然后，发送方可以基于对象的每个后续分组报头中的扩展对象传输时间包括ERT。作为其他示例，LCT报头可选择性地包含指示发送方何时将结束向会话发送分组的关闭会话标志和指示发送方何时将结束向会话发送由传输对象ID标识的对象的分组的关闭对象标志。然而，这些标志不是一种完全可靠的机制，因此关闭会话标志只应作为会话即将关闭的提示，而关闭对象标志只应作为对象数据包传输即将结束的提示。
The push model is particularly attractive in satellite networks and wireless networks. In these environments a session may include one channel and a sender may send packets at a fixed rate to this channel, but sending at a fixed rate without congestion control is outside the scope of this document.
推送模式在卫星网络和无线网络中特别有吸引力。在这些环境中，会话可能包括一个通道，发送方可能以固定速率向该通道发送数据包，但以固定速率发送而不进行拥塞控制超出了本文档的范围。
On-demand content delivery model.
按需内容交付模型。
For an on-demand content delivery service model, senders typically transmit for some given time period selected to be long enough to allow all the intended receivers to join the session and recover a single object. For example a popular software update might be transmitted using ALC for several days, even though a receiver may be able to complete the download in one hour total of connection time, perhaps spread over several intervals of time. In this case the receivers join the session at any point in time when it is active. Receivers leave the session when they have received enough packets to recover the object. The receivers, for example, obtain a Session Description by contacting a web server.
对于按需内容交付服务模型，发送方通常在指定的时间段内进行传输，该时间段被选择为足够长，以允许所有预期接收方加入会话并恢复单个对象。例如，一个流行的软件更新可能使用ALC传输几天，即使接收器可能能够在连接时间的一个小时内完成下载，可能在几个时间间隔内完成。在这种情况下，当会话处于活动状态时，接收器会在任何时间点加入会话。接收方在收到足够的数据包以恢复对象时离开会话。例如，接收者通过联系web服务器获得会话描述。
Other service models.
其他服务模式。
There may be other reliable content delivery service models that can be supported by ALC. The description of the potential applications, the appropriate delivery service model, and the additional mechanisms to support such functionalities when combined with ALC is beyond the scope of this document.
ALC可能还支持其他可靠的内容交付服务模式。当与ALC结合时，对潜在应用、适当的交付服务模型以及支持此类功能的附加机制的描述超出了本文档的范围。
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 though 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 is joined to the session 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 [11], the FEC building block [10], the multiple rate congestion control building block and to any additional building blocks that ALC uses also apply to ALC.
适用于LCT构建块[11]、FEC构建块[10]、多速率拥塞控制构建块以及ALC使用的任何其他构建块的所有环境要求和注意事项也适用于ALC。
ALC requires connectivity between a sender and receivers, but does not require connectivity from receivers to a sender. ALC inherently works with all types of networks, including LANs, WANs, Intranets, the Internet, asymmetric networks, wireless networks, and satellite networks. Thus, the inherent raw scalability of ALC is unlimited. However, ALC requires receivers to obtain the Session Description out-of-band before joining a session and some implementations of this may limit scalability.
ALC需要发送方和接收方之间的连接，但不需要从接收方到发送方的连接。ALC天生适用于所有类型的网络，包括局域网、广域网、内部网、互联网、非对称网络、无线网络和卫星网络。因此，ALC固有的原始可伸缩性是无限的。然而，ALC要求接收者在加入会话之前获得带外会话描述，这种情况的一些实现可能会限制可伸缩性。
If a receiver is joined to multiple ALC sessions then the receiver MUST be able to uniquely identify and demultiplex packets to the correct session. The Transmission Session Identifier (TSI) that MUST appear in each packet header is used for this purpose. The TSI is scoped by the IP address of the sender, and the IP address of the sender together with the TSI uniquely identify the session. Thus, the demultiplexing MUST be done on the basis of the IP address of the sender and the TSI of the session from that sender.
如果接收器加入多个ALC会话，则接收器必须能够唯一地识别数据包并将其解复用到正确的会话。必须出现在每个分组报头中的传输会话标识符（TSI）用于此目的。TSI的范围由发送方的IP地址确定，发送方的IP地址与TSI一起唯一标识会话。因此，解复用必须基于发送方的IP地址和来自该发送方的会话的TSI来完成。
ALC is presumed to be used with an underlying IP multicast network or transport service that is a "best effort" service that does not guarantee packet reception, packet reception order, and which does not have any support for flow or congestion control. There are currently two models of multicast delivery, the Any-Source Multicast (ASM) model as defined in RFC 1112 [3] and the Source-Specific Multicast (SSM) model as defined in [7]. ALC works with both multicast models, but in a slightly different way with somewhat different environmental concerns. When using ASM, a sender S sends packets to a multicast group G, and an ALC channel address consists of the pair (S,G), where S is the IP address of the sender and G is a
ALC被假定与底层IP多播网络或传输服务一起使用，该服务是“尽力”服务，不保证数据包接收、数据包接收顺序，并且不支持流量或拥塞控制。目前有两种多播交付模型，RFC 1112[3]中定义的任意源多播（ASM）模型和[7]中定义的源特定多播（SSM）模型。ALC适用于这两种多播模型，但在环境问题上略有不同。当使用ASM时，发送方S向多播组G发送数据包，并且ALC信道地址由该对（S，G）组成，其中S是发送方的IP地址，G是地址
multicast group address. When using SSM, a sender S sends packets to an SSM channel (S,G), and an ALC channel address coincides with the SSM channel address.
多播组地址。当使用SSM时，发送方S向SSM信道（S，G）发送数据包，并且ALC信道地址与SSM信道地址一致。
A sender can locally allocate unique SSM channel addresses, and this makes allocation of ALC channel addresses easy with SSM. To allocate ALC channel addresses using ASM, the sender must uniquely choose the ASM multicast group address across the scope of the group, and this makes allocation of ALC channel addresses more difficult with ASM.
发送方可以在本地分配唯一的SSM通道地址，这使得使用SSM分配ALC通道地址变得容易。要使用ASM分配ALC通道地址，发送方必须在组范围内唯一选择ASM多播组地址，这使得使用ASM分配ALC通道地址更加困难。
ALC channels and SSM channels coincide, and thus the receiver will only receive packets sent to the requested ALC channel. With ASM, the receiver joins an ALC channel by joining a multicast group G, and all packets sent to G, regardless of the sender, may be received by the receiver. Thus, SSM has compelling security advantages over ASM for prevention of denial of service attacks. In either case, receivers SHOULD use mechanisms to filter out packets from unwanted sources.
ALC信道和SSM信道重合，因此接收机将只接收发送到请求的ALC信道的数据包。使用ASM，接收器通过加入多播组G来加入ALC信道，并且发送到G的所有数据包，无论发送者是谁，都可以由接收器接收。因此，与ASM相比，SSM在防止拒绝服务攻击方面具有引人注目的安全优势。在这两种情况下，接收者都应该使用机制从不需要的来源过滤掉数据包。
Other issues 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 uses 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 MSDP 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 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.
与ASM相关的ALC特有的其他问题是多速率拥塞控制构建块与ASM交互的方式。拥塞控制构建块可以使用在发送到信道的加入和来自信道的第一分组到达之间测量的时间差来确定接收机接收速率。拥塞控制构建块还可以使用每个信道的分组序列号来测量丢失，并且这也用于确定接收机接收速率。这些特性引起了与ASM有关的两个问题：由于使用了集合点（RPs）和MSDP协议，发送到通道的连接和第一个数据包到达之间的时间差可能很大，并且数据包可能在从（*，G）连接到RP和（S，G）连接的切换中丢失直接加入发件人。这两个问题都可能严重降低接收机的接收速率。为了改善这些问题，建议RP尽可能靠近发送方。SSM没有这些相同的担忧。要更全面地考虑这些问题，请参考多速率拥塞控制构建块。
Some networks are not amenable to some congestion control protocols that could be used with ALC. In particular, for a satellite or wireless network, there may be no mechanism for receivers to effectively reduce their reception rate since there may be a fixed transmission rate allocated to the session.
有些网络不适用于某些可与ALC一起使用的拥塞控制协议。具体地，对于卫星或无线网络，可能没有用于接收器有效降低其接收速率的机制，因为可能存在分配给会话的固定传输速率。
ALC is compatible with either IPv4 or IPv6 as no part of the packet is IP version specific.
ALC与IPv4或IPv6兼容，因为数据包的任何部分都不是特定于IP版本的。
ALC uses the LCT building block [11] to provide in-band session management functionality. ALC uses a multiple rate congestion control building block that is compliant with RFC 2357 [12] 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 [10] 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 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.
ALC使用LCT构建块[11]提供带内会话管理功能。ALC使用符合RFC 2357[12]的多速率拥塞控制构建块来提供无反馈的拥塞控制。接收机通过加入和离开与会话相关的频道来单独调整接收速率。ALC使用FEC构建块[10]提供可靠性。发送方使用FEC码基于要传送的对象生成编码符号，并将它们以分组的形式发送到与会话相关联的信道。接收器只是等待足够的数据包到达，以便可靠地重建对象。因此，不存在为了确保对象的可靠接收而错过分组的接收机对单个分组的重传的请求，并且分组及其从发送方发送出去的速率可以独立于接收机的数目和单个接收体验。
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 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 RFC 3048 [16]. This document describes version 1 of ALC which MUST use version 1 of LCT described in [11]. 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 [15] that supports IP multicast delivery of packets. Future versions of this specification, or companion documents may extend ALC to use the IP network layer service directly. ALC could be used as the basis for designing a protocol that uses a different underlying network service such as unicast UDP, but the design of such a protocol is outside the scope of this document.
ALC是RFC 3048[16]中定义的协议实例化。本文件描述了ALC版本1，该版本必须使用[11]中所述的LCT版本1。与LCT一样，ALC设计用于IP多播网络服务。本规范将ALC定义为UDP传输协议[15]的有效负载，该协议支持数据包的IP多播传送。本规范的未来版本或配套文档可能会扩展ALC以直接使用IP网络层服务。ALC可以用作设计使用不同底层网络服务（如单播UDP）的协议的基础，但此类协议的设计不在本文档的范围内。
An ALC packet header immediately follows the UDP header and consists of the default LCT header that is described in [11] followed by the FEC Payload ID that is described in [10]. The Congestion Control Information field within the LCT header carries the required
ALC数据包报头紧跟在UDP报头之后，由[11]中描述的默认LCT报头和[10]中描述的FEC有效负载ID组成。LCT报头中的拥塞控制信息字段包含所需的
Congestion Control Information that is described in the multiple rate congestion control building block specified that is compliant with RFC 2357 [12]. The packet payload that follows the ALC packet header consists of encoding symbols that are identified by the FEC Payload ID as described in [10].
指定的符合RFC 2357[12]的多速率拥塞控制构建块中描述的拥塞控制信息。ALC分组报头之后的分组有效载荷由编码符号组成，编码符号由FEC有效载荷ID标识，如[10]所述。
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 [10] 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构建块[10]中指定的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 Information as specified in the FEC building block [10] 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.
LCT报头包含一个代码点字段，该字段可用于将会话期间可能发生变化的信息的设置传达给接收器。如果使用，设置和代码点值之间的映射将在会话描述中传达，并且此映射不在本文档的范围内。例如，作为FEC构建块[10]中指定的FEC对象传输信息的一部分的FEC编码ID可以针对会话中携带的每个对象而变化，并且可以使用代码点值来传递要用于每个对象的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 MAY NOT 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 default LCT header from version 1 of the LCT building block [11] MUST be used.
必须使用LCT构造块[11]版本1中的默认LCT标头。
Implementors of ALC MUST implement a multiple rate feedback-free congestion control building block that is in accordance to RFC 2357 [12]. 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. The multiple rate congestion control building block MUST specify in-band Congestion Control Information (CCI) that MUST be carried in the CCI field of the LCT header. The multiple rate congestion control building block MAY specify more than one format, 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的实施者必须按照RFC 2357[12]的要求实施无多速率反馈拥塞控制构建块。拥塞控制必须应用于会话中的所有数据包，而与每个数据包中携带的对象相关的信息无关。指定多速率拥塞控制是因为它适合大规模扩展，并且适合可靠的内容交付。多速率拥塞控制构建块必须指定必须在LCT标头的CCI字段中携带的带内拥塞控制信息（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 which set of channels they are joined to 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 [10] provides reliable object delivery within an ALC session. Each object sent in the session is independently encoded using FEC codes as described in [9], 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 building block [10]. 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构建块[10]在ALC会话中提供可靠的对象传递。会话中发送的每个对象都使用FEC代码进行独立编码，如[9]中所述，这为可靠内容交付协议中FEC代码的使用提供了更深入的描述。ALC会话中的所有数据包必须包含符合FEC构建块格式的FEC有效负载ID[10]。FEC有效载荷ID唯一地标识构成每个分组的有效载荷的编码符号，并且接收机必须使用FEC有效载荷ID来确定分组的有效载荷中携带的编码符号是如何从FEC构建块中描述的对象生成的。
As described in [10], a receiver is REQUIRED to obtain the FEC Object Transmission Information for each object for which data packets are received from the session. The FEC Object Transmission Information includes:
如[10]中所述，接收机需要获得从会话接收数据分组的每个对象的FEC对象传输信息。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 length of the object in bytes.
o 对于会话中的每个对象，以字节为单位的对象长度。
o The additional required FEC Object Transmission Information for the FEC Encoding ID as prescribed in the FEC building block [10]. For example, when the FEC Encoding ID is 128, the required FEC Object Transmission Information is the number of source blocks that the object is partitioned into and the length of each source block in bytes.
o FEC构建块[10]中规定的FEC编码ID所需的附加FEC对象传输信息。例如，当FEC编码ID为128时，所需的FEC对象传输信息是对象被划分成的源块的数量和每个源块的长度（以字节为单位）。
Some of the FEC Object Transmission Information MAY be implicit based on the 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编码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 times the objects may not know when the session begins, or 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 either 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对象传输信息可以在从会话接收对象的分组时或之前动态地传送给接收机。这可以使用带外机制、使用码点字段或报头扩展的带内机制或这些方法的任何组合来实现。如何将FEC对象传输信息传送给接收机不在本文档的范围内。
If packets for more than one object are transmitted within a session then a Transmission Object Identifier (TOI) that uniquely identifies objects within a session MUST appear in each packet header. Portions of the FEC Object Transmission Information could be the same for all objects in the session, in which case these portions can be communicated to the receiver with an indication that this applies to all objects in the session. These portions may be implicitly determined based on the application, e.g., an application may use the same FEC Encoding ID for all objects in all sessions. If there is a portion of the FEC Object Transmission Information that may vary from object to object and if this FEC Object Transmission Information is communicated to a receiver out-of-band then the TOI for the object MUST also be communicated to the receiver together with the corresponding FEC Object Transmission Information, and the receiver MUST use the corresponding FEC Object Transmission Information for all packets received with that TOI. How the TOI and corresponding FEC Object Transmission Information is communicated out-of-band to receivers is outside the scope of this document.
如果在一个会话中传输多个对象的数据包，则在每个数据包报头中必须出现唯一标识会话中对象的传输对象标识符（TOI）。对于会话中的所有对象，FEC对象传输信息的部分可以是相同的，在这种情况下，可以将这些部分传送给接收机，并指示这适用于会话中的所有对象。这些部分可以基于应用隐式地确定，例如，应用可以对所有会话中的所有对象使用相同的FEC编码ID。如果FEC对象传输信息的一部分可能因对象而异，并且如果该FEC对象传输信息在带外传送给接收机，则该对象的TOI也必须与相应的FEC对象传输信息一起传送给接收机，并且接收机必须对使用该TOI接收的所有分组使用相应的FEC对象传输信息。TOI和相应的FEC对象传输信息如何在带外传送给接收机不在本文件的范围内。
It is also possible that there is a portion of the FEC Object Transmission Information that may vary from object to object that is carried in-band, for example in the CodePoint field or in Header Extensions. How this is done is outside the scope of this document. In this case the FEC Object Transmission Information is associated with the object identified by the TOI carried in the packet.
还可能存在FEC对象传输信息的一部分，该部分信息可能因对象而异，例如在码点字段或报头扩展中在频带中携带。如何做到这一点超出了本文件的范围。在这种情况下，FEC对象传输信息与由分组中携带的TOI标识的对象相关联。
The Session Description that a receiver is REQUIRED to obtain before joining an ALC session MUST contain 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 it 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 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.
报头的LCT部分内的Codepoint字段可用于在会话内传送带内一些动态变化的信息。为此，必须在会话描述中包含代码点值和不同动态设置之间的映射，然后通过放入每个数据包中的代码点值传递要使用的设置。例如，可能在同一会话中传递多个对象，并且对不同类型的对象使用不同的FEC编码算法。然后，会话描述可以包含代码点值和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 SDP as defined in RFC 2327 [5], or XML metadata as defined in RFC 3023 [13], or HTTP/Mime headers as defined in RFC 2068 [4], etc. It might be carried in a session announcement protocol such as SAP as defined in RFC 2974 [6], obtained using a proprietary session control protocol, located on a web page with scheduling information, or conveyed via E-mail 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.
会话描述可以是RFC 2327[5]中定义的SDP，或RFC 3023[13]中定义的XML元数据，或RFC 2068[4]中定义的HTTP/Mime头等形式。它可以在会话公告协议（如RFC 2974[6]中定义的SAP）中携带，该协议使用专有会话控制协议获得，位于包含日程安排信息的网页上，或通过电子邮件或其他带外方法传送。关于会话描述格式和向接收者传达会话描述的方法的讨论超出了本文档的范围。
It is RECOMMENDED that implementors of ALC use some packet authentication scheme to protect the protocol from attacks. An example of a possibly suitable scheme is described in [14]. Packet authentication in ALC, if used, is to be integrated through the Header Extension support for packet authentication provided in the LCT building block.
建议ALC的实现者使用一些包认证方案来保护协议免受攻击。[14]中描述了可能合适的方案的示例。ALC中的数据包认证（如果使用）将通过LCT构建块中提供的数据包认证的报头扩展支持进行集成。
This Protocol Instantiation document, in conjunction with the LCT building block [11], the FEC building block [10] and with a multiple rate congestion control building block completely specifies a working reliable multicast transport protocol that conforms to the requirements described in RFC 2357 [12].
本协议实例化文件与LCT构建块[11]、FEC构建块[10]和多速率拥塞控制构建块一起，完全指定了一个工作可靠的多播传输协议，该协议符合RFC 2357[12]中描述的要求。
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 default LCT header followed by the FEC Payload ID followed by the packet payload. The default LCT header is described in the LCT building block [11] and the FEC Payload ID is described in the FEC building block [10]. 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 which object the encoding symbols are generated from. 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构建块[11]中描述，FEC有效负载ID在FEC构建块[10]中描述。LCT标头中的拥塞控制信息字段包含所使用的多速率拥塞控制构建块中描述的所需拥塞控制信息。数据包有效负载包含从对象生成的编码符号。如果会话中携带了多个对象，则必须使用LCT报头中的传输对象ID（TOI）来标识编码符号是从哪个对象生成的。在对象的范围内，分组的有效载荷中携带的编码符号由FEC构建块中描述的FEC有效载荷ID标识。
The version number of ALC specified in this document is 1. This coincides with version 1 of the LCT building block [11] used in this specification. The LCT version number field should be interpreted as the ALC version number field.
本文档中指定的ALC版本号为1。这与本规范中使用的LCT构建块[11]版本1一致。LCT版本号字段应解释为ALC版本号字段。
The overall ALC packet format is depicted in Figure 1. 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. The default LCT header MUST be used by ALC and this default is described in detail in the LCT building block [11].
整个ALC数据包格式如图1所示。该数据包是一个IP数据包，可以是IPv4或IPv6，IP报头位于UDP报头之前。ALC数据包格式不依赖于IP版本号。默认LCT头必须由ALC使用，该默认值在LCT构建块[11]中有详细描述。
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 |
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Default 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 |
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Default LCT header |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Payload ID |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol(s) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - Overall ALC packet format
图1-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的缺失。
A detailed example of an ALC packet starting with the LCT header is shown in Figure 2. In the example, the LCT header is the first 5 32-bit words, the FEC Payload ID is the next 2 32-bit words, and the remainder of the packet is the payload.
图2显示了以LCT报头开始的ALC数据包的详细示例。在该示例中，LCT报头是前5个32位字，FEC有效负载ID是下2个32位字，包的其余部分是有效负载。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 0 |1| 1 |0|1|0|0|0| 5 | 128 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Control Information (CCI, length = 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Session Identifier (TSI, length = 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Object Identifier (TOI, length = 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Current Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 0 |1| 1 |0|1|0|0|0| 5 | 128 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Control Information (CCI, length = 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Session Identifier (TSI, length = 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Object Identifier (TOI, length = 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Current Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol(s) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 - A detailed example of the ALC packet format
图2-ALC数据包格式的详细示例
The LCT portion of the overall ALC packet header is of variable size, which is specified by a length field in the third byte of the header. All integer fields are carried in "big-endian" or "network order" format, that is, most significant byte (octet) first. Bits designated as "padding" or "reserved" (r) MUST by set to 0 by senders and ignored by receivers. Unless otherwise noted, numeric constants in this specification are in decimal (base 10).
整个ALC数据包报头的LCT部分大小可变，由报头第三字节中的长度字段指定。所有整数字段都以“big-endian”或“network-order”格式携带，也就是说，首先是最高有效字节（octet）。指定为“填充”或“保留”（r）的位必须由发送方设置为0，并由接收方忽略。除非另有说明，本规范中的数值常量为十进制（以10为基数）。
The function and length and particular setting of the value for each field in this detailed example of the header is the following, described in the order of their appearance in the header.
标题的这个详细示例中每个字段的功能、长度和特定值设置如下所示，按照它们在标题中的出现顺序进行描述。
ALC version number (V): 4 bits
自动高度控制版本号（V）：4位
Indicates the ALC version number. The ALC version number for this specification is 1 as shown. This is also the LCT version number.
指示自动高度控制版本号。本规范的ALC版本号为1，如图所示。这也是LCT版本号。
Congestion control flag (C): 2 bits
拥塞控制标志（C）：2位
The Congestion Control Information (CCI) field specified by the multiple rate congestion control building block is a multiple of 32-bits in length. The multiple rate congestion control building block MUST specify a format for the CCI. The congestion control building block MAY specify formats for different CCI lengths, where the set of possible lengths is 32, 64, 96 or 128 bits. The value of C MUST match the length of exactly one of the possible formats for the congestion control building block, and this format MUST be used for the CCI field. The value of C MUST be the same for all packets sent to a session.
由多速率拥塞控制构建块指定的拥塞控制信息（CCI）字段是长度为32位的倍数。多速率拥塞控制构建块必须指定CCI的格式。拥塞控制构建块可以为不同的CCI长度指定格式，其中可能的长度集是32、64、96或128位。C的值必须与拥塞控制构建块的一种可能格式的长度完全匹配，并且此格式必须用于CCI字段。对于发送到会话的所有数据包，C的值必须相同。
C=0 indicates the 32-bit CCI field format is to be used. C=1 indicates the 64-bit CCI field format is to be used. C=2 indicates the 96-bit CCI field format is to be used. C=3 indicates the 128-bit CCI field format is to be used.
C=0表示将使用32位CCI字段格式。C=1表示将使用64位CCI字段格式。C=2表示将使用96位CCI字段格式。C=3表示将使用128位CCI字段格式。
In the example C=0 indicates that a 32-bit format is to be used.
在示例中，C=0表示将使用32位格式。
Reserved (r): 2 bits
保留（r）：2位
Reserved for future use. A sender MUST set these bits to zero and a receiver MUST ignore these bits.
保留供将来使用。发送方必须将这些位设置为零，接收方必须忽略这些位。
As required, these bits are set to 0 in the example.
根据需要，这些位在示例中设置为0。
Transport Session Identifier flag (S): 1 bit
传输会话标识符标志：1位
This is the number of full 32-bit words in the TSI field. The TSI field is 32*S + 16*H bits in length. For ALC the length of the TSI field is REQUIRED to be non-zero. This implies that the setting S=0 and H=0 MUST NOT be used.
这是TSI字段中完整的32位字数。TSI字段的长度为32*S+16*H位。对于ALC，TSI字段的长度要求为非零。这意味着不得使用设置S=0和H=0。
In the example S=1 and H=0, and thus the TSI is 32-bits in length.
在示例中，S＝1和H＝0，因此TSI的长度为32位。
Transport Object Identifier flag (O): 2 bits
传输对象标识符标志（O）：2位
This is the number of full 32-bit words in the TOI field. The TOI field is 32*O + 16*H bits in length. If more than one object is to be delivered in the session then the TOI MUST be used, in which case the setting O=0 and H=0 MUST NOT be used.
这是TOI字段中完整的32位字数。TOI字段的长度为32*O+16*H位。如果会话中要交付多个对象，则必须使用TOI，在这种情况下，不得使用设置O=0和H=0。
In the example O=1 and H=0, and thus the TOI is 32-bits in length.
在示例中，O=1和H=0，因此TOI的长度为32位。
Half-word flag (H): 1 bit
半字标志（H）：1位
The TSI and the TOI fields are both multiples of 32-bits plus 16*H bits in length. This allows the TSI and TOI field lengths to be multiples of a half-word (16 bits), while ensuring that the aggregate length of the TSI and TOI fields is a multiple of 32-bits.
TSI和TOI字段的长度都是32位加上16*H位的倍数。这允许TSI和TOI字段长度为半个字（16位）的倍数，同时确保TSI和TOI字段的聚合长度为32位的倍数。
In the example H=0 which indicates that both TSI and TOI are both multiples of 32-bits in length.
在示例中，H=0表示TSI和TOI都是32位长度的倍数。
Sender Current Time present flag (T): 1 bit
发送方当前时间存在标志（T）：1位
T = 0 indicates that the Sender Current Time (SCT) field is not present. T = 1 indicates that the SCT field is present. The SCT is inserted by senders to indicate to receivers how long the session has been in progress.
T=0表示发送方当前时间（SCT）字段不存在。T=1表示存在SCT字段。发送方插入SCT以向接收方指示会话进行了多长时间。
In the example T=1, which indicates that the SCT is carried in this packet.
在示例T＝1中，其指示在该分组中携带SCT。
Expected Residual Time present flag (R): 1 bit
预期剩余时间存在标志（R）：1位
R = 0 indicates that the Expected Residual Time (ERT) field is not present. R = 1 indicates that the ERT field is present.
R=0表示预期剩余时间（ERT）字段不存在。R=1表示存在ERT字段。
The ERT is inserted by senders to indicate to receivers how much longer packets will be sent to the session for either the single object carried in the session or for the object identified by the TOI if there are multiple objects carried in the session. Senders MUST NOT set R = 1 when the ERT for the object is more than 2^32-1 time units (approximately 49 days), where time is measured in units of milliseconds.
发送方插入ERT，以向接收方指示会话中携带的单个对象或TOI标识的对象（如果会话中携带多个对象）的数据包将发送到会话的时间。当对象的ERT超过2^32-1时间单位（约49天）时，发送方不得将R=1设置为以毫秒为单位的时间。
In the example R=0, which indicates that the ERT is not carried in this packet.
在示例R=0中，表示此数据包中未携带ERT。
Close Session flag (A): 1 bit
关闭会话标志（A）：1位
Normally, A is set to 0. The sender MAY set A to 1 when termination of transmission of packets for the session is imminent. A MAY be set to 1 in just the last packet transmitted for the session, or A MAY be set to 1 in the last few seconds of packets transmitted for the session. Once the sender sets A to 1 in one packet, the sender SHOULD set A to 1 in all subsequent packets until termination of transmission of packets for the session. A received packet with A set to 1 indicates to a receiver that the sender will immediately stop sending packets for the session. When a receiver receives a packet with A set to 1 the receiver SHOULD assume that no more packets will be sent to the session.
通常，A设置为0。当用于会话的分组的传输即将终止时，发送方可以将A设置为1。A可以仅在为会话发送的最后一个分组中被设置为1，或者A可以在为会话发送的分组的最后几秒钟中被设置为1。一旦发送方在一个数据包中将A设置为1，发送方应在所有后续数据包中将A设置为1，直到会话的数据包传输终止。设置为1的接收到的数据包向接收方指示发送方将立即停止为会话发送数据包。当接收器接收到设置为1的数据包时，接收器应假定不再向会话发送数据包。
In the example A=0, and thus this packet does not indicate the close of the session.
在示例中，A=0，因此该数据包并不表示会话结束。
Close Object flag (B): 1 bit
关闭对象标志（B）：1位
Normally, B is set to 0. The sender MAY set B to 1 when termination of transmission of packets for an object is imminent. If the TOI field is in use and B is set to 1 then termination of transmission for the object identified by the TOI field is imminent. If the TOI field is not in use and B is set to 1 then termination of transmission for the one object in the session identified by out-of-band information is imminent. B MAY be set to 1 in just the last packet transmitted for the object, or B MAY be set to 1 in the last few seconds packets transmitted for the object. Once the sender sets B to 1 in one packet for a particular object, the sender SHOULD set B to 1 in all subsequent packets for the object until termination of transmission of packets for the object. A received packet with B set to 1 indicates to a receiver that the sender will immediately stop sending packets for the object. When a receiver receives a packet with B set to 1 then it SHOULD assume that no more packets will be sent for the object to the session.
通常，B设置为0。当对象的分组的传输即将终止时，发送方可以将B设置为1。如果TOI字段正在使用且B设置为1，则TOI字段标识的对象的传输即将终止。如果TOI字段未使用且B设置为1，则由带外信息标识的会话中的一个对象的传输即将终止。B可以仅在为对象发送的最后一个分组中被设置为1，或者B可以在为对象发送的最后几秒钟的分组中被设置为1。一旦发送方为特定对象在一个数据包中将B设置为1，发送方应在该对象的所有后续数据包中将B设置为1，直到该对象的数据包传输终止。B设置为1的接收数据包向接收方指示发送方将立即停止发送对象的数据包。当接收器接收到B设置为1的数据包时，它应该假定不再向会话发送对象的数据包。
In the example B=0, and thus this packet does not indicate the end of sending data packets for the object.
在示例中，B=0，因此该数据包并不表示为对象发送数据包的结束。
LCT header length (HDR_LEN): 8 bits
LCT头长度（HDR_LEN）：8位
Total length of the LCT header in units of 32-bit words. The length of the LCT header MUST be a multiple of 32-bits. This field can be used to directly access the portion of the packet beyond the LCT header, i.e., the FEC Payload ID if the packet
LCT标头的总长度，以32位字为单位。LCT头的长度必须是32位的倍数。该字段可用于直接访问LCT报头之外的数据包部分，即，如果数据包被删除，则访问FEC有效负载ID
contains a payload, or the end of the packet if the packet contains no payload.
包含有效负载，如果数据包不包含有效负载，则为数据包的结尾。
In the example HDR_LEN=5 to indicate that the length of the LCT header portion of the overall ALC is 5 32-bit words.
在示例中，HDR_LEN=5表示整个ALC的LCT报头部分的长度为5个32位字。
Codepoint (CP): 8 bits
码点（CP）：8位
This field is used by ALC to carry the mapping that identifies settings for portions of the Session Description that can change within the session. The mapping between Codepoint values and the settings for portions of the Session Description is to be communicated out-of-band.
ALC使用此字段携带映射，该映射标识会话描述中可在会话中更改的部分的设置。代码点值和会话描述部分的设置之间的映射将在带外进行通信。
In the example the portion of the Session Description that can change within the session is the FEC Encoding ID, and the identity mapping is used between Codepoint values and FEC Encoding IDs. Thus, CP=128 identifies FEC Encoding ID 128, the "Small Block, Large Block and Expandable FEC Codes" as described in the FEC building block [10]. The FEC Payload ID associated with FEC Encoding ID 128 is 64-bits in length.
在该示例中，会话描述中可以在会话内更改的部分是FEC编码ID，并且在代码点值和FEC编码ID之间使用标识映射。因此，CP＝128标识FEC编码ID 128，即如FEC构建块[10]中所述的“小块、大块和可扩展的FEC码”。与FEC编码ID 128相关联的FEC有效负载ID的长度为64位。
Congestion Control Information (CCI): 32, 64, 96 or 128 bits
拥塞控制信息（CCI）：32、64、96或128位
This is field contains the Congestion Control Information as defined by the specified multiple rate congestion control building block. The format of this field is determined by the multiple rate congestion control building block.
此字段包含由指定的多速率拥塞控制构建块定义的拥塞控制信息。此字段的格式由多速率拥塞控制构建块确定。
This field MUST be 32 bits if C=0. This field MUST be 64 bits if C=1. This field MUST be 96 bits if C=2. This field MUST be 128 bits if C=3.
如果C=0，此字段必须为32位。如果C=1，此字段必须为64位。如果C=2，此字段必须为96位。如果C=3，此字段必须为128位。
In the example, the CCI is 32-bits in length. The format of the CCI field for the example MUST correspond to the format for the 32-bit version of the CCI specified in the multiple rate congestion control building block.
在本例中，CCI的长度为32位。示例中CCI字段的格式必须与多速率拥塞控制构建块中指定的32位版本的CCI格式相对应。
Transport Session Identifier (TSI): 16, 32 or 48 bits
传输会话标识符（TSI）：16、32或48位
The TSI uniquely identifies a session among all sessions from a particular sender. The TSI is scoped by the sender IP address, and thus the (sender IP address, TSI) pair uniquely identify the session. For ALC, the TSI MUST be included in the LCT header.
TSI在来自特定发送方的所有会话中唯一标识一个会话。TSI由发送方IP地址确定范围，因此（发送方IP地址，TSI）对唯一标识会话。对于ALC，TSI必须包含在LCT标头中。
The TSI MUST be unique among all sessions served by the sender during the period when the session is active, and for a large period of time preceding and following when the session is active. A primary purpose of the TSI is to prevent receivers from inadvertently accepting packets from a sender that belong to sessions other than sessions receivers are subscribed to. For example, suppose a session is deactivated and then another session is activated by a sender and the two sessions use an overlapping set of channels. A receiver that connects and remains connected to the first session during this sender activity could possibly accept packets from the second session as belonging to the first session if the TSI for the two sessions were identical. The mapping of TSI field values to sessions is outside the scope of this document and is to be done out-of-band.
TSI在会话处于活动状态期间以及会话处于活动状态之前和之后的很长时间内，在发送方服务的所有会话中必须是唯一的。TSI的主要目的是防止接收方无意中接受来自发送方的分组，该发送方属于接收方订阅的会话以外的会话。例如，假设一个会话被停用，然后另一个会话被发送方激活，这两个会话使用一组重叠的通道。如果两个会话的TSI相同，则在此发送方活动期间连接并保持连接到第一会话的接收方可能会从第二会话接收属于第一会话的数据包。TSI字段值到会话的映射超出了本文档的范围，需要在带外完成。
The length of the TSI field is 32*S + 16*H bits. Note that the aggregate lengths of the TSI field plus the TOI field is a multiple of 32 bits.
TSI字段的长度为32*S+16*H位。请注意，TSI字段加上TOI字段的聚合长度是32位的倍数。
In the example the TSI is 32 bits in length.
在该示例中，TSI的长度为32位。
Transport Object Identifier (TOI): 0, 16, 32, 48, 64, 80, 96 or 112 bits.
传输对象标识符（TOI）：0、16、32、48、64、80、96或112位。
This field indicates which object within the session this packet pertains to. For example, a sender might send a number of files in the same session, using TOI=0 for the first file, TOI=1 for the second one, etc. As another example, the TOI may be a unique global identifier of the object that is being transmitted from several senders concurrently, and the TOI value may be the output of a hash function applied to the object. The mapping of TOI field values to objects is outside the scope of this document and is to be done out-of-band. The TOI field MUST be used in all packets if more than one object is to be transmitted in a session, i.e., the TOI field is either present in all the packets of a session or is never present.
此字段指示此数据包属于会话中的哪个对象。例如，发送方可能在同一会话中发送多个文件，第一个文件使用TOI=0，第二个文件使用TOI=1，等等。另一个例子是，TOI可能是同时从多个发送方发送的对象的唯一全局标识符，并且TOI值可以是应用于对象的散列函数的输出。TOI字段值到对象的映射不在本文档的范围内，应在带外完成。如果在一个会话中要传输多个对象，则必须在所有数据包中使用TOI字段，即，TOI字段存在于会话的所有数据包中或从不存在。
The length of the TOI field is 32*O + 16*H bits. Note that the aggregate lengths of the TSI field plus the TOI field is a multiple of 32 bits.
TOI字段的长度为32*O+16*H位。请注意，TSI字段加上TOI字段的聚合长度是32位的倍数。
In the example the TOI is 32 bits in length.
在本例中，TOI的长度为32位。
Sender Current Time (SCT): 0 or 32 bits
发送方当前时间（SCT）：0或32位
This field represents the current clock of the sender at the time this packet was transmitted, measured in units of 1ms and computed modulo 2^32 units from the start of the session.
此字段表示发送此数据包时发送方的当前时钟，以1ms为单位测量，并从会话开始计算模2^32单位。
This field MUST NOT be present if T=0 and MUST be present if T=1.
如果T=0，此字段必须不存在；如果T=1，此字段必须存在。
In this example the SCT is present.
在本例中，存在SCT。
Expected Residual Time (ERT): 0 or 32 bits
预期剩余时间（ERT）：0或32位
This field represents the sender expected residual transmission time of packets for either the single object carried in the session or for the object identified by the TOI if there are multiple objects carried in the session.
此字段表示会话中携带的单个对象或TOI标识的对象（如果会话中携带多个对象）的发送方预期剩余数据包传输时间。
This field MUST NOT be present if R=0 and MUST be present if R=1.
如果R=0，此字段不得存在；如果R=1，此字段必须存在。
In this example the ERT is not present.
在本例中，ERT不存在。
FEC Payload ID: X bits
FEC有效负载ID:X位
The length and format of the FEC Payload ID depends on the FEC Encoding ID as described in the FEC building block [10]. The FEC Payload ID format is determined by the FEC Encoding ID that MUST be communicated in the Session Description. The Session Description MAY specify that more than one FEC Encoding ID is used in the session, in which case the Session Description MUST contain a mapping that identifies which Codepoint values correspond to which FEC Encoding IDs. This mapping, if used, is outside the scope of this document.
FEC有效负载ID的长度和格式取决于FEC构建块[10]中描述的FEC编码ID。FEC有效负载ID格式由必须在会话描述中通信的FEC编码ID确定。会话描述可以指定会话中使用多个FEC编码ID，在这种情况下，会话描述必须包含标识哪些码点值对应于哪些FEC编码ID的映射。此映射（如果使用）超出了本文档的范围。
The example packet format corresponds to the format for "Small Block, Large Block and Expandable FEC Codes" as described in the FEC building block, for which the associated FEC Encoding ID 128. For FEC Encoding ID 128, the FEC Payload ID consists of the following two fields that in total are X = 64 bits in length:
示例分组格式对应于FEC构建块中描述的“小块、大块和可扩展FEC代码”的格式，相关联的FEC编码ID为128。对于FEC编码ID 128，FEC有效负载ID由以下两个字段组成，总长度为X=64位：
Source Block Number (SBN): 32 bits
源块编号（SBN）：32位
The Source Block Number identifies from which source block of the object the encoding symbol(s) in the payload are generated. These blocks are numbered consecutively from
源块编号标识有效负载中的编码符号是从对象的哪个源块生成的。这些块从开始连续编号
0 to N-1, where N is the number of source blocks in the object.
0到N-1，其中N是对象中的源块数。
Encoding Symbol ID (ESI): 32 bits
编码符号ID（ESI）：32位
The Encoding Symbol ID identifies which specific encoding symbol(s) generated from the source block are carried in the packet payload. The exact details of the correspondence between Encoding Symbol IDs and the encoding symbol(s) in the packet payload are dependent on the particular encoding algorithm used as identified by the FEC Encoding ID and by the FEC Instance ID.
编码符号ID标识从源块生成的哪些特定编码符号被携带在分组有效载荷中。编码符号ID和分组有效载荷中的编码符号之间的对应关系的确切细节取决于由FEC编码ID和FEC实例ID标识的特定编码算法。
Encoding Symbol(s): Y bits
编码符号：Y位
The encoding symbols are what the receiver uses to reconstruct an object. The total length Y of the encoding symbol(s) in the packet can be determined by the receiver of the packet by computing the total length of the received packet and subtracting off the length of the headers.
编码符号是接收器用来重建对象的符号。分组中的编码符号的总长度Y可由分组的接收器通过计算所接收分组的总长度并减去报头的长度来确定。
Header Extensions can be used to extend the LCT header portion of the ALC header to accommodate optional header fields that are not always used or have variable size. Header Extensions are not used in the example ALC packet format shown in the previous subsection. Examples of the use of Header Extensions include:
标头扩展可用于扩展ALC标头的LCT标头部分，以容纳并非始终使用或大小可变的可选标头字段。在上一小节所示的示例ALC数据包格式中不使用报头扩展。标题扩展的使用示例包括：
o Extended-size versions of already existing header fields.
o 已存在标题字段的扩展大小版本。
o Sender and Receiver authentication information.
o 发送方和接收方身份验证信息。
The presence of Header Extensions can be inferred by the LCT header length (HDR_LEN): if HDR_LEN is larger than the length of the standard header then the remaining header space is taken by Header Extension fields.
可以通过LCT标头长度（HDR_LEN）推断是否存在标头扩展：如果HDR_LEN大于标准标头的长度，则标头扩展字段将占用剩余的标头空间。
If present, Header Extensions MUST be processed to ensure that they are recognized before performing any congestion control procedure or otherwise accepting a packet. The default action for unrecognized Header Extensions is to ignore them. This allows the future introduction of backward-compatible enhancements to ALC without changing the ALC version number. Non backward-compatible Header Extensions CANNOT be introduced without changing the ALC version number.
如果存在，则必须处理报头扩展，以确保在执行任何拥塞控制过程或以其他方式接受数据包之前识别它们。无法识别的标头扩展的默认操作是忽略它们。这允许将来在不更改ALC版本号的情况下向ALC引入向后兼容的增强功能。如果不更改ALC版本号，则无法引入不向后兼容的标头扩展。
There are two formats for Header Extension fields, as depicted below. The first format is used for variable-length extensions, with Header Extension Type (HET) values between 0 and 127. The second format is used for fixed length (one 32-bit word) extensions, using HET values from 127 to 255.
标题扩展字段有两种格式，如下所示。第一种格式用于可变长度扩展，标题扩展类型（HET）值介于0和127之间。第二种格式用于固定长度（一个32位字）扩展，使用127到255之间的HET值。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (<=127) | HEL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. Header Extension Content (HEC) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (<=127) | HEL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. Header Extension Content (HEC) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (>=128) | Header Extension Content (HEC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (>=128) | Header Extension Content (HEC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 - Format of additional headers
图3-附加标题的格式
The explanation of each sub-field is the following.
每个子字段的解释如下所示。
Header Extension Type (HET): 8 bits
标头扩展类型（HET）：8位
The type of the Header Extension. This document defines a number of possible types. Additional types may be defined in future versions of this specification. HET values from 0 to 127 are used for variable-length Header Extensions. HET values from 128 to 255 are used for fixed-length 32-bit Header Extensions.
标题扩展的类型。本文档定义了许多可能的类型。其他类型可在本规范的未来版本中定义。0到127之间的HET值用于可变长度标头扩展。从128到255的HET值用于固定长度的32位标头扩展。
Header Extension Length (HEL): 8 bits
标题扩展长度（HEL）：8位
The length of the whole Header Extension field, expressed in multiples of 32-bit words. This field MUST be present for variable-length extensions (HET between 0 and 127) and MUST NOT be present for fixed-length extensions (HET between 128 and 255).
整个标头扩展字段的长度，以32位字的倍数表示。对于可变长度扩展（HET介于0和127之间）必须存在此字段，对于固定长度扩展（HET介于128和255之间）必须不存在此字段。
Header Extension Content (HEC): variable length
标题扩展内容（HEC）：可变长度
The content of the Header Extension. The format of this sub-field depends on the Header Extension type. For fixed-length Header Extensions, the HEC is 24 bits. For variable-length Header Extensions, the HEC field has variable size, as
标题扩展的内容。此子字段的格式取决于标题扩展类型。对于固定长度的报头扩展，HEC为24位。对于可变长度标头扩展，HEC字段具有可变大小，如下所示
specified by the HEL field. Note that the length of each Header Extension field MUST be a multiple of 32 bits. Also note that the total size of the LCT header, including all Header Extensions and all optional header fields, cannot exceed 255 32-bit words.
由HEL字段指定。请注意，每个标头扩展字段的长度必须是32位的倍数。还请注意，LCT标头的总大小（包括所有标头扩展名和所有可选标头字段）不能超过255个32位字。
Header Extensions are further divided between general LCT extensions and Protocol Instantiation specific extensions (PI-specific). General LCT extensions have HET in the ranges 0:63 and 128:191 inclusive. PI-specific extensions have HET in the ranges 64:127 and 192:255 inclusive.
标头扩展进一步分为通用LCT扩展和协议实例化特定扩展（PI特定）。通用LCT扩展的HET范围为0:63和128:191（含0:63和128:191）。PI特定扩展的HET范围为64:127和192:255（含64:127和192:255）。
General LCT extensions are intended to allow the introduction of backward-compatible enhancements to LCT without changing the LCT version number. Non backward-compatible Header Extensions CANNOT be introduced without changing the LCT version number.
通用LCT扩展旨在允许在不更改LCT版本号的情况下向LCT引入向后兼容的增强功能。如果不更改LCT版本号，则无法引入不向后兼容的标头扩展。
PI-specific extensions are reserved for PI-specific use with semantic and default parsing actions defined by the PI.
特定于PI的扩展保留用于PI定义的语义和默认解析操作的特定于PI的使用。
The following general LCT Header Extension types are defined:
定义了以下通用LCT标头扩展类型：
EXT_NOP=0 No-Operation extension. The information present in this extension field MUST be ignored by receivers.
EXT_NOP=0无操作扩展。接收器必须忽略此扩展字段中的信息。
EXT_AUTH=1 Packet authentication extension Information used to authenticate the sender of the packet. The format of this Header Extension and its processing is outside the scope of this document and is to be communicated out-of-band as part of the Session Description.
EXT_AUTH=1用于验证数据包发送方身份的数据包身份验证扩展信息。此标题扩展及其处理的格式不在本文档的范围内，将作为会话描述的一部分在带外传达。
It is RECOMMENDED that senders provide some form of packet authentication. If EXT_AUTH is present, whatever packet authentication checks that can be performed immediately upon reception of the packet SHOULD be performed before accepting the packet and performing any congestion control-related action on it. Some packet authentication schemes impose a delay of several seconds between when a packet is received and when the packet is fully authenticated. Any congestion control related action that is appropriate MUST NOT be postponed by any such full packet authentication.
建议发送方提供某种形式的数据包身份验证。如果存在EXT_AUTH，则在接收数据包并对其执行任何与拥塞控制相关的操作之前，应执行可在接收数据包后立即执行的任何数据包身份验证检查。一些分组认证方案在接收分组和分组完全认证之间施加几秒钟的延迟。任何与拥塞控制相关的适当行动不得因任何此类完整数据包身份验证而延迟。
All senders and receivers implementing ALC MUST support the EXT_NOP Header Extension and MUST recognize EXT_AUTH, but MAY NOT be able to parse its content.
所有实现ALC的发送方和接收方必须支持EXT_NOP头扩展，并且必须识别EXT_AUTH，但可能无法解析其内容。
For this version of ALC, the following PI-specific extension is defined:
对于此版本的ALC，定义了以下特定于PI的扩展：
EXT_FTI=64 FEC Object Transmission Information extension The purpose of this extension is to carry in-band the FEC Object Transmission Information for an object. The format of this Header Extension and its processing is outside the scope of this document and is to be communicated out-of-band as part of the Session Description.
EXT_FTI=64 FEC对象传输信息扩展此扩展的目的是在带内携带对象的FEC对象传输信息。此标题扩展及其处理的格式不在本文档的范围内，将作为会话描述的一部分在带外传达。
The sender operation when using ALC includes all the points made about the sender operation when using the LCT building block [11], the FEC building block [10] and the multiple rate congestion control building block.
使用ALC时的发送方操作包括使用LCT构建块[11]、FEC构建块[10]和多速率拥塞控制构建块时有关发送方操作的所有要点。
A sender using ALC MUST make available the required Session Description as described in Section 2.4. A sender also MUST 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 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 and 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必须对应于数据包有效载荷中所携带对象的编码符号。
Objects MAY be transmitted sequentially within a session, and they MAY be transmitted concurrently. However, it is good practice to only send objects concurrently in the same session if the receivers that participate in that portion of the session have interest in receiving all the objects. The reason for this is that it wastes bandwidth and networking resources to have receivers receive data for objects that they have no interest in. However, there are no rules with respect to mixing packets for different objects carried within the session. Although this issue affects the efficiency of the
对象可以在会话内顺序地传输，并且它们可以并发地传输。然而，如果参与会话的该部分的接收器对接收所有对象感兴趣，则在同一会话中仅并发发送对象是一种良好的实践。原因是，让接收器接收他们不感兴趣的对象的数据会浪费带宽和网络资源。但是，没有关于混合会话中携带的不同对象的数据包的规则。虽然这个问题影响了整个系统的效率
protocol, it does not affect the correctness nor the inter-operability of ALC between senders and receivers.
协议，它不影响发送方和接收方之间ALC的正确性和互操作性。
Typically, the sender(s) continues to send packets in a session until the transmission is considered complete. The transmission may be considered complete when some time has expired, a certain number of packets have been sent, or some out-of-band signal (possibly from a higher level protocol) has indicated completion by a sufficient number of receivers.
通常，发送方继续在会话中发送分组，直到传输被认为完成。当一段时间已经过期、发送了一定数量的分组或者一些带外信号（可能来自更高级别协议）已经指示足够数量的接收机完成时，可以认为传输已经完成。
It is RECOMMENDED that packet authentication be used. If packet authentication is used then the Header Extensions described in Section 4.3 MUST be used to carry the authentication.
建议使用数据包身份验证。如果使用数据包身份验证，则必须使用第4.3节中描述的报头扩展来进行身份验证。
This document does not pose any restriction on packet sizes. However, network efficiency considerations recommend that the sender uses as large as possible packet payload size, but in such a way that packets do not exceed the network's maximum transmission unit size (MTU), or fragmentation coupled with packet loss might introduce severe inefficiency in the transmission. It is RECOMMENDED that all packets have the same or very similar sizes, as this can have a severe impact on the effectiveness of the multiple rate congestion control building block.
本文件对数据包大小没有任何限制。然而，网络效率考虑建议发送方使用尽可能大的分组有效载荷大小，但是以这样的方式分组不超过网络的最大传输单元大小（MTU），或者与分组丢失相结合的碎片可能在传输中引入严重的低效率。建议所有数据包具有相同或非常相似的大小，因为这会严重影响多速率拥塞控制构建块的有效性。
The receiver operation when using ALC includes all the points made about the receiver operation when using the LCT building block [11], the FEC building block [10] and the multiple rate congestion control building block.
使用ALC时的接收器操作包括使用LCT构建块[11]、FEC构建块[10]和多速率拥塞控制构建块时关于接收器操作的所有要点。
To be able to participate in a session, a receiver MUST 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节中列出的所需会话描述。接收者如何获得会话描述超出了本文档的范围。
To be able to be a receiver in a session, the receiver MUST be able to process the ALC header. The receiver MUST be able to discard, forward, store or process the other headers and the packet payload. If a receiver is not able to process the ALC header, it MUST drop from the session.
为了能够成为会话中的接收器，接收器必须能够处理ALC报头。接收器必须能够丢弃、转发、存储或处理其他报头和数据包有效负载。如果接收器无法处理ALC报头，它必须从会话中退出。
To be able to participate in a session, a receiver MUST implement the multiple rate congestion control building block using the Congestion Control Information field provided in the LCT header. If a receiver is not able to implement the multiple rate congestion control building block it MUST NOT join the session.
为了能够参与会话，接收方必须使用LCT报头中提供的拥塞控制信息字段实现多速率拥塞控制构建块。如果接收器无法实现多速率拥塞控制构建块，则它不得加入会话。
Several objects can be carried either sequentially or concurrently within the same session. In this case, each object is identified by a unique TOI. Note that even if a sender stops sending packets for an old object before starting to transmit packets for a new object, both the network and the underlying protocol layers can cause some reordering of packets, especially when sent over different channels, and thus receivers SHOULD NOT assume that the reception of a packet for a new object means that there are no more packets in transit for the previous one, at least for some amount of time.
在同一个会话中，可以顺序或并发地携带多个对象。在这种情况下，每个对象都由唯一的TOI标识。请注意，即使发送方在开始发送新对象的数据包之前停止发送旧对象的数据包，网络和底层协议层都可能导致数据包重新排序，特别是在通过不同通道发送时，因此，接收机不应假设接收到新对象的分组意味着至少在一段时间内没有前一个对象的更多分组在传输中。
As described in Section 2.3, a receiver MUST obtain the required FEC Object Transmission Information for each object for which the receiver receives and processes packets.
如第2.3节所述，接收器必须为其接收和处理数据包的每个对象获取所需的FEC对象传输信息。
A receiver MAY concurrently join multiple ALC sessions from one or more senders. The receiver MUST perform congestion control on each such session. The receiver MAY make choices to optimize the packet flow performance across multiple sessions, as long as the receiver still adheres to the multiple rate congestion control building block for each session individually.
接收器可以同时加入来自一个或多个发送者的多个ALC会话。接收方必须对每个这样的会话执行拥塞控制。接收机可以做出选择来优化跨多个会话的分组流性能，只要接收机仍然单独遵守每个会话的多速率拥塞控制构建块。
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. If multiple packets are received that cannot be parsed then the receiver SHOULD leave the session.
(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 that the receiver is currently joined to. If there is not a match then the packet MUST be discarded without further processing. If multiple packets are received with non-matching (sender IP address, TSI) values then the receiver SHOULD leave the session. If the receiver is joined to multiple ALC sessions then the remainder of the steps are performed within the scope of the (sender IP address, TSI) session of the received packet.
(2) 接收方必须验证发送方IP地址和标头中携带的TSI是否与会话描述中接收到的（发送方IP地址，TSI）对之一匹配，并且接收方当前已加入。如果不存在匹配，则必须丢弃该数据包，而无需进一步处理。如果接收到多个数据包的值不匹配（发送方IP地址，TSI），则接收方应离开会话。如果接收器加入到多个ALC会话，则其余步骤在所接收数据包的（发送方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 discard the packet and reduce its reception rate to a minimum before continuing to regulate its reception rate using the multiple rate congestion control.
建议使用数据包身份验证。如果使用分组认证，则建议接收器在继续进行上述步骤（3）之前立即检查分组的真实性。如果可以立即检查并且数据包未通过检查，则接收器必须丢弃数据包并将其接收速率降至最低，然后再继续使用多速率拥塞控制调节其接收速率。
Some packet authentication schemes such as TESLA [14] do not allow an immediate authenticity check. In this case the receiver SHOULD check the authenticity of a packet as soon as possible, and if the packet fails the check then it MUST be discarded before step (5) above and reduce its reception rate to a minimum before continuing to regulate its reception rate using the multiple rate congestion control.
一些数据包认证方案，如特斯拉[14]不允许立即进行真实性检查。在这种情况下，接收器应尽快检查数据包的真实性，如果该数据包未通过检查，则必须在上述步骤（5）之前丢弃该数据包，并在继续使用多速率拥塞控制调节其接收速率之前将其接收速率降至最低。
The same security consideration that apply to the LCT, FEC and the multiple rate congestion control building blocks also apply to ALC.
适用于LCT、FEC和多速率拥塞控制构建块的相同安全考虑也适用于ALC。
Because of the use of FEC, 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.
由于FEC的使用，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 FEC 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. Although there is currently no IETF standard that specifies how to do multicast packet level authentication, TESLA [14] is a known multicast packet authentication scheme that would work.
在数据包级别，建议使用数据包级别的身份验证，以确保每个接收到的数据包都是真实且未损坏的数据包，其中包含来自指定发送方的对象的FEC数据。数据包级身份验证的优点是可以单独丢弃损坏或伪造的数据包，并且可以使用接收到的经过身份验证的数据包准确地重建对象。因此，注入伪造数据包的拒绝服务攻击的效果仅与伪造数据包的数量成正比，而与对象大小无关。尽管目前没有IETF标准规定如何进行多播数据包级认证，但TESLA[14]是一个已知的多播数据包认证方案，可以工作。
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. TESLA [14] 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.
除了针对不准确对象的重建提供保护外，数据包级身份验证还可以针对多速率拥塞控制上的拒绝服务攻击提供一些保护。攻击者可以尝试向多播流中注入带有不正确拥塞控制信息的伪造数据包，从而可能对攻击下游的网络元素和接收器产生不利影响，更不用说对网络其余部分和其他接收器产生不利影响了。因此，还建议使用数据包级身份验证来防止此类攻击。特斯拉[14]也可以在一定程度上用于限制此类攻击造成的损害。然而，对于特斯拉，接收器只能在接收到数据包几秒钟后确定数据包是否真实，因此对拥塞控制协议的攻击可以有效几秒钟，然后接收器才能做出反应以降低会话接收速率。
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.
反向路径转发检查应在从发送方到接收方的所有网络路由器和交换机中启用，以限制坏代理将伪造数据包注入多播树数据路径的可能性。
A receiver with an incorrect or corrupted implementation of the multiple rate congestion control building block may affect health of the network in the path between the sender and the receiver, and may also affect the reception rates of other receivers joined to the session. It is therefore RECOMMENDED that receivers be required to identify themselves as legitimate before they receive the Session Description needed to join the session. How receivers identify themselves as legitimate is outside the scope of this document.
具有多速率拥塞控制构建块的不正确或损坏的实现的接收器可能影响发送方和接收器之间路径中的网络健康，并且还可能影响加入会话的其他接收器的接收速率。因此，建议要求接收者在接收加入会话所需的会话描述之前将自己标识为合法。接收人如何认定自己合法不在本文件范围内。
Another vulnerability of ALC is the potential of receivers obtaining an incorrect Session Description for the session. The consequences of this could be that legitimate receivers with the wrong Session Description are unable to correctly receive the session content, or that receivers inadvertently try to receive at a much higher rate than they are capable of, thereby disrupting traffic in portions of the network. To avoid these problems, it is RECOMMENDED that measures be taken to prevent receivers from accepting incorrect Session Descriptions, e.g., by using source authentication to ensure that receivers only accept legitimate Session Descriptions from authorized senders. How this is done is outside the scope of this document.
ALC的另一个漏洞是接收方可能获得不正确的会话描述。这可能导致具有错误会话描述的合法接收器无法正确接收会话内容，或者接收器无意中尝试以远高于其能力的速率接收，从而中断网络部分中的通信。为了避免这些问题，建议采取措施防止接收者接受不正确的会话描述，例如，通过使用源身份验证确保接收者只接受来自授权发送者的合法会话描述。如何做到这一点超出了本文件的范围。
No information in this specification is directly subject to IANA registration. However, building blocks components used by ALC may introduce additional IANA considerations. In particular, the FEC building block used by ALC does require IANA registration of the FEC codecs used.
本规范中的任何信息均不直接受IANA注册的约束。但是，ALC使用的构建块组件可能会引入额外的IANA注意事项。特别是，ALC使用的FEC构建块确实需要对所使用的FEC编解码器进行IANA注册。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETF已收到关于本文件所含部分或全部规范的知识产权声明。有关更多信息，请查阅在线权利主张列表。
Thanks to Vincent Roca, Justin Chapweske and Roger Kermode for their detailed comments on this document.
感谢Vincent Roca、Justin Chapweske和Roger Kermode对本文件的详细评论。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1] Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[3] Deering，S.，“IP多播的主机扩展”，STD 5，RFC 1112，1989年8月。
[4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, January 1997.
[4] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1997年1月。
[5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[5] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[6] Handley, M., Perkins, C. and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[6] Handley，M.，Perkins，C.和E.Whelan，“会话公告协议”，RFC 29742000年10月。
[7] Holbrook, H. W., "A Channel Model for Multicast", Ph.D. Dissertation, Stanford University, Department of Computer Science, Stanford, California, August 2001.
[7] 霍尔布鲁克，H.W.，“多播的信道模型”，博士。斯坦福大学计算机科学系博士论文，斯坦福，加利福尼亚，2001年8月。
[8] Kermode, R., Vicisano, L., "Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents", RFC 3269, April 2002.
[8] Kermode，R.，Vicisano，L.，“可靠多播传输（RMT）构建块和协议实例化文档的作者指南”，RFC 3269，2002年4月。
[9] 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.
[9] Luby，M.，Vicisano，L.，Gemmell，J.，Rizzo，L.，Handley，M.和J.Crowcroft，“前向纠错（FEC）在可靠多播中的使用”，RFC 3453，2002年12月。
[10] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "Forward Error Correction (FEC) Building Block", RFC 3452, December 2002.
[10] 卢比，M.，维西萨诺，L.，杰梅尔，J.，里佐，L.，汉德利，M.，和J.克罗夫特，“前向纠错（FEC）构建块”，RFC 3452，2002年12月。
[11] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M. and J. Crowcroft, "Layered Coding Transport (LCT) Building Block", RFC 3451 December 2002.
[11] Luby，M.，Gemmell，J.，Vicisano，L.，Rizzo，L.，Handley，M.和J.Crowcroft，“分层编码传输（LCT）构建块”，RFC 3451，2002年12月。
[12] Mankin, A., Romanow, A., Bradner, S. and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
[12] Mankin，A.，Romanow，A.，Bradner，S.和V.Paxson，“IETF评估可靠多播传输和应用协议的标准”，RFC 2357，1998年6月。
[13] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[13] Murata，M.，St.Laurent，S.和D.Kohn，“XML媒体类型”，RFC 3023，2001年1月。
[14] Perrig, A., Canetti, R., Song, D. and J.D. Tygar, "Efficient and Secure Source Authentication for Multicast", Network and Distributed System Security Symposium, NDSS 2001, pp. 35-46, February 2001.
[14] Perrig，A.，Canetti，R.，Song，D.和J.D.Tygar，“多播的高效和安全源认证”，网络和分布式系统安全研讨会，NDSS 2001，第35-46页，2001年2月。
[15] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[15] Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[16] 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.
[16] Whetten，B.，Vicisano，L.，Kermode，R.，Handley，M.，Floyd，S.和M.Luby，“一对多批量数据传输的可靠多播传输构建块”，RFC 3048，2001年1月。
Authors' Addresses
作者地址
Michael Luby Digital Fountain 39141 Civic Center Dr. Suite 300 Fremont, CA, USA, 94538
迈克尔·鲁比数字喷泉39141美国加利福尼亚州弗里蒙特市公民中心博士套房300号，邮编94538
EMail: luby@digitalfountain.com
EMail: luby@digitalfountain.com
Jim Gemmell Microsoft Research 455 Market St. #1690 San Francisco, CA, 94105
吉姆GMMELL微软研究455市场S.Syz 1690旧金山，CA，94105
EMail: jgemmell@microsoft.com
EMail: jgemmell@microsoft.com
Lorenzo Vicisano cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA, USA, 95134
Lorenzo Vicisano cisco Systems，Inc.170 West Tasman Dr.圣何塞，加利福尼亚州，美国，95134
EMail: lorenzo@cisco.com
EMail: lorenzo@cisco.com
Luigi Rizzo Dip. Ing. dell'Informazione, Univ. di Pisa via Diotisalvi 2, 56126 Pisa, Italy
路易吉·里佐·迪普。惯性导航与制导。戴尔信息网，比萨大学，途经迪奥蒂萨尔维256126比萨，意大利
EMail: luigi@iet.unipi.it
EMail: luigi@iet.unipi.it
Jon Crowcroft Marconi Professor of Communications Systems University of Cambridge Computer Laboratory William Gates Building J J Thomson Avenue Cambridge CB3 0FD, UK
Jon Crowcroft Marconi通信系统教授剑桥大学计算机实验室威廉盖茨大厦J J汤姆逊大道剑桥CB3 0FD，英国
EMail: Jon.Crowcroft@cl.cam.ac.uk
EMail: Jon.Crowcroft@cl.cam.ac.uk
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
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编辑功能的资金目前由互联网协会提供。