Internet Research Task Force (IRTF) H. Kruse
Request for Comments: 7122 Ohio University
Category: Experimental S. Jero
ISSN: 2070-1721 Purdue University
S. Ostermann
Ohio University
March 2014
Internet Research Task Force (IRTF) H. Kruse
Request for Comments: 7122 Ohio University
Category: Experimental S. Jero
ISSN: 2070-1721 Purdue University
S. Ostermann
Ohio University
March 2014
Datagram Convergence Layers for the Delay- and Disruption-Tolerant Networking (DTN) Bundle Protocol and Licklider Transmission Protocol (LTP)
延迟和中断容忍网络（DTN）捆绑协议和利克利德传输协议（LTP）的数据报聚合层
Abstract
摘要
This document specifies the preferred method for transporting Delay-and Disruption-Tolerant Networking (DTN) protocol data over the Internet using datagrams. It covers convergence layers for the Bundle Protocol (RFC 5050), as well as the transportation of segments using the Licklider Transmission Protocol (LTP) (RFC 5326). UDP and the Datagram Congestion Control Protocol (DCCP) are the candidate datagram protocols discussed. UDP can only be used on a local network or in cases where the DTN node implements explicit congestion control. DCCP addresses the congestion control problem, and its use is recommended whenever possible. This document is a product of the Delay-Tolerant Networking Research Group (DTNRG) and represents the consensus of the DTNRG.
本文件规定了使用数据报在互联网上传输延迟和中断容忍网络（DTN）协议数据的首选方法。它涵盖捆绑协议（RFC 5050）的汇聚层，以及使用利克利德传输协议（LTP）（RFC 5326）的段传输。UDP和数据报拥塞控制协议（DCCP）是讨论的候选数据报协议。UDP只能在本地网络上使用，或者在DTN节点实现显式拥塞控制的情况下使用。DCCP解决了拥塞控制问题，建议尽可能使用它。本文件是延迟容忍网络研究小组（DTNRG）的产品，代表了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/rfc7122.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7122.
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. General Recommendation . . . . . . . . . . . . . . . . . . . 4
3. Recommendations for Implementers . . . . . . . . . . . . . . 6
3.1. How and Where to Deal with Fragmentation . . . . . . . . 6
3.1.1. DCCP . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Bundle Protocol over a Datagram Convergence Layer . . . . 6
3.2.1. DCCP . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. LTP over Datagrams . . . . . . . . . . . . . . . . . . . 7
3.3.1. DCCP . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Keep-Alive Option . . . . . . . . . . . . . . . . . . . . 7
3.5. Checksums . . . . . . . . . . . . . . . . . . . . . . . . 8
3.5.1. DCCP . . . . . . . . . . . . . . . . . . . . . . . . 8
3.5.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.6. DCCP Congestion Control Modules . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. General Recommendation . . . . . . . . . . . . . . . . . . . 4
3. Recommendations for Implementers . . . . . . . . . . . . . . 6
3.1. How and Where to Deal with Fragmentation . . . . . . . . 6
3.1.1. DCCP . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Bundle Protocol over a Datagram Convergence Layer . . . . 6
3.2.1. DCCP . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. LTP over Datagrams . . . . . . . . . . . . . . . . . . . 7
3.3.1. DCCP . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Keep-Alive Option . . . . . . . . . . . . . . . . . . . . 7
3.5. Checksums . . . . . . . . . . . . . . . . . . . . . . . . 8
3.5.1. DCCP . . . . . . . . . . . . . . . . . . . . . . . . 8
3.5.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.6. DCCP Congestion Control Modules . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . 10
DTN communication protocols include the Bundle Protocol described in RFC 5050 [RFC5050], which provides transmission of application data blocks ("bundles") through optional intermediate custody transfer, and the Licklider Transmission Protocol (LTP) -- LTP Motivation [RFC5325], LTP Specification [RFC5326], and LTP Security [RFC5327] -- which can be used to transmit bundles reliably and efficiently over a point-to-point link. It is often desirable to test these protocols over Internet Protocol links. "Delay Tolerant Networking TCP Convergence Layer Protocol" [CLAYER] defines a method for transporting bundles over TCP. This document specifies the preferred method for transmitting either bundles or LTP blocks across the Internet using datagrams in place of TCP. Figure 1 shows the general protocol layering described in the DTN documents. DTN Applications interact with the Bundle Protocol Layer, which in turn uses a Convergence Layer to prepare a bundle for transmission. The Convergence Layer will typically rely on a lower-level protocol to carry out the transmission.
DTN通信协议包括RFC 5050[RFC5050]中描述的捆绑协议，该协议通过可选的中间托管传输提供应用程序数据块（“捆绑”）的传输，以及利克利德传输协议（LTP）——LTP动机[RFC5325]、LTP规范[RFC5326]和LTP安全[RFC5327]--可用于通过点到点链路可靠高效地传输捆绑包。通常需要通过Internet协议链路测试这些协议。“延迟容忍网络TCP聚合层协议”[CLAYER]定义了通过TCP传输捆绑包的方法。本文档规定了使用数据报代替TCP在Internet上传输捆绑包或LTP块的首选方法。图1显示了DTN文档中描述的通用协议分层。DTN应用程序与捆绑协议层交互，而捆绑协议层又使用汇聚层来准备捆绑包进行传输。汇聚层通常依赖较低级别的协议来执行传输。
+-----------------------------------------+
| |
| DTN Application |
| |
+-----------------------------------------+
+-----------------------------------------+
| |
| Bundle Protocol (BP) |
| |
+-----------------------------------------+
+-----------------------------------------+
| |
| Convergence Layer Adapter (CL) |
| |
+-----------------------------------------+
+-----------------------------------------+
| |
| Local Data-Link Layer (Transport) |
| |
+-----------------------------------------+
+-----------------------------------------+
| |
| DTN Application |
| |
+-----------------------------------------+
+-----------------------------------------+
| |
| Bundle Protocol (BP) |
| |
+-----------------------------------------+
+-----------------------------------------+
| |
| Convergence Layer Adapter (CL) |
| |
+-----------------------------------------+
+-----------------------------------------+
| |
| Local Data-Link Layer (Transport) |
| |
+-----------------------------------------+
Figure 1: Generic Protocol Stack for DTN
图1:DTN的通用协议栈
This document provides guidance for implementation of the two protocol stacks illustrated in Figure 2. In Figure 2(a), the Convergence Layer Adapter is UDP or DCCP for direct transport of
本文档为图2所示的两个协议栈的实现提供了指导。在图2（a）中，汇聚层适配器是UDP或DCCP，用于直接传输数据
bundles over the Internet. In Figure 2(b), the Convergence Layer Adapter is LTP, which then uses UDP or DCCP as the local data-link layer.
通过互联网进行捆绑。在图2（b）中，汇聚层适配器是LTP，然后使用UDP或DCCP作为本地数据链路层。
+-------------+ +-------------+
| | | |
| DTN App | | DTN App |
| | | |
+-------------+ +-------------+
+-------------+ +-------------+
| | | |
| BP | | BP |
| | | |
+-------------+ +-------------+
+-------------+ +-------------+
| | | |
| UDP/DCCP | | LTP |
| | | |
+-------------+ +-------------+
+-------------+
| |
| UDP/DCCP |
| |
+-------------+
+-------------+ +-------------+
| | | |
| DTN App | | DTN App |
| | | |
+-------------+ +-------------+
+-------------+ +-------------+
| | | |
| BP | | BP |
| | | |
+-------------+ +-------------+
+-------------+ +-------------+
| | | |
| UDP/DCCP | | LTP |
| | | |
+-------------+ +-------------+
+-------------+
| |
| UDP/DCCP |
| |
+-------------+
(a) (b)
(a) （b）
Figure 2: Protocol Stacks Addressed in this Document
图2：本文档中介绍的协议栈
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
In order to utilize DTN protocols across the Internet, whether for testing purposes or as part of a larger network path, it is necessary to encapsulate them into a standard Internet Protocol so that they travel easily across the Internet. This is particularly true for LTP, which provides no endpoint addressing. This encapsulation choice needs to be made carefully in order to avoid redundancy, since DTN protocols may provide their own reliability mechanisms.
为了在互联网上使用DTN协议，无论是出于测试目的还是作为更大网络路径的一部分，都有必要将它们封装到标准互联网协议中，以便它们能够轻松地在互联网上传播。LTP尤其如此，它不提供端点寻址。为了避免冗余，需要仔细选择这种封装，因为DTN协议可能提供它们自己的可靠性机制。
Congestion control is vital to the continued functioning of the Internet, particularly for situations where data will be sent at arbitrarily fast data rates. The Bundle Protocol delegates provision
拥塞控制对于互联网的持续运行至关重要，特别是在数据以任意快的数据速率发送的情况下。捆绑协议委托提供
of reliable delivery and, implicitly, congestion control to the convergence layer used (Section 7.2 of RFC 5050 [RFC5050]). In situations where TCP will work effectively in communications between pairs of DTN nodes, use of the TCP convergence layer [CLAYER] will provide the required reliability and congestion control for transport of bundles and would be the default choice in the Internet. Alternatives such as encapsulating bundles directly in datagrams and using UDP or DCCP are not generally appropriate because they offer limited reliability and, in the case of UDP, no congestion control.
对所用汇聚层的可靠传输和隐含的拥塞控制（RFC 5050[RFC5050]第7.2节）。在TCP将在DTN节点对之间的通信中有效工作的情况下，使用TCP汇聚层[CLAYER]将为捆绑包的传输提供所需的可靠性和拥塞控制，并将是Internet中的默认选择。诸如直接在数据报中封装捆绑包和使用UDP或DCCP等替代方案通常不合适，因为它们提供的可靠性有限，并且在UDP的情况下，没有拥塞控制。
LTP, on the other hand, offers its own form of reliability. Particularly for testing purposes, it makes no sense to run LTP over a protocol like TCP that offers reliability already. In addition, running LTP over TCP would reduce the flexibility available to users, since LTP offers more control over what data is delivered reliably and what data is delivered best effort, a feature that TCP lacks. As such, it would be better to run LTP over an unreliable protocol.
另一方面，LTP提供了自己的可靠性形式。特别是出于测试目的，在像TCP这样已经提供可靠性的协议上运行LTP是没有意义的。此外，在TCP上运行LTP会降低用户可用的灵活性，因为LTP提供了对可靠交付数据和尽力而为交付数据的更多控制，而TCP缺少这一功能。因此，最好在不可靠的协议上运行LTP。
One solution would be to use UDP. UDP provides no reliability, allowing LTP to manage that itself. However, UDP also does not provide congestion control. Because LTP is designed to run over fixed-rate radio links, it does provide rate control but not congestion control. Lack of congestion control in network connections is a major problem that can cause artificially high loss rates and/or serious fairness issues. Previous standards documents are unanimous in recommending congestion control for protocols to be used on the Internet, see "Congestion Control Principles" [RFC2914], "Unicast UDP Usage Guidelines" [RFC5405], and "Queue Management and Congestion Avoidance" [RFC2309], among others. RFC 5405, in particular, calls congestion control "vital" for "applications that can operate at higher, potentially unbounded data rates". Therefore, any Bundle Protocol implementation permitting the use of UDP to transport LTP segments or bundles outside an isolated network for the transmission of any non-trivial amounts of data MUST implement congestion control consistent with RFC 5405.
一种解决方案是使用UDP。UDP不提供可靠性，允许LTP自行管理。但是，UDP也不提供拥塞控制。因为LTP设计用于在固定速率的无线链路上运行，所以它确实提供速率控制，但不提供拥塞控制。网络连接中缺乏拥塞控制是一个主要问题，它可能导致人为的高丢失率和/或严重的公平性问题。先前的标准文件一致建议对互联网上使用的协议进行拥塞控制，参见“拥塞控制原则”[RFC2914]、“单播UDP使用指南”[RFC5405]和“队列管理和拥塞避免”[RFC2309]等。尤其是RFC 5405，它将拥塞控制称为“对“能够以更高的、潜在的无限数据速率运行的应用程序”至关重要。因此，任何允许使用UDP在隔离网络外部传输LTP段或捆绑包以传输任何非平凡数据量的捆绑包协议实现必须实现与RFC 5405一致的拥塞控制。
Alternatively, the Datagram Congestion Control Protocol (DCCP) [RFC4340] was designed specifically to provide congestion control without reliability for those applications that traverse the Internet but do not desire to retransmit lost data. As such, it is RECOMMENDED that, if possible, DCCP be used to transport LTP segments across the Internet.
或者，数据报拥塞控制协议（DCCP）[RFC4340]专门设计用于为那些穿越互联网但不希望重新传输丢失数据的应用程序提供无可靠性的拥塞控制。因此，建议尽可能使用DCCP在互联网上传输LTP段。
The Bundle Protocol allows bundles with sizes limited only by node resource constraints. In IPv4, the maximum size of a UDP datagram is nearly 64 KB. In IPv6, when using jumbograms [RFC2675], UDP datagrams can technically be up to 4 GB in size [RFC2147], although this option is rarely used. (Note: RFC 2147 was obsoleted by RFC 2675.) It is well understood that sending large IP datagrams that must be fragmented by the network has enormous efficiency penalties [Kent87]. The Bundle Protocol specification provides a bundle fragmentation concept [RFC5050] that allows a large bundle to be divided into bundle fragments. If the Bundle Protocol is being encapsulated in DCCP or UDP, it therefore SHOULD create each fragment of sufficiently small size that it can then be encapsulated into a datagram that will not need to be fragmented at the IP layer.
Bundle协议允许Bundle的大小仅受节点资源约束的限制。在IPv4中，UDP数据报的最大大小接近64 KB。在IPv6中，当使用巨型程序[RFC2675]时，UDP数据报在技术上可以达到4GB大小[RFC2147]，尽管很少使用此选项。（注：RFC 2147已被RFC 2675淘汰。）众所周知，发送必须由网络分段的大型IP数据报会带来巨大的效率损失[87]。捆绑包协议规范提供了捆绑包碎片概念[RFC5050]，允许将大型捆绑包划分为捆绑包碎片。如果捆绑协议被封装在DCCP或UDP中，那么它应该创建足够小的每个片段，这样就可以将其封装到不需要在IP层进行分段的数据报中。
IP fragmentation can be avoided by using IP Path MTU Discovery [RFC1191] [RFC1981], which depends on the deterministic delivery of ICMP Packet Too Big (PTB) messages from routers in the network. To bypass a condition referred to as a black hole [RFC2923], a newer specification is available in [RFC4821] to determine the IP Path MTU without the use of PTB messages. This document does not attempt to recommend one fragmentation avoidance mechanism over another; the information in this section is included for the benefit of implementers.
IP碎片可以通过使用IP路径MTU发现[RFC1191][RFC1981]来避免，这取决于网络中路由器发送的ICMP数据包过大（PTB）消息的确定性传递。为了绕过被称为黑洞[RFC2923]的情况，[RFC4821]中提供了一个更新的规范，用于在不使用PTB消息的情况下确定IP路径MTU。本文件不试图推荐一种碎片避免机制而不是另一种；本节中的信息是为了方便实施者而提供的。
Because DCCP implementations are not required to support IP fragmentation and are not allowed to enable it by default, a DCCP Convergence Layer (we will use "CL" from here on) MUST NOT accept data segments that cannot be sent as a single MTU-sized datagram.
因为DCCP实现不需要支持IP分段，并且默认情况下不允许启用它，所以DCCP聚合层（从这里开始我们将使用“CL”）不能接受不能作为单个MTU大小的数据报发送的数据段。
When an LTP CL is using UDP for datagram delivery, it SHOULD NOT create segments that will result in UDP datagrams that will need to be fragmented, as discussed above.
当LTP CL使用UDP进行数据报传递时，它不应创建导致需要分段的UDP数据报的段，如上所述。
In general, the use of the Bundle Protocol over a datagram CL is discouraged in IP networks. Bundles can be of (almost) arbitrary length, and the Bundle Protocol does not include an effective retransmission mechanism. Whenever possible, the Bundle Protocol SHOULD be operated over the TCP Convergence Layer or over LTP.
通常，IP网络中不鼓励在数据报CL上使用捆绑协议。捆绑包可以（几乎）任意长度，捆绑包协议不包括有效的重传机制。只要有可能，Bundle协议应在TCP汇聚层或LTP上运行。
If a datagram CL is used for transmission of bundles, every datagram MUST contain exactly one bundle or 4 octets of zero bits as a keep-alive. Bundles that are too large for the path MTU SHOULD be fragmented and reassembled at the Bundle Protocol layer to prevent IP fragmentation.
如果数据报CL用于捆绑包的传输，则每个数据报必须正好包含一个捆绑包或4个零位八位组作为保持活动。对于路径MTU来说太大的捆绑包应该在捆绑包协议层进行碎片化和重新组装，以防止IP碎片化。
The DCCP CL for Bundle Protocol use SHOULD use the IANA-assigned port 4556/DCCP and service code 1685351985; the use of other port numbers and service codes is implementation specific.
捆绑协议使用的DCCP CL应使用IANA分配的端口4556/DCCP和服务代码1685351985；其他端口号和服务代码的使用是特定于实现的。
The UDP CL for Bundle Protocol use SHOULD use the IANA-assigned port 4556/UDP; the use of other port numbers is implementation specific.
用于捆绑协议的UDP CL应使用IANA分配的端口4556/UDP；其他端口号的使用是特定于实现的。
LTP is designed as a point-to-point protocol within DTN, and it provides intrinsic acknowledgement and retransmission facilities. LTP segments are transported over a "local data-link layer" (RFC 5325 [RFC5325]); we will use the term "transport" from here on. Transport of LTP using datagrams is an appropriate choice. When a datagram transport is used to send LTP segments, every datagram MUST contain exactly one LTP segment or 4 octets of zero bits as a keep-alive. LTP MUST perform segmentation in such a way as to ensure that every LTP segment fits into a single packet which will not require IP fragmentation as discussed above.
LTP被设计为DTN中的点对点协议，它提供了固有的确认和重传功能。LTP段通过“本地数据链路层”（RFC 5325[RFC5325]）传输；从现在起，我们将使用“运输”一词。使用数据报传输LTP是一个合适的选择。当使用数据报传输发送LTP段时，每个数据报必须正好包含一个LTP段或4个零位八位组作为保持活动。LTP必须以这样的方式执行分段，以确保每个LTP分段都适合单个数据包，而不需要如上所述的IP分段。
The DCCP transport for LTP SHOULD use the IANA-assigned port 1113/ DCCP and service code 7107696; the use of other port numbers and service codes is implementation specific.
LTP的DCCP传输应使用IANA分配的端口1113/DCCP和服务代码7107696；其他端口号和服务代码的使用是特定于实现的。
The UDP transport for LTP SHOULD use the IANA-assigned port 1113/UDP; the use of other port numbers is implementation specific.
LTP的UDP传输应使用IANA分配的端口1113/UDP；其他端口号的使用是特定于实现的。
It may be desirable for a UDP or DCCP CL or transport to send "keep-alive" packets during extended idle periods. This may be needed to refresh a contact table entry at the destination, or to maintain an address mapping in a NAT or a dynamic access rule in a firewall. Therefore, the CL or transport MAY send a datagram containing exactly
UDP或DCCP CL或传输可能需要在延长的空闲时间内发送“保持活动”数据包。刷新目的地的联系人表条目，或者在NAT中维护地址映射，或者在防火墙中维护动态访问规则，都可能需要这样做。因此，CL或传输可以发送一个数据报，其中包含
4 octets of zero bits. The CL or transport receiving such a packet MUST discard this packet. The receiving CL or transport may then perform local maintenance of its state tables; these maintenance functions are not covered in this document. Note that packets carrying bundles or segments will always contain more than 4 octets of information (either the bundle or the LTP header); keep-alive packets will therefore never be mistaken for actual data packets. If UDP or DCCP is being used for communication in both directions between a pair of bundle agents, transmission and processing of keep-alives in the two directions occurs independently. Keep-alive intervals SHOULD be configurable, SHOULD default to 15 seconds, and MUST NOT be configured shorter than 15 seconds.
4个零位八位组。接收此类数据包的CL或传输必须丢弃此数据包。然后，接收CL或传输可执行其状态表的本地维护；本文件不包括这些维护功能。注意，携带包或段的数据包将始终包含超过4个八位字节的信息（包或LTP头）；因此，“保持活动”数据包永远不会被误认为是实际的数据包。如果UDP或DCCP用于一对捆绑代理之间的双向通信，则在这两个方向上的保持有效性的传输和处理将独立进行。保持活动时间间隔应可配置，应默认为15秒，且不得配置为小于15秒。
Both the core Bundle Protocol specification and core LTP specification assume that they are transmitting over an erasure channel, i.e., a channel that either delivers packets correctly or not at all.
核心捆绑协议规范和核心LTP规范都假定它们是通过擦除信道进行传输的，即，要么正确地传递数据包，要么根本不传递数据包的信道。
A DCCP transmitter MUST, therefore, ensure that the entire packet is checksummed by setting the Checksum Coverage to zero. Likewise, the DCCP receiver MUST ignore all packets with partial checksum coverage.
因此，DCCP发送器必须通过将校验和覆盖率设置为零来确保对整个数据包进行校验和。同样，DCCP接收器必须忽略具有部分校验和覆盖的所有数据包。
A UDP transmitter, therefore, MUST NOT disable UDP checksums, and the UDP receiver MUST NOT disable the checking of received UDP checksums.
因此，UDP发送器不得禁用UDP校验和，UDP接收器不得禁用对接收到的UDP校验和的检查。
Even when UDP checksums are enabled, a small probability of UDP packet corruption remains. In some environments, it may be acceptable for LTP or the Bundle Protocol to occasionally receive corrupted input. In general, however, a UDP implementation SHOULD use optional security extensions available in the Bundle Protocol or LTP to protect against message corruption.
即使启用UDP校验和，UDP数据包损坏的可能性仍然很小。在某些环境中，LTP或捆绑协议偶尔接收损坏的输入是可以接受的。但是，一般来说，UDP实现应该使用捆绑协议或LTP中提供的可选安全扩展来防止消息损坏。
DCCP supports pluggable congestion control modules in order to optimize its behavior to particular environments. The two most common congestion control modules (CCIDs) are TCP-like Congestion Control (CCID2) [RFC4341] and TCP-Friendly Rate Control (CCID3) [RFC4342]. TCP-like Congestion Control is designed to emulate TCP's congestion control as much as possible. It is recommended for applications that want to send data as quickly as possible, while TCP-Friendly Rate Control is aimed at applications that want to avoid
DCCP支持可插拔拥塞控制模块，以优化其对特定环境的行为。两个最常见的拥塞控制模块（CCID）是类TCP拥塞控制（CCID2）[RFC4341]和TCP友好速率控制（CCID3）[RFC4342]。类似TCP的拥塞控制旨在尽可能地模拟TCP的拥塞控制。建议用于希望尽快发送数据的应用程序，而TCP友好的速率控制则针对希望避免错误的应用程序
sudden changes in sending rate. DTN use cases seem to fit more into the first case, so DCCP CL's and transports SHOULD use TCP-like Congestion Control (CCID2) by default.
发送速率的突然变化。DTN用例似乎更适合第一种情况，因此DCCP CL和传输在默认情况下应该使用类似TCP的拥塞控制（CCID2）。
Port number assignments 1113/UDP and 4556/UDP have been registered with IANA. The assignment for 1113/UDP referenced [RFC5326]; this entry has been changed to add the present document in addition to [RFC5326]. The assignment of 4556/UDP had no reference; this entry has been changed to point to the present document. The service name for 4556/UDP has been changed from dtn-bundle-udp to dtn-bundle. Port number 1113/DCCP (ltp-deepspace) with Service Code 7107696 has been assigned for the transport of LTP. Port number 4556/DCCP (dtn-bundle) with Service Code 1685351985 has been assigned for the transport of bundles. The port number assignment for 4556/TCP is addressed in the [CLAYER] document.
端口号分配1113/UDP和4556/UDP已向IANA注册。1113/UDP的赋值引用[RFC5326]；除了[RFC5326]之外，此条目已更改为添加当前文档。4556/UDP的分配没有参考；此条目已更改为指向当前文档。4556/UDP的服务名称已从dtn bundle UDP更改为dtn bundle。已为ltp的运输分配了服务代码为7107696的端口号1113/DCCP（ltp deepspace）。已为捆绑包的传输分配了服务代码为1685351985的端口号4556/DCCP（dtn捆绑包）。[CLAYER]文档中介绍了4556/TCP的端口号分配。
This memo describes the use of datagrams to transport DTN application data. Hosts may be in the position of having to accept and process packets from unknown sources; the DTN Endpoint ID can be discovered only after the bundle has been retrieved from the DCCP or UDP packet. Hosts SHOULD use authentication methods available in the DTN specifications to prevent malicious hosts from inserting unknown data into the application.
本备忘录描述了使用数据报传输DTN应用程序数据。主机可能不得不接受和处理来自未知来源的数据包；只有在从DCCP或UDP数据包检索到包之后，才能发现DTN端点ID。主机应使用DTN规范中提供的身份验证方法，以防止恶意主机将未知数据插入应用程序。
Hosts need to listen for and process DCCP or UDP data on the known LTP or Bundle Protocol ports. A denial-of-service scenario exists where a malicious host sends datagrams at a high rate, forcing the receiving hosts to use their resources to process and attempt to authenticate this data. Whenever possible, hosts SHOULD use IP address filtering to limit the origin of packets to known hosts.
主机需要侦听和处理已知LTP或捆绑协议端口上的DCCP或UDP数据。存在拒绝服务场景，恶意主机以高速率发送数据报，迫使接收主机使用其资源处理并尝试验证此数据。只要有可能，主机应使用IP地址过滤将数据包的来源限制为已知主机。
[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月。
[RFC2147] Borman, D., "TCP and UDP over IPv6 Jumbograms", RFC 2147, May 1997.
[RFC2147]Borman，D.，“IPv6巨型程序上的TCP和UDP”，RFC 2147，1997年5月。
[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, August 1999.
[RFC2675]Borman，D.，Deering，S.，和R.Hinden，“IPv6巨型程序”，RFC 26751999年8月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]Kohler，E.，Handley，M.和S.Floyd，“数据报拥塞控制协议（DCCP）”，RFC 43402006年3月。
[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control", RFC 4341, March 2006.
[RFC4341]Floyd，S.和E.Kohler，“数据报拥塞控制协议（DCCP）拥塞控制ID 2的配置文件：类似TCP的拥塞控制”，RFC 43412006年3月。
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007.
[RFC5050]Scott，K.和S.Burleigh，“捆绑协议规范”，RFC 50502007年11月。
[RFC5325] Burleigh, S., Ramadas, M., and S. Farrell, "Licklider Transmission Protocol - Motivation", RFC 5325, September 2008.
[RFC5325]Burleigh，S.，Ramadas，M.，和S.Farrell，“利克利德传输协议-动机”，RFC 53252008年9月。
[RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider Transmission Protocol - Specification", RFC 5326, September 2008.
[RFC5326]Ramadas，M.，Burleigh，S.和S.Farrell，“利克利德传输协议-规范”，RFC 5326，2008年9月。
[RFC5327] Farrell, S., Ramadas, M., and S. Burleigh, "Licklider Transmission Protocol - Security Extensions", RFC 5327, September 2008.
[RFC5327]Farrell，S.，Ramadas，M.，和S.Burleigh，“利克利德传输协议-安全扩展”，RFC 5327，2008年9月。
[CLAYER] Demmer, M., Ott, J., and S. Perreault, "Delay Tolerant Networking TCP Convergence Layer Protocol", Work in Progress, January 2014.
[CLAYER]Demmer，M.，Ott，J.，和S.Perreault，“延迟容忍网络TCP汇聚层协议”，正在进行的工作，2014年1月。
[Kent87] Kent, C. and J. Mogul, "Fragmentation considered harmful", SIGCOMM '87, Proceedings of the ACM workshop on Frontiers in computer communications technology, 1987, <http://doi.acm.org/10.1145/55482.55524>.
[Kent87]Kent，C.和J.Mogul，“碎片被认为是有害的”，SIGCOMM'87，ACM计算机通信技术前沿研讨会论文集，1987年<http://doi.acm.org/10.1145/55482.55524>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，1990年11月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]McCann，J.，Deering，S.，和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，1996年8月。
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J., and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.
[RFC2309]Braden，B.，Clark，D.，Crowcroft，J.，Davie，B.，Deering，S.，Estrin，D.，Floyd，S.，Jacobson，V.，Minshall，G.，Partridge，C.，Peterson，L.，Ramakrishnan，K.，Shenker，S.，Wroclawski，J.，和L.Zhang，“关于互联网中队列管理和拥塞避免的建议”，RFC 2309，1998年4月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]Floyd，S.，“拥塞控制原则”，BCP 41，RFC 2914，2000年9月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2923]Lahey，K.，“路径MTU发现的TCP问题”，RFC 29232000年9月。
[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, March 2006.
[RFC4342]Floyd，S.，Kohler，E.，和J.Padhye，“数据报拥塞控制协议（DCCP）拥塞控制ID 3的配置文件：TCP友好速率控制（TFRC）”，RFC 43422006年3月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821]Mathis，M.和J.Heffner，“打包层路径MTU发现”，RFC 48212007年3月。
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
[RFC5405]Eggert，L.和G.Fairhurst，“应用程序设计者的单播UDP使用指南”，BCP 145，RFC 5405，2008年11月。
Authors' Addresses
作者地址
Hans Kruse Ohio University 31 S. Court Street, Rm 150 Athens, OH 45701 United States
美国俄亥俄州雅典市S.Court Street 31号汉斯·克鲁斯俄亥俄大学150室，邮编：45701
Phone: +1 740 593 4891
EMail: kruse@ohio.edu
Phone: +1 740 593 4891
EMail: kruse@ohio.edu
Samuel Jero Purdue University West Lafayette, IN 47907 United States
塞缪尔·杰罗·普渡大学西拉斐特分校，美国47907
EMail: sjero@purdue.edu
EMail: sjero@purdue.edu
Shawn Ostermann Ohio University Stocker Engineering Center Athens, OH 45701 United States
肖恩·奥斯特曼俄亥俄大学斯托克工程中心美国俄亥俄州雅典45701
Phone: +1 740 593 1566
EMail: ostermann@eecs.ohiou.edu
Phone: +1 740 593 1566
EMail: ostermann@eecs.ohiou.edu