Network Working Group M. Luby
Request for Comments: 3451 Digital Fountain
Category: Experimental J. Gemmell
Microsoft
L. Vicisano
Cisco
L. Rizzo
Univ. Pisa
M. Handley
ICIR
J. Crowcroft
Cambridge Univ.
December 2002
Network Working Group M. Luby
Request for Comments: 3451 Digital Fountain
Category: Experimental J. Gemmell
Microsoft
L. Vicisano
Cisco
L. Rizzo
Univ. Pisa
M. Handley
ICIR
J. Crowcroft
Cambridge Univ.
December 2002
Layered Coding Transport (LCT) Building Block
分层编码传输（LCT）构建块
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
摘要
Layered Coding Transport (LCT) provides transport level support for reliable content delivery and stream delivery protocols. LCT is specifically designed to support protocols using IP multicast, but also provides support to protocols that use unicast. LCT is compatible with congestion control that provides multiple rate delivery to receivers and is also compatible with coding techniques that provide reliable delivery of content.
分层编码传输（LCT）为可靠的内容交付和流交付协议提供传输级支持。LCT专门设计用于支持使用IP多播的协议，但也支持使用单播的协议。LCT与向接收器提供多速率传送的拥塞控制兼容，还与提供可靠内容传送的编码技术兼容。
Table of Contents
目录
1. Introduction...................................................2
2. Rationale......................................................3
3. Functionality..................................................4
4. Applicability..................................................7
4.1 Environmental Requirements and Considerations...............8
4.2 Delivery service models....................................10
4.3 Congestion Control.........................................11
5. Packet Header Fields..........................................12
5.1 Default LCT header format..................................12
5.2 Header-Extension Fields....................................17
6. Operations....................................................20
6.1 Sender Operation...........................................20
6.2 Receiver Operation.........................................22
7. Requirements from Other Building Blocks.......................23
8. Security Considerations.......................................24
9. IANA Considerations...........................................25
10. Acknowledgments..............................................25
11. References...................................................25
Authors' Addresses...............................................28
Full Copyright Statement.........................................29
1. Introduction...................................................2
2. Rationale......................................................3
3. Functionality..................................................4
4. Applicability..................................................7
4.1 Environmental Requirements and Considerations...............8
4.2 Delivery service models....................................10
4.3 Congestion Control.........................................11
5. Packet Header Fields..........................................12
5.1 Default LCT header format..................................12
5.2 Header-Extension Fields....................................17
6. Operations....................................................20
6.1 Sender Operation...........................................20
6.2 Receiver Operation.........................................22
7. Requirements from Other Building Blocks.......................23
8. Security Considerations.......................................24
9. IANA Considerations...........................................25
10. Acknowledgments..............................................25
11. References...................................................25
Authors' Addresses...............................................28
Full Copyright Statement.........................................29
Layered Coding Transport provides transport level support for reliable content delivery and stream delivery protocols. Layered Coding Transport is specifically designed to support protocols using IP multicast, but also provides support to protocols that use unicast. Layered Coding Transport is compatible with congestion control that provides multiple rate delivery to receivers and is also compatible with coding techniques that provide reliable delivery of content.
分层编码传输为可靠的内容交付和流交付协议提供传输级支持。分层编码传输专门设计用于支持使用IP多播的协议，但也支持使用单播的协议。分层编码传输与向接收器提供多速率传送的拥塞控制兼容，也与提供可靠内容传送的编码技术兼容。
This document describes a building block as defined in RFC 3048 [26]. This document is a product of the IETF RMT WG and follows the general guidelines provided in RFC 3269 [24].
本文件描述了RFC 3048[26]中定义的构建块。本文件是IETF RMT工作组的产品，遵循RFC 3269[24]中提供的一般指南。
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 RFC 2357. As per RFC 2357, the use of any reliable multicast protocol in the Internet requires an adequate congestion control scheme.
本备忘录包含根据RFC 2357完全指定可靠多播传输协议所需的部分定义。根据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建议的标准重新提交。
LCT provides transport level support for massively scalable protocols using the IP multicast network service. The support that LCT provides is common to a variety of very important applications, including reliable content delivery and streaming applications.
LCT使用IP多播网络服务为大规模可扩展协议提供传输级支持。LCT提供的支持对于各种非常重要的应用程序都是通用的，包括可靠的内容交付和流式应用程序。
An LCT 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. The logic behind defining a session as originating from a single sender is that this is the right granularity to regulate packet traffic via congestion control. One rationale for using multiple channels within the same session is that there are massively scalable congestion control protocols that use multiple channels per session. These congestion control protocols are considered to be layered because a receiver joins and leaves channels in a layered order during its participation in the session. The use of layered channels is also useful for streaming applications.
LCT会话包括源自单个发送方的多个信道，这些信道在一段时间内用于承载与一个或多个对象的传输有关的数据包，这些对象可能是接收方感兴趣的。将会话定义为源自单个发送方的逻辑是，这是通过拥塞控制调节数据包流量的正确粒度。在同一会话中使用多个信道的一个基本原理是，存在可大规模扩展的拥塞控制协议，每个会话使用多个信道。这些拥塞控制协议被认为是分层的，因为接收器在其参与会话期间以分层顺序加入和离开信道。分层通道的使用对于流应用程序也很有用。
There are coding techniques that provide massively scalable reliability and asynchronous delivery which are compatible with both layered congestion control and with LCT. When all are combined the result is a massively scalable reliable asynchronous content delivery protocol that is network friendly. LCT also provides functionality that can be used for other applications as well, e.g., layered streaming applications.
有一些编码技术提供了大规模可扩展的可靠性和异步交付，它们与分层拥塞控制和LCT兼容。当所有这些结合在一起时，结果是一个可大规模扩展的、可靠的、网络友好的异步内容交付协议。LCT还提供了可用于其他应用程序的功能，例如分层流应用程序。
LCT avoids providing functionality that is not massively scalable. For example, LCT does not provide any mechanisms for sending information from receivers to senders, although this does not rule out protocols that both use LCT and do require sending information from receivers to senders.
LCT避免提供不可大规模扩展的功能。例如，LCT不提供任何从接收者向发送者发送信息的机制，尽管这并不排除既使用LCT又要求从接收者向发送者发送信息的协议。
LCT includes general support for congestion control that must be used. It does not, however, specify which congestion control should be used. The rationale for this is that congestion control must be provided by any protocol that is network friendly, and yet the different applications that can use LCT will not have the same requirements for congestion control. For example, a content delivery protocol may strive to use all available bandwidth between receivers and the sender. It must, therefore, drastically back off its rate when there is competing traffic. On the other hand, a streaming delivery protocol may strive to maintain a constant rate instead of trying to use all available bandwidth, and it may not back off its rate as fast when there is competing traffic.
LCT包括对必须使用的拥塞控制的一般支持。但是，它没有指定应该使用哪种拥塞控制。其基本原理是，拥塞控制必须由任何网络友好的协议提供，但可以使用LCT的不同应用程序对拥塞控制的要求不同。例如，内容交付协议可以努力使用接收器和发送器之间的所有可用带宽。因此，当存在竞争流量时，它必须大幅降低其速率。另一方面，流传送协议可能努力保持恒定速率，而不是尝试使用所有可用带宽，并且当存在竞争流量时，它可能不会以同样快的速度后退速率。
Beyond support for congestion control, LCT provides a number of fields and supports functionality commonly required by many protocols. For example, LCT provides a Transmission Session ID that can be used to identify which session each received packet belongs to. This is important because a receiver may be joined to many sessions concurrently, and thus it is very useful to be able to demultiplex packets as they arrive according to which session they belong to. As another example, LCT provides optional support for identifying which object each packet is carrying information about. Therefore, LCT provides many of the commonly used fields and support for functionality required by many protocols.
除了支持拥塞控制之外，LCT还提供了许多字段，并支持许多协议通常需要的功能。例如，LCT提供传输会话ID，该ID可用于识别每个接收到的分组所属的会话。这一点很重要，因为一个接收器可以同时加入多个会话，因此能够在数据包到达时根据它们所属的会话对其进行解复用是非常有用的。作为另一个示例，LCT提供可选支持，用于识别每个数据包携带的信息是关于哪个对象的。因此，LCT提供了许多常用字段，并支持许多协议所需的功能。
An LCT session consists of a set of logically grouped LCT channels associated with a single sender carrying packets with LCT headers for one or more objects. An LCT channel is defined by the combination of a sender and an address associated with the channel by the sender. A receiver joins a channel to start receiving the data packets sent to the channel by the sender, and a receiver leaves a channel to stop receiving data packets from the channel.
LCT会话由一组逻辑分组的LCT通道组成，这些通道与单个发送方关联，该发送方承载一个或多个对象的带有LCT头的数据包。LCT信道由发送方和发送方与信道关联的地址的组合定义。接收机加入信道以开始接收发送方发送到信道的数据包，接收机离开信道以停止从信道接收数据包。
LCT is meant to be combined with other building blocks so that the resulting overall protocol is massively scalable. Scalability refers to the behavior of the protocol in relation to the number of receivers and network paths, their heterogeneity, and the ability to accommodate dynamically variable sets of receivers. Scalability limitations can come from memory or processing requirements, or from the amount of feedback control and redundant data packet traffic
LCT意味着与其他构建块相结合，从而产生的整体协议具有大规模可扩展性。可伸缩性是指协议的行为与接收器和网络路径的数量、它们的异构性以及动态适应可变接收器集的能力有关。可伸缩性限制可能来自内存或处理需求，也可能来自反馈控制量和冗余数据包流量
generated by the protocol. In turn, such limitations may be a consequence of the features that a complete reliable content delivery or stream delivery protocol is expected to provide.
由协议生成。反过来，这种限制可能是一个完整可靠的内容交付或流交付协议预期提供的特性的结果。
The LCT header provides a number of fields that are useful for conveying in-band session information to receivers. One of the required fields is the Transmission Session ID (TSI), which allows the receiver of a session to uniquely identify received packets as part of the session. Another required field is the Congestion Control Information (CCI), which allows the receiver to perform the required congestion control on the packets received within the session. Other LCT fields provide optional but often very useful additional information for the session. For example, the Transport Object Identifier (TOI) identifies which object the packet contains data for. As other examples, the Sender Current Time (SCT) conveys the time when the packet was sent from the sender to the receiver, the Expected Residual Time (ERT) conveys the amount of time the session will be continued for, flags for indicating the close of the session and the close of sending packets for an object, and header extensions for fields that for example can be used for packet authentication.
LCT报头提供了许多字段，用于将带内会话信息传送给接收机。所需字段之一是传输会话ID（TSI），它允许会话的接收器唯一地识别作为会话一部分的接收到的分组。另一个必填字段是拥塞控制信息（CCI），它允许接收方对会话中接收的数据包执行所需的拥塞控制。其他LCT字段为会话提供可选但通常非常有用的附加信息。例如，传输对象标识符（TOI）标识包包含数据的对象。作为其他示例，发送方当前时间（SCT）表示数据包从发送方发送到接收方的时间，预期剩余时间（ERT）表示会话将持续的时间量，用于指示会话结束和对象发送数据包结束的标志，以及字段的标头扩展，例如，可用于数据包身份验证。
LCT provides support for congestion control. Congestion control MUST be used that conforms to RFC 2357 [13] between receivers and the sender for each LCT session. Congestion control refers to the ability to adapt throughput to the available bandwidth on the path from the sender to a receiver, and to share bandwidth fairly with competing flows such as TCP. Thus, the total flow of packets flowing to each receiver participating in an LCT session MUST NOT compete unfairly with existing flow adaptive protocols such as TCP.
LCT为拥塞控制提供支持。对于每个LCT会话，接收方和发送方之间必须使用符合RFC 2357[13]的拥塞控制。拥塞控制指的是使吞吐量适应从发送方到接收方的路径上的可用带宽，并与竞争流（如TCP）公平共享带宽的能力。因此，流向参与LCT会话的每个接收器的数据包的总流量不得与现有的流自适应协议（如TCP）不公平竞争。
A multiple rate or a single rate congestion control protocol can be used with LCT. For multiple rate protocols, a session typically consists of more than one channel and the sender sends packets to the channels in the session at rates that do not depend on the receivers. Each receiver adjusts its reception rate during its participation in the session by joining and leaving channels dynamically depending on the available bandwidth to the sender independent of all other receivers. Thus, for multiple rate protocols, the reception rate of each receiver may vary dynamically independent of the other receivers.
LCT可以使用多速率或单速率拥塞控制协议。对于多速率协议，会话通常由多个信道组成，发送方以不依赖于接收方的速率向会话中的信道发送数据包。每个接收机在其参与会话期间通过动态地加入和离开信道来调整其接收速率，这取决于发送端的可用带宽，而不依赖于所有其他接收机。因此，对于多速率协议，每个接收机的接收速率可以独立于其他接收机动态地变化。
For single rate protocols, a session typically consists of one channel and the sender sends packets to the channel at variable rates over time depending on feedback from receivers. Each receiver remains joined to the channel during its participation in the session. Thus, for single rate protocols, the reception rate of each receiver may vary dynamically but in coordination with all receivers.
对于单速率协议，会话通常由一个信道组成，发送方根据来自接收方的反馈以可变速率随时间向该信道发送数据包。每个接收器在其参与会话期间保持与频道的连接。因此，对于单速率协议，每个接收机的接收速率可以动态变化，但与所有接收机协调。
Generally, a multiple rate protocol is preferable to a single rate protocol in a heterogeneous receiver environment, since generally it more easily achieves scalability to many receivers and provides higher throughput to each individual receiver. Some possible multiple rate congestion control protocols are described in [22], [3], and [25]. A possible single rate congestion control protocol is described in [19].
通常，在异构接收机环境中，多速率协议比单速率协议更可取，因为通常多速率协议更容易实现对多个接收机的可伸缩性，并为每个接收机提供更高的吞吐量。[22]、[3]和[25]中描述了一些可能的多速率拥塞控制协议。[19]中描述了一种可能的单速率拥塞控制协议。
Layered coding refers to the ability to produce a coded stream of packets that can be partitioned into an ordered set of layers. The coding is meant to provide some form of reliability, and the layering is meant to allow the receiver experience (in terms of quality of playout, or overall transfer speed) to vary in a predictable way depending on how many consecutive layers of packets the receiver is receiving.
分层编码是指产生可被划分为一组有序层的数据包编码流的能力。编码意味着提供某种形式的可靠性，分层意味着允许接收机体验（在播放质量或总体传输速度方面）以可预测的方式变化，这取决于接收机接收的连续数据包层的数量。
The concept of layered coding was first introduced with reference to audio and video streams. For example, the information associated with a TV broadcast could be partitioned into three layers, corresponding to black and white, color, and HDTV quality. Receivers can experience different quality without the need for the sender to replicate information in the different layers.
分层编码的概念首先是针对音频和视频流引入的。例如，与电视广播相关联的信息可以被划分为三层，对应于黑白、彩色和HDTV质量。接收者可以体验不同的质量，而不需要发送者在不同的层中复制信息。
The concept of layered coding can be naturally extended to reliable content delivery protocols when Forward Error Correction (FEC) techniques are used for coding the data stream. Descriptions of this can be found in [20], [18], [7], [22] and [4]. By using FEC, the data stream is transformed in such a way that reconstruction of a data object does not depend on the reception of specific data packets, but only on the number of different packets received. As a result, by increasing the number of layers a receiver is receiving from, the receiver can reduce the transfer time accordingly. Using FEC to provide reliability can increase scalability dramatically in comparison to other methods for providing reliability. More details on the use of FEC for reliable content delivery can be found in [11].
当使用前向纠错（FEC）技术对数据流进行编码时，分层编码的概念可以自然地扩展到可靠的内容交付协议。关于这一点的描述见[20]、[18]、[7]、[22]和[4]。通过使用FEC，以这样的方式变换数据流，使得数据对象的重构不依赖于特定数据分组的接收，而仅依赖于接收的不同分组的数目。结果，通过增加接收机从中接收的层的数量，接收机可以相应地减少传输时间。与提供可靠性的其他方法相比，使用FEC提供可靠性可以显著提高可伸缩性。有关使用FEC进行可靠内容交付的更多详细信息，请参见[11]。
Reliable protocols aim at giving guarantees on the reliable delivery of data from the sender to the intended recipients. Guarantees vary from simple packet data integrity to reliable delivery of a precise copy of an object to all intended recipients. Several reliable content delivery protocols have been built on top of IP multicast using methods other than FEC, but scalability was not the primary design goal for many of them.
可靠的协议旨在保证数据从发送方可靠地传递到预期的接收方。从简单的数据包数据完整性到向所有预期收件人可靠地交付对象的精确副本，各种保证都不尽相同。使用FEC以外的方法在IP多播的基础上构建了几种可靠的内容交付协议，但可伸缩性并不是其中许多协议的主要设计目标。
Two of the key difficulties in scaling reliable content delivery using IP multicast are dealing with the amount of data that flows from receivers back to the sender, and the associated response (generally data retransmissions) from the sender. Protocols that
使用IP多播扩展可靠内容交付的两个关键困难是处理从接收者流回发送者的数据量，以及来自发送者的相关响应（通常是数据重传）。协议
avoid any such feedback, and minimize the amount of retransmissions, can be massively scalable. LCT can be used in conjunction with FEC codes or a layered codec to achieve reliability with little or no feedback.
避免任何此类反馈，并最大限度地减少重新传输的次数，可以实现大规模扩展。LCT可与FEC代码或分层编解码器结合使用，以实现可靠性，而无需反馈或很少反馈。
Protocol instantiations MAY be built by combining the LCT framework with other components. A complete protocol instantiation that uses LCT MUST include a congestion control protocol that is compatible with LCT and that conforms to RFC 2357 [13]. A complete protocol instantiation that uses LCT MAY include a scalable reliability protocol that is compatible with LCT, it MAY include an session control protocol that is compatible with LCT, and it MAY include other protocols such as security protocols.
协议实例化可以通过将LCT框架与其他组件相结合来构建。使用LCT的完整协议实例化必须包括与LCT兼容且符合RFC 2357[13]的拥塞控制协议。使用LCT的完整协议实例化可以包括与LCT兼容的可伸缩可靠性协议，可以包括与LCT兼容的会话控制协议，还可以包括诸如安全协议之类的其他协议。
An LCT session comprises a logically related set of one or more LCT channels originating at a single sender. The channels are used for some period of time to carry packets containing LCT headers, and these headers pertain to the transmission of one or more objects that can be of interest to receivers.
LCT会话包括源自单个发送方的一个或多个LCT信道的逻辑相关集合。信道在一段时间内用于承载包含LCT报头的分组，并且这些报头与接收机可能感兴趣的一个或多个对象的传输有关。
LCT is most applicable for delivery of objects or streams in a session of substantial length, i.e., objects or streams that range in aggregate length from hundreds of kilobytes to many gigabytes, and where the duration of the session is on the order of tens of seconds or more.
LCT最适用于在相当长的会话中交付对象或流，即，对象或流的总长度从数百KB到数千GB不等，并且会话的持续时间大约为数十秒或更长。
As an example, an LCT session could be used to deliver a TV program using three LCT channels. Receiving packets from the first LCT channel could allow black and white reception. Receiving the first two LCT channels could also permit color reception. Receiving all three channels could allow HDTV quality reception. Objects in this example could correspond to individual TV programs being transmitted.
例如，LCT会话可用于使用三个LCT频道传送电视节目。从第一个LCT信道接收数据包可以允许黑白接收。接收前两个LCT通道也可以允许彩色接收。接收所有三个频道可实现高清晰度电视质量接收。本例中的对象可能对应于正在传输的单个电视节目。
As another example, a reliable LCT session could be used to reliably deliver hourly-updated weather maps (objects) using ten LCT channels at different rates, using FEC coding. A receiver may join and concurrently receive packets from subsets of these channels, until it has enough packets in total to recover the object, then leave the session (or remain connected listening for session description information only) until it is time to receive the next object. In this case, the quality metric is the time required to receive each object.
作为另一个示例，可靠的LCT会话可用于使用FEC编码以不同速率使用十个LCT信道可靠地交付每小时更新的天气图（对象）。接收机可以加入并同时接收来自这些信道的子集的数据包，直到其总共有足够的数据包来恢复对象，然后离开会话（或保持连接，只监听会话描述信息），直到到达接收下一个对象的时间。在这种情况下，质量度量是接收每个对象所需的时间。
Before joining a session, the receivers MUST obtain enough of the session description to start the session. This MUST include the relevant session parameters needed by a receiver to participate in
在加入会话之前，接收方必须获得足够的会话描述以启动会话。这必须包括接收方参与所需的相关会话参数
the session, including all information relevant to congestion control. The session description is determined by the sender, and is typically communicated to the receivers out-of-band. In some cases, as described later, parts of the session description that are not required to initiate a session MAY be included in the LCT header or communicated to a receiver out-of-band after the receiver has joined the session.
会话，包括与拥塞控制相关的所有信息。会话描述由发送方确定，并且通常在带外与接收方通信。在某些情况下，如下文所述，会话描述中不需要发起会话的部分可以包括在LCT报头中，或者在接收机加入会话后在带外传送给接收机。
An encoder MAY be used to generate the data that is placed in the packet payload in order to provide reliability. A suitable decoder is used to reproduce the original information from the packet payload. There MAY be a reliability header that follows the LCT header if such an encoder and decoder is used. The reliability header helps to describe the encoding data carried in the payload of the packet. The format of the reliability header depends on the coding used, and this is negotiated out-of-band. As an example, one of the FEC headers described in [12] could be used.
编码器可用于生成放置在分组有效载荷中的数据以提供可靠性。使用合适的解码器从分组有效载荷再现原始信息。如果使用这样的编码器和解码器，则在LCT报头之后可能存在可靠性报头。可靠性报头有助于描述包的有效载荷中携带的编码数据。可靠性报头的格式取决于所使用的编码，这是在带外协商的。例如，可以使用[12]中描述的FEC报头之一。
For LCT, when multiple rate congestion control is used, congestion control is achieved by sending packets associated with a given session to several LCT channels. Individual receivers dynamically join one or more of these channels, according to the network congestion as seen by the receiver. LCT headers include an opaque field which MUST be used to convey congestion control information to the receivers. The actual congestion control scheme to use with LCT is negotiated out-of-band. Some examples of congestion control protocols that may be suitable for content delivery are described in [22], [3], and [25]. Other congestion controls may be suitable when LCT is used for a streaming application.
对于LCT，当使用多速率拥塞控制时，通过将与给定会话相关联的数据包发送到多个LCT信道来实现拥塞控制。根据接收机看到的网络拥塞情况，单个接收机动态地加入一个或多个这些信道。LCT报头包括一个不透明字段，必须使用该字段将拥塞控制信息传送给接收方。与LCT一起使用的实际拥塞控制方案是在带外协商的。[22]、[3]和[25]中描述了可能适用于内容交付的拥塞控制协议的一些示例。当LCT用于流应用程序时，其他拥塞控制可能适用。
This document does not specify and restrict the type of exchanges between LCT (or any PI built on top of LCT) and an upper application. Some upper APIs may use an object-oriented approach, where the only possible unit of data exchanged between LCT (or any PI built on top of LCT) and an application, either at a source or at a receiver, is an object. Other APIs may enable a sending or receiving application to exchange a subset of an object with LCT (or any PI built on top of LCT), or may even follow a streaming model. These considerations are outside the scope of this document.
本文档未指定和限制LCT（或构建在LCT之上的任何PI）与上层应用程序之间的交换类型。一些上层API可能使用面向对象的方法，其中LCT（或构建在LCT之上的任何PI）和应用程序（无论是在源还是在接收器）之间交换的唯一可能的数据单元是对象。其他API可以使发送或接收应用程序能够与LCT（或构建在LCT之上的任何PI）交换对象的子集，甚至可以遵循流模型。这些注意事项不在本文件的范围内。
LCT is intended for congestion controlled delivery of objects and streams (both reliable content delivery and streaming of multimedia information).
LCT用于对象和流的拥塞控制交付（可靠内容交付和多媒体信息流）。
LCT can be used with both multicast and unicast delivery. LCT requires connectivity between a sender and receivers but does not require connectivity from receivers to a sender. LCT 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 LCT is unlimited. However, when other specific applications are built on top of LCT, then these applications by their very nature may limit scalability. For example, if an application requires receivers to retrieve out of band information in order to join a session, or an application allows receivers to send requests back to the sender to report reception statistics, then the scalability of the application is limited by the ability to send, receive, and process this additional data.
LCT可用于多播和单播传送。LCT需要发送方和接收方之间的连接，但不需要从接收方到发送方的连接。LCT固有地适用于所有类型的网络，包括LAN、WAN、内部网、Internet、非对称网络、无线网络和卫星网络。因此，LCT固有的原始可伸缩性是无限的。然而，当其他特定的应用程序构建在LCT之上时，这些应用程序本身就可能限制可伸缩性。例如，如果应用程序要求接收器检索带外信息以加入会话，或者应用程序允许接收器将请求发送回发送器以报告接收统计信息，则应用程序的可伸缩性受到发送、接收和处理此附加数据的能力的限制。
LCT requires receivers to be able to uniquely identify and demultiplex packets associated with an LCT session. In particular, there MUST be a Transport Session Identifier (TSI) associated with each LCT session. The TSI is scoped by the IP address of the sender, and the IP address of the sender together with the TSI MUST uniquely identify the session. If the underlying transport is UDP as described in RFC 768 [16], then the 16 bit UDP source port number MAY serve as the TSI for the session. The TSI value MUST be the same in all places it occurs within a packet. If there is no underlying TSI provided by the network, transport or any other layer, then the TSI MUST be included in the LCT header.
LCT要求接收器能够唯一地识别和解复用与LCT会话相关联的数据包。特别是，必须有一个与每个LCT会话相关联的传输会话标识符（TSI）。TSI的作用域由发送方的IP地址确定，发送方的IP地址和TSI必须唯一标识会话。如果底层传输为RFC 768[16]中所述的UDP，则16位UDP源端口号可作为会话的TSI。TSI值在数据包中出现的所有位置都必须相同。如果网络、传输或任何其他层未提供基础TSI，则TSI必须包含在LCT头中。
LCT is presumed to be used with an underlying network or transport service that is a "best effort" service that does not guarantee packet reception or packet reception order, and which does not have any support for flow or congestion control. For example, the Any-Source Multicast (ASM) model of IP multicast as defined in RFC 1112 [5] is such a "best effort" network service. While the basic service provided by RFC 1112 is largely scalable, providing congestion control or reliability should be done carefully to avoid severe scalability limitations, especially in presence of heterogeneous sets of receivers.
LCT被假定与底层网络或传输服务一起使用，该服务是“尽力而为”的服务，不保证数据包接收或数据包接收顺序，并且不支持流量或拥塞控制。例如，RFC 1112[5]中定义的IP多播的任意源多播（ASM）模型就是这样一种“尽力而为”的网络服务。虽然RFC 1112提供的基本服务在很大程度上是可伸缩的，但应小心地提供拥塞控制或可靠性，以避免严重的可伸缩性限制，特别是在存在异构接收机集的情况下。
There are currently two models of multicast delivery, the Any-Source Multicast (ASM) model as defined in RFC 1112 [5] and the Source-Specific Multicast (SSM) model as defined in [10]. LCT 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 the LCT channel address consists of the pair (S,G), where S is the IP address of the sender and G is a multicast group address. When using SSM, a sender S sends packets to an SSM channel (S,G), and the LCT channel address coincides with the SSM channel address.
目前有两种多播交付模型，RFC 1112[5]中定义的任意源多播（ASM）模型和[10]中定义的源特定多播（SSM）模型。LCT适用于这两种多播模型，但在环境问题上略有不同。当使用ASM时，发送方S向多播组G发送数据包，LCT信道地址由该对（S，G）组成，其中S是发送方的IP地址，G是多播组地址。使用SSM时，发送方S向SSM信道（S，G）发送数据包，LCT信道地址与SSM信道地址一致。
A sender can locally allocate unique SSM channel addresses, and this makes allocation of LCT channel addresses easy with SSM. To allocate LCT channel addresses using ASM, the sender must uniquely chose the ASM multicast group address across the scope of the group, and this makes allocation of LCT channel addresses more difficult with ASM.
发送方可以在本地分配唯一的SSM通道地址，这使得SSM可以轻松分配LCT通道地址。要使用ASM分配LCT通道地址，发送方必须在整个组范围内唯一选择ASM多播组地址，这使得使用ASM分配LCT通道地址更加困难。
LCT channels and SSM channels coincide, and thus the receiver will only receive packets sent to the requested LCT channel. With ASM, the receiver joins an LCT 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.
LCT信道和SSM信道重合，因此接收机将只接收发送到请求的LCT信道的数据包。使用ASM，接收器通过加入多播组G来加入LCT信道，并且发送到G的所有数据包，无论发送者是谁，都可以由接收器接收。因此，与ASM相比，SSM在防止拒绝服务攻击方面具有引人注目的安全优势。在这两种情况下，接收者都应该使用机制从不需要的来源过滤掉数据包。
Some networks are not amenable to some congestion control protocols that could be used with LCT. 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.
有些网络不适用于某些可与LCT一起使用的拥塞控制协议。具体地，对于卫星或无线网络，可能没有用于接收器有效降低其接收速率的机制，因为可能存在分配给会话的固定传输速率。
LCT can support several different delivery service models. Two examples are briefly described here.
LCT可以支持多种不同的交付服务模式。这里简要介绍两个例子。
Push service model.
推送服务模式。
One way a push service model can be used for reliable content delivery is to deliver a series of objects. For example, a receiver could join the session and dynamically adapt the number of LCT channels the receiver is joined to until enough packets have been received to reconstruct an object. After reconstructing the object the receiver may stay in the session and wait for the transmission of the next object.
推送服务模型用于可靠内容交付的一种方法是交付一系列对象。例如，接收器可以加入会话并动态调整接收器加入到的LCT通道的数量，直到接收到足够的数据包来重建对象。在重构对象之后，接收器可以停留在会话中并等待下一对象的传输。
The push model is particularly attractive in satellite networks and wireless networks. In these cases, a session may consist of one fixed rate LCT channel.
推送模式在卫星网络和无线网络中特别有吸引力。在这些情况下，会话可能由一个固定速率LCT信道组成。
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 the object. For example a popular software update might be transmitted
对于按需内容交付服务模型，发送方通常在指定的时间段内进行传输，该时间段被选择为足够长，以允许所有预期接收方加入会话并恢复对象。例如，可能会传输流行的软件更新
using LCT 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.
使用LCT几天，即使接收器可能能够在一个小时的总连接时间内完成下载，可能需要几个时间间隔。
In this case the receivers join the session, and dynamically adapt the number of LCT channels they subscribe to according to the available bandwidth. Receivers then drop from the session when they have received enough packets to recover the object.
在这种情况下，接收机加入会话，并根据可用带宽动态调整其订阅的LCT信道的数量。然后，当接收器接收到足够的数据包来恢复对象时，就会从会话中退出。
As an example, assume that an object is 50 MB. The sender could send 1 KB packets to the first LCT channel at 50 packets per second, so that receivers using just this LCT channel could complete reception of the object in 1,000 seconds in absence of loss, and would be able to complete reception even in presence of some substantial amount of losses with the use of coding for reliability. Furthermore, the sender could use a number of LCT channels such that the aggregate rate of 1 KB packets to all LCT channels is 1,000 packets per second, so that a receiver could be able to complete reception of the object in as little 50 seconds (assuming no loss and that the congestion control mechanism immediately converges to the use of all LCT channels).
例如，假设一个对象是50MB。发送方可以每秒50个分组向第一个LCT信道发送1kb分组，以便仅使用该LCT信道的接收机可以在没有丢失的情况下在1000秒内完成对象的接收，并且将能够通过使用可靠性编码来完成即使在存在一些大量丢失的情况下的接收。此外，发送方可以使用多个LCT信道，使得到所有LCT信道的1kb分组的聚合速率为每秒1000个分组，使得接收机能够在短短50秒内完成对象的接收（假设没有损失，并且拥塞控制机制立即收敛到使用所有LCT信道）。
Other service models.
其他服务模式。
There are many other delivery service models that LCT can be used for that are not covered above. As examples, a live streaming or an on-demand archival content streaming service model. A description of the many potential applications, the appropriate delivery service model, and the additional mechanisms to support such functionalities when combined with LCT is beyond the scope of this document. This document only attempts to describe the minimal common scalable elements to these diverse applications using LCT as the delivery transport.
LCT还可以用于许多其他交付服务模式，但上面没有介绍。例如，实时流媒体或按需存档内容流媒体服务模型。许多潜在应用的描述、适当的交付服务模型以及与LCT结合时支持此类功能的附加机制超出了本文档的范围。本文档仅试图描述使用LCT作为交付传输的这些不同应用程序的最小通用可扩展元素。
The specific congestion control protocol to be used for LCT sessions depends on the type of content to be delivered. While the general behavior of the congestion control protocol is to reduce the throughput in presence of congestion and gradually increase it in the absence of congestion, the actual dynamic behavior (e.g. response to single losses) can vary.
用于LCT会话的特定拥塞控制协议取决于要交付的内容类型。虽然拥塞控制协议的一般行为是在出现拥塞时降低吞吐量，并在没有拥塞时逐渐增加吞吐量，但实际的动态行为（例如对单个丢失的响应）可能会有所不同。
Some possible congestion control protocols for reliable content delivery using LCT are described in [22], [3], and [25]. Different delivery service models might require different congestion control protocols.
[22]、[3]和[25]中描述了使用LCT进行可靠内容交付的一些可能的拥塞控制协议。不同的交付服务模型可能需要不同的拥塞控制协议。
Packets sent to an LCT session MUST include an "LCT header". The LCT header format described below is the default format, and this is the format that is recommended for use by protocol instantiations to ensure a uniform format across different protocol instantiations. Other LCT header formats MAY be used by protocol instantiations, but if the default LCT header format is not used by a protocol instantiation that uses LCT, then the protocol instantiation MUST specify the lengths and positions within the LCT header it uses of all fields described in the default LCT header.
发送到LCT会话的数据包必须包含“LCT头”。下面描述的LCT头格式是默认格式，这是建议协议实例化使用的格式，以确保不同协议实例化的格式一致。协议实例化可使用其他LCT头格式，但如果使用LCT的协议实例化未使用默认LCT头格式，则协议实例化必须指定其使用的LCT头内默认LCT头中描述的所有字段的长度和位置。
Other building blocks MAY describe some of the same fields as described for the LCT header. It is RECOMMENDED that protocol instantiations using multiple building blocks include shared fields at most once in each packet. Thus, for example, if another building block is used with LCT that includes the optional Expected Residual Time field, then the Expected Residual Time field SHOULD be carried in each packet at most once.
其他构建块可以描述与LCT头相同的一些字段。建议使用多个构建块的协议实例化在每个数据包中最多包含一次共享字段。因此，例如，如果另一个构建块与包括可选的预期剩余时间字段的LCT一起使用，则预期剩余时间字段应最多在每个分组中携带一次。
The position of the LCT header within a packet MUST be specified by any protocol instantiation that uses LCT.
LCT头在数据包中的位置必须由使用LCT的任何协议实例化指定。
The default LCT header is of variable size, which is specified by a length field in the third byte of the header. In the LCT 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).
默认LCT头的大小是可变的，由头的第三个字节中的长度字段指定。在LCT报头中，所有整数字段都以“big-endian”或“network-order”格式携带，即首先是最高有效字节（octet）。指定为“填充”或“保留”（r）的位必须由发送方设置为0，并由接收方忽略。除非另有说明，本规范中的数值常量为十进制（以10为基数）。
The format of the default LCT header is depicted in Figure 1.
默认LCT头的格式如图1所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | C | r |S| O |H|T|R|A|B| HDR_LEN | Codepoint (CP)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Control Information (CCI, length = 32*(C+1) bits) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Session Identifier (TSI, length = 32*S+16*H bits) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Object Identifier (TOI, length = 32*O+16*H bits) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Current Time (SCT, if T = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Expected Residual Time (ERT, if R = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header Extensions (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | C | r |S| O |H|T|R|A|B| HDR_LEN | Codepoint (CP)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Control Information (CCI, length = 32*(C+1) bits) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Session Identifier (TSI, length = 32*S+16*H bits) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Object Identifier (TOI, length = 32*O+16*H bits) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Current Time (SCT, if T = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Expected Residual Time (ERT, if R = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header Extensions (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - Default LCT header format
图1-默认LCT头格式
The function and length of each field in the default LCT header is the following. Fields marked as "1" mean that the corresponding bits MUST be set to "1" by the sender. Fields marked as "r" or "0" mean that the corresponding bits MUST be set to "0" by the sender.
默认LCT标头中每个字段的功能和长度如下所示。标记为“1”的字段表示发送方必须将相应的位设置为“1”。标记为“r”或“0”的字段表示发送方必须将相应位设置为“0”。
LCT version number (V): 4 bits
LCT版本号（V）：4位
Indicates the LCT version number. The LCT version number for this specification is 1.
指示LCT版本号。本规范的LCT版本号为1。
Congestion control flag (C): 2 bits
拥塞控制标志（C）：2位
C=0 indicates the Congestion Control Information (CCI) field is 32-bits in length. C=1 indicates the CCI field is 64-bits in length. C=2 indicates the CCI field is 96-bits in length. C=3 indicates the CCI field is 128-bits in length.
C=0表示拥塞控制信息（CCI）字段的长度为32位。C=1表示CCI字段的长度为64位。C=2表示CCI字段的长度为96位。C=3表示CCI字段的长度为128位。
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.
保留供将来使用。发送方必须将这些位设置为零，接收方必须忽略这些位。
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, i.e. the length is either 0 bits, 16 bits, 32 bits, or 48 bits.
这是TSI字段中完整的32位字数。TSI字段的长度为32*S+16*H位，即长度为0位、16位、32位或48位。
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, i.e., the length is either 0 bits, 16 bits, 32 bits, 48 bits, 64 bits, 80 bits, 96 bits, or 112 bits.
这是TOI字段中完整的32位字数。TOI字段的长度为32*O+16*H位，即长度为0位、16位、32位、48位、64位、80位、96位或112位。
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位的倍数。
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以向接收方指示会话进行了多长时间。
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. The ERT is inserted by senders to indicate to receivers how much longer the session / object transmission will continue.
R=0表示预期剩余时间（ERT）字段不存在。R=1表示存在ERT字段。发送方插入ERT，以向接收方指示会话/对象传输将持续多长时间。
Senders MUST NOT set R = 1 when the ERT for the session is more than 2^32-1 time units (approximately 49 days), where time is measured in units of milliseconds.
当会话的ERT超过2^32-1时间单位（约49天）时，发送方不得将R=1设置为以毫秒为单位的时间。
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
通常，A设置为0。当用于会话的分组的传输即将终止时，发送方可以将A设置为1。A可以仅在为会话发送的最后一个分组中被设置为1，或者A可以在为会话发送的分组的最后几秒钟中被设置为1。一旦发送方在一个数据包中将A设置为1，发送方应在所有后续数据包中将A设置为1，直到数据传输终止
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.
会话的数据包。设置为1的接收到的数据包向接收方指示发送方将立即停止为会话发送数据包。当接收器接收到设置为1的数据包时，接收器应假定不再向会话发送数据包。
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的数据包时，它应该假定不再向会话发送对象的数据包。
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., to the first other header if it exists, or to the packet payload if it exists and there is no other header, or to the end of the packet if there are no other headers or packet payload.
LCT标头的总长度，以32位字为单位。LCT头的长度必须是32位的倍数。该字段可用于直接访问LCT报头之外的数据包部分，即，如果存在第一个其他报头，则访问第一个其他报头；如果存在且没有其他报头，则访问数据包有效载荷；如果没有其他报头或数据包有效载荷，则访问数据包的末尾。
Codepoint (CP): 8 bits
码点（CP）：8位
An opaque identifier which is passed to the packet payload decoder to convey information on the codec being used for the packet payload. The mapping between the codepoint and the actual codec is defined on a per session basis and communicated out-of-band as part of the session description information. The use of the CP field is similar to the Payload Type (PT) field in RTP headers as described in RFC 1889 [21].
一种不透明标识符，传递给包有效载荷解码器，以传递关于用于包有效载荷的编解码器的信息。代码点和实际编解码器之间的映射在每个会话的基础上定义，并作为会话描述信息的一部分在带外进行通信。CP字段的使用类似于RFC 1889[21]中描述的RTP报头中的有效负载类型（PT）字段。
Congestion Control Information (CCI): 32, 64, 96 or 128 bits
拥塞控制信息（CCI）：32、64、96或128位
Used to carry congestion control information. For example, the congestion control information could include layer numbers, logical channel numbers, and sequence numbers. This field is opaque for the purpose of this specification.
用于承载拥塞控制信息。例如，拥塞控制信息可以包括层号、逻辑信道号和序列号。就本规范而言，此字段是不透明的。
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位。
Transport Session Identifier (TSI): 0, 16, 32 or 48 bits
传输会话标识符（TSI）：0、16、32或48位
The TSI uniquely identifies a session among all sessions from a particular sender. The TSI is scoped by the IP address of the sender, and thus the IP address of the sender and the TSI together uniquely identify the session. Although a TSI in conjunction with the IP address of the sender always uniquely identifies a session, whether or not the TSI is included in the LCT header depends on what is used as the TSI value. If the underlying transport is UDP, then the 16 bit UDP source port number MAY serve as the TSI for the session. If the TSI value appears multiple times in a packet then all occurrences MUST be the same value. If there is no underlying TSI provided by the network, transport or any other layer, then the TSI MUST be included in the LCT header.
TSI在来自特定发送方的所有会话中唯一标识一个会话。TSI的范围由发送方的IP地址确定，因此发送方的IP地址和TSI一起唯一地标识会话。尽管TSI与发送方的IP地址一起始终唯一地标识会话，但该TSI是否包含在LCT头中取决于用作TSI值的内容。如果基础传输是UDP，则16位UDP源端口号可以用作会话的TSI。如果TSI值在数据包中多次出现，则所有出现的值必须相同。如果网络、传输或任何其他层未提供基础TSI，则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 the 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位的倍数。
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位的倍数。
Sender Current Time (SCT): 0 or 32 bits
发送方当前时间（SCT）：0或32位
This field represents the current clock at the sender and 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，此字段必须存在。
Expected Residual Time (ERT): 0 or 32 bits
预期剩余时间（ERT）：0或32位
This field represents the sender expected residual transmission time for the current session or for the transmission of the current object, measured in units of 1ms. If the packet containing the ERT field also contains the TOI field, then ERT refers to the object corresponding to the TOI field, otherwise it refers to the session.
此字段表示当前会话或当前对象传输的发送方预期剩余传输时间，单位为1ms。如果包含ERT字段的数据包也包含TOI字段，则ERT引用与TOI字段对应的对象，否则它引用会话。
This field MUST NOT be present if R=0 and MUST be present if R=1.
如果R=0，此字段不得存在；如果R=1，此字段必须存在。
Header Extensions are used in LCT to accommodate optional header fields that are not always used or have variable size. Examples of the use of Header Extensions include:
标题扩展在LCT中用于容纳不总是使用或大小可变的可选标题字段。标题扩展的使用示例包括：
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 LCT without changing the LCT version number. Non backward-compatible header extensions CANNOT be introduced without changing the LCT version number.
如果存在，则必须处理报头扩展，以确保在执行任何拥塞控制过程或以其他方式接受数据包之前识别它们。无法识别的标头扩展的默认操作是忽略它们。这允许将来在不更改LCT版本号的情况下向LCT引入向后兼容的增强功能。如果不更改LCT版本号，则无法引入不向后兼容的标头扩展。
Protocol instantiation MAY override this default behavior for PI-specific extensions (see below).
协议实例化可能会覆盖PI特定扩展的此默认行为（见下文）。
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 2 - Format of additional headers
图2-附加标题的格式
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 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.
标题扩展的内容。此子字段的格式取决于标题扩展类型。对于固定长度的报头扩展，HEC为24位。对于可变长度标头扩展，HEC字段具有由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
EXT_AUTH=1用于验证数据包发送方身份的数据包身份验证扩展信息。此标头扩展名的格式及其扩展名
processing is outside the scope of this document and is to be communicated out-of-band as part of the session description.
处理不在本文件范围内，将作为会话描述的一部分在带外进行沟通。
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.
建议发送方提供某种形式的数据包身份验证。如果存在EXT_AUTH，则在接收数据包并对其执行任何与拥塞控制相关的操作之前，应执行可在接收数据包后立即执行的任何数据包身份验证检查。
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.
一些分组认证方案在接收分组和分组完全认证之间施加几秒钟的延迟。任何与拥塞控制相关的适当行动不得因任何此类完整数据包身份验证而延迟。
All senders and receivers implementing LCT MUST support the EXT_NOP Header Extension and MUST recognize EXT_AUTH, but MAY NOT be able to parse its content.
所有实现LCT的发送方和接收方必须支持EXT_NOP头扩展，并且必须识别EXT_AUTH，但可能无法解析其内容。
Before joining an LCT session a receiver MUST obtain a session description. The session description MUST include:
在加入LCT会话之前，接收方必须获得会话描述。会话描述必须包括：
o The sender IP address;
o 发送方IP地址；
o The number of LCT channels;
o LCT频道的数量；
o The addresses and port numbers used for each LCT channel;
o 每个LCT通道使用的地址和端口号；
o The Transport Session ID (TSI) to be used for the session;
o 用于会话的传输会话ID（TSI）；
o Enough information to determine the congestion control protocol being used;
o 足够的信息来确定正在使用的拥塞控制协议；
o Enough information to determine the packet authentication scheme being used if it is being used.
o 足够的信息，以确定正在使用的数据包身份验证方案（如果正在使用）。
The session description could also include, but is not limited to:
会话描述还可以包括但不限于：
o The data rates used for each LCT channel;
o 每个LCT信道使用的数据速率；
o The length of the packet payload;
o 分组有效载荷的长度；
o The mapping of TOI value(s) to objects for the session;
o 将TOI值映射到会话的对象；
o Any information that is relevant to each object being transported, such as when it will be available within the session, for how long, and the length of the object;
o 与正在传输的每个对象相关的任何信息，例如在会话中何时可用、多长时间以及对象的长度；
Protocol instantiations using LCT MAY place additional requirements on what must be included in the session description. For example, a protocol instantiation might require that the data rates for each channel, or the mapping of TOI value(s) to objects for the session, or other information related to other headers that might be required to be included in the session description.
使用LCT的协议实例化可能会对会话描述中必须包含的内容提出额外要求。例如，协议实例化可能需要每个通道的数据速率，或TOI值到会话对象的映射，或与会话描述中可能需要包含的其他头相关的其他信息。
The session description could be in a form such as SDP as defined in RFC 2327 [8], or XML metadata as defined in RFC 3023 [14], or HTTP/Mime headers as defined in RFC 2068 [6], etc. It might be carried in a session announcement protocol such as SAP as defined in RFC 2974 [9], 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 format, and distribution of session descriptions is beyond the scope of this document.
会话描述可以是RFC 2327[8]中定义的SDP，或RFC 3023[14]中定义的XML元数据，或RFC 2068[6]中定义的HTTP/Mime头等形式。它可以在会话公告协议（如RFC 2974[9]中定义的SAP）中携带，该协议使用专有会话控制协议获得，位于包含日程安排信息的网页上，或通过电子邮件或其他带外方法传送。关于会话描述格式的讨论以及会话描述的分发超出了本文档的范围。
Within an LCT session, a sender using LCT transmits a sequence of packets, each in the format defined above. Packets are sent from a sender using one or more LCT channels which together constitute a session. Transmission rates may be different in different channels and may vary over time. The specification of the other building block headers and the packet payload used by a complete protocol instantiation using LCT is beyond the scope of this document. This document does not specify the order in which packets are transmitted, nor the organization of a session into multiple channels. Although these issues affect the efficiency of the protocol, they do not affect the correctness nor the inter-operability of LCT between senders and receivers.
在LCT会话中，使用LCT的发送方发送一系列数据包，每个数据包采用上述定义的格式。使用一个或多个LCT信道从发送方发送数据包，这些信道共同构成会话。不同信道中的传输速率可能不同，并且可能随时间而变化。使用LCT的完整协议实例化所使用的其他构建块头和数据包有效负载的规范超出了本文档的范围。本文档未指定数据包的传输顺序，也未指定将会话组织到多个通道中。尽管这些问题影响了协议的效率，但它们并不影响发送端和接收端之间LCT的正确性和互操作性。
Several objects can be carried within the same LCT session. In this case, each object MUST be identified by a unique TOI. Objects MAY be transmitted sequentially, or they MAY be transmitted concurrently. 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.
在同一LCT会话中可以携带多个对象。在这种情况下，每个对象必须由唯一的TOI标识。对象可以按顺序发送，也可以同时发送。如果参与该会话部分的接收者对接收所有对象感兴趣，则最好只在同一会话中并发发送对象。原因是，让接收器接收他们不感兴趣的对象的数据会浪费带宽和网络资源。
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.
数据包已发送，或者某些带外信号（可能来自更高级别的协议）已指示足够数量的接收器已完成。
For the reasons mentioned above, this document does not pose any restriction on packet sizes. However, network efficiency considerations recommend that the sender uses an 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 when fragmentation coupled with packet loss might introduce severe inefficiency in the transmission.
出于上述原因，本文件对数据包大小没有任何限制。然而，网络效率考虑建议发送方使用尽可能大的分组有效载荷大小，但是以这样的方式分组不超过网络的最大传输单元大小（MTU），或者当碎片与分组丢失耦合时可能在传输中引入严重的低效率。
It is recommended that all packets have the same or very similar sizes, as this can have a severe impact on the effectiveness of congestion control schemes such as the ones described in [22], [3], and [25]. A sender of packets using LCT MUST implement the sender-side part of one of the congestion control schemes that is in accordance with RFC 2357 [13] using the Congestion Control Information field provided in the LCT header, and the corresponding receiver congestion control scheme is to be communicated out-of-band and MUST be implemented by any receivers participating in the session.
建议所有数据包具有相同或非常相似的大小，因为这可能严重影响拥塞控制方案的有效性，如[22]、[3]和[25]中所述。使用LCT的数据包的发送方必须使用LCT报头中提供的拥塞控制信息字段，实现其中一个拥塞控制方案的发送方部分，该方案符合RFC 2357[13]，相应的接收机拥塞控制方案将在带外通信，并且必须由参与会话的任何接收机实现。
Receivers can operate differently depending on the delivery service model. For example, for an on demand service model, receivers may join a session, obtain the necessary packets to reproduce the object, and then leave the session. As another example, for a streaming service model, a receiver may be continuously joined to a set of LCT channels to download all objects in a session.
根据交付服务模式的不同，接收者可以进行不同的操作。例如，对于按需服务模型，接收机可以加入会话，获得必要的分组以再现对象，然后离开会话。作为另一示例，对于流式服务模型，接收机可以连续地加入到一组LCT信道以下载会话中的所有对象。
To be able to participate in a session, a receiver MUST obtain the relevant session description information as listed in Section 6.1.
为了能够参与会话，接收方必须获得第6.1节中列出的相关会话描述信息。
If packet authentication information is present in an LCT header, it SHOULD be used as specified in Section 5.2. To be able to be a receiver in a session, the receiver MUST be able to process the LCT 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 a LCT header, it MUST drop from the session.
如果LCT报头中存在数据包身份验证信息，则应按照第5.2节的规定使用该信息。为了能够成为会话中的接收器，接收器必须能够处理LCT报头。接收器必须能够丢弃、转发、存储或处理其他报头和数据包有效负载。如果接收器无法处理LCT头，则必须从会话中删除。
To be able to participate in a session, a receiver MUST implement the congestion control protocol specified in the session description using the Congestion Control Information field provided in the LCT header. If a receiver is not able to implement the congestion control protocol used in the session, it MUST NOT join the session. When the session is transmitted on multiple LCT channels, receivers MUST
为了能够参与会话，接收方必须使用LCT报头中提供的拥塞控制信息字段实现会话描述中指定的拥塞控制协议。如果接收器无法实现会话中使用的拥塞控制协议，则它不得加入会话。当会话在多个LCT信道上传输时，接收机必须
initially join channels according to the specified startup behavior of the congestion control protocol. For a multiple rate congestion control protocol that uses multiple channels, this typically means that a receiver will initially join only a minimal set of LCT channels, possibly a single one, that in aggregate are carrying packets at a low rate. This rule has the purpose of preventing receivers from starting at high data rates.
根据拥塞控制协议的指定启动行为初始加入通道。对于使用多个信道的多速率拥塞控制协议，这通常意味着接收器最初将仅加入最小的LCT信道集，可能是单个信道，这些信道集中以低速率承载数据包。此规则的目的是防止接收器以高数据速率启动。
Several objects can be carried either sequentially or concurrently within the same LCT session. In this case, each object is identified by a unique TOI. Note that even if a server 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 LCT 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.
在同一LCT会话中，可以顺序或同时携带多个对象。在这种情况下，每个对象都由唯一的TOI标识。请注意，即使服务器在开始传输新对象的数据包之前停止发送旧对象的数据包，网络和底层协议层都可能导致数据包重新排序，特别是在通过不同LCT通道发送时，因此，接收机不应假设接收到新对象的分组意味着至少在一段时间内没有前一个对象的更多分组在传输中。
A receiver MAY be concurrently joined to multiple LCT sessions from one or more senders. The receiver MUST perform congestion control on each such LCT session. If the congestion control protocol allows the receiver some flexibility in terms of its actions within a session then the receiver MAY make choices to optimize the packet flow performance across the multiple LCT sessions, as long as the receiver still adheres to the congestion control rules for each LCT session individually.
接收机可以同时加入来自一个或多个发送方的多个LCT会话。接收方必须在每个这样的LCT会话上执行拥塞控制。如果拥塞控制协议允许接收机在其在会话内的动作方面具有一定的灵活性，那么只要接收机仍然单独遵守每个LCT会话的拥塞控制规则，接收机就可以做出选择来优化多个LCT会话的分组流性能。
As described in RFC 3048 [23], LCT is a building block that is intended to be used, in conjunction with other building blocks, to help specify a protocol instantiation. A congestion control building block that uses the Congestion Control information field within the LCT header MUST be used by any protocol instantiation that uses LCT, and other building blocks MAY also be used, such as a reliability building block.
如RFC 3048[23]所述，LCT是一个构建块，旨在与其他构建块一起使用，以帮助指定协议实例化。任何使用LCT的协议实例化都必须使用LCT头中使用拥塞控制信息字段的拥塞控制构建块，也可以使用其他构建块，例如可靠性构建块。
The congestion control MUST be applied to the LCT session as an entity, i.e., over the aggregate of the traffic carried by all of the LCT channels associated with the LCT session. Some possible schemes are specified in [22], [3], and [25]. The Congestion Control Information field in the LCT header is an opaque field that is reserved to carry information related to congestion control. There MAY also be congestion control Header Extension fields that carry additional information related to congestion control.
拥塞控制必须作为一个实体应用于LCT会话，即与LCT会话相关联的所有LCT信道承载的流量的总和。[22]、[3]和[25]中规定了一些可能的方案。LCT标头中的拥塞控制信息字段是一个不透明字段，保留该字段以承载与拥塞控制相关的信息。也可能有拥塞控制标头扩展字段，其中包含与拥塞控制相关的附加信息。
The particular layered encoder and congestion control protocols used with LCT have an impact on the performance and applicability of LCT. For example, some layered encoders used for video and audio streams can produce a very limited number of layers, thus providing a very coarse control in the reception rate of packets by receivers in a session. When LCT is used for reliable data transfer, some FEC codecs are inherently limited in the size of the object they can encode, and for objects larger than this size the reception overhead on the receivers can grow substantially.
与LCT一起使用的特定分层编码器和拥塞控制协议对LCT的性能和适用性有影响。例如，用于视频和音频流的一些分层编码器可以产生非常有限数量的层，从而提供会话中接收器对分组的接收速率的非常粗略的控制。当LCT用于可靠的数据传输时，一些FEC编解码器在其可以编码的对象的大小上固有地受到限制，并且对于大于此大小的对象，接收机上的接收开销可以显著增加。
A more in-depth description of the use of FEC in Reliable Multicast Transport (RMT) protocols is given in [11]. Some of the FEC codecs that MAY be used in conjunction with LCT for reliable content delivery are specified in [12]. The Codepoint field in the LCT header is an opaque field that can be used to carry information related to the encoding of the packet payload.
[11]更深入地描述了FEC在可靠多播传输（RMT）协议中的使用。[12]中规定了一些可与LCT结合使用以实现可靠内容交付的FEC编解码器。LCT报头中的Codepoint字段是不透明字段，可用于携带与分组有效载荷的编码相关的信息。
LCT also requires receivers to obtain a session description, as described in Section 6.1. The session description could be in a form such as SDP as defined in RFC 2327 [8], or XML metadata as defined in RFC 3023 [14], or HTTP/Mime headers as defined in RFC 2068 [6], and distributed with SAP as defined in RFC 2974 [9], using HTTP, or in other ways. It is RECOMMENDED that an authentication protocol such as IPSEC [11] be used to deliver the session description to receivers to ensure the correct session description arrives.
LCT还要求接收机获得会话描述，如第6.1节所述。会话描述可以采用RFC 2327[8]中定义的SDP、RFC 3023[14]中定义的XML元数据或RFC 2068[6]中定义的HTTP/Mime头等形式，并使用HTTP或其他方式与RFC 2974[9]中定义的SAP一起分发。建议使用诸如IPSEC[11]之类的身份验证协议将会话描述传递给接收方，以确保正确的会话描述到达。
It is recommended that LCT implementors use some packet authentication scheme to protect the protocol from attacks. An example of a possibly suitable scheme is described in [15].
建议LCT实现人员使用一些数据包身份验证方案来保护协议免受攻击。[15]中描述了可能合适的方案的示例。
Some protocol instantiations that use LCT MAY use building blocks that require the generation of feedback from the receivers to the sender. However, the mechanism for doing this is outside the scope of LCT.
一些使用LCT的协议实例可能会使用需要生成从接收方到发送方的反馈的构建块。然而，这样做的机制超出了LCT的范围。
LCT can be subject to denial-of-service attacks by attackers which try to confuse the congestion control mechanism, or send forged packets to the session which would prevent successful reconstruction or cause inaccurate reconstruction of large portions of an object by receivers. LCT is particularly affected by such an attack since many receivers may receive the same forged packet. It is therefore RECOMMENDED that an integrity check be made on received objects before delivery to an application, e.g., by appending an MD5 hash [17] to an object before it is sent and then computing the MD5 hash once the object is reconstructed to ensure it is the same as the sent object. Moreover, in order to obtain strong cryptographic integrity
LCT可能受到攻击者的拒绝服务攻击，攻击者试图混淆拥塞控制机制，或向会话发送伪造数据包，这将阻止成功重建或导致接收者不准确地重建对象的大部分。LCT尤其受到此类攻击的影响，因为许多接收者可能会收到相同的伪造数据包。因此，建议在将接收到的对象交付给应用程序之前对其进行完整性检查，例如，在发送对象之前将MD5哈希[17]附加到对象，然后在重构对象后计算MD5哈希，以确保其与发送的对象相同。此外，为了获得强大的密码完整性
protection a digital signature verifiable by the receiver SHOULD be computed on top of such a hash value. It is also RECOMMENDED that protocol instantiations that use LCT implement some form of packet authentication such as TESLA [15] to protect against such attacks. Finally, it is RECOMMENDED that Reverse Path Forwarding checks 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.
保护接收方可验证的数字签名应在此类散列值的基础上计算。还建议使用LCT的协议实例化实现某种形式的数据包身份验证，如TESLA[15]，以防止此类攻击。最后，建议在从发送方到接收方的路径上的所有网络路由器和交换机中启用反向路径转发检查，以限制坏代理将伪造数据包注入多播树数据路径的可能性。
Another vulnerability of LCT 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.
LCT的另一个漏洞是接收方可能获得错误的会话描述。这可能导致具有错误会话描述的合法接收器无法正确接收会话内容，或者接收器无意中尝试以远高于其能力的速率接收，从而中断网络部分中的通信。为了避免这些问题，建议采取措施防止接收者接受不正确的会话描述，例如，通过使用源身份验证确保接收者只接受来自授权发送者的合法会话描述。
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.
具有多速率拥塞控制构建块的不正确或损坏的实现的接收器可能影响发送方和接收器之间路径中的网络健康，并且还可能影响加入会话的其他接收器的接收速率。因此，建议要求接收者在接收加入会话所需的会话描述之前将自己标识为合法。接收人如何认定自己合法不在本文件范围内。
No information in this specification is subject to IANA registration.
本规范中的任何信息均无需IANA注册。
Building blocks used in conjunction with LCT MAY introduce additional IANA considerations.
与LCT结合使用的构建块可能会引入额外的IANA注意事项。
Thanks to Vincent Roca and Roger Kermode for detailed comments and contributions to this document. Thanks also to Bruce Lueckenhoff, Hayder Radha and Justin Chapweske for detailed comments on this document.
感谢Vincent Roca和Roger Kermode对本文件的详细评论和贡献。还感谢Bruce Lueckenhoff、Hayder Radha和Justin Chapweske对本文件的详细评论。
[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] Byers, J.W., Frumin, M., Horn, G., Luby, M., Mitzenmacher, M., Roetter, A. and W. Shaver, "FLID-DL: Congestion Control for Layered Multicast", Proceedings of Second International Workshop on Networked Group Communications (NGC 2000), Palo Alto, CA, November 2000.
[3] Byers，J.W.，Frumin，M.，Horn，G.，Luby，M.，Mitzenmacher，M.，Roetter，A.和W.Shaver，“FLID-DL：分层多播的拥塞控制”，第二届网络化群组通信国际研讨会论文集（NGC 2000），加利福尼亚州帕洛阿尔托，2000年11月。
[4] Byers, J.W., Luby, M., Mitzenmacher, M. and A. Rege, "A Digital Fountain Approach to Reliable Distribution of Bulk Data", Proceedings ACM SIGCOMM'98, Vancouver, Canada, September 1998.
[4] Byers，J.W.，Luby，M.，Mitzenmacher，M.和A.Rege，“批量数据可靠分发的数字喷泉方法”，ACM SIGCOMM'98论文集，加拿大温哥华，1998年9月。
[5] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[5] Deering，S.，“IP多播的主机扩展”，STD 5，RFC 1112，1989年8月。
[6] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, January 1997.
[6] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1997年1月。
[7] Gemmell, J., Schooler, E. and J. Gray, "Fcast Multicast File Distribution", IEEE Network, Vol. 14, No. 1, pp. 58-68, January 2000.
[7] Gemmell，J.，Schooler，E.和J.Gray，“Fcast多播文件分发”，IEEE网络，第14卷，第1期，第58-68页，2000年1月。
[8] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[8] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[9] Handley, M., Perkins, C. and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[9] Handley，M.，Perkins，C.和E.Whelan，“会话公告协议”，RFC 29742000年10月。
[10] Holbrook, H. W., "A Channel Model for Multicast", Ph.D. Dissertation, Stanford University, Department of Computer Science, Stanford, California, August 2001.
[10] 霍尔布鲁克，H.W.，“多播的信道模型”，博士。斯坦福大学计算机科学系博士论文，斯坦福，加利福尼亚，2001年8月。
[11] 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.
[11] Luby，M.，Vicisano，L.，Gemmell，J.，Rizzo，L.，Handley，M.和J.Crowcroft，“前向纠错（FEC）在可靠多播中的使用”，RFC 3453，2002年12月。
[12] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and J. Crowcroft, "Forward Error Correction (FEC) Building Block", RFC 3452, December 2002.
[12] 卢比，M.，维西萨诺，L.，杰梅尔，J.，里佐，L.，汉德利，M.和J.克罗夫特，“前向纠错（FEC）构建块”，RFC 3452，2002年12月。
[13] Mankin, A., Romanow, A., Bradner, S. and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
[13] Mankin，A.，Romanow，A.，Bradner，S.和V.Paxson，“IETF评估可靠多播传输和应用协议的标准”，RFC 2357，1998年6月。
[14] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[14] Murata，M.，St.Laurent，S.和D.Kohn，“XML媒体类型”，RFC 3023，2001年1月。
[15] 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.
[15] Perrig，A.，Canetti，R.，Song，D.和J.D.Tygar，“多播的高效和安全源认证”，网络和分布式系统安全研讨会，NDSS 2001，第35-46页，2001年2月。
[16] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[16] Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[17] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[17] Rivest，R.，“MD5消息摘要算法”，RFC1321，1992年4月。
[18] Rizzo, L., "Effective Erasure Codes for Reliable Computer Communication Protocols", ACM SIGCOMM Computer Communication Review, Vol.27, No.2, pp.24-36, Apr 1997.
[18] Rizzo，L.“可靠计算机通信协议的有效擦除码”，《ACM SIGCOMM计算机通信评论》，第27卷，第2期，第24-36页，1997年4月。
[19] Rizzo, L, "PGMCC: A TCP-friendly single-rate multicast congestion control scheme", Proceedings of SIGCOMM 2000, Stockholm Sweden, August 2000.
[19] Rizzo，L，“PGMCC：一种TCP友好的单速率多播拥塞控制方案”，SIGCOMM 2000年论文集，瑞典斯德哥尔摩，2000年8月。
[20] Rizzo, L and L. Vicisano, "Reliable Multicast Data Distribution protocol based on software FEC techniques", Proceedings of the Fourth IEEES Workshop on the Architecture and Implementation of High Performance Communication Systems, HPCS'97, Chalkidiki Greece, June 1997.
[20] Rizzo，L和L.Vicisano，“基于软件FEC技术的可靠多播数据分发协议”，第四届IEEES高性能通信系统体系结构和实现研讨会论文集，HPCS'97，Chalkidiki希腊，1997年6月。
[21] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[21] Schulzrinne，H.，Casner，S.，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC 1889，1996年1月。
[22] Vicisano, L., Rizzo, L. and J. Crowcroft, "TCP-like Congestion Control for Layered Multicast Data Transfer", IEEE Infocom'98, San Francisco, CA, Mar.28-Apr.1 1998.
[22] ViSISANO，L.，RiZZO，L.和C.CurrCROFT，“类似TCP拥塞控制的分层多播数据传输”，IEEE iFoCOM’98，旧金山，CA，MAR.23-APR.1 1998。
[23] 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.
[23] Whetten，B.，Vicisano，L.，Kermode，R.，Handley，M.，Floyd，S.和M.Luby，“一对多批量数据传输的可靠多播传输构建块”，RFC 3048，2001年1月。
[24] Kermode, R., Vicisano, L., "Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents", RFC 3269, April 2002.
[24] Kermode，R.，Vicisano，L.，“可靠多播传输（RMT）构建块和协议实例化文档的作者指南”，RFC 3269，2002年4月。
[25] Luby, M., Goyal V. K, Skaria S., Horn, G., "Wave and Equation Based Rate Control using Multicast Round-trip Time", Proceedings of ACM SIGCOMM 2002, Pittsburgh PA, August, 2002.
[25] Luby，M.，Goyal V.K.，Skaria S.，Horn，G.，“使用多播往返时间的基于波动和方程的速率控制”，ACM SIGCOMM 2002年论文集，宾夕法尼亚州匹兹堡，2002年8月。
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
Mark Handley ICIR 1947 Center St. Berkeley, CA, USA, 94704
美国加利福尼亚州圣伯克利市马克·汉德利ICIR 1947中心，邮编94704
EMail: mjh@icir.org
EMail: mjh@icir.org
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编辑功能的资金目前由互联网协会提供。