Network Working Group V. Cerf
Request for Comments: 4838 Google/Jet Propulsion Laboratory
Category: Informational S. Burleigh
A. Hooke
L. Torgerson
NASA/Jet Propulsion Laboratory
R. Durst
K. Scott
The MITRE Corporation
K. Fall
Intel Corporation
H. Weiss
SPARTA, Inc.
April 2007
Network Working Group V. Cerf
Request for Comments: 4838 Google/Jet Propulsion Laboratory
Category: Informational S. Burleigh
A. Hooke
L. Torgerson
NASA/Jet Propulsion Laboratory
R. Durst
K. Scott
The MITRE Corporation
K. Fall
Intel Corporation
H. Weiss
SPARTA, Inc.
April 2007
Delay-Tolerant Networking Architecture
容错网络体系结构
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
IESG Note
IESG注释
This RFC is a product of the Internet Research Task Force and is not a candidate for any level of Internet Standard. The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment on the public Internet.
本RFC是互联网研究工作组的产品，不适用于任何级别的互联网标准。IRTF发布互联网相关研究和开发活动的结果。这些结果可能不适合在公共互联网上部署。
Abstract
摘要
This document describes an architecture for delay-tolerant and disruption-tolerant networks, and is an evolution of the architecture originally designed for the Interplanetary Internet, a communication system envisioned to provide Internet-like services across interplanetary distances in support of deep space exploration. This document describes an architecture that addresses a variety of problems with internetworks having operational and performance characteristics that make conventional (Internet-like) networking approaches either unworkable or impractical. We define a message-oriented overlay that exists above the transport (or other) layers of
本文件描述了一种耐延迟和耐中断网络的体系结构，是最初为星际互联网设计的体系结构的演变。星际互联网是一种通信系统，旨在跨星际距离提供类似互联网的服务，以支持深空探索。本文档描述了一种体系结构，该体系结构解决了互联网的各种问题，这些问题具有操作和性能特征，使得传统（类似互联网的）联网方法不可行或不切实际。我们定义了一个面向消息的覆盖，它存在于消息的传输（或其他）层之上
the networks it interconnects. The document presents a motivation for the architecture, an architectural overview, review of state management required for its operation, and a discussion of application design issues. This document represents the consensus of the IRTF DTN research group and has been widely reviewed by that group.
它所连接的网络。本文档介绍了体系结构的动机、体系结构概述、运行所需状态管理的回顾以及应用程序设计问题的讨论。本文件代表了IRTF DTN研究小组的共识，并已被该小组广泛审查。
Table of Contents
目录
1. Introduction ....................................................3
2. Why an Architecture for Delay-Tolerant Networking? ..............4
3. DTN Architectural Description ...................................5
3.1. Virtual Message Switching Using Store-and-Forward
Operation ..................................................5
3.2. Nodes and Endpoints ........................................7
3.3. Endpoint Identifiers (EIDs) and Registrations ..............8
3.4. Anycast and Multicast .....................................10
3.5. Priority Classes ..........................................10
3.6. Postal-Style Delivery Options and Administrative Records ..11
3.7. Primary Bundle Fields .....................................15
3.8. Routing and Forwarding ....................................16
3.9. Fragmentation and Reassembly ..............................18
3.10. Reliability and Custody Transfer .........................19
3.11. DTN Support for Proxies and Application Layer Gateways ...21
3.12. Timestamps and Time Synchronization ......................22
3.13. Congestion and Flow Control at the Bundle Layer ..........22
3.14. Security .................................................23
4. State Management Considerations ................................25
4.1. Application Registration State ............................25
4.2. Custody Transfer State ....................................26
4.3. Bundle Routing and Forwarding State .......................26
4.4. Security-Related State ....................................27
4.5. Policy and Configuration State ............................27
5. Application Structuring Issues .................................28
6. Convergence Layer Considerations for Use of Underlying
Protocols ......................................................28
7. Summary ........................................................29
8. Security Considerations ........................................29
9. IANA Considerations ............................................30
10. Normative References ..........................................30
11. Informative References ........................................30
12. Acknowledgments ...............................................32
1. Introduction ....................................................3
2. Why an Architecture for Delay-Tolerant Networking? ..............4
3. DTN Architectural Description ...................................5
3.1. Virtual Message Switching Using Store-and-Forward
Operation ..................................................5
3.2. Nodes and Endpoints ........................................7
3.3. Endpoint Identifiers (EIDs) and Registrations ..............8
3.4. Anycast and Multicast .....................................10
3.5. Priority Classes ..........................................10
3.6. Postal-Style Delivery Options and Administrative Records ..11
3.7. Primary Bundle Fields .....................................15
3.8. Routing and Forwarding ....................................16
3.9. Fragmentation and Reassembly ..............................18
3.10. Reliability and Custody Transfer .........................19
3.11. DTN Support for Proxies and Application Layer Gateways ...21
3.12. Timestamps and Time Synchronization ......................22
3.13. Congestion and Flow Control at the Bundle Layer ..........22
3.14. Security .................................................23
4. State Management Considerations ................................25
4.1. Application Registration State ............................25
4.2. Custody Transfer State ....................................26
4.3. Bundle Routing and Forwarding State .......................26
4.4. Security-Related State ....................................27
4.5. Policy and Configuration State ............................27
5. Application Structuring Issues .................................28
6. Convergence Layer Considerations for Use of Underlying
Protocols ......................................................28
7. Summary ........................................................29
8. Security Considerations ........................................29
9. IANA Considerations ............................................30
10. Normative References ..........................................30
11. Informative References ........................................30
12. Acknowledgments ...............................................32
This document describes an architecture for delay and disruption-tolerant interoperable networking (DTN). The architecture embraces the concepts of occasionally-connected networks that may suffer from frequent partitions and that may be comprised of more than one divergent set of protocols or protocol families. The basis for this architecture lies with that of the Interplanetary Internet, which focused primarily on the issue of deep space communication in high-delay environments. We expect the DTN architecture described here to be utilized in various operational environments, including those subject to disruption and disconnection and those with high-delay; the case of deep space is one specialized example of these, and is being pursued as a specialization of this architecture (See [IPN01] and [SB03] for more details).
本文档描述了一种延迟和中断容忍互操作网络（DTN）的体系结构。该体系结构包含偶尔连接的网络的概念，这些网络可能受到频繁分区的影响，并且可能由多个不同的协议集或协议族组成。这种架构的基础是星际互联网，它主要关注高延迟环境中的深空通信问题。我们希望这里描述的DTN体系结构能够在各种操作环境中使用，包括那些受到干扰和断开连接的环境以及那些具有高延迟的环境；深空是其中一个专门的例子，目前正在作为该体系结构的一个专门化进行研究（有关更多详细信息，请参见[IPN01]和[SB03]）。
Other networks to which we believe this architecture applies include sensor-based networks using scheduled intermittent connectivity, terrestrial wireless networks that cannot ordinarily maintain end-to-end connectivity, satellite networks with moderate delays and periodic connectivity, and underwater acoustic networks with moderate delays and frequent interruptions due to environmental factors. A DTN tutorial [FW03], aimed at introducing DTN and the types of networks for which it is designed, is available to introduce new readers to the fundamental concepts and motivation. More technical descriptions may be found in [KF03], [JFP04], [JDPF05], and [WJMF05].
我们认为该体系结构适用的其他网络包括使用计划间歇连接的基于传感器的网络、通常无法保持端到端连接的地面无线网络、具有适度延迟和定期连接的卫星网络，以及由于环境因素造成的中度延迟和频繁中断的水声网络。DTN教程[FW03]旨在介绍DTN及其设计的网络类型，可向新读者介绍基本概念和动机。更多技术说明可在[KF03]、[JFP04]、[JDPF05]和[WJMF05]中找到。
We define an end-to-end message-oriented overlay called the "bundle layer" that exists at a layer above the transport (or other) layers of the networks on which it is hosted and below applications. Devices implementing the bundle layer are called DTN nodes. The bundle layer forms an overlay that employs persistent storage to help combat network interruption. It includes a hop-by-hop transfer of reliable delivery responsibility and optional end-to-end acknowledgement. It also includes a number of diagnostic and management features. For interoperability, it uses a flexible naming scheme (based on Uniform Resource Identifiers [RFC3986]) capable of encapsulating different naming and addressing schemes in the same overall naming syntax. It also has a basic security model, optionally enabled, aimed at protecting infrastructure from unauthorized use.
我们定义了一个面向端到端消息的覆盖层，称为“bundle层”，它位于承载它的网络的传输（或其他）层之上和应用程序之下。实现捆绑层的设备称为DTN节点。捆绑层形成一个覆盖层，该覆盖层使用持久存储来帮助对抗网络中断。它包括可靠交付责任的逐跳传输和可选的端到端确认。它还包括许多诊断和管理功能。为了实现互操作性，它使用灵活的命名方案（基于统一资源标识符[RFC3986]），能够以相同的总体命名语法封装不同的命名和寻址方案。它还有一个基本的安全模型，可以选择启用，旨在保护基础设施免受未经授权的使用。
The bundle layer provides functionality similar to the internet layer of gateways described in the original ARPANET/Internet designs [CK74]. It differs from ARPANET gateways, however, because it is layer-agnostic and is focused on virtual message forwarding rather than packet switching. However, both generally provide interoperability between underlying protocols specific to one
捆绑层提供的功能类似于原始ARPANET/互联网设计中描述的网关互联网层[CK74]。然而，它不同于ARPANET网关，因为它是层不可知的，并且专注于虚拟消息转发而不是数据包交换。然而，两者通常都提供特定于一个应用程序的底层协议之间的互操作性
environment and those protocols specific to another, and both provide a store-and-forward forwarding service (with the bundle layer employing persistent storage for its store and forward function).
环境和特定于另一个环境的协议，两者都提供存储和转发服务（包层使用持久存储来实现其存储和转发功能）。
In a sense, the DTN architecture provides a common method for interconnecting heterogeneous gateways or proxies that employ store-and-forward message routing to overcome communication disruptions. It provides services similar to electronic mail, but with enhanced naming, routing, and security capabilities. Nodes unable to support the full capabilities required by this architecture may be supported by application-layer proxies acting as DTN applications.
从某种意义上说，DTN体系结构提供了一种互连异构网关或代理的通用方法，这些网关或代理采用存储转发消息路由来克服通信中断。它提供类似于电子邮件的服务，但具有增强的命名、路由和安全功能。作为DTN应用程序的应用层代理可能支持无法支持此体系结构所需的全部功能的节点。
Our motivation for pursuing an architecture for delay tolerant networking stems from several factors. These factors are summarized below; much more detail on their rationale can be explored in [SB03], [KF03], and [DFS02].
我们追求延迟容忍网络体系结构的动机来自几个因素。这些因素总结如下；[SB03]、[KF03]和[DFS02]中详细介绍了其原理。
The existing Internet protocols do not work well for some environments, due to some fundamental assumptions built into the Internet architecture:
由于互联网体系结构中的一些基本假设，现有的互联网协议在某些环境下无法正常工作：
- that an end-to-end path between source and destination exists for the duration of a communication session
- 在通信会话期间，源和目标之间存在端到端路径
- (for reliable communication) that retransmissions based on timely and stable feedback from data receivers is an effective means for repairing errors
- （对于可靠通信）基于数据接收器及时稳定反馈的重传是修复错误的有效手段
- that end-to-end loss is relatively small
- 这种端到端的损失相对较小
- that all routers and end stations support the TCP/IP protocols
- 所有路由器和终端站都支持TCP/IP协议
- that applications need not worry about communication performance
- 应用程序不必担心通信性能
- that endpoint-based security mechanisms are sufficient for meeting most security concerns
- 基于端点的安全机制足以满足大多数安全问题
- that packet switching is the most appropriate abstraction for interoperability and performance
- 分组交换是互操作性和性能最合适的抽象
- that selecting a single route between sender and receiver is sufficient for achieving acceptable communication performance
- 在发送方和接收方之间选择单一路由足以实现可接受的通信性能
The DTN architecture is conceived to relax most of these assumptions, based on a number of design principles that are summarized here (and further discussed in [KF03]):
DTN体系结构旨在根据此处总结的许多设计原则（并在[KF03]中进一步讨论）放松大部分假设：
- Use variable-length (possibly long) messages (not streams or limited-sized packets) as the communication abstraction to help enhance the ability of the network to make good scheduling/path selection decisions when possible.
- 使用可变长度（可能较长）消息（而不是流或有限大小的数据包）作为通信抽象，以帮助增强网络的能力，以便在可能的情况下做出良好的调度/路径选择决策。
- Use a naming syntax that supports a wide range of naming and addressing conventions to enhance interoperability.
- 使用支持多种命名和寻址约定的命名语法来增强互操作性。
- Use storage within the network to support store-and-forward operation over multiple paths, and over potentially long timescales (i.e., to support operation in environments where many and/or no end-to-end paths may ever exist); do not require end-to-end reliability.
- 使用网络中的存储来支持多条路径上的存储和转发操作，以及可能存在的较长时间尺度（即，支持在可能存在许多和/或没有端到端路径的环境中的操作）；不需要端到端的可靠性。
- Provide security mechanisms that protect the infrastructure from unauthorized use by discarding traffic as quickly as possible.
- 提供安全机制，通过尽快丢弃流量来保护基础架构不被未经授权的使用。
- Provide coarse-grained classes of service, delivery options, and a way to express the useful lifetime of data to allow the network to better deliver data in serving the needs of applications.
- 提供粗粒度的服务类、交付选项，以及表示数据有用生命周期的方法，以允许网络更好地交付数据，满足应用程序的需求。
The use of the bundle layer is guided not only by its own design principles, but also by a few application design principles:
bundle层的使用不仅受其自身设计原则的指导，还受一些应用程序设计原则的指导：
- Applications should minimize the number of round-trip exchanges.
- 应用程序应尽量减少往返交换的次数。
- Applications should cope with restarts after failure while network transactions remain pending.
- 当网络事务仍然挂起时，应用程序应处理故障后的重新启动。
- Applications should inform the network of the useful life and relative importance of data to be delivered.
- 应用程序应告知网络要交付的数据的使用寿命和相对重要性。
These issues are discussed in further detail in Section 5.
第5节将进一步详细讨论这些问题。
The previous section summarized the design principles that guide the definition of the DTN architecture. This section presents a description of the major features of the architecture resulting from design decisions guided by the aforementioned design principles.
上一节总结了指导DTN体系结构定义的设计原则。本节描述了由上述设计原则指导的设计决策所产生的体系结构的主要特征。
A DTN-enabled application sends messages of arbitrary length, also called Application Data Units or ADUs [CT90], which are subject to any implementation limitations. The relative order of ADUs might not be preserved. ADUs are typically sent by and delivered to
启用DTN的应用程序发送任意长度的消息，也称为应用程序数据单元或ADU[CT90]，这些消息受任何实现限制。ADUs的相对顺序可能不会得到保留。ADU通常由发送和交付至
applications in complete units, although a system interface that behaves differently is not precluded.
完整单元中的应用程序，但不排除行为不同的系统接口。
ADUs are transformed by the bundle layer into one or more protocol data units called "bundles", which are forwarded by DTN nodes. Bundles have a defined format containing two or more "blocks" of data. Each block may contain either application data or other information used to deliver the containing bundle to its destination(s). Blocks serve the purpose of holding information typically found in the header or payload portion of protocol data units in other protocol architectures. The term "block" is used instead of "header" because blocks may not appear at the beginning of a bundle due to particular processing requirements (e.g., digital signatures).
ADU由包层转换为一个或多个协议数据单元，称为“包”，由DTN节点转发。捆绑包具有包含两个或多个“块”数据的定义格式。每个块可能包含应用程序数据或用于将包含的包传递到其目的地的其他信息。块用于保存通常在其他协议体系结构中的协议数据单元的报头或有效负载部分中找到的信息。使用术语“块”代替“头”，因为由于特殊的处理要求（例如，数字签名），块可能不会出现在包的开头。
Bundles may be split up ("fragmented") into multiple constituent bundles (also called "fragments" or "bundle fragments") during transmission. Fragments are themselves bundles, and may be further fragmented. Two or more fragments may be reassembled anywhere in the network, forming a new bundle.
在传输过程中，捆绑包可能被分成多个组成捆绑包（也称为“碎片”或“捆绑包碎片”）。片段本身就是束，可能会进一步碎片化。两个或多个碎片可以在网络中的任何位置重新组装，形成一个新的束。
Bundle sources and destinations are identified by (variable-length) Endpoint Identifiers (EIDs, described below), which identify the original sender and final destination(s) of bundles, respectively. Bundles also contain a "report-to" EID used when special operations are requested to direct diagnostic output to an arbitrary entity (e.g., other than the source). An EID may refer to one or more DTN nodes (i.e., for multicast destinations or "report-to" destinations).
捆绑包源和目的地由（可变长度）端点标识符（EID，如下所述）标识，分别标识捆绑包的原始发送方和最终目的地。捆绑包还包含一个“报告到”EID，用于请求特殊操作将诊断输出定向到任意实体（例如，源以外的实体）。EID可指一个或多个DTN节点（即，对于多播目的地或“向”目的地报告）。
While IP networks are based on "store-and-forward" operation, there is an assumption that the "storing" will not persist for more than a modest amount of time, on the order of the queuing and transmission delay. In contrast, the DTN architecture does not expect that network links are always available or reliable, and instead expects that nodes may choose to store bundles for some time. We anticipate that most DTN nodes will use some form of persistent storage for this -- disk, flash memory, etc. -- and that stored bundles will survive system restarts.
虽然IP网络基于“存储和转发”操作，但有一个假设，即“存储”不会持续超过一定的时间，这取决于排队和传输延迟的顺序。相比之下，DTN体系结构并不期望网络链路始终可用或可靠，而是期望节点可以选择存储捆绑包一段时间。我们预计大多数DTN节点将为此使用某种形式的持久性存储—磁盘、闪存等—并且存储的捆绑包将在系统重新启动后继续存在。
Bundles contain an originating timestamp, useful life indicator, a class of service designator, and a length. This information provides bundle-layer routing with a priori knowledge of the size and performance requirements of requested data transfers. When there is a significant amount of queuing that can occur in the network (as is the case in the DTN version of store-and-forward), the advantage provided by knowing this information may be significant for making scheduling and path selection decisions [JFP04]. An alternative abstraction (i.e., of stream-based delivery based on packets) would
捆绑包包含原始时间戳、使用寿命指示器、服务类别指示符和长度。该信息为捆绑层路由提供了所请求数据传输的大小和性能要求的先验知识。当网络中可能出现大量排队时（如DTN版本的store and forward），了解此信息所提供的优势对于做出调度和路径选择决策可能非常重要[JFP04]。另一种抽象（即基于数据包的基于流的交付）将
make such scheduling much more difficult. Although packets provide some of the same benefits as bundles, larger aggregates provide a way for the network to apply scheduling and buffer management to units of data that are more useful to applications.
使这样的日程安排更加困难。尽管数据包提供了与捆绑包相同的一些好处，但更大的聚合为网络提供了一种方法，可以将调度和缓冲区管理应用于对应用程序更有用的数据单元。
An essential element of the bundle-based style of forwarding is that bundles have a place to wait in a queue until a communication opportunity ("contact") is available. This highlights the following assumptions:
基于捆绑包的转发方式的一个基本要素是，捆绑包在队列中有一个位置等待，直到有通信机会（“联系”）可用。这突出了以下假设：
1. that storage is available and well-distributed throughout the network,
1. 存储在整个网络中可用且分布良好，
2. that storage is sufficiently persistent and robust to store bundles until forwarding can occur, and
2. 该存储具有足够的持久性和健壮性，可以存储捆绑包，直到发生转发，以及
3. (implicitly) that this "store-and-forward" model is a better choice than attempting to effect continuous connectivity or other alternatives.
3. （隐含地）这种“存储转发”模式比试图实现连续连接或其他替代方案更好。
For a network to effectively support the DTN architecture, these assumptions must be considered and must be found to hold. Even so, the inclusion of long-term storage as a fundamental aspect of the DTN architecture poses new problems, especially with respect to congestion management and denial-of-service mitigation. Node storage in essence represents a new resource that must be managed and protected. Much of the research in DTN revolves around exploring these issues. Congestion is discussed in Section 3.13, and security mechanisms, including methods for DTN nodes to protect themselves from handling unauthorized traffic from other nodes, are discussed in [DTNSEC] and [DTNSOV].
为了使网络能够有效地支持DTN体系结构，必须考虑并发现这些假设成立。即便如此，将长期存储作为DTN体系结构的一个基本方面也带来了新的问题，特别是在拥塞管理和拒绝服务缓解方面。节点存储本质上是一种必须管理和保护的新资源。DTN中的许多研究都围绕着探索这些问题展开。第3.13节讨论了拥塞问题，[DTNSEC]和[DTNSOV]中讨论了安全机制，包括DTN节点保护自己不处理来自其他节点的未经授权流量的方法。
A DTN node (or simply "node" in this document) is an engine for sending and receiving bundles -- an implementation of the bundle layer. Applications utilize DTN nodes to send or receive ADUs carried in bundles (applications also use DTN nodes when acting as report-to destinations for diagnostic information carried in bundles). Nodes may be members of groups called "DTN endpoints". A DTN endpoint is therefore a set of DTN nodes. A bundle is considered to have been successfully delivered to a DTN endpoint when some minimum subset of the nodes in the endpoint has received the bundle without error. This subset is called the "minimum reception group" (MRG) of the endpoint. The MRG of an endpoint may refer to one node (unicast), one of a group of nodes (anycast), or all of a group of nodes (multicast and broadcast). A single node may be in the MRG of multiple endpoints.
DTN节点（或本文中的“节点”）是发送和接收捆绑包的引擎——捆绑包层的实现。应用程序利用DTN节点发送或接收捆绑包中携带的ADU（应用程序在充当捆绑包中携带的诊断信息的目的地报告时也使用DTN节点）。节点可以是称为“DTN端点”的组的成员。因此，DTN端点是一组DTN节点。当端点中的某个最小节点子集无误地接收到捆绑包时，认为捆绑包已成功交付到DTN端点。该子集称为端点的“最小接收组”（MRG）。端点的MRG可指一个节点（单播）、一组节点中的一个节点（选播）或一组节点中的所有节点（多播和广播）。单个节点可能位于多个端点的MRG中。
An Endpoint Identifier (EID) is a name, expressed using the general syntax of URIs (see below), that identifies a DTN endpoint. Using an EID, a node is able to determine the MRG of the DTN endpoint named by the EID. Each node is also required to have at least one EID that uniquely identifies it.
端点标识符（EID）是一个名称，使用URI的通用语法表示（见下文），用于标识DTN端点。使用EID，节点能够确定由EID命名的DTN端点的MRG。每个节点还需要至少有一个唯一标识它的EID。
Applications send ADUs destined for an EID, and may arrange for ADUs sent to a particular EID to be delivered to them. Depending on the construction of the EID being used (see below), there may be a provision for wildcarding some portion of an EID, which is often useful for diagnostic and routing purposes.
应用程序发送目的地为EID的ADU，并且可以安排将发送到特定EID的ADU交付给它们。根据所使用的EID的构造（见下文），可能有一个用于通配符EID的某些部分的规定，这通常用于诊断和路由目的。
An application's desire to receive ADUs destined for a particular EID is called a "registration", and in general is maintained persistently by a DTN node. This allows application registration information to survive application and operating system restarts.
应用程序希望接收目的地为特定EID的ADU称为“注册”，通常由DTN节点持续维护。这允许应用程序注册信息在应用程序和操作系统重新启动后仍然有效。
An application's attempt to establish a registration is not guaranteed to succeed. For example, an application could request to register itself to receive ADUs by specifying an Endpoint ID that is uninterpretable or unavailable to the DTN node servicing the request. Such requests are likely to fail.
应用程序建立注册的尝试不一定成功。例如，应用程序可以通过指定一个端点ID来请求注册自身以接收ADU，该端点ID对于服务于请求的DTN节点来说是不可理解的或不可用的。这样的请求很可能会失败。
Each Endpoint ID is expressed syntactically as a Uniform Resource Identifier (URI) [RFC3986]. The URI syntax has been designed as a way to express names or addresses for a wide range of purposes, and is therefore useful for constructing names for DTN endpoints.
每个端点ID以语法形式表示为统一资源标识符（URI）[RFC3986]。URI语法被设计为一种表达名称或地址的方法，用于广泛的用途，因此对于构造DTN端点的名称非常有用。
In URI terminology, each URI begins with a scheme name. The scheme name is an element of the set of globally-managed scheme names maintained by IANA [ISCHEMES]. Lexically following the scheme name in a URI is a series of characters constrained by the syntax defined by the scheme. This portion of the URI is called the scheme-specific part (SSP), and can be quite general. (See, as one example, the URI scheme for SNMP [RFC4088]). Note that scheme-specific syntactical and semantic restrictions may be more constraining than the basic rules of RFC 3986. Section 3.1 of RFC 3986 provides guidance on the syntax of scheme names.
在URI术语中，每个URI都以一个方案名称开头。方案名称是IANA[ISCHEMES]维护的一组全局管理方案名称中的一个元素。URI中方案名称的词汇后面是一系列受方案定义的语法约束的字符。URI的这一部分称为特定于方案的部分（SSP），可以非常通用。（作为一个示例，请参见SNMP的URI方案[RFC4088]）。注意，特定于方案的语法和语义限制可能比RFC 3986的基本规则更具约束性。RFC 3986第3.1节提供了有关方案名称语法的指导。
URI schemes are a key concept in the DTN architecture, and evolved from an earlier concept called regions, which were tied more closely to assumptions of the network topology. Using URIs, significant flexibility is attained in the structuring of EIDs. They might, for example, be constructed based on DNS names, or might look like
URI方案是DTN体系结构中的一个关键概念，是从早期的称为区域的概念演变而来的，区域与网络拓扑的假设关系更为密切。使用URI，EID的结构具有很大的灵活性。例如，它们可能基于DNS名称构造，或者看起来像
"expressions of interest" or forms of database-like queries as in a directed diffusion-routed network [IGE00] or in intentional naming [WSBL99]. As names, EIDs are not required to be related to routing or topological organization. Such a relationship is not prohibited, however, and in some environments using EIDs this way may be advantageous.
定向扩散路由网络[IGE00]或有意命名[WSBL99]中的“兴趣表达”或类似数据库的查询形式。作为名称，EID不需要与路由或拓扑组织相关。然而，这种关系并不被禁止，在某些环境中，以这种方式使用EID可能是有利的。
A single EID may refer to an endpoint containing more than one DTN node, as suggested above. It is the responsibility of a scheme designer to define how to interpret the SSP of an EID so as to determine whether it refers to a unicast, multicast, or anycast set of nodes. See Section 3.4 for more details.
如上所述，单个EID可以指包含多个DTN节点的端点。方案设计者负责定义如何解释EID的SSP，以确定它是指单播、多播还是选播节点集。详见第3.4节。
URIs are constructed based on rules specified in RFC 3986, using the US-ASCII character set. However, note this excerpt from RFC 3986, Section 1.2.1, on dealing with characters that cannot be represented by US-ASCII: "Percent-encoded octets (Section 2.1) may be used within a URI to represent characters outside the range of the US-ASCII coded character set if this representation is allowed by the scheme or by the protocol element in which the URI is referenced. Such a definition should specify the character encoding used to map those characters to octets prior to being percent-encoded for the URI".
URI是基于RFC 3986中指定的规则构造的，使用US-ASCII字符集。但是，请注意RFC 3986第1.2.1节中关于处理US-ASCII无法表示的字符的摘录：“编码八位字节百分比（第2.1节）如果方案或引用URI的协议元素允许此表示，则可在URI内使用此表示来表示US-ASCII编码字符集范围之外的字符。此定义应指定用于在对URI进行百分比编码之前将这些字符映射到八位字节的字符编码。”.
Binding means interpreting the SSP of an EID for the purpose of carrying an associated message towards a destination. For example, binding might require mapping an EID to a next-hop EID or to a lower-layer address for transmission. "Late binding" means that the binding of a bundle's destination to a particular set of destination identifiers or addresses does not necessarily happen at the bundle source. Because the destination EID is potentially re-interpreted at each hop, the binding may occur at the source, during transit, or possibly at the destination(s). This contrasts with the name-to-address binding of Internet communications where a DNS lookup at the source fixes the IP address of the destination node before data is sent. Such a circumstance would be considered "early binding" because the name-to-address translation is performed prior to data being sent into the network.
绑定意味着解释EID的SSP，以便将相关消息传送到目的地。例如，绑定可能需要将EID映射到下一跳EID或低层地址以进行传输。“后期绑定”是指捆绑包的目的地绑定到一组特定的目的地标识符或地址不一定发生在捆绑包源上。由于目标EID可能在每个跃点处重新解释，因此绑定可能发生在源处、传输期间或可能发生在目标处。这与Internet通信的名称到地址绑定形成对比，在Internet通信中，在发送数据之前，源位置的DNS查找会修复目标节点的IP地址。这种情况将被视为“早期绑定”，因为名称到地址的转换是在数据发送到网络之前执行的。
In a frequently-disconnected network, late binding may be advantageous because the transit time of a message may exceed the validity time of a binding, making binding at the source impossible or invalid. Furthermore, use of name-based routing with late binding may reduce the amount of administrative (mapping) information that
在经常断开连接的网络中，延迟绑定可能是有利的，因为消息的传输时间可能超过绑定的有效时间，从而使源处的绑定不可能或无效。此外，使用具有后期绑定的基于名称的路由可能会减少需要的管理（映射）信息量
must propagate through the network, and may also limit the scope of mapping synchronization requirements to a local topological neighborhood where changes are made.
必须通过网络传播，并且还可能限制将同步要求映射到进行更改的本地拓扑邻域的范围。
As mentioned above, an EID may refer to an endpoint containing one or more DTN nodes. When referring to a group of size greater than one, the delivery semantics may be of either the anycast or multicast variety (broadcast is considered to be of the multicast variety). For anycast group delivery, a bundle is delivered to one node among a group of potentially many nodes, and for multicast delivery it is intended to be delivered to all of them, subject to the normal DTN class of service and maximum useful lifetime semantics.
如上所述，EID可以指包含一个或多个DTN节点的端点。当提及大小大于1的组时，传递语义可以是选播或多播种类（广播被认为是多播种类）。对于选播组交付，捆绑包被交付到潜在多个节点组成的组中的一个节点，而对于多播交付，捆绑包将被交付到所有节点，这取决于正常的DTN服务类别和最大可用寿命语义。
Multicast group delivery in a DTN presents an unfamiliar issue with respect to group membership. In relatively low-delay networks, such as the Internet, nodes may be considered to be part of the group if they have expressed interest to join it "recently". In a DTN, however, nodes may wish to receive data sent to a group during an interval of time earlier than when they are actually able to receive it [ZAZ05]. More precisely, an application expresses its desire to receive data sent to EID e at time t. Prior to this, during the interval [t0, t1], t > t1, data may have been generated for group e. For the application to receive any of this data, the data must be available a potentially long time after senders have ceased sending to the group. Thus, the data may need to be stored within the network in order to support temporal group semantics of this kind. How to design and implement this remains a research issue, as it is likely to be at least as hard as problems related to reliable multicast.
DTN中的多播组交付在组成员资格方面存在一个不熟悉的问题。在相对低延迟的网络中，如互联网，如果节点“最近”表示有兴趣加入，则可将其视为该组的一部分。然而，在DTN中，节点可能希望在其实际能够接收数据之前的时间间隔内接收发送给组的数据[ZAZ05]。更准确地说，应用程序表示希望在时间t接收发送给EID e的数据。在此之前，在间隔[t0，t1]，t>t1期间，可能已经为组e生成了数据。对于要接收任何此类数据的应用程序，这些数据必须在发送方停止向组发送数据后很长一段时间内可用。因此，数据可能需要存储在网络中，以便支持此类时间组语义。如何设计和实现这一点仍然是一个研究问题，因为它可能至少与可靠多播相关的问题一样困难。
The DTN architecture offers *relative* measures of priority (low, medium, high) for delivering ADUs. These priorities differentiate traffic based upon an application's desire to affect the delivery urgency for ADUs, and are carried in bundle blocks generated by the bundle layer based on information specified by the application.
DTN架构为交付ADU提供了*相对*优先级度量（低、中、高）。这些优先级根据应用程序想要影响ADU的交付紧急程度来区分流量，并根据应用程序指定的信息在捆绑层生成的捆绑块中进行传输。
The (U.S. or similar) Postal Service provides a strong metaphor for the priority classes offered by the forwarding abstraction offered by the DTN architecture. Traffic is generally not interactive and is often one-way. There are generally no strong guarantees of timely delivery, yet there are some forms of class of service, reliability, and security.
（美国或类似）邮政服务为DTN体系结构提供的转发抽象所提供的优先级类提供了强有力的隐喻。交通通常不是交互式的，通常是单向的。通常情况下，没有强有力的及时交付保证，但存在某种形式的服务级别、可靠性和安全性。
We have defined three relative priority classes to date. These priority classes typically imply some relative scheduling prioritization among bundles in queue at a sender:
到目前为止，我们已经定义了三个相对优先级类。这些优先级类通常意味着发送方队列中捆绑包之间的一些相对调度优先级：
- Bulk - Bulk bundles are shipped on a "least effort" basis. No bundles of this class will be shipped until all bundles of other classes bound for the same destination and originating from the same source have been shipped.
- 散装-散装捆绑包以“最省力”的方式装运。在绑定到同一目标并源自同一源的其他类的所有捆绑包都已发货之前，不会发货此类的捆绑包。
- Normal - Normal-class bundles are shipped prior to any bulk-class bundles and are otherwise the same as bulk bundles.
- 正常-正常类捆绑包在任何批量类捆绑包之前发货，在其他方面与批量捆绑包相同。
- Expedited - Expedited bundles, in general, are shipped prior to bundles of other classes and are otherwise the same.
- 加急-一般来说，加急捆绑包在其他类别的捆绑包之前发货，并且在其他方面是相同的。
Applications specify their requested priority class and data lifetime (see below) for each ADU they send. This information, coupled with policy applied at DTN nodes that select how messages are forwarded and which routing algorithms are in use, affects the overall likelihood and timeliness of ADU delivery.
应用程序为其发送的每个ADU指定其请求的优先级类别和数据生存期（见下文）。这些信息，再加上DTN节点上应用的策略（选择如何转发消息以及使用哪些路由算法），会影响ADU交付的总体可能性和及时性。
The priority class of a bundle is only required to relate to other bundles from the same source. This means that a high priority bundle from one source may not be delivered faster (or with some other superior quality of service) than a medium priority bundle from a different source. It does mean that a high priority bundle from one source will be handled preferentially to a lower priority bundle sent from the same source.
捆绑包的优先级类仅需要与来自同一源的其他捆绑包相关。这意味着，来自一个来源的高优先级捆绑包的交付速度（或使用其他优质服务）可能不会比来自不同来源的中等优先级捆绑包更快。这确实意味着来自一个源的高优先级捆绑包将优先处理来自同一源的低优先级捆绑包。
Depending on a particular DTN node's forwarding/scheduling policy, priority may or may not be enforced across different sources. That is, in some DTN nodes, expedited bundles might always be sent prior to any bulk bundles, irrespective of source. Many variations are possible.
根据特定DTN节点的转发/调度策略，可以在不同的源之间强制优先级，也可以不强制优先级。也就是说，在某些DTN节点中，无论源是什么，快速捆绑包可能总是在任何批量捆绑包之前发送。有许多变化是可能的。
Continuing with the postal analogy, the DTN architecture supports several delivery options that may be selected by an application when it requests the transmission of an ADU. In addition, the architecture defines two types of administrative records: "status reports" and "signals". These records are bundles that provide information about the delivery of other bundles, and are used in conjunction with the delivery options.
继续进行邮政类比，DTN体系结构支持多个交付选项，当应用程序请求传输ADU时，可以选择这些选项。此外，该体系结构定义了两种类型的管理记录：“状态报告”和“信号”。这些记录是提供其他捆绑包交付信息的捆绑包，与交付选项一起使用。
We have defined eight delivery options. Applications sending an ADU (the "subject ADU") may request any combination of the following, which are carried in each of the bundles produced ("sent bundles") by the bundle layer resulting from the application's request to send the subject ADU:
我们定义了八种交付选项。发送ADU的应用程序（“主体ADU”）可以请求以下任意组合，这些组合由捆绑层根据应用程序发送主体ADU的请求生成的每个捆绑包（“已发送捆绑包”）中携带：
- Custody Transfer Requested - requests sent bundles be delivered with enhanced reliability using custody transfer procedures. Sent bundles will be transmitted by the bundle layer using reliable transfer protocols (if available), and the responsibility for reliable delivery of the bundle to its destination(s) may move among one or more "custodians" in the network. This capability is described in more detail in Section 3.10.
- 请求托管转移-使用托管转移程序以更高的可靠性交付发送的请求。发送的捆绑包将由捆绑包层使用可靠传输协议（如果可用）进行传输，并且捆绑包到其目的地的可靠交付责任可能会在网络中的一个或多个“保管人”之间转移。第3.10节对该能力进行了更详细的描述。
- Source Node Custody Acceptance Required - requires the source DTN node to provide custody transfer for the sent bundles. If custody transfer is not available at the source when this delivery option is requested, the requested transmission fails. This provides a means for applications to insist that the source DTN node take custody of the sent bundles (e.g., by storing them in persistent storage).
- 需要源节点托管接受-要求源DTN节点为发送的捆绑包提供托管传输。如果在请求此传递选项时，源上的托管传输不可用，则请求的传输失败。这为应用程序提供了一种坚持源DTN节点保管已发送捆绑包的方法（例如，通过将其存储在持久存储中）。
- Report When Bundle Delivered - requests a (single) Bundle Delivery Status Report be generated when the subject ADU is delivered to its intended recipient(s). This request is also known as "return-receipt".
- 捆绑交付时报告-请求在主体ADU交付给其预期收件人时生成（单个）捆绑交付状态报告。此请求也称为“退货收据”。
- Report When Bundle Acknowledged by Application - requests an Acknowledgement Status Report be generated when the subject ADU is acknowledged by a receiving application. This only happens by action of the receiving application, and differs from the Bundle Delivery Status Report. It is intended for cases where the application may be acting as a form of application layer gateway and wishes to indicate the status of a protocol operation external to DTN back to the requesting source. See Section 11 for more details.
- 应用程序确认捆绑包时报告-请求在接收应用程序确认主体ADU时生成确认状态报告。这仅通过接收应用程序的操作发生，与捆绑交付状态报告不同。它适用于应用程序可能作为应用层网关的一种形式，并希望将DTN外部的协议操作状态指示回请求源的情况。详见第11节。
- Report When Bundle Received - requests a Bundle Reception Status Report be generated when each sent bundle arrives at a DTN node. This is designed primarily for diagnostic purposes.
- 收到捆绑包时报告-请求在每个发送的捆绑包到达DTN节点时生成捆绑包接收状态报告。这主要用于诊断目的。
- Report When Bundle Custody Accepted - requests a Custody Acceptance Status Report be generated when each sent bundle has been accepted using custody transfer. This is designed primarily for diagnostic purposes.
- 接受捆绑托管时报告-请求在使用托管转移接受每个发送的捆绑时生成托管接受状态报告。这主要用于诊断目的。
- Report When Bundle Forwarded - requests a Bundle Forwarding Status Report be generated when each sent bundle departs a DTN node after forwarding. This is designed primarily for diagnostic purposes.
- 转发捆绑包时报告-请求在每个发送的捆绑包在转发后离开DTN节点时生成捆绑包转发状态报告。这主要用于诊断目的。
- Report When Bundle Deleted - requests a Bundle Deletion Status Report be generated when each sent bundle is deleted at a DTN node. This is designed primarily for diagnostic purposes.
- 捆绑包删除时报告-请求在DTN节点上删除每个发送的捆绑包时生成捆绑包删除状态报告。这主要用于诊断目的。
The first four delivery options are designed for ordinary use by applications. The last four are designed primarily for diagnostic purposes and their use may be restricted or limited in environments subject to congestion or attack.
前四个交付选项是为应用程序的普通使用而设计的。最后四种主要用于诊断目的，在受到拥塞或攻击的环境中，它们的使用可能会受到限制或限制。
If the security procedures defined in [DTNSEC] are also enabled, then three additional delivery options become available:
如果[DTNSEC]中定义的安全程序也已启用，则有三个附加的交付选项可用：
- Confidentiality Required - requires the subject ADU be made secret from parties other than the source and the members of the destination EID.
- 保密要求-要求主体ADU对来源和目的地EID成员以外的各方保密。
- Authentication Required - requires all non-mutable fields in the bundle blocks of the sent bundles (i.e., those which do not change as the bundle is forwarded) be made strongly verifiable (i.e., cryptographically strong). This protects several fields, including the source and destination EIDs and the bundle's data. See Section 3.7 and [BSPEC] for more details.
- 需要身份验证-要求已发送捆绑包的捆绑包块中的所有不可变字段（即，在转发捆绑包时不会更改的字段）都具有强可验证性（即，加密强）。这将保护多个字段，包括源和目标EID以及捆绑包的数据。详见第3.7节和[BSPEC]。
- Error Detection Required - requires modifications to the non-mutable fields of each sent bundle be made detectable with high probability at each destination.
- 需要错误检测-需要对每个发送包的不可变字段进行修改，以便在每个目的地以高概率进行检测。
3.6.2. Administrative Records: Bundle Status Reports and Custody Signals
3.6.2. 管理记录：捆绑状态报告和保管信号
Administrative records are used to report status information or error conditions related to the bundle layer. There are two types of administrative records defined: bundle status reports (BSRs) and custody signals. Administrative records correspond (approximately) to messages in the ICMP protocol in IP [RFC792]. In ICMP, however, messages are returned to the source. In DTN, they are instead directed to the report-to EID for BSRs and the EID of the current custodian for custody signals, which might differ from the source's EID. Administrative records are sent as bundles with a source EID set to one of the EIDs associated with the DTN node generating the administrative record. In some cases, arrival of a single bundle or bundle fragment may elicit multiple administrative records (e.g., in the case where a bundle is replicated for multicast forwarding).
管理记录用于报告与捆绑层相关的状态信息或错误情况。定义了两种类型的管理记录：捆绑状态报告（BSR）和托管信号。管理记录（大约）与IP[RFC792]中ICMP协议中的消息相对应。但是，在ICMP中，消息返回到源。在DTN中，它们被定向到BSR的EID报告和保管信号的当前保管人的EID，这可能不同于源的EID。管理记录作为捆绑包发送，源EID设置为与生成管理记录的DTN节点关联的一个EID。在某些情况下，单个bundle或bundle片段的到达可能会引发多个管理记录（例如，在为多播转发复制bundle的情况下）。
The following BSRs are currently defined (also see [BSPEC] for more details):
目前定义了以下BSR（有关更多详细信息，请参见[BSPEC]：
- Bundle Reception - sent when a bundle arrives at a DTN node. Generation of this message may be limited by local policy.
- 捆绑接收-当捆绑到达DTN节点时发送。此消息的生成可能受到本地策略的限制。
- Custody Acceptance - sent when a node has accepted custody of a bundle with the Custody Transfer Requested option set. Generation of this message may be limited by local policy.
- 当发送了一个包含托管集的传输接受选项时，请求托管-节点已接受托管集。此消息的生成可能受到本地策略的限制。
- Bundle Forwarded - sent when a bundle containing a Report When Bundle Forwarded option departs from a DTN node after having been forwarded. Generation of this message may be limited by local policy.
- Bundle Forwarded—当包含报告的Bundle Forwarded选项在转发后离开DTN节点时发送。此消息的生成可能受到本地策略的限制。
- Bundle Deletion - sent from a DTN node when a bundle containing a Report When Bundle Deleted option is discarded. This can happen for several reasons, such as expiration. Generation of this message may be limited by local policy but is required in cases where the deletion is performed by a bundle's current custodian.
- 捆绑删除-当包含报告的捆绑包被丢弃时，从DTN节点发送捆绑删除选项。发生这种情况有几个原因，例如过期。此消息的生成可能受到本地策略的限制，但在由捆绑包的当前保管人执行删除的情况下是必需的。
- Bundle Delivery - sent from a final recipient's (destination) node when a complete ADU comprising sent bundles containing Report When Bundle Delivered options is consumed by an application.
- Bundle Delivery-当一个完整的ADU包含包含报告的已发送Bundle时，从最终收件人（目的地）节点发送，当应用程序使用Bundle Delivered选项时。
- Acknowledged by application - sent from a final recipient's (destination) node when a complete ADU comprising sent bundles containing Application Acknowledgment options has been processed by an application. This generally involves specific action on the receiving application's part.
- 由应用程序确认-当包含包含应用程序确认选项的已发送捆绑包的完整ADU已由应用程序处理时，从最终收件人（目的地）节点发送。这通常涉及接收应用程序的特定操作。
In addition to the status reports, the custody signal is currently defined to indicate the status of a custody transfer. These are sent to the current-custodian EID contained in an arriving bundle:
除状态报告外，监护信号当前定义为指示监护转移的状态。这些文件将发送到包含在到达捆绑包中的当前保管人EID：
- Custody Signal - indicates that custody has been successfully transferred. This signal appears as a Boolean indicator, and may therefore indicate either a successful or a failed custody transfer attempt.
- 监护信号-表示监护已成功转移。此信号显示为布尔指示符，因此可能表示托管转移尝试成功或失败。
Administrative records must reference a received bundle. This is accomplished by a method for uniquely identifying bundles based on a transmission timestamp and sequence number discussed in Section 3.12.
管理记录必须引用已收到的捆绑包。这是通过一种基于第3.12节讨论的传输时间戳和序列号唯一标识捆绑包的方法实现的。
The bundles carried between and among DTN nodes obey a standard bundle protocol specified in [BSPEC]. Here we provide an overview of most of the fields carried with every bundle. The protocol is designed with a mandatory primary block, an optional payload block (which contains the ADU data itself), and a set of optional extension blocks. Blocks may be cascaded in a way similar to extension headers in IPv6. The following selected fields are all present in the primary block, and therefore are present for every bundle and fragment:
DTN节点之间以及DTN节点之间承载的捆绑包遵守[BSPEC]中指定的标准捆绑协议。在这里，我们提供了每个bundle附带的大多数字段的概述。该协议设计有一个强制主块、一个可选有效负载块（包含ADU数据本身）和一组可选扩展块。块可以以类似于IPv6中的扩展头的方式级联。以下选定字段都存在于主块中，因此每个束和片段都存在：
- Creation Timestamp - a concatenation of the bundle's creation time and a monotonically increasing sequence number such that the creation timestamp is guaranteed to be unique for each ADU originating from the same source. The creation timestamp is based on the time-of-day an application requested an ADU to be sent (not when the corresponding bundle(s) are sent into the network). DTN nodes are assumed to have a basic time synchronization capability (see Section 3.12).
- 创建时间戳-捆绑包的创建时间和单调递增的序列号的串联，以确保创建时间戳对于来自同一源的每个ADU都是唯一的。创建时间戳基于应用程序请求发送ADU的时间（而不是当相应的包被发送到网络中时）。假定DTN节点具有基本的时间同步能力（见第3.12节）。
- Lifespan - the time-of-day at which the message is no longer useful. If a bundle is stored in the network (including the source's DTN node) when its lifespan is reached, it may be discarded. The lifespan of a bundle is expressed as an offset relative to its creation time.
- 寿命-一天中信息不再有用的时间。如果捆绑包在达到其使用寿命时存储在网络（包括源的DTN节点）中，则可能会将其丢弃。捆绑包的寿命表示为相对于其创建时间的偏移量。
- Class of Service Flags - indicates the delivery options and priority class for the bundle. Priority classes may be one of bulk, normal, or expedited. See Section 3.6.1.
- 服务类别标志-指示捆绑包的交付选项和优先级类别。优先级类别可以是批量、普通或快速。见第3.6.1节。
- Source EID - EID of the source (the first sender).
- Source EID—源（第一个发送方）的EID。
- Destination EID - EID of the destination (the final intended recipient(s)).
- 目的地EID-目的地（最终预期收件人）的EID。
- Report-To Endpoint ID - an EID identifying where reports (return-receipt, route-tracing functions) should be sent. This may or may not identify the same endpoint as the Source EID.
- Report To Endpoint ID—标识报告（返回收据、路由跟踪功能）应发送位置的EID。这可能会也可能不会标识与源EID相同的端点。
- Custodian EID - EID of the current custodian of a bundle (if any).
- 保管人EID—捆绑包的当前保管人的EID（如果有）。
The payload block indicates information about the contained payload (e.g., its length) and the payload itself. In addition to the fields found in the primary and payload blocks, each bundle may have fields in additional blocks carried with each bundle. See [BSPEC] for additional details.
有效载荷块指示关于所包含的有效载荷（例如，其长度）和有效载荷本身的信息。除了在主块和有效负载块中找到的字段外，每个捆绑包还可以在每个捆绑包附带的附加块中包含字段。有关更多详细信息，请参见[BSPEC]。
The DTN architecture provides a framework for routing and forwarding at the bundle layer for unicast, anycast, and multicast messages. Because nodes in a DTN network might be interconnected using more than one type of underlying network technology, a DTN network is best described abstractly using a *multigraph* (a graph where vertices may be interconnected with more than one edge). Edges in this graph are, in general, time-varying with respect to their delay and capacity and directional because of the possibility of one-way connectivity. When an edge has zero capacity, it is considered to not be connected.
DTN体系结构为单播、选播和多播消息的捆绑层路由和转发提供了一个框架。由于DTN网络中的节点可以使用多种类型的底层网络技术互连，因此最好使用*多重图*（顶点可以与多条边互连的图）抽象地描述DTN网络。由于单向连接的可能性，此图中的边通常随延迟、容量和方向而变化。当一条边的容量为零时，它被视为未连接。
Because edges in a DTN graph may have significant delay, it is important to distinguish where time is measured when expressing an edge's capacity or delay. We adopt the convention of expressing capacity and delay as functions of time where time is measured at the point where data is inserted into a network edge. For example, consider an edge having capacity C(t) and delay D(t) at time t. If B bits are placed in this edge at time t, they completely arrive by time t + D(t) + (1/C(t))*B. We assume C(t) and D(t) do not change significantly during the interval [t, t+D(t)+(1/C(t))*B].
因为DTN图中的边可能具有显著的延迟，所以在表示边的容量或延迟时，区分时间的测量位置非常重要。我们采用将容量和延迟表示为时间函数的约定，其中时间是在数据插入网络边缘的点处测量的。例如，考虑在时间t上具有容量C（t）和延迟d（t）的边。如果B位在时间t被放置在该边缘，它们在时间t+D（t）+（1/C（t））*B时完全到达。我们假设C（t）和D（t）在间隔[t，t+D（t）+（1/C（t））*B]期间没有显著变化。
Because edges may vary between positive and zero capacity, it is possible to describe a period of time (interval) during which the capacity is strictly positive, and the delay and capacity can be considered to be constant [AF03]. This period of time is called a "contact". In addition, the product of the capacity and the interval is known as a contact's "volume". If contacts and their volumes are known ahead of time, intelligent routing and forwarding decisions can be made (optimally for small networks) [JFP04]. Optimally using a contact's volume, however, requires the ability to divide large ADUs and bundles into smaller routable units. This is provided by DTN fragmentation (see Section 3.9).
由于边缘可能在正容量和零容量之间变化，因此可以描述一段时间（间隔），在此期间，容量严格为正，并且延迟和容量可以被视为常数[AF03]。这段时间被称为“接触”。此外，容量和间隔的乘积称为触点的“体积”。如果提前知道联系人及其数量，则可以做出智能路由和转发决策（最适合小型网络）[JFP04]。然而，最佳使用触点容量需要能够将大型ADU和线束划分为更小的可路由单元。这由DTN碎片提供（见第3.9节）。
When delivery paths through a DTN graph are lossy or contact intervals and volumes are not known precisely ahead of time, routing computations become especially challenging. How to handle these situations is an active area of work in the (emerging) research area of delay tolerant networking.
当通过DTN图的传送路径有损或接触间隔，并且无法提前准确地知道体积时，路由计算变得特别具有挑战性。如何处理这些情况是容错网络（新兴）研究领域的一个活跃工作领域。
Contacts typically fall into one of several categories, based largely on the predictability of their performance characteristics and whether some action is required to bring them into existence. To date, the following major types of contacts have been defined:
联系人通常分为几个类别之一，主要取决于其绩效特征的可预测性以及是否需要采取某些行动才能使其存在。迄今为止，已定义了以下主要类型的联系人：
Persistent Contacts
持续接触
Persistent contacts are always available (i.e., no connection-initiation action is required to instantiate a persistent contact). An 'always-on' Internet connection such as a DSL or Cable Modem connection would be a representative of this class.
永久联系人始终可用（即，实例化永久联系人不需要连接启动操作）。“始终在线”的Internet连接（如DSL或电缆调制解调器连接）就是此类连接的代表。
On-Demand Contacts
随需应变联系人
On-Demand contacts require some action in order to instantiate, but then function as persistent contacts until terminated. A dial-up connection is an example of an On-Demand contact (at least, from the viewpoint of the dialer; it may be viewed as an Opportunistic Contact, below, from the viewpoint of the dial-up service provider).
按需联系人需要执行一些操作以进行实例化，但在终止之前，将作为永久联系人使用。拨号连接是按需联系的一个示例（至少从拨号程序的角度来看；从拨号服务提供商的角度来看，它可能被视为机会主义联系）。
Intermittent - Scheduled Contacts
间歇性定期接触
A scheduled contact is an agreement to establish a contact at a particular time, for a particular duration. An example of a scheduled contact is a link with a low-earth orbiting satellite. A node's list of contacts with the satellite can be constructed from the satellite's schedule of view times, capacities, and latencies. Note that for networks with substantial delays, the notion of the "particular time" is delay-dependent. For example, a single scheduled contact between Earth and Mars would not be at the same instant in each location, but would instead be offset by the (non-negligible) propagation delay.
预定联系人是在特定时间、特定期限内建立联系人的协议。预定接触的一个例子是与低地球轨道卫星的链路。节点与卫星的联系人列表可以根据卫星的查看时间、容量和延迟时间表构建。请注意，对于具有大量延迟的网络，“特定时间”的概念取决于延迟。例如，地球和火星之间的单一预定接触不会在每个位置处于同一时刻，而是会被（不可忽略的）传播延迟所抵消。
Intermittent - Opportunistic Contacts
间歇性机会主义接触
Opportunistic contacts are not scheduled, but rather present themselves unexpectedly. For example, an unscheduled aircraft flying overhead and beaconing, advertising its availability for communication, would present an opportunistic contact. Another type of opportunistic contact might be via an infrared or Bluetooth communication link between a personal digital assistant (PDA) and a kiosk in an airport concourse. The opportunistic contact begins as the PDA is brought near the kiosk, lasting an undetermined amount of time (i.e., until the link is lost or terminated).
机会主义接触不会被安排，而是意外地出现。例如，一架计划外的飞机在头顶和信标上飞行，宣传其通信可用性，这将是一种机会主义接触。另一种机会主义接触可能是通过个人数字助理（PDA）和机场大厅中的信息亭之间的红外或蓝牙通信链路。当PDA靠近信息亭时，机会主义接触开始，持续时间不确定（即，直到链路丢失或终止）。
Intermittent - Predicted Contacts
间歇预测触点
Predicted contacts are based on no fixed schedule, but rather are predictions of likely contact times and durations based on a history of previously observed contacts or some other information. Given a great enough confidence in a predicted contact, routes may
预测的接触没有固定的时间表，而是根据以前观察到的接触历史或其他一些信息预测可能的接触时间和持续时间。如果对预测的接触有足够的信心，路线可能会
be chosen based on this information. This is an active research area, and a few approaches having been proposed [LFC05].
将根据此信息进行选择。这是一个活跃的研究领域，已经提出了一些方法[LFC05]。
DTN fragmentation and reassembly are designed to improve the efficiency of bundle transfers by ensuring that contact volumes are fully utilized and by avoiding retransmission of partially-forwarded bundles. There are two forms of DTN fragmentation/reassembly:
DTN碎片化和重组旨在通过确保充分利用联系卷和避免部分转发包的重新传输来提高包传输的效率。DTN碎片化/重组有两种形式：
Proactive Fragmentation
主动碎片化
A DTN node may divide a block of application data into multiple smaller blocks and transmit each such block as an independent bundle. In this case, the *final destination(s)* are responsible for extracting the smaller blocks from incoming bundles and reassembling them into the original larger bundle and, ultimately, ADU. This approach is called proactive fragmentation because it is used primarily when contact volumes are known (or predicted) in advance.
DTN节点可以将应用数据块划分为多个较小的块，并将每个这样的块作为独立的包进行传输。在这种情况下，*最终目的地*负责从传入的捆绑包中提取较小的块，并将它们重新组装到原始较大的捆绑包中，最后再组装到ADU中。这种方法称为主动碎片化，因为它主要用于提前知道（或预测）联系人数量的情况。
Reactive Fragmentation
反应破碎
DTN nodes sharing an edge in the DTN graph may fragment a bundle cooperatively when a bundle is only partially transferred. In this case, the receiving bundle layer modifies the incoming bundle to indicate it is a fragment, and forwards it normally. The previous- hop sender may learn (via convergence-layer protocols, see Section 6) that only a portion of the bundle was delivered to the next hop, and send the remaining portion(s) when subsequent contacts become available (possibly to different next-hops if routing changes). This is called reactive fragmentation because the fragmentation process occurs after an attempted transmission has taken place.
在DTN图中共享一条边的DTN节点可以在束仅部分传输时协同地分割束。在这种情况下，接收包层修改传入包以指示它是一个片段，并正常转发它。前一跳发送方可能知道（通过汇聚层协议，参见第6节）只有一部分捆绑被传递到下一跳，并在后续联系人可用时发送剩余部分（如果路由发生变化，则可能发送到不同的下一跳）。这称为反应性分段，因为分段过程发生在尝试传输之后。
As an example, consider a ground station G, and two store-and-forward satellites S1 and S2, in opposite low-earth orbit. While G is transmitting a large bundle to S1, a reliable transport layer protocol below the bundle layer at each indicates the transmission has terminated, but that half the transfer has completed successfully. In this case, G can form a smaller bundle fragment consisting of the second half of the original bundle and forward it to S2 when available. In addition, S1 (now out of range of G) can form a new bundle consisting of the first half of the original bundle and forward it to whatever next hop(s) it deems appropriate.
作为一个例子，考虑地面站G和两个存储和转发卫星S1和S2，在相对低地球轨道。当G向S1传输大数据包时，每个数据包层下的可靠传输层协议表示传输已终止，但一半传输已成功完成。在这种情况下，G可以形成一个较小的束片段，由原始束的后半部分组成，并在可用时将其转发给S2。此外，S1（现在超出G的范围）可以形成一个新的包，由原始包的前半部分组成，并将其转发到它认为合适的下一跳。
The reactive fragmentation capability is not required to be available in every DTN implementation, as it requires a certain level of support from underlying protocols that may not be present, and presents significant challenges with respect to handling digital signatures and authentication codes on messages. When a signed message is only partially received, most message authentication codes will fail. When DTN security is present and enabled, it may therefore be necessary to proactively fragment large bundles into smaller units that are more convenient for digital signatures.
无需在每个DTN实现中都提供反应式分段功能，因为它需要来自可能不存在的底层协议的一定级别的支持，并且在处理消息上的数字签名和身份验证代码方面存在重大挑战。当仅部分接收到已签名的消息时，大多数消息身份验证码将失败。当存在并启用DTN安全性时，可能需要主动将大型捆绑包拆分为更便于数字签名的较小单元。
Even if reactive fragmentation is not present in an implementation, the ability to reassemble fragments at a destination is required in order to support DTN fragmentation. Furthermore, for contacts with volumes that are small compared to typical bundle sizes, some incremental delivery approach must be used (e.g., checkpoint/restart) to prevent data delivery livelock. Reactive fragmentation is one such approach, but other protocol layers could potentially handle this issue as well.
即使实现中不存在反应性碎片，也需要在目的地重新组装碎片的能力，以支持DTN碎片。此外，对于具有与典型捆绑包大小相比较小的卷的联系人，必须使用一些增量传递方法（例如，检查点/重新启动）来防止数据传递活锁。反应性分段就是这样一种方法，但其他协议层也可能处理这个问题。
The most basic service provided by the bundle layer is unacknowledged, prioritized (but not guaranteed) unicast message delivery. It also provides two options for enhancing delivery reliability: end-to-end acknowledgments and custody transfer. Applications wishing to implement their own end-to-end message reliability mechanisms are free to utilize the acknowledgment. The custody transfer feature of the DTN architecture only specifies a coarse-grained retransmission capability, described next.
bundle层提供的最基本的服务是未确认、优先（但不保证）的单播消息传递。它还提供了两种增强交付可靠性的选项：端到端确认和托管转移。希望实现自己的端到端消息可靠性机制的应用程序可以自由地使用确认。DTN体系结构的托管传输特性仅指定粗粒度重传能力，如下所述。
Transmission of bundles with the Custody Transfer Requested option specified generally involves moving the responsibility for reliable delivery of an ADU's bundles among different DTN nodes in the network. For unicast delivery, this will typically involve moving bundles "closer" (in terms of some routing metric) to their ultimate destination(s), and retransmitting when necessary. The nodes receiving these bundles along the way (and agreeing to accept the reliable delivery responsibility) are called "custodians". The movement of a bundle (and its delivery responsibility) from one node to another is called a "custody transfer". It is analogous to a database commit transaction [FHM03]. The exact meaning and design of custody transfer for multicast and anycast delivery remains to be fully explored.
使用指定的托管转移请求选项传输捆绑包通常涉及在网络中的不同DTN节点之间转移可靠交付ADU捆绑包的责任。对于单播交付，这通常涉及将捆绑包“移近”（根据某些路由度量）到其最终目的地，并在必要时重新传输。沿途接收这些捆绑包（并同意接受可靠的交付责任）的节点称为“保管人”。捆绑包（及其交付责任）从一个节点移动到另一个节点称为“托管转移”。它类似于数据库提交事务[FHM03]。多播和选播传输的监护权转移的确切含义和设计仍有待充分探索。
Custody transfer allows the source to delegate retransmission responsibility and recover its retransmission-related resources relatively soon after sending a bundle (on the order of the minimum round-trip time to the first bundle hop(s)). Not all nodes in a DTN
托管传输允许源在发送捆绑包后（按照到第一个捆绑包跃点的最小往返时间的顺序）相对较快地委派重传责任并恢复其重传相关资源。不是DTN中的所有节点
are required by the DTN architecture to accept custody transfers, so it is not a true 'hop-by-hop' mechanism. For example, some nodes may have sufficient storage resources to sometimes act as custodians, but may elect to not offer such services when congested or running low on power.
DTN体系结构要求接受托管传输，因此它不是真正的“逐跳”机制。例如，某些节点可能有足够的存储资源，有时可以充当保管人，但在拥塞或功率不足时可能选择不提供此类服务。
The existence of custodians can alter the way DTN routing is performed. In some circumstances, it may be beneficial to move a bundle to a custodian as quickly as possible even if the custodian is further away (in terms of distance, time or some routing metric) from the bundle's final destination(s) than some other reachable node. Designing a system with this capability involves constructing more than one routing graph, and is an area of continued research.
保管人的存在可能会改变DTN路由的执行方式。在某些情况下，尽可能快地将捆绑移动到保管人可能是有益的，即使保管人距离捆绑的最终目的地（在距离、时间或某些路由度量方面）比其他可到达节点更远。设计一个具有这种能力的系统需要构造多个路由图，这是一个持续研究的领域。
Custody transfer in DTN not only provides a method for tracking bundles that require special handling and identifying DTN nodes that participate in custody transfer, it also provides a (weak) mechanism for enhancing the reliability of message delivery. Generally speaking, custody transfer relies on underlying reliable delivery protocols of the networks that it operates over to provide the primary means of reliable transfer from one bundle node to the next (set). However, when custody transfer is requested, the bundle layer provides an additional coarse-grained timeout and retransmission mechanism and an accompanying (bundle-layer) custodian-to-custodian acknowledgment signaling mechanism. When an application does *not* request custody transfer, this bundle layer timeout and retransmission mechanism is typically not employed, and successful bundle layer delivery depends solely on the reliability mechanisms of the underlying protocols.
DTN中的托管传输不仅提供了一种跟踪需要特殊处理的捆绑包并识别参与托管传输的DTN节点的方法，还提供了一种（弱）机制来增强消息传递的可靠性。一般来说，托管传输依赖于网络的底层可靠传输协议，它通过这些协议运行，以提供从一个捆绑节点到下一个捆绑节点（set）的可靠传输的主要手段。然而，当请求托管传输时，捆绑层提供额外的粗粒度超时和重传机制以及伴随的（捆绑层）托管到托管确认信令机制。当应用程序*不*请求托管传输时，通常不采用此捆绑层超时和重传机制，并且成功的捆绑层交付仅取决于底层协议的可靠性机制。
When a node accepts custody for a bundle that contains the Custody Transfer Requested option, a Custody Transfer Accepted Signal is sent by the bundle layer to the Current Custodian EID contained in the primary bundle block. In addition, the Current Custodian EID is updated to contain one of the forwarding node's (unicast) EIDs before the bundle is forwarded.
当节点接受包含托管传输请求选项的捆绑的托管时，捆绑层将向主捆绑块中包含的当前托管EID发送托管传输接受信号。此外，在转发捆绑包之前，当前托管EID将更新为包含转发节点的一个（单播）EID。
When an application requests an ADU to be delivered with custody transfer, the request is advisory. In some circumstances, a source of a bundle for which custody transfer has been requested may not be able to provide this service. In such circumstances, the subject bundle may traverse multiple DTN nodes before it obtains a custodian. Bundles in this condition are specially marked with their Current Custodian EID field set to a null endpoint. In cases where applications wish to require the source to take custody of the bundle, they may supply the Source Node Custody Acceptance Required
当申请要求ADU随监护权转移一起交付时，该请求是建议性的。在某些情况下，请求进行托管转移的捆绑包的源可能无法提供此服务。在这种情况下，主题包可能在获得托管之前遍历多个DTN节点。在这种情况下，bundle被特别标记，其当前字段设置为空端点。如果应用程序希望要求源节点保管捆绑包，则可以提供所需的源节点保管验收
delivery option. This may be useful to applications that desire a continuous "chain" of custody or that wish to exit after being ensured their data is safely held in a custodian.
交付选项。这对于希望拥有连续“保管链”的应用程序或希望在确保其数据安全保存在保管人中后退出的应用程序可能很有用。
In a DTN network where one or more custodian-to-custodian hops are strictly one directional (and cannot be reversed), the DTN custody transfer mechanism will be affected over such hops due to the lack of any way to receive a custody signal (or any other information) back across the path, resulting in the expiration of the bundle at the ingress to the one-way hop. This situation does not necessarily mean the bundle has been lost; nodes on the other side of the hop may continue to transfer custody, and the bundle may be delivered successfully to its destination(s). However, in this circumstance a source that has requested to receive expiration BSRs for this bundle will receive an expiration report for the bundle, and possibly conclude (incorrectly) that the bundle has been discarded and not delivered. Although this problem cannot be fully solved in this situation, a mechanism is provided to help ameliorate the seemingly incorrect information that may be reported when the bundle expires after having been transferred over a one-way hop. This is accomplished by the node at the ingress to the one-way hop reporting the existence of a known one-way path using a variant of a bundle status report. These types of reports are provided if the subject bundle requests the report using the 'Report When Bundle Forwarded' delivery option.
在DTN网络中，一个或多个保管人到保管人的跃点严格是单向的（且不能反转），DTN保管传输机制将在此类跃点上受到影响，因为无法通过任何方式接收路径上的保管信号（或任何其他信息），导致包在进入单向跃点时过期。这种情况并不一定意味着捆绑已经丢失；跃点另一侧的节点可以继续转移监护权，并且包可以成功地传递到其目的地。但是，在这种情况下，请求接收此捆绑包的到期BSR的源将收到该捆绑包的到期报告，并可能（错误地）得出该捆绑包已被丢弃且未交付的结论。虽然在这种情况下无法完全解决此问题，但提供了一种机制，以帮助改善在通过单向跳传输包到期后可能报告的看似不正确的信息。这是由单向跃点入口处的节点使用包状态报告的变体报告已知单向路径的存在来完成的。如果主题捆绑包使用“捆绑包转发时报告”交付选项请求报告，则会提供这些类型的报告。
One of the aims of DTN is to provide a common method for interconnecting application layer gateways and proxies. In cases where existing Internet applications can be made to tolerate delays, local proxies can be constructed to benefit from the existing communication capabilities provided by DTN [S05, T02]. Making such proxies compatible with DTN reduces the burden on the proxy author from being concerned with how to implement routing and reliability management and allows existing TCP/IP-based applications to operate unmodified over a DTN-based network.
DTN的目标之一是提供一种互连应用层网关和代理的通用方法。在现有互联网应用程序可以容忍延迟的情况下，可以构建本地代理以从DTN提供的现有通信能力中获益[S05，T02]。使此类代理与DTN兼容可以减轻代理作者的负担，使其不必担心如何实现路由和可靠性管理，并允许现有基于TCP/IP的应用程序在基于DTN的网络上不经修改地运行。
When DTN is used to provide a form of tunnel encapsulation for other protocols, it can be used in constructing overlay networks comprised of application layer gateways. The application acknowledgment capability is designed for such circumstances. This provides a common way for remote application layer gateways to signal the success or failure of non-DTN protocol operations initiated as a result of receiving DTN ADUs. Without this capability, such indicators would have to be implemented by applications themselves in non-standard ways.
当DTN用于为其他协议提供一种隧道封装形式时，它可以用于构建由应用层网关组成的覆盖网络。应用程序确认功能是针对这种情况设计的。这为远程应用层网关提供了一种通用的方式，以指示由于接收DTN ADU而启动的非DTN协议操作的成功或失败。如果没有这种能力，这些指标将不得不由应用程序自己以非标准方式实现。
The DTN architecture depends on time synchronization among DTN nodes (supported by external, non-DTN protocols) for four primary purposes: bundle and fragment identification, routing with scheduled or predicted contacts, bundle expiration time computations, and application registration expiration.
DTN体系结构依赖于DTN节点之间的时间同步（由外部非DTN协议支持），主要用于四个目的：捆绑包和片段识别、使用预定或预测的联系人进行路由、捆绑包过期时间计算和应用程序注册过期。
Bundle identification and expiration are supported by placing a creation timestamp and an explicit expiration field (expressed in seconds after the source timestamp) in each bundle. The origination timestamps on arriving bundles are made available to consuming applications in ADUs they receive by some system interface function. Each set of bundles corresponding to an ADU is required to contain a timestamp unique to the sender's EID. The EID, timestamp, and data offset/length information together uniquely identify a bundle. Unique bundle identification is used for a number of purposes, including custody transfer and reassembly of bundle fragments.
通过在每个捆绑包中放置创建时间戳和显式过期字段（以源时间戳后的秒数表示），支持捆绑包标识和过期。到达包上的起始时间戳可用于ADU中的消费应用程序，这些应用程序通过某些系统接口功能接收。与ADU对应的每一组bundle都需要包含发送方EID唯一的时间戳。EID、时间戳和数据偏移量/长度信息一起唯一地标识捆绑包。唯一的捆标识用于多种目的，包括捆碎片的保管转移和重新组装。
Time is also used in conjunction with application registrations. When an application expresses its desire to receive ADUs destined for a particular EID, this registration is only maintained for a finite period of time, and may be specified by the application. For multicast registrations, an application may also specify a time range or "interest interval" for its registration. In this case, traffic sent to the specified EID any time during the specified interval will eventually be delivered to the application (unless such traffic has expired due to the expiration time provided by the application at the source or some other reason prevents such delivery).
时间也与申请注册一起使用。当应用程序表示希望接收目的地为特定EID的ADU时，该注册仅在有限的时间内保持，并且可以由应用程序指定。对于多播注册，应用程序还可以为其注册指定时间范围或“兴趣间隔”。在这种情况下，在指定的时间间隔内的任何时间发送到指定EID的通信量最终将被发送到应用程序（除非由于应用程序在源位置提供的过期时间或某些其他原因导致该通信量过期）。
The subject of congestion control and flow control at the bundle layer is one on which the authors of this document have not yet reached complete consensus. We have unresolved concerns about the efficiency and efficacy of congestion and flow control schemes implemented across long and/or highly variable delay environments, especially with the custody transfer mechanism that may require nodes to retain bundles for long periods of time.
捆绑层的拥塞控制和流量控制是本文档作者尚未达成完全共识的主题。对于在长延迟和/或高度可变延迟环境中实施的拥塞和流量控制方案的效率和有效性，特别是对于可能需要节点长时间保留捆绑包的托管传输机制，我们尚未解决相关问题。
For the purposes of this document, we define "flow control" as a means of assuring that the average rate at which a sending node transmits data to a receiving node does not exceed the average rate at which the receiving node is prepared to receive data from that sender. (Note that this is a generalized notion of flow control, rather than one that applies only to end-to-end communication.) We define "congestion control" as a means of assuring that the aggregate rate at which all traffic sources inject data into a network does not
在本文档中，我们将“流量控制”定义为确保发送节点向接收节点发送数据的平均速率不超过接收节点准备从该发送方接收数据的平均速率的一种方法。（请注意，这是流量控制的广义概念，而不是仅适用于端到端通信的概念。）我们将“拥塞控制”定义为一种确保所有流量源向网络中注入数据的总速率不会降低的方法
exceed the maximum aggregate rate at which the network can deliver data to destination nodes over time. If flow control is propagated backward from congested nodes toward traffic sources, then the flow control mechanism can be used as at least a partial solution to the problem of congestion as well.
超过网络随时间向目标节点传送数据的最大聚合速率。如果流量控制从拥塞的节点向后传播到流量源，那么流量控制机制至少可以作为拥塞问题的部分解决方案。
DTN flow control decisions must be made within the bundle layer itself based on information about resources (in this case, primarily persistent storage) available within the bundle node. When storage resources become scarce, a DTN node has only a certain degree of freedom in handling the situation. It can always discard bundles which have expired -- an activity DTN nodes should perform regularly in any case. If it ordinarily is willing to accept custody for bundles, it can cease doing so. If storage resources are available elsewhere in the network, it may be able to make use of them in some way for bundle storage. It can also discard bundles which have not expired but for which it has not accepted custody. A node must avoid discarding bundles for which it has accepted custody, and do so only as a last resort. Determining when a node should engage in or cease to engage in custody transfers is a resource allocation and scheduling problem of current research interest.
DTN流控制决策必须在bundle层内根据bundle节点内可用资源（在本例中，主要是持久存储）的信息做出。当存储资源变得稀缺时，DTN节点在处理这种情况时只有一定程度的自由。它总是可以丢弃过期的捆绑包——DTN节点在任何情况下都应该定期执行一项活动。如果它通常愿意接受捆绑的托管，它可以停止这样做。如果存储资源在网络中的其他地方可用，它可能能够以某种方式将其用于捆绑存储。它还可以丢弃尚未过期但尚未接受保管的捆绑包。节点必须避免丢弃其已接受托管的捆绑包，并且仅作为最后手段。确定节点何时应该参与或停止参与托管转移是当前研究兴趣的一个资源分配和调度问题。
In addition to the bundle layer mechanisms described above, a DTN node may be able to avail itself of support from lower-layer protocols in affecting its own resource utilization. For example, a DTN node receiving a bundle using TCP/IP might intentionally slow down its receiving rate by performing read operations less frequently in order to reduce its offered load. This is possible because TCP provides its own flow control, so reducing the application data consumption rate could effectively implement a form of hop-by-hop flow control. Unfortunately, it may also lead to head-of-line blocking issues, depending on the nature of bundle multiplexing within a TCP connection. A protocol with more relaxed ordering constraints (e.g. SCTP [RFC2960]) might be preferable in such circumstances.
除了上述捆绑层机制之外，DTN节点还可以利用来自较低层协议的支持来影响其自身的资源利用率。例如，使用TCP/IP接收捆绑包的DTN节点可能会故意降低其接收速率，方法是降低读取操作的频率，以减少其提供的负载。这是可能的，因为TCP提供自己的流控制，因此降低应用程序数据消耗率可以有效地实现一种逐跳流控制。不幸的是，它还可能导致线路阻塞问题，这取决于TCP连接中的捆绑多路复用的性质。在这种情况下，具有更宽松的排序约束（例如SCTP[RFC2960]）的协议可能更可取。
Congestion control is an ongoing research topic.
拥塞控制是一个正在进行的研究课题。
The possibility of severe resource scarcity in some delay-tolerant networks dictates that some form of authentication and access control to the network itself is required in many circumstances. It is not acceptable for an unauthorized user to flood the network with traffic easily, possibly denying service to authorized users. In many cases it is also not acceptable for unauthorized traffic to be forwarded over certain network links at all. This is especially true for exotic, mission-critical links. In light of these considerations,
在一些延迟容忍网络中，资源严重短缺的可能性决定了在许多情况下需要对网络本身进行某种形式的身份验证和访问控制。未经授权的用户不可轻易地向网络注入流量，可能会拒绝向授权用户提供服务。在许多情况下，通过某些网络链路转发未经授权的流量也是不可接受的。对于异国情调的、关键任务的链接尤其如此。基于这些考虑,，
several goals are established for the security component of the DTN architecture:
为DTN体系结构的安全组件制定了几个目标：
- Promptly prevent unauthorized applications from having their data carried through or stored in the DTN.
- 及时防止未经授权的应用程序将其数据传输或存储在DTN中。
- Prevent unauthorized applications from asserting control over the DTN infrastructure.
- 防止未经授权的应用程序断言对DTN基础结构的控制。
- Prevent otherwise authorized applications from sending bundles at a rate or class of service for which they lack permission.
- 防止其他授权的应用程序以其缺乏权限的速率或服务级别发送捆绑包。
- Promptly discard bundles that are damaged or improperly modified in transit.
- 及时丢弃在运输过程中损坏或修改不当的捆包。
- Promptly detect and de-authorize compromised entities.
- 及时检测并取消对受损实体的授权。
Many existing authentication and access control protocols designed for operation in low-delay, connected environments may not perform well in DTNs. In particular, updating access control lists and revoking ("blacklisting") credentials may be especially difficult. Also, approaches that require frequent access to centralized servers to complete an authentication or authorization transaction are not attractive. The consequences of these difficulties include delays in the onset of communication, delays in detecting and recovering from system compromise, and delays in completing transactions due to inappropriate access control or authentication settings.
许多为在低延迟、连接的环境中运行而设计的现有身份验证和访问控制协议可能在DTN中性能不佳。特别是，更新访问控制列表和撤销（“黑名单”）凭证可能特别困难。此外，需要频繁访问集中式服务器以完成身份验证或授权事务的方法也没有吸引力。这些困难的后果包括通信开始延迟、检测系统泄露并从中恢复的延迟，以及由于访问控制或身份验证设置不当而导致的事务完成延迟。
To help satisfy these security requirements in light of the challenges, the DTN architecture adopts a standard but optionally deployed security architecture [DTNSEC] that utilizes hop-by-hop and end-to-end authentication and integrity mechanisms. The purpose of using both approaches is to be able to handle access control for data forwarding and storage separately from application-layer data integrity. While the end-to-end mechanism provides authentication for a principal such as a user (of which there may be many), the hop-by-hop mechanism is intended to authenticate DTN nodes as legitimate transceivers of bundles to each-other. Note that it is conceivable to construct a DTN in which only a subset of the nodes participate in the security mechanisms, resulting in a secure DTN overlay existing atop an insecure DTN overlay. This idea is relatively new and is still being explored.
为了根据这些挑战帮助满足这些安全需求，DTN体系结构采用了一种标准但可选部署的安全体系结构[DTNSEC]，该体系结构利用逐跳和端到端身份验证和完整性机制。使用这两种方法的目的是能够独立于应用层数据完整性处理数据转发和存储的访问控制。虽然端到端机制为诸如用户（其中可能有许多用户）之类的主体提供认证，但逐跳机制旨在将DTN节点作为捆绑包的合法收发器相互认证。注意，可以设想构造一个DTN，其中只有一部分节点参与安全机制，从而在不安全的DTN覆盖上存在一个安全的DTN覆盖。这一想法相对较新，仍在探索中。
In accordance with the goals listed above, DTN nodes discard traffic as early as possible if authentication or access control checks fail. This approach meets the goals of removing unwanted traffic from being forwarded over specific high-value links, but also has the associated benefit of making denial-of-service attacks considerably harder to
根据上面列出的目标，如果身份验证或访问控制检查失败，DTN节点将尽早丢弃流量。这种方法实现了消除通过特定高价值链路转发的不需要的通信量的目标，但也具有使拒绝服务攻击更难被攻击的相关好处
mount more generally, as compared with conventional Internet routers. However, the obvious cost for this capability is potentially larger computation and credential storage overhead required at DTN nodes.
与传统互联网路由器相比，挂载更为普遍。然而，此功能的明显成本是DTN节点可能需要更大的计算和凭证存储开销。
For more detailed information on DTN security provisions, refer to [DTNSEC] and [DTNSOV].
有关DTN安全规定的更多详细信息，请参阅[DTNSEC]和[DTNSOV]。
An important aspect of any networking architecture is its management of state. This section describes the state managed at the bundle layer and discusses how it is established and removed.
任何网络体系结构的一个重要方面是其状态管理。本节描述在bundle层管理的状态，并讨论如何建立和删除该状态。
In long/variable delay environments, an asynchronous application interface seems most appropriate. Such interfaces typically include methods for applications to register callback actions when certain triggering events occur (e.g., when ADUs arrive). These registrations create state information called application registration state.
在长/可变延迟环境中，异步应用程序接口似乎最合适。此类接口通常包括应用程序在某些触发事件发生时（例如，ADU到达时）注册回调操作的方法。这些注册创建称为应用程序注册状态的状态信息。
Application registration state is typically created by explicit request of the application, and is removed by a separate explicit request, but may also be removed by an application-specified timer (it is thus "firm" state). In most cases, there must be a provision for retaining this state across application and operating system termination/restart conditions because a client/server bundle round-trip time may exceed the requesting application's execution time (or hosting system's uptime). In cases where applications are not automatically restarted but application registration state remains persistent, a method must be provided to indicate to the system what action to perform when the triggering event occurs (e.g., restarting some application, ignoring the event, etc.).
应用程序注册状态通常由应用程序的显式请求创建，并由单独的显式请求删除，但也可以由应用程序指定的计时器删除（因此为“固定”状态）。在大多数情况下，必须在应用程序和操作系统终止/重新启动条件下保留此状态，因为客户端/服务器包的往返时间可能超过请求应用程序的执行时间（或主机系统的正常运行时间）。如果应用程序未自动重新启动，但应用程序注册状态保持持久，则必须提供一种方法，向系统指示在触发事件发生时要执行的操作（例如，重新启动某些应用程序，忽略事件等）。
To initiate a registration and thereby establish application registration state, an application specifies an Endpoint ID for which it wishes to receive ADUs, along with an optional time value indicating how long the registration should remain active. This operation is somewhat analogous to the bind() operation in the common sockets API.
为了启动注册并由此建立应用程序注册状态，应用程序指定其希望接收ADU的端点ID，以及指示注册应保持活动的时间的可选时间值。此操作在某种程度上类似于公共套接字API中的bind（）操作。
For registrations to groups (i.e., joins), a time interval may also be specified. The time interval refers to the range of origination times of ADUs sent to the specified EID. See Section 3.4 above for more details.
对于组注册（即加入），还可以指定时间间隔。时间间隔是指发送到指定EID的ADU的起始时间范围。更多详情见上文第3.4节。
Custody transfer state includes information required to keep account of bundles for which a node has taken custody, as well as the protocol state related to transferring custody for one or more of them. The accounting-related state is created when a bundle is received. Custody transfer retransmission state is created when a transfer of custody is initiated by forwarding a bundle with the custody transfer requested delivery option specified. Retransmission state and accounting state may be released upon receipt of one or more Custody Transfer Succeeded signals, indicating custody has been moved. In addition, the bundle's expiration time (possibly mitigated by local policy) provides an upper bound on the time when this state is purged from the system in the event that it is not purged explicitly due to receipt of a signal.
托管传输状态包括记录节点已对其进行托管的捆绑包所需的信息，以及与其中一个或多个捆绑包的托管传输相关的协议状态。会计相关状态在收到捆绑时创建。当通过使用指定的保管转移请求传递选项转发捆绑包来启动保管转移时，将创建保管转移重传状态。在接收到一个或多个托管转移成功信号时，可以释放重传状态和记帐状态，指示托管已被移动。此外，如果由于收到信号而未明确清除该状态，则捆绑包的过期时间（可能由本地策略缓解）提供了从系统中清除该状态的时间上限。
As with the Internet architecture, we distinguish between routing and forwarding. Routing refers to the execution of a (possibly distributed) algorithm for computing routing paths according to some objective function (see [JFP04], for example). Forwarding refers to the act of moving a bundle from one DTN node to another. Routing makes use of routing state (the RIB, or routing information base), while forwarding makes use of state derived from routing, and is maintained as forwarding state (the FIB, or forwarding information base). The structure of the FIB and the rules for maintaining it are implementation choices. In some DTNs, exchange of information used to update state in the RIB may take place on network paths distinct from those where exchange of application data takes place.
与Internet体系结构一样，我们区分路由和转发。路由是指根据某个目标函数（例如参见[JFP04]）执行（可能是分布式）算法来计算路由路径。转发是指将包从一个DTN节点移动到另一个DTN节点的行为。路由使用路由状态（RIB，或路由信息库），而转发使用从路由派生的状态，并保持为转发状态（FIB，或转发信息库）。FIB的结构和维护规则是实现选择。在某些DTN中，用于更新RIB中状态的信息交换可能发生在与应用程序数据交换不同的网络路径上。
The maintenance of state in the RIB is dependent on the type of routing algorithm being used. A routing algorithm may consider requested class of service and the location of potential custodians (for custody transfer, see section 3.10), and this information will tend to increase the size of the RIB. The separation between FIB and RIB is not required by this document, as these are implementation details to be decided by system implementers. The choice of routing algorithms is still under study.
RIB中状态的维护取决于所使用的路由算法的类型。路由算法可以考虑请求的服务类别和潜在的保管人的位置（用于托管转移，参见第3.10节），并且该信息将倾向于增加肋的大小。本文件不要求FIB和RIB之间的分离，因为这些是由系统实施者决定的实施细节。路由算法的选择仍在研究中。
Bundles may occupy queues in nodes for a considerable amount of time. For unicast or anycast delivery, the amount of time is likely to be the interval between when a bundle arrives at a node and when it can be forwarded to its next hop. For multicast delivery of bundles, this could be significantly longer, up to a bundle's expiration time. This situation occurs when multicast delivery is utilized in such a way that nodes joining a group can obtain information previously sent to the group. In such cases, some nodes may act as "archivers" that
捆绑包可能会占用节点中的队列相当长的时间。对于单播或选播交付，时间量可能是捆绑到达节点和可以转发到下一跳之间的间隔。对于捆绑包的多播交付，这可能会显著延长，直至捆绑包的过期时间。当以加入组的节点可以获得先前发送给组的信息的方式使用多播传送时，就会发生这种情况。在这种情况下，一些节点可以充当
provide copies of bundles to new participants that have already been delivered to other participants.
向新参与者提供已交付给其他参与者的捆绑包副本。
The DTN security approach described in [DTNSEC], when used, requires maintenance of state in all DTN nodes that use it. All such nodes are required to store their own private information (including their own policy and authentication material) and a block of information used to verify credentials. Furthermore, in most cases, DTN nodes will cache some public information (and possibly the credentials) of their next-hop (bundle) neighbors. All cached information has expiration times, and nodes are responsible for acquiring and distributing updates of public information and credentials prior to the expiration of the old set (in order to avoid a disruption in network service).
使用[DTNSEC]中描述的DTN安全方法时，需要维护使用该方法的所有DTN节点中的状态。所有这些节点都需要存储自己的私有信息（包括自己的策略和身份验证材料）以及用于验证凭据的信息块。此外，在大多数情况下，DTN节点将缓存其下一跳（捆绑）邻居的一些公共信息（可能还有凭据）。所有缓存的信息都有过期时间，节点负责在旧信息集过期之前获取和分发公共信息和凭据的更新（以避免网络服务中断）。
In addition to basic end-to-end and hop-by-hop authentication, access control may be used in a DTN by one or more mechanisms such as capabilities or access control lists (ACLs). ACLs would represent another block of state present in any node that wishes to enforce security policy. ACLs are typically initialized at node configuration time and may be updated dynamically by DTN bundles or by some out of band technique. Capabilities or credentials may be revoked, requiring the maintenance of a revocation list ("black list", another form of state) to check for invalid authentication material that has already been distributed.
除了基本的端到端和逐跳认证之外，访问控制还可以通过一个或多个机制（例如能力或访问控制列表（ACL））在DTN中使用。ACL将表示任何希望强制执行安全策略的节点中存在的另一个状态块。ACL通常在节点配置时初始化，可以通过DTN包或某些带外技术动态更新。可能会撤销功能或凭据，需要维护撤销列表（“黑名单”，另一种状态形式），以检查已分发的无效身份验证材料。
Some DTNs may implement security boundaries enforced by selected nodes in the network, where end-to-end credentials may be checked in addition to checking the hop-by-hop credentials. (Doing so may require routing to be adjusted to ensure all bundles comprising each ADU pass through these points.) Public information used to verify end-to-end authentication will typically be cached at these points.
一些DTN可以实现由网络中的选定节点强制执行的安全边界，其中除了检查逐跳凭证外，还可以检查端到端凭证。（这样做可能需要调整路由，以确保组成每个ADU的所有捆绑包都通过这些点。）用于验证端到端身份验证的公共信息通常会缓存在这些点上。
DTN nodes will contain some amount of configuration and policy information. Such information may alter the behavior of bundle forwarding. Examples of policy state include the types of cryptographic algorithms and access control procedures to use if DTN security is employed, whether nodes may become custodians, what types of convergence layer (see Section 6) and routing protocols are in use, how bundles of differing priorities should be scheduled, where and for how long bundles and other data is stored, what status reports may be generated or at what rate, etc.
DTN节点将包含一些配置和策略信息。这些信息可能会改变包转发的行为。策略状态的示例包括：如果采用DTN安全性，将使用的加密算法和访问控制程序的类型，节点是否可能成为保管人，使用的是什么类型的汇聚层（见第6节）和路由协议，不同优先级的包应如何调度，捆绑包和其他数据存储在何处以及存储多长时间，可以生成什么状态报告或以什么速率生成，等等。
DTN bundle delivery is intended to operate in a delay-tolerant fashion over a broad range of network types. This does not mean there *must* be large delays in the network; it means there *may* be very significant delays (including extended periods of disconnection between sender and intended recipient(s)). The DTN protocols are delay tolerant, so applications using them must also be delay tolerant in order to operate effectively in environments subject to significant delay or disruption.
DTN捆绑交付旨在在各种网络类型上以容忍延迟的方式运行。这并不意味着网络中必须有大的延迟；这意味着*可能*有非常严重的延迟（包括发送方和预期接收方之间的长时间断开连接）。DTN协议具有延迟容忍能力，因此使用DTN协议的应用程序也必须具有延迟容忍能力，以便在存在严重延迟或中断的环境中有效运行。
The communication primitives provided by the DTN architecture are based on asynchronous, message-oriented communication which differs from conversational request/response communication. In general, applications should attempt to include enough information in an ADU so that it may be treated as an independent unit of work by the network and receiver(s). The goal is to minimize synchronous interchanges between applications that are separated by a network characterized by long and possibly highly variable delays. A single file transfer request message, for example, might include authentication information, file location information, and requested file operation (thus "bundling" this information together). Comparing this style of operation to a classic FTP transfer, one sees that the bundled model can complete in one round trip, whereas an FTP file "put" operation can take as many as eight round trips to get to a point where file data can flow [DFS02].
DTN体系结构提供的通信原语基于异步、面向消息的通信，这与会话请求/响应通信不同。一般来说，应用程序应尝试在ADU中包含足够的信息，以便网络和接收器将其视为独立的工作单元。其目标是最大限度地减少应用程序之间的同步交换，这些应用程序由一个具有长且可能高度可变延迟的网络分隔开。例如，单个文件传输请求消息可能包括身份验证信息、文件位置信息和请求的文件操作（因此将这些信息“捆绑”在一起）。将这种操作方式与经典的FTP传输进行比较，可以发现捆绑模式可以在一次往返中完成，而FTP文件“放置”操作可能需要多达八次往返才能到达文件数据可以流动的位置[DFS02]。
Delay-tolerant applications must consider additional factors beyond the conversational implications of long delay paths. For example, an application may terminate (voluntarily or not) between the time it sends a message and the time it expects a response. If this possibility has been anticipated, the application can be "re-instantiated" with state information saved in persistent storage. This is an implementation issue, but also an application design consideration.
延迟容忍应用必须考虑超出长延时路径会话含义的附加因素。例如，在应用程序发送（或预期）响应的时间与应用程序发送（或预期）响应的时间之间，可能会自动终止。如果已经预料到这种可能性，则可以使用保存在持久存储中的状态信息“重新实例化”应用程序。这是一个实现问题，也是应用程序设计的考虑因素。
Some consideration of delay-tolerant application design can result in applications that work reasonably well in low-delay environments, and that do not suffer extraordinarily in high or highly-variable delay environments.
对延迟容忍应用程序设计的一些考虑可以使应用程序在低延迟环境中工作得相当好，并且在高延迟或高度可变的延迟环境中不会受到特别的影响。
Implementation experience with the DTN architecture has revealed an important architectural construct and interface for DTN nodes [DBFJHP04]. Not all underlying protocols in different protocol families provide the same exact functionality, so some additional adaptation or augmentation on a per-protocol or per-protocol-family
DTN体系结构的实施经验揭示了DTN节点的重要体系结构构造和接口[DBFJHP04]。并非不同协议族中的所有底层协议都提供相同的确切功能，因此对每个协议或每个协议族进行了一些额外的调整或扩充
basis may be required. This adaptation is accomplished by a set of convergence layers placed between the bundle layer and underlying protocols. The convergence layers manage the protocol-specific details of interfacing with particular underlying protocols and present a consistent interface to the bundle layer.
可能需要一个基础。这种适应是通过在捆绑层和底层协议之间放置一组聚合层来实现的。汇聚层管理与特定底层协议接口的协议特定细节，并向捆绑层提供一致的接口。
The complexity of one convergence layer may vary substantially from another, depending on the type of underlying protocol it adapts. For example, a TCP/IP convergence layer for use in the Internet might only have to add message boundaries to TCP streams, whereas a convergence layer for some network where no reliable transport protocol exists might be considerably more complex (e.g., it might have to implement reliability, fragmentation, flow-control, etc.) if reliable delivery is to be offered to the bundle layer.
一个汇聚层的复杂性可能与另一个汇聚层有很大的不同，这取决于它所适应的底层协议的类型。例如，用于Internet的TCP/IP聚合层可能只需向TCP流添加消息边界，而对于某些不存在可靠传输协议的网络，聚合层可能要复杂得多（例如，它可能必须实现可靠性、碎片化、流控制等）如果要向捆绑层提供可靠的交付。
As convergence layers implement protocols above and beyond the basic bundle protocol specified in [BSPEC], they will be defined in their own documents (in a fashion similar to the way encapsulations for IP datagrams are specified on a per-underlying-protocol basis, such as in RFC 894 [RFC894]).
由于汇聚层实现的协议高于[BSPEC]中规定的基本捆绑协议，因此它们将在自己的文档中定义（以类似于在每个底层协议基础上指定IP数据报封装的方式，如在RFC 894[RFC894]中）。
The DTN architecture addresses many of the problems of heterogeneous networks that must operate in environments subject to long delays and discontinuous end-to-end connectivity. It is based on asynchronous messaging and uses postal mail as a model of service classes and delivery semantics. It accommodates many different forms of connectivity, including scheduled, predicted, and opportunistically connected delivery paths. It introduces a novel approach to end-to-end reliability across frequently partitioned and unreliable networks. It also proposes a model for securing the network infrastructure against unauthorized access.
DTN体系结构解决了必须在长延迟和不连续端到端连接的环境中运行的异构网络的许多问题。它基于异步消息传递，并使用邮政邮件作为服务类和传递语义的模型。它支持多种不同形式的连接，包括计划、预测和机会连接的交付路径。它介绍了一种跨频繁分区和不可靠网络的端到端可靠性的新方法。它还提出了一个保护网络基础设施免受未经授权访问的模型。
It is our belief that this architecture is applicable to many different types of challenged environments.
我们相信，这种体系结构适用于许多不同类型的挑战环境。
Security is an integral concern for the design of the Delay Tolerant Network Architecture, but its use is optional. Sections 3.6.1, 3.14, and 4.4 of this document present some factors to consider for securing the DTN architecture, but separate documents [DTNSOV] and [DTNSEC] define the security architecture in much more detail.
安全性是延迟容忍网络体系结构设计的一个整体问题，但其使用是可选的。本文档的3.3.1、3.14和4.4部分提供了一些考虑DTN体系结构的因素，但是单独的文档[dTNSOv]和[dTNSEC]更详细地定义了安全体系结构。
This document specifies the architecture for Delay Tolerant Networking, which uses Internet-standard URIs for its Endpoint Identifiers. URIs intended for use with DTN should be compliant with the guidelines given in [RFC3986].
本文档指定了延迟容忍网络的体系结构，该体系结构使用互联网标准URI作为其端点标识符。用于DTN的URI应符合[RFC3986]中给出的指南。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[IPN01] InterPlaNetary Internet Project, Internet Society IPN Special Interest Group, http://www.ipnsig.org.
[IPN01]星际互联网项目，互联网协会IPN特别利益集团，http://www.ipnsig.org.
[SB03] S. Burleigh, et al., "Delay-Tolerant Networking - An Approach to Interplanetary Internet", IEEE Communications Magazine, July 2003.
[SB03]S.Burleigh等人，“延迟容忍网络——星际互联网的一种方法”，IEEE通信杂志，2003年7月。
[FW03] F. Warthman, "Delay-Tolerant Networks (DTNs): A Tutorial v1.1", Wartham Associates, 2003. Available from http://www.dtnrg.org.
[FW03]F.Warthman，“延迟容忍网络（DTN）：教程v1.1”，Wartham Associates，2003年。可从http://www.dtnrg.org.
[KF03] K. Fall, "A Delay-Tolerant Network Architecture for Challenged Internets", Proceedings SIGCOMM, Aug 2003.
[KF03]K.Fall，“一种面向挑战性互联网的容迟网络体系结构”，会议记录SIGCOMM，2003年8月。
[JFP04] S. Jain, K. Fall, R. Patra, "Routing in a Delay Tolerant Network", Proceedings SIGCOMM, Aug/Sep 2004.
[JFP04]S.Jain，K.Fall，R.Patra，“延迟容忍网络中的路由”，SIGCOMM学报，2004年8月/9月。
[DFS02] R. Durst, P. Feighery, K. Scott, "Why not use the Standard Internet Suite for the Interplanetary Internet?", MITRE White Paper, 2002. Available from http://www.ipnsig.org/reports/TCP_IP.pdf.
[DFS02]R.Durst，P.Feighery，K.Scott，“为什么不为星际互联网使用标准互联网套件？”，米特白皮书，2002年。可从http://www.ipnsig.org/reports/TCP_IP.pdf.
[CK74] V. Cerf, R. Kahn, "A Protocol for Packet Network Intercommunication", IEEE Trans. on Comm., COM-22(5), May 1974.
[CK74]V.Cerf，R.Kahn，“分组网络内部通信协议”，IEEE Trans。1974年5月第22（5）号通讯。
[IGE00] C. Intanagonwiwat, R. Govindan, D. Estrin, "Directed Diffusion: A Scalable and Robust Communication Paradigm for Sensor Networks", Proceedings MobiCOM, Aug 2000.
[IGE00]C.Intanagonwiwat，R.Govindan，D.Estrin，“定向扩散：传感器网络的可扩展和健壮通信范例”，MobiCOM学报，2000年8月。
[WSBL99] W. Adjie-Winoto, E. Schwartz, H. Balakrishnan, J. Lilley, "The Design and Implementation of an Intentional Naming System", Proc. 17th ACM SOSP, Kiawah Island, SC, Dec. 1999.
[WSBL99]W.Adjie Winoto，E.Schwartz，H.Balakrishnan，J.Lilley，“有意命名系统的设计和实现”，Proc。1999年12月，南卡罗来纳州嘉华岛第17届ACM SOSP。
[CT90] D. Clark, D. Tennenhouse, "Architectural Considerations for a New Generation of Protocols", Proceedings SIGCOMM, 1990.
[CT90]D.Clark，D.Tennenhouse，“新一代协议的架构考虑”，会议记录SIGCOMM，1990年。
[ISCHEMES] IANA, Uniform Resource Identifer (URI) Schemes, http://www.iana.org/assignments/uri-schemes.html.
[ISCHEMES]IANA，统一资源标识（URI）方案，http://www.iana.org/assignments/uri-schemes.html.
[JDPF05] S. Jain, M. Demmer, R. Patra, K. Fall, "Using Redundancy to Cope with Failures in a Delay Tolerant Network", Proceedings SIGCOMM, 2005.
[JDPF05]S.Jain，M.Demmer，R.Patra，K.Fall，“使用冗余来应对延迟容忍网络中的故障”，会议记录SIGCOM，2005年。
[WJMF05] Y. Wang, S. Jain, M. Martonosi, K. Fall, "Erasure Coding Based Routing in Opportunistic Networks", Proceedings SIGCOMM Workshop on Delay Tolerant Networks, 2005.
[WJMF05]Y.Wang，S.Jain，M.Martonosi，K.Fall，“机会网络中基于擦除编码的路由”，SIGCOMM延迟容忍网络研讨会论文集，2005年。
[ZAZ05] W. Zhao, M. Ammar, E. Zegura, "Multicast in Delay Tolerant Networks", Proceedings SIGCOMM Workshop on Delay Tolerant Networks, 2005.
[ZAZ05]W.Zhao，M.Ammar，E.Zegura，“延迟容忍网络中的多播”，SIGCOMM延迟容忍网络研讨会论文集，2005年。
[LFC05] J. Leguay, T. Friedman, V. Conan, "DTN Routing in a Mobility Pattern Space", Proceedings SIGCOMM Workshop on Delay Tolerant Networks, 2005.
[LFC05]J.Leguay，T.Friedman，V.Conan，“移动模式空间中的DTN路由”，SIGCOMM延迟容忍网络研讨会论文集，2005年。
[AF03] J. Alonso, K. Fall, "A Linear Programming Formulation of Flows over Time with Piecewise Constant Capacity and Transit Times", Intel Research Technical Report IRB-TR-03-007, June 2003.
[AF03]J.Alonso，K.Fall，“具有分段恒定容量和运输时间的流量随时间变化的线性规划公式”，英特尔研究技术报告IRB-TR-03-007，2003年6月。
[FHM03] K. Fall, W. Hong, S. Madden, "Custody Transfer for Reliable Delivery in Delay Tolerant Networks", Intel Research Technical Report IRB-TR-03-030, July 2003.
[FHM03]K.Fall，W.Hong，S.Madden，“延迟容忍网络中可靠交付的托管转移”，英特尔研究技术报告IRB-TR-03-030，2003年7月。
[BSPEC] K. Scott, S. Burleigh, "Bundle Protocol Specification", Work in Progress, December 2006.
[BSPEC]K.Scott，S.Burleigh，“捆绑协议规范”，正在进行的工作，2006年12月。
[DTNSEC] S. Symington, S. Farrell, H. Weiss, "Bundle Security Protocol Specification", Work in Progress, October 2006.
[DTNSEC]S.Symington，S.Farrell，H.Weiss，“捆绑安全协议规范”，正在进行的工作，2006年10月。
[DTNSOV] S. Farrell, S. Symington, H. Weiss, "Delay-Tolerant Networking Security Overview", Work in Progress, October 2006.
[DTNSOV]S.Farrell，S.Symington，H.Weiss，“容错网络安全概述”，正在进行的工作，2006年10月。
[DBFJHP04] M. Demmer, E. Brewer, K. Fall, S. Jain, M. Ho, R. Patra, "Implementing Delay Tolerant Networking", Intel Research Technical Report IRB-TR-04-020, Dec. 2004.
[DBFJHP04]M.Demmer，E.Brewer，K.Fall，S.Jain，M.Ho，R.Patra，“实施延迟容忍网络”，英特尔研究技术报告IRB-TR-04-020，2004年12月。
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC792]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，1981年9月。
[RFC894] Hornig, C., "A Standard for the Transmission of IP Datagrams over Ethernet Networks", STD 41, RFC 894, April 1 1984.
[RFC894]Hornig，C.，“通过以太网传输IP数据报的标准”，STD 41，RFC894，1984年4月1日。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960]Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwarzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，L.，和V.Paxson，“流控制传输协议”，RFC 29602000年10月。
[RFC4088] Black, D., McCloghrie, K., and J. Schoenwaelder, "Uniform Resource Identifier (URI) Scheme for the Simple Network Management Protocol (SNMP)", RFC 4088, June 2005.
[RFC4088]Black，D.，McCloghrie，K.，和J.Schoenwaeld，“简单网络管理协议（SNMP）的统一资源标识符（URI）方案”，RFC 4088，2005年6月。
[S05] K. Scott, "Disruption Tolerant Networking Proxies for On-the-Move Tactical Networks", Proc. MILCOM 2005 (unclassified track), Oct. 2005.
[S05]K.Scott，“移动战术网络的抗干扰网络代理”，Proc。MILCOM 2005（非保密赛道），2005年10月。
[T02] W. Thies, et al., "Searching the World Wide Web in Low-Connectivity Communities", Proc. WWW Conference (Global Community track), May 2002.
[T02]W.Thies等人，“在低连通性社区中搜索万维网”，Proc。WWW会议（全球社区轨道），2002年5月。
John Wroclawski, David Mills, Greg Miller, James P. G. Sterbenz, Joe Touch, Steven Low, Lloyd Wood, Robert Braden, Deborah Estrin, Stephen Farrell, Melissa Ho, Ting Liu, Mike Demmer, Jakob Ericsson, Susan Symington, Andrei Gurtov, Avri Doria, Tom Henderson, Mark Allman, Michael Welzl, and Craig Partridge all contributed useful thoughts and criticisms to versions of this document. We are grateful for their time and participation.
约翰·沃克罗夫斯基、大卫·米尔斯、格雷格·米勒、詹姆斯·P·G·斯特本斯、乔·图奇、史蒂文·洛、劳埃德·伍德、罗伯特·布拉登、黛博拉·埃斯林、斯蒂芬·法雷尔、何梅丽莎、刘婷、迈克·德默、雅各布·爱立信、苏珊·西明顿、安德烈·古托夫、艾弗里·多里亚、汤姆·亨德森、马克·奥尔曼、迈克尔·韦尔茨、，克雷格·帕特里奇（Craig Partridge）都对这份文件的版本提出了有益的想法和批评。我们感谢他们的时间和参与。
This work was performed in part 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。
Authors' Addresses
作者地址
Dr. Vinton G. Cerf Google Corporation Suite 384 13800 Coppermine Rd. Herndon, VA 20171 Phone: +1 (703) 234-1823 Fax: +1 (703) 848-0727 EMail: vint@google.com
Vinton G.Cerf博士谷歌公司套房384 13800弗吉尼亚州赫恩登科佩明路20171电话：+1（703）234-1823传真：+1（703）848-0727电子邮件：vint@google.com
Scott C. Burleigh Jet Propulsion Laboratory 4800 Oak Grove Drive M/S: 179-206 Pasadena, CA 91109-8099 Phone: +1 (818) 393-3353 Fax: +1 (818) 354-1075 EMail: Scott.Burleigh@jpl.nasa.gov
斯科特·C·伯利喷气推进实验室4800橡树林大道M/S:179-206加利福尼亚州帕萨迪纳91109-8099电话：+1（818）393-3353传真：+1（818）354-1075电子邮件：斯科特。Burleigh@jpl.nasa.gov
Robert C. Durst The MITRE Corporation 7515 Colshire Blvd., M/S H440 McLean, VA 22102 Phone: +1 (703) 983-7535 Fax: +1 (703) 983-7142 EMail: durst@mitre.org
Robert C.Durst The MITRE Corporation 7515 Colshire Blvd.，M/S H440 McLean，弗吉尼亚州22102电话：+1（703）983-7535传真：+1（703）983-7142电子邮件：durst@mitre.org
Dr. Kevin Fall Intel Research, Berkeley 2150 Shattuck Ave., #1300 Berkeley, CA 94704 Phone: +1 (510) 495-3014 Fax: +1 (510) 495-3049 EMail: kfall@intel.com
Kevin Fall Intel Research博士，加利福尼亚州伯克利市沙塔克大道2150号，伯克利，邮编：94704电话：+1（510）495-3014传真：+1（510）495-3049电子邮件：kfall@intel.com
Adrian J. Hooke Jet Propulsion Laboratory 4800 Oak Grove Drive M/S: 303-400 Pasadena, CA 91109-8099 Phone: +1 (818) 354-3063 Fax: +1 (818) 393-3575 EMail: Adrian.Hooke@jpl.nasa.gov
阿德里安J.胡克喷气推进实验室4800橡树林大道M/S:303-400加利福尼亚州帕萨迪纳91109-8099电话：+1（818）354-3063传真：+1（818）393-3575电子邮件：阿德里安。Hooke@jpl.nasa.gov
Dr. Keith L. Scott The MITRE Corporation 7515 Colshire Blvd., M/S H440 McLean, VA 22102 Phone: +1 (703) 983-6547 Fax: +1 (703) 983-7142 EMail: kscott@mitre.org
Keith L.Scott The MITRE Corporation 7515 Colshire Blvd.，M/S H440 McLean，VA 22102电话：+1（703）983-6547传真：+1（703）983-7142电子邮件：kscott@mitre.org
Leigh Torgerson Jet Propulsion Laboratory 4800 Oak Grove Drive M/S: 238-412 Pasadena, CA 91109-8099 Phone: +1 (818) 393-0695 Fax: +1 (818) 354-6825 EMail: ltorgerson@jpl.nasa.gov
Leigh Torgerson喷气推进实验室4800橡树林大道M/S:238-412加利福尼亚州帕萨迪纳91109-8099电话：+1（818）393-0695传真：+1（818）354-6825电子邮件：ltorgerson@jpl.nasa.gov
Howard S. Weiss SPARTA, Inc. 7075 Samuel Morse Drive Columbia, MD 21046 Phone: +1 (410) 872-1515 x201 Fax: +1 (410) 872-8079 EMail: howard.weiss@sparta.com
Howard S.Weiss SPARTA，Inc.美国马里兰州哥伦比亚塞缪尔莫尔斯大道7075号21046电话：+1（410）872-1515 x201传真：+1（410）872-8079电子邮件：Howard。weiss@sparta.com
Please refer comments to dtn-interest@mailman.dtnrg.org. The Delay Tolerant Networking Research Group (DTNRG) web site is located at http://www.dtnrg.org.
请参考dtn的评论-interest@mailman.dtnrg.org. 容错网络研究组（DTNRG）网站位于http://www.dtnrg.org.
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。