Network Working Group S. Burleigh
Request for Comments: 5325 NASA/Jet Propulsion Laboratory
Category: Informational M. Ramadas
ISTRAC, ISRO
S. Farrell
Trinity College Dublin
September 2008
Network Working Group S. Burleigh
Request for Comments: 5325 NASA/Jet Propulsion Laboratory
Category: Informational M. Ramadas
ISTRAC, ISRO
S. Farrell
Trinity College Dublin
September 2008
Licklider Transmission Protocol - Motivation
利克利德传输协议-动机
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). See RFC 3932 for more information.
本RFC不适用于任何级别的互联网标准。它代表了互联网研究任务组（IRTF）的延迟容忍网络（DTN）研究小组的共识。有关更多信息，请参阅RFC 3932。
Abstract
摘要
This document describes the motivation for the development of 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.
本文件描述了开发利克利德传输协议（LTP）的动机，该协议旨在通过具有超长消息往返时间（RTT）和/或频繁连接中断特征的链路提供基于重传的可靠性。由于跨行星际空间的通信是此类环境中最突出的例子，LTP的主要目标是支持行星际空间中的“长距离”可靠传输，但它在其他环境中也有应用。
In an Interplanetary Internet setting deploying the Bundle protocol, LTP is intended to serve as a reliable convergence layer over single-hop deep-space radio frequency (RF) links. 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旨在作为单跳深空射频（RF）链路上的可靠汇聚层。LTP通过请求选择性确认接收报告来执行数据传输的自动重复请求（ARQ）。它是有状态的，没有协商或握手。
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 ....................................................2
2. Problem .........................................................3
2.1. IPN Operating Environment ..................................3
2.2. Why Not TCP or SCTP? .......................................5
3. Protocol Overview ...............................................6
3.1. Nominal Operation ..........................................6
3.1.1. Link State Cues .....................................9
3.1.2. Deferred Transmission ...............................9
3.1.3. Timers .............................................10
3.2. Retransmission ............................................13
3.3. Accelerated Retransmission ................................16
3.4. Session Cancellation ......................................17
4. Security Considerations ........................................17
5. IANA Considerations ............................................20
6. Acknowledgments ................................................20
7. References .....................................................20
7.1. Informative References ....................................20
1. Introduction ....................................................2
2. Problem .........................................................3
2.1. IPN Operating Environment ..................................3
2.2. Why Not TCP or SCTP? .......................................5
3. Protocol Overview ...............................................6
3.1. Nominal Operation ..........................................6
3.1.1. Link State Cues .....................................9
3.1.2. Deferred Transmission ...............................9
3.1.3. Timers .............................................10
3.2. Retransmission ............................................13
3.3. Accelerated Retransmission ................................16
3.4. Session Cancellation ......................................17
4. Security Considerations ........................................17
5. IANA Considerations ............................................20
6. Acknowledgments ................................................20
7. References .....................................................20
7.1. Informative References ....................................20
The Licklider Transmission Protocol (LTP) is designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times and/or frequent interruptions in connectivity. Communication in interplanetary space is the most prominent example of this sort of environment, and LTP is principally aimed at supporting "long-haul" reliable transmission over deep-space RF links. Specifically, LTP is intended to serve as a reliable "convergence layer" protocol, underlying the Delay-Tolerant Networking (DTN) [DTN] Bundle protocol [BP], in DTN deployments where data links are characterized by very long round-trip times.
利克利德传输协议（LTP）旨在通过链路提供基于重传的可靠性，其特征是消息往返时间极长和/或连接频繁中断。行星际空间的通信是此类环境中最突出的例子，LTP的主要目标是支持通过深空射频链路进行“长距离”可靠传输。具体而言，LTP旨在作为可靠的“汇聚层”协议，在数据链路具有很长往返时间的DTN部署中，作为延迟容忍网络（DTN）[DTN]捆绑协议[BP]的基础。
This document describes the motivation for LTP, its features, functions, and overall design. It is part of a series of documents describing LTP. Other documents in the series include the main protocol specification document [LTPSPEC] and the protocol extensions document [LTPEXT].
本文档描述了LTP的动机、特性、功能和总体设计。它是描述LTP的一系列文档的一部分。本系列中的其他文档包括主协议规范文档[LTPSPEC]和协议扩展文档[LTPEXT]。
The protocol is named in honor of ARPA/Internet pioneer JCR Licklider.
该协议是为了纪念ARPA/互联网先驱JCR利克利德而命名的。
There are a number of fundamental differences between the environment for terrestrial communications (such as seen in the Internet) and the operating environments envisioned for the Interplanetary Internet (IPN) [IPN].
地面通信环境（如互联网中所见）与星际互联网（IPN）[IPN]所设想的运行环境之间存在许多根本性差异。
The most challenging difference between communication among points on Earth and communication among planets is round-trip delay, of which there are two main sources, both relatively intractable: physics and economics.
地球上各点之间的通信和行星之间的通信之间最具挑战性的区别是往返延迟，其中有两个主要来源，都相对棘手：物理和经济。
The more obvious type of delay imposed by nature is signal propagation time. Round-trip times between Earth and Jupiter's moon Europa, for example, run between 66 and 100 minutes.
自然界施加的更明显的延迟类型是信号传播时间。例如，地球和木星卫星木卫二之间的往返时间为66到100分钟。
Less obvious and more dynamic is the delay imposed by occultation. Communication between planets must be by radiant transmission, which is usually possible only when the communicating entities are in line of sight of each other. During the time that communication is impossible, delivery is impaired and messages must wait in a queue for later transmission.
掩星造成的延迟不那么明显，也更具动态性。行星之间的通信必须通过辐射传输，这通常只有在通信实体彼此在视线内时才可能实现。在无法进行通信期间，传递会受到影响，消息必须在队列中等待稍后的传输。
Round-trip times and occultations can at least be readily computed given the ephemerides of the communicating entities. Additional delay that is less easily predictable is introduced by discontinuous transmission support, which is rooted in economics.
鉴于通信实体的星历表，至少可以容易地计算往返时间和掩星。不连续传输支持引入了不太容易预测的额外延迟，这一点植根于经济学。
Communicating over interplanetary distances requires expensive special equipment: large antennas, high-performance receivers, etc.
跨行星际距离通信需要昂贵的特殊设备：大型天线、高性能接收器等。
For most deep-space missions, even non-NASA ones, these are currently provided by NASA's Deep Space Network (DSN) [DSN]. The communication resources of the DSN are currently oversubscribed and will probably remain so for the foreseeable future. Radio contact via the DSN must therefore be carefully scheduled and is often severely limited.
对于大多数深空任务，即使是非NASA的任务，这些任务目前由NASA的深空网络（DSN）[DSN]提供。DSN的通信资源目前被超额认购，在可预见的未来可能仍将如此。因此，必须仔细安排通过DSN进行的无线电联系，并且通常受到严格限制。
This over-subscription means that the round-trip times experienced by packets will be affected not only by the signal propagation delay and occultation, but also by the scheduling and queuing delays imposed by the management of Earth-based resources: packets to be sent to a given destination may have to be queued until the next scheduled contact period, which may be hours, days, or even weeks away.
这种过度订阅意味着分组经历的往返时间将不仅受到信号传播延迟和掩星的影响，但也受到地球资源管理所施加的调度和排队延迟的影响：发送到给定目的地的数据包可能必须排队，直到下一个预定的接触期，这可能需要几个小时、几天甚至几周的时间。
These operating conditions imply a number of additional constraints on any protocol designed to ensure reliable communication over deep-space links.
这些运行条件意味着对任何旨在确保通过深空链路进行可靠通信的协议都有一些额外的限制。
- Long round-trip times mean substantial delay between the transmission of a block of data and the reception of an acknowledgment from the block's destination, signaling arrival of the block. If LTP postponed transmission of additional blocks of data until it received acknowledgment of the arrival of all prior blocks, valuable opportunities to utilize what little deep-space transmission bandwidth is available would be forever lost. Multiple parallel data block transmission "sessions" must be in progress concurrently in order to avoid under-utilization of the links.
- 长的往返时间意味着数据块的传输和从数据块的目的地接收到确认之间的实质性延迟，表示数据块的到达。如果LTP延迟额外数据块的传输，直到收到所有先前数据块到达的确认，那么利用有限的深空传输带宽的宝贵机会将永远失去。多个并行数据块传输“会话”必须同时进行，以避免链路利用率不足。
- Like any reliable transport service employing ARQ, LTP is "stateful". In order to ensure the reception of a block of data it has sent, LTP must retain for possible retransmission all portions of that block that might not have been received yet. In order to do so, it must keep track of which portions of the block are known to have been received so far and which are not, together with any additional information needed for purposes of retransmitting part or all of that block.
- 与使用ARQ的任何可靠传输服务一样，LTP是“有状态的”。为了确保接收到它发送的数据块，LTP必须保留该数据块中可能尚未接收到的所有部分，以便可能的重新传输。为了做到这一点，它必须跟踪到目前为止已知接收到的和未接收到的块的哪些部分，以及重传该块的部分或全部所需的任何附加信息。
- In the IPN, round-trip times may be so long and communication opportunities so brief that a negotiation exchange, such as an adjustment of transmission rate, might not be completed before connectivity is lost. Even if connectivity is uninterrupted, waiting for negotiation to complete before revising data transmission parameters might well result in costly under-utilization of link resources.
- 在IPN中，往返时间可能很长，通信机会可能很短，以至于在连接丢失之前，协商交换（例如传输速率的调整）可能无法完成。即使连接性是不间断的，在修改数据传输参数之前等待协商完成也很可能导致链路资源利用率低下。
- Another respect in which LTP differs from TCP is that, while TCP connections are bidirectional (blocks of application data may be flowing in both directions on any single connection), LTP sessions are unidirectional. This design decision derives from the fact that the flow of data in deep-space flight missions is usually unidirectional. (Long round-trip times make interactive spacecraft operation infeasible, so spacecraft are largely autonomous and command traffic is very light.) Bidirectional data flow, where possible, is performed using two unidirectional links in opposite directions and at different data rates.
- LTP不同于TCP的另一个方面是，虽然TCP连接是双向的（应用程序数据块可以在任何单个连接上双向流动），但LTP会话是单向的。这一设计决策源于深空飞行任务中的数据流通常是单向的。（长的往返时间使得交互式航天器操作不可行，因此航天器在很大程度上是自主的，指挥交通量很小。）双向数据流（如有可能）使用两个方向相反的单向链路以不同的数据速率进行。
- Finally, the problem of timeout interval computation in the environment for which LTP is mainly intended is different from the analogous problem in the Internet. Since multiple sessions can be conducted in parallel, retardation of transmission on any single session while awaiting a timeout need not degrade communication performance on the association as a whole. Timeout intervals that would be intolerably optimistic in TCP don't necessarily degrade LTP's bandwidth utilization.
- 最后，LTP主要用于的环境中的超时间隔计算问题不同于Internet中的类似问题。由于多个会话可以并行进行，因此在等待超时的同时延迟任何单个会话上的传输不必降低整个关联的通信性能。TCP中过于乐观的超时间隔不一定会降低LTP的带宽利用率。
But the reciprocal half-duplex nature of LTP communication makes it infeasible to use statistical analysis of round-trip history as a means of predicting round-trip time. The round-trip time for transmitted segment N could easily be orders of magnitude greater than that for segment N-1 if there happened to be a transient loss of connectivity between the segment transmissions. A different mechanism for timeout interval computation is needed.
但是LTP通信的倒数半双工特性使得使用往返历史的统计分析作为预测往返时间的手段是不可行的。如果在段传输之间发生瞬时连接丢失，则传输段N的往返时间很容易比传输段N-1的往返时间大几个数量级。需要一种不同的超时间隔计算机制。
These environmental characteristics -- long and highly variable delays, intermittent connectivity, and relatively high error rates -- make using unmodified TCP for end-to-end communications in the IPN infeasible. Using the TCP throughput equation from [TFRC] we can calculate the loss event rate (p) required to achieve a given steady-state throughput. Assuming the minimum RTT to Mars from planet Earth is 8 minutes (one-way speed of light delay to Mars at its closest approach to Earth is 4 minutes), assuming a packet size of 1500 bytes, assuming that the receiver acknowledges every other packet, and ignoring negligible higher-order terms in p (i.e., ignoring the second additive term in the denominator of the TCP throughput equation), we obtain the following table of loss event rates required to achieve various throughput values.
这些环境特征——长且高度可变的延迟、间歇性连接和相对较高的错误率——使得在IPN中使用未经修改的TCP进行端到端通信变得不可行。使用[TFRC]中的TCP吞吐量方程，我们可以计算实现给定稳态吞吐量所需的丢失事件率（p）。假设从地球到火星的最小RTT为8分钟（距离地球最近的火星的单向光速延迟为4分钟），假设数据包大小为1500字节，假设接收器每隔一个数据包确认一次数据包，并忽略p中可忽略的高阶项（即，忽略TCP吞吐量方程分母中的第二个加法项），我们获得了实现各种吞吐量值所需的丢失事件率的下表。
Throughput Loss event rate (p)
---------- -------------------
10 Mbps 4.68 * 10^(-12)
1 Mbps 4.68 * 10^(-10)
100 Kbps 4.68 * 10^(-8)
10 Kbps 4.68 * 10^(-6)
Throughput Loss event rate (p)
---------- -------------------
10 Mbps 4.68 * 10^(-12)
1 Mbps 4.68 * 10^(-10)
100 Kbps 4.68 * 10^(-8)
10 Kbps 4.68 * 10^(-6)
Note that although multiple losses encountered in a single RTT are treated as a single loss event in the TCP throughput equation [TFRC], such loss event rates are still unrealistic on deep-space links.
请注意，尽管在TCP吞吐量方程[TFRC]中将单个RTT中遇到的多个丢失视为单个丢失事件，但这种丢失事件率在深空链路上仍然不现实。
For the purposes of this discussion, we are not considering the more aggressive TCP throughput equation that characterizes HighSpeed TCP [HSTCP].
在本讨论中，我们不考虑表征高速TCP[HSTCP]的更具攻击性的TCP吞吐量方程。
The TCP characteristic of an initial three-way handshake for each new connection, followed by slow-start, is a further obstacle, because the delay of the three-way handshake and the additional delay of slow-start could be exorbitant in a long-delay environment.
每个新连接的初始三方握手，然后缓慢启动的TCP特性是另一个障碍，因为在长延迟环境中，三方握手的延迟和额外的缓慢启动延迟可能过高。
The Stream Control Transmission Protocol (SCTP) [SCTP] can multiplex "chunks" (units of application data) for multiple sessions over a single-layer connection (called an 'association' in SCTP terminology) as LTP does, but it still requires multiple round trips prior to transmitting application data for session setup and so clearly does not suit the needs of the IPN operating environment.
流控制传输协议（SCTP）[SCTP]可以像LTP一样，通过单层连接（在SCTP术语中称为“关联”）对多个会话的“块”（应用数据单元）进行多路复用，但在传输应用程序数据进行会话设置之前，它仍然需要多次往返，因此显然不适合IPN操作环境的需要。
The nominal sequence of events in an LTP transmission session is as follows.
LTP传输会话中的标称事件顺序如下所示。
Operation begins when a client service instance asks an LTP engine to transmit a block of data to a remote client service instance.
当客户端服务实例请求LTP引擎将数据块传输到远程客户端服务实例时，操作开始。
LTP regards each block of data as comprising two parts: a "red-part", whose delivery must be assured by acknowledgment and retransmission as necessary, followed by a "green-part" whose delivery is attempted, but not assured. The length of either part may be zero; that is, any given block may be designated entirely red (retransmission continues until reception of the entire block has been asserted by the receiver) or entirely green (no part of the block is acknowledged or retransmitted). Thus, LTP can provide both TCP-like and UDP-like functionality concurrently on a single session.
LTP将每个数据块视为包含两个部分：一个“红色部分”，其交付必须通过确认和必要的重新传输来保证，然后是一个“绿色部分”，其交付是尝试的，但不保证。任何一部分的长度都可以为零；也就是说，任何给定的块可以被指定为完全红色（重新传输继续，直到接收器已经断言接收到整个块为止）或完全绿色（没有对块的任何部分进行确认或重新传输）。因此，LTP可以在单个会话上同时提供类似TCP和UDP的功能。
Note that in a red-green block transmission, the red-part data does NOT have any urgency or higher-priority semantics relative to the block's green-part data. The red-part data is merely data for which the user has requested reliable transmission, possibly (though not necessarily) data without which the green-part data may be useless, such as an application-layer header or other metadata.
注意，在红绿块传输中，红色部分数据相对于块的绿色部分数据没有任何紧急性或更高优先级语义。红色部分数据仅仅是用户已请求可靠传输的数据，可能（尽管不一定）没有绿色部分数据可能无用的数据，例如应用层报头或其他元数据。
The client service instance uses the LTP implementation's application programming interface to specify to LTP the identity of the remote client service instance to which the data must be transmitted, the location of the data to be transmitted, the total length of data to be transmitted, and the number of leading data bytes that are to be transmitted reliably as "red" data. The sending engine starts a transmission session for this block and notifies the client service instance that the session has been started. Note that
客户端服务实例使用LTP实现的应用程序编程接口向LTP指定必须向其传输数据的远程客户端服务实例的标识、要传输的数据的位置、要传输的数据的总长度，以及要作为“红色”数据可靠传输的前导数据字节数。发送引擎启动此块的传输会话，并通知客户端服务实例该会话已启动。注意
LTP communication session parameters are not negotiated but are instead asserted unilaterally, subject to application-level network management activity; the sending engine does not negotiate the start of the session with the remote client service instance's engine.
LTP通信会话参数不进行协商，而是根据应用程序级网络管理活动单方面声明；发送引擎不会与远程客户端服务实例的引擎协商会话的启动。
The sending engine then initiates the original transmission: it queues for transmission as many data segments as are necessary to transmit the entire block, within the constraints on maximum segment size imposed by the underlying communication service. The last segment of the red-part of the block is marked as the end of red-part (EORP) indicating the end of red-part data for the block, and as a checkpoint (identified by a unique checkpoint serial number) indicating that the receiving engine must issue a reception report upon receiving the segment. The last segment of the block overall is marked end of block (EOB) indicating that the receiving engine can calculate the size of the block by summing the offset and length of the data in the segment.
然后，发送引擎启动原始传输：在底层通信服务施加的最大数据段大小限制范围内，它排队等待传输整个数据块所需的尽可能多的数据段。块的红色部分的最后一段标记为红色部分结束（EORP），表示块的红色部分结束数据，并标记为检查点（由唯一的检查点序列号标识），表示接收引擎在接收到该段时必须发出接收报告。块整体的最后一段被标记为块结束（EOB），表示接收引擎可以通过将段中数据的偏移量和长度相加来计算块的大小。
LTP is designed to run directly over a data-link layer protocol, but it may instead be deployed directly over UDP in some cases (i.e., for software development or in private local area networks). In either case, the protocol layer immediately underlying LTP is here referred to as the "local data-link layer".
LTP被设计为直接在数据链路层协议上运行，但在某些情况下，它可以直接在UDP上部署（例如，用于软件开发或专用局域网）。在任何一种情况下，紧靠LTP的协议层在这里被称为“本地数据链路层”。
At the next opportunity, subject to allocation of bandwidth to the queue into which the block data segments were written, the enqueued segments and their lengths are passed to the local data-link layer protocol (which might be UDP/IP) via the API supported by that protocol, for transmission to the LTP engine serving the remote client service instance.
在下一次机会，根据向写入块数据段的队列分配的带宽，排队的段及其长度通过该协议支持的API传递给本地数据链路层协议（可能是UDP/IP），用于传输到为远程客户端服务实例提供服务的LTP引擎。
A timer is started for the EORP, so that it can be retransmitted automatically if no response is received.
启动EORP的计时器，以便在未收到响应时自动重新传输。
The content of each local data-link layer protocol data unit (link-layer frame or UDP datagram) is required to be an integral number of LTP segments, and the local data-link layer protocol is required never to deliver incomplete LTP segments to the receiving LTP engine. When the local data-link layer protocol is UDP, 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). When the LTP authentication extension is not
要求每个本地数据链路层协议数据单元（链路层帧或UDP数据报）的内容为LTP段的整数，并且本地数据链路层协议决不能将不完整的LTP段交付给接收LTP引擎。当本地数据链路层协议为UDP时，应使用LTP身份验证[LTPEXT]扩展来确保数据完整性，除非端到端路径中数据报内容损坏的可能性可以忽略不计（如在某些专用局域网中）或者，接收和处理损坏的LTP段的后果是微不足道的（可能在软件开发期间）。当LTP身份验证扩展不可用时
used, LTP requires the local data-link layer protocol to perform integrity checking of all segments received; specifically, the local data-link layer protocol is required to detect any corrupted segments that are received and to discard them silently.
使用时，LTP要求本地数据链路层协议对接收到的所有段执行完整性检查；具体地说，需要本地数据链路层协议来检测接收到的任何损坏段，并以静默方式丢弃它们。
Received segments that are not discarded are passed up to the receiving LTP engine via the API supported by the local data-link layer protocol.
未丢弃的接收段通过本地数据链路层协议支持的API传递给接收LTP引擎。
On reception of the first data segment for the block, the receiving engine starts a reception session for this block and notifies the local instance of the relevant client service that the session has been started. In the nominal case, it receives all segments of the original transmission without error. Therefore, on reception of the EORP data segment, it responds by (a) queuing for transmission to the sending engine a report segment indicating complete reception and (b) delivering the received red-part of the block to the local instance of the client service: on reception of each data segment of the green-part, it responds by immediately delivering the received data to the local instance of the client service.
在接收到该块的第一数据段时，接收引擎启动该块的接收会话，并通知相关客户端服务的本地实例该会话已经启动。在标称情况下，它无误地接收原始传输的所有段。因此，在接收到EORP数据段时，它通过（a）排队向发送引擎发送指示完全接收的报告段和（b）将接收到的块的红色部分发送到客户端服务的本地实例来响应：在接收到绿色部分的每个数据段时，它通过立即将接收到的数据传递到客户端服务的本地实例来响应。
All delivery of data and protocol event notices to the local client service instance is performed using the LTP implementation's application programming interface.
所有数据和协议事件通知到本地客户端服务实例的传递都是使用LTP实现的应用程序编程接口执行的。
Note that since LTP data flows are unidirectional, LTP's data acknowledgments -- "reception reports" -- can't be piggybacked on data segments as in TCP. They are instead carried in a separate segment type.
注意，由于LTP数据流是单向的，所以LTP的数据确认——“接收报告”——不能像TCP中那样在数据段上进行。相反，它们以单独的分段类型进行运输。
At the next opportunity, the enqueued report segment is immediately transmitted to the sending engine and a timer is started so that the report segment can be retransmitted automatically if no response is received.
在下一次机会，排队的报告段将立即传输到发送引擎，并启动计时器，以便在未收到响应时自动重新传输报告段。
The sending engine receives the report segment, turns off the timer for the EORP, enqueues for transmission to the receiving engine a report-acknowledgment segment, and notifies the local client service instance that the red-part of the block has been successfully transmitted. The session's red-part transmission has now ended.
发送引擎接收报告段，关闭EORP的计时器，排队向接收引擎发送报告确认段，并通知本地客户端服务实例块的红色部分已成功发送。会话的红色部分传输现已结束。
At the next opportunity, the enqueued report-acknowledgment segment is immediately transmitted to the receiving engine.
在下一次机会中，排队的报告确认段将立即发送到接收引擎。
The receiving engine receives the report-acknowledgment segment and turns off the timer for the report segment. The session's red-part reception has now ended and transmission of the block is complete.
接收引擎接收报告确认段并关闭报告段的计时器。会话的红色部分接收现已结束，块的传输已完成。
Establishing a communication link across interplanetary distances may entail hardware configuration changes based on the presumed operational state of the remote communicating entity, for example:
跨行星际距离建立通信链路可能需要基于远程通信实体的假定操作状态进行硬件配置更改，例如：
o orienting a directional antenna correctly;
o 正确定向定向天线；
o tuning a transponder to pre-selected transmission and/or reception frequencies; and
o 将应答器调谐到预先选择的发射和/或接收频率；和
o diverting precious electrical power to the transponder at the last possible moment, and for the minimum necessary length of time.
o 在最后一个可能的时刻，将宝贵的电力转移到应答器上，并持续最短的必要时间。
We therefore assume that the operating environment in which LTP functions is able to pass information on the link status (termed "link state cues" in this document) to LTP, telling it which remote LTP engine(s) should currently be transmitting to the local LTP engine and vice versa. The operating environment itself must have this information in order to configure communication link hardware correctly.
因此，我们假设LTP功能所在的操作环境能够将链路状态信息（本文档中称为“链路状态提示”）传递给LTP，告知其当前应将哪个远程LTP引擎传输到本地LTP引擎，反之亦然。为了正确配置通信链路硬件，操作环境本身必须具有此信息。
Link state cues also notify LTP when it is and isn't possible to transmit segments. In deep-space communications, at no moment can there ever be any expectation of two-way connectivity. It is always possible for LTP to be generating outbound segments -- in response to received segments, timeouts, or requests from client services -- that cannot immediately be transmitted. These segments must be queued for transmission at a later time when a link has been established, as signaled by a link state cue.
链路状态提示还通知LTP是否可以传输段。在深空通信中，任何时候都不可能有任何双向连接的期望。LTP总是可能生成出站段，以响应接收到的段、超时或来自客户端服务的请求，而这些段不能立即传输。这些段必须排队等待稍后建立链路时的传输，如链路状态提示所示。
In concept, every outbound LTP segment is appended to one of two queues -- forming a queue-set -- of traffic bound for the LTP engine that is that segment's destination. One such traffic queue is the "internal operations queue" of that queue set; the other is the application data queue for the queue set. The de-queuing of a segment always implies delivering it to the underlying communication system for immediate transmission. Whenever the internal operations queue is non-empty, the oldest segment in that queue is the next segment de-queued for transmission to the destination; at all other times, the oldest segment in the application data queue is the next segment de-queued for transmission to the destination.
在概念上，每个出站LTP段都附加到两个队列中的一个，形成一个队列集，该队列是LTP引擎（该段的目的地）绑定的流量。一个这样的业务队列是该队列集的“内部操作队列”；另一个是队列集的应用程序数据队列。段的解排队总是意味着将其传送到底层通信系统以便立即传输。每当内部操作队列为非空时，该队列中最早的段就是下一个被解列以传输到目的地的段；在所有其他时间，应用程序数据队列中最旧的段是为传输到目的地而解列的下一段。
The production and enqueuing of a segment and the subsequent actual transmission of that segment are in principle wholly asynchronous.
段的产生和排队以及该段的后续实际传输原则上完全是异步的。
In the event that (a) a transmission link to the destination is currently active and (b) the queue to which a given outbound segment is appended is otherwise empty and (c) either this queue is the internal operations queue or else the internal operations queue is empty, the segment will be transmitted immediately upon production. Transmission of a newly queued segment is necessarily deferred in all other circumstances.
如果（a）到目的地的传输链路当前处于活动状态，并且（b）附加了给定出站段的队列在其他情况下为空，并且（c）该队列是内部操作队列，或者内部操作队列为空，则该段将在生产时立即传输。在所有其他情况下，新排队段的传输必须延迟。
Conceptually, the de-queuing of segments from traffic queues bound for a given destination is initiated upon reception of a link state cue indicating that the underlying communication system is now transmitting to that destination; i.e., the link to that destination is now active. It ceases upon reception of a link state cue indicating that the underlying communication system is no longer transmitting to that destination; i.e., the link to that destination is no longer active.
从概念上讲，在接收到指示基础通信系统现在正在向该目的地发送的链路状态提示时，发起从绑定到给定目的地的业务队列的分段的解排队；i、 例如，到该目的地的链接现在处于活动状态。它在接收到指示基础通信系统不再向该目的地发送的链路状态提示时停止；i、 例如，到该目的地的链接不再处于活动状态。
LTP relies on accurate calculation of expected arrival times for report and acknowledgment segments in order to know when proactive retransmission is required. If a calculated time were even slightly early, the result would be costly unnecessary retransmission. On the other hand, calculated arrival times may safely be several seconds late: the only penalties for late timeout and retransmission are slightly delayed data delivery and slightly delayed release of session resources.
LTP依赖于准确计算报告和确认段的预期到达时间，以便知道何时需要主动重传。如果计算出的时间甚至稍早，结果将是代价高昂的不必要的重新传输。另一方面，计算的到达时间可能安全地延迟几秒钟：延迟超时和重新传输的唯一惩罚是稍微延迟数据交付和稍微延迟会话资源的释放。
Since statistics derived from round-trip history cannot safely be used as a predictor of LTP round-trip times, we have to assume that round-trip timing is at least roughly deterministic -- i.e., that sufficiently accurate RTT estimates can be computed individually in real time from available information.
由于从往返历史中得出的统计数据不能安全地用作LTP往返时间的预测值，因此我们必须假设往返时间至少是大致确定的——即，可以根据可用信息实时单独计算足够准确的RTT估计值。
This computation is performed in two stages:
此计算分两个阶段进行：
- We calculate a first approximation of RTT by simply doubling the known one-way light time to the destination and adding an arbitrary margin for any additional anticipated latency, such as queuing and processing delay at both ends of the transmission. For deep-space operations, the margin value is typically a small number of whole seconds. Although such a margin is enormous by Internet standards, it is insignificant compared to the two-way
- 我们通过简单地将到达目的地的已知单向光照时间加倍，并为任何额外的预期延迟（如传输两端的排队和处理延迟）添加任意裕度，来计算RTT的第一近似值。对于深空操作，边距值通常为整秒的一小部分。尽管以互联网标准衡量，这样的差距是巨大的，但与双向网络相比，这是微不足道的
light time component of round-trip time in deep space. We choose to risk tardy retransmission, which will postpone delivery of one block by a relatively tiny increment, in preference to premature retransmission, which will unnecessarily consume precious bandwidth and thereby degrade overall performance.
深空往返时间的光时间成分。我们选择冒重传延迟的风险，这将使一个数据块的交付延迟相对较小的增量，而不是过早重传，过早重传将不必要地消耗宝贵的带宽，从而降低整体性能。
- Then, to account for the additional delay imposed by interrupted connectivity, we dynamically suspend timers during periods when the relevant remote LTP engines are known to be unable to transmit responses. This knowledge of the operational state of remote entities is assumed to be provided by link state cues from the operating environment.
- 然后，为了考虑连接中断带来的额外延迟，我们在相关远程LTP引擎无法传输响应的期间动态暂停计时器。远程实体的操作状态的这种知识假定是由来自操作环境的链路状态提示提供的。
The following discussion is the basis for LTP's expected arrival time calculations.
以下讨论是LTP预计到达时间计算的基础。
The total time consumed in a single "round trip" (transmission and reception of the original segment, followed by transmission and reception of the acknowledging segment) has the following components:
单次“往返”所消耗的总时间（原始段的发送和接收，然后是确认段的发送和接收）由以下部分组成：
- Protocol processing time: The time consumed in issuing the original segment, receiving the original segment, generating and issuing the acknowledging segment, and receiving the acknowledging segment.
- 协议处理时间：发出原始段、接收原始段、生成和发出确认段、接收确认段所消耗的时间。
- Outbound queuing delay: The delay at the sender of the original segment while that segment is in a queue waiting for transmission, and delay at the sender of the acknowledging segment while that segment is in a queue waiting for transmission.
- 出站排队延迟：当原始段在队列中等待传输时，原始段发送方的延迟，以及当该段在队列中等待传输时，确认段发送方的延迟。
- Radiation time: The time that passes while all bits of the original segment are being radiated, and the time that passes while all bits of the acknowledging segment are being radiated. (This is significant only at extremely low data transmission rates.)
- 辐射时间：原始段的所有位被辐射时经过的时间，以及确认段的所有位被辐射时经过的时间。（这仅在极低的数据传输速率下才有意义。）
- Round-trip light time: The signal propagation delay at the speed of light, in both directions.
- 往返光时间：信号在两个方向上以光速传播的延迟。
- Inbound queuing delay: Delay at the receiver of the original segment while that segment is in a reception queue, and delay at the receiver of the acknowledging segment while that segment is in a reception queue.
- 入站排队延迟：当原始段在接收队列中时，该段接收器的延迟，以及当该段在接收队列中时，确认段接收器的延迟。
- Delay in transmission of the original segment or the acknowledging segment due to loss of connectivity -- that is, interruption in outbound link activity at the sender of either segment due to occultation, scheduled end of tracking pass, etc.
- 由于连接中断，原始段或确认段的传输延迟——也就是说，由于掩星、预定跟踪通道结束等原因，任一段的发送方的出站链路活动中断。
In this context, where errors on the order of seconds or even minutes may be tolerated, protocol processing time at each end of the session is assumed to be negligible.
在这种情况下，如果可以容忍秒级甚至分钟级的错误，则假定会话每结束时的协议处理时间可以忽略不计。
Inbound queuing delay is also assumed to be negligible because, even on small spacecraft, LTP processing speeds are high compared to data transmission rates.
由于即使在小型航天器上，LTP处理速度也比数据传输速率高，因此也假定入站排队延迟可以忽略不计。
Two mechanisms are used to make outbound queuing delay negligible:
使用两种机制使出站排队延迟可以忽略：
- The expected arrival time of an acknowledging segment is not calculated until the moment the underlying communication system notifies LTP that radiation of the original segment has begun. All outbound queuing delay for the original segment has already been incurred at that point.
- 直到底层通信系统通知LTP原始段的辐射已经开始时，才计算确认段的预期到达时间。原始段的所有出站排队延迟已在该点发生。
- LTP's deferred transmission model minimizes latency in the delivery of acknowledging segments (reports and acknowledgments) to the underlying communication system. That is, acknowledging segments are (in concept) appended to the internal operations queue rather than the application data queue, so they have higher transmission priority than any other outbound segments, i.e., they should always be de-queued for transmission first. This limits outbound queuing delay for a given acknowledging segment to the time needed to de-queue and radiate all previously generated acknowledging segments that have not yet been de-queued for transmission. Since acknowledging segments are sent infrequently and are normally very small, outbound queuing delay for a given acknowledging segment is likely to be minimal.
- LTP的延迟传输模型最大限度地减少了向底层通信系统发送确认段（报告和确认）的延迟。也就是说，确认段（在概念上）被附加到内部操作队列而不是应用程序数据队列，因此它们比任何其他出站段具有更高的传输优先级，即，它们应该总是首先被解列以进行传输。这将给定确认段的出站排队延迟限制为取消排队所需的时间，并辐射所有之前生成的尚未取消排队以进行传输的确认段。由于确认段不经常发送，并且通常非常小，因此给定确认段的出站排队延迟可能最小。
Deferring calculation of the expected arrival time of the acknowledging segment until the moment at which the original segment is radiated has the additional effect of removing from consideration any original segment transmission delay due to loss of connectivity at the original segment sender.
将确认段的预期到达时间的计算推迟到原始段被辐射的时刻，具有额外的效果，即消除由于原始段发送方的连接丢失而导致的任何原始段传输延迟。
Radiation delay at each end of the session is simply segment size divided by transmission data rate. It is insignificant except when the data rate is extremely low (for example, 10 bps), in which case the use of LTP may well be inadvisable for other reasons (LTP header overhead, for example, could be too much under such data rates). Therefore, radiation delay is normally assumed to be negligible.
会话每结束时的辐射延迟只是段大小除以传输数据速率。除了数据速率极低（例如，10 bps）的情况外，它是无关紧要的，在这种情况下，由于其他原因（例如，在这种数据速率下，LTP报头开销可能太大），LTP的使用可能是不可取的。因此，通常认为辐射延迟可以忽略不计。
We assume that one-way light time to the nearest second can always be known (for example, provided by the operating environment).
我们假设到最近秒的单向光照时间总是可以知道的（例如，由操作环境提供）。
So the initial expected arrival time for each acknowledging segment is typically computed as simply the current time at the moment that radiation of the original segment begins, plus twice the one-way light time, plus 2*N seconds of margin to account for processing and queuing delays and for radiation time at both ends. N is a parameter set by network management for which 2 seconds seem to be a reasonable default value.
因此，每个确认段的初始预期到达时间通常仅计算为原始段开始辐射时的当前时间，加上两倍的单向光照时间，再加上2*N秒的余量，以考虑处理和排队延迟以及两端的辐射时间。N是网络管理设置的参数，2秒似乎是合理的默认值。
This leaves only one unknown, the additional round-trip time introduced by loss of connectivity at the sender of the acknowledging segment. To account for this, we again rely on external link state cues. Whenever interruption of transmission at a remote LTP engine is signaled by a link state cue, we suspend the countdown timers for all acknowledging segments expected from that engine. Upon a signal that transmission has resumed at that engine, we resume those timers after (in effect) adding to each expected arrival time the length of the timer suspension interval.
这只留下了一个未知值，即由于确认段的发送方失去连接而导致的额外往返时间。为了解释这一点，我们再次依赖外部链接状态提示。当远程LTP引擎的传输中断由链路状态提示发出信号时，我们暂停该引擎预期的所有确认段的倒计时。在该引擎上传输已恢复的信号发出后，我们在（实际上）将计时器暂停间隔的长度添加到每个预期到达时间之后恢复这些计时器。
Loss or corruption of transmitted segments may cause the operation of LTP to deviate from the nominal sequence of events described above.
传输段的丢失或损坏可能导致LTP的操作偏离上述标称事件序列。
Loss of one or more red-part data segments other than the EORP segment triggers data retransmission: the receiving engine returns a reception report detailing all the contiguous ranges of red-part data received (assuming no discretionary checkpoints were received, which are described below). The reception report is normally sent in a single report segment that carries a unique report serial number and the scope of red-part data covered. For example, if the red-part data covered block offsets [0:1000] and all but the segment in range [500:600] were received, the report segment with a unique serial number (say 100) and scope [0:1000] would carry two report entries: (0:500) and (600:1000). The maximum size of a report segment, like all LTP segments, is constrained by the data-link MTU; if many non-contiguous segments were lost in a large block transmission and/or the data-link MTU was relatively small, multiple report segments need to be generated. In this case, LTP generates as many report segments as are necessary and splits the scope of red-part data covered across multiple report segments so that each of them may stand on their own. For example, if three report segments are to be generated as part of a reception report covering red-part data in range [0:1,000,000], they could look like this: RS 19, scope [0:300,000], RS 20, scope
除EORP段以外的一个或多个红色部分数据段丢失会触发数据重传：接收引擎返回一份接收报告，详细说明接收到的红色部分数据的所有连续范围（假设未接收到任意检查点，如下所述）。接收报告通常在单个报告段中发送，该报告段带有唯一的报告序列号和包含的红色部分数据范围。例如，如果接收到红色零件数据覆盖的块偏移量[0:1000]和范围[500:600]内的所有段，则具有唯一序列号（例如100）和范围[0:1000]的报告段将包含两个报告条目：（0:500）和（600:1000）。与所有LTP段一样，报告段的最大大小受数据链路MTU的约束；如果在大数据块传输中丢失了许多非连续段和/或数据链路MTU相对较小，则需要生成多个报告段。在这种情况下，LTP会根据需要生成尽可能多的报告段，并将红色零件数据的范围划分为多个报告段，以便每个报告段都可以独立存在。例如，如果要生成三个报告段作为涵盖范围[0:1000000]内红色部分数据的接收报告的一部分，则它们可能如下所示：RS 19，作用域[0:300000]，RS 20，作用域
[300,000:950,000], and RS 21, scope [950,000:1,000,000]. In all cases, a timer is started upon transmission of each report segment of the reception report.
[300000:950000]和RS 21，范围[950000:1000000]。在所有情况下，在发送接收报告的每个报告段时启动计时器。
On reception of each report segment, the sending engine responds as follows:
在接收到每个报告段时，发送引擎的响应如下：
- It turns off the timer for the checkpoint referenced by the report segment, if any.
- 它关闭报告段引用的检查点（如果有）的计时器。
- It enqueues a reception-acknowledgment segment acknowledging the report segment (to turn off the report retransmission timer at the receiving engine). This segment is sent immediately at the next transmission opportunity.
- 它使确认报告段的接收确认段排队（以关闭接收引擎处的报告重传计时器）。此段在下一次传输机会时立即发送。
- If the reception claims in the report segment indicate that not all data within the scope have been received, it normally initiates a retransmission by enqueuing all data segments not yet received. The last such segment is marked as a checkpoint and contains the report serial number of the report segment to which the retransmission is a response. These segments are likewise sent at the next transmission opportunity, but only after all data segments previously queued for transmission to the receiving engine have been sent. A timer is started for the checkpoint, so that it can be retransmitted automatically if no responsive report segment is received.
- 如果报告段中的接收声明指示未接收范围内的所有数据，则它通常通过将尚未接收的所有数据段排队来发起重传。最后一个这样的段被标记为检查点，并包含报告段的报告序列号，该报告段的重新传输是对该报告段的响应。这些数据段同样在下一次传输机会时发送，但仅在之前排队等待传输到接收引擎的所有数据段都已发送后发送。为检查点启动计时器，以便在未收到响应报告段时自动重新传输。
- On the other hand, if the reception claims in the report segment indicate that all data within the scope of the report segment have been received, and the union of all reception claims received so far in this session indicates that all data in the red-part of the block have been received, then the sending engine notifies the local client service instance that the red-part of the block has been successfully transmitted; the session's red-part transmission has ended.
- 另一方面，如果报告段中的接收请求指示已接收到报告段范围内的所有数据，并且在该会话中迄今为止接收到的所有接收请求的并集指示已接收到块的红色部分中的所有数据，然后，发送引擎通知本地客户端服务实例块的红色部分已成功发送；会话的红色部分传输已结束。
On reception of a report-acknowledgment segment, the receiver turns off the timer for the referenced report segment.
在接收到报告确认段时，接收器关闭引用报告段的计时器。
On reception of a checkpoint segment with a non-zero report serial number, the receiving engine responds as follows:
接收到具有非零报告序列号的检查点段时，接收引擎响应如下：
- It returns a reception report comprising as many report segments as are needed in order to report in detail on all data reception within the scope of the referenced report segment, and a timer is started for each report segment.
- 它返回接收报告，该报告包含所需的任意多个报告段，以便详细报告所引用报告段范围内的所有数据接收情况，并为每个报告段启动计时器。
- If at this point all data in the red-part of the block have been received, the receiving engine delivers the received block's red-part to the local instance of the client service and, upon reception of reception-acknowledgment segments acknowledging all report segments, the session's red-part reception ends and transmission of the block is complete. Otherwise, the data retransmission cycle continues.
- 如果此时已接收到块的红色部分中的所有数据，则接收引擎将接收到的块的红色部分发送到客户端服务的本地实例，并在接收到确认所有报告段的接收确认段时，会话的红色部分接收结束，块的传输完成。否则，数据重传周期继续。
Loss of a checkpoint segment or the report segment generated in response causes timer expiry; when this occurs, the sending engine normally retransmits the checkpoint segment. Similarly, the loss of a report segment or the corresponding report-acknowledgment segment causes the report segment's timer to expire; when this occurs, the receiving engine normally retransmits the report segment.
在响应中生成的检查点段或报告段丢失会导致计时器过期；发生这种情况时，发送引擎通常会重新传输检查点段。类似地，报告段或相应报告确认段的丢失会导致报告段的计时器过期；发生这种情况时，接收引擎通常会重新传输报告段。
Note that the redundant reception of a report segment (i.e., one that was already received and processed by the sender), retransmitted due to loss of the corresponding report-acknowledgment segment for example, causes another report-acknowledgment segment to be transmitted in response but is otherwise ignored. If any of the data segments retransmitted in response to the original reception of the report segment were lost, further retransmission of those data segments will be requested by the reception report generated in response to the last retransmitted data segment marked as a checkpoint. Thus, unnecessary retransmission is suppressed.
请注意，例如，由于丢失相应的报告确认段而重新传输的报告段（即发送方已经接收和处理的报告段）的冗余接收会导致发送另一个报告确认段作为响应，但会被忽略。如果为响应报告段的原始接收而重新传输的任何数据段丢失，则为响应标记为检查点的最后一个重新传输的数据段而生成的接收报告将请求进一步重新传输这些数据段。因此，抑制了不必要的重传。
Note also that the responsibility for responding to segment loss in LTP is shared between the sender and receiver of a block: the sender retransmits checkpoint segments in response to checkpoint timeouts, and retransmits missing data in response to reception reports indicating incomplete reception, while the receiver retransmits report segments in response to timeouts. An alternative design would have been to make the sender responsible for all retransmission, in which case the receiver would not expect report-acknowledgment segments and would not retransmit report segments. There are two disadvantages to this approach:
还要注意，在LTP中响应段丢失的责任由块的发送方和接收方共同承担：发送方重新传输检查点段以响应检查点超时，并重新传输丢失的数据以响应指示接收不完整的接收报告，而接收器则根据超时情况重新传输报告段。另一种设计是让发送方负责所有重传，在这种情况下，接收方不会期望报告确认段，也不会重传报告段。这种方法有两个缺点：
First, because of constraints on segment size that might be imposed by the underlying communication service, it is at least remotely possible that the response to any single checkpoint might be multiple report segments. An additional sender-side mechanism for detecting and appropriately responding to the loss of some proper subset of those reception reports would be needed. We believe that the current design is simpler.
首先，由于底层通信服务可能会对段大小施加限制，因此对任何单个检查点的响应至少可能是多个报告段。需要一种额外的发送方机制，用于检测和适当响应这些接收报告中某些适当子集的丢失。我们认为目前的设计更简单。
Second, an engine that receives a block needs a way to determine when the session can be closed. In the absence of explicit final report acknowledgment (which entails retransmission of the report in case of the loss of the report acknowledgment), the alternatives are (a) to close the session immediately on transmission of the report segment that signifies complete reception and (b) to close the session on receipt of an explicit authorization from the sender. In case (a), loss of the final report segment would cause retransmission of a checkpoint by the sender, but the session would no longer exist at the time the retransmitted checkpoint arrived. The checkpoint could reasonably be interpreted as the first data segment of a new block, most of which was lost in transit, and the result would be redundant retransmission of the entire block. In case (b), the explicit session termination segment and the responsive acknowledgment by the receiver (needed in order to turn off the timer for the termination segment, which in turn would be needed in case of in-transit loss or corruption of the termination segment) would somewhat complicate the protocol, increase bandwidth consumption, and retard the release of session state resources at the sender. Here again we believe that the current design is simpler and more efficient.
其次，接收块的引擎需要一种方法来确定会话何时可以关闭。如果没有明确的最终报告确认（在报告确认丢失的情况下需要重新传输报告），备选方案是（a）在传输表示完全接收的报告段时立即关闭会话，以及（b）在收到发件人的明确授权后关闭会话。在情况（a）中，丢失最终报告段将导致发送方重新传输检查点，但在重新传输的检查点到达时，会话将不再存在。检查点可以合理地解释为新块的第一个数据段，其中大部分在传输过程中丢失，其结果将是整个块的冗余重传。在情况（b）中，显式会话终止段和接收器的响应确认（需要关闭终止段的计时器，而在传输中丢失或损坏终止段的情况下，需要关闭计时器）将使协议复杂化，增加带宽消耗，并延迟在发送方释放会话状态资源。在这里，我们再次相信当前的设计更简单、更高效。
Data segment retransmission occurs only on receipt of a report segment indicating incomplete reception; report segments are normally transmitted only at the end of original transmission of the red-part of a block or at the end of a retransmission. For some applications, it may be desirable to trigger data segment retransmission incrementally during the course of red-part original transmission so that the missing segments are recovered sooner. This can be accomplished in two ways:
数据段重发仅在接收到表明接收不完整的报告段时发生；报告段通常仅在块的红色部分的原始传输结束时或在重传结束时传输。对于一些应用，可能希望在红色部分原始传输过程中增量触发数据段重传，以便更快地恢复丢失的段。这可以通过两种方式实现：
- Any red-part data segment prior to the EORP can additionally be flagged as a checkpoint. Reception of each such "discretionary" checkpoint causes the receiving engine to issue a reception report.
- EORP之前的任何红色零件数据段还可以标记为检查点。接收每个这样的“任意”检查点会导致接收引擎发出接收报告。
- At any time during the original transmission of a block's red-part (that is, prior to reception of any data segment of the block's green-part), the receiving engine can unilaterally issue additional asynchronous reception reports. Note that the CFDP protocol's "Immediate" mode is an example of this sort of asynchronous reception reporting [CFDP]. The reception reports generated for accelerated retransmission are processed in exactly the same way as the standard reception reports.
- 在块的红色部分的原始传输期间的任何时候（即，在接收块的绿色部分的任何数据段之前），接收引擎都可以单方面发出额外的异步接收报告。注意，CFDP协议的“立即”模式就是这种异步接收报告[CFDP]的一个例子。以与标准接收报告完全相同的方式处理为加速重传生成的接收报告。
A transmission session may be canceled by either the sending or the receiving engine in response either to a request from the local client service instance or to an LTP operational failure as noted earlier. Session cancellation is accomplished as follows.
发送或接收引擎可以响应来自本地客户端服务实例的请求或前面提到的LTP操作故障来取消传输会话。会话取消按如下方式完成。
The canceling engine deletes all currently queued segments for the session and notifies the local instance of the affected client service that the session is canceled. If no segments for this session have yet been sent to or received from the corresponding LTP engine, then at this point the canceling engine simply closes its state record for the session and cancellation is complete.
取消引擎删除会话的所有当前排队段，并通知受影响客户端服务的本地实例会话已取消。如果此会话的任何段尚未发送到相应的LTP引擎或从相应的LTP引擎接收到，则此时取消引擎仅关闭其会话状态记录，取消完成。
Otherwise, a session cancellation segment is queued for transmission. At the next opportunity, the enqueued cancellation segment is immediately transmitted to the LTP engine serving the remote client service instance. A timer is started for the segment, so that it can be retransmitted automatically if no response is received.
否则，会话取消段将排队等待传输。在下一次机会中，排队取消段将立即传输到为远程客户端服务实例服务的LTP引擎。为该段启动计时器，以便在未收到响应时自动重新传输该段。
The corresponding engine receives the cancellation segment, enqueues for transmission to the canceling engine a cancellation-acknowledgment segment, deletes all other currently queued segments for the indicated session, notifies the local client service instance that the block has been canceled, and closes its state record for the session.
相应的引擎接收取消段，排队等待向取消引擎发送取消确认段，删除指示会话的所有其他当前排队段，通知本地客户端服务实例该块已被取消，并关闭其会话状态记录。
At the next opportunity, the enqueued cancellation-acknowledgment segment is immediately transmitted to the canceling engine.
在下一次机会中，排队的取消确认段将立即传输到取消引擎。
The canceling engine receives the cancellation-acknowledgment, turns off the timer for the cancellation segment, and closes its state record for the session.
取消引擎接收取消确认，关闭取消段的计时器，并关闭会话的状态记录。
Loss of a cancellation segment or of the responsive cancellation-acknowledgment causes the cancellation segment timer to expire. When this occurs, the canceling engine retransmits the cancellation segment.
取消段或响应取消确认的丢失会导致取消段计时器过期。发生这种情况时，取消引擎将重新传输取消段。
There is a clear risk that unintended receivers can listen in on LTP transmissions over satellite and other radio broadcast data links. Such unintended recipients of LTP transmissions may also be able to manipulate LTP segments at will.
显然存在这样一种风险，即无意中的接收器可能通过卫星和其他无线电广播数据链路监听LTP传输。这种LTP传输的非预期接收者也可以随意操纵LTP段。
Hence, there is a potential requirement for confidentiality, integrity, and anti-DoS (Denial of Service) security services and mechanisms.
因此，对保密性、完整性和反DoS（拒绝服务）安全服务和机制有潜在的要求。
In particular, DoS problems are more severe for LTP compared to typical Internet protocols because LTP inherently retains state for long periods and has very long time-out values. Further, it could be difficult to reset LTP nodes to recover from an attack. Thus, any adversary who can actively attack an LTP transmission has the potential to create severe DoS conditions for the LTP receiver.
特别是，与典型的Internet协议相比，LTP的DoS问题更为严重，因为LTP固有地长时间保持状态，并且具有很长的超时值。此外，可能很难重置LTP节点以从攻击中恢复。因此，任何能够主动攻击LTP传输的对手都有可能为LTP接收器造成严重的拒绝服务条件。
To give a terrestrial example: were LTP to be used in a sparse sensor network, DoS attacks could be mounted resulting in nodes missing critical information, such as communications schedule updates. In such cases, a single successful DoS attack could take a node entirely off the network until the node was physically visited and reset.
举一个地面示例：如果LTP用于稀疏传感器网络，可能会发起DoS攻击，导致节点丢失关键信息，例如通信计划更新。在这种情况下，一次成功的DoS攻击可能会使节点完全脱离网络，直到该节点被物理访问并重置。
Even for deep-space applications of LTP, we need to consider certain terrestrial attacks, in particular those involving insertion of messages into an ongoing session (usually without having seen the exact bytes of the previous messages in the session). Such attacks are likely in the presence of firewall failures at various nodes in the network, or due to Trojan software running on an authorized host. Many message insertion attacks will depend on the attacker correctly "guessing" something about the state of the LTP peers, but experience shows that successful guesses are easier than might be thought [DDJ].
即使对于LTP的深空应用，我们也需要考虑某些地面攻击，特别是涉及将消息插入正在进行的会话中（通常没有看到会话中的先前消息的确切字节）。此类攻击可能发生在网络中的各个节点出现防火墙故障时，或者由于授权主机上运行的特洛伊木马软件而导致。许多消息插入攻击将取决于攻击者是否正确地“猜测”LTP对等方的状态，但经验表明，成功的猜测比想象的要容易[DDJ]。
We now consider the appropriate layer(s) at which security mechanisms can be deployed to increase the security properties of LTP, and the trade-offs entailed in doing so.
我们现在考虑适当的层，在其中可以部署安全机制来增加LTP的安全属性，并且在这样做时需要权衡。
The Application layer (above-LTP)
应用层（LTP之上）
Higher-layer security mechanisms clearly protect LTP payload, but leave LTP headers open. Such mechanisms provide little or no protection against DoS type attacks against LTP, but may well provide sufficient data integrity and ought to be able to provide data confidentiality.
更高层的安全机制明显地保护LTP有效负载，但保持LTP头处于打开状态。这种机制对针对LTP的DoS类型攻击提供的保护很少或没有，但很可能提供足够的数据完整性，并且应该能够提供数据机密性。
The LTP layer
LTP层
An authentication header (similar to IPsec [AH]) can help protect against replay attacks and other bogus packets. However, an adversary may still see the LTP header of segments passing by in the ether. This approach also requires some key management infrastructure to be in place in order to provide strong authentication, which may not always be an acceptable overhead. Such an authentication header could mitigate many DoS attacks.
身份验证头（类似于IPsec[AH]）可以帮助防止重播攻击和其他伪造数据包。但是，敌方仍可能看到以太网络中经过的段的LTP头。这种方法还需要一些密钥管理基础设施，以便提供强身份验证，这可能并不总是可以接受的开销。这样的身份验证标头可以减轻许多DoS攻击。
Similarly, a confidentiality service could be defined for LTP payload and (some) header fields. However, this seems less attractive since (a) confidentiality is arguably better provided either above or below the LTP layer, (b) key management for such a service is harder (in a high-delay context) than for an integrity service, and (c) forcing LTP engines to attempt decryption of incoming segments can in itself provide a DoS opportunity.
类似地，可以为LTP有效负载和（某些）头字段定义保密服务。然而，这似乎不太吸引人，因为（a）机密性可以在LTP层之上或之下更好地提供，（b）此类服务的密钥管理（在高延迟上下文中）比完整性服务更难，（c）强制LTP引擎尝试解密传入段本身就可以提供DoS机会。
Further, within the LTP layer we can make various design decisions to reduce the probability of successful DoS attacks. In particular, we can mandate that values for certain fields in the header (session numbers, for example) be chosen randomly.
此外，在LTP层中，我们可以做出各种设计决策，以降低成功DoS攻击的概率。特别是，我们可以强制头中某些字段的值（例如会话号）随机选择。
The Data-link layer (below-LTP)
数据链路层（LTP以下）
The lower layers can clearly provide confidentiality and integrity services, although such security may result in unnecessary overhead if the cryptographic service provided is not required for all data. For example, it can be harder to manage lower layers so that only the data that requires encryption is in fact encrypted. Encrypting all data could represent a significant overhead for some LTP use cases. However, the lower layers are often the place where compression and error-correction is done, and so may well also be the optimal place to do encryption since the same issues with applying or not applying the service apply to both encryption and compression.
较低的层可以清楚地提供机密性和完整性服务，尽管如果并非所有数据都需要提供加密服务，则这种安全性可能会导致不必要的开销。例如，管理较低的层可能会更困难，因此实际上只对需要加密的数据进行加密。对所有数据进行加密可能会对某些LTP用例造成很大的开销。然而，较低的层通常是进行压缩和纠错的地方，因此也可能是进行加密的最佳位置，因为应用或不应用服务的问题同样适用于加密和压缩。
In light of these considerations, LTP includes the following security mechanisms:
鉴于这些考虑，LTP包括以下安全机制：
The optional LTP Authentication mechanism is an LTP segment extension comprising a ciphersuite identifier and optional key identifier that precede the segment's content, plus an authentication value (either a message authentication code or a digital signature) that follows the segment's content; the ciphersuite ID is used to indicate the length and format of the authentication value. The authentication mechanism serves to assure the segment's integrity and, depending on the ciphersuite selected and the key management regime, its authenticity.
可选LTP认证机制是LTP段扩展，包括段内容之前的密码套件标识符和可选密钥标识符，以及段内容之后的认证值（消息认证码或数字签名）；ciphersuite ID用于指示身份验证值的长度和格式。身份验证机制用于确保段的完整性，并根据选择的密码套件和密钥管理机制确保其真实性。
The optional LTP cookie mechanism is an LTP segment extension comprising a "cookie" -- a randomly chosen numeric value -- that precedes the segment's content. By increasing the number of bytes in a segment that cannot be easily predicted by an inauthentic data source, and by requiring that segments lacking the correct values of these bytes be silently discarded, the cookie mechanism increases the difficulty of mounting a successful denial-of-service attack on an LTP engine.
可选的LTP cookie机制是一个LTP段扩展，它包含一个“cookie”——一个随机选择的数值——位于段内容之前。通过增加不真实数据源无法轻易预测的段中的字节数，并要求悄悄丢弃缺少这些字节正确值的段，cookie机制增加了在LTP引擎上成功实施拒绝服务攻击的难度。
The above mechanisms are defined in detail in the LTP extensions document [LTPEXT].
上述机制在LTP扩展文档[LTPEXT]中有详细定义。
In addition, the serial numbers of LTP checkpoints and reports are required to be randomly chosen integers, and implementers are encouraged to choose session numbers randomly as well. This randomness adds a further increment of protection against DoS attacks. See [PRNG] for recommendations related to randomness.
此外，LTP检查点和报告的序列号必须是随机选择的整数，并且鼓励实施者也随机选择会话号。这种随机性进一步增加了防御DoS攻击的能力。有关随机性的建议，请参见[PRNG]。
Please see the IANA Considerations sections of [LTPSPEC] and [LTPEXT].
请参见[LTPSPEC]和[LTPEXT]的IANA注意事项部分。
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, and Dovel Myers 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在做出各种设计决策时提出的建议和建议。这项工作是在马尼坎坦·拉马达斯（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合同的一部分。
[LTPSPEC] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider Transmission Protocol - Specification", RFC 5326, September 2008.
[LTPSPEC]Ramadas，M.，Burleigh，S.，和S.Farrell，“利克利德传输协议-规范”，RFC 5326，2008年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月。
[AH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[AH]Kent，S.，“IP认证头”，RFC 4302，2005年12月。
[BP] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007.
[BP]Scott，K.和S.Burleigh，“捆绑协议规范”，RFC 50502007年11月。
[CFDP] CCSDS File Delivery Protocol (CFDP). Recommendation for Space Data System Standards, CCSDS 727.0-B-2 BLUE BOOK Issue 1, October 2002.
[CFDP]CCSDS文件传递协议（CFDP）。《空间数据系统标准建议》，CCSDS 727.0-B-2蓝皮书，第1期，2002年10月。
[DDJ] I. Goldberg and E. Wagner, "Randomness and the Netscape Browser", Dr. Dobb's Journal, 1996, (pages 66-70).
[DDJ] I. Goldberg and E. Wagner, "Randomness and the Netscape Browser", Dr. Dobb's Journal, 1996, (pages 66-70).translate error, please retry
[DSN] Deep Space Mission Systems Telecommunications Link Design
Handbook (810-005) web-page,
"http://eis.jpl.nasa.gov/deepspace/dsndocs/810-005/"
[DSN] Deep Space Mission Systems Telecommunications Link Design
Handbook (810-005) web-page,
"http://eis.jpl.nasa.gov/deepspace/dsndocs/810-005/"
[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月。
[IPN] InterPlanetary Internet Special Interest Group web page, "http://www.ipnsig.org".
[IPN]星际互联网特别兴趣小组网页，”http://www.ipnsig.org".
[TFRC] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
[TFRC]Handley，M.，Floyd，S.，Padhye，J.，和J.Widmer，“TCP友好速率控制（TFRC）：协议规范”，RFC 3448，2003年1月。
[HSTCP] Floyd, S., "HighSpeed TCP for Large Congestion Windows", RFC 3649, December 2003.
[HSTCP]Floyd，S.，“用于大拥塞窗口的高速TCP”，RFC 3649，2003年12月。
[SCTP] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[SCTP]Stewart，R.，Ed.“流控制传输协议”，RFC 49602007年9月。
[PRNG] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[PRNG]Eastlake，D.，3rd，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 40862005年6月。
Authors' Addresses
作者地址
Scott C. Burleigh Jet Propulsion Laboratory 4800 Oak Grove Drive M/S: 301-485B 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-485B加利福尼亚州帕萨迪纳91109-8099电话：+1（818）393-3353传真：+1（818）354-1075电子邮件：斯科特。Burleigh@jpl.nasa.gov
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
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.