Network Working Group M. Luby
Request for Comments: 5651 M. Watson
Obsoletes: 3451 L. Vicisano
Category: Standards Track Qualcomm, Inc.
October 2009
Network Working Group M. Luby
Request for Comments: 5651 M. Watson
Obsoletes: 3451 L. Vicisano
Category: Standards Track Qualcomm, Inc.
October 2009
Layered Coding Transport (LCT) Building Block
分层编码传输（LCT）构建块
Abstract
摘要
The Layered Coding Transport (LCT) Building Block provides transport level support for reliable content delivery and stream delivery protocols. LCT is specifically designed to support protocols using IP multicast, but it 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. This document obsoletes RFC 3451.
分层编码传输（LCT）构建块为可靠的内容交付和流交付协议提供传输级支持。LCT专门设计用于支持使用IP多播的协议，但它也支持使用单播的协议。LCT与向接收器提供多速率传送的拥塞控制兼容，还与提供可靠内容传送的编码技术兼容。本文件淘汰RFC 3451。
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括《信托法律条款》第4.e节中所述的简化BSD许可文本，并且提供BSD许可中所述的代码组件时不提供任何担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。
Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
2. Rationale .......................................................3
3. Functionality ...................................................4
4. Applicability ...................................................7
4.1. Environmental Requirements and Considerations ..............9
4.2. Delivery Service Models ...................................10
4.3. Congestion Control ........................................13
5. Packet Header Fields ...........................................13
5.1. LCT Header Format .........................................13
5.2. Header-Extension Fields ...................................18
5.2.1. General ............................................18
5.2.2. EXT_TIME Header Extension ..........................20
6. Operations .....................................................23
6.1. Sender Operation ..........................................23
6.2. Receiver Operation ........................................25
7. Requirements from Other Building Blocks ........................26
8. Security Considerations ........................................28
8.1. Session and Object Multiplexing and Termination ...........28
8.2. Time Synchronization ......................................29
8.3. Data Transport ............................................29
9. IANA Considerations ............................................29
9.1. Namespace Declaration for LCT Header Extension Types ......29
9.2. LCT Header Extension Type Registration ....................30
10. Acknowledgments ...............................................30
11. Changes from RFC 3451 .........................................31
12. References ....................................................31
12.1. Normative References .....................................31
12.2. Informative References ...................................32
1. Introduction ....................................................3
2. Rationale .......................................................3
3. Functionality ...................................................4
4. Applicability ...................................................7
4.1. Environmental Requirements and Considerations ..............9
4.2. Delivery Service Models ...................................10
4.3. Congestion Control ........................................13
5. Packet Header Fields ...........................................13
5.1. LCT Header Format .........................................13
5.2. Header-Extension Fields ...................................18
5.2.1. General ............................................18
5.2.2. EXT_TIME Header Extension ..........................20
6. Operations .....................................................23
6.1. Sender Operation ..........................................23
6.2. Receiver Operation ........................................25
7. Requirements from Other Building Blocks ........................26
8. Security Considerations ........................................28
8.1. Session and Object Multiplexing and Termination ...........28
8.2. Time Synchronization ......................................29
8.3. Data Transport ............................................29
9. IANA Considerations ............................................29
9.1. Namespace Declaration for LCT Header Extension Types ......29
9.2. LCT Header Extension Type Registration ....................30
10. Acknowledgments ...............................................30
11. Changes from RFC 3451 .........................................31
12. References ....................................................31
12.1. Normative References .....................................31
12.2. Informative References ...................................32
Layered Coding Transport (LCT) 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 it 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.
分层编码传输（LCT）为可靠的内容交付和流交付协议提供传输级支持。分层编码传输专门设计用于支持使用IP多播的协议，但它也支持使用单播的协议。分层编码传输与向接收器提供多速率传送的拥塞控制兼容，也与提供可靠内容传送的编码技术兼容。
This document describes a building block as defined in [RFC3048]. This document is a product of the IETF RMT WG and follows the general guidelines provided in [RFC3269].
本文件描述了[RFC3048]中定义的构造块。本文件是IETF RMT工作组的产品，遵循[RFC3269]中提供的一般指南。
[RFC3451], which was published in the "Experimental" category and which is obsoleted by this document, contained a previous version of the protocol.
[RFC3451]以“实验性”类别出版，本文件已将其淘汰，其中包含该协议的早期版本。
This Proposed Standard specification is thus based on and backwards compatible with the protocol defined in [RFC3451] updated according to accumulated experience and growing protocol maturity since its original publication. Said experience applies both to this specification itself and to congestion control strategies related to the use of this specification.
因此，本拟议标准规范基于[RFC3451]中定义的协议，并与之向后兼容，该协议根据其原始发布以来积累的经验和不断增长的协议成熟度进行更新。上述经验既适用于本规范本身，也适用于与本规范使用相关的拥塞控制策略。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
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.
LCT会话包括源自单个发送方的多个信道，这些信道在一段时间内用于承载与一个或多个对象的传输有关的数据包，这些对象可能是接收方感兴趣的。将会话定义为源自单个发送方的逻辑是，这是通过拥塞控制调节数据包流量的正确粒度。在同一会话中使用多个信道的一个基本原理是，存在可大规模扩展的拥塞控制协议，每个会话使用多个信道。这些拥塞控制协议被认为是分层的，因为接收器在其参与会话期间以分层顺序加入和离开信道。
The use of layered channels is also useful for streaming applications.
分层通道的使用对于流应用程序也很有用。
There are coding techniques that provide massively scalable reliability and asynchronous delivery that 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 to which session each received packet belongs. 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 the session to which they belong. As another example, there are optional fields within the LCT packet header for identifying the object about which information is carried in the packet payload.
除了支持拥塞控制之外，LCT还提供了许多字段，并支持许多协议通常需要的功能。例如，LCT提供传输会话ID，该ID可用于标识每个接收到的分组所属的会话。这一点很重要，因为一个接收器可以同时加入多个会话，因此能够在数据包到达时根据它们所属的会话对其进行解复用是非常有用的。作为另一个示例，在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
LCT会话由一组逻辑分组的LCT通道组成，这些通道与单个发送方关联，该发送方承载一个或多个对象的带有LCT头的数据包。LCT信道由发送方和发送方与信道关联的地址的组合定义。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 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 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.
LCT意味着与其他构建块相结合，从而产生的整体协议具有大规模可扩展性。可伸缩性是指协议的行为与接收器和网络路径的数量、它们的异构性以及动态适应可变接收器集的能力有关。可伸缩性限制可能来自内存或处理需求，也可能来自协议生成的反馈控制量和冗余数据包流量。反过来，这种限制可能是一个完整可靠的内容交付或流交付协议预期提供的特性的结果。
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 for which object the packet contains data and flags are included for indicating the close of the session and the close of sending packets for an object. Header extensions can carry additional fields that, for example, can be used for packet authentication or to convey various kinds of timing information: 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 or transmission object will be continued for, and Session Last Change (SLC) conveys the time when objects have been added, modified, or removed from the session.
LCT报头提供了许多字段，用于将带内会话信息传送给接收机。所需字段之一是传输会话ID（TSI），它允许会话的接收器唯一地识别作为会话一部分的接收到的分组。另一个必填字段是拥塞控制信息（CCI），它允许接收方对会话中接收的数据包执行所需的拥塞控制。其他LCT字段为会话提供可选但通常非常有用的附加信息。例如，传输对象标识符（TOI）标识分组包含数据的对象，并且包括用于指示会话结束和对象发送分组结束的标志。报头扩展可以携带附加字段，例如，这些字段可用于数据包身份验证或传送各种定时信息：发送方当前时间（SCT）传送数据包从发送方发送到接收方的时间、预期剩余时间（ERT）传递会话或传输对象将持续的时间量，会话上次更改（SLC）传递对象已添加、修改或从会话中移除的时间。
LCT provides support for congestion control. Congestion control MUST be used that conforms to [RFC2357] 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会话，接收方和发送方之间必须使用符合[RFC2357]的拥塞控制。拥塞控制指的是使吞吐量适应从发送方到接收方的路径上的可用带宽，并与竞争流（如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
LCT可以使用多速率或单速率拥塞控制协议。对于多速率协议，一个会话通常由多个通道组成，发送方将数据包发送给
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.
会话中的信道速率不依赖于接收机。每个接收机在其参与会话期间通过动态地加入和离开信道来调整其接收速率，这取决于发送端的可用带宽，而不依赖于所有其他接收机。因此，对于多速率协议，每个接收机的接收速率可以独立于其他接收机动态地变化。
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. Use of the multiple rate congestion control scheme defined in [RFC3738] is RECOMMENDED. Alternative multiple rate congestion control protocols are described in [VIC1998] and [BYE2000]. A possible single rate congestion control protocol is described in [RIZ2000].
通常，在异构接收机环境中，多速率协议比单速率协议更可取，因为通常多速率协议更容易实现对多个接收机的可伸缩性，并为每个接收机提供更高的吞吐量。建议使用[RFC3738]中定义的多速率拥塞控制方案。[VIC1998]和[BYE2000]中描述了替代的多速率拥塞控制协议。[2000]中描述了一种可能的单速率拥塞控制协议。
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 [RIZ1997a], [RIZ1997b], [GEM2000], [VIC1998], and [BYE1998]. 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 from which a receiver is receiving, the receiver can reduce
当使用前向纠错（FEC）技术对数据流进行编码时，分层编码的概念可以自然地扩展到可靠的内容交付协议。有关这方面的说明，请参见[RIZ1997a]、[RIZ1997b]、[GEM2000]、[VIC1998]和[BYE1998]。通过使用FEC，以这样的方式变换数据流，使得数据对象的重构不依赖于特定数据分组的接收，而仅依赖于接收的不同分组的数目。结果，通过增加接收器接收的层的数量，接收器可以减少
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 [RFC3453].
相应的传输时间。与提供可靠性的其他方法相比，使用FEC提供可靠性可以显著提高可伸缩性。有关使用FEC进行可靠内容交付的更多详细信息，请参见[RFC3453]。
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 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.
使用IP多播扩展可靠内容交付的两个关键困难是处理从接收者流回发送者的数据量和来自发送者的相关响应（通常是数据重传）。避免任何此类反馈并最小化重传量的协议可以大规模扩展。LCT可与FEC代码或分层编解码器结合使用，以实现可靠性，而无需反馈或很少反馈。
Protocol instantiations (PIs) 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 [RFC2357]. A complete protocol instantiation that uses LCT MAY include a scalable reliability protocol that is compatible with LCT, it MAY include a session control protocol that is compatible with LCT, and it MAY include other protocols such as security protocols.
协议实例化（PI）可以通过将LCT框架与其他组件相结合来构建。使用LCT的完整协议实例化必须包括与LCT兼容且符合[RFC2357]的拥塞控制协议。使用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
例如，LCT会话可用于使用三个LCT频道传送电视节目。从第一个LCT信道接收数据包可以允许黑白接收。接收第一个
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通道也可以允许彩色接收。接收所有三个频道可实现高清晰度电视质量接收。本例中的对象可能对应于正在传输的单个电视节目。
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 includes 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 [RFC5052] could be used.
编码器可用于生成放置在分组有效载荷中的数据以提供可靠性。使用合适的解码器从分组有效载荷再现原始信息。如果使用这样的编码器和解码器，则在LCT报头之后可能存在可靠性报头。可靠性报头有助于描述包的有效载荷中携带的编码数据。可靠性报头的格式取决于所使用的编码，这是在带外协商的。例如，可以使用[RFC5052]中描述的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 that 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 [VIC1998], [BYE2000], and [RFC3738]. Other congestion controls may be suitable when LCT is used for a streaming application.
对于LCT，当使用多速率拥塞控制时，通过将与给定会话相关联的数据包发送到多个LCT信道来实现拥塞控制。根据接收机看到的网络拥塞情况，单个接收机动态地加入一个或多个这些信道。LCT报头包括一个不透明字段，必须使用该字段将拥塞控制信息传递给接收方。与LCT一起使用的实际拥塞控制方案是在带外协商的。[VIC1998]、[BYE2000]和[RFC3738]中描述了可能适用于内容交付的拥塞控制协议的一些示例。当LCT用于流应用程序时，其他拥塞控制可能适用。
This document does not specify and restrict the type of exchanges between LCT (or any protocol instantiation 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 protocol instantiation 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之上的任何协议实例化）与上层应用程序之间的交换类型。一些上层API可以使用面向对象的方法，其中LCT（或构建在LCT之上的任何协议实例化）和应用程序（无论是在源还是在接收器）之间交换的唯一可能的数据单元是对象。其他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 it 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 [RFC0768], 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必须唯一标识会话。如[RFC0768]所述，如果底层传输为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 that does not have any support for flow or congestion control. For example, the Any-Source Multicast (ASM) model of IP multicast as defined in [RFC1112]
LCT被假定与底层网络或传输服务一起使用，该服务是“尽力而为”的服务，不保证数据包接收或数据包接收顺序，并且不支持流量或拥塞控制。例如，[RFC1112]中定义的IP多播的任意源多播（ASM）模型
is such a "best effort" network service. While the basic service provided by [RFC1112] is largely scalable, providing congestion control or reliability should be done carefully to avoid severe scalability limitations, especially in the presence of heterogeneous sets of receivers.
就是这样一种“尽力而为”的网络服务。虽然[RFC1112]提供的基本服务在很大程度上是可伸缩的，但应谨慎地提供拥塞控制或可靠性，以避免严重的可伸缩性限制，尤其是在存在异构接收机集的情况下。
There are currently two models of multicast delivery, the Any-Source Multicast (ASM) model as defined in [RFC1112] and the Source-Specific Multicast (SSM) model as defined in [RFC4607]. 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.
目前有两种多播交付模型，[RFC1112]中定义的任意源多播（ASM）模型和[RFC4607]中定义的源特定多播（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 (DoS) attacks. In either case, receivers SHOULD use packet authentication mechanisms to mitigate such attacks (see Sections 6.2 and 7).
LCT信道和SSM信道重合，因此接收机将只接收发送到请求的LCT信道的数据包。使用ASM，接收器通过加入多播组G来加入LCT信道，并且发送到G的所有数据包，无论发送者是谁，都可以由接收器接收。因此，与ASM相比，SSM在防止拒绝服务（DoS）攻击方面具有引人注目的安全优势。在任何一种情况下，接收方都应使用数据包身份验证机制来缓解此类攻击（见第6.2和7节）。
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 is compatible with both IPv4 and IPv6 as no part of the packet is IP version specific.
LCT与IPv4和IPv6兼容，因为数据包的任何部分都不是特定于IP版本的。
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信道组成。
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 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.
例如，可以使用推送服务模型来可靠地传递大型对象，例如100GB文件。发送方可以向控制通道发送会话描述公告，接收方可以监视该通道，并在感兴趣的会话描述到达时加入会话。在接收到会话描述后，每个接收器都可以加入会话以接收数据包，直到有足够的数据包到达以重构对象，此时接收器可以向发送者报告其接收已成功完成。发送方可以决定继续向会话发送对象的数据包，直到所有接收方都报告成功重建，或者直到满足某些其他条件。
There are several features Asynchronous Layered Coding (ALC) provides to support the push model. For example, the sender can optionally include an Expected Residual Time (ERT) in the packet header extension 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 stop sending packets to the session and a Close Object flag that indicates when the sender is about to stop sending packets to the session for the object identified by the Transmission Object ID. However, these
异步分层编码（ALC）提供了几个特性来支持推送模型。例如，发送方可以可选地在分组报头扩展中包括预期剩余时间（ERT），该预期剩余时间指示会话中携带的单个对象或由传输对象标识符（TOI）标识的对象的分组传输的预期剩余时间如果会话中携带了多个对象。接收者可以使用它来确定会话中是否有足够的剩余时间来成功接收足够的附加数据包以恢复对象。例如，如果没有足够的时间，则推送应用可使接收器向发送器报告，以将对象的分组的传输延长足够的时间，以允许接收器获得足够的分组来重构对象。然后，发送方可以基于对象的每个后续分组报头中的扩展对象传输时间包括ERT。作为其他示例，LCT报头可选地可以包含指示发送方何时将要停止向会话发送分组的关闭会话标志和指示发送方何时将要停止向由传输对象ID标识的对象的会话发送分组的关闭对象标志。然而，这些
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.
标志不是一种完全可靠的机制，因此关闭会话标志应仅用作会话即将关闭的提示，而关闭对象标志应仅用作对象数据包传输即将结束的提示。
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. 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.
对于按需内容交付服务模型，发送方通常在指定的时间段内进行传输，该时间段被选择为足够长，以允许所有预期接收方加入会话并恢复对象。例如，一个流行的软件更新可能使用LCT传输几天，即使接收器可能能够在连接时间的一个小时内完成下载，可能在几个时间间隔内完成。在这种情况下，接收器在会话处于活动状态时的任何时间点加入会话。接收方在收到足够的数据包以恢复对象时离开会话。例如，接收者通过联系web服务器获得会话描述。
In this case, the receivers join the session, and dynamically adapt the number of LCT channels to which they subscribe 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 for which LCT can be used 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
还有许多其他交付服务模式可以使用LCT，但上面没有介绍。例如，实时流媒体或按需存档内容流媒体服务模型。对许多潜在应用、适当的交付服务模型以及与LCT结合时支持此类功能的附加机制的描述超出了本文的范围
this document. This document only attempts to describe the minimal common scalable elements to these diverse applications using LCT as the delivery transport.
这份文件。本文档仅试图描述使用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会话的特定拥塞控制协议取决于要交付的内容类型。虽然拥塞控制协议的一般行为是在出现拥塞时降低吞吐量，并在没有拥塞时逐渐增加吞吐量，但实际的动态行为（例如，对单个丢失的响应）可能会有所不同。
It is RECOMMENDED that the congestion control mechanism specified in [RFC3738] be used. Some alternative possible congestion control protocols for reliable content delivery using LCT are described in [VIC1998] and [BYE2000]. Different delivery service models might require different congestion control protocols.
建议使用[RFC3738]中规定的拥塞控制机制。[VIC1998]和[BYE2000]中描述了使用LCT进行可靠内容交付的一些替代可能的拥塞控制协议。不同的交付服务模型可能需要不同的拥塞控制协议。
Packets sent to an LCT session MUST include an "LCT header". The LCT header format is described below.
发送到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 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 in this version of the specification. Unless otherwise noted, numeric constants in this specification are in decimal form (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 |PSI|S| O |H|Res|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) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |PSI|S| O |H|Res|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) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
默认LCT标头中每个字段的功能和长度如下所示。
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位。
Protocol-Specific Indication (PSI): 2 bits
协议特定指示（PSI）：2位
The usage of these bits, if any, is specific to each protocol instantiation that uses the LCT building block. If no protocol-instantiation-specific usage of these bits is defined, then a sender MUST set them to zero and a receiver MUST ignore these bits.
这些位的使用（如果有）特定于使用LCT构建块的每个协议实例化。如果未定义这些位的特定协议实例化用法，则发送方必须将其设置为零，接收方必须忽略这些位。
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位的倍数。
Reserved (Res): 2 bits
保留（Res）：2位
These bits are reserved. In this version of the specification, they MUST be set to zero by senders and MUST be ignored by receivers.
这些位是保留的。在此版本的规范中，发送方必须将它们设置为零，接收方必须忽略它们。
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的数据包时，接收器应假定不再向会话发送数据包。
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
通常，B设置为0。当对象的分组的传输即将终止时，发送方可以将B设置为1。如果TOI字段正在使用且B设置为1，则会终止TOI字段标识的对象的传输
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 that packets are 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.
迫在眉睫的如果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 that 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 [RFC3550].
一种不透明的标识符，传递给包有效载荷解码器，以传递有关用于包有效载荷的编解码器的信息。代码点和实际编解码器之间的映射在每个会话的基础上定义，并作为会话描述信息的一部分在带外进行通信。CP字段的使用类似于[RFC3550]中所述的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.
如果C=0，此字段必须为32位。
This field MUST be 64 bits if C=1.
如果C=1，此字段必须为64位。
This field MUST be 96 bits if C=2.
如果C=2，此字段必须为96位。
This field MUST be 128 bits if C=3.
如果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 to which receivers are subscribed. 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 to which object within the session this packet pertains. 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
此字段指示此数据包属于会话中的哪个对象。例如，发送方可能在同一会话中发送多个文件，第一个文件使用TOI=0，第二个文件使用TOI=1，等等。另一个例子是，TOI可能是同时从多个发送方发送的对象的唯一全局标识符，并且TOI值可以是应用于对象的散列函数的输出。TOI字段值到对象的映射不在本文档的范围内，应在带外完成。TOI字段必须用于所有类型
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字段存在于会话的所有数据包中或从不存在，则为数据包。
The length of the TOI field is 32*O + 16*H bits. Note that the aggregate length of the TSI field plus the TOI field is a multiple of 32 bits.
TOI字段的长度为32*O+16*H位。请注意，TSI字段加上TOI字段的总长度是32位的倍数。
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 发送方和接收方身份验证信息。
o Transmission of timing 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版本号，则无法引入不向后兼容的标头扩展。
There are two formats for Header Extension fields, as depicted in Figure 2. 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.
标题扩展字段有两种格式，如图2所示。第一种格式用于可变长度扩展，标题扩展类型（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 (HETs between 0 and 127) and MUST NOT be present for fixed-length extensions (HETs 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位字。
The following LCT Header Extensions are defined by this specification:
本规范定义了以下LCT标头扩展：
EXT_NOP, HET=0 No-Operation extension. The information present in this extension field MUST be ignored by receivers.
EXT_NOP，HET=0无操作扩展。接收器必须忽略此扩展字段中的信息。
EXT_AUTH, HET=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，HET=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.
建议发送方提供某种形式的数据包身份验证。如果存在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 SHOULD NOT be postponed by any such full packet authentication.
一些分组认证方案在接收分组和分组完全认证之间施加几秒钟的延迟。任何与拥塞控制相关的适当操作都不应因任何此类完整数据包身份验证而延迟。
EXT_TIME, HET=2 Time Extension. This extension is used to carry several types of timing information. It includes general purpose timing information, namely the Sender Current Time (SCT), Expected Residual Time (ERT), and Sender Last Change (SLC) time extensions described in the present document. It can also be used for timing information with narrower applicability (e.g., defined for a single protocol instantiation); in this case, it will be described in a separate document.
扩展时间，HET=2次扩展。此扩展用于承载多种类型的定时信息。它包括通用定时信息，即本文档中描述的发送方当前时间（SCT）、预期剩余时间（ERT）和发送方上次更改（SLC）时间扩展。它还可用于适用范围较窄的定时信息（例如，为单个协议实例化定义）；在这种情况下，将在单独的文件中描述。
All senders and receivers implementing LCT MUST support the EXT_NOP Header Extension and MUST recognize EXT_AUTH and EXT_TIME, but are not required to be able to parse their content.
所有实现LCT的发送方和接收方必须支持EXT_NOP头扩展，并且必须识别EXT_AUTH和EXT_TIME，但不要求能够解析其内容。
This section defines the timing Header Extensions with general applicability. The time values carried in this Header Extension are related to the server's wall clock. The server MUST maintain consistent relative time during a session (i.e., insignificant clock drift). For some applications, system or even global synchronization of server wall clock may be desirable, such as using the Network Time
本节定义了具有一般适用性的定时标头扩展。此标头扩展中包含的时间值与服务器的挂钟相关。服务器必须在会话期间保持一致的相对时间（即，不显著的时钟漂移）。对于某些应用，可能需要系统或甚至服务器挂钟的全局同步，例如使用网络时间
Protocol (NTP) [RFC1305] to ensure actual time relative to 00:00 hours GMT, January 1st 1900. Such session-external synchronization is outside the scope of this document.
协议（NTP）[RFC1305]确保相对于1900年1月1日格林尼治标准时间00:00的实际时间。此类会话外部同步不在本文档的范围内。
The EXT_TIME Header Extension uses the format depicted in Figure 3.
EXT_时间头扩展使用图3所示的格式。
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 = 2 | HEL >= 1 | Use (bit field) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| first time value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... (other time values (optional) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 2 | HEL >= 1 | Use (bit field) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| first time value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... (other time values (optional) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: EXT_TIME Header Extension Format
图3:EXT_时间头扩展格式
The "Use" bit field indicates the semantic of the following 32-bit time value(s).
“使用”位字段表示以下32位时间值的语义。
It is divided into two parts:
它分为两部分：
o 8 bits are reserved for general purpose timing information. This information is applicable to any protocol that makes use of LCT.
o 为通用定时信息保留8位。此信息适用于使用LCT的任何协议。
o 8 bits are reserved for PI-specific timing information. This information is out of the scope of this document.
o 为PI特定定时信息保留8位。此信息不在本文档的范围内。
The format of the "Use" bit field is depicted in Figure 4.
“使用”位字段的格式如图4所示。
2 3
6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|SCT|SCT|ERT|SLC| reserved | PI-specific |
|Hi |Low| | | by LCT | use |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2 3
6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|SCT|SCT|ERT|SLC| reserved | PI-specific |
|Hi |Low| | | by LCT | use |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 4: "Use" Bit Field Format
图4：“使用”位字段格式
Several "time value" fields MAY be present in a given EXT_TIME Header Extension, as specified in the "Use-field". When several "time value" fields are present, they MUST appear in the order specified by the associated flag position in the "Use-field": first SCT-High (if
如“使用字段”中所述，给定的EXT_time标头扩展中可能存在多个“time value”字段。当存在多个“时间值”字段时，它们必须按照“使用字段”中相关标志位置指定的顺序出现：第一个SCT高（如果有
present), then SCT-Low (if present), then ERT (if present), then SLC (if present). Receivers SHOULD ignore additional fields within the EXT_TIME Header Extension that they do not support.
存在），然后是SCT低（如果存在），然后是ERT（如果存在），然后是SLC（如果存在）。接收方应忽略其不支持的EXT_TIME标头扩展中的其他字段。
The fields for the general purpose EXT_TIME timing information are:
通用EXT_时间定时信息的字段包括：
Sender Current Time (SCT): SCT-High flag, SCT-Low flag, corresponding time value (one or two 32-bit words).
发送方当前时间（SCT）：SCT高标志、SCT低标志、相应的时间值（一个或两个32位字）。
This timing information represents the current time at the sender at the time this packet was transmitted.
此定时信息表示发送此数据包时发送方的当前时间。
When the SCT-High flag is set, the associated 32-bit time value provides an unsigned integer representing the time in seconds of the sender's wall clock. In the particular case where NTP is used, these 32 bits provide an unsigned integer representing the time in seconds relative to 00:00 hours GMT, January 1st 1900, (i.e., the most significant 32 bits of a full 64-bit NTP time value). In that case, handling of wraparound of the 32-bit time is outside the scope of NTP and LCT.
设置SCT High标志时，关联的32位时间值提供一个无符号整数，表示发送方挂钟的时间（以秒为单位）。在使用NTP的特定情况下，这32位提供了一个无符号整数，表示相对于1900年1月1日格林尼治标准时间00:00小时的时间（即，完整64位NTP时间值的最高有效32位）。在这种情况下，32位时间的环绕处理超出了NTP和LCT的范围。
When the SCT-Low flag is set, the associated 32-bit time value provides an unsigned integer representing a multiple of 1/2^^32 of a second, in order to allow sub-second precision. When the SCT-Low flag is set, the SCT-High flag MUST be set, too. In the particular case where NTP is used, these 32 bits provide the 32 least significant bits of a 64-bit NTP timestamp.
设置SCT Low标志时，关联的32位时间值提供一个无符号整数，表示1/2^^32秒的倍数，以允许亚秒精度。设置SCT Low标志时，也必须设置SCT High标志。在使用NTP的特定情况下，这32位提供64位NTP时间戳的32个最低有效位。
Expected Residual Time (ERT): ERT flag, corresponding 32-bit time value.
预期剩余时间（ERT）：ERT标志，对应的32位时间值。
This timing information represents the sender expected residual transmission time for the transmission of the current object. If the packet containing the ERT timing information also contains the TOI field, then ERT refers to the object corresponding to the TOI field; otherwise, it refers to the only object in the session.
该定时信息表示当前对象的传输的发送方预期剩余传输时间。如果包含ERT定时信息的分组还包含TOI字段，则ERT指与TOI字段相对应的对象；否则，它将引用会话中的唯一对象。
When the ERT flag is set, it is expressed as a number of seconds. The 32 bits provide an unsigned integer representing this number of seconds.
设置ERT标志时，它表示为秒数。32位提供了一个表示秒数的无符号整数。
Session Last Changed (SLC): SLC flag, corresponding 32-bit time value.
上次更改会话（SLC）：SLC标志，对应32位时间值。
The Session Last Changed time value is the server wall clock time, in seconds, at which the last change to session data occurred. That is, it expresses the time at which the last (most recent)
Session Last Changed time（会话上次更改时间）值是发生会话数据上次更改的服务器挂钟时间（以秒为单位）。也就是说，它表示最后一次（最近一次）的时间
Transport Object addition, modification, or removal was made for the delivery session. In the case of modifications and additions, it indicates that new data will be transported that was not transported prior to this time. In the case of removals, SLC indicates that some prior data will no longer be transported.
已为传递会话添加、修改或删除传输对象。在修改和添加的情况下，它表示将传输在此时间之前未传输的新数据。在删除的情况下，SLC表示一些以前的数据将不再传输。
When the SLC flag is set, the associated 32-bit time value provides an unsigned integer representing a time in seconds. In the particular case where NTP is used, these 32 bits provide an unsigned integer representing the time in seconds relative to 00:00 hours GMT, January 1st 1900, (i.e., the most significant 32 bits of a full 64-bit NTP time value). In that case, handling of wraparound of the 32-bit time is outside the scope of NTP and LCT.
设置SLC标志时，关联的32位时间值提供一个无符号整数，表示以秒为单位的时间。在使用NTP的特定情况下，这32位提供了一个无符号整数，表示相对于1900年1月1日格林尼治标准时间00:00小时的时间（即，完整64位NTP时间值的最高有效32位）。在这种情况下，32位时间的环绕处理超出了NTP和LCT的范围。
In some cases, it may be appropriate that a packet containing an EXT_TIME Header Extension with SLC information also contain an SCT-High information.
在某些情况下，包含具有SLC信息的EXT_时间报头扩展的分组也包含SCT高信息可能是合适的。
Reserved by LCT for future use (4 bits):
由LCT保留供将来使用（4位）：
In this version of the specification, these bits MUST be set to zero by senders and MUST be ignored by receivers.
在此版本的规范中，发送方必须将这些位设置为零，接收方必须忽略这些位。
PI-specific use (8 bits):
PI特定用途（8位）：
These bits are out of the scope of this document. The bits that are not specified by the PI built on top of LCT SHOULD be set to zero.
这些位不在本文档的范围内。构建在LCT之上的PI未指定的位应设置为零。
The total EXT_TIME length is carried in the HEL, since this Header Extension is of variable length. It also enables clients to skip this Header Extension altogether if not supported (but recognized).
HEL中携带了EXT_总时间长度，因为此标头扩展具有可变长度。如果不支持（但可识别），它还允许客户端完全跳过此标头扩展。
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 one 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 be included in the session description.
使用LCT的协议实例化可能会对会话描述中必须包含的内容提出额外要求。例如，协议实例化可能要求在会话描述中包括每个通道的数据速率、TOI值到会话对象的映射，或与可能需要的其他头相关的其他信息。
The session description could be in a form such as SDP as defined in [RFC4566], or another format appropriate to a particular application. It might be carried in a session announcement protocol such as SAP as defined in [RFC2974], obtained using a proprietary session control protocol, located on a Web page with scheduling information, or conveyed via email or other out-of-band methods. Discussion of session description format, and distribution of session descriptions is beyond the scope of this document.
会话描述可以是[RFC4566]中定义的SDP格式，也可以是适合特定应用程序的其他格式。它可以在会话公告协议（如[RFC2974]中定义的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 in which they have no interest.
在同一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 [VIC1998], [BYE2000], and [RFC3738]. A sender of packets using LCT MUST implement the sender-side part of one of the congestion control schemes that is in accordance with [RFC2357] 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.
建议所有数据包具有相同或非常相似的大小，因为这可能会严重影响拥塞控制方案的有效性，如[VIC1998]、[BYE2000]和[RFC3738]中所述的拥塞控制方案。使用LCT的数据包发送方必须使用LCT报头中提供的拥塞控制信息字段，实现符合[RFC2357]的拥塞控制方案之一的发送方部分，相应的接收机拥塞控制方案将在带外通信，并且必须由参与会话的任何接收机实现。
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 an 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 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报头中提供的拥塞控制信息字段实现会话描述中指定的拥塞控制协议。如果接收器无法实现会话中使用的拥塞控制协议，则它不得加入会话。当会话在多个LCT信道上传输时，接收机必须首先根据拥塞控制协议的指定启动行为加入信道。对于使用多个信道的多速率拥塞控制协议，这通常意味着接收器最初将仅加入最小的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 [RFC3048], 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
如[RFC3048]所述，LCT是一个构建块，旨在与其他构建块一起使用，以帮助指定协议实例化。一种拥塞控制构建块，使用
LCT header MUST be used by any protocol instantiation that uses LCT; other building blocks MAY also be used, such as a reliability building block.
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. 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信道承载的流量的总和。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 [RFC3453]. Some of the FEC codecs that MAY be used in conjunction with LCT for reliable content delivery are specified in [RFC5052]. 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.
[RFC3453]对FEC在可靠多播传输（RMT）协议中的使用进行了更深入的描述。[RFC5052]中规定了一些可与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 [RFC4566], or another format appropriate to a particular application and may be distributed with SAP as defined in [RFC2974], using HTTP, or in other ways. It is RECOMMENDED that an authentication protocol be used to deliver the session description to receivers to ensure the correct session description arrives.
LCT还要求接收机获得会话描述，如第6.1节所述。会话描述可以是[RFC4566]中定义的SDP格式，也可以是适合特定应用程序的另一种格式，并且可以使用HTTP或其他方式与[RFC2974]中定义的SAP一起分发。建议使用身份验证协议将会话描述传递给接收方，以确保正确的会话描述到达。
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 [Perrig2001].
建议LCT实现人员使用一些数据包身份验证方案来保护协议免受攻击。[Perrig2001]中描述了可能合适的方案的示例。
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 is a building block as defined in [RFC3048] and as such does not define a complete protocol. Protocol instantiations that use the LCT building block MUST address the potential vulnerabilities described in the following sections. For an example, see [ALC-PI].
LCT是[RFC3048]中定义的构建块，因此未定义完整的协议。使用LCT构建块的协议实例化必须解决以下部分中描述的潜在漏洞。有关示例，请参见[ALC-PI]。
Protocol instantiations could address the vulnerabilities described below by taking measures to prevent receivers from accepting incorrect packets, for example, by using a source authentication and content integrity mechanism. See also Sections 6.2 and 7 for discussion of packet authentication requirements.
协议实例化可以通过采取措施防止接收者接受不正确的数据包（例如，通过使用源身份验证和内容完整性机制）来解决下面描述的漏洞。有关数据包认证要求的讨论，请参见第6.2节和第7节。
Note that for correct operation, LCT assumes availability of session description information (see Sections 4 and 7). Incorrect or maliciously modified session description information may result in receivers being 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. Protocol instantiations MUST address this potential vulnerability, for example, by providing source authentication and integrity mechanisms for the session description. Additionally, these mechanisms MUST allow the receivers to securely verify the correspondence between session description and LCT data packets.
注意，对于正确的操作，LCT假设会话描述信息可用（参见第4节和第7节）。不正确或恶意修改的会话描述信息可能导致接收器无法正确接收会话内容，或者接收器无意中尝试以远高于其能力的速率接收会话内容，从而中断网络部分中的通信。协议实例化必须解决此潜在漏洞，例如，为会话描述提供源身份验证和完整性机制。此外，这些机制必须允许接收方安全地验证会话描述和LCT数据包之间的对应关系。
The following sections consider further each of the services provided by LCT.
下面的部分进一步考虑LCT提供的每一项服务。
The Transport Session Identifier and the Transport Object Identifier in the LCT header provide for multiplexing of sessions and objects. Modification of these fields by an attacker could have the effect of depriving a session or object of data and potentially directing incorrect data to another session or object, in both cases effecting a denial-of-service attack.
LCT报头中的传输会话标识符和传输对象标识符提供会话和对象的多路复用。攻击者修改这些字段可能会剥夺会话或对象的数据，并可能将不正确的数据定向到另一个会话或对象，在这两种情况下都会导致拒绝服务攻击。
Additionally, injection of forged packets with fake TSI or TOI values may cause receivers to allocate resources for additional sessions or objects, again potentially effecting a DoS attack.
此外，假冒TSI或TOI值的伪造数据包的注入可能会导致接收者为额外的会话或对象分配资源，再次可能影响DoS攻击。
The Close Object and Close Session bits in the LCT header provide for signaling of the end of a session or object. Modification of these fields by an attacker could cause receivers to incorrectly behave as if the session or object had ended, resulting in a denial-of-service attack, or conversely to continue to unnecessarily utilize resources after the session or object has ended (although resource utilization in this case is largely an implementation issue).
LCT报头中的Close Object（关闭对象）和Close Session（关闭会话）位提供会话或对象结束的信令。攻击者对这些字段的修改可能会导致接收方错误地表现为会话或对象已结束，从而导致拒绝服务攻击，或者相反，在会话或对象结束后继续不必要地利用资源（尽管在这种情况下，资源利用主要是一个实现问题）。
As a result of the above vulnerabilities, these fields MUST be protected by protocol instantiation security mechanisms (for example, source authentication and data integrity mechanisms).
由于存在上述漏洞，这些字段必须受到协议实例化安全机制（例如，源身份验证和数据完整性机制）的保护。
The SCT and ERT mechanisms provide rudimentary time synchronization features which can both be subject to attacks. Indeed an attacker can easily de-synchronize clients, sending erroneous SCT information, or mount a DoS attack by informing all clients that the session (respectively, a particular object) is about to be closed.
SCT和ERT机制提供了基本的时间同步功能，它们都可能受到攻击。实际上，攻击者可以通过通知所有客户端会话（分别是特定对象）即将关闭，从而轻松地解除客户端同步、发送错误的SCT信息或发起DoS攻击。
As a result of the above vulnerabilities, these fields MUST be protected by protocol instantiation security mechanisms (for example, source authentication and data integrity mechanisms).
由于存在上述漏洞，这些字段必须受到协议实例化安全机制（例如，源身份验证和数据完整性机制）的保护。
The LCT protocol provides for transport of information for other building blocks, specifically the PSI field for the protocol instantiation, the Congestion Control field for the Congestion Control building block, the Codepoint field for the FEC building block, the EXT-AUTH Header Extension (used by the protocol instantiation) and the packet payload itself.
LCT协议提供其他构建块的信息传输，特别是协议实例化的PSI字段、拥塞控制构建块的拥塞控制字段、FEC构建块的代码点字段、EXT-AUTH头扩展（由协议实例化使用）以及数据包负载本身。
Modification of any of these fields by an attacker may result in a denial-of-service attack. In particular, modification of the Codepoint or packet payload may prevent successful reconstruction or cause inaccurate reconstruction of large portions of an object by receivers. Modification of the Congestion Control field may cause receivers to attempt to receive at an incorrect rate, potentially worsening or causing a congestion situation and thereby effecting a DoS attack.
攻击者修改其中任何字段都可能导致拒绝服务攻击。具体地，对码点或分组有效载荷的修改可阻止接收机成功地重建或导致不准确地重建对象的大部分。修改拥塞控制字段可能会导致接收器尝试以错误的速率接收，可能会恶化或造成拥塞情况，从而影响DoS攻击。
As a result of the above vulnerabilities, these fields MUST be protected by protocol instantiation security mechanisms (for example, source authentication and data integrity mechanisms).
由于存在上述漏洞，这些字段必须受到协议实例化安全机制（例如，源身份验证和数据完整性机制）的保护。
This document defines a new namespace for "LCT Header Extension Types". Values in this namespace are integers between 0 and 255 (inclusive).
本文档为“LCT头扩展类型”定义了一个新名称空间。此命名空间中的值是介于0和255（包括0和255）之间的整数。
Values in the range 0 to 63 (inclusive) are reserved for use for variable-length LCT Header Extensions and assignments shall be made through "IETF Review" as defined in [RFC5226].
0至63（含）范围内的值保留用于可变长度LCT标头扩展，并应通过[RFC5226]中定义的“IETF审查”进行分配。
Values in the range 64 to 127 (inclusive) are reserved for variable-length LCT Header Extensions and assignments shall be made on the "Specification Required" basis as defined in [RFC5226].
64至127（含）范围内的值保留用于可变长度LCT标头扩展，并应根据[RFC5226]中定义的“所需规范”进行分配。
Values in the range 128 to 191 (inclusive) are reserved for use for fixed-length LCT Header Extensions and assignments shall be made through "IETF Review" as defined in [RFC5226].
128至191（含）范围内的值保留用于固定长度LCT标头扩展，并应通过[RFC5226]中定义的“IETF审查”进行分配。
Values in the range 192 to 255 (inclusive) are reserved for fixed-length LCT Header Extensions and assignments shall be made on the "Specification Required" basis as defined in [RFC5226].
192至255（含）范围内的值保留用于固定长度LCT标头扩展，并应根据[RFC5226]中定义的“所需规范”进行分配。
Initial values for the LCT Header Extension Type registry are defined in Section 9.2.
LCT标头扩展类型注册表的初始值在第9.2节中定义。
Note that the previous Experimental version of this specification reserved values in the ranges [64, 127] and [192, 255] for PI-specific LCT Header Extensions. In the interest of simplification and since there were no overlapping allocations of these LCT Header Extension Type values by PIs, this document specifies a single flat space for LCT Header Extension Types.
请注意，本规范的先前实验版本为特定于PI的LCT头扩展保留了[64127]和[192255]范围内的值。为了简化，并且由于PIs对这些LCT头扩展类型值的分配没有重叠，因此本文档为LCT头扩展类型指定了一个单一的平面空间。
This document registers three values in the LCT Header Extension Type namespace as follows:
本文档在LCT标头扩展类型命名空间中注册三个值，如下所示：
+-------+----------+--------------------+
| Value | Name | Reference |
+-------+----------+--------------------+
| 0 | EXT_NOP | This specification |
| | | |
| 1 | EXT_AUTH | This specification |
| | | |
| 2 | EXT_TIME | This specification |
+-------+----------+--------------------+
+-------+----------+--------------------+
| Value | Name | Reference |
+-------+----------+--------------------+
| 0 | EXT_NOP | This specification |
| | | |
| 1 | EXT_AUTH | This specification |
| | | |
| 2 | EXT_TIME | This specification |
+-------+----------+--------------------+
This specification is substantially based on RFC 3451 [RFC3451] and thus credit for the authorship of this document is primarily due to the authors of RFC 3451: Mike Luby, Jim Gemmel, Lorenzo Vicisano, Luigi Rizzo, Mark Handley, and Jon Crowcroft. Bruce Lueckenhoff,
本规范基本上基于RFC 3451[RFC3451]，因此本文件的作者资格主要归功于RFC 3451的作者：Mike Luby、Jim Gemmel、Lorenzo Vicisano、Luigi Rizzo、Mark Handley和Jon Crowft。布鲁斯·鲁肯霍夫，
Hayder Radha, and Justin Chapweske also contributed to RFC 3451. Additional thanks are due to Vincent Roca, Rod Walsh, and Toni Paila for contributions to this update to Proposed Standard.
Hayder Radha和Justin Chapweske也为RFC 3451捐款。还要感谢Vincent Roca、Rod Walsh和Toni Paila为本次标准更新做出的贡献。
This section summarizes the changes that were made from the Experimental version of this specification published as RFC 3451 [RFC3451]:
本节总结了从作为RFC 3451[RFC3451]发布的本规范实验版本所做的更改：
o Removed the 'Statement of Intent' from the introduction. (The statement of intent was meant to clarify the "Experimental" status of RFC 3451.)
o 从介绍中删除“意向声明”。（意向声明旨在澄清RFC 3451的“实验”状态。）
o Inclusion of material from ALC that is applicable in the more general LCT context.
o 包含适用于更一般LCT环境的ALC材料。
o Creation of an IANA registry for LCT Header Extensions.
o 为LCT头扩展创建IANA注册表。
o Allocation of the 2 'reserved' bits in the LCT header as "Protocol-Specific Indication" - usage to be defined by protocol instantiations.
o 将LCT头中的2个“保留”位分配为“协议特定指示”-使用由协议实例化定义。
o Removal of the Sender Current Time and Expected Residual Time LCT header fields.
o 删除发送方当前时间和预期剩余时间LCT标头字段。
o Inclusion of a new Header Extension, EXT_TIME, to replace the SCT and ERT and provide for future extension of timing capabilities.
o 包括一个新的报头扩展EXT_TIME，以取代SCT和ERT，并提供未来的定时功能扩展。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]Deering，S.，“IP多播的主机扩展”，STD 5，RFC11121989年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction (FEC) Building Block", RFC 5052, August 2007.
[RFC5052]Watson，M.，Luby，M.，和L.Vicisano，“前向纠错（FEC）构建块”，RFC 5052，2007年8月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[ALC-PI] Luby, M., Watson, M., and L. Vicisano, "Asynchronous Layered Coding (ALC) Protocol Instantiation", Work in Progress, September 2009.
[ALC-PI]Luby，M.，Watson，M.，和L.Vicisano，“异步分层编码（ALC）协议实例化”，正在进行的工作，2009年9月。
[BYE1998] Byers, J., Luby, M., Mitzenmacher, M., and A. Rege, "Fountain Approach to Reliable Distribution of Bulk Data", Proceedings ACM SIGCOMM'98, Vancouver, Canada, September 1998.
[BYE1998]Byers，J.，Luby，M.，Mitzenmacher，M.，和A.Rege，“批量数据可靠分布的喷泉方法”，ACM SIGCOMM'98会议记录，加拿大温哥华，1998年9月。
[BYE2000] Byers, J., Frumin, M., Horn, G., Luby, M., Mitzenmacher, M., Rotter, 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.
[BYE2000]Byers，J.，Frumin，M.，Horn，G.，Luby，M.，Mitzenmacher，M.，Rotter，A.，和W.Shaver，“FLID-DL：分层多播的拥塞控制”，第二届网络化群组通信国际研讨会论文集（NGC 2000），加利福尼亚州帕洛阿尔托，2000年11月。
[GEM2000] Gemmell, J., Schooler, E., and J. Gray, "Fcast Multicast File Distribution", IEEE Network, Vol. 14, No. 1, pp. 58-68, January 2000.
[Gemmell，J.，Schooler，E.，和J.Gray，“Fcast多播文件分发”，IEEE网络，第14卷，第1期，第58-68页，2000年1月。
[Perrig2001] Perrig, A., Canetti, R., Song, D., and J. Tyger, "Efficient and Secure Source Authentication for Multicast", Network and Distributed System Security Symposium, NDSS 2001, pp. 35-46, February 2001.
[Perrig2001]Perrig，A.，Canetti，R.，Song，D.，和J.Tyger，“多播的高效和安全源认证”，网络和分布式系统安全研讨会，NDSS 2001，第35-46页，2001年2月。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
[RFC1305]Mills，D.，“网络时间协议（版本3）规范，实施”，RFC1305，1992年3月。
[RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
[RFC2357]Mankin，A.，Romanov，A.，Bradner，S.，和V.Paxson，“IETF评估可靠多播传输和应用协议的标准”，RFC 2357，1998年6月。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974]Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，RFC 2974，2000年10月。
[RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S., and M. Luby, "Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer", RFC 3048, January 2001.
[RFC3048]Whetten，B.，Vicisano，L.，Kermode，R.，Handley，M.，Floyd，S.，和M.Luby，“一对多批量数据传输的可靠多播传输构建块”，RFC 3048，2001年1月。
[RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents", RFC 3269, April 2002.
[RFC3269]Kermode，R.和L.Vicisano，“可靠多播传输（RMT）构建块和协议实例化文档的作者指南”，RFC 3269，2002年4月。
[RFC3451] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M., and J. Crowcroft, "Layered Coding Transport (LCT) Building Block", RFC 3451, December 2002.
[RFC3451]Luby，M.，Gemmell，J.，Vicisano，L.，Rizzo，L.，Handley，M.，和J.Crowcroft，“分层编码传输（LCT）构建块”，RFC 34512002年12月。
[RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "The Use of Forward Error Correction (FEC) in Reliable Multicast", RFC 3453, December 2002.
[RFC3453]Luby，M.，Vicisano，L.，Gemmell，J.，Rizzo，L.，Handley，M.，和J.Crowcroft，“在可靠多播中使用前向纠错（FEC）”，RFC 3453，2002年12月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate Control (WEBRC) Building Block", RFC 3738, April 2004.
[RFC3738]Luby，M.和V.Goyal，“基于波动和方程的速率控制（WEBRC）构造块”，RFC 3738，2004年4月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607]Holbrook，H.和B.Cain，“IP的源特定多播”，RFC4607，2006年8月。
[RIZ1997a] Rizzo, L., "Effective Erasure Codes for Reliable Computer Communication Protocols", ACM SIGCOMM Computer Communication Review, Vol.27, No.2, pp.24-36, April 1997.
[Rizzo，L.，“可靠计算机通信协议的有效擦除码”，《ACM SIGCOMM计算机通信评论》，第27卷，第2期，第24-36页，1997年4月。
[RIZ1997b] Rizzo, L. and L. Vicisano, "Reliable Multicast Data Distribution protocol based on software FEC techniques", Proceedings of the Fourth IEEE Workshop on the Architecture and Implementation of High Performance Communication Systems, HPCS'97, Chalkidiki Greece, June 1997.
[Rizzo，L.和L.Vicisano，“基于软件FEC技术的可靠多播数据分发协议”，第四届IEEE高性能通信系统体系结构和实现研讨会论文集，HPCS'97，Chalkidiki希腊，1997年6月。
[RIZ2000] Rizzo, L., "PGMCC: A TCP-friendly single-rate multicast congestion control scheme", Proceedings of SIGCOMM 2000, Stockholm Sweden, August 2000.
[Rizzo 2000]Rizzo，L.，“PGMCC：一种TCP友好的单速率多播拥塞控制方案”，SIGCOMM 2000年论文集，瑞典斯德哥尔摩，2000年8月。
[VIC1998] Vicisano, L., Rizzo, L., and J. Crowcroft, "TCP-like Congestion Control for Layered Multicast Data Transfer", IEEE Infocom'98, San Francisco, CA, March 1998.
[VC88] ViSISANO，L.，RiZZO，L.和J. Crowcroft，“类似TCP拥塞控制的分层多播数据传输”，IEEE iFocom’98，旧金山，CA，1998年3月。
Authors' Addresses
作者地址
Michael Luby Qualcomm, Inc. 3165 Kifer Rd. Santa Clara, CA 95051 US
Michael Luby Qualcomm，Inc.美国加利福尼亚州圣克拉拉基弗路3165号，邮编95051
EMail: luby@qualcomm.com
EMail: luby@qualcomm.com
Mark Watson Qualcomm, Inc. 3165 Kifer Rd. Santa Clara, CA 95051 US
美国加利福尼亚州圣克拉拉基弗路3165号马克·沃森高通公司，邮编95051
EMail: watson@qualcomm.com
EMail: watson@qualcomm.com
Lorenzo Vicisano Qualcomm, Inc. 3165 Kifer Rd. Santa Clara, CA 95051 US
洛伦佐·维西萨诺高通公司，美国加利福尼亚州圣克拉拉基弗路3165号，邮编95051
EMail: vicisano@qualcomm.com
EMail: vicisano@qualcomm.com