Internet Research Task Force (IRTF) M. Demmer
Request for Comments: 7242 UC Berkeley
Category: Experimental J. Ott
ISSN: 2070-1721 Aalto University
S. Perreault
Internet Research Task Force (IRTF) M. Demmer
Request for Comments: 7242 UC Berkeley
Category: Experimental J. Ott
ISSN: 2070-1721 Aalto University
S. Perreault
June 2014
2014年6月
Delay-Tolerant Networking TCP Convergence-Layer Protocol
容错网络TCP汇聚层协议
Abstract
摘要
This document describes the protocol for the TCP-based convergence layer for Delay-Tolerant Networking (DTN). It is the product of the IRTF's DTN Research Group (DTNRG).
本文档描述了用于延迟容忍网络（DTN）的基于TCP的聚合层协议。它是IRTF的DTN研究小组（DTNRG）的产品。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Delay-Tolerant Networking Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网研究工作组（IRTF）的产品。IRTF发布互联网相关研究和开发活动的结果。这些结果可能不适合部署。该RFC代表了互联网研究任务组（IRTF）的延迟容忍网络研究小组的共识。IRSG批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7242.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7242.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................2
2. Definitions .....................................................4
2.1. Definitions Specific to the TCPCL Protocol .................4
3. General Protocol Description ....................................5
3.1. Bidirectional Use of TCP Connection ........................6
3.2. Example Message Exchange ...................................6
4. Connection Establishment ........................................7
4.1. Contact Header .............................................8
4.2. Validation and Parameter Negotiation ......................10
5. Established Connection Operation ...............................11
5.1. Message Type Codes ........................................11
5.2. Bundle Data Transmission (DATA_SEGMENT) ...................12
5.3. Bundle Acknowledgments (ACK_SEGMENT) ......................13
5.4. Bundle Refusal (REFUSE_BUNDLE) ............................14
5.5. Bundle Length (LENGTH) ....................................15
5.6. KEEPALIVE Feature (KEEPALIVE) .............................16
6. Connection Termination .........................................17
6.1. Shutdown Message (SHUTDOWN) ...............................17
6.2. Idle Connection Shutdown ..................................18
7. Security Considerations ........................................19
8. IANA Considerations ............................................20
8.1. Port Number ...............................................20
8.2. Protocol Versions .........................................20
8.3. Message Types .............................................20
8.4. REFUSE_BUNDLE Reason Codes ................................21
8.5. SHUTDOWN Reason Codes .....................................21
9. Acknowledgments ................................................21
10. References ....................................................21
10.1. Normative References .....................................21
10.2. Informative References ...................................21
1. Introduction ....................................................2
2. Definitions .....................................................4
2.1. Definitions Specific to the TCPCL Protocol .................4
3. General Protocol Description ....................................5
3.1. Bidirectional Use of TCP Connection ........................6
3.2. Example Message Exchange ...................................6
4. Connection Establishment ........................................7
4.1. Contact Header .............................................8
4.2. Validation and Parameter Negotiation ......................10
5. Established Connection Operation ...............................11
5.1. Message Type Codes ........................................11
5.2. Bundle Data Transmission (DATA_SEGMENT) ...................12
5.3. Bundle Acknowledgments (ACK_SEGMENT) ......................13
5.4. Bundle Refusal (REFUSE_BUNDLE) ............................14
5.5. Bundle Length (LENGTH) ....................................15
5.6. KEEPALIVE Feature (KEEPALIVE) .............................16
6. Connection Termination .........................................17
6.1. Shutdown Message (SHUTDOWN) ...............................17
6.2. Idle Connection Shutdown ..................................18
7. Security Considerations ........................................19
8. IANA Considerations ............................................20
8.1. Port Number ...............................................20
8.2. Protocol Versions .........................................20
8.3. Message Types .............................................20
8.4. REFUSE_BUNDLE Reason Codes ................................21
8.5. SHUTDOWN Reason Codes .....................................21
9. Acknowledgments ................................................21
10. References ....................................................21
10.1. Normative References .....................................21
10.2. Informative References ...................................21
This document describes the TCP-based convergence-layer protocol for Delay-Tolerant Networking. Delay-Tolerant Networking is an end-to-end architecture providing communications in and/or through highly stressed environments, including those with intermittent connectivity, long and/or variable delays, and high bit error rates. More detailed descriptions of the rationale and capabilities of these networks can be found in "Delay-Tolerant Network Architecture" [RFC4838].
本文档描述了用于容错网络的基于TCP的汇聚层协议。延迟容忍网络是一种端到端体系结构，在高压力环境中和/或通过高压力环境提供通信，包括具有间歇性连接、长延迟和/或可变延迟以及高误码率的环境。关于这些网络的原理和功能的更详细描述，请参见“延迟容忍网络体系结构”[RFC4838]。
An important goal of the DTN architecture is to accommodate a wide range of networking technologies and environments. The protocol used for DTN communications is the Bundle Protocol (BP) [RFC5050], an application-layer protocol that is used to construct a store-and-
DTN体系结构的一个重要目标是适应广泛的网络技术和环境。用于DTN通信的协议是捆绑协议（BP）[RFC5050]，一种用于构建存储和存储的应用层协议-
forward overlay network. As described in the Bundle Protocol specification [RFC5050], it requires the services of a "convergence-layer adapter" (CLA) to send and receive bundles using the service of some "native" link, network, or Internet protocol. This document describes one such convergence-layer adapter that uses the well-known Transmission Control Protocol (TCP). This convergence layer is referred to as TCPCL.
前向覆盖网络。如捆绑协议规范[RFC5050]所述，它需要“汇聚层适配器”（CLA）的服务来使用某些“本机”链路、网络或Internet协议的服务发送和接收捆绑包。本文档描述了一个这样的聚合层适配器，它使用众所周知的传输控制协议（TCP）。该汇聚层称为TCPCL。
The locations of the TCPCL and the BP in the Internet model protocol stack are shown in Figure 1. In particular, when BP is using TCP as its bearer with TCPCL as its convergence layer, both BP and TCPCL reside at the application layer of the Internet model.
TCPCL和BP在Internet模型协议栈中的位置如图1所示。特别是，当BP使用TCP作为其承载，TCPCL作为其收敛层时，BP和TCPCL都位于Internet模型的应用层。
+-------------------------+
| DTN Application | -\
+-------------------------| |
| Bundle Protocol (BP) | -> Application Layer
+-------------------------+ |
| TCP Conv. Layer (TCPCL) | -/
+-------------------------+
| TCP | ---> Transport Layer
+-------------------------+
| IP | ---> Network Layer
+-------------------------+
| Link-Layer Protocol | ---> Link Layer
+-------------------------+
| Physical Medium | ---> Physical Layer
+-------------------------+
+-------------------------+
| DTN Application | -\
+-------------------------| |
| Bundle Protocol (BP) | -> Application Layer
+-------------------------+ |
| TCP Conv. Layer (TCPCL) | -/
+-------------------------+
| TCP | ---> Transport Layer
+-------------------------+
| IP | ---> Network Layer
+-------------------------+
| Link-Layer Protocol | ---> Link Layer
+-------------------------+
| Physical Medium | ---> Physical Layer
+-------------------------+
Figure 1: The Locations of the Bundle Protocol and the TCP Convergence-Layer Protocol in the Internet Protocol Stack
图1：捆绑协议和TCP聚合层协议在Internet协议栈中的位置
This document describes the format of the protocol data units passed between entities participating in TCPCL communications. This document does not address:
本文件描述了参与TCPCL通信的实体之间传递的协议数据单元的格式。本文件不涉及：
o The format of protocol data units of the Bundle Protocol, as those are defined elsewhere [RFC5050].
o 捆绑协议的协议数据单元格式，如其他地方定义的[RFC5050]。
o Mechanisms for locating or identifying other bundle nodes within an internet.
o 用于定位或标识internet中其他捆绑包节点的机制。
Note that this document describes version 3 of the protocol. Versions 0, 1, and 2 were never specified in an Internet-Draft, RFC, or any other public document. These prior versions of the protocol were, however, implemented in the DTN reference implementation [DTNIMPL] in prior releases; hence, the current version number reflects the existence of those prior versions.
请注意，本文档描述了协议的第3版。Internet草稿、RFC或任何其他公共文档中从未指定版本0、1和2。然而，这些协议的早期版本是在早期版本的DTN参考实现[DTNIMPL]中实现的；因此，当前版本号反映了先前版本的存在。
This is an experimental protocol produced within the IRTF's Delay-Tolerant Networking Research Group (DTNRG). It represents the consensus of all active contributors to this group. If this protocol is used on the Internet, IETF standard protocols for security and congestion control should be used.
这是在IRTF的延迟容忍网络研究小组（DTNRG）内产生的实验协议。它代表了该小组所有积极贡献者的共识。如果此协议在Internet上使用，则应使用IETF安全和拥塞控制标准协议。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The terms defined in Section 3.1 of [RFC5050] are used extensively in this document.
[RFC5050]第3.1节中定义的术语在本文件中广泛使用。
This section contains definitions that are interpreted to be specific to the operation of the TCPCL protocol, as described below.
本节包含解释为特定于TCPCL协议操作的定义，如下所述。
TCP Connection -- A TCP connection refers to a transport connection using TCP as the transport protocol.
TCP连接——TCP连接是指使用TCP作为传输协议的传输连接。
TCPCL Connection -- A TCPCL connection (as opposed to a TCP connection) is a TCPCL communication relationship between two bundle nodes. The lifetime of a TCPCL connection is bound to the lifetime of an underlying TCP connection. Therefore, a TCPCL connection is initiated when a bundle node initiates a TCP connection to be established for the purposes of bundle communication. A TCPCL connection is terminated when the TCP connection ends, due either to one or both nodes actively terminating the TCP connection or due to network errors causing a failure of the TCP connection. For the remainder of this document, the term "connection" without the prefix "TCPCL" shall refer to a TCPCL connection.
TCPCL连接——TCPCL连接（与TCP连接相反）是两个束节点之间的TCPCL通信关系。TCPCL连接的生存期绑定到基础TCP连接的生存期。因此，当bundle节点为bundle通信目的启动要建立的TCP连接时，TCPCL连接被启动。TCPCL连接在TCP连接结束时终止，原因可能是一个或两个节点主动终止TCP连接，或者是网络错误导致TCP连接失败。对于本文件的其余部分，不带前缀“TCPCL”的术语“连接”应指TCPCL连接。
Connection parameters -- The connection parameters are a set of values used to affect the operation of the TCPCL for a given connection. The manner in which these parameters are conveyed to the bundle node and thereby to the TCPCL is implementation dependent. However, the mechanism by which two bundle nodes exchange and negotiate the values to be used for a given session is described in Section 4.2.
连接参数——连接参数是一组用于影响给定连接的TCPCL操作的值。将这些参数传输到bundle节点从而传输到TCPCL的方式取决于实现。但是，第4.2节描述了两个束节点交换和协商用于给定会话的值的机制。
Transmission -- Transmission refers to the procedures and mechanisms (described below) for conveyance of a bundle from one node to another.
传输——传输是指将包从一个节点传输到另一个节点的过程和机制（如下所述）。
The service of this protocol is the transmission of DTN bundles over TCP. This document specifies the encapsulation of bundles, procedures for TCP setup and teardown, and a set of messages and node requirements. The general operation of the protocol is as follows.
该协议的服务是通过TCP传输DTN包。本文档规定了捆绑包的封装、TCP设置和拆卸过程以及一组消息和节点要求。协议的一般操作如下。
First, one node establishes a TCPCL connection to the other by initiating a TCP connection. After setup of the TCP connection is complete, an initial contact header is exchanged in both directions to set parameters of the TCPCL connection and exchange a singleton endpoint identifier for each node (not the singleton Endpoint Identifier (EID) of any application running on the node) to denote the bundle-layer identity of each DTN node. This is used to assist in routing and forwarding messages, e.g., to prevent loops.
首先，一个节点通过启动TCP连接建立到另一个节点的TCPCL连接。TCP连接设置完成后，将在两个方向上交换初始联系人标头，以设置TCPCL连接的参数，并交换每个节点的单例端点标识符（而不是节点上运行的任何应用程序的单例端点标识符（EID））以表示每个DTN节点的捆绑层标识。这用于帮助路由和转发消息，例如防止循环。
Once the TCPCL connection is established and configured in this way, bundles can be transmitted in either direction. Each bundle is transmitted in one or more logical segments of formatted bundle data. Each logical data segment consists of a DATA_SEGMENT message header, a Self-Delimiting Numeric Value (SDNV) as defined in [RFC5050] (see also [RFC6256]) containing the length of the segment, and finally the byte range of the bundle data. The choice of the length to use for segments is an implementation matter. The first segment for a bundle must set the 'start' flag, and the last one must set the 'end' flag in the DATA_SEGMENT message header.
以这种方式建立和配置TCPCL连接后，捆绑包可以向任意方向传输。每个包在格式化包数据的一个或多个逻辑段中传输。每个逻辑数据段包括一个数据段消息头、[RFC5050]（另请参见[RFC6256]）中定义的自定界数值（SDNV），其中包含段的长度，最后是捆绑数据的字节范围。选择用于段的长度是一个实现问题。捆绑包的第一个段必须设置“开始”标志，最后一个段必须在数据段消息头中设置“结束”标志。
If multiple bundles are transmitted on a single TCPCL connection, they MUST be transmitted consecutively. Interleaving data segments from different bundles is not allowed. Bundle interleaving can be accomplished by fragmentation at the BP layer.
如果在单个TCPCL连接上传输多个捆绑包，则必须连续传输这些捆绑包。不允许交错来自不同捆绑包的数据段。束交织可以通过在BP层分段来完成。
An optional feature of the protocol is for the receiving node to send acknowledgments as bundle data segments arrive (ACK_SEGMENT). The rationale behind these acknowledgments is to enable the sender node to determine how much of the bundle has been received, so that in case the connection is interrupted, it can perform reactive fragmentation to avoid re-sending the already transmitted part of the bundle.
协议的一个可选功能是接收节点在捆绑数据段到达时发送确认（ACK_段）。这些确认背后的基本原理是使发送方节点能够确定收到了多少捆绑包，以便在连接中断的情况下，它可以执行反应性分段，以避免重新发送捆绑包中已传输的部分。
When acknowledgments are enabled, then for each data segment that is received, the receiving node sends an ACK_SEGMENT code followed by an SDNV containing the cumulative length of the bundle that has been received. The sending node may transmit multiple DATA_SEGMENT messages without necessarily waiting for the corresponding ACK_SEGMENT responses. This enables pipelining of messages on a channel. In addition, there is no explicit flow control on the TCPCL layer.
启用确认后，对于接收到的每个数据段，接收节点发送一个ACK_段代码，后跟一个SDNV，该SDNV包含已接收的包的累积长度。发送节点可以发送多个数据段消息，而不必等待相应的ACK段响应。这将启用通道上的消息管道。此外，TCPCL层上没有显式的流控制。
Another optional feature is that a receiver may interrupt the transmission of a bundle at any point in time by replying with a REFUSE_BUNDLE message, which causes the sender to stop transmission of the current bundle, after completing transmission of a partially sent data segment. Note: This enables a cross-layer optimization in that it allows a receiver that detects that it already has received a certain bundle to interrupt transmission as early as possible and thus save transmission capacity for other bundles.
另一个可选特征是，接收方可以通过回复拒绝捆绑消息在任何时间点中断捆绑的传输，这使得发送方在完成部分发送的数据段的传输后停止当前捆绑的传输。注意：这支持跨层优化，因为它允许检测到已经接收到某个包的接收器尽早中断传输，从而为其他包节省传输容量。
For connections that are idle, a KEEPALIVE message may optionally be sent at a negotiated interval. This is used to convey liveness information.
对于空闲的连接，可以选择按协商的间隔发送KEEPALIVE消息。这是用来传递活性信息的。
Finally, before connections close, a SHUTDOWN message is sent on the channel. After sending a SHUTDOWN message, the sender of this message may send further acknowledgments (ACK_SEGMENT or REFUSE_BUNDLE) but no further data messages (DATA_SEGMENT). A SHUTDOWN message may also be used to refuse a connection setup by a peer.
最后，在连接关闭之前，会在通道上发送一条关机消息。发送关机消息后，此消息的发送方可以发送进一步的确认（确认段或拒绝包），但不发送进一步的数据消息（数据段）。关机消息也可用于拒绝对等方的连接设置。
There are specific messages for sending and receiving operations (in addition to connection setup/teardown). TCPCL is symmetric, i.e., both sides can start sending data segments in a connection, and one side's bundle transfer does not have to complete before the other side can start sending data segments on its own. Hence, the protocol allows for a bi-directional mode of communication.
有用于发送和接收操作的特定消息（除了连接设置/拆卸）。TCPCL是对称的，即双方可以在连接中开始发送数据段，并且在另一方可以开始发送数据段之前，不必完成一方的捆绑传输。因此，该协议允许双向通信模式。
Note that in the case of concurrent bidirectional transmission, acknowledgment segments may be interleaved with data segments.
注意，在并发双向传输的情况下，确认段可以与数据段交织。
The following figure visually depicts the protocol exchange for a simple session, showing the connection establishment and the transmission of a single bundle split into three data segments (of lengths L1, L2, and L3) from Node A to Node B.
下图直观地描述了简单会话的协议交换，显示了从节点a到节点B的连接建立和将单个捆绑包分成三个数据段（长度为L1、L2和L3）的传输。
Note that the sending node may transmit multiple DATA_SEGMENT messages without necessarily waiting for the corresponding ACK_SEGMENT responses. This enables pipelining of messages on a channel. Although this example only demonstrates a single bundle transmission, it is also possible to pipeline multiple DATA_SEGMENT
注意，发送节点可以发送多个数据段消息，而不必等待相应的ACK段响应。这将启用通道上的消息管道。尽管此示例仅演示了单束传输，但也可以将多个数据段管道化
messages for different bundles without necessarily waiting for ACK_SEGMENT messages to be returned for each one. However, interleaving data segments from different bundles is not allowed.
不同捆绑包的消息，无需等待每个捆绑包返回ACK_段消息。但是，不允许交错来自不同捆绑包的数据段。
No errors or rejections are shown in this example.
本例中未显示错误或拒绝。
Node A Node B
====== ======
Node A Node B
====== ======
+-------------------------+ +-------------------------+
| Contact Header | -> <- | Contact Header |
+-------------------------+ +-------------------------+
+-------------------------+ +-------------------------+
| Contact Header | -> <- | Contact Header |
+-------------------------+ +-------------------------+
+-------------------------+
| DATA_SEGMENT (start) | ->
| SDNV length [L1] | ->
| Bundle Data 0..(L1-1) | ->
+-------------------------+
+-------------------------+ +-------------------------+
| DATA_SEGMENT | -> <- | ACK_SEGMENT |
| SDNV length [L2] | -> <- | SDNV length [L1] |
|Bundle Data L1..(L1+L2-1)| -> +-------------------------+
+-------------------------+
+-------------------------+ +-------------------------+
| DATA_SEGMENT (end) | -> <- | ACK_SEGMENT |
| SDNV length [L3] | -> <- | SDNV length [L1+L2] |
|Bundle Data | -> +-------------------------+
| (L1+L2)..(L1+L2+L3-1)|
+-------------------------+
+-------------------------+
<- | ACK_SEGMENT |
<- | SDNV length [L1+L2+L3] |
+-------------------------+
+-------------------------+
| DATA_SEGMENT (start) | ->
| SDNV length [L1] | ->
| Bundle Data 0..(L1-1) | ->
+-------------------------+
+-------------------------+ +-------------------------+
| DATA_SEGMENT | -> <- | ACK_SEGMENT |
| SDNV length [L2] | -> <- | SDNV length [L1] |
|Bundle Data L1..(L1+L2-1)| -> +-------------------------+
+-------------------------+
+-------------------------+ +-------------------------+
| DATA_SEGMENT (end) | -> <- | ACK_SEGMENT |
| SDNV length [L3] | -> <- | SDNV length [L1+L2] |
|Bundle Data | -> +-------------------------+
| (L1+L2)..(L1+L2+L3-1)|
+-------------------------+
+-------------------------+
<- | ACK_SEGMENT |
<- | SDNV length [L1+L2+L3] |
+-------------------------+
+-------------------------+ +-------------------------+
| SHUTDOWN | -> <- | SHUTDOWN |
+-------------------------+ +-------------------------+
+-------------------------+ +-------------------------+
| SHUTDOWN | -> <- | SHUTDOWN |
+-------------------------+ +-------------------------+
Figure 2: A Simple Visual Example of the Flow of Protocol Messages on a Single TCP Session between Two Nodes (A and B)
图2：两个节点（A和B）之间单个TCP会话上协议消息流的简单可视示例
For bundle transmissions to occur using the TCPCL, a TCPCL connection must first be established between communicating nodes. It is up to the implementation to decide how and when connection setup is triggered. For example, some connections may be opened proactively and maintained for as long as is possible given the network
要使用TCPCL进行捆绑传输，必须首先在通信节点之间建立TCPCL连接。由实现决定如何以及何时触发连接设置。例如，某些连接可以主动打开，并在给定网络的情况下尽可能长时间保持
conditions, while other connections may be opened only when there is a bundle that is queued for transmission and the routing algorithm selects a certain next-hop node.
条件，而只有当存在排队等待传输的包并且路由算法选择某个下一跳节点时，才可以打开其他连接。
To establish a TCPCL connection, a node must first establish a TCP connection with the intended peer node, typically by using the services provided by the operating system. Port number 4556 has been assigned by IANA as the well-known port number for the TCP convergence layer. Other port numbers MAY be used per local configuration. Determining a peer's port number (if different from the well-known TCPCL port) is up to the implementation.
要建立TCPCL连接，节点必须首先与目标对等节点建立TCP连接，通常使用操作系统提供的服务。IANA已将端口号4556指定为TCP聚合层的已知端口号。其他端口号可根据本地配置使用。确定对等方的端口号（如果与众所周知的TCPCL端口不同）取决于实现。
If the node is unable to establish a TCP connection for any reason, then it is an implementation matter to determine how to handle the connection failure. A node MAY decide to re-attempt to establish the connection. If it does so, it MUST NOT overwhelm its target with repeated connection attempts. Therefore, the node MUST retry the connection setup only after some delay (a 1-second minimum is RECOMMENDED), and it SHOULD use a (binary) exponential backoff mechanism to increase this delay in case of repeated failures. In case a SHUTDOWN message specifying a reconnection delay is received, that delay is used as the initial delay. The default initial delay SHOULD be at least 1 second but SHOULD be configurable since it will be application and network type dependent.
如果节点由于任何原因无法建立TCP连接，那么确定如何处理连接故障是一个实现问题。节点可以决定重新尝试建立连接。如果它这样做了，就不能用重复的连接尝试来压倒它的目标。因此，节点必须仅在延迟一段时间后重试连接设置（建议至少1秒），并且应该使用（二进制）指数退避机制来增加重复故障时的延迟。如果收到指定重新连接延迟的关机消息，则该延迟将用作初始延迟。默认初始延迟应至少为1秒，但应可配置，因为它将取决于应用程序和网络类型。
The node MAY declare failure after one or more connection attempts and MAY attempt to find an alternate route for bundle data. Such decisions are up to the higher layer (i.e., the BP).
节点可能会在一次或多次连接尝试后声明失败，并可能会尝试为捆绑数据找到备用路由。此类决策由高层（即BP）做出。
Once a TCP connection is established, each node MUST immediately transmit a contact header over the TCP connection. The format of the contact header is described in Section 4.1.
一旦建立了TCP连接，每个节点必须立即通过TCP连接传输联系人标头。第4.1节描述了联系人标题的格式。
Upon receipt of the contact header, both nodes perform the validation and negotiation procedures defined in Section 4.2
收到联系人标头后，两个节点都执行第4.2节中定义的验证和协商程序
After receiving the contact header from the other node, either node MAY also refuse the connection by sending a SHUTDOWN message. If connection setup is refused, a reason MUST be included in the SHUTDOWN message.
在从另一个节点接收到联系人报头后，任一节点也可以通过发送关机消息来拒绝连接。如果连接设置被拒绝，则关机消息中必须包含原因。
Once a TCP connection is established, both parties exchange a contact header. This section describes the format of the contact header and the meaning of its fields.
建立TCP连接后，双方交换一个联系人头。本节介绍联系人标题的格式及其字段的含义。
The format for the Contact Header is as follows:
联系人标题的格式如下所示：
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| magic='dtn!' |
+---------------+---------------+---------------+---------------+
| version | flags | keepalive_interval |
+---------------+---------------+---------------+---------------+
| local EID length (SDNV) |
+---------------+---------------+---------------+---------------+
| |
+ local EID (variable) +
| |
+---------------+---------------+---------------+---------------+
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| magic='dtn!' |
+---------------+---------------+---------------+---------------+
| version | flags | keepalive_interval |
+---------------+---------------+---------------+---------------+
| local EID length (SDNV) |
+---------------+---------------+---------------+---------------+
| |
+ local EID (variable) +
| |
+---------------+---------------+---------------+---------------+
Figure 3: Contact Header Format
图3：联系人标题格式
The fields of the contact header are:
联系人标题的字段包括：
magic: A four-byte field that always contains the byte sequence 0x64 0x74 0x6e 0x21, i.e., the text string "dtn!" in US-ASCII.
魔术：一个四字节字段，始终包含字节序列0x64 0x74 0x6e 0x21，即US-ASCII中的文本字符串“dtn！”。
version: A one-byte field value containing the value 3 (current version of the protocol).
版本：一个单字节字段值，包含值3（协议的当前版本）。
flags: A one-byte field containing optional connection flags. The first four bits are unused and MUST be set to zero upon transmission and MUST be ignored upon reception. The last four bits are interpreted as shown in Table 1 below.
标志：包含可选连接标志的单字节字段。前四位未使用，传输时必须设置为零，接收时必须忽略。最后四位的解释如下表1所示。
keepalive_interval: A two-byte integer field containing the number of seconds between exchanges of KEEPALIVE messages on the connection (see Section 5.6). This value is in network byte order, as are all other multi-byte fields described in this protocol.
keepalive_interval：一个两字节整数字段，包含连接上keepalive消息交换之间的秒数（参见第5.6节）。该值按网络字节顺序排列，本协议中描述的所有其他多字节字段也是如此。
local EID length: A variable-length SDNV field containing the length of the endpoint identifier (EID) for some singleton endpoint in which the sending node is a member. A four-byte SDNV is depicted for clarity of the figure.
本地EID长度：一个可变长度的SDNV字段，包含发送节点是其成员的某个单例端点的端点标识符（EID）的长度。为了图的清晰，描述了四字节SDNV。
local EID: A byte string containing the EID of some singleton endpoint in which the sending node is a member, in the canonical format of <scheme name>:<scheme-specific part>. An eight-byte EID is shown for clarity of the figure.
本地EID：一个字节字符串，包含发送节点是其成员的某个单例端点的EID，其标准格式为<scheme name>：<scheme specific part>。为清晰起见，显示了一个8字节的EID。
+----------+--------------------------------------------------------+
| Value | Meaning |
+----------+--------------------------------------------------------+
| 00000001 | Request acknowledgment of bundle segments. |
| 00000010 | Request enabling of reactive fragmentation. |
| 00000100 | Indicate support for bundle refusal. This flag MUST |
| | NOT be set to '1' unless support for acknowledgments |
| | is also indicated. |
| 00001000 | Request sending of LENGTH messages. |
+----------+--------------------------------------------------------+
+----------+--------------------------------------------------------+
| Value | Meaning |
+----------+--------------------------------------------------------+
| 00000001 | Request acknowledgment of bundle segments. |
| 00000010 | Request enabling of reactive fragmentation. |
| 00000100 | Indicate support for bundle refusal. This flag MUST |
| | NOT be set to '1' unless support for acknowledgments |
| | is also indicated. |
| 00001000 | Request sending of LENGTH messages. |
+----------+--------------------------------------------------------+
Table 1: Contact Header Flags
表1：联系人标题标志
The manner in which values are configured and chosen for the various flags and parameters in the contact header is implementation dependent.
为联系人标头中的各种标志和参数配置和选择值的方式取决于实现。
Upon reception of the contact header, each node follows the following procedures to ensure the validity of the TCPCL connection and to negotiate values for the connection parameters.
接收到联系人报头后，每个节点都遵循以下步骤，以确保TCPCL连接的有效性，并协商连接参数的值。
If the magic string is not present or is not valid, the connection MUST be terminated. The intent of the magic string is to provide some protection against an inadvertent TCP connection by a different protocol than the one described in this document. To prevent a flood of repeated connections from a misconfigured application, a node MAY elect to hold an invalid connection open and idle for some time before closing it.
如果魔术字符串不存在或无效，则必须终止连接。魔术字符串的目的是通过与本文档中描述的协议不同的协议提供一些保护，以防止意外的TCP连接。为了防止来自配置错误的应用程序的大量重复连接，节点可以选择在关闭无效连接之前将其保持打开和空闲一段时间。
If a node receives a contact header containing a version that is greater than the current version of the protocol that the node implements, then the node SHOULD interpret all fields and messages as it would normally. If a node receives a contact header with a version that is lower than the version of the protocol that the node implements, the node may either terminate the connection due to the version mismatch or may adapt its operation to conform to the older version of the protocol. This decision is an implementation matter.
如果节点接收到包含版本大于该节点实现的协议当前版本的联系人标头，则该节点应按照正常方式解释所有字段和消息。如果节点接收到的联系人标头的版本低于该节点实现的协议版本，则该节点可能会由于版本不匹配而终止连接，或者可能会调整其操作以符合较旧版本的协议。这项决定是一个执行问题。
A node calculates the parameters for a TCPCL connection by negotiating the values from its own preferences (conveyed by the contact header it sent) with the preferences of the peer node (expressed in the contact header that it received). This negotiation MUST proceed in the following manner:
节点通过协商来自其自身首选项（由其发送的联系人标头传递）的值与对等节点的首选项（在其接收的联系人标头中表示）来计算TCPCL连接的参数。谈判必须按以下方式进行：
o The parameter for requesting acknowledgment of bundle segments is set to true iff the corresponding flag is set in both contact headers.
o 如果在两个联系人标头中都设置了相应的标志，则用于请求包段确认的参数设置为true。
o The parameter for enabling reactive fragmentation is set to true iff the corresponding flag is set in both contact headers.
o 如果在两个联系人标头中都设置了相应的标志，则启用反应性分段的参数设置为true。
o The bundle refusal capability is set to true if the corresponding flag is set in both contact headers and if segment acknowledgment has been enabled.
o 如果在两个联系人标头中都设置了相应的标志，并且已启用段确认，则捆绑拒绝功能将设置为true。
o The keepalive_interval parameter is set to the minimum value from both contact headers. If one or both contact headers contains the value zero, then the keepalive feature (described in Section 5.6) is disabled.
o keepalive_interval参数设置为两个联系人标头的最小值。如果一个或两个联系人标头包含值零，则禁用keepalive功能（如第5.6节所述）。
o The flag requesting sending of LENGTH messages is handled as described in Section 5.5.
o 请求发送长度消息的标志按照第5.5节所述进行处理。
Once this process of parameter negotiation is completed, the protocol defines no additional mechanism to change the parameters of an established connection; to effect such a change, the connection MUST be terminated and a new connection established.
一旦这个参数协商过程完成，协议就没有定义任何额外的机制来更改已建立连接的参数；要实现这种更改，必须终止连接并建立新连接。
This section describes the protocol operation for the duration of an established connection, including the mechanisms for transmitting bundles over the connection.
本节描述建立连接期间的协议操作，包括通过连接传输捆绑包的机制。
After the initial exchange of a contact header, all messages transmitted over the connection are identified by a one-byte header with the following structure:
初始交换联系人报头后，通过连接传输的所有消息由一个具有以下结构的单字节报头标识：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| type | flags |
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| type | flags |
+-+-+-+-+-+-+-+-+
Figure 4: Format of the One-Byte Message Header
图4：单字节消息头的格式
type: Indicates the type of the message as per Table 2 below
类型：根据下表2指示消息的类型
flags: Optional flags defined based on message type.
标志：根据消息类型定义的可选标志。
The types and values for the message type code are as follows.
消息类型代码的类型和值如下所示。
+----------------+---------+----------------------------------------+
| Type | Code | Description |
+----------------+---------+----------------------------------------+
| | 0x0 | Reserved. |
| | | |
| DATA_SEGMENT | 0x1 | Indicates the transmission of a |
| | | segment of bundle data, as described |
| | | in Section 5.2. |
| | | |
| ACK_SEGMENT | 0x2 | Acknowledges reception of a data |
| | | segment, as described in Section 5.3 |
| | | |
| REFUSE_BUNDLE | 0x3 | Indicates that the transmission of the |
| | | current bundle shall be stopped, as |
| | | described in Section 5.4. |
| | | |
| KEEPALIVE | 0x4 | KEEPALIVE message for the connection, |
| | | as described in Section 5.6. |
| | | |
| SHUTDOWN | 0x5 | Indicates that one of the nodes |
| | | participating in the connection wishes |
| | | to cleanly terminate the connection, |
| | | as described in Section 6. |
| | | |
| LENGTH | 0x6 | Contains the length (in bytes) of the |
| | | next bundle, as described in Section |
| | | 5.5. |
| | | |
| | 0x7-0xf | Unassigned. |
| | | |
+----------------+---------+----------------------------------------+
+----------------+---------+----------------------------------------+
| Type | Code | Description |
+----------------+---------+----------------------------------------+
| | 0x0 | Reserved. |
| | | |
| DATA_SEGMENT | 0x1 | Indicates the transmission of a |
| | | segment of bundle data, as described |
| | | in Section 5.2. |
| | | |
| ACK_SEGMENT | 0x2 | Acknowledges reception of a data |
| | | segment, as described in Section 5.3 |
| | | |
| REFUSE_BUNDLE | 0x3 | Indicates that the transmission of the |
| | | current bundle shall be stopped, as |
| | | described in Section 5.4. |
| | | |
| KEEPALIVE | 0x4 | KEEPALIVE message for the connection, |
| | | as described in Section 5.6. |
| | | |
| SHUTDOWN | 0x5 | Indicates that one of the nodes |
| | | participating in the connection wishes |
| | | to cleanly terminate the connection, |
| | | as described in Section 6. |
| | | |
| LENGTH | 0x6 | Contains the length (in bytes) of the |
| | | next bundle, as described in Section |
| | | 5.5. |
| | | |
| | 0x7-0xf | Unassigned. |
| | | |
+----------------+---------+----------------------------------------+
Table 2: TCPCL Message Types
表2:TCPCL消息类型
Each bundle is transmitted in one or more data segments. The format of a DATA_SEGMENT message follows:
每个包在一个或多个数据段中传输。数据段消息的格式如下：
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x1 |0|0|S|E| length ... | contents.... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x1 |0|0|S|E| length ... | contents.... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Format of DATA_SEGMENT Messages
图5：数据段消息的格式
The type portion of the message header contains the value 0x1.
消息头的类型部分包含值0x1。
The flags portion of the message header byte contains two optional values in the two low-order bits, denoted 'S' and 'E' above. The 'S' bit MUST be set to one if it precedes the transmission of the first segment of a new bundle. The 'E' bit MUST be set to one when transmitting the last segment of a bundle.
消息头字节的标志部分包含两个低阶位中的两个可选值，上面表示为“S”和“E”。如果“S”位在传输新束的第一段之前，则必须将其设置为1。传输束的最后一段时，“E”位必须设置为1。
Following the message header, the length field is an SDNV containing the number of bytes of bundle data that are transmitted in this segment. Following this length is the actual data contents.
在消息头之后，长度字段是一个SDNV，其中包含在此段中传输的捆绑数据的字节数。此长度之后是实际数据内容。
Determining the size of the segment is an implementation matter. In particular, a node may, based on local policy or configuration, only ever transmit bundle data in a single segment, in which case both the 'S' and 'E' bits MUST be set to one.
确定细分市场的规模是一个实施问题。特别地，基于本地策略或配置，节点可能仅在单个段中传输捆绑数据，在这种情况下，“S”和“E”位都必须设置为1。
In the Bundle Protocol specification [RFC5050], a single bundle comprises a primary bundle block, a payload block, and zero or more additional bundle blocks. The relationship between the protocol blocks and the convergence-layer segments is an implementation-specific decision. In particular, a segment MAY contain more than one protocol block; alternatively, a single protocol block (such as the payload) MAY be split into multiple segments.
在捆绑协议规范[RFC5050]中，单个捆绑包包括一个主捆绑包块、一个有效负载块和零个或多个附加捆绑包块。协议块和汇聚层段之间的关系是一个特定于实现的决策。具体地，一个段可以包含多个协议块；或者，单个协议块（例如有效载荷）可以被分割成多个段。
However, a single segment MUST NOT contain data of more than a single bundle.
但是，单个数据段不能包含多个数据包的数据。
Once a transmission of a bundle has commenced, the node MUST only send segments containing sequential portions of that bundle until it sends a segment with the 'E' bit set.
一旦一个包的传输开始，节点必须只发送包含该包的顺序部分的段，直到它发送一个设置了“E”位的段为止。
Although the TCP transport provides reliable transfer of data between transport peers, the typical BSD sockets interface provides no means to inform a sending application of when the receiving application has processed some amount of transmitted data. Thus, after transmitting some data, a Bundle Protocol agent needs an additional mechanism to determine whether the receiving agent has successfully received the segment.
尽管TCP传输在传输对等点之间提供了可靠的数据传输，但典型的BSD套接字接口无法在接收应用程序处理了一定数量的传输数据时通知发送应用程序。因此，在传输一些数据之后，捆绑协议代理需要一个附加的机制来确定接收代理是否已成功接收到该段。
To this end, the TCPCL protocol offers an optional feature whereby a receiving node transmits acknowledgments of reception of data segments. This feature is enabled if, and only if, during the exchange of contact headers, both parties set the flag to indicate that segment acknowledgments are enabled (see Section 4.1). If so, then the receiver MUST transmit a bundle acknowledgment message when it successfully receives each data segment.
为此，TCPCL协议提供了一个可选特性，其中接收节点发送数据段接收确认。当且仅当在交换联系人标头期间，双方设置标志以指示已启用段确认时，才启用此功能（见第4.1节）。如果是这样，则接收器必须在成功接收每个数据段时发送捆绑确认消息。
The format of a bundle acknowledgment is as follows:
捆绑包确认的格式如下所示：
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x2 |0|0|0|0| acknowledged length ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x2 |0|0|0|0| acknowledged length ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Format of ACK_SEGMENT Messages
图6:ACK_段消息的格式
To transmit an acknowledgment, a node first transmits a message header with the ACK_SEGMENT type code and all flags set to zero, then transmits an SDNV containing the cumulative length in bytes of the received segment(s) of the current bundle. The length MUST fall on a segment boundary. That is, only full segments can be acknowledged.
为了发送确认，节点首先发送带有ACK_段类型代码和所有标志设置为零的消息头，然后发送SDNV，该SDNV包含当前束的接收段的累积长度（以字节为单位）。长度必须落在线段边界上。也就是说，只能确认完整的段。
For example, suppose the sending node transmits four segments of bundle data with lengths 100, 200, 500, and 1000, respectively. After receiving the first segment, the node sends an acknowledgment of length 100. After the second segment is received, the node sends an acknowledgment of length 300. The third and fourth acknowledgments are of length 800 and 1800, respectively.
例如，假设发送节点发送长度分别为100、200、500和1000的四段捆绑数据。在接收到第一段之后，节点发送长度为100的确认。在接收到第二段之后，节点发送长度为300的确认。第三次和第四次确认的长度分别为800和1800。
As bundles may be large, the TCPCL supports an optional mechanisms by which a receiving node may indicate to the sender that it does not want to receive the corresponding bundle.
由于捆绑包可能很大，TCPCL支持可选机制，通过该机制，接收节点可以向发送方指示它不希望接收相应的捆绑包。
To do so, upon receiving a DATA_SEGMENT message, the node MAY transmit a REFUSE_BUNDLE message. As data segments and acknowledgments may cross on the wire, the bundle that is being refused is implicitly identified by the sequence in which acknowledgements and refusals are received.
为此，在接收到数据段消息时，节点可以发送拒绝捆绑消息。由于数据段和确认可能在线路上交叉，被拒绝的捆绑包由接收确认和拒绝的序列隐式标识。
The format of the REFUSE_BUNDLE message is as follows:
拒绝包消息的格式如下所示：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| 0x3 | RCode |
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| 0x3 | RCode |
+-+-+-+-+-+-+-+-+
Figure 7: Format of REFUSE_BUNDLE Messages
图7：垃圾包消息的格式
The RCode field, which stands for "reason code", contains a value indicating why the bundle was refused. The following table contains semantics for some values. Other values may be registered with IANA, as defined in Section 8.
RCode字段（代表“原因代码”）包含一个值，该值指示捆绑包被拒绝的原因。下表包含某些值的语义。根据第8节的定义，其他值可向IANA注册。
+---------+---------------------------------------------------------+
| RCode | Semantics |
+---------+---------------------------------------------------------+
| 0x0 | Reason for refusal is unknown or not specified. |
| 0x1 | The receiver now has the complete bundle. The sender |
| | may now consider the bundle as completely received. |
| 0x2 | The receiver's resources are exhausted. The sender |
| | SHOULD apply reactive bundle fragmentation before |
| | retrying. |
| 0x3 | The receiver has encountered a problem that requires |
| | the bundle to be retransmitted in its entirety. |
| 0x4-0x7 | Unassigned. |
| 0x8-0xf | Reserved for future usage. |
+---------+---------------------------------------------------------+
+---------+---------------------------------------------------------+
| RCode | Semantics |
+---------+---------------------------------------------------------+
| 0x0 | Reason for refusal is unknown or not specified. |
| 0x1 | The receiver now has the complete bundle. The sender |
| | may now consider the bundle as completely received. |
| 0x2 | The receiver's resources are exhausted. The sender |
| | SHOULD apply reactive bundle fragmentation before |
| | retrying. |
| 0x3 | The receiver has encountered a problem that requires |
| | the bundle to be retransmitted in its entirety. |
| 0x4-0x7 | Unassigned. |
| 0x8-0xf | Reserved for future usage. |
+---------+---------------------------------------------------------+
Table 3: REFUSE_BUNDLE Reason Codes
表3：拒绝捆绑原因代码
The receiver MUST, for each bundle preceding the one to be refused, have either acknowledged all DATA_SEGMENTs or refused the bundle. This allows the sender to identify the bundles accepted and refused by means of a simple FIFO list of segments and acknowledgments.
对于要拒绝的包之前的每个包，接收方必须确认所有数据段或拒绝该包。这允许发送方通过一个简单的FIFO段和确认列表来识别接受和拒绝的捆绑包。
The bundle refusal MAY be sent before the entire data segment is received. If a sender receives a REFUSE_BUNDLE message, the sender MUST complete the transmission of any partially sent DATA_SEGMENT message (so that the receiver stays in sync). The sender MUST NOT commence transmission of any further segments of the rejected bundle subsequently. Note, however, that this requirement does not ensure that a node will not receive another DATA_SEGMENT for the same bundle after transmitting a REFUSE_BUNDLE message since messages may cross on the wire; if this happens, subsequent segments of the bundle SHOULD also be refused with a REFUSE_BUNDLE message.
可以在接收整个数据段之前发送包拒绝。如果发送方收到拒绝包消息，发送方必须完成任何部分发送的数据段消息的传输（以便接收方保持同步）。发送方不得随后开始传输被拒绝捆绑包的任何其他段。但是，请注意，此要求不能确保节点在传输拒绝捆绑消息后不会收到同一捆绑的另一个数据段，因为消息可能会在线路上交叉；如果发生这种情况，还应使用拒绝bundle消息拒绝bundle的后续段。
Note: If a bundle transmission is aborted in this way, the receiver may not receive a segment with the 'E' flag set to '1' for the aborted bundle. The beginning of the next bundle is identified by the 'S' bit set to '1', indicating the start of a new bundle.
注意：如果以这种方式中止捆绑传输，则对于中止的捆绑，接收器可能不会接收到“E”标志设置为“1”的段。下一个捆绑包的开始由设置为“1”的“S”位标识，表示新捆绑包的开始。
The LENGTH message contains the total length, in bytes, of the next bundle, formatted as an SDNV. Its purpose is to allow nodes to preemptively refuse bundles that would exceed their resources. It is an optimization.
长度消息包含下一个捆绑包的总长度（以字节为单位），格式为SDNV。其目的是允许节点以抢占方式拒绝超出其资源的捆绑包。这是一种优化。
The format of the LENGTH message is as follows:
长度信息的格式如下所示：
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x6 |0|0|0|0| total bundle length ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x6 |0|0|0|0| total bundle length ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Format of LENGTH Messages
图8：长度消息的格式
LENGTH messages MUST NOT be sent unless the corresponding flag bit is set in the contact header. If the flag bit is set, LENGTH messages MAY be sent at the sender's discretion. LENGTH messages MUST NOT be sent unless the next DATA_SEGMENT message has the 'S' bit set to "1" (i.e., just before the start of a new bundle).
除非在联系人标头中设置了相应的标志位，否则不得发送长度消息。如果设置了标志位，则发送方可自行决定发送长度消息。除非下一个数据段消息的“S”位设置为“1”（即，在新捆绑开始之前），否则不得发送长度消息。
A receiver MAY send a BUNDLE_REFUSE message as soon as it receives a LENGTH message without waiting for the next DATA_SEGMENT message. The sender MUST be prepared for this and MUST associate the refusal with the right bundle.
接收方可在收到长度消息后立即发送捆绑拒绝消息，而无需等待下一个数据段消息。发件人必须对此做好准备，并且必须将拒绝与正确的捆绑相关联。
The protocol includes a provision for transmission of KEEPALIVE messages over the TCP connection to help determine if the connection has been disrupted.
该协议包括通过TCP连接传输KEEPALIVE消息的规定，以帮助确定连接是否中断。
As described in Section 4.1, one of the parameters in the contact header is the keepalive_interval. Both sides populate this field with their requested intervals (in seconds) between KEEPALIVE messages.
如第4.1节所述，联系人标头中的一个参数是keepalive_间隔。双方都使用其请求的KEEPALIVE消息之间的间隔（以秒为单位）填充此字段。
The format of a KEEPALIVE message is a one-byte message type code of KEEPALIVE (as described in Table 2) with no additional data. Both sides SHOULD send a KEEPALIVE message whenever the negotiated interval has elapsed with no transmission of any message (KEEPALIVE or other).
KEEPALIVE消息的格式为KEEPALIVE的单字节消息类型代码（如表2所述），不包含其他数据。双方应在协商的时间间隔结束且未传输任何消息（KEEPALIVE或其他）时发送KEEPALIVE消息。
If no message (KEEPALIVE or other) has been received for at least twice the keepalive_interval, then either party MAY terminate the session by transmitting a one-byte SHUTDOWN message (as described in Table 2) and by closing the TCP connection.
如果在至少两倍的KEEPALIVE_间隔内没有收到任何消息（KEEPALIVE或其他），则任何一方都可以通过发送一个单字节的关机消息（如表2所述）和关闭TCP连接来终止会话。
Note: The keepalive_interval should not be chosen too short as TCP retransmissions may occur in case of packet loss. Those will have to be triggered by a timeout (TCP retransmission timeout (RTO)), which is dependent on the measured RTT for the TCP connection so that KEEPALIVE messages may experience noticeable latency.
注意：keepalive_间隔不应选择得太短，因为在数据包丢失的情况下可能会发生TCP重传。这些必须由超时（TCP重传超时（RTO））触发，该超时取决于TCP连接的测量RTT，因此KEEPALIVE消息可能会经历明显的延迟。
This section describes the procedures for ending a TCPCL connection.
本节介绍结束TCPCL连接的步骤。
To cleanly shut down a connection, a SHUTDOWN message MUST be transmitted by either node at any point following complete transmission of any other message. In case acknowledgments have been negotiated, a node SHOULD acknowledge all received data segments first and then shut down the connection.
要彻底关闭连接，任何节点都必须在任何其他消息完全传输后的任何时间点传输关闭消息。如果已协商确认，则节点应首先确认所有接收到的数据段，然后关闭连接。
The format of the SHUTDOWN message is as follows:
关机消息的格式如下所示：
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x5 |0|0|R|D| reason (opt) | reconnection delay (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x5 |0|0|R|D| reason (opt) | reconnection delay (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Format of Bundle SHUTDOWN Messages
图9：包关闭消息的格式
It is possible for a node to convey additional information regarding the reason for connection termination. To do so, the node MUST set the 'R' bit in the message header flags and transmit a one-byte reason code immediately following the message header. The specified values of the reason code are:
节点可以传递关于连接终止原因的附加信息。为此，节点必须在消息头标志中设置“R”位，并在消息头之后立即发送一个单字节的原因码。原因代码的指定值为：
+-----------+------------------+------------------------------------+
| Code | Meaning | Description |
+-----------+------------------+------------------------------------+
| 0x00 | Idle timeout | The connection is being closed due |
| | | to idleness. |
| | | |
| 0x01 | Version mismatch | The node cannot conform to the |
| | | specified TCPCL protocol version. |
| | | |
| 0x02 | Busy | The node is too busy to handle the |
| | | current connection. |
| | | |
| 0x03-0xff | | Unassigned. |
+-----------+------------------+------------------------------------+
+-----------+------------------+------------------------------------+
| Code | Meaning | Description |
+-----------+------------------+------------------------------------+
| 0x00 | Idle timeout | The connection is being closed due |
| | | to idleness. |
| | | |
| 0x01 | Version mismatch | The node cannot conform to the |
| | | specified TCPCL protocol version. |
| | | |
| 0x02 | Busy | The node is too busy to handle the |
| | | current connection. |
| | | |
| 0x03-0xff | | Unassigned. |
+-----------+------------------+------------------------------------+
Table 4: SHUTDOWN Reason Codes
表4：停机原因代码
It is also possible to convey a requested reconnection delay to indicate how long the other node must wait before attempting connection re-establishment. To do so, the node sets the 'D' bit in
还可以传递请求的重新连接延迟，以指示另一节点在尝试重新建立连接之前必须等待多长时间。为此，节点在中设置“D”位
the message header flags and then transmits an SDNV specifying the requested delay, in seconds, following the message header (and optionally, the SHUTDOWN reason code). The value 0 SHALL be interpreted as an infinite delay, i.e., that the connecting node MUST NOT re-establish the connection. In contrast, if the node does not wish to request a delay, it SHOULD omit the reconnection delay field (and set the 'D' bit to zero). Note that in the figure above, the reconnection delay SDNV is represented as a two-byte field for convenience.
消息头标记并随后发送SDNV，指定消息头（以及可选的关机原因代码）后请求的延迟（以秒为单位）。值0应解释为无限延迟，即连接节点不得重新建立连接。相反，如果节点不希望请求延迟，则应省略重新连接延迟字段（并将“D”位设置为零）。注意，在上图中，为了方便起见，重新连接延迟SDNV表示为两字节字段。
A connection shutdown MAY occur immediately after TCP connection establishment or reception of a contact header (and prior to any further data exchange). This may, for example, be used to notify that the node is currently not able or willing to communicate. However, a node MUST always send the contact header to its peer before sending a SHUTDOWN message.
TCP连接建立或接收到联系人报头后（以及任何进一步的数据交换之前），可能会立即发生连接关闭。例如，这可用于通知节点当前不能或不愿意通信。但是，在发送关闭消息之前，节点必须始终将联系人标头发送给其对等方。
If either node terminates a connection prematurely in this manner, it SHOULD send a SHUTDOWN message and MUST indicate a reason code unless the incoming connection did not include the magic string. If a node does not want its peer to reopen the connection immediately, it SHOULD set the 'D' bit in the flags and include a reconnection delay to indicate when the peer is allowed to attempt another connection setup.
如果任一节点以这种方式过早终止连接，它应该发送一条关机消息，并且必须指明原因码，除非传入的连接不包含魔术字符串。如果节点不希望其对等方立即重新打开连接，则应在标志中设置“D”位，并包括重新连接延迟，以指示何时允许对等方尝试另一个连接设置。
If a connection is to be terminated before another protocol message has completed, then the node MUST NOT transmit the SHUTDOWN message but still SHOULD close the TCP connection. In particular, if the connection is to be closed (for whatever reason) while a node is in the process of transmitting a bundle data segment, the receiving node is still expecting segment data and might erroneously interpret the SHUTDOWN message to be part of the data segment.
如果要在另一个协议消息完成之前终止连接，则节点不得传输关机消息，但仍应关闭TCP连接。特别是，如果在节点正在传输捆绑数据段的过程中关闭连接（无论出于何种原因），则接收节点仍然期望段数据，并且可能错误地将关闭消息解释为数据段的一部分。
The protocol includes a provision for clean shutdown of idle TCP connections. Determining the length of time to wait before closing idle connections, if they are to be closed at all, is an implementation and configuration matter.
该协议包括一个干净关闭空闲TCP连接的规定。如果要关闭空闲连接，则确定关闭空闲连接之前等待的时间长度是一个实现和配置问题。
If there is a configured time to close idle links and if no bundle data (other than KEEPALIVE messages) has been received for at least that amount of time, then either node MAY terminate the connection by transmitting a SHUTDOWN message indicating the reason code of 'Idle timeout' (as described in Table 4). After receiving a SHUTDOWN message in response, both sides may close the TCP connection.
如果有一个配置的时间来关闭空闲链接，并且如果至少在该时间段内没有收到捆绑数据（KEEPALIVE消息除外），则任一节点都可以通过发送指示“空闲超时”原因码的关机消息来终止连接（如表4所述）。在收到关机消息响应后，双方都可以关闭TCP连接。
One security consideration for this protocol relates to the fact that nodes present their endpoint identifier as part of the connection header exchange. It would be possible for a node to fake this value and present the identity of a singleton endpoint in which the node is not a member, essentially masquerading as another DTN node. If this identifier is used without further verification as a means to determine which bundles are transmitted over the connection, then the node that has falsified its identity may be able to obtain bundles that it should not have. Therefore, a node SHALL NOT use the endpoint identifier conveyed in the TCPCL connection message to derive a peer node's identity unless it can ascertain it via other means.
该协议的一个安全考虑因素涉及这样一个事实，即节点将其端点标识符作为连接头交换的一部分呈现。节点可能会伪造此值，并显示该节点不是成员的单例端点的标识，本质上伪装为另一个DTN节点。如果在没有进一步验证的情况下使用该标识符作为确定通过连接传输哪些捆绑包的手段，那么伪造其标识的节点可能能够获得其不应该拥有的捆绑包。因此，节点不得使用TCPCL连接消息中传输的端点标识符来推导对等节点的身份，除非它可以通过其他方式确定它。
These concerns may be mitigated through the use of the Bundle Security Protocol [RFC6257]. In particular, the Bundle Authentication Block defines mechanism for secure exchange of bundles between DTN nodes. Thus, an implementation could delay trusting the presented endpoint identifier until the node can securely validate that its peer is in fact the only member of the given singleton endpoint.
这些问题可以通过使用Bundle安全协议[RFC6257]来缓解。特别是，Bundle身份验证块定义了DTN节点之间安全交换Bundle的机制。因此，一个实现可以延迟信任所提供的端点标识符，直到节点能够安全地验证其对等方实际上是给定单例端点的唯一成员。
In general, TCPCL does not provide any security services. The mechanisms defined in [RFC6257] are to be used instead.
一般来说，TCPCL不提供任何安全服务。将使用[RFC6257]中定义的机制。
Nothing in TCPCL prevents the use of the Transport Layer Security (TLS) protocol [RFC5246] to secure a connection.
TCPCL中没有任何内容阻止使用传输层安全（TLS）协议[RFC5246]来保护连接。
Another consideration for this protocol relates to denial-of-service attacks. A node may send a large amount of data over a TCP connection, requiring the receiving node to handle the data, attempt to stop the flood of data by sending a REFUSE_BUNDLE message, or forcibly terminate the connection. This burden could cause denial of service on other, well-behaving connections. There is also nothing to prevent a malicious node from continually establishing connections and repeatedly trying to send copious amounts of bundle data. A listening node MAY take countermeasures such as ignoring TCP SYN messages, closing TCP connections as soon as they are established, waiting before sending the contact header, sending a SHUTDOWN message quickly or with a delay, etc.
此协议的另一个考虑事项涉及拒绝服务攻击。节点可以通过TCP连接发送大量数据，要求接收节点处理数据，尝试通过发送拒绝包消息来阻止数据泛滥，或者强制终止连接。这一负担可能会导致其他行为良好的连接拒绝服务。也无法阻止恶意节点持续建立连接并重复尝试发送大量捆绑数据。侦听节点可以采取对策，例如忽略TCP SYN消息、在TCP连接建立后立即关闭TCP连接、在发送联系人头之前等待、快速或延迟发送关机消息等。
In this section, registration procedures are as defined in [RFC5226].
在本节中，注册程序如[RFC5226]所述。
Port number 4556 has been assigned as the default port for the TCP convergence layer.
端口号4556已被指定为TCP聚合层的默认端口。
Service Name: dtn-bundle
服务名称：dtn bundle
Transport Protocol(s): TCP
传输协议：TCP
Assignee: Simon Perreault <simon@per.reau.lt>
Assignee: Simon Perreault <simon@per.reau.lt>
Contact: Simon Perreault <simon@per.reau.lt>
Contact: Simon Perreault <simon@per.reau.lt>
Description: DTN Bundle TCP CL Protocol
描述：DTN Bundle TCP CL协议
Reference: [RFC7242]
参考文献：[RFC7242]
Port Number: 4556
端口号：4556
IANA has created, under the "Bundle Protocol" registry, a sub-registry titled "Bundle Protocol TCP Convergence-Layer Version Numbers" and initialized it with the following:
IANA在“捆绑协议”注册表下创建了一个名为“捆绑协议TCP汇聚层版本号”的子注册表，并使用以下内容对其进行了初始化：
+-------+-------------+-----------+
| Value | Description | Reference |
+-------+-------------+-----------+
| 0 | Reserved | [RFC7242] |
| 1 | Reserved | [RFC7242] |
| 2 | Reserved | [RFC7242] |
| 3 | TCPCL | [RFC7242] |
| 4-255 | Unassigned | [RFC7242] |
+-------+-------------+-----------+
+-------+-------------+-----------+
| Value | Description | Reference |
+-------+-------------+-----------+
| 0 | Reserved | [RFC7242] |
| 1 | Reserved | [RFC7242] |
| 2 | Reserved | [RFC7242] |
| 3 | TCPCL | [RFC7242] |
| 4-255 | Unassigned | [RFC7242] |
+-------+-------------+-----------+
The registration procedure is RFC Required.
注册程序是RFC要求的。
IANA has created, under the "Bundle Protocol" registry, a sub-registry titled "Bundle Protocol TCP Convergence-Layer Message Types" and initialized it with the contents of Table 2. The registration procedure is RFC Required.
IANA在“捆绑协议”注册表下创建了一个名为“捆绑协议TCP汇聚层消息类型”的子注册表，并使用表2的内容对其进行了初始化。注册程序是RFC要求的。
IANA has created, under the "Bundle Protocol" registry, a sub-registry titled "Bundle Protocol TCP Convergence-Layer REFUSE_BUNDLE Reason Codes" and initialized it with the contents of Table 3. The registration procedure is RFC Required.
IANA在“Bundle Protocol”注册表下创建了一个名为“Bundle Protocol TCP Convergence Layer\u Bundle Reason Codes”的子注册表，并使用表3的内容对其进行了初始化。注册程序是RFC要求的。
IANA has created, under the "Bundle Protocol" registry, a sub-registry titled "Bundle Protocol TCP Convergence-Layer SHUTDOWN Reason Codes" and initialized it with the contents of Table 4. The registration procedure is RFC Required.
IANA在“Bundle Protocol”注册表下创建了一个名为“Bundle Protocol TCP Convergence Layer SHUTDOWN Reason Codes”的子注册表，并使用表4的内容对其进行了初始化。注册程序是RFC要求的。
The authors would like to thank the following individuals who have participated in the drafting, review, and discussion of this memo: Alex McMahon, Brenton Walker, Darren Long, Dirk Kutscher, Elwyn Davies, Jean-Philippe Dionne, Joseph Ishac, Keith Scott, Kevin Fall, Lloyd Wood, Marc Blanchet, Peter Lovell, Scott Burleigh, Stephen Farrell, Vint Cerf, and William Ivancic.
作者要感谢以下参与本备忘录起草、审查和讨论的个人：亚历克斯·麦克马洪、布伦顿·沃克、达伦·朗、德克·库彻、埃尔温·戴维斯、让·菲利普·迪翁、约瑟夫·伊萨克、基思·斯科特、凯文·法尔、劳埃德·伍德、马克·布兰切特、彼得·洛维尔、斯科特·伯利、斯蒂芬·法雷尔、，温特·瑟夫和威廉·伊万西奇。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007.
[RFC5050]Scott，K.和S.Burleigh，“捆绑协议规范”，RFC 50502007年11月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[DTNIMPL] DTNRG, "Delay-Tolerant Networking Reference Implementation", <https://sites.google.com/site/ dtnresgroup/home/code>.
[DTNIMPL]DTNRG，“延迟容忍网络参考实现”<https://sites.google.com/site/ DTNRegroup/home/code>。
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking Architecture", RFC 4838, April 2007.
[RFC4838]Cerf，V.，Burleigh，S.，Hooke，A.，Torgerson，L.，Durst，R.，Scott，K.，Fall，K.，和H.Weiss，“延迟容忍网络架构”，RFC 48382007年4月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC6256] Eddy, W. and E. Davies, "Using Self-Delimiting Numeric Values in Protocols", RFC 6256, May 2011.
[RFC6256]Eddy，W.和E.Davies，“在协议中使用自定界数值”，RFC 6256，2011年5月。
[RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell, "Bundle Security Protocol Specification", RFC 6257, May 2011.
[RFC6257]Symington，S.，Farrell，S.，Weiss，H.，和P.Lovell，“捆绑包安全协议规范”，RFC 6257，2011年5月。
Authors' Addresses
作者地址
Michael J. Demmer University of California, Berkeley Computer Science Division 445 Soda Hall Berkeley, CA 94720-1776 US
米迦勒J德默加利福尼亚大学，伯克利计算机科学司445苏打厅伯克利，CA 947 20 1776美国
EMail: demmer@cs.berkeley.edu
EMail: demmer@cs.berkeley.edu
Joerg Ott Aalto University Department of Communications and Networking PO Box 13000 AALTO 02015 Finland
约尔格·奥特·阿尔托大学通信与网络系芬兰阿尔托02015邮箱13000
EMail: jo@netlab.tkk.fi
EMail: jo@netlab.tkk.fi
Simon Perreault Quebec, QC Canada
Simon Perreault魁北克，加拿大QC
EMail: simon@per.reau.lt
EMail: simon@per.reau.lt