Networking Working Group M. Ramadas
Request for Comments: 5326 ISTRAC, ISRO
Category: Experimental S. Burleigh
NASA/Jet Propulsion Laboratory
S. Farrell
Trinity College Dublin
September 2008
Networking Working Group M. Ramadas
Request for Comments: 5326 ISTRAC, ISRO
Category: Experimental S. Burleigh
NASA/Jet Propulsion Laboratory
S. Farrell
Trinity College Dublin
September 2008
Licklider Transmission Protocol - Specification
利克利德传输协议.规范
Status of This Memo
关于下段备忘
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
IESG Note
IESG注释
This RFC is not a candidate for any level of Internet Standard. It represents the consensus of the Delay Tolerant Networking (DTN) Research Group of the Internet Research Task Force (IRTF). It may be considered for standardization by the IETF in the future, but the IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. See RFC 3932 for more information.
本RFC不适用于任何级别的互联网标准。它代表了互联网研究任务组（IRTF）的延迟容忍网络（DTN）研究小组的共识。IETF将来可能会考虑将其标准化，但IETF不承认该RFC适用于任何目的，并特别指出，发布决定并非基于IETF对安全、拥塞控制或与已部署协议的不当交互等事项的审查。有关更多信息，请参阅RFC 3932。
Abstract
摘要
This document describes the Licklider Transmission Protocol (LTP), designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting "long-haul" reliable transmission in interplanetary space, but it has applications in other environments as well.
本文件描述了Licklider传输协议（LTP），该协议旨在通过具有超长消息往返时间（RTT）和/或频繁连接中断特征的链路提供基于重传的可靠性。由于跨行星际空间的通信是此类环境中最突出的例子，LTP的主要目标是支持行星际空间中的“长距离”可靠传输，但它在其他环境中也有应用。
This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised.
本文件是耐延迟网络研究小组的产品，该小组已对其进行了审查。没有人反对将其作为RFC出版。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Segment Structure ...............................................9
3.1. Segment Header ............................................10
3.1.1. Segment Type Flags .................................11
3.1.2. Segment Type Codes .................................13
3.1.3. Segment Class Masks ................................14
3.1.4. Extensions Field ...................................14
3.2. Segment Content ...........................................16
3.2.1. Data Segment (DS) ..................................16
3.2.2. Report Segment (RS) ................................17
3.2.3. Report Acknowledgment Segment ......................19
3.2.4. Session Management Segments ........................20
3.3. Segment Trailer ...........................................20
4. Requests from Client Service ...................................20
4.1. Transmission Request ......................................21
4.2. Cancellation Request ......................................22
5. Requirements from the Operating Environment ....................23
6. Internal Procedures ............................................24
6.1. Start Transmission ........................................25
6.2. Start Checkpoint Timer ....................................25
6.3. Start RS Timer ............................................25
6.4. Stop Transmission .........................................25
6.5. Suspend Timers ............................................26
6.6. Resume Timers .............................................26
6.7. Retransmit Checkpoint .....................................27
6.8. Retransmit RS .............................................27
6.9. Signify Red-Part Reception ................................28
6.10. Signify Green-Part Segment Arrival .......................28
6.11. Send Reception Report ....................................28
6.12. Signify Transmission Completion ..........................30
6.13. Retransmit Data ..........................................30
6.14. Stop RS Timer ............................................31
6.15. Start Cancel Timer .......................................32
6.16. Retransmit Cancellation Segment ..........................32
6.17. Acknowledge Cancellation .................................32
6.18. Stop Cancel Timer ........................................33
6.19. Cancel Session ...........................................33
6.20. Close Session ............................................33
6.21. Handle Miscolored Segment ................................33
6.22. Handling System Error Conditions .........................34
7. Notices to Client Service ......................................35
7.1. Session Start .............................................35
7.2. Green-Part Segment Arrival ................................36
7.3. Red-Part Reception ........................................36
7.4. Transmission-Session Completion ...........................36
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Segment Structure ...............................................9
3.1. Segment Header ............................................10
3.1.1. Segment Type Flags .................................11
3.1.2. Segment Type Codes .................................13
3.1.3. Segment Class Masks ................................14
3.1.4. Extensions Field ...................................14
3.2. Segment Content ...........................................16
3.2.1. Data Segment (DS) ..................................16
3.2.2. Report Segment (RS) ................................17
3.2.3. Report Acknowledgment Segment ......................19
3.2.4. Session Management Segments ........................20
3.3. Segment Trailer ...........................................20
4. Requests from Client Service ...................................20
4.1. Transmission Request ......................................21
4.2. Cancellation Request ......................................22
5. Requirements from the Operating Environment ....................23
6. Internal Procedures ............................................24
6.1. Start Transmission ........................................25
6.2. Start Checkpoint Timer ....................................25
6.3. Start RS Timer ............................................25
6.4. Stop Transmission .........................................25
6.5. Suspend Timers ............................................26
6.6. Resume Timers .............................................26
6.7. Retransmit Checkpoint .....................................27
6.8. Retransmit RS .............................................27
6.9. Signify Red-Part Reception ................................28
6.10. Signify Green-Part Segment Arrival .......................28
6.11. Send Reception Report ....................................28
6.12. Signify Transmission Completion ..........................30
6.13. Retransmit Data ..........................................30
6.14. Stop RS Timer ............................................31
6.15. Start Cancel Timer .......................................32
6.16. Retransmit Cancellation Segment ..........................32
6.17. Acknowledge Cancellation .................................32
6.18. Stop Cancel Timer ........................................33
6.19. Cancel Session ...........................................33
6.20. Close Session ............................................33
6.21. Handle Miscolored Segment ................................33
6.22. Handling System Error Conditions .........................34
7. Notices to Client Service ......................................35
7.1. Session Start .............................................35
7.2. Green-Part Segment Arrival ................................36
7.3. Red-Part Reception ........................................36
7.4. Transmission-Session Completion ...........................36
7.5. Transmission-Session Cancellation .........................37
7.6. Reception-Session Cancellation ............................37
7.7. Initial-Transmission Completion ...........................37
8. State Transition Diagrams ......................................38
8.1. Sender ....................................................39
8.2. Receiver ..................................................44
9. Security Considerations ........................................48
9.1. Denial of Service Considerations ..........................48
9.2. Replay Handling ...........................................49
9.3. Implementation Considerations .............................50
10. IANA Considerations ...........................................51
10.1. UDP Port Number for LTP ..................................51
10.2. LTP Extension Tag Registry ...............................51
11. Acknowledgments ...............................................51
12. References ....................................................52
12.1. Normative References .....................................52
12.2. Informative References ...................................52
7.5. Transmission-Session Cancellation .........................37
7.6. Reception-Session Cancellation ............................37
7.7. Initial-Transmission Completion ...........................37
8. State Transition Diagrams ......................................38
8.1. Sender ....................................................39
8.2. Receiver ..................................................44
9. Security Considerations ........................................48
9.1. Denial of Service Considerations ..........................48
9.2. Replay Handling ...........................................49
9.3. Implementation Considerations .............................50
10. IANA Considerations ...........................................51
10.1. UDP Port Number for LTP ..................................51
10.2. LTP Extension Tag Registry ...............................51
11. Acknowledgments ...............................................51
12. References ....................................................52
12.1. Normative References .....................................52
12.2. Informative References ...................................52
This document serves as the main protocol specification of LTP and is part of a series of documents describing LTP. Other documents in this series include the motivation document [LTPMTV] and the protocol extensions document [LTPEXT]. We strongly recommend reading the protocol motivation document before reading this document, to establish sufficient background and motivation for the specification.
本文件作为LTP的主要协议规范，是描述LTP的一系列文件的一部分。本系列中的其他文档包括动机文档[LTPMTV]和协议扩展文档[LTPEXT]。我们强烈建议在阅读本文件之前阅读协议动机文件，为规范建立足够的背景和动机。
LTP does Automatic Repeat reQuest (ARQ) of data transmissions by soliciting selective-acknowledgment reception reports. It is stateful, and has no negotiation or handshakes.
LTP通过请求选择性确认接收报告来执行数据传输的自动重复请求（ARQ）。它是有状态的，没有协商或握手。
In an Interplanetary Internet setting deploying the Bundle Protocol that is being developed by the Delay Tolerant Networking Research Group, LTP is intended to serve as a reliable "convergence layer" protocol operating in pairwise fashion between adjacent Interplanetary Internet nodes that are in direct radio frequency (RF) communication. In that operational scenario, and potentially in some other deployments of the Bundle Protocol, LTP runs directly over a data-link layer protocol; when this is the case, forward error correction coding and/or checksum mechanisms in the underlying data-link layer protocol must ensure the integrity of the data passed between the communicating entities.
在部署延迟容忍网络研究小组正在开发的捆绑协议的星际互联网环境中，LTP旨在作为一个可靠的“汇聚层”协议，在处于直接射频（RF）通信中的相邻星际互联网节点之间以成对方式运行。在该操作场景中，以及在捆绑协议的某些其他部署中，LTP直接在数据链路层协议上运行；在这种情况下，底层数据链路层协议中的前向纠错编码和/或校验和机制必须确保通信实体之间传递的数据的完整性。
Since no mechanisms for flow control or congestion control are included in the design of LTP, this protocol is not intended or appropriate for ubiquitous deployment in the global Internet.
由于LTP的设计中没有流量控制或拥塞控制机制，因此该协议不适用于全球互联网中的普遍部署。
When LTP is run over UDP, it must only be used for software development or in private local area networks. When LTP is not run over UDP, it must be run directly over a protocol (nominally a link-layer protocol) that meets the requirements specified in Section 5.
当LTP通过UDP运行时，它只能用于软件开发或专用局域网。当LTP不是通过UDP运行时，它必须直接通过满足第5节规定要求的协议（名义上是链路层协议）运行。
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 [B97].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[B97]中所述进行解释。
(1) Engine ID
(1) 发动机ID
A number that uniquely identifies a given LTP engine, within some closed set of communicating LTP engines. Note that when LTP is operating underneath the Delay-Tolerant Networking (DTN) [DTN] Bundle Protocol [BP], the convergence layer adapter mediating the two will be responsible for translating between DTN endpoint IDs and LTP engine IDs in an implementation-specific manner.
在一组封闭的通信LTP引擎中唯一标识给定LTP引擎的数字。请注意，当LTP在延迟容忍网络（DTN）[DTN]捆绑协议[BP]下运行时，调解两者的汇聚层适配器将负责以特定于实现的方式在DTN端点ID和LTP引擎ID之间进行转换。
(2) Block
(2) 块
An array of contiguous octets of application data handed down by the upper layer protocol (typically Bundle Protocol) to be transmitted from one LTP client service instance to another.
由上层协议（通常是捆绑协议）传递的应用程序数据的连续八位字节数组，从一个LTP客户机服务实例传输到另一个实例。
Any subset of a block comprising contiguous octets beginning at the start of the block is termed a "block prefix", and any such subset of the block ending with the end of the block is termed a "block suffix".
包含从块的开头开始的连续八位字节的块的任何子集被称为“块前缀”，并且以块的结尾结束的块的任何这样的子集被称为“块后缀”。
(3) Red-Part
(3) 红色部分
The block prefix that is to be transmitted reliably, i.e., subject to acknowledgment and retransmission.
要可靠传输的块前缀，即接受确认和重传。
(4) Green-Part
(4) 绿色部分
The block suffix that is to be transmitted unreliably, i.e., not subject to acknowledgments or retransmissions. If present, the green-part of a block begins at the octet following the end of the red-part.
不可靠传输的块后缀，即不受确认或重传的约束。如果存在，块的绿色部分从红色部分结束后的八位字节开始。
(5) Session
(5) 一场
A thread of LTP protocol activity conducted between two peer engines for the purpose of transmitting a block. Data flow in a session is unidirectional: data traffic flows from the sending peer to the
为了传输数据块，在两个对等引擎之间执行的LTP协议活动线程。会话中的数据流是单向的：数据流量从发送对等方流向发送对等方
receiving peer, while data-acknowledgment traffic flows from the receiving peer to the sending peer.
接收对等方，而数据确认流量从接收对等方流向发送对等方。
(6) Sender
(6) 发件人
The data sending peer of a session.
会话的数据发送对等方。
(7) Receiver
(7) 接受者
The data receiving peer of a session.
会话的数据接收对等方。
(8) Client Service Instance
(8) 客户端服务实例
A software entity, such as an application or a higher-layer protocol implementation, that is using LTP to transfer data.
使用LTP传输数据的软件实体，如应用程序或更高层协议实现。
(9) Segment
(9) 段
The unit of LTP data transmission activity. It is the data structure transmitted from one LTP engine to another in the course of a session. Each LTP segment is of one of the following types: data segment, report segment, report-acknowledgment segment, cancel segment, cancel-acknowledgment segment.
LTP数据传输活动的单位。它是在会话过程中从一个LTP引擎传输到另一个LTP引擎的数据结构。每个LTP段属于以下类型之一：数据段、报告段、报告确认段、取消段、取消确认段。
(10) Reception Claim
（10） 接收索赔
An assertion of reception of some number of contiguous octets of application data (a subset of a block) characterized by: the offset of the first received octet, and the number of contiguous octets received (beginning at the offset).
一种接收若干个连续八位字节的应用数据（块的子集）的断言，其特征是：第一个接收到的八位字节的偏移量和接收到的连续八位字节的数量（从偏移量开始）。
(11) Scope
（11） 范围
Scope identifies a subset of a block and comprises two numbers -- upper bound and lower bound.
范围标识块的子集，由两个数字组成——上限和下限。
For a data segment, lower bound is the offset of the segment's application data from the start of the block (in octets), while upper bound is the sum of the offset and length of the segment's application data (in octets). For example, a segment with a block offset of 1000 and length of 500 would have a lower bound of 1000 and upper bound of 1500.
对于数据段，下界是段的应用数据从块开始的偏移量（以八位字节为单位），而上界是段的应用数据的偏移量和长度之和（以八位字节为单位）。例如，块偏移为1000且长度为500的线段的下限为1000，上限为1500。
For a report segment, upper bound is the end of the block prefix to which the reception claims in the report apply, while lower bound is the end of the (smaller) interior block prefix to which the reception claims in the report do *not* apply. That is, data at any offset equal to or greater than the report's lower bound but less than its
对于报告段，上界是报告中的接收声明适用的块前缀的结尾，而下界是报告中的接收声明*不*适用的（较小）内部块前缀的结尾。也就是说，任何偏移量处的数据等于或大于报表的下限，但小于其下限
upper bound and not designated as "received" by any of the report's reception claims must be assumed not received, and therefore eligible for retransmission. For example, if a report segment carried a lower bound of 1000 and an upper bound of 5000, and the reception claims indicated reception of data within offsets 1000-1999 and 3000-4999, data within the block offsets 2000-2999 can be considered missing and eligible for retransmission.
上限和未被任何报告接收声明指定为“已接收”的，必须假定未接收，因此有资格重新传输。例如，如果报告段具有1000的下限和5000的上限，并且接收请求指示接收偏移量1000-1999和3000-4999内的数据，则块偏移量2000-2999内的数据可以被视为丢失并且有资格重新传输。
Reception reports (which may comprise multiple report segments) also have scope, as defined in Section 6.11.
接收报告（可能包括多个报告段）也有范围，如第6.11节所定义。
(12) End of Block (EOB)
（12） 块结束（EOB）
The last data segment transmitted as part of the original transmission of a block. This data segment also indicates that the segment's upper bound is the total length of the block (in octets).
作为块原始传输的一部分传输的最后一个数据段。该数据段还表明该段的上界是块的总长度（以八位字节为单位）。
(13) End of Red-Part (EORP)
（13） 红色零件端部（EORP）
The segment transmitted as part of the original transmission of a block containing the last octet of the block's red-part. This data segment also indicates that the segment's upper bound is the length of the block's red-part (in octets).
作为包含块红色部分最后一个八位组的块的原始传输的一部分传输的段。该数据段还表示该段的上限是块的红色部分的长度（以八位字节为单位）。
(14) Checkpoint
（14） 检查站
A data segment soliciting a reception report from the receiving LTP engine. The EORP segment must be flagged as a checkpoint, as must the last segment of any retransmission; these are "mandatory checkpoints". All other checkpoints are "discretionary checkpoints".
从接收LTP引擎请求接收报告的数据段。EORP段必须标记为检查点，任何重传的最后一段也必须标记为检查点；这些是“强制性检查点”。所有其他检查点都是“任意检查点”。
(15) Reception Report
（15） 接待报告
A sequence of one or more report segments reporting on all block data reception within some scope.
一个或多个报告段的序列，报告某个范围内的所有块数据接收情况。
(16) Synchronous Reception Report
（16） 同步接收报告
A reception report that is issued in response to a checkpoint.
为响应检查点而发布的接收报告。
(17) Asynchronous Reception Report
（17） 异步接收报告
A reception report that is issued in response to some implementation-defined event other than the arrival of a checkpoint.
为响应某些实现定义的事件而发布的接收报告，而不是检查点的到达。
(18) Primary Reception Report
（18） 主要接收报告
A reception report that is issued in response to some event other than the arrival of a checkpoint segment that was itself issued in response to a reception report. Primary reception reports include all asynchronous reception reports and all synchronous reception reports that are sent in response to discretionary checkpoints or to the EORP segment for a session.
为响应某些事件而发布的接收报告，而不是为响应接收报告而发布的检查点段的到达。主接收报告包括响应任意检查点或会话的EORP段而发送的所有异步接收报告和所有同步接收报告。
(19) Secondary Reception Report
（19） 二级接收报告
A reception report that is issued in response to the arrival of a checkpoint segment that was itself issued in response to a reception report.
为响应检查点段的到达而发布的接收报告，该检查点段本身是为响应接收报告而发布的。
(20) Self-Delimiting Numeric Value (SDNV)
（20） 自定界数值（SDNV）
The design of LTP attempts to reconcile minimal consumption of transmission bandwidth with
LTP的设计试图将传输带宽的最小消耗与
(a) extensibility to satisfy requirements not yet identified, and
(a) 可扩展性，以满足尚未确定的需求，以及
(b) scalability across a very wide range of network sizes and transmission payload sizes.
(b) 跨各种网络规模和传输有效负载规模的可扩展性。
The SDNV encoding scheme is modeled after the Abstract Syntax Notation One [ASN1] scheme for encoding Object Identifier values. In a data field encoded as an SDNV, the most significant bit (MSB) of each octet of the SDNV serves to indicate whether or not the octet is the last octet of the SDNV. An octet with an MSB of 1 indicates that it is either the first or a middle octet of a multi-octet SDNV; the octet with an MSB of 0 is the last octet of the SDNV. The value encoded in an SDNV is found by concatenating the 7 least significant bits of each octet of the SDNV, beginning at the first octet and ending at the last octet.
SDNV编码方案是在抽象语法符号One[ASN1]方案的基础上建模的，用于编码对象标识符值。在编码为SDNV的数据字段中，SDNV的每个八位字节的最高有效位（MSB）用于指示该八位字节是否为SDNV的最后一个八位字节。MSB为1的八位元表示它是多八位元SDNV的第一个八位元或中间八位元；MSB为0的八位字节是SDNV的最后一个八位字节。SDNV中编码的值是通过将SDNV的每个八位字节的7个最低有效位串联在一起，从第一个八位字节开始，到最后一个八位字节结束。
The following examples illustrate the encoding scheme for various hexadecimal values.
以下示例说明了各种十六进制值的编码方案。
0xABC : 1010 1011 1100 is encoded as
0xABC:1010 1011 1100编码为
{100 1010 1} {0 011 1100}
- -
{100 1010 1} {0 011 1100}
- -
= 10010101 00111100
= 10010101 00111100
0x1234 : 0001 0010 0011 0100 = 1 0010 0011 0100 is encoded as
0x1234:0001 0010 0011 0100=1 0010 0011 0100编码为
{10 1 0010 0} {0 011 0100}
- -
{10 1 0010 0} {0 011 0100}
- -
= 10100100 00110100
= 10100100 00110100
0x4234 : 0100 0010 0011 0100 =100 0010 0011 0100 is encoded as
0x4234:0100 0010 0011 0100=100 0010 0011 0100编码为
{1000000 1} {1 00 0010 0} {0 011 0100}
- - -
{1000000 1} {1 00 0010 0} {0 011 0100}
- - -
= 10000001 10000100 00110100
= 10000001 10000100 00110100
0x7F : 0111 1111 =111 1111 is encoded as
0x7F:0111111=111 1111编码为
{0 111 1111} -
{0 111 1111} -
= 01111111
= 01111111
Note:
注:
Care must be taken to make sure that the value to be encoded is padded with zeroes at the most significant bit end (NOT at the least significant bit end) to make its bitwise length a multiple of 7 before encoding.
必须注意确保要编码的值在最高有效位端（而不是最低有效位端）用零填充，以使其位长度在编码前为7的倍数。
While there is no theoretical limit on the size of an SDNV field, we note that the overhead of the SDNV scheme is 1:7, i.e., 1 bit of overhead for every 7 bits of actual data to be encoded. Thus, a
虽然SDNV字段的大小在理论上没有限制，但我们注意到SDNV方案的开销为1:7，即每7位要编码的实际数据就有1位开销。因此
7-octet value (a 56-bit quantity with no leading zeroes) would be encoded in an 8-octet SDNV; an 8-octet value (a 64-bit quantity with no leading zeroes) would be encoded in a 10-octet SDNV. In general, an N-bit quantity with no leading zeroes would be encoded in a ceil(N/7) octet SDNV, where ceil is the integer ceiling function. Clearly, for fields that typically carry larger values such as RSA public keys, the SDNV overhead could become unacceptable. Hence, when adopting the SDNV scheme for other purposes related to this document, such as any protocol extensions, we RECOMMEND that if the typical data field value is expected to be larger than 8 octets, then the data field should be specified as a {LENGTH, VALUE} tuple, with the LENGTH parameter encoded as an SDNV followed by LENGTH octets housing the VALUE of the data field.
7-八位组值（无前导零的56位量）将编码在8-八位组SDNV中；8个八位组的值（一个没有前导零的64位量）将被编码在10个八位组的SDNV中。通常，不带前导零的N位量将被编码在ceil（N/7）八位组SDNV中，其中ceil是整数上限函数。显然，对于通常携带较大值（如RSA公钥）的字段，SDNV开销可能无法接受。因此，当将SDNV方案用于与本文件相关的其他目的时，如任何协议扩展，我们建议，如果预期典型数据字段值大于8个八位字节，则应将数据字段指定为{LENGTH，value}元组，长度参数编码为SDNV，后跟包含数据字段值的长度八位字节。
We also note that SDNV is clearly not the best way to represent every numeric value. When the maximum possible value of a number is known without question, the cost of additional bits may not be justified. For example, an SDNV is a poor way to represent an integer whose value typically falls in the range 128 to 255. In general, though, we believe that the SDNV representation of various protocol data fields in LTP segments yields the smallest segment sizes without sacrificing scalability.
我们还注意到，SDNV显然不是表示每个数值的最佳方式。当一个数字的最大可能值毫无疑问是已知的时，额外比特的成本可能是不合理的。例如，SDNV是表示值通常在128到255范围内的整数的糟糕方法。但是，一般来说，我们认为LTP段中各种协议数据字段的SDNV表示在不牺牲可伸缩性的情况下产生最小的段大小。
Each LTP segment comprises
每个LTP部分包括
(a) a "header" in the format defined below.
(a) 以下定义格式的“标题”。
(b) zero or more octets of "content".
(b) “内容”的零个或多个八位字节。
(c) zero or more octets of "trailer" as indicated by information in the "Extensions field" of the header.
(c) “拖车”的零个或多个八位字节，如标题“扩展字段”中的信息所示。
LTP segments are of four general types depending on the nature of the content carried:
根据所载内容的性质，LTP片段有四种一般类型：
Data segments flow from the sender to the receiver and carry client service (application) data.
数据段从发送方流向接收方，并携带客户端服务（应用程序）数据。
A report segment flows from the receiver to the sender and carries data reception claims together with the upper and lower bounds of the block scope to which the claims pertain.
报告段从接收方流向发送方，并携带数据接收声明以及声明所涉及的块范围的上限和下限。
A report-acknowledgment segment flows from the sender to the receiver and acknowledges reception of a report segment. It carries the serial number of the report being acknowledged.
报告确认段从发送方流向接收方，并确认报告段的接收。它携带被确认报告的序列号。
Session management segments may be generated by both the sender and the receiver and are of two general sub-types: cancellation and cancellation-acknowledgment. A cancellation segment initiates session cancellation procedures at the peer and carries a single byte reason-code to indicate the reason for session cancellation. Cancellation-acknowledgment segments merely acknowledge reception of a cancellation segment and have no content.
会话管理段可以由发送方和接收方生成，并且具有两种通用子类型：取消和取消确认。取消段在对等端启动会话取消过程，并携带一个单字节的原因码来指示会话取消的原因。取消确认段仅确认接收到取消段，没有内容。
The overall segment structure is illustrated below:
整体分部结构如下图所示：
Bit 0 1 2 3 4 5 6 7
^ +-----+-----+-----+-----+-----+-----+-----+-----+
| | Version number | Segment Type Flags | Control
| +-----------------------+-----------------------+ -byte
| | |
| / Session ID \
| \ /
Header +-----------------------+-----------------------+
| | Header Extension Cnt. | Trailer Extension Cnt.| Extensions
| +-----------------------+-----------------------+
| | |
| / Header Extensions \
| \ /
V +-----------------------------------------------+
| |
| |
| |
| Segment Content |
/ \
\ /
| |
| |
| |
^ +-----------------------------------------------+
| | |
Trailer / Trailer Extensions \
| \ /
V +-----------------------------------------------+
Bit 0 1 2 3 4 5 6 7
^ +-----+-----+-----+-----+-----+-----+-----+-----+
| | Version number | Segment Type Flags | Control
| +-----------------------+-----------------------+ -byte
| | |
| / Session ID \
| \ /
Header +-----------------------+-----------------------+
| | Header Extension Cnt. | Trailer Extension Cnt.| Extensions
| +-----------------------+-----------------------+
| | |
| / Header Extensions \
| \ /
V +-----------------------------------------------+
| |
| |
| |
| Segment Content |
/ \
\ /
| |
| |
| |
^ +-----------------------------------------------+
| | |
Trailer / Trailer Extensions \
| \ /
V +-----------------------------------------------+
An LTP segment header comprises three data items: a single-octet control byte, the session ID, and the Extensions field.
LTP段头包含三个数据项：单个八位字节控制字节、会话ID和扩展字段。
Control byte comprises the following:
控制字节包括以下内容：
Version number (4 bits): MUST be set to the binary value 0000 for this version of the protocol.
版本号（4位）：对于此版本的协议，必须设置为二进制值0000。
Segment type flags (4 bits): described in Section 3.1.1.
段类型标志（4位）：如第3.1.1节所述。
Session ID uniquely identifies, among all transmissions between the sender and receiver, the session of which the segment is one token. It comprises the following:
会话ID在发送方和接收方之间的所有传输中唯一标识该段为一个令牌的会话。它包括以下内容：
Session originator (SDNV): the engine ID of the sender.
会话发起者（SDNV）：发送者的引擎ID。
Session number (SDNV): typically a random number (for anti-DoS reasons), generated by the sender.
会话号（SDNV）：通常是一个随机数（出于反DoS原因），由发送方生成。
The format and resolution of session number are matters that are private to the LTP sender; the only requirement imposed by LTP is that every session initiated by an LTP engine MUST be uniquely identified by the session ID.
会话号的格式和解析是LTP发送方专有的事项；LTP施加的唯一要求是，由LTP引擎启动的每个会话必须由会话ID唯一标识。
The Extensions field is described in Section 3.1.4.
第3.1.4节描述了扩展字段。
The last 4 bits of the control byte in the segment header are flags that indicate the nature of the segment. In order (most significant bit first), these flags are CTRL, EXC, Flag 1, and Flag 0.
段头中控制字节的最后4位是指示段性质的标志。按顺序（最高有效位优先），这些标志是CTRL、EXC、标志1和标志0。
A value of 0 in the CTRL (Control) flag identifies the segment as a data segment, while a value of 1 identifies it as a control segment. A data segment with the EXC (Exception) flag set to 0 is a red-part segment; a data segment with EXC set to 1 is a green-part segment. For a control segment, having the EXC flag set to 1 indicates that the segment pertains to session cancellation activity. Any data segment (whether red-part or green-part) with both Flag 1 and Flag 0 set to 1 indicates EOB. Any data segment (whether red-part or green-part) with both Flag 1 and Flag 0 set to 0 indicates data without any additional protocol significance. Any red-part data segment with either flag bit non-zero is a checkpoint. Any red-part data segment with Flag 1 set to 1 indicates the end of red-part.
CTRL（Control）标志中的值为0表示该段为数据段，而值为1表示该段为控制段。EXC（异常）标志设置为0的数据段为红色部分段；EXC设置为1的数据段是绿色零件段。对于控制段，将EXC标志设置为1表示该段属于会话取消活动。标志1和标志0均设置为1的任何数据段（红色部分或绿色部分）表示EOB。标志1和标志0均设置为0的任何数据段（红色部分或绿色部分）表示没有任何附加协议意义的数据。任何标志位非零的红色部分数据段都是检查点。标志1设置为1的任何红色零件数据段表示红色零件的结束。
Put another way:
换句话说：
if (CTRL flag = 0) segment is a data segment if (EXC flag = 0) segment contains only red-part data if (Flag 1 = 1) segment is a checkpoint segment is the last segment in the red part of the block if (Flag 0 = 1) segment is the last segment in the block else // segment is not end of red-part if (Flag 0 = 1) segment is a checkpoint else segment contains only green-part data if (Flag 1 = 1) if (Flag 0 = 1) segment is the last segment in the block else segment is a control segment if (EXC flag = 0) segment pertains to report activity if (flag 0 = 0) segment is a report segment else segment is an acknowledgment of a report segment else segment pertains to session cancellation activity if (Flag 1 = 0) segment pertains to cancellation by block sender if (Flag 0 = 1) segment is a cancellation by sender else segment is an acknowledgment of a cancellation by sender else segment pertains to cancellation by block receiver if (Flag 0 = 1) segment is a cancellation by receiver else segment is an acknowledgment of a cancellation by receiver
如果（CTRL flag=0）段是数据段如果（EXC flag=0）段仅包含红色部分数据如果（标志1=1）段是检查点段如果（标志0=1）段是块的红色部分的最后一段否则//段不是红色部分的结尾如果（标志0=1）如果（标志1=1）如果（标志0=1）段是块中的最后一段，则段为检查点else段仅包含绿色零件数据；如果（EXC标志=0）段属于报告活动if（标志0=0），则段为控制段段是报告段else段是对报告段的确认else段属于会话取消活动如果（标志1=0）段属于块发送方取消如果（标志0=1）段是由发送方取消的，其他段是由发送方取消的确认。如果（标志0=1）段是由接收方取消的，则其他段属于由块接收方取消的。其他段是由接收方取消的确认
Combinations of the settings of the segment type flags CTRL, EXC, Flag 1, and Flag 0 constitute segment type codes, which serve as concise representations of detailed segment nature.
段类型标志CTRL、EXC、标志1和标志0的设置组合构成段类型代码，作为详细段性质的简明表示。
CTRL EXC Flag 1 Flag 0 Code Nature of segment
---- --- ------ ------ ---- ---------------------------------------
0 0 0 0 0 Red data, NOT {Checkpoint, EORP or EOB}
0 0 0 1 1 Red data, Checkpoint, NOT {EORP or EOB}
0 0 1 0 2 Red data, Checkpoint, EORP, NOT EOB
0 0 1 1 3 Red data, Checkpoint, EORP, EOB
CTRL EXC Flag 1 Flag 0 Code Nature of segment
---- --- ------ ------ ---- ---------------------------------------
0 0 0 0 0 Red data, NOT {Checkpoint, EORP or EOB}
0 0 0 1 1 Red data, Checkpoint, NOT {EORP or EOB}
0 0 1 0 2 Red data, Checkpoint, EORP, NOT EOB
0 0 1 1 3 Red data, Checkpoint, EORP, EOB
0 1 0 0 4 Green data, NOT EOB 0 1 0 1 5 Green data, undefined 0 1 1 0 6 Green data, undefined 0 1 1 1 7 Green data, EOB
0 1 0 0 4绿色数据，非EOB 0 1 0 1 5绿色数据，未定义0 1 0 6绿色数据，未定义0 1 1 1 7绿色数据，EOB
1 0 0 0 8 Report segment 1 0 0 1 9 Report-acknowledgment segment 1 0 1 0 10 Control segment, undefined 1 0 1 1 11 Control segment, undefined
1 0 0 8报告段1 0 1 9报告确认段1 0 1 0 10控制段，未定义1 0 1 11控制段，未定义
1 1 0 0 12 Cancel segment from block sender 1 1 0 1 13 Cancel-acknowledgment segment to block sender
1 1 0 0 12从块发送方取消段1 0 1 13从块发送方取消确认段
1 1 1 0 14 Cancel segment from block receiver 1 1 1 1 15 Cancel-acknowledgment segment to block receiver
1 1 0 14从块接收器1 1 1 15取消确认段到块接收器的取消段
For the purposes of this specification, some bit patterns in the segment type flags field correspond to "segment classes" that are designated by mnemonics. The mnemonics are intended to evoke the characteristics shared by all types of segments characterized by these flag bit patterns.
在本规范中，段类型标志字段中的某些位模式对应于助记符指定的“段类”。助记符旨在唤起以这些标志位模式为特征的所有类型的段共享的特征。
CTRL EXC Flag 1 Flag 0 Mnemonic Description
---- --- ------ ------ -------- ---------------------------
0 0 - 1
-- or --
0 0 1 - CP Checkpoint
CTRL EXC Flag 1 Flag 0 Mnemonic Description
---- --- ------ ------ -------- ---------------------------
0 0 - 1
-- or --
0 0 1 - CP Checkpoint
0 0 1 - EORP End of red-part;
red-part size = offset + length
0 0 1 - EORP End of red-part;
red-part size = offset + length
0 - 1 1 EOB End of block;
block size = offset + length
0 - 1 1 EOB End of block;
block size = offset + length
1 0 0 0 RS Report segment; carries reception claims
1 0 0 RS报告段；进行接收索赔
1 0 0 1 RA Report-acknowledgment segment
1 0 1 RA报告确认段
1 1 0 0 CS Cancel segment from block sender
1 10 CS取消来自块发送器的段
1 1 0 1 CAS Cancel-acknowledgment segment to block sender
1 0 1 CAS取消确认段以阻止发送方
1 1 1 0 CR Cancel segment from block receiver
来自块接收器的10 CR取消段
1 1 1 1 CAR Cancel-acknowledgment segment to block receiver
1车辆取消确认段至闭塞接收器
1 1 - 0 Cx Cancel segment (generic)
1 1-0 Cx取消段（通用）
1 1 - 1 CAx Cancel-acknowledgment segment (generic)
1 1-1 CAx取消确认段（通用）
The Extensions field enables the inclusion of zero or more functional extensions to the basic LTP segment, each in type-length-value (TLV) representation as explained below.
Extensions（扩展）字段允许将零个或多个功能扩展包含到基本LTP段，每个扩展都包含在类型长度值（TLV）表示中，如下所述。
The first octet of the Extensions field indicates the number of extensions present in the segment: the high-order 4 bits indicate the number of extension TLVs in the header (immediately following the extensions count octet and preceding the segment's content), while the low-order 4 bits indicate the number of extension TLVs in the trailer (immediately following the segment's content). That is, each segment may have from 0 to 15 extension TLVs in its header and from 0 to 15 extension TLVs in its trailer. In the absence of any extension TLVs, all bits of this extensions count octet MUST be set to zero.
Extensions字段的第一个八位表示段中存在的扩展的数量：高阶4位表示头中扩展TLV的数量（紧跟扩展计数八位之后、段内容之前），而低阶4位表示尾部中扩展TLV的数量（紧跟在段内容之后）。也就是说，每个段的头中可能有0到15个扩展TLV，尾中可能有0到15个扩展TLV。在没有任何扩展TLV的情况下，此扩展计数八位字节的所有位都必须设置为零。
Note that it is valid for header extensions to be immediately followed by trailer extensions; for example, since a CAx segment has no contents, it may have header extensions immediately followed by trailer extensions.
请注意，头部延伸后紧接拖车延伸是有效的；例如，因为CAx段没有内容，所以它可能有标题扩展，后面紧跟着拖车扩展。
Each extension consists of a one-octet tag identifying the type of the extension, followed by a length parameter in SDNV form, followed by a value of the specified length.
每个扩展都由一个八位组标记组成，标识扩展的类型，后跟一个SDNV形式的长度参数，后跟一个指定长度的值。
The diagram below illustrates the extension TLVs as they may occur in the header or trailer.
下图显示了可能出现在收割台或拖车中的扩展TLV。
+--------+----///-----///--+
|ext-tag | length | value |
+--------+-------///-------+----------///-------+
|ext-tag | length | value |
+--------+-----///-----///-+---------////-------+
|ext-tag | length | value |
+--------+----------+----------+
+--------+----///-----///--+
|ext-tag | length | value |
+--------+-------///-------+----------///-------+
|ext-tag | length | value |
+--------+-----///-----///-+---------////-------+
|ext-tag | length | value |
+--------+----------+----------+
The IANA maintains an LTP Extension Tag registry as shown below. See the IANA considerations section below for details of code point assignment in the Unassigned range.
IANA维护一个LTP扩展标记注册表，如下所示。有关未分配范围内代码点分配的详细信息，请参见下面的IANA注意事项部分。
Extension tag Meaning
------------- -------
0x00 LTP authentication extension [LTPEXT]
0x01 LTP cookie extension [LTPEXT]
0x02-0xAF Unassigned
0xB0-0xBF Reserved
0xC0-0xFF Private / Experimental Use
Extension tag Meaning
------------- -------
0x00 LTP authentication extension [LTPEXT]
0x01 LTP cookie extension [LTPEXT]
0x02-0xAF Unassigned
0xB0-0xBF Reserved
0xC0-0xFF Private / Experimental Use
Note that since the last quarter of the extension-tag space is for experimental use, implementations should be aware that collisions for these tags are possible.
请注意，由于扩展标记空间的最后四分之一是供实验使用的，所以实现应该知道这些标记可能发生冲突。
The content of a data segment includes client service data and the metadata enabling the receiving client service instance to receive and make use of that data.
数据段的内容包括客户端服务数据和元数据，使接收客户端服务实例能够接收和使用该数据。
Client service ID (SDNV)
客户端服务ID（SDNV）
The client service ID number identifies the upper-level service to which the segment is to be delivered by the receiver. It is functionally analogous to a TCP port number. If multiple instances of the client service are present at the destination, multiplexing must be done by the client service itself on the basis of information encoded within the transmitted block.
客户端服务ID号标识接收方将向其交付段的上层服务。它在功能上类似于TCP端口号。如果目的地存在多个客户机服务实例，则必须由客户机服务本身根据传输块中编码的信息进行多路复用。
Offset (SDNV)
偏移量（SDNV）
Offset indicates the location of the segment's client service data within the session's transmitted block. It is the number of bytes in the block prior to the byte from which the first octet of the segment's client service data was copied.
偏移量表示会话传输块中段的客户端服务数据的位置。它是在复制段的客户机服务数据的第一个八位字节之前的块中的字节数。
Length (SDNV)
长度（SDNV）
The length of the ensuing client service data, in octets.
随后的客户端服务数据的长度，以八位字节为单位。
If the data segment is a checkpoint, the segment MUST additionally include the following two serial numbers (checkpoint serial number and report serial number) to support efficient retransmission. Data segments that are not checkpoints MUST NOT have these two fields in the header and MUST continue on directly with the client service data.
如果数据段是检查点，则该段还必须包括以下两个序列号（检查点序列号和报告序列号），以支持有效的重新传输。非检查点的数据段在标头中不能有这两个字段，并且必须直接与客户机服务数据一起继续。
Checkpoint serial number (SDNV)
检查点序列号（SDNV）
The checkpoint serial number uniquely identifies the checkpoint among all checkpoints issued by the block sender in a session. The first checkpoint issued by the sender MUST have this serial number chosen randomly for security reasons, and it is RECOMMENDED that the sender use the guidelines in [ESC05] for this. Any subsequent checkpoints issued by the sender MUST have the serial number value found by incrementing the prior checkpoint serial number by 1. When a checkpoint segment is retransmitted, however, its serial number MUST be the same as when it was originally transmitted. The checkpoint serial number MUST NOT be zero.
检查点序列号唯一标识会话中由块发送方发出的所有检查点中的检查点。出于安全原因，发送方发布的第一个检查点必须随机选择此序列号，建议发送方使用[ESC05]中的指南。发送方发出的任何后续检查点必须具有通过将先前检查点序列号增加1找到的序列号值。但是，当重新传输检查点段时，其序列号必须与最初传输时的序列号相同。检查点序列号不得为零。
Report serial number (SDNV)
报告序列号（SDNV）
If the checkpoint was queued for transmission in response to the reception of an RS (Section 6.13), then its value MUST be the report serial number value of the RS that caused the data segment to be queued for transmission.
如果检查点排队等待传输以响应RS的接收（第6.13节），则其值必须是导致数据段排队等待传输的RS的报告序列号值。
Otherwise, the value of report serial number MUST be zero.
否则，报告序列号的值必须为零。
Client service data (array of octets)
客户端服务数据（八位字节数组）
The client service data carried in the segment is a copy of a subset of the bytes in the original client service data block, starting at the indicated offset.
段中携带的客户端服务数据是原始客户端服务数据块中字节子集的副本，从指示的偏移量开始。
The content of an RS comprises one or more data reception claims, together with the upper and lower bounds of the scope within the data block to which the claims pertain. It also includes two serial numbers to support efficient retransmission.
RS的内容包括一个或多个数据接收权利要求，以及权利要求所涉及的数据块内范围的上限和下限。它还包括两个序列号，以支持有效的重新传输。
Report serial number (SDNV)
报告序列号（SDNV）
The report serial number uniquely identifies the report among all reports issued by the receiver in a session. The first report issued by the receiver MUST have this serial number chosen randomly for security reasons, and it is RECOMMENDED that the receiver use the guidelines in [ESC05] for this. Any subsequent RS issued by the receiver MUST have the serial number value found by incrementing the last report serial number by 1. When an RS is retransmitted however, its serial number MUST be the same as when it was originally transmitted. The report serial number MUST NOT be zero.
报告序列号在会话中由接收方发布的所有报告中唯一标识报告。出于安全原因，接收人发布的第一份报告必须随机选择该序列号，建议接收人使用[ESC05]中的指南。接收方发出的任何后续RS必须具有通过将上次报告序列号增加1找到的序列号值。然而，当RS重新传输时，其序列号必须与最初传输时相同。报告序列号不得为零。
Checkpoint serial number (SDNV)
检查点序列号（SDNV）
The value of the checkpoint serial number MUST be zero if the report segment is NOT a response to reception of a checkpoint, i.e., the reception report is asynchronous; otherwise, it MUST be the checkpoint serial number of the checkpoint that caused the RS to be issued.
如果报告段不是对检查点接收的响应，即接收报告是异步的，则检查点序列号的值必须为零；否则，必须是导致发出RS的检查点的检查点序列号。
Upper bound (SDNV)
上限（SDNV）
The upper bound of a report segment is the size of the block prefix to which the segment's reception claims pertain.
报告段的上限是该段的接收声明所涉及的块前缀的大小。
Lower bound (SDNV)
下限（SDNV）
The lower bound of a report segment is the size of the (interior) block prefix to which the segment's reception claims do NOT pertain.
报告段的下限是段的接收声明不涉及的（内部）块前缀的大小。
Reception claim count (SDNV)
接收索赔计数（SDNV）
The number of data reception claims in this report segment.
此报告段中的数据接收声明数。
Reception claims
接收索赔
Each reception claim comprises two elements: offset and length.
每个接收索赔包括两个要素：偏移量和长度。
Offset (SDNV)
偏移量（SDNV）
The offset indicates the successful reception of data beginning at the indicated offset from the lower bound of the RS. The offset within the entire block can be calculated by summing this offset with the lower bound of the RS.
偏移量表示从指示的RS下界偏移量开始成功接收数据。可通过将该偏移量与RS下界相加来计算整个块内的偏移量。
Length (SDNV)
长度（SDNV）
The length of a reception claim indicates the number of contiguous octets of block data starting at the indicated offset that have been successfully received.
接收声明的长度表示从所指示的偏移量开始已成功接收的块数据的连续八位字节数。
Reception claims MUST conform to the following rules:
接收索赔必须符合以下规则：
A reception claim's length shall never be less than 1 and shall never exceed the difference between the upper and lower bounds of the report segment.
接收索赔的长度不得小于1，且不得超过报告段上下限之间的差值。
The offset of a reception claim shall always be greater than the sum of the offset and length of the prior claim, if any.
接收索赔的偏移量应始终大于先前索赔的偏移量和长度之和（如有）。
The sum of a reception claim's offset and length and the lower bound of the report segment shall never exceed the upper bound of the report segment.
接收索赔的偏移量和长度与报告段的下限之和不得超过报告段的上限。
Implied requests for retransmission of client service data can be inferred from an RS's data reception claims. However, *nothing* can be inferred regarding reception of block data at any offset equal to or greater than the segment's upper bound or at any offset less than the segment's lower bound.
可以从RS的数据接收声明中推断出客户端服务数据的隐含重传请求。然而，对于在等于或大于段的上界的任何偏移处或在小于段的下界的任何偏移处接收块数据，不能推断出*没有*。
For example, if the scope of a report segment has lower bound 0 and upper bound 6000, and the report contains a single data reception claim with offset 0 and length 6000, then the report signifies successful reception of the first 6000 bytes of the block. If the total length of the block is 6000, then the report additionally signifies successful reception of the entire block.
例如，如果报告段的范围具有下限0和上限6000，并且报告包含偏移量为0且长度为6000的单个数据接收声明，则报告表示成功接收块的前6000字节。如果区块的总长度为6000，则报告还表示成功接收整个区块。
If on the other hand, the scope of a report segment has lower bound 1000 and upper bound 6000, and the report contains two data reception claims, one with offset 0 and length 2000 and the other with offset 3000 and length 500, then the report signifies successful reception only of bytes 1000-2999 and 4000-4499 of the block. From this we can infer that bytes 3000-3999 and 4500-5999 of the block need to be retransmitted, but we cannot infer anything about reception of the first 1000 bytes or of any subsequent data beginning at block offset 6000.
另一方面，如果报告段的范围具有下限1000和上限6000，并且报告包含两个数据接收声明，一个具有偏移量0和长度2000，另一个具有偏移量3000和长度500，则报告表示仅成功接收块的字节1000-2999和4000-4499。由此，我们可以推断块的字节3000-3999和4500-5999需要重新传输，但我们无法推断关于接收前1000字节或从块偏移量6000开始的任何后续数据的任何信息。
The content of an RA is simply the report serial number of the RS in response to which the segment was generated.
RA的内容只是生成段的RS的报告序列号。
Report serial number (SDNV)
报告序列号（SDNV）
This field returns the report serial number of the RS being acknowledged.
此字段返回正在确认的RS的报告序列号。
Cancel segments (Cx) carry a single byte reason-code with the following semantics:
取消段（Cx）包含一个单字节原因码，其语义如下：
Reason-Code Mnemonic Semantics
----------- -------- ---------------------------------------
00 USR_CNCLD Client service canceled session.
Reason-Code Mnemonic Semantics
----------- -------- ---------------------------------------
00 USR_CNCLD Client service canceled session.
01 UNREACH Unreachable client service.
01无法访问的无法访问的客户端服务。
02 RLEXC Retransmission limit exceeded.
超过02 RLEXC重新传输限制。
03 MISCOLORED Received either a red-part data segment at block offset above any green-part data segment offset or a green-part data segment at block offset below any red-part data segment offset.
03 MISCOLORED在任何绿色零件数据段偏移上方的块偏移处接收到红色零件数据段，或在任何红色零件数据段偏移下方的块偏移处接收到绿色零件数据段。
04 SYS_CNCLD A system error condition caused unexpected session termination.
04系统错误导致意外会话终止。
05 RXMTCYCEXC Exceeded the Retransmission-Cycles limit.
05 RXMTCYCEXC超出了重传周期限制。
06-FF Reserved
06-FF保留
The Cancel-acknowledgments (CAx) have no content.
取消确认（CAx）没有内容。
Note: The reason we use different cancel segment types for the originator and recipient is to allow a loopback mode to work without disturbing any replay protection mechanism in use.
注意：我们为发起者和接收者使用不同的取消段类型的原因是允许环回模式工作，而不会干扰正在使用的任何重播保护机制。
The segment trailer consists of a sequence of zero to 15 extension TLVs as described in Section 3.1.4 above.
分段挂车由零至15个延伸TLV组成，如上文第3.1.4节所述。
In all cases, the representation of request parameters is a local implementation matter, as are validation of parameter values and notification of the client service in the event that a request is found to be invalid.
在所有情况下，请求参数的表示都是本地实现问题，参数值的验证以及在发现请求无效时通知客户机服务也是如此。
In order to request transmission of a block of client service data, the client service MUST provide the following parameters to LTP:
为了请求传输客户端服务数据块，客户端服务必须向LTP提供以下参数：
Destination client service ID.
目标客户端服务ID。
Destination LTP engine ID.
目标LTP引擎ID。
Client service data to send, as an array of bytes.
要发送的客户端服务数据，作为字节数组。
Length of the data to be sent.
要发送的数据的长度。
Length of the red-part of the data. This value MUST be in the range from zero to the total length of data to be sent.
数据红色部分的长度。此值必须在从零到要发送的数据总长度的范围内。
On reception of a valid transmission request from a client service, LTP proceeds as follows.
在接收到来自客户端服务的有效传输请求时，LTP进行如下操作。
First, the array of data to be sent is subdivided as necessary, with each subdivision serving as the client service data of a single new LTP data segment. The algorithm used for subdividing the data is a local implementation matter; it is expected that data size constraints imposed by the underlying communication service, if any, will be accommodated in this algorithm.
首先，根据需要对要发送的数据数组进行细分，每个细分用作单个新LTP数据段的客户机服务数据。用于细分数据的算法是本地实现问题；预计该算法将适应底层通信服务施加的数据大小约束（如果有）。
The last (and only the last) of the resulting data segments must be marked as the EOB (end of block).
结果数据段的最后一个（且仅最后一个）必须标记为EOB（块结束）。
Note that segment type indicates that the client service data in a given LTP segment either is or is not in the red-part of the block. To prevent segment type ambiguity, each data segment MUST contain either only red-part data or only green-part data. Therefore, when the length of the block's red-part is N, the total length of the block is M, and N is not equal to M, the (N+1)th byte of the block SHOULD be the first byte of client service data in a green-part data segment. Note that this means that at the red-part boundary, LTP may send a segment of size lesser than the link MTU size. For bandwidth efficiency reasons, implementations MAY choose to instead mark the entire segment (within which the red-part boundary falls) as red-part, causing green-part data falling within the segment to also be treated as red-part.
请注意，段类型表示给定LTP段中的客户机服务数据是否在块的红色部分。为防止段类型歧义，每个数据段必须仅包含红色零件数据或绿色零件数据。因此，当块的红色部分的长度为N，块的总长度为M，且N不等于M时，块的（N+1）个字节应为绿色部分数据段中客户端服务数据的第一个字节。注意，这意味着在红色部分边界处，LTP可能发送小于链路MTU大小的段。出于带宽效率的原因，实现可能会选择将整个段（红色部分边界落在其中）标记为红色部分，从而使落在段内的绿色部分数据也被视为红色部分。
If the length of the block's red-part is greater than zero, then the last data segment containing red-part data must be marked as the EORP (end of red-part) segment by setting the appropriate segment type flag bits (Section 3.1.2). Zero or more preceding data segments containing red-part data (selected according to an algorithm that is
如果块的红色部分的长度大于零，则必须通过设置适当的段类型标志位（第3.1.2节），将包含红色部分数据的最后一个数据段标记为EORP（红色部分结束）段。零个或多个包含红色零件数据的先前数据段（根据以下算法选择）：
a local implementation matter) MAY additionally be marked as a CP (Checkpoint), and serve as additional discretionary checkpoints (Section 3.1.2).
本地实施事项）可额外标记为CP（检查点），并作为额外的自由裁量检查点（第3.1.2节）。
All data segments are appended to the (conceptual) application data queue bound for the destination engine, for subsequent transmission.
所有数据段都会附加到为目标引擎绑定的（概念性）应用程序数据队列，以便后续传输。
Finally, a session start notice (Section 7.1) is sent back to the client service that requested the transmission.
最后，会话开始通知（第7.1节）被发送回请求传输的客户端服务。
In order to request cancellation of a session, either as the sender or as the receiver of the associated data block, the client service must provide the session ID identifying the session to be canceled.
为了以相关数据块的发送方或接收方的身份请求取消会话，客户机服务必须提供标识要取消的会话的会话ID。
On reception of a valid cancellation request from a client service, LTP proceeds as follows.
在接收到来自客户端服务的有效取消请求后，LTP按如下方式进行。
First, the internal "Cancel Session" procedure (Section 6.19) is invoked.
首先，调用内部“取消会话”过程（第6.19节）。
Next, if the session is being canceled by the sender (i.e., the session originator part of the session ID supplied in the cancellation request is the local LTP engine ID):
接下来，如果发送方正在取消会话（即，取消请求中提供的会话ID的会话发起方部分是本地LTP引擎ID）：
- If none of the data segments previously queued for transmission as part of this session have yet been de-queued and transmitted -- i.e., if the destination engine cannot possibly be aware of this session -- then the session is simply closed; the "Close Session" procedure (Section 6.20) is invoked.
- 如果之前作为该会话的一部分排队等待传输的数据段中没有一个已经被解排队并传输——即，如果目标引擎不可能意识到该会话——则该会话只是关闭；调用“关闭会话”程序（第6.20节）。
- Otherwise, a CS (cancel by block sender) segment with the reason-code USR_CNCLD MUST be queued for transmission to the destination LTP engine specified in the transmission request that started this session.
- 否则，带有原因码USR_CNCLD的CS（按块发送方取消）段必须排队，以便传输到启动此会话的传输请求中指定的目标LTP引擎。
Otherwise (i.e., the session is being canceled by the receiver):
否则（即，接收方正在取消会话）：
- If there is no transmission queue-set bound for the sender (possibly because the local LTP engine is running on a receive-only device), then the session is simply closed; the "Close Session" procedure (Section 6.20) is invoked.
- 如果没有为发送方绑定传输队列集（可能是因为本地LTP引擎在仅接收设备上运行），则会话将简单地关闭；调用“关闭会话”程序（第6.20节）。
- Otherwise, a CR (cancel by block receiver) segment with reason-code USR_CNCLD MUST be queued for transmission to the block sender.
- 否则，原因码为USR_CNCLD的CR（按块接收器取消）段必须排队，以便传输到块发送方。
LTP is designed to run directly over a data-link layer protocol.
LTP设计为直接在数据链路层协议上运行。
LTP MUST only be deployed directly over UDP, for software development purposes or for use in private local area networks, for example, in a sparse sensor network where the link, when available, is only used for LTP traffic.
LTP必须仅在UDP上直接部署，用于软件开发目的或用于专用局域网，例如，在稀疏传感器网络中，链路（如果可用）仅用于LTP流量。
In either case, the protocol layer immediately underlying LTP is referred to as the "local data-link layer" for the purposes of this specification.
在任何一种情况下，就本规范而言，紧靠LTP的协议层称为“本地数据链路层”。
When the local data-link layer protocol is UDP, (a) the content of each UDP datagram MUST be an integral number of LTP segments and (b) the LTP authentication [LTPEXT] extension SHOULD be used unless the end-to-end path is one in which either the likelihood of datagram content corruption is negligible or the consequences of receiving and processing corrupt LTP segments are insignificant (as during software development). In addition, the LTP authentication [LTPEXT] extension SHOULD be used to ensure data integrity unless the end-to-end path is one in which either the likelihood of datagram content corruption is negligible (as in some private local area networks) or the consequences of receiving and processing corrupt LTP segments are insignificant (as perhaps during software development).
当本地数据链路层协议为UDP时，（a）每个UDP数据报的内容必须是LTP段的整数，（b）LTP身份验证[LTPEXT]除非端到端路径中数据报内容损坏的可能性可以忽略，或者接收和处理损坏的LTP段的后果微不足道（如软件开发期间），否则应使用扩展。此外，应使用LTP认证[LTPEXT]扩展来确保数据完整性，除非端到端路径中数据报内容损坏的可能性可以忽略不计（如在某些专用局域网中），或者接收和处理损坏的LTP段的后果微不足道（可能在软件开发期间）。
When the local data-link layer protocol is not UDP, the content of each local data-link layer protocol frame MUST be an integral number of LTP segments.
当本地数据链路层协议不是UDP时，每个本地数据链路层协议帧的内容必须是LTP段的整数。
The local data-link layer protocol MUST be a protocol that, together with the operating environment in which that protocol is implemented, satisfies the following requirements:
本地数据链路层协议必须与实现该协议的操作环境一起满足以下要求：
- It is required to inform LTP whenever the link to a specific LTP destination is brought up or torn down. Similarly, it is required to inform the local LTP engine whenever it is known that a remote LTP engine is set to begin or stop communication with the local engine based on the engines' operating schedules.
- 当连接到特定LTP目的地的链路被接通或断开时，需要通知LTP。类似地，只要知道远程LTP引擎被设置为基于引擎的运行时间表开始或停止与本地引擎的通信，就需要通知本地LTP引擎。
- It is required to provide link state cues to LTP upon transmission of the CP, RS (report), EORP, EOB, and Cx (cancel) segments so that timers can be started.
- 在传输CP、RS（报告）、EORP、EOB和Cx（取消）段时，需要向LTP提供链路状态提示，以便启动计时器。
- It is required to provide, upon request, the current distance (in light seconds) to any peer engine in order to calculate timeout intervals.
- 需要根据请求提供到任何对等引擎的当前距离（以光秒为单位），以便计算超时间隔。
A MIB (Management Information Base) with the above parameters, updated periodically by the local data-link layer and the operating environment, should be made available to the LTP engine for its operations. The details of the MIB are, however, beyond the scope of this document.
具有上述参数的MIB（管理信息库），由本地数据链路层和操作环境定期更新，应可供LTP引擎用于其操作。但是，MIB的详细信息超出了本文档的范围。
The underlying data-link layer is required to never deliver incompletely received LTP segments to LTP. In the absence of the use of LTP authentication [LTPEXT], LTP also requires the underlying local data-link layer protocol to perform data integrity checking of the segments received. Specifically, the local data-link layer protocol is required to detect any corrupted segments received and to silently discard them.
底层数据链路层要求永远不要将未完全接收到的LTP段交付给LTP。在不使用LTP身份验证[LTPEXT]的情况下，LTP还要求底层本地数据链路层协议对接收到的段执行数据完整性检查。具体地说，需要本地数据链路层协议来检测接收到的任何损坏段并以静默方式丢弃它们。
This section describes the internal procedures that are triggered by the occurrence of various events during the lifetime of an LTP session.
本节介绍LTP会话生命周期内发生各种事件时触发的内部过程。
Whenever the content of any of the fields of the header of any received LTP segment does not conform to this specification document, the segment is assumed to be corrupt and MUST be discarded immediately and processed no further. This procedure supersedes all other procedures described below.
当任何接收到的LTP段的头的任何字段的内容不符合本规范文件时，假定该段已损坏，必须立即丢弃，不再进一步处理。本程序取代下文所述的所有其他程序。
All internal procedures described below that are triggered by the arrival of a data segment are superseded by the following procedure in the event that the client service identified by the data segment does not exist at the local LTP engine:
如果本地LTP引擎中不存在由数据段标识的客户端服务，则由数据段到达触发的以下所有内部程序将被以下程序取代：
- If there is no transmission queue-set bound for the block sender (possibly because the local LTP engine is running on a receive-only device), then the received data segment is simply discarded.
- 如果没有为块发送器绑定传输队列集（可能是因为本地LTP引擎在仅接收设备上运行），则接收到的数据段将被丢弃。
- Otherwise, if the data segment contains data from the red-part of the block, a CR with reason-code UNREACH MUST be enqueued for transmission to the block sender. A CR with reason-code UNREACH SHOULD be similarly enqueued for transmission to the data sender even if the data segment contained data from the green-part of the block; note however that (for example) in the case where the block receiver knows that the sender of this green-part data is functioning in a "beacon" (transmit-only) fashion, a CR need not be sent. In either case, the received data segment is discarded.
- 否则，如果数据段包含来自块的红色部分的数据，则必须排队等待原因码为Unrach的CR传输到块发送方。即使数据段包含来自块的绿色部分的数据，原因码为UNREACH的CR也应类似地排队传输到数据发送方；然而，注意，（例如）在块接收器知道该绿色部分数据的发送者以“信标”（仅发射）方式工作的情况下，不需要发送CR。在任何一种情况下，接收到的数据段都被丢弃。
This procedure is triggered by the arrival of a link state cue indicating the start of transmission to a specified remote LTP engine.
此过程由链路状态提示的到达触发，该提示指示开始传输到指定的远程LTP引擎。
Response: the de-queuing and delivery of segments to the LTP engine specified in the link state cue begins.
响应：开始对链路状态提示中指定的LTP引擎进行解队列和段传递。
This procedure is triggered by the arrival of a link state cue indicating the de-queuing (for transmission) of a CP segment.
此过程由链路状态提示的到达触发，该提示指示CP段的解排队（用于传输）。
Response: the expected arrival time of the RS segment that will be produced on reception of this CP segment is computed, and a countdown timer is started for this arrival time. However, if it is known that the remote LTP engine has ceased transmission (Section 6.5), then this timer is immediately suspended, because the computed expected arrival time may require an adjustment that cannot yet be computed.
响应：计算接收到此CP段时产生的RS段的预期到达时间，并为此到达时间启动倒计时。但是，如果已知远程LTP发动机已停止传输（第6.5节），则该计时器将立即暂停，因为计算的预期到达时间可能需要尚未计算的调整。
This procedure is triggered by the arrival of a link state cue indicating the de-queuing (for transmission) of an RS segment.
此过程由链路状态提示的到达触发，该提示指示RS段的解排队（用于传输）。
Response: the expected arrival time of the RA (report acknowledgment) segment in response to the reception of this RS segment is computed, and a countdown timer is started for this arrival time. However, as in Section 6.2, if it is known that the remote LTP engine has ceased transmission (Section 6.5), then this timer is immediately suspended, because the computed expected arrival time may require an adjustment that cannot yet be computed.
响应：计算响应此RS段接收的RA（报告确认）段的预期到达时间，并为此到达时间启动倒计时。但是，如第6.2节所述，如果已知远程LTP发动机已停止传输（第6.5节），则该计时器立即暂停，因为计算的预期到达时间可能需要进行尚未计算的调整。
This procedure is triggered by the arrival of a link state cue indicating the cessation of transmission to a specified remote LTP engine.
此过程由链路状态提示的到达触发，该提示指示停止向指定远程LTP引擎的传输。
Response: the de-queuing and delivery to the underlying communication system of segments from traffic queues bound for the LTP engine specified in the link state cue ceases.
响应：链路状态提示中指定的LTP引擎绑定的流量队列中的段的解队列和向底层通信系统的传送停止。
This procedure is triggered by the arrival of a link state cue indicating the cessation of transmission from a specified remote LTP engine to the local LTP engine. Normally, this event is inferred from advance knowledge of the remote engine's planned transmission schedule.
此过程由链路状态提示的到达触发，该提示指示从指定的远程LTP引擎到本地LTP引擎的传输停止。通常情况下，此事件是根据远程发动机计划传输计划的提前信息推断出来的。
Response: countdown timers for the acknowledging segments that the remote engine is expected to return are suspended as necessary based on the following procedure.
响应：根据以下程序，根据需要暂停远程发动机预期返回的确认段的倒计时计时器。
The nominal remote engine acknowledge transmission time is computed as the sum of the transmission time of the original segment (to which the acknowledging segment will respond) and the one-way light time to the remote engine, plus N seconds of "additional anticipated latency" (AAL) encompassing anticipated transmission delays other than signal propagation time. N is determined in an implementation-specific manner. For example, when LTP is deployed in deep-space vehicles, the one-way light time to the remote engine may be very large while N may be relatively small, covering processing and queuing delays. N may be a network management parameter, for which 2 seconds seems like a reasonable default value. As another example, when LTP is deployed in a terrestrial "data mule" environment, one-way light time latency is effectively zero while N may need to be some dynamically computed function of the data mule circulation schedule.
标称远程发动机确认传输时间计算为原始段（确认段将响应）的传输时间和远程发动机的单向光照时间加上N秒的“额外预期延迟”（AAL）之和包括除信号传播时间以外的预期传输延迟。N以特定于实现的方式确定。例如，当LTP部署在深空飞行器中时，远程发动机的单向光照时间可能非常长，而N可能相对较小，包括处理和排队延迟。N可能是一个网络管理参数，2秒似乎是一个合理的默认值。作为另一个示例，当LTP部署在地面“数据骡”环境中时，单向光时间延迟实际上为零，而N可能需要是数据骡循环调度的一些动态计算函数。
If the nominal remote engine acknowledge transmission time is greater than or equal to the current time (i.e., the acknowledging segment may be presented for transmission during the time that transmission at the remote engine is suspended), then the countdown timer for this acknowledging segment is suspended.
如果标称远程发动机确认传输时间大于或等于当前时间（即，在远程发动机的传输暂停期间，可能会出现确认段进行传输），则该确认段的倒计时暂停。
This procedure is triggered by the arrival of a link state cue indicating the start of transmission from a specified remote LTP engine to the local LTP engine. Normally, this event is inferred from advance knowledge of the remote engine's planned transmission schedule.
此过程由链路状态提示的到达触发，该提示指示从指定的远程LTP引擎到本地LTP引擎的传输开始。通常情况下，此事件是根据远程发动机计划传输计划的提前信息推断出来的。
Response: expected arrival time is adjusted for every acknowledging segment that the remote engine is expected to return, for which the countdown timer has been suspended. First, the transmission delay interval is calculated as follows:
响应：为远程引擎预期返回的每个确认段调整预期到达时间，其中已暂停倒计时。首先，传输延迟间隔计算如下：
- The nominal remote engine acknowledge transmission time is computed as the sum of the transmission time of the original segment (to which the acknowledging segment will respond) and the one-way light time to the remote engine, plus N seconds of AAL Section 6.5.
- 标称远程发动机确认传输时间计算为原始段（确认段将响应）的传输时间和远程发动机的单向光照时间加上AAL第6.5节中N秒的总和。
- If the nominal remote engine acknowledge transmission time is greater than the current time, i.e., the remote engine resumed transmission prior to presentation of the acknowledging segment for transmission, then the transmission delay interval is zero.
- 如果标称远程发动机确认传输时间大于当前时间，即远程发动机在传输确认段出现之前恢复传输，则传输延迟间隔为零。
- Otherwise, the transmission delay interval is computed as the current time less the nominal remote engine acknowledge transmission time.
- 否则，传输延迟间隔计算为当前时间减去标称远程发动机确认传输时间。
The expected arrival time is increased by the computed transmission delay interval for each of the suspended countdown timers, and the timers are resumed.
对于每个挂起的倒计时计时器，预期到达时间增加计算的传输延迟间隔，并且计时器恢复。
This procedure is triggered by the expiration of a countdown timer associated with a CP segment.
此过程由与CP段相关的倒计时计时器过期触发。
Response: if the number of times this CP segment has been queued for transmission exceeds the checkpoint retransmission limit established for the local LTP engine by network management, then the session of which the segment is one token is canceled: the "Cancel Session" procedure (Section 6.19) is invoked, a CS with reason-code RLEXC is appended to the (conceptual) application data queue, and a transmission-session cancellation notice (Section 7.5) is sent back to the client service that requested the transmission.
响应：如果此CP段排队等待传输的次数超过网络管理为本地LTP引擎建立的检查点重传限制，则取消该段为一个令牌的会话：调用“取消会话”过程（第6.19节），将带有原因码RLEXC的CS附加到（概念）应用程序数据队列，并将传输会话取消通知（第7.5节）发送回请求传输的客户端服务。
Otherwise, a new copy of the CP segment is appended to the (conceptual) application data queue for the destination LTP engine.
否则，CP段的新副本将附加到目标LTP引擎的（概念）应用程序数据队列中。
This procedure is triggered by either (a) the expiration of a countdown timer associated with an RS segment or (b) the reception of a CP segment for which one or more RS segments were previously issued -- a redundantly retransmitted checkpoint.
此过程由（a）与RS段相关的倒计时计时器过期或（b）接收到之前已发出一个或多个RS段的CP段（冗余重传检查点）触发。
Response: if the number of times any affected RS segment has been queued for transmission exceeds the report retransmission limit established for the local LTP engine by network management, then the session of which the segment is one token is canceled: the "Cancel Session" procedure (Section 6.19) is invoked, a CR segment with
响应：如果任何受影响的RS段排队等待传输的次数超过网络管理为本地LTP引擎建立的报告重传限制，则取消该段为一个令牌的会话：调用“取消会话”过程（第6.19节），使用
reason-code RLEXC is queued for transmission to the LTP engine that originated the session, and a reception-session cancellation notice (Section 7.6) is sent to the client service identified in each of the data segments received in this session.
原因码RLEXC排队等待发送到发起会话的LTP引擎，接收会话取消通知（第7.6节）发送到在此会话中接收的每个数据段中标识的客户端服务。
Otherwise, a new copy of each affected RS segment is queued for transmission to the LTP engine that originated the session.
否则，每个受影响RS段的新副本将排队等待传输到发起会话的LTP引擎。
This procedure is triggered by the arrival of a CP segment when the EORP for this session has been received (ensuring that the size of the data block's red-part is known; this includes the case where the CP segment itself is the EORP segment) and all data in the red-part of the block being transmitted in this session have been received.
当接收到该会话的EORP（确保数据块红色部分的大小已知；这包括CP段本身是EORP段的情况）并且在该会话中传输的块的红色部分中的所有数据都已接收到时，CP段的到达会触发该过程。
Response: a red-part reception notice (Section 7.3) is sent to the specified client service.
响应：红色部分接收通知（第7.3节）发送至指定的客户服务。
This procedure is triggered by the arrival of a data segment whose content is a portion of the green-part of a block.
此过程由数据段的到达触发，该数据段的内容是块绿色部分的一部分。
Response: a green-part segment arrival notice (Section 7.2) is sent to the specified client service.
响应：绿色零件段到达通知（第7.2节）发送至指定的客户服务。
This procedure is triggered by either (a) the original reception of a CP segment (the checkpoint serial number identifying this CP is new) (b) an implementation-specific circumstance pertaining to a particular block reception session for which no EORP has yet been received ("asynchronous" reception reporting).
该过程由（a）CP段的原始接收（识别该CP的检查点序列号是新的）（b）与尚未接收到EORP的特定块接收会话相关的实施特定情况（“异步”接收报告）触发。
Response: if the number of reception problems detected for this session exceeds a limit established for the local LTP engine by network management, then the affected session is canceled: the "Cancel Session" procedure (Section 6.19) is invoked, a CR segment with reason-code RLEXC is issued and is, in concept, appended to the queue of internal operations traffic bound for the LTP engine that originated the session, and a reception-session cancellation notice (Section 7.6) is sent to the client service identified in each of the data segments received in this session. One possible limit on reception problems would be the maximum number of reception reports that can be issued for any single session.
响应：如果此会话检测到的接收问题数量超过网络管理为本地LTP引擎确定的限制，则取消受影响的会话：调用“取消会话”过程（第6.19节），发出原因代码为RLEXC的CR段，从概念上讲，附加到发起会话的LTP引擎绑定的内部操作流量队列，并将接收会话取消通知（第7.6节）发送到在此会话中接收的每个数据段中标识的客户端服务。接收问题的一个可能限制是任何单个会话可以发布的接收报告的最大数量。
If such a limit is not reached, a reception report is issued as follows.
如果未达到此限值，将发布如下接收报告。
If production of the reception report was triggered by reception of a checkpoint:
如果接收检查点触发了接收报告的生成：
- The upper bound of the report SHOULD be the upper bound (the sum of the offset and length) of the checkpoint data segment, to minimize unnecessary retransmission. Note: If a discretionary checkpoint is lost but subsequent segments are received, then by the time the retransmission of the lost checkpoint is received the receiver would have segments at block offsets beyond the upper bound of the checkpoint. For deployments where bandwidth economy is not critical, the upper bound of a synchronous reception report MAY be the maximum upper bound value among all red-part data segments received so far in the affected session.
- 报告的上限应为检查点数据段的上限（偏移量和长度之和），以最小化不必要的重新传输。注意：如果一个任意检查点丢失，但随后的段被接收到，那么在接收到丢失的检查点的重传时，接收器的段的块偏移量将超过检查点的上限。对于带宽经济性不重要的部署，同步接收报告的上限可能是受影响会话中迄今为止接收到的所有红色部分数据段中的最大上限值。
- If the checkpoint was itself issued in response to a report segment, then this report is a "secondary" reception report. In that case, the lower bound of the report SHOULD be the lower bound of the report segment to which the triggering checkpoint was itself a response, to minimize unnecessary retransmission. Note: For deployments where bandwidth economy is not critical, the lower bound of the report MAY instead be zero.
- 如果检查点本身是响应报告段发出的，则此报告是“次要”接收报告。在这种情况下，报告的下限应该是触发检查点本身是响应的报告段的下限，以最小化不必要的重新传输。注意：对于带宽经济性不重要的部署，报告的下限可能为零。
- If the checkpoint was not issued in response to a report segment, this report is a "primary" reception report. The lower bound of the first primary reception report issued for any session MUST be zero. The lower bound of each subsequent primary reception report issued for the same session SHOULD be the upper bound of the prior primary reception report issued for the session, to minimize unnecessary retransmission. Note: For deployments where bandwidth economy is not critical, the lower bound of every primary reception report MAY be zero.
- 如果检查点不是响应报告段发出的，则此报告是“主要”接收报告。为任何会话发布的第一个主接收报告的下限必须为零。为同一会话发布的每个后续主接收报告的下界应为为该会话发布的先前主接收报告的上界，以最小化不必要的重传。注意：对于带宽经济性不重要的部署，每个主接收报告的下限可能为零。
If production of the reception report is "asynchronous" as noted above:
如果接收报告的生成如上所述为“异步”：
- The upper bound of the report MUST be the maximum upper bound among all red-part data segments received so far for this session.
- 报告的上限必须是该会话迄今为止收到的所有红色零件数据段的最大上限。
- The lower bound of the first asynchronous reception report issued for any session for which no other primary reception reports have yet been issued MUST be zero. The lower bound of each subsequent asynchronous reception report SHOULD be the upper bound of the prior primary reception report issued for the
- 为尚未发布其他主接收报告的任何会话发布的第一个异步接收报告的下限必须为零。每个后续异步接收报告的下界应为为该系统发布的先前主接收报告的上界
session, to minimize unnecessary retransmission. Note: For deployments where bandwidth economy is not critical, the lower bound of every asynchronous reception report MAY be zero.
会话，以尽量减少不必要的重新传输。注意：对于带宽经济性不重要的部署，每个异步接收报告的下限可能为零。
In all cases, if the applicable lower bound of the scope of a report is determined to be greater than or equal to the applicable upper bound (for example, due to out-of-order arrival of discretionary checkpoints) then the reception report MUST NOT be issued. Otherwise:
在所有情况下，如果确定报告范围的适用下限大于或等于适用上限（例如，由于任意检查点的无序到达），则不得发布接收报告。否则：
As many RS segments must be produced as are needed in order to report on all data reception within the scope of the report, given whatever data size constraints are imposed by the underlying communication service. The RS segments are, in concept, appended to the queue of internal operations traffic bound for the LTP engine that originated the indicated session. The lower bound of the first RS segment of the report MUST be the reception report's lower bound. The upper bound of the last RS segment of the report MUST be the reception report's upper bound.
鉴于基础通信服务施加的数据大小限制，为了报告报告范围内的所有数据接收，必须根据需要生成尽可能多的RS段。在概念上，RS段附加到发起所指示会话的LTP引擎的内部操作通信量绑定队列。报告的第一个RS段的下限必须是接收报告的下限。报告最后一个RS段的上限必须是接收报告的上限。
This procedure is triggered at the earliest time at which (a) all data in the block are known to have been transmitted *and* (b) the entire red-part of the block -- if of non-zero length -- is known to have been successfully received. Condition (a) is signaled by arrival of a link state cue indicating the de-queuing (for transmission) of the EOB segment for the block. Condition (b) is signaled by reception of an RS segment whose reception claims, taken together with the reception claims of all other RS segments previously received in the course of this session, indicate complete reception of the red-part of the block.
该过程在（a）已知块中的所有数据已发送*和*（b）已知块的整个红色部分（如果长度非零）已成功接收的最早时间触发。条件（a）通过链路状态提示的到达发出信号，该链路状态提示指示块的EOB段的解排队（用于传输）。条件（b）通过接收一个RS段发出信号，该RS段的接收声明与之前在该会话过程中接收到的所有其他RS段的接收声明一起表示完全接收到块的红色部分。
Response: a transmission-session completion notice (Section 7.4) is sent to the local client service associated with the session, and the session is closed: the "Close Session" procedure (Section 6.20) is invoked.
响应：传输会话完成通知（第7.4节）被发送到与会话相关联的本地客户端服务，并且会话被关闭：调用“关闭会话”过程（第6.20节）。
This procedure is triggered by the reception of an RS segment.
此程序由接收RS段触发。
Response: first, an RA segment with the same report serial number as the RS segment is issued and is, in concept, appended to the queue of internal operations traffic bound for the receiver. If the RS segment is redundant -- i.e., either the indicated session is unknown (for example, the RS segment is received after the session has been completed or canceled) or the RS segment's report serial number
响应：首先，发出与RS段具有相同报告序列号的RA段，并且在概念上，附加到为接收方绑定的内部操作流量队列。如果RS段是冗余的——即，指示的会话未知（例如，在会话完成或取消后接收RS段）或RS段的报告序列号
matches that of an RS segment that has already been received and processed -- then no further action is taken. Otherwise, the procedure below is followed.
匹配已经接收和处理的RS段的数据，则不采取进一步的操作。否则，请遵循以下步骤。
If the report's checkpoint serial number is not zero, then the countdown timer associated with the indicated checkpoint segment is deleted.
如果报告的检查点序列号不为零，则与指示的检查点段关联的倒计时计时器将被删除。
Note: All retransmission buffer space occupied by data whose reception is claimed in the report segment can (in concept) be released.
注：报告段中声明接收的数据占用的所有重传缓冲区空间（概念上）都可以释放。
If the segment's reception claims indicate incomplete data reception within the scope of the report segment:
如果分部的接收声明表明报告分部范围内的数据接收不完整：
- If the number of transmission problems for this session exceeds a limit established for the local LTP engine by network management, then the session of which the segment is one token is canceled: the "Cancel Session" procedure (Section 6.19) is invoked, a CS with reason-code RLEXC is appended to the transmission queue specified in the transmission request that started this session, and a transmission-session cancellation notice (Section 7.5) is sent back to the client service that requested the transmission. One possible limit on transmission problems would be the maximum number of retransmission CP segments that may be issued for any single session.
- 如果此会话的传输问题数量超过网络管理为本地LTP引擎设定的限制，则取消该段为一个令牌的会话：调用“取消会话”过程（第6.19节），将带有原因码RLEXC的CS附加到启动此会话的传输请求中指定的传输队列，并将传输会话取消通知（第7.5节）发送回请求传输的客户端服务。传输问题的一个可能限制是为任何单个会话发出的最大重发CP段数。
- If the number of transmission problems for this session has not exceeded any limit, new data segments encapsulating all block data whose non-reception is implied by the reception claims are appended to the transmission queue bound for the receiver. The last -- and only the last -- data segment must be marked as a CP segment carrying a new CP serial number (obtained by incrementing the last CP serial number used) and the report serial number of the received RS segment.
- 如果该会话的传输问题的数量没有超过任何限制，则将封装接收声明暗示其未接收的所有块数据的新数据段附加到为接收器绑定的传输队列。最后一个（且仅最后一个）数据段必须标记为CP段，其中包含新的CP序列号（通过增加使用的最后一个CP序列号获得）和所接收RS段的报告序列号。
This procedure is triggered by the reception of an RA.
此程序由接收到RA触发。
Response: the countdown timer associated with the original RS segment (identified by the report serial number of the RA segment) is deleted. If no other countdown timers associated with RS segments exist for this session, then the session is closed: the "Close Session" procedure (Section 6.20) is invoked.
响应：删除与原始RS段相关的倒计时计时器（由RA段的报告序列号标识）。如果该会话不存在与RS段相关的其他倒计时计时器，则该会话关闭：调用“关闭会话”过程（第6.20节）。
This procedure is triggered by arrival of a link state cue indicating the de-queuing (for transmission) of a Cx segment.
此过程由链路状态提示的到达触发，该提示指示Cx段的解排队（用于传输）。
Response: the expected arrival time of the CAx segment that will be produced on reception of this Cx segment is computed and a countdown timer for this arrival time is started. However, if it is known that the remote LTP engine has ceased transmission (Section 6.5), then this timer is immediately suspended, because the computed expected arrival time may require an adjustment that cannot yet be computed.
响应：计算接收此Cx段时产生的CAx段的预期到达时间，并启动此到达时间的倒计时。但是，如果已知远程LTP发动机已停止传输（第6.5节），则该计时器将立即暂停，因为计算的预期到达时间可能需要尚未计算的调整。
This procedure is triggered by the expiration of a countdown timer associated with a Cx segment.
此过程由与Cx段关联的倒计时计时器过期触发。
Response: if the number of times this Cx segment has been queued for transmission exceeds the cancellation retransmission limit established for the local LTP engine by network management, then the session of which the segment is one token is simply closed: the "Close Session" procedure (Section 6.20) is invoked.
响应：如果此Cx段排队等待传输的次数超过网络管理为本地LTP引擎建立的取消重传限制，则该段为一个令牌的会话将简单关闭：调用“关闭会话”过程（第6.20节）。
Otherwise, a copy of the cancellation segment (retaining the same reason-code) is queued for transmission to the appropriate LTP engine.
否则，取消段的副本（保留相同的原因代码）将排队等待传输到相应的LTP引擎。
This procedure is triggered by the reception of a Cx segment.
此过程由接收Cx段触发。
Response: in the case of a CS segment where there is no transmission queue-set bound for the sender (possibly because the receiver is a receive-only device), then no action is taken. Otherwise:
响应：如果CS段没有为发送方设置传输队列（可能是因为接收方是仅接收设备），则不采取任何操作。否则：
- If the received segment is a CS segment, a CAS (cancel acknowledgment to block sender) segment is issued and is, in concept, appended to the queue of internal operations traffic bound for the sender.
- 如果接收到的段是CS段，则会发出CAS（取消对阻止发送方的确认）段，并在概念上附加到为发送方绑定的内部操作流量队列中。
- If the received segment is a CR segment, a CAR (cancel acknowledgment to block receiver) segment is issued and is, in concept, appended to the queue of internal operations traffic bound for the receiver.
- 如果接收到的段是CR段，则发出CAR（取消对块接收器的确认）段，并且在概念上附加到为接收器绑定的内部操作通信量队列。
It is possible that the Cx segment has been retransmitted because a previous responding acknowledgment CAx (cancel acknowledgment) segment was lost, in which case there will no longer be any record of the session of which the segment is one token. If so, no further action is taken.
Cx段可能因为先前的响应确认CAx（取消确认）段丢失而被重新传输，在这种情况下，将不再存在该段为一个令牌的会话记录。如果是，则不采取进一步行动。
Otherwise: the "Cancel Session" procedure (Section 6.19) is invoked and a reception-session cancellation notice (Section 7.6) is sent to the client service identified in each of the data segments received in this session. Finally, the session is closed: the "Close Session" procedure (Section 6.20) is invoked.
否则：将调用“取消会话”过程（第6.19节），并将接收会话取消通知（第7.6节）发送给在此会话中接收的每个数据段中标识的客户端服务。最后，会话关闭：调用“关闭会话”过程（第6.20节）。
This procedure is triggered by the reception of a CAx segment.
此程序由接收CAx段触发。
Response: the timer associated with the Cx segment is deleted, and the session of which the segment is one token is closed, i.e., the "Close Session" procedure (Section 6.20) is invoked.
响应：删除与Cx段关联的计时器，并关闭该段为一个令牌的会话，即调用“关闭会话”过程（第6.20节）。
This procedure is triggered internally by one of the other procedures described above.
该程序由上述其他程序之一在内部触发。
Response: all segments of the affected session that are currently queued for transmission can be deleted from the outbound traffic queues. All countdown timers currently associated with the session are deleted. Note: If the local LTP engine is the sender, then all remaining data retransmission buffer space allocated to the session can be released.
响应：可以从出站流量队列中删除当前排队等待传输的受影响会话的所有段。将删除当前与会话关联的所有倒计时计时器。注意：如果本地LTP引擎是发送方，则可以释放分配给会话的所有剩余数据重传缓冲区空间。
This procedure is triggered internally by one of the other procedures described above.
该程序由上述其他程序之一在内部触发。
Response: any remaining countdown timers associated with the session are deleted. The session state record (SSR|RSR) for the session is deleted; existence of the session is no longer recognized.
响应：将删除与会话关联的所有剩余倒计时计时器。删除会话的会话状态记录（SSR | RSR）；不再承认会话的存在。
This procedure is triggered by the arrival of either (a) a red-part data segment whose block offset begins at an offset higher than the block offset of any green-part data segment previously received for the same session or (b) a green-part data segment whose block offset is lower than the block offset of any red-part data segment
此过程由以下两种情况触发：（a）块偏移开始的红色零件数据段的偏移量高于之前为同一会话接收的任何绿色零件数据段的块偏移量，或（b）块偏移量低于任何红色零件数据段的块偏移量的绿色零件数据段
previously received for the same session. The arrival of a segment matching either of the above checks is a violation of the protocol requirement of having all red-part data as the block prefix and all green-part data as the block suffix.
以前为同一届会议收到的。与上述任一检查匹配的段的到达违反了将所有红色部分数据作为块前缀，将所有绿色部分数据作为块后缀的协议要求。
Response: the received data segment is simply discarded.
响应：接收到的数据段被丢弃。
The Cancel Session procedure (Section 6.19) is invoked and a CR segment with reason-code MISCOLORED SHOULD be enqueued for transmission to the data sender.
调用取消会话过程（第6.19节），并且应将原因代码为MISCOLED的CR段排队，以便传输到数据发送方。
Note: If there is no transmission queue-set bound for the sender (possibly because the local LTP engine is running on a receive-only device), or if the receiver knows that the sender is functioning in a "beacon" (transmit-only) fashion, a CR segment need not be sent.
注意：如果没有为发送方设置传输队列绑定（可能是因为本地LTP引擎在仅接收设备上运行），或者如果接收方知道发送方以“信标”（仅传输）方式工作，则不需要发送CR段。
A reception-session cancellation notice (Section 7.6) is sent to the client service.
接收会话取消通知（第7.6节）发送至客户服务。
It is possible (especially for long-lived LTP sessions) that an unexpected operating system error condition may occur during the lifetime of an LTP session. An example is the case where the system faces severe memory crunch forcing LTP sessions into a scenario similar to that of TCP SACK [SACK] reneging. But unlike TCP SACK reception reports, which are advisory, LTP reception reports are binding, and reneging is NOT permitted on previously made reception claims.
在LTP会话的生存期内，可能会发生意外的操作系统错误情况（特别是对于长寿命的LTP会话）。例如，系统面临严重的内存不足，迫使LTP会话进入类似于TCP SACK[SACK]退出的场景。但与TCP SACK接收报告不同，后者是咨询性的，LTP接收报告具有约束力，并且不允许对之前提出的接收声明进行反悔。
Under any such irrecoverable system error condition, the following response is to be initiated: the Cancel Session procedure (Section 6.19) is invoked. If the error condition is observed on the sender, a CS segment with reason-code SYS_CNCLD SHOULD be enqueued for transmission to the receiver, and a transmission-session cancellation notice (Section 7.5) is sent to the client service; on the other hand, if it is observed on the receiver, a CR segment with the same reason-code SYS_CNCLD SHOULD be enqueued for transmission to the sender, and a reception-session cancellation notice (Section 7.6) is sent to the client service.
在任何此类不可恢复的系统错误情况下，将启动以下响应：调用取消会话过程（第6.19节）。如果在发送方上观察到错误情况，则应将带有原因码SYS_CNCLD的CS段排队，以便传输到接收方，并向客户端服务发送传输会话取消通知（第7.5节）；另一方面，如果在接收器上观察到，则具有相同原因码SYS_CNCLD的CR段应排队传输给发送方，并向客户端服务发送接收会话取消通知（第7.6节）。
Note that as in (Section 6.21), if there is no transmission queue-set bound for the sender (possibly because the local LTP engine is running on a receive-only device), or if the receiver knows that the sender of this green-part data is functioning in a "beacon" (transmit-only) fashion, a CR segment need not be sent.
注意，如（第6.21节）中所述，如果没有为发送方设置传输队列绑定（可能是因为本地LTP引擎在仅接收设备上运行），或者如果接收方知道此绿色部分数据的发送方以“信标”（仅发送）方式运行，则无需发送CR段。
There may be other implementation-specific limits that may cause an LTP implementation to initiate session-cancellation procedures. One such limit is the maximum number of retransmission-cycles seen. A retransmission cycle at the LTP Sender comprises the two related events: the transmission of all outstanding CP segments from the sender, and the reception of all RS segments issued from the receiver in response to those CP segments. A similar definition would apply at the LTP Receiver but relate to the reception of the CP segments and transmission of all RS segments in response. Note that the retransmitted CP and RS segments remain part of their original retransmission-cycle. Also, a single CP segment may cause multiple RS segments to be generated if a reception report would not fit in a single data link-MTU-sized RS segment; all RS segments that are part of a reception report belong to the same retransmission cycle to which the CP segment belongs. In the presence of severe channel error conditions, many retransmission cycles may elapse before red-part transmission is deemed successful; an implementation may therefore impose a retransmission-cycle limit to shield itself from a resource-crunch situation. If an LTP sender notices the retransmission-cycle limit being exceeded, it SHOULD initiate the Cancel Session procedure (Section 6.19), queuing a CS segment with reason-code RXMTCYCEXC and sending a transmission-session cancellation notice (Section 7.5) to the client service.
可能存在其他特定于实现的限制，这些限制可能导致LTP实现启动会话取消过程。其中一个限制是所看到的最大重传周期数。LTP发送方处的重传周期包括两个相关事件：来自发送方的所有未完成CP段的传输，以及响应于这些CP段而从接收方发出的所有RS段的接收。类似的定义将适用于LTP接收机，但与CP段的接收和所有RS段的传输相关。注意，重传的CP和RS段仍然是其原始重传周期的一部分。此外，如果接收报告不适合单个数据链路MTU大小的RS段，则单个CP段可能导致生成多个RS段；作为接收报告一部分的所有RS段都属于CP段所属的相同重传周期。在存在严重信道错误的情况下，在红色部分传输被视为成功之前，可能经过许多重传周期；因此，一个实现可能会施加一个重传周期限制，以保护自己不受资源短缺情况的影响。如果LTP发送方注意到已超过重传周期限制，则应启动取消会话程序（第6.19节），将CS段与原因码RXMTCYCEXC排队，并向客户端服务发送传输会话取消通知（第7.5节）。
In all cases, the representation of notice parameters is a local implementation matter.
在所有情况下，通知参数的表示都是本地实现问题。
The Session Start notice returns the session ID identifying a newly created session.
会话开始通知返回标识新创建会话的会话ID。
At the sender, the session start notice informs the client service of the initiation of the transmission session. On receiving this notice the client service may, for example, release resources of its own that are allocated to the block being transmitted, or remember the session ID so that the session can be canceled in the future if necessary. At the receiver, this notice indicates the beginning of a new reception session, and is delivered upon arrival of the first data segment carrying a new session ID.
在发送方，会话开始通知通知客户端服务传输会话的启动。在接收到该通知时，客户机服务例如可以释放分配给正在传输的块的其自己的资源，或者记住会话ID，以便在必要时可以在将来取消会话。在接收器处，该通知指示新接收会话的开始，并且在携带新会话ID的第一数据段到达时递送。
The following parameters are provided by the LTP engine when a green-part segment arrival notice is delivered:
交付绿色零件段到达通知时，LTP引擎提供以下参数：
Session ID of the transmission session.
传输会话的会话ID。
Array of client service data bytes contained in the data segment.
数据段中包含的客户端服务数据字节数组。
Offset of the data segment's content from the start of the block.
数据段内容相对于块起点的偏移量。
Length of the data segment's content.
数据段内容的长度。
Indication as to whether or not the last byte of this data segment's content is also the end of the block.
指示此数据段内容的最后一个字节是否也是块的结尾。
Source LTP engine ID.
源LTP引擎ID。
The following parameters are provided by the LTP engine when a red-part reception notice is delivered:
发送红色零件接收通知时，LTP引擎提供以下参数：
Session ID of the transmission session.
传输会话的会话ID。
Array of client service data bytes that constitute the red-part of the block.
构成块红色部分的客户端服务数据字节数组。
Length of the red-part of the block.
块的红色部分的长度。
Indication as to whether or not the last byte of the red-part is also the end of the block.
指示红色部分的最后一个字节是否也是块的结尾。
Source LTP engine ID.
源LTP引擎ID。
The sole parameter provided by the LTP engine when a transmission-session completion notice is delivered is the session ID of the transmission session.
发送传输会话完成通知时，LTP引擎提供的唯一参数是传输会话的会话ID。
A transmission-session completion notice informs the client service that all bytes of the indicated data block have been transmitted and that the receiver has received the red-part of the block.
传输会话完成通知通知客户端服务所指示的数据块的所有字节都已发送，并且接收机已接收到块的红色部分。
The parameters provided by the LTP engine when a transmission-session cancellation notice is delivered are:
发送传输会话取消通知时，LTP引擎提供的参数为：
Session ID of the transmission session.
传输会话的会话ID。
The reason-code sent or received in the Cx segment that initiated the cancellation sequence.
在启动取消序列的Cx段中发送或接收的原因码。
A transmission-session cancellation notice informs the client service that the indicated session was terminated, either by the receiver or else due to an error or a resource quench condition in the local LTP engine. There is no assurance that the destination client service instance received any portion of the data block.
传输会话取消通知通知客户机服务所指示的会话已被终止，该终止可能是由于接收方的原因，也可能是由于本地LTP引擎中的错误或资源熄灭情况。无法保证目标客户端服务实例接收到数据块的任何部分。
The parameters provided by the LTP engine when a reception cancellation notice is delivered are:
发送接收取消通知时，LTP引擎提供的参数为：
Session ID of the transmission session.
传输会话的会话ID。
The reason-code explaining the cancellation.
解释取消的原因代码。
A reception-session cancellation notice informs the client service that the indicated session was terminated, either by the sender or else due to an error or a resource quench condition in the local LTP engine. No subsequent delivery notices will be issued for this session.
接收会话取消通知通知客户端服务所指示的会话已被终止，这可能是由于发送方的原因，也可能是由于本地LTP引擎中的错误或资源中断情况。本次会议将不再发布后续交付通知。
The session ID of the transmission session is included with the initial-transmission completion notice.
传输会话的会话ID包括在初始传输完成通知中。
This notice informs the client service that all segments of a block (both red-part and green-part) have been transmitted. This notice only indicates that original transmission is complete; retransmission of any lost red-part data segments may still be necessary.
此通知通知客户端服务块的所有段（红色部分和绿色部分）都已传输。此通知仅表示原始传输已完成；可能仍然需要重新传输任何丢失的红色部件数据段。
The following mnemonics have been used in the sender and LTP receiver state transition diagrams that follow:
以下助记符已在以下发送方和LTP接收方状态转换图中使用：
TE Timer Expiry RDS Regular Red Data Segment (NOT {CP|EORP|EOB}) GDS Regular Green Data Segment (NOT EOB) RL EXC Retransmission Limit Exceeded RP Red-Part GP Green-Part FG Fully-Green
TE定时器到期RDS常规红色数据段（非{CP | EORP | EOB}）GDS常规绿色数据段（非EOB）RL EXC重传限制超过RP红色部分GP绿色部分FG完全绿色
Note that blocks represented in rectangles, as in
请注意，块以矩形表示，如中所示
+---------+
| FG_XMIT |
+---------+
+---------+
| FG_XMIT |
+---------+
specify actual states in the state-transition diagrams, while blocks represented with jagged edges, as in
在状态转换图中指定实际状态，而块用锯齿边表示，如中所示
/\/\/\/\
| Cncld |
\/\/\/\/
/\/\/\/\
| Cncld |
\/\/\/\/
are either pointers to a state or place-holders for sequences of state transitions.
是指向状态的指针或状态转换序列的占位符。
8.1. Sender LTP Sender State Transition Diagram
8.1. 发送方LTP发送方状态转换图
/\/\/\/\
| Cncld |
\/\/\/\/
+--------+ | +------+
Rcv CR; | V V V | Rcv RS;
Snd CAR | +-------------+ | Snd RA
+-------+ CLOSED +----+
+---------------------------->+------+------+
| | Blk. Trans. Req
| Zero RP +
| Xmit ________________________/ \ Non-Zero RP
| GDS; / \
| +---+ | +------------------+ | +------+
| | V V | /\/\ Rcv RS V V V |
| | +---------+ +<-| RX |<---+ +---------+ |
| +<-+ FG_XMIT | | \/\/ +---+ +--->+ Xmit RDS;
| +----+----+ | | RP_XMIT | |
| | | /\/\ +---+ +--->+ Xmit {RDS, CP};
+<--------+ +<-| CP |<---+ +-----+---+ Start CP Tmr
| Xmit \/\/ CP TE | \
| {GDS, EOB}; | |
| Xmit {RDS, CP, EORP}; | +-------+
| Start CP Tmr | |
| | |
| +------------------+ | +---+ | Xmit {RDS,
| | /\/\ Rcv RS V V V | | CP, EORP,
| +<-| RX |<---+ +---------+ | | EOB};
| | \/\/ +---+ | | | Start
| | | GP_XMIT +->+ | CP Tmr
| | /\/\ +---+ | Xmit |
| +<-| CP |<---+ +-----+---+ GDS; |
| \/\/ CP TE | |
| | |
| Xmit {GDS, EOB}; | +---------+
| | |
| +------------------+ | |
| | /\/\ Rcv RS V V V
| +<-| RX |<---+ +-------------+
| | \/\/ +---+ |
| | | WAIT_RP_ACK |
| | /\/\ +---+ |
| +<-| CP |<---+ +-----+-------+
| \/\/ CP TE | RP acknowledged fully;
| V
+----------------------------------------+
/\/\/\/\
| Cncld |
\/\/\/\/
+--------+ | +------+
Rcv CR; | V V V | Rcv RS;
Snd CAR | +-------------+ | Snd RA
+-------+ CLOSED +----+
+---------------------------->+------+------+
| | Blk. Trans. Req
| Zero RP +
| Xmit ________________________/ \ Non-Zero RP
| GDS; / \
| +---+ | +------------------+ | +------+
| | V V | /\/\ Rcv RS V V V |
| | +---------+ +<-| RX |<---+ +---------+ |
| +<-+ FG_XMIT | | \/\/ +---+ +--->+ Xmit RDS;
| +----+----+ | | RP_XMIT | |
| | | /\/\ +---+ +--->+ Xmit {RDS, CP};
+<--------+ +<-| CP |<---+ +-----+---+ Start CP Tmr
| Xmit \/\/ CP TE | \
| {GDS, EOB}; | |
| Xmit {RDS, CP, EORP}; | +-------+
| Start CP Tmr | |
| | |
| +------------------+ | +---+ | Xmit {RDS,
| | /\/\ Rcv RS V V V | | CP, EORP,
| +<-| RX |<---+ +---------+ | | EOB};
| | \/\/ +---+ | | | Start
| | | GP_XMIT +->+ | CP Tmr
| | /\/\ +---+ | Xmit |
| +<-| CP |<---+ +-----+---+ GDS; |
| \/\/ CP TE | |
| | |
| Xmit {GDS, EOB}; | +---------+
| | |
| +------------------+ | |
| | /\/\ Rcv RS V V V
| +<-| RX |<---+ +-------------+
| | \/\/ +---+ |
| | | WAIT_RP_ACK |
| | /\/\ +---+ |
| +<-| CP |<---+ +-----+-------+
| \/\/ CP TE | RP acknowledged fully;
| V
+----------------------------------------+
LTP Sender State Transition Diagram (contd.)
LTP发送方状态转换图（续）
/\/\ /\/\
|CP| |CX |
\/\/ \/\/
| | | Snd CS,
| | RL EXC; | Start CS Tmr;
| | |
| | /\/\ | +---+
| +------>| CX | V V |
| \/\/ +---------+ | CS TE,
| | CS_SENT | | RL NOT EXC;
V RL NOT EXC; +-+--+--+-+ | Rxmt CS,
Rxmt CP, | | | | Restart
Start CP Tmr; CS TE, | | +---+ CS Tmr
RL EXC; | |
| | Rcv CAS;
V V
/\/\/\/\
| Cncld |
\/\/\/\/
/\/\ /\/\
|CP| |CX |
\/\/ \/\/
| | | Snd CS,
| | RL EXC; | Start CS Tmr;
| | |
| | /\/\ | +---+
| +------>| CX | V V |
| \/\/ +---------+ | CS TE,
| | CS_SENT | | RL NOT EXC;
V RL NOT EXC; +-+--+--+-+ | Rxmt CS,
Rxmt CP, | | | | Restart
Start CP Tmr; CS TE, | | +---+ CS Tmr
RL EXC; | |
| | Rcv CAS;
V V
/\/\/\/\
| Cncld |
\/\/\/\/
/\/\
| RX |
\/\/
| Cncl CP Tmr (if any)
V Snd RA
+---------+ +----+
| CHK_RPT | | |
+-+--+----+ RP in scope V |
| | \ NOT rcvd. fully +---------+ | Rxmt
Redundant | | RP +--------------------->| RP_RXMT | | missing
RS rcvd; | | in scope +----+--+-+ | RDS;
| | rcvd. fully | | |
V V Rxmt last | +----+
missing RDS |
(marked CP) |
Start CP Tmr; |
V
/\/\
| RX |
\/\/
| Cncl CP Tmr (if any)
V Snd RA
+---------+ +----+
| CHK_RPT | | |
+-+--+----+ RP in scope V |
| | \ NOT rcvd. fully +---------+ | Rxmt
Redundant | | RP +--------------------->| RP_RXMT | | missing
RS rcvd; | | in scope +----+--+-+ | RDS;
| | rcvd. fully | | |
V V Rxmt last | +----+
missing RDS |
(marked CP) |
Start CP Tmr; |
V
Asynchronous cancel request may be received from the local client service while the LTP sender is in any of the states shown. If it was not already in the sequence of state transitions beginning at the CX marker, the internal procedure Cancel Session (Section 6.19) is followed, and the LTP sender moves from its current state into the sequence beginning at the CX marker initiating session cancellation with reason-code USR_CNCLD. From the CX marker, the CS segment with appropriate reason-code (USR_CNCLD or RLEXC depending on how the CX
当LTP发送方处于所示的任何状态时，可以从本地客户端服务接收异步取消请求。如果它尚未处于从CX标记开始的状态转换序列中，则遵循内部过程取消会话（第6.19节），LTP发送方从其当前状态移动到从CX标记开始的序列中，启动会话取消，原因代码为USR_CNCLD。从CX标记中，选择具有适当原因代码的CS段（USR_CNCLD或RLEXC，具体取决于CX
sequence was entered) is queued for transmission to the LTP receiver and the sender enters the Cancel-from-Sender Sent (CS_SENT) state. The internal procedure Start Cancel Timer (Section 6.15) is started upon receiving a link state cue indicating the beginning of transmission of the CS segment. Upon receiving the acknowledging CAS segment from the receiver, the LTP sender moves to the CLOSED state (via the 'Cncld' pointer). If the CS timer expires, the internal procedure Retransmit Cancellation Segment (Section 6.16) is followed:
序列（已输入）排队等待传输到LTP接收器，发送方进入从发送方发送的取消（CS_发送）状态。内部程序启动-取消计时器（第6.15节）在收到指示CS段传输开始的链路状态提示后启动。在接收到来自接收器的确认CAS段后，LTP发送器移动到关闭状态（通过“Cncld”指针）。如果CS定时器过期，则遵循内部程序重传取消段（第6.16节）：
- If the network management set retransmission limit is exceeded, the session is simply closed and the LTP sender follows the Cncld marker to the CLOSED state. If the retransmission limit is not exceeded however, the CS segment is queued for a retransmission and the LTP sender stays in the CS_SENT state. The CS timer is started upon receiving a link state cue indicating the beginning of actual transmission according to the internal procedure Start Cancel Timer (Section 6.15).
- 如果超出了网络管理设置的重传限制，会话将简单地关闭，LTP发送方将遵循Cncld标记进入关闭状态。但是，如果未超过重传限制，则CS段将排队等待重传，LTP发送方将保持CS_发送状态。根据内部程序Start Cancel timer（第6.15节），CS定时器在接收到指示实际传输开始的链路状态提示后启动。
Asynchronous cancel request may also be received from the receiver LTP in the form of a CR segment when the LTP sender is in any of the states. Upon receiving such a CR segment, the internal procedure Acknowledge Cancellation (Section 6.17) is invoked: The LTP sender sends a CAR segment in response and returns to the CLOSED state.
当LTP发送方处于任一状态时，还可以以CR段的形式从接收方LTP接收异步取消请求。收到此类CR段后，调用内部程序确认取消（第6.17节）：LTP发送方发送一个CAR段作为响应，并返回到关闭状态。
The LTP sender stays in the CLOSED state until receiving a Block Transmission Request (Blk. Trans. Req) from the client service instance. Upon receiving the request, it moves to either the Fully Green Transmission State (FG_XMIT) if no portion of the block was requested to be transmitted as red or to the Red-Part Transmission State (RP_XMIT) state if a non-zero block-prefix was requested to be transmitted red.
LTP发送方保持关闭状态，直到从客户端服务实例接收到块传输请求（Blk.Trans.Req）。在接收到请求后，如果没有请求将块的任何部分作为红色传输，则它移动到完全绿色传输状态（FG_XMIT），或者如果请求将非零块前缀作为红色传输，则它移动到红色部分传输状态（RP_XMIT）。
In the FG_XMIT state, the block is segmented as multiple green LTP data segments respecting the link MTU size and the segments are queued for transmission to the remote engine. The last such segment is marked as EOB, and the LTP sender returns to the CLOSED state after queuing it for transmission.
在FG_XMIT状态下，根据链路MTU大小将块分割为多个绿色LTP数据段，这些段排队等待传输到远程引擎。最后一个这样的段被标记为EOB，LTP发送方在排队等待传输后返回到关闭状态。
Similarly, from the RP_XMIT state, multiple red data segments are queued for transmission, respecting the link MTU size. The sender LTP may optionally mark some of the red data segments as asynchronous checkpoints; the internal procedure Start Checkpoint Timer (Section 6.2) is followed upon receiving a link state cue indicating the transmission of the asynchronous checkpoints. If the block transmission request comprises a non-zero green part, the LTP sender marks the last red data segment as CP and EORP, and after queuing it for transmission, moves to the Green Part Transmission (GP_XMIT) state. If the block transmission request was fully red however, the
Similarly, from the RP_XMIT state, multiple red data segments are queued for transmission, respecting the link MTU size. The sender LTP may optionally mark some of the red data segments as asynchronous checkpoints; the internal procedure Start Checkpoint Timer (Section 6.2) is followed upon receiving a link state cue indicating the transmission of the asynchronous checkpoints. If the block transmission request comprises a non-zero green part, the LTP sender marks the last red data segment as CP and EORP, and after queuing it for transmission, moves to the Green Part Transmission (GP_XMIT) state. If the block transmission request was fully red however, thetranslate error, please retry
last red data segment is marked as CP, EORP, and EOB and the sender LTP moves directly to the Wait-for-Red-Part-Acknowledgment (WAIT_RP_ACK) state. In both of the above state-transitions, the internal procedure Start Checkpoint Timer (Section 6.2) is followed upon receiving a link state cue indicating the beginning of transmission of the queued CP segments. In the GP_XMIT state, the green-part of the block is segmented as green data segments and queued for transmission to the LTP receiver; the last green segment of the block is additionally marked as EOB, and after queueing it for transmission the LTP sender moves to the WAIT_RP_ACK state.
最后一个红色数据段标记为CP、EORP和EOB，发送方LTP直接进入等待红色部分确认（Wait_RP_ACK）状态。在上述两种状态转换中，在接收到指示排队CP段传输开始的链路状态提示后，遵循内部过程启动检查点计时器（第6.2节）。在GP_XMIT状态下，块的绿色部分被分割为绿色数据段，并排队等待传输到LTP接收器；块的最后一个绿色段额外标记为EOB，在将其排队等待传输后，LTP发送方将移动到WAIT_RP_ACK状态。
While the LTP sender is at any of the RP_XMIT, GP_XMIT, or WAIT_RP_ACK states, it might be interrupted by the occurrence of the following events:
当LTP发送方处于RP_XMIT、GP_XMIT或WAIT_RP_ACK状态时，它可能会被以下事件中断：
1. An RS might be received from the LTP receiver (either in response to a previously transmitted CP segment or sent asynchronously for accelerated retransmission). The LTP sender then moves to perform the sequence of state transitions beginning at the RX marker (second part of the diagram), and retransmits data if necessary, illustrating the internal procedure Retransmit Data (Section 6.13):
1. 可以从LTP接收器接收RS（响应于先前发送的CP段或异步发送以加速重传）。然后，LTP发送器移动以执行从RX标记（图的第二部分）开始的状态转换序列，并在必要时重新传输数据，说明内部程序重新传输数据（第6.13节）：
First, if the RS segment had a non-zero CP serial number, the corresponding CP timer is canceled. Then an RA segment acknowledging the received RS segment is queued for transmission to the LTP receiver and the LTP sender moves to the Check Report state (CHK_RPT). If the RS segment was redundantly transmitted by the LTP receiver (possibly because either the last transmitted RA segment got lost or the RS segment timer expired prematurely at the receiver), the LTP sender does nothing more and returns back to the interrupted state. Similarly, if all red data within the scope of the RS segment is reported as received, there is no work to be done and the LTP sender returns to the interrupted state. However, if the RS segment indicated incomplete reception of data within its scope, the LTP sender moves to the Red-Part Retransmit state (RP_RXMT) where missing red data segments within scope are queued for transmission. The last such segment is marked as a CP, and the LTP sender returns to the interrupted state. The internal procedure (Section 6.2) is followed upon receiving a link state cue indicating the beginning of transmission of the CP segment.
首先，如果RS段具有非零CP序列号，则取消相应的CP定时器。然后，确认接收到的RS段的RA段排队等待传输到LTP接收器，LTP发送方移动到检查报告状态（CHK_RPT）。如果RS段由LTP接收器冗余传输（可能是因为最后传输的RA段丢失或RS段计时器在接收器处过早过期），LTP发送方不再执行任何操作，并返回中断状态。类似地，如果RS段范围内的所有红色数据报告为已接收，则没有工作要做，LTP发送方返回到中断状态。但是，如果RS段指示其作用域内的数据接收不完整，LTP发送方将进入红色部分重传状态（RP_RXMT），其中作用域内缺失的红色数据段将排队等待传输。最后一个这样的段被标记为CP，LTP发送方返回到中断状态。在接收到指示CP段传输开始的链路状态提示后，遵循内部程序（第6.2节）。
2. A previously set CP timer might expire. Now the LTP sender follows the states beginning at the CP marker (second part of the diagram), and follows the internal procedure Retransmit Checkpoint (Section 6.7):
2. 以前设置的CP计时器可能会过期。现在，LTP发送方遵循从CP标记（图的第二部分）开始的状态，并遵循内部过程重新传输检查点（第6.7节）：
If the CP Retransmission Limit set by network management for the session has been exceeded, the LTP sender proceeds towards canceling the session (with reason-code RLEXC) as indicated by the sequence of state transitions following the CX marker. Otherwise (if the Retransmission Limit is not exceeded yet), the CP segment is queued for retransmission and the LTP sender returns to the interrupted state. The internal procedure Start Checkpoint Timer (Section 6.2) is started again upon receiving a link state cue indicating the beginning of transmission of the segment.
如果已超过网络管理为会话设置的CP重传限制，则LTP发送方将继续取消会话（原因码为RLEXC），如CX标记后的状态转换序列所示。否则（如果尚未超过重传限制），CP段将排队等待重传，LTP发送方将返回中断状态。内部程序启动检查点计时器（第6.2节）在收到指示段传输开始的链路状态提示后再次启动。
The LTP sender stays at the WAIT_RP_ACK state after reaching it until the red-part data is fully acknowledged as received by the receiver LTP, and then returns to the CLOSED state following the internal procedure Close Session (Section 6.20).
LTP发送方在到达后保持等待确认状态，直到接收方LTP完全确认收到红色部分数据，然后在内部程序关闭会话后返回关闭状态（第6.20节）。
Note that while at the CLOSED state, the LTP sender might receive an RS segment (if the last transmitted RA segment before session close got lost or if the LTP receiver retransmitted the RS segment prematurely), in which case it retransmits an acknowledging RA segment and stays in the CLOSED state. If the session was canceled by the receiver by issuing a CR segment, the receiver may retransmit the CR segment (either prematurely or because the acknowledging CAR segment got lost). In this case, the LTP sender retransmits the acknowledging CAR segment and stays in the CLOSED state.
注意，当处于关闭状态时，LTP发送方可能会收到RS段（如果会话关闭前最后发送的RA段丢失，或者如果LTP接收方过早地重新发送RS段），在这种情况下，它会重新发送确认RA段并保持在关闭状态。如果会话被接收器通过发出CR段而取消，接收器可能会重新传输CR段（过早地或由于确认的车辆段丢失）。在这种情况下，LTP发送器重新传输确认的车辆段并保持在关闭状态。
8.2. Receiver LTP Receiver State Transition Diagram
8.2. 接收机LTP接收机状态转换图
/\/\/\/\
+----+ +----+ Cncld |
Rcv CS; | V V \/\/\/\/
Snd CAS | +-------------+
+--+ CLOSED +<--------------------------+
+------+------+ |
+----+ | Rcv first DS |
Rcv RA; | V V |
Cncl RS Tmr | +--------+ |
+---+ DS_REC | |
+----------------------------->+-+--+-+-+<----------------------+---+ |
| Svc. does not exist | | | RS TE | | |
| /\/\ or Rcv miscolored seg. | | | /\/\ | | |
| | CX |<-----------------------+ | +------------->| RX |---->+ | |
| \/\/ | \/\/ | |
| Rcv RDS; | Rcv GDS; | |
| +-----------+------------+ | |
| V V | |
| /\/\ RS TE +--------------+ +--------+ | |
+<-| RX |<------+ RCV_RP | | RCV_GP | | |
| \/\/ +-+----+--+--+-+ +--+-+-+-+ | |
| | | | | | | | | |
| Rcvd RDS; | | | | Rcvd {RDS, CP, | | | RS TE /\/\ | |
| | | | | EORP, EOB}; | | +------>| RX |->+ |
+<----------------+ | | | Snd RS, | | \/\/ | |
| | | | Start RS Tmr | | Rcvd GDS; | |
| Rcvd {RDS, CP}; | | | | +---------------->+ |
| Snd RS, Start RS Tmr | | +-------+ +-----+ |
+<---------------------+ | | | Rcvd {GDS, EOB}; |
| | | | |
| | +-----+ | | +------+ |
| Rcvd {RDS, CP, EORP}; | | V V V V | |
| Snd RS, Start RS Tmr | | +----------------+ | Rcv RDS; |
| | | | +-->+ |
| | | | WAIT_RP_REC | | Rcv {RDS, CP}; |
| | | | +-->+ Snd RS, Start |
+<------------------------+ | +---+--+-+-+-----+ | RS Tmr |
| RS TE | | | | Rcv RA; | |
| V | | | Cncl | |
| /\/\ | | | RS Tmr | |
+---| RX | | | +-------->+ |
\/\/ | | |
/\/\ | | |
| CX |<------------------------+ | RP rcvd. fully |
\/\/ Rcv miscolored seg. +--------------------------->+
/\/\/\/\
+----+ +----+ Cncld |
Rcv CS; | V V \/\/\/\/
Snd CAS | +-------------+
+--+ CLOSED +<--------------------------+
+------+------+ |
+----+ | Rcv first DS |
Rcv RA; | V V |
Cncl RS Tmr | +--------+ |
+---+ DS_REC | |
+----------------------------->+-+--+-+-+<----------------------+---+ |
| Svc. does not exist | | | RS TE | | |
| /\/\ or Rcv miscolored seg. | | | /\/\ | | |
| | CX |<-----------------------+ | +------------->| RX |---->+ | |
| \/\/ | \/\/ | |
| Rcv RDS; | Rcv GDS; | |
| +-----------+------------+ | |
| V V | |
| /\/\ RS TE +--------------+ +--------+ | |
+<-| RX |<------+ RCV_RP | | RCV_GP | | |
| \/\/ +-+----+--+--+-+ +--+-+-+-+ | |
| | | | | | | | | |
| Rcvd RDS; | | | | Rcvd {RDS, CP, | | | RS TE /\/\ | |
| | | | | EORP, EOB}; | | +------>| RX |->+ |
+<----------------+ | | | Snd RS, | | \/\/ | |
| | | | Start RS Tmr | | Rcvd GDS; | |
| Rcvd {RDS, CP}; | | | | +---------------->+ |
| Snd RS, Start RS Tmr | | +-------+ +-----+ |
+<---------------------+ | | | Rcvd {GDS, EOB}; |
| | | | |
| | +-----+ | | +------+ |
| Rcvd {RDS, CP, EORP}; | | V V V V | |
| Snd RS, Start RS Tmr | | +----------------+ | Rcv RDS; |
| | | | +-->+ |
| | | | WAIT_RP_REC | | Rcv {RDS, CP}; |
| | | | +-->+ Snd RS, Start |
+<------------------------+ | +---+--+-+-+-----+ | RS Tmr |
| RS TE | | | | Rcv RA; | |
| V | | | Cncl | |
| /\/\ | | | RS Tmr | |
+---| RX | | | +-------->+ |
\/\/ | | |
/\/\ | | |
| CX |<------------------------+ | RP rcvd. fully |
\/\/ Rcv miscolored seg. +--------------------------->+
Receiver State Transition Diagram (contd.)
接收机状态转换图（续）
/\/\
| RX |
\/\/
| |
| | RL EXC; /\/\
RL NOT EXC; | +---------->| CX |
Rxmt RS, | \/\/
Start RS Tmr |
V
/\/\
| RX |
\/\/
| |
| | RL EXC; /\/\
RL NOT EXC; | +---------->| CX |
Rxmt RS, | \/\/
Start RS Tmr |
V
/\/\
| CX |
\/\/
| Snd CR,
| Start CR Tmr;
|
| +----+
V V |
+---------+ | CR TE,
| CR_SENT | | RL NOT EXC;
+-+--+--+-+ | Rxmt CR,
| | | | Restart
CR TE, | | +---+ CR Tmr
RL EXC; | |
| | Rcv CAR;
V V
/\/\/\/\
| Cncld |
\/\/\/\/
/\/\
| CX |
\/\/
| Snd CR,
| Start CR Tmr;
|
| +----+
V V |
+---------+ | CR TE,
| CR_SENT | | RL NOT EXC;
+-+--+--+-+ | Rxmt CR,
| | | | Restart
CR TE, | | +---+ CR Tmr
RL EXC; | |
| | Rcv CAR;
V V
/\/\/\/\
| Cncld |
\/\/\/\/
Asynchronous cancel requests are handled in a manner similar to the way they are handled in the LTP sender. If the cancel request was made from the local client service instance and the LTP receiver was not already in the CR_SENT state, a CR segment with reason-code USR_CNCLD SHOULD be sent to the LTP sender following the sequence of state transitions beginning at the CX marker as described above. If the asynchronous cancel request is received from the LTP sender, a CAS segment is sent and the LTP receiver moves to the CLOSED state (independent of the state the LTP receiver may be in).
异步取消请求的处理方式与LTP发送方中处理它们的方式类似。如果取消请求是从本地客户端服务实例发出的，并且LTP接收方尚未处于CR_发送状态，则应按照从CX标记开始的状态转换顺序，向LTP发送方发送带有原因代码USR_CNCLD的CR段，如上所述。如果从LTP发送方接收到异步取消请求，则发送CAS段，并且LTP接收方移动到关闭状态（与LTP接收方可能处于的状态无关）。
The LTP receiver begins at the CLOSED state and enters the Data Segment Reception (DS_REC) state upon receiving the first data segment. If the client service ID referenced in the data segment was non-existent, a Cx segment with reason-code UNREACH SHOULD be sent to the LTP sender via the Cancellation sequence beginning with the CX marker (second part of the diagram). If the received segment was
LTP接收器从关闭状态开始，并在接收到第一个数据段时进入数据段接收（DS_REC）状态。如果数据段中引用的客户机服务ID不存在，则应通过从Cx标记开始的取消序列（图的第二部分）将带有原因码Unrach的Cx段发送给LTP发送方。如果收到的段是
found to be miscolored, the internal procedure Handle Miscolored Segment (Section 6.21) is followed, and a CX segment with reason-code MISCOLORED SHOULD be sent to the LTP sender with the Cancellation sequence beginning with the CX marker.
如果发现错误颜色，则遵循内部程序句柄错误颜色段（第6.21节），并且应将带有原因代码错误颜色的CX段发送给LTP发送方，取消顺序从CX标记开始。
Otherwise, the LTP receiver enters the Receive Red-Part state (RCV_RP) or the Receive Green-Part state (RCV_GP) depending on whether the segment received was red or green, respectively.
否则，LTP接收机分别根据接收的段是红色还是绿色进入接收红色部分状态（RCV_RP）或接收绿色部分状态（RCV_GP）。
In the RCV_RP state, a check is made of the nature of the received red DS. If the segment was a regular red data segment, the receiver LTP just returns to the DS_REC state. For red data segments marked also as CP and as CP & EORP, a responding RS segment is queued for transmission to the sender following either the internal procedure Retransmit RS (Section 6.8) or Send Reception Report (Section 6.11) depending on whether the CP segment was a retransmission (an RS segment corresponding to the checkpoint serial number in the CP segment was previously issued) or not, respectively. The LTP receiver then returns to the DS_REC state. If the block transmission was fully red and the segment was marked as CP, EORP, and EOB, the LTP receiver enters the Wait-for-Red-Part-Reception state (WAIT_RP_REC). In all cases, the internal procedure Start RS Timer (Section 6.3) is followed upon receiving link state cues indicating the beginning of transmission of the RS segments.
在RCV_RP状态下，对接收到的红色DS的性质进行检查。如果该段为常规红色数据段，则接收器LTP仅返回DS_REC状态。对于标记为CP和CP&EORP的红色数据段，根据CP段是否为重传，响应RS段按照内部程序重传RS（第6.8节）或发送接收报告（第6.11节）排队等待发送至发送方（与CP段中的检查点序列号相对应的RS段之前已发出）或未发出。然后，LTP接收器返回DS_REC状态。如果块传输为全红色，且该段标记为CP、EORP和EOB，则LTP接收器进入等待红色部分接收状态（Wait_RP_REC）.在所有情况下，在接收到指示RS段传输开始的链路状态提示后，遵循内部程序启动RS定时器（第6.3节）。
In the RCV_GP state, if the received green data segment was not marked EOB, the LTP receiver returns to the DS_REC state. Otherwise, it enters the WAIT_RP_REC state to receive the red-part of the block fully.
在RCV_GP状态下，如果接收到的绿色数据段未标记为EOB，则LTP接收器返回DS_REC状态。否则，它将进入WAIT_RP_REC状态以完全接收块的红色部分。
A previously set RS timer may expire and interrupt the LTP receiver while in the DS_REC, RCV_RP, RCV_GP, or WAIT_RP_REC state. If so, the internal procedure Retransmit RS (Section 6.8) is followed as illustrated in the states beginning at the RX marker (shown in the second part of the diagram) before returning to the interrupted state:
当处于DS_REC、RCV_RP、RCV_GP或WAIT_RP_REC状态时，先前设置的RS定时器可能会过期并中断LTP接收机。如果是这样，在返回到中断状态之前，按照从RX标记开始的状态（如图的第二部分所示）所示，遵循内部程序重新传输RS（第6.8节）：
- A check is made here to see if the retransmission limit set by the network management has been exceeded in the number of RSs sent in the session. If so, a CR segment with reason-code RLEXC SHOULD be sent to the LTP sender and the sequence indicated by the CX marker is followed. Otherwise, the RS segment is queued for retransmission and the associated RS timer is started following the internal procedure Start RS Timer (Section 6.3) upon receiving a link state cue indicating the beginning of its transmission.
- 此处进行检查，查看会话中发送的RSs数量是否超过了网络管理设置的重传限制。如果是，应将带有原因代码RLEXC的CR段发送给LTP发送方，并遵循CX标记指示的顺序。否则，RS段排队等待重新传输，并且在接收到指示其传输开始的链路状态提示后，按照内部程序启动RS定时器（第6.3节）启动相关RS定时器。
The LTP receiver may also receive RA segments from the sender in response to the RS segments sent while in the DS_REC state. If so, then the RS timer corresponding to the report serial number mentioned in the RA segment is canceled following the internal procedure Stop RS Timer (Section 6.14).
LTP接收机还可以响应于在DS_REC状态下发送的RS段从发送方接收RA段。如果是，则在内部程序停止RS定时器（第6.14节）后，取消RA段中提及的报告序列号对应的RS定时器。
The LTP receiver stays in the WAIT_RP_REC state until the entire red-part of the block is received, and moves to the CLOSED state upon full red-part reception. In this state, a check is made upon reception of every red-part data segment to see if it is at a block offset higher than any green-part data segment received. If so, the internal procedure Handle Miscolored Segment (Section 6.21) is invoked and the sequence of state transitions beginning with the CX marker is followed; a CX segment with reason-code MISCOLORED SHOULD be sent to the LTP sender with the Cancellation sequence beginning with the CX marker.
LTP接收器保持等待RP REC状态，直到接收到块的整个红色部分，并在接收到全部红色部分后移到关闭状态。在此状态下，在接收到每个红色部件数据段时进行检查，以查看其是否位于高于接收到的任何绿色部件数据段的块偏移。如果是这样，则调用内部程序Handle Miscolored Segment（第6.21节），并遵循从CX标记开始的状态转换顺序；应将原因代码为MISCOLED的CX段发送给LTP发送方，取消顺序从CX标记开始。
Note that if there were no red data segments received in the session yet, including the case where the session was indeed fully green or the pathological case where the entire red-part of the block gets lost but at least the green data segment marked EOB is received (the LTP receiver has no indication of whether the session had a red-part transmission), the LTP receiver assumes the "RP rcvd. fully" condition to be true and moves to the CLOSED state from the WAIT_RP_REC state.
请注意，如果会话中尚未接收到红色数据段，包括会话确实是完全绿色的情况，或块的整个红色部分丢失但至少接收到标记为EOB的绿色数据段的病理情况（LTP接收器没有指示会话是否有红色部分传输），LTP接收器假定“RP rcvd.full”条件为真，并从WAIT_RP_REC状态移动到关闭状态。
In the WAIT_RP_REC state, the LTP receiver may receive the retransmitted red data segments. Upon receiving red data segments marked CP, it queues the responding RS segment for transmission based on either internal procedure Retransmit RS (Section 6.8) or Send Reception Report (Section 6.11) depending on whether the CP was found to be a retransmission or not, respectively. The internal procedure Start RS Timer is invoked upon receiving a link state cue indicating the beginning of transmission of the RS segment. If an RA segment is received, the RS timer corresponding to the report segment mentioned is canceled and the LTP receiver stays in the state until the entire red-part is received.
在WAIT_RP_REC状态下，LTP接收机可以接收重传的红色数据段。在接收到标记为CP的红色数据段后，它将根据内部程序重新传输RS（第6.8节）或发送接收报告（第6.11节）分别对响应RS段进行排队以进行传输，具体取决于CP是否为重新传输。当接收到指示RS段传输开始的链路状态提示时，调用内部过程Start RS Timer。如果接收到RA段，则与所述报告段对应的RS定时器被取消，并且LTP接收机保持在状态，直到接收到整个红色部分。
In the sequence of state transitions beginning at the CX marker, the CR segment with the given reason-code (depending on how the sequence is entered) is queued for transmission, and the CR timer is started upon reception of the link state cue indicating actual transmission following the internal procedure Start Cancel Timer (Section 6.15). If the CAR segment is received from the LTP sender, the LTP receiver returns to the CLOSED state (via the Cncld marker) following the internal procedure Stop Cancel Timer (Section 6.18). If the CR timer expires asynchronously, the internal procedure Retransmit Cancellation Segment (Section 6.16) is followed:
在从CX标记开始的状态转换序列中，具有给定原因码（取决于序列的输入方式）的CR段排队等待传输，并且CR定时器在收到链路状态提示时启动，该提示指示按照内部程序开始取消定时器（第6.15节）进行的实际传输。如果从LTP发送器接收到车辆段，则LTP接收器按照内部程序停止-取消计时器（第6.18节）返回到关闭状态（通过Cncld标记）。如果CR计时器异步过期，则遵循内部程序重传取消段（第6.16节）：
- A check is made to see if the retransmission limit set by the network management for the number of CR segments per session has been exceeded. If so, the LTP receiver returns to the CLOSED state following the Cncld marker. Otherwise, a CR segment is scheduled for retransmission with the CR timer being started following the internal procedure Start Cancel Timer (Section 6.15) upon reception of a link state cue indicating actual transmission.
- 检查是否超过了网络管理为每个会话的CR段数设置的重传限制。如果是，LTP接收器返回Cncld标记后的关闭状态。否则，在接收到指示实际传输的链路状态提示后，CR段被调度为重新传输，CR定时器按照内部程序Start Cancel timer（第6.15节）启动。
The LTP receiver might also receive a retransmitted CS segment at the CLOSED state (either if the CAS segment previously transmitted was lost or if the CS timer expired prematurely at the LTP sender). In such a case, the CAS is scheduled for retransmission.
LTP接收器也可能在关闭状态下接收重新传输的CS段（如果先前传输的CAS段丢失，或者如果LTP发送器处的CS定时器过早过期）。在这种情况下，CAS被调度为重传。
Implementers SHOULD consider the likelihood of the following Denial of Service (DoS) attacks:
实现者应该考虑以下拒绝服务（DoS）攻击的可能性：
- A fake Cx could be inserted, thus bringing down a session.
- 可能会插入一个伪Cx，从而导致会话中断。
- Various acknowledgment segments (RA, RS, etc.) could be deleted, causing timers to expire, and having the potential to disable communication altogether if done with a knowledge of the communications schedule. This could be achieved either by mounting a DoS attack on a lower-layer service in order to prevent it from sending an acknowledgment segment, or by simply jamming the transmission (all of which are more likely for terrestrial applications of LTP).
- 各种确认段（RA、RS等）可能会被删除，导致计时器过期，如果在了解通信计划的情况下完成，则可能会完全禁用通信。这可以通过在较低层服务上安装DoS攻击来实现，以防止其发送确认段，或者通过简单地干扰传输来实现（所有这些都更可能用于LTP的地面应用）。
- An attacker might also corrupt some bits, which is tantamount to deleting that segment.
- 攻击者还可能损坏某些位，这相当于删除该段。
- An attacker may flood an LTP engine with segments for the internal operations queue and prevent transmission of legitimate data segments.
- 攻击者可能会将内部操作队列的段淹没LTP引擎，并阻止合法数据段的传输。
- An attacker could attempt to fill up the storage in an engine by sending many large messages to it. In terrestrial LTP applications, this may be much more serious since spotting the additional traffic may not be possible from any network management point.
- 攻击者可以通过向引擎发送许多大消息来尝试填充引擎中的存储。在地面LTP应用中，这可能更为严重，因为从任何网络管理点都不可能发现额外的流量。
If any of the above DoS attacks is likely, then one or more of the following anti-DoS mechanisms ought to be employed:
如果可能发生上述任何DoS攻击，则应采用以下一种或多种反DoS机制：
- Session numbers SHOULD be partly random making it harder to insert valid segments.
- 会话编号应该是部分随机的，这样就更难插入有效的段。
- An engine that suspects that either it or its peer is under DoS attack could frequently checkpoint its data segments (if it were the sender) or send asynchronous RSs (if it were the receiver), thus eliciting an earlier response from its peer or timing out earlier due to the failure of an attacker to respond.
- 怀疑其或其对等方受到DoS攻击的引擎可能会经常检查其数据段（如果它是发送方）或发送异步RSs（如果它是接收方），从而从其对等方获得更早的响应，或者由于攻击者响应失败而提前超时。
- Serial numbers (checkpoint serial numbers, report serial numbers) MUST begin each session anew using random numbers rather than from 0.
- 序列号（检查点序列号、报告序列号）必须使用随机数而不是0重新开始每个会话。
- The authentication header [LTPEXT].
- 身份验证标头[LTPEXT]。
The following algorithm is given as an example of how an LTP implementation MAY handle replays.
下面给出了一个LTP实现如何处理重播的示例。
1. On receipt of an LTP segment, check against a cache for replay. If this is a replay segment and if a pre-cooked response is available (stored from the last time this segment was processed), then send the pre-cooked response. If there is no pre-cooked response, then silently drop the inbound segment. This can all be done without attempting to decode the buffer.
1. 收到LTP段后，检查缓存以进行重播。如果这是一个重播段，并且如果预煮响应可用（从上次处理该段时开始存储），则发送预煮响应。如果没有预先准备好的响应，则静默地删除入站段。这一切都可以在不尝试解码缓冲区的情况下完成。
2. If the inbound segment does not decode correctly, then silently drop the segment. If the segment decodes properly, then add its hash to the replay cache and return a handle to the entry.
2. 如果入站段未正确解码，则自动删除该段。如果段正确解码，则将其哈希添加到重播缓存中，并返回该项的句柄。
3. For those cases where a pre-cooked response should be stored, store the response using the handle received from the previous step. These cases include:
3. 对于那些应该存储预煮响应的情况，使用从上一步接收到的句柄存储响应。这些个案包括：
(a) when the inbound packet is a CP segment, the RS segment sent in response gets stored as pre-cooked,
(a) 当入站数据包是CP段时，作为响应发送的RS段被存储为预煮，
(b) when the Incoming packet is an RS segment, the RA segment is stored as pre-cooked, and
(b) 当传入数据包是RS段时，RA段存储为预煮，并且
(c) when the incoming packet is a Cx segment, the CAx segment sent in response gets stored pre-cooked.
(c) 当传入数据包是Cx段时，作为响应发送的CAx段将被预先存储。
4. Occasionally clean out the replay cache -- how frequently this happens is an implementation issue.
4. 偶尔清理replay缓存——这种情况发生的频率是一个实现问题。
The downside of this algorithm is that receiving a totally bogus segment still results in a replay cache search and attempted LTP decode operation. It is not clear that it is possible to do much better though, since all an attacker would have to do to get past the replay cache would be to tweak a single bit in the inbound segment each time, which is certainly cheaper than the hash+lookup+decode combination, though also certainly more expensive than simply sending the same octets many times.
该算法的缺点是，接收完全虚假的段仍然会导致重播缓存搜索和尝试LTP解码操作。不过，目前还不清楚是否有可能做得更好，因为攻击者要通过重播缓存所需做的只是每次调整入站段中的一个位，这肯定比哈希+查找+解码组合便宜，但也肯定比多次发送相同的八位字节要贵。
The benefit of doing this is that implementers no longer need to analyze many bugs/attacks based on replaying packets, which in combination with the use of LTP authentication should defeat many attempted DoS attacks.
这样做的好处是，实现人员不再需要分析基于重放数据包的许多错误/攻击，这与LTP身份验证的使用相结合，应该可以击败许多尝试的DoS攻击。
SDNV
SDNV
Implementations SHOULD make sanity checks on SDNV length fields and SHOULD check that no SDNV field is too long when compared with the overall segment length.
实现应该对SDNV长度字段进行完整性检查，并且应该检查与整个段长度相比，没有SDNV字段过长。
Implementations SHOULD check that SDNV values are within suitable ranges where possible.
在可能的情况下，实施应检查SDNV值是否在合适的范围内。
Byte ranges
字节范围
Various report and other segments contain offset and length fields. Implementations MUST ensure that these are consistent and sane.
各种报告和其他段包含偏移量和长度字段。实施必须确保这些是一致的和合理的。
Randomness
随机性
Various fields in LTP (e.g., serial numbers) MUST be initialized using random values. Good sources of randomness that are not easily guessable SHOULD be used [ESC05]. The collision of random values is subject to the birthday paradox, which means that a collision is likely after roughly the square root of the space has been seen (e.g., 2^16 in the case of a 32-bit random value).
必须使用随机值初始化LTP中的各种字段（例如序列号）。应使用不易猜测的良好随机性来源[ESC05]。随机值的碰撞受到生日悖论的影响，这意味着在大致看到空间的平方根后可能发生碰撞（例如，在32位随机值的情况下为2^16）。
Implementers MUST ensure that they use sufficiently long random values so that the birthday paradox doesn't cause a problem in their environment.
实现者必须确保使用足够长的随机值，这样生日悖论就不会在他们的环境中造成问题。
The UDP port number 1113 with the name "ltp-deepspace" has been reserved for LTP deployments. An LTP implementation may be implemented to operate over UDP datagrams using this port number for study and testing over the Internet.
名为“ltp deepspace”的UDP端口号1113已保留给ltp部署。可以实现LTP实现，以便使用此端口号在UDP数据报上操作，以便在Internet上进行研究和测试。
The IANA has created and now maintains a registry for known LTP Extension Tags (as indicated in Section 3.1). The registry has been populated using the initial values given in Section 3.1 above. IANA may assign LTP Extension Tag values from the range 0x02-0xAF (inclusive) using the Specification Required rule [GUIDE]. The specification concerned can be an RFC (whether Standards Track, Experimental, or Informational), or a specification from any other standards development organization recognized by IANA or with a liaison with the IESG, specifically including CCSDS (http://www.ccsds.org/). Any use of Reserved values (0xB0-0xBF inclusive) requires an update this specification.
IANA已经为已知的LTP扩展标签创建并维护了一个注册表（如第3.1节所示）。已使用上文第3.1节中给出的初始值填充注册表。IANA可以使用规范要求的规则[指南]从0x02-0xAF（包括0x02-0xAF）范围分配LTP扩展标记值。相关规范可以是RFC（无论是标准跟踪、实验或信息），也可以是IANA认可的任何其他标准开发组织或与IESG联络的规范，具体包括CCSDS(http://www.ccsds.org/). 任何使用保留值（0xB0-0xBF包括在内）都需要更新本规范。
Many thanks to Tim Ray, Vint Cerf, Bob Durst, Kevin Fall, Adrian Hooke, Keith Scott, Leigh Torgerson, Eric Travis, and Howie Weiss for their thoughts on this protocol and its role in Delay-Tolerant Networking architecture.
非常感谢Tim Ray、Vint Cerf、Bob Durst、Kevin Fall、Adrian Hooke、Keith Scott、Leigh Torgerson、Eric Travis和Howie Weiss对该协议及其在延迟容忍网络架构中的作用的思考。
Part of the research described in this document was carried out at the Jet Propulsion Laboratory, California Institute of Technology, under a contract with the National Aeronautics and Space Administration. This work was performed under DOD Contract DAA-B07- 00-CC201, DARPA AO H912; JPL Task Plan No. 80-5045, DARPA AO H870; and NASA Contract NAS7-1407.
本文件中描述的部分研究是在加利福尼亚理工学院喷气推进实验室根据与美国国家航空航天局签订的合同进行的。这项工作是根据国防部合同DAA-B07-00-CC201，DARPA AO H912执行的；JPL任务计划编号80-5045，DARPA AO H870；美国宇航局合同NAS7-1407。
Thanks are also due to Shawn Ostermann, Hans Kruse, Dovel Myers, and Jayram Deshpande at Ohio University for their suggestions and advice in making various design decisions. This work was done when Manikantan Ramadas was a graduate student at the EECS Dept., Ohio University, in the Internetworking Research Group Laboratory.
感谢俄亥俄大学的Shawn Ostermann、Hans Kruse、Dovel Myers和Jayram Deshpande在做出各种设计决策时提出的建议和建议。这项工作是在马尼坎坦·拉马达斯（Manikantan Ramadas）是俄亥俄大学电子工程系（EECS）的研究生时在互联网研究小组实验室完成的。
Part of this work was carried out at Trinity College Dublin as part of the SeNDT contract funded by Enterprise Ireland's research innovation fund.
这项工作的一部分在都柏林三一学院进行，作为爱尔兰企业研究创新基金资助的SeNDT合同的一部分。
[B97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[B97]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[GUIDE] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[指南]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[LTPMTV] Burleigh, S., Ramadas, M., and S. Farrell,"Licklider Transmission Protocol - Motivation", RFC 5325, September 2008.
[LTPMTV]Burleigh，S.，Ramadas，M.，和S.Farrell，“利克利德传输协议-动机”，RFC 53252008年9月。
[LTPEXT] Farrell, S., Ramadas, M., and S. Burleigh, "Licklider Transmission Protocol - Security Extensions", RFC 5327, September 2008.
[LTPEXT]Farrell，S.，Ramadas，M.，和S.Burleigh，“利克利德传输协议-安全扩展”，RFC 5327，2008年9月。
[ASN1] Abstract Syntax Notation One (ASN.1). ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER), and Distinguished Encoding Rules (DER). ITU-T Rec. X.690 (2002) | ISO/IEC 8825-1:2002.
[ASN1]抽象语法符号1（ASN.1）。ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）的规范。ITU-T Rec.X.690（2002）| ISO/IEC 8825-1:2002。
[BP] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007.
[BP]Scott，K.和S.Burleigh，“捆绑协议规范”，RFC 50502007年11月。
[DTN] K. Fall, "A Delay-Tolerant Network Architecture for Challenged Internets", In Proceedings of ACM SIGCOMM 2003, Karlsruhe, Germany, Aug 2003.
[DTN]K.Fall，“一种面向挑战性互联网的延迟容忍网络架构”，载于ACM SIGCOMM 2003年会议记录，德国卡尔斯鲁厄，2003年8月。
[ESC05] D. Eastlake, J. Schiller and S. Crockerr, "Randomness Recommendations for Security", RFC 4086, June 2005.
[ESC05]D.Eastlake，J.Schiller和S.Crocker，“安全性的随机性建议”，RFC 40862005年6月。
[SACK] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow, "TCP Selective Acknowledgement Options", RFC 2018, October 1996.
[SACK]M.Mathis，J.Mahdavi，S.Floyd和A.Romanow，“TCP选择性确认选项”，RFC 2018，1996年10月。
Authors' Addresses
作者地址
Manikantan Ramadas ISRO Telemetry Tracking and Command Network (ISTRAC) Indian Space Research Organization (ISRO) Plot # 12 & 13, 3rd Main, 2nd Phase Peenya Industrial Area Bangalore 560097 India Telephone: +91 80 2364 2602 EMail: mramadas@gmail.com
Manikantan Ramadas印度空间研究组织ISRO遥测跟踪和指挥网络（ISTRAC）印度空间研究组织（ISRO）班加罗尔喷丸工业区二期3号干线12号和13号地块560097印度电话：+91 80 2364 2602电子邮件：mramadas@gmail.com
Scott C. Burleigh Jet Propulsion Laboratory 4800 Oak Grove Drive M/S: 301-490 Pasadena, CA 91109-8099 Telephone: +1 (818) 393-3353 Fax: +1 (818) 354-1075 EMail: Scott.Burleigh@jpl.nasa.gov
斯科特·C·伯利喷气推进实验室4800橡树林大道M/S:301-490加利福尼亚州帕萨迪纳91109-8099电话：+1（818）393-3353传真：+1（818）354-1075电子邮件：斯科特。Burleigh@jpl.nasa.gov
Stephen Farrell Computer Science Department Trinity College Dublin Ireland Telephone: +353-1-896-1761 EMail: stephen.farrell@cs.tcd.ie
斯蒂芬·法雷尔计算机科学系都柏林三一学院爱尔兰电话：+353-1-896-1761电子邮件：斯蒂芬。farrell@cs.tcd.ie
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at http://www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78和http://www.rfc-editor.org/copyright.html，除本协议另有规定外，提交人保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.