Network Working Group K. Scott
Request for Comments: 5050 The MITRE Corporation
Category: Experimental S. Burleigh
NASA Jet Propulsion Laboratory
November 2007
Network Working Group K. Scott
Request for Comments: 5050 The MITRE Corporation
Category: Experimental S. Burleigh
NASA Jet Propulsion Laboratory
November 2007
Bundle Protocol Specification
捆绑协议规范
Status of This Memo
关于下段备忘
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
IESG Note
IESG注释
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
本RFC不适用于任何级别的互联网标准。IETF不承认本RFC适用于任何目的的任何知识，特别注意到，发布决定并非基于IETF对安全、拥塞控制或与已部署协议的不当交互等事项的审查。RFC编辑已自行决定发布本文件。本文档的读者在评估其实施和部署价值时应谨慎。有关更多信息，请参阅RFC 3932。
Abstract
摘要
This document describes the end-to-end protocol, block formats, and abstract service description for the exchange of messages (bundles) in Delay Tolerant Networking (DTN).
本文档描述了延迟容忍网络（DTN）中消息交换（捆绑包）的端到端协议、块格式和抽象服务描述。
This document was produced within the IRTF's Delay Tolerant Networking Research Group (DTNRG) and represents the consensus of all of the active contributors to this group. See http://www.dtnrg.org for more information.
本文件由IRTF的延迟容忍网络研究小组（DTNRG）编制，代表了该小组所有积极贡献者的共识。看见http://www.dtnrg.org 了解更多信息。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Service Description . . . . . . . . . . . . . . . . . . . . . 5
3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Implementation Architectures . . . . . . . . . . . . . . . 9
3.3. Services Offered by Bundle Protocol Agents . . . . . . . . 11
4. Bundle Format . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Self-Delimiting Numeric Values (SDNVs) . . . . . . . . . . 12
4.2. Bundle Processing Control Flags . . . . . . . . . . . . . 13
4.3. Block Processing Control Flags . . . . . . . . . . . . . . 15
4.4. Endpoint IDs . . . . . . . . . . . . . . . . . . . . . . . 16
4.5. Formats of Bundle Blocks . . . . . . . . . . . . . . . . . 17
4.5.1. Primary Bundle Block . . . . . . . . . . . . . . . . . 19
4.5.2. Canonical Bundle Block Format . . . . . . . . . . . . 22
4.5.3. Bundle Payload Block . . . . . . . . . . . . . . . . . 23
4.6. Extension Blocks . . . . . . . . . . . . . . . . . . . . . 24
4.7. Dictionary Revision . . . . . . . . . . . . . . . . . . . 24
5. Bundle Processing . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Generation of Administrative Records . . . . . . . . . . . 25
5.2. Bundle Transmission . . . . . . . . . . . . . . . . . . . 26
5.3. Bundle Dispatching . . . . . . . . . . . . . . . . . . . . 26
5.4. Bundle Forwarding . . . . . . . . . . . . . . . . . . . . 27
5.4.1. Forwarding Contraindicated . . . . . . . . . . . . . . 28
5.4.2. Forwarding Failed . . . . . . . . . . . . . . . . . . 29
5.5. Bundle Expiration . . . . . . . . . . . . . . . . . . . . 29
5.6. Bundle Reception . . . . . . . . . . . . . . . . . . . . . 30
5.7. Local Bundle Delivery . . . . . . . . . . . . . . . . . . 31
5.8. Bundle Fragmentation . . . . . . . . . . . . . . . . . . . 32
5.9. Application Data Unit Reassembly . . . . . . . . . . . . . 33
5.10. Custody Transfer . . . . . . . . . . . . . . . . . . . . . 34
5.10.1. Custody Acceptance . . . . . . . . . . . . . . . . . . 34
5.10.2. Custody Release . . . . . . . . . . . . . . . . . . . 35
5.11. Custody Transfer Success . . . . . . . . . . . . . . . . . 35
5.12. Custody Transfer Failure . . . . . . . . . . . . . . . . . 35
5.13. Bundle Deletion . . . . . . . . . . . . . . . . . . . . . 36
5.14. Discarding a Bundle . . . . . . . . . . . . . . . . . . . 36
5.15. Canceling a Transmission . . . . . . . . . . . . . . . . . 36
5.16. Polling . . . . . . . . . . . . . . . . . . . . . . . . . 36
6. Administrative Record Processing . . . . . . . . . . . . . . . 37
6.1. Administrative Records . . . . . . . . . . . . . . . . . . 37
6.1.1. Bundle Status Reports . . . . . . . . . . . . . . . . 38
6.1.2. Custody Signals . . . . . . . . . . . . . . . . . . . 41
6.2. Generation of Administrative Records . . . . . . . . . . . 44
6.3. Reception of Custody Signals . . . . . . . . . . . . . . . 44
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Service Description . . . . . . . . . . . . . . . . . . . . . 5
3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Implementation Architectures . . . . . . . . . . . . . . . 9
3.3. Services Offered by Bundle Protocol Agents . . . . . . . . 11
4. Bundle Format . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Self-Delimiting Numeric Values (SDNVs) . . . . . . . . . . 12
4.2. Bundle Processing Control Flags . . . . . . . . . . . . . 13
4.3. Block Processing Control Flags . . . . . . . . . . . . . . 15
4.4. Endpoint IDs . . . . . . . . . . . . . . . . . . . . . . . 16
4.5. Formats of Bundle Blocks . . . . . . . . . . . . . . . . . 17
4.5.1. Primary Bundle Block . . . . . . . . . . . . . . . . . 19
4.5.2. Canonical Bundle Block Format . . . . . . . . . . . . 22
4.5.3. Bundle Payload Block . . . . . . . . . . . . . . . . . 23
4.6. Extension Blocks . . . . . . . . . . . . . . . . . . . . . 24
4.7. Dictionary Revision . . . . . . . . . . . . . . . . . . . 24
5. Bundle Processing . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Generation of Administrative Records . . . . . . . . . . . 25
5.2. Bundle Transmission . . . . . . . . . . . . . . . . . . . 26
5.3. Bundle Dispatching . . . . . . . . . . . . . . . . . . . . 26
5.4. Bundle Forwarding . . . . . . . . . . . . . . . . . . . . 27
5.4.1. Forwarding Contraindicated . . . . . . . . . . . . . . 28
5.4.2. Forwarding Failed . . . . . . . . . . . . . . . . . . 29
5.5. Bundle Expiration . . . . . . . . . . . . . . . . . . . . 29
5.6. Bundle Reception . . . . . . . . . . . . . . . . . . . . . 30
5.7. Local Bundle Delivery . . . . . . . . . . . . . . . . . . 31
5.8. Bundle Fragmentation . . . . . . . . . . . . . . . . . . . 32
5.9. Application Data Unit Reassembly . . . . . . . . . . . . . 33
5.10. Custody Transfer . . . . . . . . . . . . . . . . . . . . . 34
5.10.1. Custody Acceptance . . . . . . . . . . . . . . . . . . 34
5.10.2. Custody Release . . . . . . . . . . . . . . . . . . . 35
5.11. Custody Transfer Success . . . . . . . . . . . . . . . . . 35
5.12. Custody Transfer Failure . . . . . . . . . . . . . . . . . 35
5.13. Bundle Deletion . . . . . . . . . . . . . . . . . . . . . 36
5.14. Discarding a Bundle . . . . . . . . . . . . . . . . . . . 36
5.15. Canceling a Transmission . . . . . . . . . . . . . . . . . 36
5.16. Polling . . . . . . . . . . . . . . . . . . . . . . . . . 36
6. Administrative Record Processing . . . . . . . . . . . . . . . 37
6.1. Administrative Records . . . . . . . . . . . . . . . . . . 37
6.1.1. Bundle Status Reports . . . . . . . . . . . . . . . . 38
6.1.2. Custody Signals . . . . . . . . . . . . . . . . . . . 41
6.2. Generation of Administrative Records . . . . . . . . . . . 44
6.3. Reception of Custody Signals . . . . . . . . . . . . . . . 44
7. Services Required of the Convergence Layer . . . . . . . . . . 44
7.1. The Convergence Layer . . . . . . . . . . . . . . . . . . 44
7.2. Summary of Convergence Layer Services . . . . . . . . . . 45
8. Security Considerations . . . . . . . . . . . . . . . . . . . 45
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
10.1. Normative References . . . . . . . . . . . . . . . . . . . 47
10.2. Informative References . . . . . . . . . . . . . . . . . . 47
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 49
Appendix B. Comments . . . . . . . . . . . . . . . . . . . . . . 49
7. Services Required of the Convergence Layer . . . . . . . . . . 44
7.1. The Convergence Layer . . . . . . . . . . . . . . . . . . 44
7.2. Summary of Convergence Layer Services . . . . . . . . . . 45
8. Security Considerations . . . . . . . . . . . . . . . . . . . 45
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
10.1. Normative References . . . . . . . . . . . . . . . . . . . 47
10.2. Informative References . . . . . . . . . . . . . . . . . . 47
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 49
Appendix B. Comments . . . . . . . . . . . . . . . . . . . . . . 49
This document describes version 6 of the Delay Tolerant Networking (DTN) "bundle" protocol (BP). Delay Tolerant Networking is an end-to-end architecture providing communications in and/or through highly stressed environments. Stressed networking environments include those with intermittent connectivity, large and/or variable delays, and high bit error rates. To provide its services, BP sits at the application layer of some number of constituent internets, forming a store-and-forward overlay network. Key capabilities of BP include:
本文档描述了延迟容忍网络（DTN）“捆绑”协议（BP）的第6版。延迟容忍网络是一种端到端架构，可在高压力环境中和/或通过高压力环境提供通信。紧张的网络环境包括间歇性连接、大延迟和/或可变延迟以及高误码率的环境。为了提供服务，BP位于若干组成互联网的应用层，形成一个存储转发覆盖网络。BP的主要能力包括：
o Custody-based retransmission
o 基于监护的重传
o Ability to cope with intermittent connectivity
o 处理间歇性连接的能力
o Ability to take advantage of scheduled, predicted, and opportunistic connectivity (in addition to continuous connectivity)
o 能够利用计划、预测和机会主义连接（以及连续连接）
o Late binding of overlay network endpoint identifiers to constituent internet addresses
o 覆盖网络端点标识符与组成internet地址的后期绑定
For descriptions of these capabilities and the rationale for the DTN architecture, see [ARCH] and [SIGC]. [TUT] contains a tutorial-level overview of DTN concepts.
有关这些功能的描述和DTN体系结构的基本原理，请参见[ARCH]和[SIGC]。[TUT]包含DTN概念的教程级概述。
This is an experimental protocol, produced within the IRTF's Delay Tolerant Networking Research Group (DTNRG) and represents the consensus of all of the active contributors to this group. If this protocol is used on the Internet, IETF standard protocols for security and congestion control should be used.
这是一个实验性协议，由IRTF的延迟容忍网络研究小组（DTNRG）制定，代表了该小组所有积极参与者的共识。如果此协议在Internet上使用，则应使用IETF安全和拥塞控制标准协议。
BP's location within the standard protocol stack is as shown in Figure 1. BP uses the "native" internet protocols for communications within a given internet. Note that "internet" in the preceding is used in a general sense and does not necessarily refer to TCP/IP. The interface between the common bundle protocol and a specific
BP在标准协议栈中的位置如图1所示。BP使用“本地”互联网协议在给定互联网内进行通信。请注意，前面的“internet”是在一般意义上使用的，不一定指TCP/IP。公共包协议与特定包之间的接口
internetwork protocol suite is termed a "convergence layer adapter". Figure 1 shows three distinct transport and network protocols (denoted T1/N1, T2/N2, and T3/N3).
互联网协议套件被称为“汇聚层适配器”。图1显示了三种不同的传输和网络协议（表示为T1/N1、T2/N2和T3/N3）。
+-----------+ +-----------+
| BP app | | BP app |
+---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+
| BP v | | ^ BP v | | ^ BP v | | ^ BP |
+---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+
| Trans1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ Trans3 |
+---------v-+ +-^---------v-+ +-^---------v + +-^---------+
| Net1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ Net3 |
+---------v-+ +-^---------v + +-^---------v-+ +-^---------+
| >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ |
+-----------+ +-------------+ +-------------+ +-----------+
| | | |
|<--- An internet --->| |<--- An internet --->|
| | | |
+-----------+ +-----------+
| BP app | | BP app |
+---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+
| BP v | | ^ BP v | | ^ BP v | | ^ BP |
+---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+
| Trans1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ Trans3 |
+---------v-+ +-^---------v-+ +-^---------v + +-^---------+
| Net1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ Net3 |
+---------v-+ +-^---------v + +-^---------v-+ +-^---------+
| >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ |
+-----------+ +-------------+ +-------------+ +-----------+
| | | |
|<--- An internet --->| |<--- An internet --->|
| | | |
Figure 1: The Bundle Protocol Sits at the Application Layer of the Internet Model
图1：捆绑协议位于Internet模型的应用层
This document describes the format of the protocol data units (called bundles) passed between entities participating in BP communications. The entities are referred to as "bundle nodes". This document does not address:
本文档描述了参与BP通信的实体之间传递的协议数据单元（称为捆绑包）的格式。这些实体称为“束节点”。本文件不涉及：
o Operations in the convergence layer adapters that bundle nodes use to transport data through specific types of internets. (However, the document does discuss the services that must be provided by each adapter at the convergence layer.)
o 聚合层适配器中的操作，捆绑节点使用该适配器通过特定类型的Internet传输数据。（不过，本文档确实讨论了每个适配器在聚合层必须提供的服务。）
o The bundle routing algorithm.
o 包路由算法。
o Mechanisms for populating the routing or forwarding information bases of bundle nodes.
o 填充捆绑节点的路由或转发信息库的机制。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Bundle - A bundle is a protocol data unit of the DTN bundle protocol. Each bundle comprises a sequence of two or more "blocks" of protocol data, which serve various purposes. Multiple instances of the same bundle (the same unit of DTN protocol data) might exist concurrently in different parts of a network -- possibly in different representations -- in the memory local to one or more bundle nodes and/or in transit between nodes. In the context of the operation of a bundle node, a bundle is an instance of some bundle in the network that is in that node's local memory.
Bundle-Bundle是DTN Bundle协议的协议数据单元。每个捆绑包由两个或多个协议数据“块”组成，用于各种用途。同一捆绑包（DTN协议数据的同一单元）的多个实例可能同时存在于网络的不同部分——可能以不同的表示形式存在于一个或多个捆绑包节点的本地内存中和/或在节点之间传输。在bundle节点的操作上下文中，bundle是网络中某个bundle的实例，该bundle位于该节点的本地内存中。
Bundle payload - A bundle payload (or simply "payload") is the application data whose conveyance to the bundle's destination is the purpose for the transmission of a given bundle. The terms "bundle content", "bundle payload", and "payload" are used interchangeably in this document. The "nominal" payload for a bundle forwarded in response to a bundle transmission request is the application data unit whose location is provided as a parameter to that request. The nominal payload for a bundle forwarded in response to reception of that bundle is the payload of the received bundle.
捆绑负载-捆绑负载（或简称“负载”）是应用程序数据，其传输到捆绑目的地是传输给定捆绑的目的。术语“捆绑内容”、“捆绑有效负载”和“有效负载”在本文档中互换使用。为响应捆绑传输请求而转发的捆绑的“标称”有效载荷是应用数据单元，其位置作为该请求的参数提供。为响应捆绑包的接收而转发的捆绑包的标称有效负载是所接收捆绑包的有效负载。
Fragment - A fragment is a bundle whose payload block contains a fragmentary payload. A fragmentary payload is either the first N bytes or the last N bytes of some other payload -- either a nominal payload or a fragmentary payload -- of length M, such that 0 < N < M.
片段-片段是其有效负载块包含片段有效负载的捆绑包。碎片有效载荷是长度为M的某个其他有效载荷（标称有效载荷或碎片有效载荷）的前N个字节或最后N个字节，例如0<N<M。
Bundle node - A bundle node (or, in the context of this document, simply a "node") is any entity that can send and/or receive bundles. In the most familiar case, a bundle node is instantiated as a single process running on a general-purpose computer, but in general the definition is meant to be broader: a bundle node might alternatively be a thread, an object in an object-oriented operating system, a special-purpose hardware device, etc. Each bundle node has three conceptual components, defined below: a "bundle protocol agent", a set of zero or more "convergence layer adapters", and an "application agent".
Bundle节点-Bundle节点（或者，在本文档的上下文中，简称为“节点”）是可以发送和/或接收Bundle的任何实体。在最常见的情况下，bundle节点被实例化为在通用计算机上运行的单个进程，但一般来说，其定义更广泛：bundle节点也可以是线程、面向对象操作系统中的对象、专用硬件设备，每个bundle节点有三个概念组件，定义如下：一个“bundle协议代理”、一组零个或多个“汇聚层适配器”和一个“应用程序代理”。
Bundle protocol agent - The bundle protocol agent (BPA) of a node is the node component that offers the BP services and executes the procedures of the bundle protocol. The manner in which it does so is wholly an implementation matter. For example, BPA functionality might be coded into each node individually; it might be implemented as a shared library that is used in common by any
捆绑协议代理—节点的捆绑协议代理（BPA）是提供BP服务并执行捆绑协议过程的节点组件。它这样做的方式完全是一个执行问题。例如，BPA功能可以单独编码到每个节点中；它可能被实现为一个共享库，供任何用户共同使用
number of bundle nodes on a single computer; it might be implemented as a daemon whose services are invoked via inter-process or network communication by any number of bundle nodes on one or more computers; it might be implemented in hardware.
单个计算机上的束节点数；它可以实现为守护进程，其服务通过进程间或网络通信由一台或多台计算机上的任意数量的捆绑节点调用；它可以在硬件中实现。
Convergence layer adapters - A convergence layer adapter (CLA) sends and receives bundles on behalf of the BPA, utilizing the services of some 'native' internet protocol that is supported in one of the internets within which the node is functionally located. The manner in which a CLA sends and receives bundles is wholly an implementation matter, exactly as described for the BPA.
汇聚层适配器-汇聚层适配器（CLA）代表BPA发送和接收捆绑包，利用某些“本机”互联网协议的服务，这些协议在节点功能所在的一个互联网中受支持。CLA发送和接收捆绑包的方式完全是一个实现问题，正如BPA所描述的那样。
Application agent - The application agent (AA) of a node is the node component that utilizes the BP services to effect communication for some purpose. The application agent in turn has two elements, an administrative element and an application-specific element. The application-specific element of an AA constructs, requests transmission of, accepts delivery of, and processes application-specific application data units; the only interface between the BPA and the application-specific element of the AA is the BP service interface. The administrative element of an AA constructs and requests transmission of administrative records (status reports and custody signals), and it accepts delivery of and processes any custody signals that the node receives. In addition to the BP service interface, there is a (conceptual) private control interface between the BPA and the administrative element of the AA that enables each to direct the other to take action under specific circumstances. In the case of a node that serves simply as a "router" in the overlay network, the AA may have no application-specific element at all. The application-specific elements of other nodes' AAs may perform arbitrarily complex application functions, perhaps even offering multiplexed DTN communication services to a number of other applications. As with the BPA, the manner in which the AA performs its functions is wholly an implementation matter; in particular, the administrative element of an AA might be built into the library or daemon or hardware that implements the BPA, and the application-specific element of an AA might be implemented either in software or in hardware.
应用程序代理-节点的应用程序代理（AA）是利用BP服务实现通信的节点组件。应用程序代理又有两个元素，一个管理元素和一个特定于应用程序的元素。AA的特定于应用的元素构造、请求传输、接受交付和处理特定于应用的应用数据单元；BPA和AA的应用程序特定元素之间的唯一接口是BP服务接口。AA的管理元素构造并请求传输管理记录（状态报告和监护信号），它接受并处理节点接收到的任何监护信号。除了BP服务接口外，BPA和AA的管理元素之间还有一个（概念上的）私人控制接口，使双方能够指示对方在特定情况下采取行动。在覆盖网络中仅用作“路由器”的节点的情况下，AA可能根本没有特定于应用程序的元素。其他节点的AAs的特定于应用的元件可以执行任意复杂的应用功能，甚至可能向许多其他应用提供多路复用DTN通信服务。与《BPA》一样，机管局履行其职能的方式完全是一个实施问题；特别是，AA的管理元素可以内置到实现BPA的库、守护进程或硬件中，AA的应用程序特定元素可以在软件或硬件中实现。
Bundle endpoint - A bundle endpoint (or simply "endpoint") is a set of zero or more bundle nodes that all identify themselves for BP purposes by some single text string, called a "bundle endpoint ID" (or, in this document, simply "endpoint ID"; endpoint IDs are described in detail in Section 4.4 below). The special case of an endpoint that never contains more than one node is termed a "singleton" endpoint; every bundle node must be a member of at least one singleton endpoint. Singletons are the most familiar
Bundle endpoint-Bundle endpoint（或简称“endpoint”）是一组零个或多个Bundle节点，它们都通过一个称为“Bundle endpoint ID”（或在本文档中简称为“endpoint ID”；endpoint ID在下面的第4.4节中有详细描述）的文本字符串为BP目的标识自己。从不包含多个节点的端点的特殊情况称为“单一”端点；每个束节点必须是至少一个单例终结点的成员。单身人士是最熟悉的
sort of endpoint, but in general the endpoint notion is meant to be broader. For example, the nodes in a sensor network might constitute a set of bundle nodes that identify themselves by a single common endpoint ID and thus form a single bundle endpoint. *Note* too that a given bundle node might identify itself by multiple endpoint IDs and thus be a member of multiple bundle endpoints.
一种端点，但一般来说，端点的概念是更广泛的。例如，传感器网络中的节点可能构成一组束节点，这些束节点通过单个公共端点ID标识自己，从而形成单个束端点*还要注意*一个给定的bundle节点可能通过多个端点ID来标识自己，从而成为多个bundle端点的成员。
Forwarding - When the bundle protocol agent of a node determines that a bundle must be "forwarded" to an endpoint, it causes the bundle to be sent to all of the nodes that the bundle protocol agent currently believes are in the "minimum reception group" of that endpoint. The minimum reception group of an endpoint may be any one of the following: (a) ALL of the nodes registered in an endpoint that is permitted to contain multiple nodes (in which case forwarding to the endpoint is functionally similar to "multicast" operations in the Internet, though possibly very different in implementation); (b) ANY N of the nodes registered in an endpoint that is permitted to contain multiple nodes, where N is in the range from zero to the cardinality of the endpoint (in which case forwarding to the endpoint is functionally similar to "anycast" operations in the Internet); or (c) THE SOLE NODE registered in a singleton endpoint (in which case forwarding to the endpoint is functionally similar to "unicast" operations in the Internet). The nature of the minimum reception group for a given endpoint can be determined from the endpoint's ID (again, see Section 4.4 below): for some endpoint ID "schemes", the nature of the minimum reception group is fixed - in a manner that is defined by the scheme - for all endpoints identified under the scheme; for other schemes, the nature of the minimum reception group is indicated by some lexical feature of the "scheme-specific part" of the endpoint ID, in a manner that is defined by the scheme.
转发—当节点的捆绑协议代理确定捆绑必须“转发”到某个端点时，它会将捆绑发送到捆绑协议代理当前认为位于该端点的“最小接收组”中的所有节点。端点的最小接收组可以是以下任意一个：（a）在允许包含多个节点的端点中注册的所有节点（在这种情况下，转发到端点在功能上类似于因特网中的“多播”操作，但在实现上可能非常不同）；（b） 在允许包含多个节点的端点中注册的任意N个节点，其中N在从零到端点基数的范围内（在这种情况下，转发到端点在功能上类似于Internet中的“选播”操作）；或者（c）在单一终端中注册的唯一节点（在这种情况下，转发到该终端在功能上类似于互联网中的“单播”操作）。给定端点的最小接收组的性质可以通过端点的ID确定（同样，请参见下面的第4.4节）：对于一些端点ID“方案”，最小接收组的性质是固定的-以方案定义的方式-对于方案下标识的所有端点；对于其他方案，最小接收组的性质由端点ID的“方案特定部分”的一些词汇特征以方案定义的方式表示。
Registration - A registration is the state machine characterizing a given node's membership in a given endpoint. Any number of registrations may be concurrently associated with a given endpoint, and any number of registrations may be concurrently associated with a given node. Any single registration must at any time be in one of two states: Active or Passive. A registration always has an associated "delivery failure action", the action that is to be taken when a bundle that is "deliverable" (see below) subject to that registration is received at a time when the registration is in the Passive state. Delivery failure action must be one of the following:
注册-注册是描述给定节点在给定端点中的成员身份的状态机。任意数量的注册可以与给定端点并发关联，并且任意数量的注册可以与给定节点并发关联。任何单一注册必须在任何时候处于两种状态之一：主动或被动。注册始终有一个相关的“交付失败操作”，即在注册处于被动状态时，收到受该注册约束的“可交付”（见下文）捆绑包时要采取的操作。交付失败操作必须是以下操作之一：
* defer "delivery" (see below) of the bundle subject to this registration until (a) this bundle is the least recently
* 将受此注册约束的捆绑包的“交付”（见下文）推迟到（a）该捆绑包是最新的
received of all bundles currently deliverable subject to this registration and (b) either the registration is polled or else the registration is in the Active state; or
已收到所有当前可交付的捆绑包，但须符合本次注册的要求，并且（b）该注册已被轮询，或者该注册处于活动状态；或
* "abandon" (see below) delivery of the bundle subject to this registration.
* “放弃”（见下文）交付受此注册约束的捆绑包。
An additional implementation-specific delivery deferral procedure may optionally be associated with the registration. While the state of a registration is Active, reception of a bundle that is deliverable subject to this registration must cause the bundle to be delivered automatically as soon as it is the least recently received bundle that is currently deliverable subject to the registration. While the state of a registration is Passive, reception of a bundle that is deliverable subject to this registration must cause delivery of the bundle to be abandoned or deferred as mandated by the registration's current delivery failure action; in the latter case, any additional delivery deferral procedure associated with the registration must also be performed.
附加的特定于实现的交付延迟程序可选择性地与注册相关联。当注册状态处于活动状态时，接收根据此注册可交付的捆绑包必须使该捆绑包在其是最近收到的、当前根据注册可交付的捆绑包时自动交付。当注册状态为被动时，接收根据本注册可交付的捆绑必须导致按照注册当前交付失败行动的要求放弃或推迟捆绑的交付；在后一种情况下，还必须执行与注册相关的任何附加交付延迟程序。
Delivery - Upon reception, the processing of a bundle that has been sent to a given node depends on whether or not the receiving node is registered in the bundle's destination endpoint. If it is, and if the payload of the bundle is non-fragmentary (possibly as a result of successful payload reassembly from fragmentary payloads, including the original payload of the received bundle), then the bundle is normally "delivered" to the node's application agent subject to the registration characterizing the node's membership in the destination endpoint. A bundle is considered to have been delivered at a node subject to a registration as soon as the application data unit that is the payload of the bundle, together with the value of the bundle's "Acknowledgement by application is requested" flag and any other relevant metadata (an implementation matter), has been presented to the node's application agent in a manner consistent with the state of that registration and, as applicable, the registration's delivery failure action.
传递-接收时，已发送到给定节点的捆绑包的处理取决于接收节点是否在捆绑包的目标端点中注册。如果是，并且捆绑包的有效负载是非碎片的（可能是碎片有效负载重新组装成功的结果，包括接收到的捆绑包的原始有效负载），则捆绑包通常是“交付的”发送到节点的应用程序代理，该应用程序代理受描述节点在目标端点中的成员身份的注册的约束。一旦作为捆绑包有效负载的应用程序数据单元，连同捆绑包的“应用程序确认被请求”标志的值和任何其他相关元数据（实现事项），捆绑包被视为已在需要注册的节点处交付，已以与该注册状态一致的方式呈现给节点的应用程序代理，如适用，还包括注册的传递失败操作。
Deliverability, Abandonment - A bundle is considered "deliverable" subject to a registration if and only if (a) the bundle's destination endpoint is the endpoint with which the registration is associated, (b) the bundle has not yet been delivered subject to this registration, and (c) delivery of the bundle subject to this registration has not been abandoned. To "abandon" delivery of a bundle subject to a registration is simply to declare it no longer deliverable subject to that registration; normally only registrations' registered delivery failure actions cause deliveries to be abandoned.
可交付性、放弃-当且仅当（A）捆绑包的目标端点是与注册相关联的端点，（b）捆绑包尚未根据此注册交付，以及（c）时，捆绑包才被视为“可交付”，并进行注册未放弃交付受此注册约束的捆绑包。“放弃”交付受注册约束的捆绑，只是宣布其不再受该注册约束；通常，只有注册的注册交付失败操作才会导致放弃交付。
Deletion, Discarding - A bundle protocol agent "discards" a bundle by simply ceasing all operations on the bundle and functionally erasing all references to it; the specific procedures by which this is accomplished are an implementation matter. Bundles are discarded silently; i.e., the discarding of a bundle does not result in generation of an administrative record. "Retention constraints" are elements of the bundle state that prevent a bundle from being discarded; a bundle cannot be discarded while it has any retention constraints. A bundle protocol agent "deletes" a bundle in response to some anomalous condition by notifying the bundle's report-to endpoint of the deletion (provided such notification is warranted; see Section 5.13 for details) and then arbitrarily removing all of the bundle's retention constraints, enabling the bundle to be discarded.
删除，丢弃-捆绑协议代理通过简单地停止捆绑上的所有操作并从功能上擦除对捆绑的所有引用来“丢弃”捆绑；实现这一目标的具体程序是一个执行问题。包裹被悄悄地丢弃；i、 例如，丢弃包不会导致生成管理记录。“保留约束”是捆绑状态的元素，用于防止放弃捆绑；捆绑包具有任何保留约束时，不能将其丢弃。bundle协议代理响应某些异常情况“删除”bundle，方法是将bundle的报告通知端点删除（前提是此类通知有保证；有关详细信息，请参见第5.13节），然后任意删除bundle的所有保留约束，从而使bundle能够被丢弃。
Transmission - A transmission is a sustained effort by a node's bundle protocol agent to cause a bundle to be sent to all nodes in the minimum reception group of some endpoint (which may be the bundle's destination or may be some intermediate forwarding endpoint) in response to a transmission request issued by the node's application agent. Any number of transmissions may be concurrently undertaken by the bundle protocol agent of a given node.
传输-传输是节点的捆绑协议代理持续努力，以使捆绑发送到某个端点（可能是捆绑的目的地，也可能是某个中间转发端点）的最小接收组中的所有节点，以响应节点的应用代理发出的传输请求。任意数量的传输可由给定节点的捆绑协议代理同时进行。
Custody - To "accept custody" upon forwarding a bundle is to commit to retaining a copy of the bundle -- possibly re-forwarding the bundle when necessary -- until custody of that bundle is "released". Custody of a bundle whose destination is a singleton endpoint is released when either (a) notification is received that some other node has accepted custody of the same bundle; (b) notification is received that the bundle has been delivered at the (sole) node registered in the bundle's destination endpoint; or (c) the bundle is explicitly deleted for some reason, such as lifetime expiration. The condition(s) under which custody of a bundle whose destination is not a singleton endpoint may be released are not defined in this specification. To "refuse custody" of a bundle is to decide not to accept custody of the bundle. A "custodial node" of a bundle is a node that has accepted custody of the bundle and has not yet released that custody. A "custodian" of a bundle is a singleton endpoint whose sole member is one of the bundle's custodial nodes.
托管—在转发捆绑包时“接受托管”是指承诺保留捆绑包的副本—必要时可能会重新转发捆绑包—直到该捆绑包的托管被“释放”。当（a）接收到某个其他节点已接受同一捆绑包的托管的通知时，将释放目标为单例端点的捆绑包的托管；（b） 收到捆绑包已在捆绑包的目标端点中注册的（唯一）节点上交付的通知；或者（c）由于某些原因（如生存期到期）显式删除捆绑包。本规范中未定义目的地不是单例端点的捆绑包的托管可能被释放的条件。“拒绝保管”包裹就是决定不接受包裹的保管。捆绑包的“保管节点”是指已接受捆绑包保管但尚未释放该保管的节点。捆绑包的“保管者”是一个单例端点，其唯一成员是捆绑包的保管节点之一。
The above definitions are intended to enable the bundle protocol's operations to be specified in a manner that minimizes bias toward any particular implementation architecture. To illustrate the range of interoperable implementation models that might conform to this
上述定义旨在以最小化对任何特定实现架构的偏见的方式指定捆绑协议的操作。说明可能符合此要求的可互操作实现模型的范围
specification, four example architectures are briefly described below.
下面简要介绍四种示例体系结构。
1. Bundle protocol application server
1. 捆绑协议应用服务器
A single bundle protocol application server, constituting a single bundle node, runs as a daemon process on each computer. The daemon's functionality includes all functions of the bundle protocol agent, all convergence layer adapters, and both the administrative and application-specific elements of the application agent. The application-specific element of the application agent functions as a server, offering bundle protocol service over a local area network: it responds to remote procedure calls from application processes (on the same computer and/or remote computers) that need to communicate via the bundle protocol. The server supports its clients by creating a new (conceptual) node for each one and registering each such node in a client-specified endpoint. The conceptual nodes managed by the server function as clients' bundle protocol service access points.
构成单个bundle节点的单个bundle协议应用程序服务器在每台计算机上作为守护进程运行。守护进程的功能包括捆绑协议代理的所有功能、所有聚合层适配器以及应用程序代理的管理和特定于应用程序的元素。application agent的特定于应用程序的元素用作服务器，通过局域网提供捆绑协议服务：它响应需要通过捆绑协议通信的应用程序进程（在同一台计算机和/或远程计算机上）的远程过程调用。服务器通过为每个节点创建一个新的（概念上的）节点并在客户端指定的端点中注册每个这样的节点来支持其客户端。由服务器管理的概念节点用作客户端的捆绑协议服务访问点。
2. Peer application nodes
2. 对等应用程序节点
Any number of bundle protocol application processes, each one constituting a single bundle node, run in ad-hoc fashion on each computer. The functionality of the bundle protocol agent, all convergence layer adapters, and the administrative element of the application agent is provided by a library to which each node process is dynamically linked at run time. The application-specific element of each node's application agent is node-specific application code.
任意数量的bundle协议应用程序进程，每个进程构成一个bundle节点，在每台计算机上以即席方式运行。bundle协议代理、所有汇聚层适配器和应用程序代理的管理元素的功能由一个库提供，每个节点进程在运行时动态链接到该库。每个节点的应用程序代理的特定于应用程序的元素是特定于节点的应用程序代码。
3. Sensor network nodes
3. 传感器网络节点
Each node of the sensor network is the self-contained implementation of a single bundle node. All functions of the bundle protocol agent, all convergence layer adapters, and the administrative element of the application agent are implemented in simplified form in Application-Specific Integrated Circuits (ASICs), while the application-specific element of each node's application agent is implemented in a programmable microcontroller. Forwarding is rudimentary: all bundles are forwarded on a hard-coded default route.
传感器网络的每个节点都是单个捆绑节点的独立实现。捆绑协议代理的所有功能、所有汇聚层适配器和应用代理的管理元件以简化形式在专用集成电路（ASIC）中实现，而每个节点的应用代理的专用元件在可编程微控制器中实现。转发是最基本的：所有包都在硬编码的默认路由上转发。
4. Dedicated bundle router
4. 专用包路由器
Each computer constitutes a single bundle node that functions solely as a high-performance bundle forwarder. Many standard functions of the bundle protocol agent, the convergence layer adapters, and the administrative element of the application agent are implemented in ASICs, but some functions are implemented in a high-speed processor to enable reprogramming as necessary. The node's application agent has no application-specific element. Substantial non-volatile storage resources are provided, and arbitrarily complex forwarding algorithms are supported.
每台计算机构成一个单独的捆绑包节点，仅作为高性能捆绑包转发器。捆绑协议代理的许多标准功能、聚合层适配器和应用程序代理的管理元素都在ASIC中实现，但有些功能是在高速处理器中实现的，以便在必要时重新编程。节点的应用程序代理没有特定于应用程序的元素。提供大量非易失性存储资源，支持任意复杂的转发算法。
The bundle protocol agent of each node is expected to provide the following services to the node's application agent:
每个节点的捆绑协议代理应向节点的应用程序代理提供以下服务：
o commencing a registration (registering a node in an endpoint);
o 开始注册（在端点中注册节点）；
o terminating a registration;
o 终止注册；
o switching a registration between Active and Passive states;
o 在主动和被动状态之间切换注册；
o transmitting a bundle to an identified bundle endpoint;
o 将包发送到所识别的包端点；
o canceling a transmission;
o 取消传输；
o polling a registration that is in the passive state;
o 轮询处于被动状态的注册；
o delivering a received bundle.
o 交付收到的包。
Each bundle shall be a concatenated sequence of at least two block structures. The first block in the sequence must be a primary bundle block, and no bundle may have more than one primary bundle block. Additional bundle protocol blocks of other types may follow the primary block to support extensions to the bundle protocol, such as the Bundle Security Protocol [BSP]. At most one of the blocks in the sequence may be a payload block. The last block in the sequence must have the "last block" flag (in its block processing control flags) set to 1; for every other block in the bundle after the primary block, this flag must be set to zero.
每个线束应为至少两个块结构的串联序列。序列中的第一个块必须是主束块，并且任何束都不能有多个主束块。其他类型的附加捆绑协议块可以跟随主块，以支持对捆绑协议的扩展，例如捆绑安全协议[BSP]。序列中最多一个块可以是有效负载块。序列中的最后一个块必须将“最后一个块”标志（在其块处理控制标志中）设置为1；对于主块之后的捆绑包中的每一个其他块，该标志必须设置为零。
The design of the bundle protocol attempts to reconcile minimal consumption of transmission bandwidth with:
捆绑协议的设计试图将传输带宽的最小消耗与以下内容相协调：
o extensibility to address requirements not yet identified, and
o 可扩展性，以满足尚未确定的需求，以及
o scalability across a wide range of network scales and payload sizes.
o 跨各种网络规模和负载大小的可扩展性。
A key strategic element in the design is the use of self-delimiting numeric values (SDNVs). The SDNV encoding scheme is closely adapted from the Abstract Syntax Notation One Basic Encoding Rules for subidentifiers within an object identifier value [ASN1]. An SDNV is a numeric value encoded in N octets, the last of which has its most significant bit (MSB) set to zero; the MSB of every other octet in the SDNV must be set to 1. The value encoded in an SDNV is the unsigned binary number obtained by concatenating into a single bit string the 7 least significant bits of each octet of the SDNV.
设计中的一个关键战略要素是使用自定界数值（SDNV）。SDNV编码方案与抽象语法表示法密切相关，即对象标识符值[ASN1]内子标识符的一个基本编码规则。SDNV是以N个八位字节编码的数值，最后一个八位字节的最高有效位（MSB）设置为零；SDNV中每隔八位字节的MSB必须设置为1。SDNV中编码的值是通过将SDNV的每个八位字节的7个最低有效位串联成一个位字符串而获得的无符号二进制数。
The following examples illustrate the encoding scheme for various hexadecimal values.
以下示例说明了各种十六进制值的编码方案。
0xABC : 1010 1011 1100
is encoded as
{1 00 10101} {0 0111100}
= 10010101 00111100
0xABC : 1010 1011 1100
is encoded as
{1 00 10101} {0 0111100}
= 10010101 00111100
0x1234 : 0001 0010 0011 0100
= 1 0010 0011 0100
is encoded as
{1 0 100100} {0 0110100}
= 10100100 00110100
0x1234 : 0001 0010 0011 0100
= 1 0010 0011 0100
is encoded as
{1 0 100100} {0 0110100}
= 10100100 00110100
0x4234 : 0100 0010 0011 0100
= 100 0010 0011 0100
is encoded as
{1 000000 1} {1 0000100} {0 0110100}
= 10000001 10000100 00110100
0x4234 : 0100 0010 0011 0100
= 100 0010 0011 0100
is encoded as
{1 000000 1} {1 0000100} {0 0110100}
= 10000001 10000100 00110100
0x7F : 0111 1111 = 111 1111 is encoded as {0 1111111} = 01111111
0x7F:0111111=1111111编码为{0 1111111}=01111111
Figure 2: SDNV Example
图2:SDNV示例
Note: Care must be taken to make sure that the value to be encoded is (in concept) padded with high-order zero bits to make its bitwise length a multiple of 7 before encoding. Also note that, while there is no theoretical limit on the size of an SDNV field, the overhead of the SDNV scheme is 1:7, i.e., one bit of overhead for every 7 bits of actual data to be encoded. Thus, a 7-octet value (a 56-bit quantity with no leading zeroes) would be encoded in an 8-octet SDNV; an 8-octet value (a 64-bit quantity with no leading zeroes) would be encoded in a 10-octet SDNV (one octet containing the high-order bit of the value padded with six leading zero bits, followed by nine octets containing the remaining 63 bits of the value). 148 bits of overhead would be consumed in encoding a 1024-bit RSA encryption key directly in an SDNV. In general, an N-bit quantity with no leading zeroes is encoded in an SDNV occupying ceil(N/7) octets, where ceil is the integer ceiling function.
注意：必须注意确保要编码的值（在概念上）填充了高阶零位，以使其位长度在编码前为7的倍数。还请注意，虽然对SDNV字段的大小没有理论限制，但SDNV方案的开销是1:7，即，每7位要编码的实际数据就有一位开销。因此，7个八位组的值（没有前导零的56位量）将被编码在8个八位组的SDNV中；8个八位组的值（一个没有前导零的64位量）将被编码在一个10个八位组的SDNV中（一个八位组包含该值的高阶位，用六个前导零位填充，然后是九个八位组包含该值的其余63位）。直接在SDNV中编码1024位RSA加密密钥将消耗148位开销。通常，不带前导零的N位量编码在占据ceil（N/7）八位字节的SDNV中，其中ceil是整数上限函数。
Implementations of the bundle protocol may handle as an invalid numeric value any SDNV that encodes an integer that is larger than (2^64 - 1).
捆绑协议的实现可能会将任何编码大于（2^64-1）的整数的SDNV处理为无效数值。
An SDNV can be used to represent both very large and very small integer values. However, SDNV is clearly not the best way to represent every numeric value. For example, an SDNV is a poor way to represent an integer whose value typically falls in the range 128 to 255. In general, though, we believe that SDNV representation of numeric values in bundle blocks yields the smallest block sizes without sacrificing scalability.
SDNV可用于表示非常大和非常小的整数值。然而，SDNV显然不是表示每个数值的最佳方式。例如，SDNV是表示值通常在128到255范围内的整数的糟糕方法。但是，一般来说，我们认为捆绑块中数值的SDNV表示在不牺牲可伸缩性的情况下产生最小的块大小。
The bundle processing control flags field in the primary bundle block of each bundle is an SDNV; the value encoded in this SDNV is a string of bits used to invoke selected bundle processing control features. The significance of the value in each currently defined position of this bit string is described here. Note that in the figure and descriptions, the bit label numbers denote position (from least significant ('0') to most significant) within the decoded bit string, and not within the representation of the bits on the wire. This is why the descriptions in this section and the next do not follow standard RFC conventions with bit 0 on the left; if fields are added in the future, the SDNV will grow to the left, and using this representation allows the references here to remain valid.
每个捆绑包的主捆绑包块中的捆绑包处理控制标志字段是SDNV；此SDNV中编码的值是用于调用所选捆绑处理控制功能的一串位。此处描述了该位字符串的每个当前定义位置中的值的重要性。请注意，在图和说明中，位标签号表示解码位字符串中的位置（从最低有效（“0”）到最高有效），而不是在导线上的位表示中。这就是为什么本节和下一节中的描述不遵循左侧位为0的标准RFC约定的原因；如果将来添加字段，SDNV将向左增长，并且使用此表示允许此处的引用保持有效。
2 1 0
0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Status Report|Class of Svc.| General |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 1 0
0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Status Report|Class of Svc.| General |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Bundle Processing Control Flags Bit Layout
图3：捆绑处理控制标志位布局
The bits in positions 0 through 6 are flags that characterize the bundle as follows:
位置0到6中的位是标志，表示包的特征，如下所示：
0 -- Bundle is a fragment.
0——Bundle是一个片段。
1 -- Application data unit is an administrative record.
1--应用程序数据单元是一个管理记录。
2 -- Bundle must not be fragmented.
2--捆绑包不能被分割。
3 -- Custody transfer is requested.
3--要求移交监护权。
4 -- Destination endpoint is a singleton.
4——目标端点是单例。
5 -- Acknowledgement by application is requested.
5--申请确认。
6 -- Reserved for future use.
6--保留供将来使用。
The bits in positions 7 through 13 are used to indicate the bundle's class of service. The bits in positions 8 and 7 constitute a two-bit priority field indicating the bundle's priority, with higher values being of higher priority: 00 = bulk, 01 = normal, 10 = expedited, 11 is reserved for future use. Within this field, bit 8 is the most significant bit. The bits in positions 9 through 13 are reserved for future use.
位置7到13中的位用于指示捆绑包的服务类别。位置8和7中的位构成一个两位优先级字段，指示捆绑包的优先级，较高的值具有较高的优先级：00=批量，01=正常，10=加速，11保留供将来使用。在该字段中，位8是最高有效位。位置9到13中的位保留供将来使用。
The bits in positions 14 through 20 are status report request flags. These flags are used to request status reports as follows:
位置14到20中的位是状态报告请求标志。这些标志用于请求状态报告，如下所示：
14 -- Request reporting of bundle reception.
14——请求报告捆绑接收。
15 -- Request reporting of custody acceptance.
15——请求报告托管验收。
16 -- Request reporting of bundle forwarding.
16——包转发的请求报告。
17 -- Request reporting of bundle delivery.
17——请求报告捆绑交付。
18 -- Request reporting of bundle deletion.
18——请求报告捆绑删除。
19 -- Reserved for future use.
19--保留供将来使用。
20 -- Reserved for future use.
20--保留供将来使用。
If the bundle processing control flags indicate that the bundle's application data unit is an administrative record, then the custody transfer requested flag must be zero and all status report request flags must be zero. If the custody transfer requested flag is 1, then the sending node requests that the receiving node accept custody of the bundle. If the bundle's source endpoint ID is "dtn:none" (see below), then the bundle is not uniquely identifiable and all bundle protocol features that rely on bundle identity must therefore be disabled: the bundle's custody transfer requested flag must be zero, the "Bundle must not be fragmented" flag must be 1, and all status report request flags must be zero.
如果捆绑处理控制标志指示捆绑的应用程序数据单元是管理记录，则托管转移请求标志必须为零，所有状态报告请求标志必须为零。如果托管传输请求标志为1，则发送节点请求接收节点接受捆绑的托管。如果捆绑包的源端点ID为“dtn:none”（见下文），则捆绑包不是唯一可识别的，因此必须禁用依赖捆绑包标识的所有捆绑包协议功能：捆绑包的托管传输请求标志必须为零，“捆绑包不得分段”标志必须为1，并且所有状态报告请求标志必须为零。
The block processing control flags field in every block other than the primary bundle block is an SDNV; the value encoded in this SDNV is a string of bits used to invoke selected block processing control features. The significance of the values in all currently defined positions of this bit string, in order from least significant position in the decoded bit string (labeled '0') to most significant (labeled '6'), is described here.
除主束块之外的每个块中的块处理控制标志字段是SDNV；此SDNV中编码的值是用于调用选定块处理控制功能的一串位。这里描述了该位串的所有当前定义位置中的值的重要性，顺序是从解码位串中的最低有效位置（标记为“0”）到最高有效位置（标记为“6”）。
0
6 5 4 3 2 1 0
+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+
0
6 5 4 3 2 1 0
+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+
Figure 4: Block Processing Control Flags Bit Layout
图4：块处理控制标志位布局
0 - Block must be replicated in every fragment.
0-必须在每个片段中复制块。
1 - Transmit status report if block can't be processed.
1-如果无法处理块，则发送状态报告。
2 - Delete bundle if block can't be processed.
2-如果无法处理块，则删除捆绑包。
3 - Last block.
3-最后一个街区。
4 - Discard block if it can't be processed.
4-如果无法处理，则丢弃块。
5 - Block was forwarded without being processed.
5-未经处理就转发了块。
6 - Block contains an EID-reference field.
6-块包含EID参考字段。
For each bundle whose primary block's bundle processing control flags (see above) indicate that the bundle's application data unit is an administrative record, the "Transmit status report if block can't be processed" flag in the block processing flags field of every other block in the bundle must be zero.
对于其主块的捆绑处理控制标志（见上文）指示捆绑的应用程序数据单元为管理记录的每个捆绑，捆绑中其他每个块的块处理标志字段中的“如果无法处理块，则传输状态报告”标志必须为零。
The 'Block must be replicated in every fragment' bit in the block processing flags must be set to zero on all blocks that follow the payload block.
块处理标志中的“块必须在每个片段中复制”位必须在有效负载块之后的所有块上设置为零。
The destinations of bundles are bundle endpoints, identified by text strings termed "endpoint IDs" (see Section 3.1). Each endpoint ID conveyed in any bundle block takes the form of a Uniform Resource Identifier (URI; [URI]). As such, each endpoint ID can be characterized as having this general structure:
捆绑包的目的地是捆绑包端点，由称为“端点ID”的文本字符串标识（参见第3.1节）。任何包块中传递的每个端点ID都采用统一资源标识符（URI；[URI]）的形式。因此，每个端点ID可以被描述为具有以下一般结构：
< scheme name > : < scheme-specific part, or "SSP" >
< scheme name > : < scheme-specific part, or "SSP" >
As used for the purposes of the bundle protocol, neither the length of a scheme name nor the length of an SSP may exceed 1023 bytes.
就捆绑协议而言，方案名称的长度和SSP的长度均不得超过1023字节。
Bundle blocks cite a number of endpoint IDs for various purposes of the bundle protocol. Many, though not necessarily all, of the endpoint IDs referred to in the blocks of a given bundle are conveyed in the "dictionary" byte array in the bundle's primary block. This array is simply the concatenation of any number of null-terminated scheme names and SSPs.
Bundle块引用了许多端点ID，用于Bundle协议的各种用途。给定包的块中引用的许多端点ID（尽管不一定全部）在包的主块中的“字典”字节数组中传输。该数组只是任意数量的以null结尾的方案名称和SSP的串联。
"Endpoint ID references" are used to cite endpoint IDs that are contained in the dictionary; all endpoint ID citations in the primary bundle block are endpoint ID references, and other bundle blocks may contain endpoint ID references as well. Each endpoint ID reference is an ordered pair of SDNVs:
“端点ID引用”用于引用字典中包含的端点ID；主捆绑包块中的所有端点ID引用都是端点ID引用，其他捆绑包块也可能包含端点ID引用。每个端点ID引用都是一对有序的SDNV：
o The first SDNV contains the offset within the dictionary of the first character of the referenced endpoint ID's scheme name.
o 第一个SDNV包含被引用端点ID的方案名称的第一个字符在字典中的偏移量。
o The second SDNV contains the offset within the dictionary of the first character of the referenced endpoint ID's SSP.
o 第二个SDNV包含被引用端点ID的SSP的第一个字符在字典中的偏移量。
This encoding enables a degree of block compression: when the source and report-to of a bundle are the same endpoint, for example, the text of that endpoint's ID may be cited twice yet appear only once in the dictionary.
这种编码可以实现一定程度的块压缩：例如，当捆绑包的源和报告对象是同一个端点时，该端点ID的文本可能被引用两次，但在字典中只出现一次。
The scheme identified by the < scheme name > in an endpoint ID is a set of syntactic and semantic rules that fully explain how to parse and interpret the SSP. The set of allowable schemes is effectively unlimited. Any scheme conforming to [URIREG] may be used in a bundle protocol endpoint ID. In addition, a single additional scheme is defined by the present document:
端点ID中由<scheme name>标识的方案是一组语法和语义规则，完全解释了如何解析和解释SSP。允许的方案集实际上是无限的。符合[URIREG]的任何方案均可用于捆绑协议端点ID。此外，本文件还定义了一个附加方案：
o The "dtn" scheme, which is used at minimum in the representation of the null endpoint ID "dtn:none". The forwarding of a bundle to the null endpoint is never contraindicated, and the minimum reception group for the null endpoint is the empty set.
o “dtn”方案，至少用于表示空端点ID“dtn:none”。将包转发到空端点从来都不是禁忌，空端点的最小接收组是空集。
Note that, although the endpoint IDs conveyed in bundle blocks are expressed as URIs, implementations of the BP service interface may support expression of endpoint IDs in some internationalized manner (e.g., Internationalized Resource Identifiers (IRIs); see [RFC3987]).
请注意，尽管捆绑块中传输的端点ID表示为URI，但BP服务接口的实现可能支持以某种国际化方式表达端点ID（例如，国际化资源标识符（IRI）；请参阅[RFC3987]）。
This section describes the formats of the primary block and payload block. Rules for processing these blocks appear in Section 5 of this document.
本节介绍主块和有效负载块的格式。处理这些块的规则见本文件第5节。
Note that supplementary DTN protocol specifications (including, but not restricted to, the Bundle Security Protocol [BSP]) may require that BP implementations conforming to those protocols construct and process additional blocks.
注意，补充DTN协议规范（包括但不限于捆绑安全协议[BSP]）可能要求符合这些协议的BP实现构造和处理附加块。
The format of the two basic BP blocks is shown in Figure 5 below.
两个基本BP块的格式如下图5所示。
Primary Bundle Block
+----------------+----------------+----------------+----------------+
| Version | Proc. Flags (*) |
+----------------+----------------+----------------+----------------+
| Block length (*) |
+----------------+----------------+---------------------------------+
| Destination scheme offset (*) | Destination SSP offset (*) |
+----------------+----------------+----------------+----------------+
| Source scheme offset (*) | Source SSP offset (*) |
+----------------+----------------+----------------+----------------+
| Report-to scheme offset (*) | Report-to SSP offset (*) |
+----------------+----------------+----------------+----------------+
| Custodian scheme offset (*) | Custodian SSP offset (*) |
+----------------+----------------+----------------+----------------+
| Creation Timestamp time (*) |
+---------------------------------+---------------------------------+
| Creation Timestamp sequence number (*) |
+---------------------------------+---------------------------------+
| Lifetime (*) |
+----------------+----------------+----------------+----------------+
| Dictionary length (*) |
+----------------+----------------+----------------+----------------+
| Dictionary byte array (variable) |
+----------------+----------------+---------------------------------+
| [Fragment offset (*)] |
+----------------+----------------+---------------------------------+
| [Total application data unit length (*)] |
+----------------+----------------+---------------------------------+
Primary Bundle Block
+----------------+----------------+----------------+----------------+
| Version | Proc. Flags (*) |
+----------------+----------------+----------------+----------------+
| Block length (*) |
+----------------+----------------+---------------------------------+
| Destination scheme offset (*) | Destination SSP offset (*) |
+----------------+----------------+----------------+----------------+
| Source scheme offset (*) | Source SSP offset (*) |
+----------------+----------------+----------------+----------------+
| Report-to scheme offset (*) | Report-to SSP offset (*) |
+----------------+----------------+----------------+----------------+
| Custodian scheme offset (*) | Custodian SSP offset (*) |
+----------------+----------------+----------------+----------------+
| Creation Timestamp time (*) |
+---------------------------------+---------------------------------+
| Creation Timestamp sequence number (*) |
+---------------------------------+---------------------------------+
| Lifetime (*) |
+----------------+----------------+----------------+----------------+
| Dictionary length (*) |
+----------------+----------------+----------------+----------------+
| Dictionary byte array (variable) |
+----------------+----------------+---------------------------------+
| [Fragment offset (*)] |
+----------------+----------------+---------------------------------+
| [Total application data unit length (*)] |
+----------------+----------------+---------------------------------+
Bundle Payload Block
+----------------+----------------+----------------+----------------+
| Block type | Proc. Flags (*)| Block length(*) |
+----------------+----------------+----------------+----------------+
/ Bundle Payload (variable) /
+-------------------------------------------------------------------+
Bundle Payload Block
+----------------+----------------+----------------+----------------+
| Block type | Proc. Flags (*)| Block length(*) |
+----------------+----------------+----------------+----------------+
/ Bundle Payload (variable) /
+-------------------------------------------------------------------+
Figure 5: Bundle Block Formats
图5：束块格式
(*) Notes:
（*）注：
The bundle processing control ("Proc.") flags field in the Primary Bundle Block is an SDNV and is therefore variable length. A three-octet SDNV is shown here for convenience in representation.
主bundle块中的bundle processing control（“Proc.”）flags字段是SDNV，因此长度可变。为了便于表示，此处显示了三个八位组的SDNV。
The block length field of the Primary Bundle Block is an SDNV and is therefore variable length. A four-octet SDNV is shown here for convenience in representation.
主束块的块长度字段是SDNV，因此长度可变。为了便于表示，此处显示了四个八位组的SDNV。
Each of the eight offset fields in the Primary Bundle Block is an SDNV and is therefore variable length. Two-octet SDNVs are shown here for convenience in representation.
主束块中的八个偏移字段都是SDNV，因此长度可变。为了便于表示，此处显示了两个八位组SDNV。
The Creation Timestamp time field in the Primary Bundle Block is an SDNV and is therefore variable length. A four-octet SDNV is shown here for convenience in representation.
主束块中的创建时间戳时间字段是SDNV，因此长度可变。为了便于表示，此处显示了四个八位组的SDNV。
The Creation Timestamp sequence number field in the Primary Bundle Block is an SDNV and is therefore variable length. A four-octet SDNV is shown here for convenience in representation.
主束块中的创建时间戳序列号字段是SDNV，因此长度可变。为了便于表示，此处显示了四个八位组的SDNV。
The Lifetime field in the Primary Bundle Block is an SDNV and is therefore variable length. A four-octet SDNV is shown here for convenience in representation.
主束块中的生存期字段是SDNV，因此长度可变。为了便于表示，此处显示了四个八位组的SDNV。
The dictionary length field of the Primary Bundle Block is an SDNV and is therefore variable length. A four-octet SDNV is shown here for convenience in representation.
主束块的字典长度字段是SDNV，因此长度可变。为了便于表示，此处显示了四个八位组的SDNV。
The fragment offset field of the Primary Bundle Block is present only if the Fragment flag in the block's processing flags byte is set to 1. It is an SDNV and is therefore variable length; a four-octet SDNV is shown here for convenience in representation.
仅当块的处理标志字节中的碎片标志设置为1时，主束块的碎片偏移字段才会出现。它是SDNV，因此长度可变；为了便于表示，此处显示了四个八位组的SDNV。
The total application data unit length field of the Primary Bundle Block is present only if the Fragment flag in the block's processing flags byte is set to 1. It is an SDNV and is therefore variable length; a four-octet SDNV is shown here for convenience in representation.
仅当主捆绑包块的处理标志字节中的片段标志设置为1时，主捆绑包块的应用程序数据单元总长度字段才会出现。它是SDNV，因此长度可变；为了便于表示，此处显示了四个八位组的SDNV。
The block processing control ("Proc.") flags field of the Payload Block is an SDNV and is therefore variable length. A one-octet SDNV is shown here for convenience in representation.
有效负载块的块处理控制（“Proc”）标志字段是SDNV，因此长度可变。为了便于表示，此处显示了一个八位组SDNV。
The block length field of the Payload Block is an SDNV and is therefore variable length. A two-octet SDNV is shown here for convenience in representation.
有效负载块的块长度字段是SDNV，因此长度可变。为了便于表示，此处显示了两个八位组的SDNV。
The primary bundle block contains the basic information needed to route bundles to their destinations. The fields of the primary bundle block are:
主捆绑包块包含将捆绑包路由到其目的地所需的基本信息。主束块的字段包括：
Version: A 1-byte field indicating the version of the bundle protocol that constructed this block. The present document describes version 0x06 of the bundle protocol.
版本：一个1字节的字段，指示构成此块的捆绑协议的版本。本文档描述捆绑协议的版本0x06。
Bundle Processing Control Flags: The Bundle Processing Control Flags field is an SDNV that contains the bundle processing control flags discussed in Section 4.2 above.
捆绑处理控制标志：捆绑处理控制标志字段是一个SDNV，其中包含上文第4.2节中讨论的捆绑处理控制标志。
Block Length: The Block Length field is an SDNV that contains the aggregate length of all remaining fields of the block.
块长度：块长度字段是一个SDNV，包含块的所有剩余字段的聚合长度。
Destination Scheme Offset: The Destination Scheme Offset field contains the offset within the dictionary byte array of the scheme name of the endpoint ID of the bundle's destination, i.e., the endpoint containing the node(s) at which the bundle is to be delivered.
目标方案偏移量：目标方案偏移量字段包含捆绑目标的端点ID的方案名称的字典字节数组中的偏移量，即包含捆绑将在其中传递的节点的端点。
Destination SSP Offset: The Destination SSP Offset field contains the offset within the dictionary byte array of the scheme-specific part of the endpoint ID of the bundle's destination.
Destination SSP Offset（目标SSP偏移量）：Destination SSP Offset（目标SSP偏移量）字段包含绑定目标的端点ID的方案特定部分的字典字节数组中的偏移量。
Source Scheme Offset: The Source Scheme Offset field contains the offset within the dictionary byte array of the scheme name of the endpoint ID of the bundle's nominal source, i.e., the endpoint nominally containing the node from which the bundle was initially transmitted.
Source Scheme Offset（源方案偏移量）：Source Scheme Offset（源方案偏移量）字段包含捆绑包的标称源的端点ID的方案名称的字典字节数组中的偏移量，即名义上包含捆绑包最初从中传输的节点的端点。
Source SSP Offset: The Source SSP Offset field contains the offset within the dictionary byte array of the scheme-specific part of the endpoint ID of the bundle's nominal source.
Source SSP Offset（源SSP偏移量）：Source SSP Offset（源SSP偏移量）字段包含绑定的标称源的端点ID的特定于方案的部分的字典字节数组中的偏移量。
Report-to Scheme Offset: The Report-to Scheme Offset field contains the offset within the dictionary byte array of the scheme name of the ID of the endpoint to which status reports pertaining to the forwarding and delivery of this bundle are to be transmitted.
报告到方案偏移量：报告到方案偏移量字段包含方案名称的字典字节数组中的偏移量，该方案名称是要将与此捆绑包的转发和传递相关的状态报告传输到的端点的ID。
Report-to SSP Offset: The Report-to SSP Offset field contains the offset within the dictionary byte array of the scheme-specific part of the ID of the endpoint to which status reports pertaining to the forwarding and delivery of this bundle are to be transmitted.
Report to SSP Offset（向SSP报告偏移量）：Report to SSP Offset（向SSP报告偏移量）字段包含端点ID中特定于方案的部分的字典字节数组中的偏移量，与此捆绑包的转发和传递相关的状态报告将被传输到该端点。
Custodian Scheme Offset: The "current custodian endpoint ID" of a primary bundle block identifies an endpoint whose membership includes the node that most recently accepted custody of the bundle upon forwarding this bundle. The Custodian Scheme Offset field contains the offset within the dictionary byte array of the scheme name of the current custodian endpoint ID.
保管人方案偏移：主捆绑包块的“当前保管人端点ID”标识其成员资格包括最近在转发此捆绑包时接受捆绑包保管的节点的端点。保管人方案偏移量字段包含当前保管人端点ID的方案名称字典字节数组中的偏移量。
Custodian SSP Offset: The Custodian SSP Offset field contains the offset within the dictionary byte array of the scheme-specific part of the current custodian endpoint ID.
保管人SSP偏移量：保管人SSP偏移量字段包含当前保管人端点ID的方案特定部分的字典字节数组中的偏移量。
Creation Timestamp: The creation timestamp is a pair of SDNVs that, together with the source endpoint ID and (if the bundle is a fragment) the fragment offset and payload length, serve to identify the bundle. The first SDNV of the timestamp is the bundle's creation time, while the second is the bundle's creation timestamp sequence number. Bundle creation time is the time -- expressed in seconds since the start of the year 2000, on the Coordinated Universal Time (UTC) scale [UTC] -- at which the transmission request was received that resulted in the creation of the bundle. Sequence count is the latest value (as of the time at which that transmission request was received) of a monotonically increasing positive integer counter managed by the source node's bundle protocol agent that may be reset to zero whenever the current time advances by one second. A source Bundle Protocol Agent must never create two distinct bundles with the same source endpoint ID and bundle creation timestamp. The combination of source endpoint ID and bundle creation timestamp therefore serves to identify a single transmission request, enabling it to be acknowledged by the receiving application (provided the source endpoint ID is not "dtn:none").
创建时间戳：创建时间戳是一对SDNV，与源端点ID和（如果捆绑包是碎片）碎片偏移量和有效负载长度一起用于标识捆绑包。时间戳的第一个SDNV是捆绑包的创建时间，而第二个SDNV是捆绑包的创建时间戳序列号。捆绑包创建时间是指从2000年开始，在协调世界时（UTC）标度[UTC]上以秒为单位表示的时间，在该时间接收到导致捆绑包创建的传输请求。Sequence count是由源节点的捆绑协议代理管理的单调递增正整数计数器的最新值（截至接收该传输请求的时间），该计数器可在当前时间提前1秒时重置为零。源捆绑协议代理决不能创建具有相同源端点ID和捆绑创建时间戳的两个不同捆绑。因此，源端点ID和捆绑包创建时间戳的组合用于标识单个传输请求，从而使接收应用程序能够确认该请求（前提是源端点ID不是“dtn:none”）。
Lifetime: The lifetime field is an SDNV that indicates the time at which the bundle's payload will no longer be useful, encoded as a number of seconds past the creation time. When the current time is greater than the creation time plus the lifetime, bundle nodes need no longer retain or forward the bundle; the bundle may be deleted from the network.
生存期：生存期字段是一个SDNV，表示捆绑包的有效负载不再有用的时间，编码为创建时间后的秒数。当当前时间大于创建时间加上生存期时，包节点不再需要保留或转发包；可以从网络中删除该捆绑包。
Dictionary Length: The Dictionary Length field is an SDNV that contains the length of the dictionary byte array.
字典长度：字典长度字段是包含字典字节数组长度的SDNV。
Dictionary: The Dictionary field is an array of bytes formed by concatenating the null-terminated scheme names and SSPs of all endpoint IDs referenced by any fields in this Primary Block together with, potentially, other endpoint IDs referenced by fields in other TBD DTN protocol blocks. Its length is given by the value of the Dictionary Length field.
字典：字典字段是一个字节数组，通过将此主块中任何字段引用的所有端点ID的以null结尾的方案名称和SSP与其他TBD DTN协议块中的字段引用的其他端点ID连接起来而形成。其长度由Dictionary length字段的值给出。
Fragment Offset: If the Bundle Processing Control Flags of this Primary block indicate that the bundle is a fragment, then the Fragment Offset field is an SDNV indicating the offset from the start of the original application data unit at which the bytes comprising the payload of this bundle were located. If not, then the Fragment Offset field is omitted from the block.
片段偏移：如果此主块的捆绑处理控制标志指示捆绑是一个片段，则碎片偏移字段是一个SDNV，指示从原始应用程序数据单元开始的偏移量，其中包含此捆绑负载的字节位于该单元。如果不是，则从块中省略片段偏移字段。
Total Application Data Unit Length: If the Bundle Processing Control Flags of this Primary block indicate that the bundle is a fragment, then the Total Application Data Unit Length field is an SDNV indicating the total length of the original application data unit of which this bundle's payload is a part. If not, then the Total Application Data Unit Length field is omitted from the block.
总应用程序数据单元长度：如果此主块的捆绑包处理控制标志指示捆绑包是一个片段，则“总应用程序数据单元长度”字段是一个SDNV，指示原始应用程序数据单元的总长度，该捆绑包的有效负载是其一部分。如果不是，则从块中省略“应用程序数据单位总长度”字段。
Every bundle block of every type other than the primary bundle block comprises the following fields, in this order:
除主捆绑包块之外的每种类型的每个捆绑包块都按以下顺序包含以下字段：
o Block type code, expressed as an 8-bit unsigned binary integer. Bundle block type code 1 indicates that the block is a bundle payload block. Block type codes 192 through 255 are not defined in this specification and are available for private and/or experimental use. All other values of the block type code are reserved for future use.
o 块类型代码，表示为8位无符号二进制整数。捆绑包块类型代码1表示该块是捆绑包有效负载块。本规范中未定义块类型代码192至255，可供私人和/或实验使用。块类型代码的所有其他值保留供将来使用。
o Block processing control flags, an unsigned integer expressed as an SDNV. The individual bits of this integer are used to invoke selected block processing control features.
o 块处理控制标志，表示为SDNV的无符号整数。此整数的各个位用于调用选定的块处理控制功能。
o Block EID reference count and EID references (optional). If and only if the block references EID elements in the primary block's dictionary, the 'block contains an EID-reference field' flag in the block processing control flags is set to 1 and the block includes an EID reference field consisting of a count of EID references expressed as an SDNV followed by the EID references themselves. Each EID reference is a pair of SDNVs. The first SDNV of each EID reference contains the offset of a scheme name in the primary block's dictionary, and the second SDNV of each reference contains the offset of a scheme-specific part in the dictionary.
o 块EID引用计数和EID引用（可选）。当且仅当块引用主块字典中的EID元素时，块处理控制标志中的“块包含EID引用字段”标志设置为1，并且块包含EID引用字段，该字段由EID引用计数组成，EID引用表示为SDNV，后跟EID引用本身。每个EID引用是一对SDNV。每个EID引用的第一个SDNV包含主块字典中方案名称的偏移量，每个引用的第二个SDNV包含字典中方案特定部分的偏移量。
o Block data length, an unsigned integer expressed as an SDNV. The Block data length field contains the aggregate length of all remaining fields of the block, i.e., the block-type-specific data fields.
o 块数据长度，表示为SDNV的无符号整数。块数据长度字段包含块的所有剩余字段的聚合长度，即块类型特定的数据字段。
o Block-type-specific data fields, whose format and order are type-specific and whose aggregate length in octets is the value of the block data length field. All multi-byte block-type-specific data fields are represented in network byte order.
o 块类型特定的数据字段，其格式和顺序特定于类型，其聚合长度（以八位字节为单位）是块数据长度字段的值。所有多字节块类型特定的数据字段都以网络字节顺序表示。
+-----------+-----------+-----------+-----------+
|Block type | Block processing ctrl flags (SDNV)|
+-----------+-----------+-----------+-----------+
| Block length (SDNV) |
+-----------+-----------+-----------+-----------+
/ Block body data (variable) /
+-----------+-----------+-----------+-----------+
+-----------+-----------+-----------+-----------+
|Block type | Block processing ctrl flags (SDNV)|
+-----------+-----------+-----------+-----------+
| Block length (SDNV) |
+-----------+-----------+-----------+-----------+
/ Block body data (variable) /
+-----------+-----------+-----------+-----------+
Figure 6: Block Layout without EID Reference List
图6：不带EID参考列表的块布局
+-----------+-----------+-----------+-----------+
|Block Type | Block processing ctrl flags (SDNV)|
+-----------+-----------+-----------+-----------+
| EID Reference Count (SDNV) |
+-----------+-----------+-----------+-----------+
| Ref_scheme_1 (SDNV) | Ref_ssp_1 (SDNV) |
+-----------+-----------+-----------+-----------+
| Ref_scheme_2 (SDNV) | Ref_ssp_2 (SDNV) |
+-----------+-----------+-----------+-----------+
| Block length (SDNV) |
+-----------+-----------+-----------+-----------+
/ Block body data (variable) /
+-----------+-----------+-----------+-----------+
+-----------+-----------+-----------+-----------+
|Block Type | Block processing ctrl flags (SDNV)|
+-----------+-----------+-----------+-----------+
| EID Reference Count (SDNV) |
+-----------+-----------+-----------+-----------+
| Ref_scheme_1 (SDNV) | Ref_ssp_1 (SDNV) |
+-----------+-----------+-----------+-----------+
| Ref_scheme_2 (SDNV) | Ref_ssp_2 (SDNV) |
+-----------+-----------+-----------+-----------+
| Block length (SDNV) |
+-----------+-----------+-----------+-----------+
/ Block body data (variable) /
+-----------+-----------+-----------+-----------+
Figure 7: Block Layout Showing Two EID References
图7：显示两个EID引用的块布局
The fields of the bundle payload block are:
捆绑负载块的字段包括：
Block Type: The Block Type field is a 1-byte field that indicates the type of the block. For the bundle payload block, this field contains the value 1.
块类型：块类型字段是指示块类型的1字节字段。对于捆绑负载块，此字段包含值1。
Block Processing Control Flags: The Block Processing Control Flags field is an SDNV that contains the block processing control flags discussed in Section 4.3 above.
块处理控制标志：块处理控制标志字段是一个SDNV，其中包含上文第4.3节中讨论的块处理控制标志。
Block Length: The Block Length field is an SDNV that contains the aggregate length of all remaining fields of the block - which is to say, the length of the bundle's payload.
块长度：块长度字段是一个SDNV，它包含块的所有剩余字段的聚合长度，也就是说，包的有效负载的长度。
Payload: The Payload field contains the application data carried by this bundle.
有效载荷：有效载荷字段包含此捆绑包携带的应用程序数据。
That is, bundle payload blocks follow the canonical format of the previous section with the restriction that the 'block contains an
也就是说，bundle有效负载块遵循上一节的规范格式，限制为“块包含
EID-reference field' bit of the block processing control flags is never set. The block body data for payload blocks is the application data carried by the bundle.
块处理控制标志的EID参考字段位从未设置。有效负载块的块体数据是捆绑包携带的应用程序数据。
"Extension blocks" are all blocks other than the primary and payload blocks. Because extension blocks are not defined in the Bundle Protocol specification (the present document), not all nodes conforming to this specification will necessarily instantiate Bundle Protocol implementations that include procedures for processing (that is, recognizing, parsing, acting on, and/or producing) all extension blocks. It is therefore possible for a node to receive a bundle that includes extension blocks that the node cannot process.
“扩展块”是除主块和有效负载块以外的所有块。由于捆绑协议规范（本文档）中未定义扩展块，因此并非所有符合本规范的节点都必须实例化捆绑协议实现，其中包括处理（即，识别、解析、作用和/或生成）所有扩展块的过程。因此，节点可以接收包含节点无法处理的扩展块的捆绑包。
Whenever a bundle is forwarded that contains one or more extension blocks that could not be processed, the "Block was forwarded without being processed" flag must be set to 1 within the block processing flags of each such block. For each block flagged in this way, the flag may optionally be cleared (i.e., set to zero) by another node that subsequently receives the bundle and is able to process that block; the specifications defining the various extension blocks are expected to define the circumstances under which this flag may be cleared, if any.
每当转发包含一个或多个无法处理的扩展块的捆绑包时，必须在每个此类块的块处理标志内将“未经处理的块已转发”标志设置为1。对于以这种方式标记的每个块，该标记可选择性地由随后接收捆绑并能够处理该块的另一节点清除（即，设置为零）；定义各种扩展块的规范预计将定义清除此标志的情况（如果有）。
Any strings (scheme names and SSPs) in a bundle's dictionary that are referenced neither from the bundle's primary block nor from the block EID reference field of any extension block may be removed from the dictionary at the time the bundle is forwarded.
在包转发时，可以从字典中删除包字典中既不从包的主块引用也不从任何扩展块的块EID引用字段引用的任何字符串（方案名称和SSP）。
Whenever removal of a string from the dictionary causes the offsets (within the dictionary byte array) of any other strings to change, all endpoint ID references that refer to those strings must be adjusted at the same time. Note that these references may be in the primary block and/or in the block EID reference fields of extension blocks.
每当从字典中删除字符串导致任何其他字符串的偏移量（在字典字节数组中）发生更改时，必须同时调整引用这些字符串的所有端点ID引用。注意，这些引用可能位于主块和/或扩展块的块EID引用字段中。
The bundle processing procedures mandated in this section and in Section 6 govern the operation of the Bundle Protocol Agent and the Application Agent administrative element of each bundle node. They are neither exhaustive nor exclusive. That is, supplementary DTN protocol specifications (including, but not restricted to, the Bundle Security Protocol [BSP]) may require that additional measures be taken at specified junctures in these procedures. Such additional
本节和第6节中规定的捆绑包处理过程控制每个捆绑包节点的捆绑包协议代理和应用程序代理管理元素的操作。它们既不是详尽的，也不是排他性的。也就是说，补充DTN协议规范（包括但不限于捆绑安全协议[BSP]）可能要求在这些过程中的指定节点采取额外措施。这种额外的
measures shall not override or supersede the mandated bundle protocol procedures, except that they may in some cases make these procedures moot by requiring, for example, that implementations conforming to the supplementary protocol terminate the processing of a given incoming or outgoing bundle due to a fault condition recognized by that protocol.
措施不应凌驾或取代强制性捆绑协议程序，除非在某些情况下，这些措施可能通过要求（例如，符合补充协议的实现由于该协议识别的故障条件而终止对给定传入或传出包的处理。
All initial transmission of bundles is in response to bundle transmission requests presented by nodes' application agents. When required to "generate" an administrative record (a bundle status report or a custody signal), the bundle protocol agent itself is responsible for causing a new bundle to be transmitted, conveying that record. In concept, the bundle protocol agent discharges this responsibility by directing the administrative element of the node's application agent to construct the record and request its transmission as detailed in Section 6 below. In practice, the manner in which administrative record generation is accomplished is an implementation matter, provided the constraints noted in Section 6 are observed.
捆绑包的所有初始传输都响应于节点的应用程序代理提出的捆绑包传输请求。当需要“生成”管理记录（捆绑包状态报告或托管信号）时，捆绑包协议代理本身负责发送新的捆绑包，并传递该记录。从概念上讲，bundle协议代理通过指示节点的应用程序代理的管理元素构造记录并请求其传输来履行这一职责，详见下文第6节。在实践中，如果遵守第6节中提到的约束条件，完成管理记录生成的方式是一个实施问题。
Under some circumstances, the requesting of status reports could result in an unacceptable increase in the bundle traffic in the network. For this reason, the generation of status reports is mandatory only in one case, the deletion of a bundle for which custody transfer is requested. In all other cases, the decision on whether or not to generate a requested status report is left to the discretion of the bundle protocol agent. Mechanisms that could assist in making such decisions, such as pre-placed agreements authorizing the generation of status reports under specified circumstances, are beyond the scope of this specification.
在某些情况下，请求状态报告可能会导致网络中捆绑通信量的不可接受的增加。因此，只有在一种情况下，必须生成状态报告，即删除请求托管转移的捆绑包。在所有其他情况下，是否生成请求的状态报告的决定由捆绑协议代理自行决定。可能有助于作出此类决定的机制，例如授权在特定情况下生成状态报告的预先安排的协议，超出了本规范的范围。
Notes on administrative record terminology:
关于行政记录术语的说明：
o A "bundle reception status report" is a bundle status report with the "reporting node received bundle" flag set to 1.
o “捆绑接收状态报告”是一种捆绑状态报告，其“reporting node received bundle”标志设置为1。
o A "custody acceptance status report" is a bundle status report with the "reporting node accepted custody of bundle" flag set to 1.
o “托管接受状态报告”是一种捆绑状态报告，“报告节点接受捆绑托管”标志设置为1。
o A "bundle forwarding status report" is a bundle status report with the "reporting node forwarded the bundle" flag set to 1.
o “捆绑包转发状态报告”是一种捆绑包状态报告，其“reporting node forwarded the bundle”标志设置为1。
o A "bundle delivery status report" is a bundle status report with the "reporting node delivered the bundle" flag set to 1.
o “捆绑交付状态报告”是一种捆绑状态报告，“报告节点已交付捆绑”标志设置为1。
o A "bundle deletion status report" is a bundle status report with the "reporting node deleted the bundle" flag set to 1.
o “捆绑包删除状态报告”是“报告节点已删除捆绑包”标志设置为1的捆绑包状态报告。
o A "Succeeded" custody signal is a custody signal with the "custody transfer succeeded" flag set to 1.
o “成功”监护信号是“监护转移成功”标志设置为1的监护信号。
o A "Failed" custody signal is a custody signal with the "custody transfer succeeded" flag set to zero.
o “失败”监护信号是“监护转移成功”标志设置为零的监护信号。
o The "current custodian" of a bundle is the endpoint identified by the current custodian endpoint ID in the bundle's primary block.
o 捆绑包的“当前保管人”是由捆绑包主块中的当前保管人端点ID标识的端点。
The steps in processing a bundle transmission request are:
处理捆绑传输请求的步骤包括：
Step 1: If custody transfer is requested for this bundle transmission and, moreover, custody acceptance by the source node is required, then either the bundle protocol agent must commit to accepting custody of the bundle -- in which case processing proceeds from Step 2 -- or the request cannot be honored and all remaining steps of this procedure must be skipped. The bundle protocol agent must not commit to accepting custody of a bundle if the conditions under which custody of the bundle may be accepted are not satisfied. The conditions under which a node may accept custody of a bundle whose destination is not a singleton endpoint are not defined in this specification.
步骤1：如果此捆绑传输请求托管转移，并且需要源节点接受托管，然后，bundle协议代理必须承诺接受bundle的托管（在这种情况下，处理从步骤2开始），或者请求不能被接受，并且必须跳过此过程的所有剩余步骤。如果不满足可接受捆绑包保管的条件，则捆绑包协议代理不得承诺接受捆绑包保管。本规范中未定义节点可以接受目的地不是单例端点的捆绑包托管的条件。
Step 2: Transmission of the bundle is initiated. An outbound bundle must be created per the parameters of the bundle transmission request, with current custodian endpoint ID set to the null endpoint ID "dtn:none" and with the retention constraint "Dispatch pending". The source endpoint ID of the bundle must be either the ID of an endpoint of which the node is a member or the null endpoint ID "dtn:none".
步骤2：启动包的传输。必须根据捆绑传输请求的参数创建出站捆绑，当前托管端点ID设置为空端点ID“dtn:none”，保留约束为“Dispatch pending”。捆绑包的源终结点ID必须是节点所属的终结点的ID或空终结点ID“dtn:none”。
Step 3: Processing proceeds from Step 1 of Section 5.4.
步骤3：处理从第5.4节的步骤1开始。
The steps in dispatching a bundle are:
分发捆绑包的步骤包括：
Step 1: If the bundle's destination endpoint is an endpoint of which the node is a member, the bundle delivery procedure defined in Section 5.7 must be followed.
步骤1：如果捆绑的目标端点是节点为其成员的端点，则必须遵循第5.7节中定义的捆绑交付过程。
Step 2: Processing proceeds from Step 1 of Section 5.4.
步骤2：处理从第5.4节的步骤1开始。
The steps in forwarding a bundle are:
转发捆绑包的步骤包括：
Step 1: The retention constraint "Forward pending" must be added to the bundle, and the bundle's "Dispatch pending" retention constraint must be removed.
步骤1：必须将保留约束“转发挂起”添加到捆绑包中，并且必须删除捆绑包的“分派挂起”保留约束。
Step 2: The bundle protocol agent must determine whether or not forwarding is contraindicated for any of the reasons listed in Figure 12. In particular:
步骤2：bundle协议代理必须确定是否出于图12中列出的任何原因禁止转发。特别地：
* The bundle protocol agent must determine which endpoint(s) to forward the bundle to. The bundle protocol agent may choose either to forward the bundle directly to its destination endpoint (if possible) or to forward the bundle to some other endpoint(s) for further forwarding. The manner in which this decision is made may depend on the scheme name in the destination endpoint ID but in any case is beyond the scope of this document. If the agent finds it impossible to select any endpoint(s) to forward the bundle to, then forwarding is contraindicated.
* 捆绑协议代理必须确定将捆绑转发到哪个端点。捆绑协议代理可以选择将捆绑直接转发到其目标端点（如果可能），或者将捆绑转发到其他端点以进行进一步转发。做出此决定的方式可能取决于目标端点ID中的方案名称，但在任何情况下都超出了本文档的范围。如果代理发现无法选择要将捆绑转发到的任何端点，则禁止转发。
* Provided the bundle protocol agent succeeded in selecting the endpoint(s) to forward the bundle to, the bundle protocol agent must select the convergence layer adapter(s) whose services will enable the node to send the bundle to the nodes of the minimum reception group of each selected endpoint. The manner in which the appropriate convergence layer adapters are selected may depend on the scheme name in the destination endpoint ID but in any case is beyond the scope of this document. If the agent finds it impossible to select convergence layer adapters to use in forwarding this bundle, then forwarding is contraindicated.
* 如果捆绑协议代理成功选择要将捆绑转发到的端点，则捆绑协议代理必须选择汇聚层适配器，其服务将使节点能够将捆绑发送到每个选定端点的最小接收组的节点。选择适当汇聚层适配器的方式可能取决于目标端点ID中的方案名称，但在任何情况下都超出了本文档的范围。如果代理发现无法选择用于转发此捆绑包的聚合层适配器，则禁止转发。
Step 3: If forwarding of the bundle is determined to be contraindicated for any of the reasons listed in Figure 12, then the Forwarding Contraindicated procedure defined in Section 5.4.1 must be followed; the remaining steps of Section 5 are skipped at this time.
步骤3：如果由于图12中列出的任何原因，确定捆绑包的转发是禁忌的，则必须遵循第5.4.1节中定义的转发禁忌程序；此时跳过第5节的其余步骤。
Step 4: If the bundle's custody transfer requested flag (in the bundle processing flags field) is set to 1, then the custody transfer procedure defined in Section 5.10.2 must be followed.
步骤4：如果捆绑的托管转移请求标志（在捆绑处理标志字段中）设置为1，则必须遵循第5.10.2节中定义的托管转移程序。
Step 5: For each endpoint selected for forwarding, the bundle protocol agent must invoke the services of the selected convergence layer adapter(s) in order to effect the sending of the bundle to the nodes constituting the minimum reception group of that endpoint. Determining the time at which the bundle is to be sent by each convergence layer adapter is an implementation matter.
步骤5：对于选择用于转发的每个端点，捆绑协议代理必须调用所选汇聚层适配器的服务，以便将捆绑发送到构成该端点的最小接收组的节点。确定每个汇聚层适配器发送包的时间是一个实现问题。
To keep from possibly invalidating bundle security, the sequencing of the blocks in a forwarded bundle must not be changed as it transits a node; received blocks must be transmitted in the same relative order as that in which they were received. While blocks may be added to bundles as they transit intermediate nodes, removal of blocks that do not have their 'Discard block if it can't be processed' flag in the block processing control flags set to 1 may cause security to fail.
为了避免可能导致捆绑包安全性失效，转发捆绑包中的块顺序不得在其传输节点时更改；接收到的块必须以与接收它们时相同的相对顺序进行传输。虽然块可以在传输中间节点时添加到捆绑包中，但删除块处理控制标志中未将其“无法处理时丢弃块”标志设置为1的块可能会导致安全性失败。
Step 6: When all selected convergence layer adapters have informed the bundle protocol agent that they have concluded their data sending procedures with regard to this bundle:
步骤6：当所有选定的汇聚层适配器通知捆绑协议代理，它们已完成与此捆绑相关的数据发送过程时：
* If the "request reporting of bundle forwarding" flag in the bundle's status report request field is set to 1, then a bundle forwarding status report should be generated, destined for the bundle's report-to endpoint ID. If the bundle has the retention constraint "custody accepted" and all of the nodes in the minimum reception group of the endpoint selected for forwarding are known to be unable to send bundles back to this node, then the reason code on this bundle forwarding status report must be "forwarded over unidirectional link"; otherwise, the reason code must be "no additional information".
* 如果捆绑包状态报告请求字段中的“捆绑包转发的请求报告”标志设置为1，则应生成捆绑包转发状态报告，用于捆绑包向端点ID的报告。如果捆绑包具有保留约束“托管已接受”并且已知选择转发的端点的最小接收组中的所有节点无法将包发送回该节点，则该包转发状态报告上的原因码必须为“通过单向链路转发”；否则，原因代码必须为“无其他信息”。
* The bundle's "Forward pending" retention constraint must be removed.
* 必须删除捆绑包的“转发挂起”保留约束。
The steps in responding to contraindication of forwarding for some reason are:
出于某种原因，对转发禁忌症作出反应的步骤如下：
Step 1: The bundle protocol agent must determine whether or not to declare failure in forwarding the bundle for this reason. Note: this decision is likely to be influenced by the reason for which forwarding is contraindicated.
步骤1：捆绑协议代理必须确定是否为此原因声明转发捆绑失败。注意：此决定可能会受到禁止转发的原因的影响。
Step 2: If forwarding failure is declared, then the Forwarding Failed procedure defined in Section 5.4.2 must be followed. Otherwise, (a) if the bundle's custody transfer requested flag (in the bundle processing flags field) is set to 1, then the custody transfer procedure defined in Section 5.10 must be followed; (b) when -- at some future time - the forwarding of this bundle ceases to be contraindicated, processing proceeds from Step 5 of Section 5.4.
步骤2：如果声明转发失败，则必须遵循第5.4.2节中定义的转发失败程序。否则，（a）如果捆绑包的托管转移请求标志（在捆绑包处理标志字段中）设置为1，则必须遵循第5.10节中定义的托管转移程序；（b） 当——在未来某个时间——该捆绑包的转发不再被禁止时，处理将从第5.4节的步骤5开始。
The steps in responding to a declaration of forwarding failure for some reason are:
由于某种原因，响应转发失败声明的步骤包括：
Step 1: If the bundle's custody transfer requested flag (in the bundle processing flags field) is set to 1, custody transfer failure must be handled. Procedures for handling failure of custody transfer for a bundle whose destination is not a singleton endpoint are not defined in this specification. For a bundle whose destination is a singleton endpoint, the bundle protocol agent must handle the custody transfer failure by generating a "Failed" custody signal for the bundle, destined for the bundle's current custodian; the custody signal must contain a reason code corresponding to the reason for which forwarding was determined to be contraindicated. (Note that discarding the bundle will not delete it from the network, since the current custodian still has a copy.)
步骤1：如果捆绑包的托管传输请求标志（在捆绑包处理标志字段中）设置为1，则必须处理托管传输失败。本规范中未定义处理目的地不是单例端点的捆绑包的托管传输失败的过程。对于目的地为单例端点的捆绑包，捆绑包协议代理必须通过为捆绑包生成“失败”的托管信号（目的地为捆绑包的当前托管方）来处理托管传输失败；保管信号必须包含一个原因代码，该原因代码与确定禁止转发的原因相对应。（请注意，丢弃捆绑包不会将其从网络中删除，因为当前保管人仍有一份副本。）
Step 2: If the bundle's destination endpoint is an endpoint of which the node is a member, then the bundle's "Forward pending" retention constraint must be removed. Otherwise, the bundle must be deleted: the bundle deletion procedure defined in Section 5.13 must be followed, citing the reason for which forwarding was determined to be contraindicated.
步骤2：如果捆绑包的目标端点是节点为其成员的端点，则必须删除捆绑包的“前向挂起”保留约束。否则，必须删除捆绑包：必须遵循第5.13节中定义的捆绑包删除程序，并引用确定禁止转发的原因。
A bundle expires when the current time is greater than the bundle's creation time plus its lifetime as specified in the primary bundle block. Bundle expiration may occur at any point in the processing of a bundle. When a bundle expires, the bundle protocol agent must delete the bundle for the reason "lifetime expired": the bundle deletion procedure defined in Section 5.13 must be followed.
当当前时间大于捆绑包的创建时间加上主捆绑包块中指定的生存期时，捆绑包将过期。捆绑包过期可能发生在捆绑包处理过程中的任何时间点。当捆绑包过期时，捆绑包协议代理必须删除捆绑包，原因是“生存期已过期”：必须遵循第5.13节中定义的捆绑包删除程序。
The steps in processing a bundle received from another node are:
处理从另一个节点接收的捆绑包的步骤包括：
Step 1: The retention constraint "Dispatch pending" must be added to the bundle.
步骤1：必须将保留约束“Dispatch pending”添加到捆绑包中。
Step 2: If the "request reporting of bundle reception" flag in the bundle's status report request field is set to 1, then a bundle reception status report with reason code "No additional information" should be generated, destined for the bundle's report-to endpoint ID.
步骤2：如果捆绑包状态报告请求字段中的“捆绑包接收的请求报告”标志设置为1，则应生成带有原因代码“无其他信息”的捆绑包接收状态报告，用于捆绑包向端点ID的报告。
Step 3: For each block in the bundle that is an extension block that the bundle protocol agent cannot process:
步骤3：对于捆绑包中属于捆绑协议代理无法处理的扩展块的每个块：
* If the block processing flags in that block indicate that a status report is requested in this event, then a bundle reception status report with reason code "Block unintelligible" should be generated, destined for the bundle's report-to endpoint ID.
* 如果该块中的块处理标志指示在此事件中请求状态报告，则应生成带有原因代码“block Unlignible”的捆绑接收状态报告，该报告的目的地为捆绑的端点ID报告。
* If the block processing flags in that block indicate that the bundle must be deleted in this event, then the bundle protocol agent must delete the bundle for the reason "Block unintelligible"; the bundle deletion procedure defined in Section 5.13 must be followed and all remaining steps of the bundle reception procedure must be skipped.
* 如果该块中的块处理标志指示在此事件中必须删除捆绑包，则捆绑包协议代理必须删除捆绑包，原因是“块不可理解”；必须遵循第5.13节中定义的捆绑删除程序，并且必须跳过捆绑接收程序的所有剩余步骤。
* If the block processing flags in that block do NOT indicate that the bundle must be deleted in this event but do indicate that the block must be discarded, then the bundle protocol agent must remove this block from the bundle.
* 如果该块中的块处理标志未指示在此事件中必须删除捆绑包，但确实指示必须丢弃该块，则捆绑协议代理必须从捆绑包中删除该块。
* If the block processing flags in that block indicate NEITHER that the bundle must be deleted NOR that the block must be discarded, then the bundle protocol agent must set to 1 the "Block was forwarded without being processed" flag in the block processing flags of the block.
* 如果该块中的块处理标志既不表示必须删除捆绑包，也不表示必须丢弃该块，则捆绑协议代理必须将该块的块处理标志中的“未经处理的块已转发”标志设置为1。
Step 4: If the bundle's custody transfer requested flag (in the bundle processing flags field) is set to 1 and the bundle has the same source endpoint ID, creation timestamp, and (if the bundle is a fragment) fragment offset and payload length as another bundle that (a) has not been discarded and (b) currently has the retention constraint "Custody accepted", custody transfer redundancy must be handled. Otherwise, processing proceeds from Step 5. Procedures for handling redundancy in custody transfer
步骤4：如果捆绑包的托管传输请求标志（在捆绑包处理标志字段中）设置为1，并且捆绑包具有与另一个捆绑包相同的源端点ID、创建时间戳，并且（如果捆绑包是碎片）碎片偏移量和有效负载长度（a）未被丢弃，（b）当前具有保留约束“托管已接受”，必须处理托管转移冗余。否则，处理从步骤5开始。托管转移冗余处理程序
for a bundle whose destination is not a singleton endpoint are not defined in this specification. For a bundle whose destination is a singleton endpoint, the bundle protocol agent must handle custody transfer redundancy by generating a "Failed" custody signal for this bundle with reason code "Redundant reception", destined for this bundle's current custodian, and removing this bundle's "Dispatch pending" retention constraint.
对于目标不是单例端点的捆绑包，此规范中未定义。对于目的地为单例端点的捆绑包，捆绑包协议代理必须通过为该捆绑包生成一个原因码为“冗余接收”的“失败”托管信号（目的地为该捆绑包的当前托管方）并删除该捆绑包的“分派挂起”保留约束来处理托管传输冗余。
Step 5: Processing proceeds from Step 1 of Section 5.3.
步骤5：处理从第5.3节的步骤1开始。
The steps in processing a bundle that is destined for an endpoint of which this node is a member are:
处理以该节点为成员的端点为目的地的捆绑包的步骤包括：
Step 1: If the received bundle is a fragment, the application data unit reassembly procedure described in Section 5.9 must be followed. If this procedure results in reassembly of the entire original application data unit, processing of this bundle (whose fragmentary payload has been replaced by the reassembled application data unit) proceeds from Step 2; otherwise, the retention constraint "Reassembly pending" must be added to the bundle and all remaining steps of this procedure are skipped.
步骤1：如果收到的捆绑包是一个片段，则必须遵循第5.9节中描述的应用程序数据单元重新组装程序。如果该程序导致重新组装整个原始应用程序数据单元，则从步骤2开始处理该捆绑包（其碎片有效载荷已被重新组装的应用程序数据单元替换）；否则，必须将保留约束“重新组装挂起”添加到捆绑包中，并跳过此过程的所有剩余步骤。
Step 2: Delivery depends on the state of the registration whose endpoint ID matches that of the destination of the bundle:
步骤2：交付取决于注册的状态，该注册的端点ID与捆绑的目标匹配：
* If the registration is in the Active state, then the bundle must be delivered subject to this registration (see Section 3.1 above) as soon as all previously received bundles that are deliverable subject to this registration have been delivered.
* 如果注册处于活动状态，则必须在交付之前收到的所有根据本注册可交付的捆绑包后立即交付该捆绑包（见上文第3.1节）。
* If the registration is in the Passive state, then the registration's delivery failure action must be taken (see Section 3.1 above).
* 如果注册处于被动状态，则必须采取注册的交付失败行动（见上文第3.1节）。
Step 3: As soon as the bundle has been delivered:
步骤3：捆绑包交付后：
* If the "request reporting of bundle delivery" flag in the bundle's status report request field is set to 1, then a bundle delivery status report should be generated, destined for the bundle's report-to endpoint ID. Note that this status report only states that the payload has been delivered to the application agent, not that the application agent has processed that payload.
* 如果捆绑包状态报告请求字段中的“捆绑包交付的请求报告”标志设置为1，则应生成捆绑包交付状态报告，用于捆绑包向端点ID的报告。请注意，此状态报告仅说明有效负载已交付给application agent，并不是说应用程序代理已经处理了该负载。
* If the bundle's custody transfer requested flag (in the bundle processing flags field) is set to 1, custodial delivery must be reported. Procedures for reporting custodial delivery for a bundle whose destination is not a singleton endpoint are not defined in this specification. For a bundle whose destination is a singleton endpoint, the bundle protocol agent must report custodial delivery by generating a "Succeeded" custody signal for the bundle, destined for the bundle's current custodian.
* 如果捆绑的保管转移请求标志（在捆绑处理标志字段中）设置为1，则必须报告保管交付。本规范中未定义报告目的地不是单例端点的捆绑包的托管交付的过程。对于目的地为单例端点的捆绑包，捆绑包协议代理必须通过为捆绑包生成“成功”托管信号来报告托管交付，该信号的目的地为捆绑包的当前托管方。
It may at times be necessary for bundle protocol agents to reduce the sizes of bundles in order to forward them. This might be the case, for example, if the endpoint to which a bundle is to be forwarded is accessible only via intermittent contacts and no upcoming contact is long enough to enable the forwarding of the entire bundle.
捆绑协议代理有时可能需要减小捆绑包的大小以转发它们。例如，如果要转发捆绑包的端点只能通过断断续续的联系人访问，并且没有足够长的即将到来的联系人能够转发整个捆绑包，则可能会出现这种情况。
The size of a bundle can be reduced by "fragmenting" the bundle. To fragment a bundle whose payload is of size M is to replace it with two "fragments" -- new bundles with the same source endpoint ID and creation timestamp as the original bundle -- whose payloads are the first N and the last (M - N) bytes of the original bundle's payload, where 0 < N < M. Note that fragments may themselves be fragmented, so fragmentation may in effect replace the original bundle with more than two fragments. (However, there is only one 'level' of fragmentation, as in IP fragmentation.)
捆绑的大小可以通过“分割”捆绑来减小。对有效负载大小为M的捆绑包进行分段，就是将其替换为两个“碎片”——具有与原始捆绑包相同的源端点ID和创建时间戳的新捆绑包——其有效负载是原始捆绑包有效负载的前N个字节和最后（M-N）个字节，其中0<N<M。请注意，碎片本身可能被分段，因此，碎片实际上可能会用两个以上的碎片替换原始捆绑包。（但是，与IP碎片化一样，只有一个“级别”的碎片化。）
Any bundle whose primary block's bundle processing flags do NOT indicate that it must not be fragmented may be fragmented at any time, for any purpose, at the discretion of the bundle protocol agent.
主数据块的包处理标志未指示其不得分段的任何包可在任何时候出于任何目的分段，由包协议代理自行决定。
Fragmentation shall be constrained as follows:
碎片应按照以下要求进行限制：
o The concatenation of the payloads of all fragments produced by fragmentation must always be identical to the payload of the bundle that was fragmented. Note that the payloads of fragments resulting from different fragmentation episodes, in different parts of the network, may be overlapping subsets of the original bundle's payload.
o 由碎片生成的所有碎片的有效负载的连接必须始终与被碎片化的捆绑包的有效负载相同。请注意，在网络的不同部分，由不同碎片事件产生的碎片的有效载荷可能是原始捆绑包有效载荷的重叠子集。
o The bundle processing flags in the primary block of each fragment must be modified to indicate that the bundle is a fragment, and both fragment offset and total application data unit length must be provided at the end of each fragment's primary bundle block.
o 必须修改每个片段的主块中的捆绑处理标志，以指示捆绑是一个片段，并且必须在每个片段的主捆绑块末尾提供碎片偏移量和应用程序数据单元总长度。
o The primary blocks of the fragments will differ from that of the fragmented bundle as noted above.
o 如上文所述，片段的主块将不同于片段束的主块。
o The payload blocks of fragments will differ from that of the fragmented bundle as noted above.
o 如上所述，碎片的有效负载块将不同于碎片包的有效负载块。
o All blocks that precede the payload block at the time of fragmentation must be replicated in the fragment with the lowest offset.
o 必须在偏移量最低的片段中复制碎片时位于有效负载块之前的所有块。
o All blocks that follow the payload block at the time of fragmentation must be replicated in the fragment with the highest offset.
o 碎片化时跟随有效负载块的所有块必须在偏移量最高的片段中复制。
o If the 'Block must be replicated in every fragment' bit is set to 1, then the block must be replicated in every fragment.
o 如果“必须在每个片段中复制块”位设置为1，则必须在每个片段中复制块。
o If the 'Block must be replicated in every fragment' bit is set to zero, the block should be replicated in only one fragment.
o 如果“必须在每个片段中复制块”位设置为零，则应仅在一个片段中复制块。
o The relative order of all blocks that are present in a fragment must be the same as in the bundle prior to fragmentation.
o 片段中存在的所有块的相对顺序必须与片段之前在束中的顺序相同。
If the concatenation -- as informed by fragment offsets and payload lengths -- of the payloads of all previously received fragments with the same source endpoint ID and creation timestamp as this fragment, together with the payload of this fragment, forms a byte array whose length is equal to the total application data unit length in the fragment's primary block, then:
如果连接（由片段偏移量和有效负载长度通知）所有先前接收到的片段的有效负载（与此片段具有相同的源端点ID和创建时间戳），以及此片段的有效负载，形成一个字节数组，其长度等于片段主块中应用程序数据单元的总长度，然后：
o This byte array -- the reassembled application data unit -- must replace the payload of this fragment.
o 这个字节数组——重新组装的应用程序数据单元——必须替换这个片段的有效负载。
o The "Reassembly pending" retention constraint must be removed from every other fragment whose payload is a subset of the reassembled application data unit.
o 必须从负载为重新组装的应用程序数据单元子集的每个其他片段中删除“重新组装挂起”保留约束。
Note: reassembly of application data units from fragments occurs at destination endpoints as necessary; an application data unit may also be reassembled at some other endpoint on the route to the destination.
注意：根据需要在目标端点处重新组装来自片段的应用程序数据单元；应用程序数据单元也可以在到目的地的路由上的某个其他端点处重新组装。
The conditions under which a node may accept custody of a bundle whose destination is not a singleton endpoint are not defined in this specification.
本规范中未定义节点可以接受目的地不是单例端点的捆绑包托管的条件。
The decision as to whether or not to accept custody of a bundle whose destination is a singleton endpoint is an implementation matter that may involve both resource and policy considerations; however, if the bundle protocol agent has committed to accepting custody of the bundle (as described in Step 1 of Section 5.2), then custody must be accepted.
关于是否接受目的地为单例端点的捆绑包的托管的决定是一个实现问题，可能涉及资源和策略方面的考虑；但是，如果捆绑协议代理承诺接受捆绑的保管（如第5.2节步骤1所述），则必须接受保管。
If the bundle protocol agent elects to accept custody of the bundle, then it must follow the custody acceptance procedure defined in Section 5.10.1.
如果捆绑协议代理选择接受捆绑的托管，则必须遵循第5.10.1节中定义的托管接受程序。
Procedures for acceptance of custody of a bundle whose destination is not a singleton endpoint are not defined in this specification.
本规范中未定义接受目的地不是单例端点的捆绑包托管的程序。
Procedures for acceptance of custody of a bundle whose destination is a singleton endpoint are defined as follows.
接收目的地为单例端点的捆绑包托管的过程定义如下。
The retention constraint "Custody accepted" must be added to the bundle.
必须将保留约束“托管已接受”添加到捆绑包中。
If the "request reporting of custody acceptance" flag in the bundle's status report request field is set to 1, a custody acceptance status report should be generated, destined for the report-to endpoint ID of the bundle. However, if a bundle reception status report was generated for this bundle (Step 1 of Section 5.6), then this report should be generated by simply turning on the "Reporting node accepted custody of bundle" flag in that earlier report's status flags byte.
如果捆绑包状态报告请求字段中的“托管验收的请求报告”标志设置为1，则应生成托管验收状态报告，该报告的目的地为捆绑包的报告到端点ID。但是，如果为该捆绑包生成了捆绑包接收状态报告（第5.6节的步骤1），则应通过简单地打开该早期报告状态标志字节中的“报告节点接受捆绑包托管”标志来生成该报告。
The bundle protocol agent must generate a "Succeeded" custody signal for the bundle, destined for the bundle's current custodian.
捆绑协议代理必须为捆绑生成一个“成功”的托管信号，发送给捆绑的当前保管人。
The bundle protocol agent must assert the new current custodian for the bundle. It does so by changing the current custodian endpoint ID in the bundle's primary block to the endpoint ID of one of the singleton endpoints in which the node is registered. This may entail appending that endpoint ID's null-terminated scheme name and SSP to the dictionary byte array in the bundle's primary block, and in some case it may also enable the (optional) removal of the current custodian endpoint ID's scheme name and/or SSP from the dictionary.
捆绑协议代理必须为捆绑声明新的当前保管人。它通过将捆绑包主块中的当前托管端点ID更改为注册节点的其中一个单例端点的端点ID来实现。这可能需要将端点ID的以null结尾的方案名称和SSP追加到捆绑包主块中的字典字节数组中，并且在某些情况下，还可能允许（可选）从字典中删除当前托管端点ID的方案名称和/或SSP。
The bundle protocol agent may set a custody transfer countdown timer for this bundle; upon expiration of this timer prior to expiration of the bundle itself and prior to custody transfer success for this bundle, the custody transfer failure procedure detailed in Section 5.12 must be followed. The manner in which the countdown interval for such a timer is determined is an implementation matter.
捆绑协议代理可以为此捆绑设置托管转移倒计时计时器；在捆绑包本身到期之前，以及在该捆绑包的托管转移成功之前，该计时器到期后，必须遵守第5.12节详述的托管转移失败程序。确定这种计时器的倒计时间隔的方式是一个实现问题。
The bundle should be retained in persistent storage if possible.
如有可能，应将捆绑包保留在永久性存储中。
Procedures for release of custody of a bundle whose destination is not a singleton endpoint are not defined in this specification.
本规范中未定义目的地不是单例端点的捆绑包的托管释放过程。
When custody of a bundle is released, where the destination of the bundle is a singleton endpoint, the "Custody accepted" retention constraint must be removed from the bundle and any custody transfer timer that has been established for this bundle must be destroyed.
当解除捆绑包的保管时，如果捆绑包的目标是单例端点，则必须从捆绑包中删除“保管接受”保留约束，并且必须销毁为此捆绑包建立的任何保管转移计时器。
Procedures for determining custody transfer success for a bundle whose destination is not a singleton endpoint are not defined in this specification.
本规范中未定义用于确定目的地不是单例端点的捆绑包的托管传输成功的过程。
Upon receipt of a "Succeeded" custody signal at a node that is a custodial node of the bundle identified in the custody signal, where the destination of the bundle is a singleton endpoint, custody of the bundle must be released as described in Section 5.10.2.
在作为托管信号中标识的捆绑包托管节点的节点处接收到“成功”托管信号后，如果捆绑包的目的地是单例端点，则必须按照第5.10.2节所述解除捆绑包的托管。
Procedures for determining custody transfer failure for a bundle whose destination is not a singleton endpoint are not defined in this specification. Custody transfer for a bundle whose destination is a singleton endpoint is determined to have failed at a custodial node for that bundle when either (a) that node's custody transfer timer for that bundle (if any) expires or (b) a "Failed" custody signal for that bundle is received at that node.
本规范中未定义用于确定目的地不是单例端点的捆绑包的托管传输失败的过程。当（a）该捆绑包的节点托管传输计时器（如果有）过期或（b）在该节点接收到该捆绑包的“失败”托管信号时，其目的地为单例端点的捆绑包的托管传输被确定为在该捆绑包的托管节点失败。
Upon determination of custody transfer failure, the action taken by the bundle protocol agent is implementation-specific and may depend on the nature of the failure. For example, if custody transfer failure was inferred from expiration of a custody transfer timer or was asserted by a "Failed" custody signal with the "Depleted storage" reason code, the bundle protocol agent might choose to re-forward the bundle, possibly on a different route (Section 5.4). Receipt of a "Failed" custody signal with the "Redundant reception" reason code,
在确定托管传输失败时，捆绑协议代理所采取的操作是特定于实现的，并且可能取决于失败的性质。例如，如果托管传输失败是从托管传输计时器的过期推断出来的，或者是由带有“耗尽存储”原因码的“失败”托管信号断言的，则捆绑协议代理可能会选择在不同的路由上重新转发捆绑包（第5.4节）。接收到带有“冗余接收”原因码的“失败”监护信号，
on the other hand, might cause the bundle protocol agent to release custody of the bundle and to revise its algorithm for computing countdown intervals for custody transfer timers.
另一方面，可能会导致捆绑协议代理释放捆绑的托管，并修改其用于计算托管传输计时器的倒计时间隔的算法。
The steps in deleting a bundle are:
删除捆绑包的步骤包括：
Step 1: If the retention constraint "Custody accepted" currently prevents this bundle from being discarded, and the destination of the bundle is a singleton endpoint, then:
步骤1：如果保留约束“托管已接受”当前阻止丢弃此捆绑包，并且捆绑包的目标是单例端点，则：
* Custody of the node is released as described in Section 5.10.2.
* 如第5.10.2节所述，释放节点监护权。
* A bundle deletion status report citing the reason for deletion must be generated, destined for the bundle's report-to endpoint ID.
* 必须生成引用删除原因的捆绑包删除状态报告，该报告的目的地为捆绑包的端点ID报告。
Otherwise, if the "request reporting of bundle deletion" flag in the bundle's status report request field is set to 1, then a bundle deletion status report citing the reason for deletion should be generated, destined for the bundle's report-to endpoint ID.
否则，如果捆绑包的状态报告请求字段中的“请求报告捆绑包删除”标志设置为1，则应生成一个引用删除原因的捆绑包删除状态报告，以捆绑包的端点ID报告为目标。
Step 2: All of the bundle's retention constraints must be removed.
步骤2：必须删除捆绑包的所有保留约束。
As soon as a bundle has no remaining retention constraints it may be discarded.
一旦捆绑包没有剩余的保留约束，它就可能被丢弃。
When requested to cancel a specified transmission, where the bundle created upon initiation of the indicated transmission has not yet been discarded, the bundle protocol agent must delete that bundle for the reason "transmission cancelled". For this purpose, the procedure defined in Section 5.13 must be followed.
当请求取消指定传输时，如果在指定传输启动时创建的捆绑包尚未被丢弃，则捆绑协议代理必须以“传输已取消”为理由删除该捆绑包。为此，必须遵循第5.13节中规定的程序。
When requested to poll a specified registration that is in the Passive state, the bundle protocol agent must immediately deliver the least recently received bundle that is deliverable subject to the indicated registration, if any.
当请求轮询处于被动状态的指定注册时，捆绑协议代理必须立即交付最近收到的最少的捆绑包，该捆绑包可根据指定的注册（如果有）交付。
Administrative records are standard application data units that are used in providing some of the features of the Bundle Protocol. Two types of administrative records have been defined to date: bundle status reports and custody signals.
管理记录是标准的应用程序数据单元，用于提供捆绑协议的某些功能。迄今为止，已定义了两种类型的管理记录：捆绑状态报告和托管信号。
Every administrative record consists of a four-bit record type code followed by four bits of administrative record flags, followed by record content in type-specific format. Record type codes are defined as follows:
每个管理记录都由一个四位记录类型代码和四位管理记录标志组成，后面是特定类型格式的记录内容。记录类型代码定义如下：
+---------+--------------------------------------------+
| Value | Meaning |
+=========+============================================+
| 0001 | Bundle status report. |
+---------+--------------------------------------------+
| 0010 | Custody signal. |
+---------+--------------------------------------------+
| (other) | Reserved for future use. |
+---------+--------------------------------------------+
+---------+--------------------------------------------+
| Value | Meaning |
+=========+============================================+
| 0001 | Bundle status report. |
+---------+--------------------------------------------+
| 0010 | Custody signal. |
+---------+--------------------------------------------+
| (other) | Reserved for future use. |
+---------+--------------------------------------------+
Figure 8: Administrative Record Type Codes
图8：管理记录类型代码
+---------+--------------------------------------------+
| Value | Meaning |
+=========+============================================+
| 0001 | Record is for a fragment; fragment |
| | offset and length fields are present. |
+---------+--------------------------------------------+
| (other) | Reserved for future use. |
+---------+--------------------------------------------+
+---------+--------------------------------------------+
| Value | Meaning |
+=========+============================================+
| 0001 | Record is for a fragment; fragment |
| | offset and length fields are present. |
+---------+--------------------------------------------+
| (other) | Reserved for future use. |
+---------+--------------------------------------------+
Figure 9: Administrative Record Flags
图9：管理记录标志
All time values in administrative records are UTC times expressed in "DTN time" representation. A DTN time consists of an SDNV indicating the number of seconds since the start of the year 2000, followed by an SDNV indicating the number of nanoseconds since the start of the indicated second.
管理记录中的所有时间值都是以“DTN时间”表示的UTC时间。DTN时间包括一个SDNV，表示自2000年开始以来的秒数，然后是一个SDNV，表示自指示秒开始以来的纳秒数。
The contents of the various types of administrative records are described below.
各类行政记录的内容如下所述。
The transmission of 'bundle status reports' under specified conditions is an option that can be invoked when transmission of a bundle is requested. These reports are intended to provide information about how bundles are progressing through the system, including notices of receipt, custody transfer, forwarding, final delivery, and deletion. They are transmitted to the Report-to endpoints of bundles.
在指定条件下传输“捆绑状态报告”是一个选项，在请求传输捆绑时可以调用该选项。这些报告旨在提供有关捆绑包在系统中进展情况的信息，包括接收、托管转移、转发、最终交付和删除通知。它们被传输到捆绑包端点的报告。
+----------------+----------------+----------------+----------------+
| Status Flags | Reason code | Fragment offset (*) (if
+----------------+----------------+----------------+----------------+
present) | Fragment length (*) (if present) |
+----------------+----------------+----------------+----------------+
| Time of receipt of bundle X (a DTN time, if present) |
+----------------+----------------+----------------+----------------+
| Time of custody acceptance of bundle X (a DTN time, if present) |
+----------------+----------------+----------------+----------------+
| Time of forwarding of bundle X (a DTN time, if present) |
+----------------+----------------+----------------+----------------+
| Time of delivery of bundle X (a DTN time, if present) |
+----------------+----------------+----------------+----------------+
| Time of deletion of bundle X (a DTN time, if present) |
+----------------+----------------+----------------+----------------+
| Copy of bundle X's Creation Timestamp time (*) |
+----------------+----------------+----------------+----------------+
| Copy of bundle X's Creation Timestamp sequence number (*) |
+----------------+----------------+----------------+----------------+
| Length of X's source endpoint ID (*) | Source
+----------------+---------------------------------+ +
endpoint ID of bundle X (variable) |
+----------------+----------------+----------------+----------------+
+----------------+----------------+----------------+----------------+
| Status Flags | Reason code | Fragment offset (*) (if
+----------------+----------------+----------------+----------------+
present) | Fragment length (*) (if present) |
+----------------+----------------+----------------+----------------+
| Time of receipt of bundle X (a DTN time, if present) |
+----------------+----------------+----------------+----------------+
| Time of custody acceptance of bundle X (a DTN time, if present) |
+----------------+----------------+----------------+----------------+
| Time of forwarding of bundle X (a DTN time, if present) |
+----------------+----------------+----------------+----------------+
| Time of delivery of bundle X (a DTN time, if present) |
+----------------+----------------+----------------+----------------+
| Time of deletion of bundle X (a DTN time, if present) |
+----------------+----------------+----------------+----------------+
| Copy of bundle X's Creation Timestamp time (*) |
+----------------+----------------+----------------+----------------+
| Copy of bundle X's Creation Timestamp sequence number (*) |
+----------------+----------------+----------------+----------------+
| Length of X's source endpoint ID (*) | Source
+----------------+---------------------------------+ +
endpoint ID of bundle X (variable) |
+----------------+----------------+----------------+----------------+
Figure 10: Bundle Status Report Format
图10：捆绑包状态报告格式
(*) Notes:
（*）注：
The Fragment Offset field, if present, is an SDNV and is therefore variable length. A three-octet SDNV is shown here for convenience in representation.
片段偏移字段（如果存在）是SDNV，因此长度可变。为了便于表示，此处显示了三个八位组的SDNV。
The Fragment Length field, if present, is an SDNV and is therefore variable length. A three-octet SDNV is shown here for convenience in representation.
片段长度字段（如果存在）是SDNV，因此长度可变。为了便于表示，此处显示了三个八位组的SDNV。
The Creation Timestamp fields replicate the Creation Timestamp fields in the primary block of the subject bundle. As such they are SDNVs (see Section 4.5.1 above) and are therefore variable length. Four-octet SDNVs are shown here for convenience in representation.
创建时间戳字段复制主题束主块中的创建时间戳字段。因此，它们是SDNV（见上文第4.5.1节），因此长度可变。为了便于表示，此处显示了四个八位组SDNV。
The source endpoint ID length field is an SDNV and is therefore variable length. A three-octet SDNV is shown here for convenience in representation.
源端点ID长度字段是SDNV，因此长度可变。为了便于表示，此处显示了三个八位组的SDNV。
The fields in a bundle status report are:
捆绑状态报告中的字段包括：
Status Flags: A 1-byte field containing the following flags:
状态标志：包含以下标志的1字节字段：
+----------+--------------------------------------------+
| Value | Meaning |
+==========+============================================+
| 00000001 | Reporting node received bundle. |
+----------+--------------------------------------------+
| 00000010 | Reporting node accepted custody of bundle.|
+----------+--------------------------------------------+
| 00000100 | Reporting node forwarded the bundle. |
+----------+--------------------------------------------+
| 00001000 | Reporting node delivered the bundle. |
+----------+--------------------------------------------+
| 00010000 | Reporting node deleted the bundle. |
+----------+--------------------------------------------+
| 00100000 | Unused. |
+----------+--------------------------------------------+
| 01000000 | Unused. |
+----------+--------------------------------------------+
| 10000000 | Unused. |
+----------+--------------------------------------------+
+----------+--------------------------------------------+
| Value | Meaning |
+==========+============================================+
| 00000001 | Reporting node received bundle. |
+----------+--------------------------------------------+
| 00000010 | Reporting node accepted custody of bundle.|
+----------+--------------------------------------------+
| 00000100 | Reporting node forwarded the bundle. |
+----------+--------------------------------------------+
| 00001000 | Reporting node delivered the bundle. |
+----------+--------------------------------------------+
| 00010000 | Reporting node deleted the bundle. |
+----------+--------------------------------------------+
| 00100000 | Unused. |
+----------+--------------------------------------------+
| 01000000 | Unused. |
+----------+--------------------------------------------+
| 10000000 | Unused. |
+----------+--------------------------------------------+
Figure 11: Status Flags for Bundle Status Reports
图11：捆绑状态报告的状态标志
Reason Code: A 1-byte field explaining the value of the flags in the status flags byte. The list of status report reason codes provided here is neither exhaustive nor exclusive; supplementary DTN protocol specifications (including, but not restricted to, the Bundle Security Protocol [BSP]) may define additional reason codes. Status report reason codes are defined as follows:
原因代码：一个1字节字段，解释状态标志字节中标志的值。此处提供的状态报告原因代码列表既不详尽也不排他性；补充DTN协议规范（包括但不限于捆绑安全协议[BSP]）可定义其他原因码。状态报告原因代码定义如下：
+---------+--------------------------------------------+
| Value | Meaning |
+=========+============================================+
| 0x00 | No additional information. |
+---------+--------------------------------------------+
| 0x01 | Lifetime expired. |
+---------+--------------------------------------------+
| 0x02 | Forwarded over unidirectional link. |
+---------+--------------------------------------------+
| 0x03 | Transmission canceled. |
+---------+--------------------------------------------+
| 0x04 | Depleted storage. |
+---------+--------------------------------------------+
| 0x05 | Destination endpoint ID unintelligible. |
+---------+--------------------------------------------+
| 0x06 | No known route to destination from here. |
+---------+--------------------------------------------+
| 0x07 | No timely contact with next node on route.|
+---------+--------------------------------------------+
| 0x08 | Block unintelligible. |
+---------+--------------------------------------------+
| (other) | Reserved for future use. |
+---------+--------------------------------------------+
+---------+--------------------------------------------+
| Value | Meaning |
+=========+============================================+
| 0x00 | No additional information. |
+---------+--------------------------------------------+
| 0x01 | Lifetime expired. |
+---------+--------------------------------------------+
| 0x02 | Forwarded over unidirectional link. |
+---------+--------------------------------------------+
| 0x03 | Transmission canceled. |
+---------+--------------------------------------------+
| 0x04 | Depleted storage. |
+---------+--------------------------------------------+
| 0x05 | Destination endpoint ID unintelligible. |
+---------+--------------------------------------------+
| 0x06 | No known route to destination from here. |
+---------+--------------------------------------------+
| 0x07 | No timely contact with next node on route.|
+---------+--------------------------------------------+
| 0x08 | Block unintelligible. |
+---------+--------------------------------------------+
| (other) | Reserved for future use. |
+---------+--------------------------------------------+
Figure 12: Status Report Reason Codes
图12：状态报告原因代码
Fragment Offset: If the bundle fragment bit is set in the status flags, then the offset (within the original application data unit) of the payload of the bundle that caused the status report to be generated is included here.
片段偏移量：如果在状态标志中设置了捆绑包片段位，则导致生成状态报告的捆绑包有效负载的偏移量（在原始应用程序数据单元内）包含在此处。
Fragment length: If the bundle fragment bit is set in the status flags, then the length of the payload of the subject bundle is included here.
片段长度：如果在状态标志中设置了bundle片段位，则此处包括主题bundle的有效负载长度。
Time of Receipt (if present): If the bundle-received bit is set in the status flags, then a DTN time indicating the time at which the bundle was received at the reporting node is included here.
接收时间（如果存在）：如果在状态标志中设置了bundle received位，则此处包括DTN时间，该时间指示在报告节点接收bundle的时间。
Time of Custody Acceptance (if present): If the custody-accepted bit is set in the status flags, then a DTN time indicating the time at which custody was accepted at the reporting node is included here.
托管接受时间（如果存在）：如果在状态标志中设置了托管接受位，则此处包括DTN时间，指示在报告节点接受托管的时间。
Time of Forward (if present): If the bundle-forwarded bit is set in the status flags, then a DTN time indicating the time at which the bundle was first forwarded at the reporting node is included here.
转发时间（如果存在）：如果在状态标志中设置了bundle forwarded位，则此处包括DTN时间，该时间指示bundle在报告节点上第一次转发的时间。
Time of Delivery (if present): If the bundle-delivered bit is set in the status flags, then a DTN time indicating the time at which the bundle was delivered at the reporting node is included here.
交付时间（如果存在）：如果在状态标志中设置了bundle delivered位，则此处包括DTN时间，该时间指示在报告节点交付bundle的时间。
Time of Deletion (if present): If the bundle-deleted bit is set in the status flags, then a DTN time indicating the time at which the bundle was deleted at the reporting node is included here.
删除时间（如果存在）：如果在状态标志中设置了bundle deleted位，则此处包括DTN时间，该时间指示在报告节点删除bundle的时间。
Creation Timestamp of Subject Bundle: A copy of the creation timestamp of the bundle that caused the status report to be generated.
主题捆绑包的创建时间戳：导致生成状态报告的捆绑包的创建时间戳的副本。
Length of Source Endpoint ID: The length in bytes of the source endpoint ID of the bundle that caused the status report to be generated.
源端点ID的长度：导致生成状态报告的捆绑包的源端点ID的字节长度。
Source Endpoint ID text: The text of the source endpoint ID of the bundle that caused the status report to be generated.
源端点ID文本：导致生成状态报告的捆绑包的源端点ID的文本。
Custody signals are administrative records that effect custody transfer operations. They are transmitted to the endpoints that are the current custodians of bundles.
监护信号是影响监护转移操作的管理记录。它们被传输到作为捆绑包当前保管人的端点。
Custody signals have the following format.
监护信号的格式如下。
Custody signal regarding bundle 'X':
关于捆绑“X”的保管信号：
+----------------+----------------+----------------+----------------+
| Status | Fragment offset (*) (if present) |
+----------------+----------------+----------------+----------------+
| Fragment length (*) (if present) |
+----------------+----------------+----------------+----------------+
| Time of signal (a DTN time) |
+----------------+----------------+----------------+----------------+
| Copy of bundle X's Creation Timestamp time (*) |
+----------------+----------------+----------------+----------------+
| Copy of bundle X's Creation Timestamp sequence number (*) |
+----------------+----------------+----------------+----------------+
| Length of X's source endpoint ID (*) | Source
+----------------+---------------------------------+ +
endpoint ID of bundle X (variable) |
+----------------+----------------+----------------+----------------+
+----------------+----------------+----------------+----------------+
| Status | Fragment offset (*) (if present) |
+----------------+----------------+----------------+----------------+
| Fragment length (*) (if present) |
+----------------+----------------+----------------+----------------+
| Time of signal (a DTN time) |
+----------------+----------------+----------------+----------------+
| Copy of bundle X's Creation Timestamp time (*) |
+----------------+----------------+----------------+----------------+
| Copy of bundle X's Creation Timestamp sequence number (*) |
+----------------+----------------+----------------+----------------+
| Length of X's source endpoint ID (*) | Source
+----------------+---------------------------------+ +
endpoint ID of bundle X (variable) |
+----------------+----------------+----------------+----------------+
Figure 13: Custody Signal Format
图13：监护信号格式
(*) Notes:
（*）注：
The Fragment Offset field, if present, is an SDNV and is therefore variable length. A three-octet SDNV is shown here for convenience in representation.
片段偏移字段（如果存在）是SDNV，因此长度可变。为了便于表示，此处显示了三个八位组的SDNV。
The Fragment Length field, if present, is an SDNV and is therefore variable length. A four-octet SDNV is shown here for convenience in representation.
片段长度字段（如果存在）是SDNV，因此长度可变。为了便于表示，此处显示了四个八位组的SDNV。
The Creation Timestamp fields replicate the Creation Timestamp fields in the primary block of the subject bundle. As such they are SDNVs (see Section 4.5.1 above) and are therefore variable length. Four-octet SDNVs are shown here for convenience in representation.
创建时间戳字段复制主题束主块中的创建时间戳字段。因此，它们是SDNV（见上文第4.5.1节），因此长度可变。为了便于表示，此处显示了四个八位组SDNV。
The source endpoint ID length field is an SDNV and is therefore variable length. A three-octet SDNV is shown here for convenience in representation.
源端点ID长度字段是SDNV，因此长度可变。为了便于表示，此处显示了三个八位组的SDNV。
The fields in a custody signal are:
监护信号中的字段为：
Status: A 1-byte field containing a 1-bit "custody transfer succeeded" flag followed by a 7-bit reason code explaining the value of that flag. Custody signal reason codes are defined as follows:
状态：一个1字节字段，包含一个1位的“监护权转移成功”标志，后跟一个解释该标志值的7位原因码。监护信号原因代码定义如下：
+---------+--------------------------------------------+
| Value | Meaning |
+=========+============================================+
| 0x00 | No additional information. |
+---------+--------------------------------------------+
| 0x01 | Reserved for future use. |
+---------+--------------------------------------------+
| 0x02 | Reserved for future use. |
+---------+--------------------------------------------+
| 0x03 | Redundant reception (reception by a node |
| | that is a custodial node for this bundle).|
+---------+--------------------------------------------+
| 0x04 | Depleted storage. |
+---------+--------------------------------------------+
| 0x05 | Destination endpoint ID unintelligible. |
+---------+--------------------------------------------+
| 0x06 | No known route to destination from here. |
+---------+--------------------------------------------+
| 0x07 | No timely contact with next node on route.|
+---------+--------------------------------------------+
| 0x08 | Block unintelligible. |
+---------+--------------------------------------------+
| (other) | Reserved for future use. |
+---------+--------------------------------------------+
+---------+--------------------------------------------+
| Value | Meaning |
+=========+============================================+
| 0x00 | No additional information. |
+---------+--------------------------------------------+
| 0x01 | Reserved for future use. |
+---------+--------------------------------------------+
| 0x02 | Reserved for future use. |
+---------+--------------------------------------------+
| 0x03 | Redundant reception (reception by a node |
| | that is a custodial node for this bundle).|
+---------+--------------------------------------------+
| 0x04 | Depleted storage. |
+---------+--------------------------------------------+
| 0x05 | Destination endpoint ID unintelligible. |
+---------+--------------------------------------------+
| 0x06 | No known route to destination from here. |
+---------+--------------------------------------------+
| 0x07 | No timely contact with next node on route.|
+---------+--------------------------------------------+
| 0x08 | Block unintelligible. |
+---------+--------------------------------------------+
| (other) | Reserved for future use. |
+---------+--------------------------------------------+
Figure 14: Custody Signal Reason Codes
图14：监护信号原因代码
Fragment offset: If the bundle fragment bit is set in the status flags, then the offset (within the original application data unit) of the payload of the bundle that caused the status report to be generated is included here.
片段偏移量：如果在状态标志中设置了捆绑包片段位，则导致生成状态报告的捆绑包有效负载的偏移量（在原始应用程序数据单元内）包含在此处。
Fragment length: If the bundle fragment bit is set in the status flags, then the length of the payload of the subject bundle is included here.
片段长度：如果在状态标志中设置了bundle片段位，则此处包括主题bundle的有效负载长度。
Time of Signal: A DTN time indicating the time at which the signal was generated.
信号时间：表示信号生成时间的DTN时间。
Creation Timestamp of Subject Bundle: A copy of the creation timestamp of the bundle to which the signal applies.
主题包的创建时间戳：应用信号的包的创建时间戳的副本。
Length of Source Endpoint ID: The length in bytes of the source endpoint ID of the bundle to which the signal applied.
源端点ID的长度：应用信号的包的源端点ID的字节长度。
Source Endpoint ID text: The text of the source endpoint ID of the bundle to which the signal applies.
Source Endpoint ID text：应用信号的捆绑包的源端点ID的文本。
Whenever the application agent's administrative element is directed by the bundle protocol agent to generate an administrative record with reference to some bundle, the following procedure must be followed:
每当捆绑协议代理指示应用程序代理的管理元素生成有关某个捆绑的管理记录时，必须遵循以下过程：
Step 1: The administrative record must be constructed. If the referenced bundle is a fragment, the administrative record must have the Fragment flag set and must contain the fragment offset and fragment length fields. The value of the fragment offset field must be the value of the referenced bundle's fragment offset, and the value of the fragment length field must be the length of the referenced bundle's payload.
步骤1：必须构建管理记录。如果引用的捆绑包是片段，则管理记录必须设置片段标志，并且必须包含片段偏移量和片段长度字段。片段偏移量字段的值必须是被引用捆绑包的片段偏移量的值，而片段长度字段的值必须是被引用捆绑包有效负载的长度。
Step 2: A request for transmission of a bundle whose payload is this administrative record must be presented to the bundle protocol agent.
步骤2：必须向bundle协议代理提交一个传输包的请求，该包的有效负载是该管理记录。
For each received custody signal that has the "custody transfer succeeded" flag set to 1, the administrative element of the application agent must direct the bundle protocol agent to follow the custody transfer success procedure in Section 5.11.
对于每个接收到的“托管转移成功”标志设置为1的托管信号，应用程序代理的管理元素必须指示捆绑协议代理遵循第5.11节中的托管转移成功程序。
For each received custody signal that has the "custody transfer succeeded" flag set to 0, the administrative element of the application agent must direct the bundle protocol agent to follow the custody transfer failure procedure in Section 5.12.
对于每个接收到的“托管传输成功”标志设置为0的托管信号，应用程序代理的管理元素必须指示捆绑协议代理遵循第5.12节中的托管传输失败程序。
The successful operation of the end-to-end bundle protocol depends on the operation of underlying protocols at what is termed the "convergence layer"; these protocols accomplish communication between nodes. A wide variety of protocols may serve this purpose, so long as each convergence layer protocol adapter provides a defined minimal set of services to the bundle protocol agent. This convergence layer service specification enumerates those services.
端到端捆绑协议的成功运行取决于底层协议在所谓的“汇聚层”的运行；这些协议完成了节点之间的通信。只要每个汇聚层协议适配器向bundle协议代理提供定义的最小服务集，各种各样的协议都可以用于此目的。此汇聚层服务规范列举了这些服务。
Each convergence layer protocol adapter is expected to provide the following services to the bundle protocol agent:
每个汇聚层协议适配器应向捆绑协议代理提供以下服务：
o sending a bundle to all bundle nodes in the minimum reception group of the endpoint identified by a specified endpoint ID that are reachable via the convergence layer protocol; and
o 向由指定的端点ID标识的端点的最小接收组中的所有捆绑节点发送捆绑，这些节点可通过汇聚层协议到达；和
o delivering to the bundle protocol agent a bundle that was sent by a remote bundle node via the convergence layer protocol.
o 向bundle协议代理交付由远程bundle节点通过汇聚层协议发送的bundle。
The convergence layer service interface specified here is neither exhaustive nor exclusive. That is, supplementary DTN protocol specifications (including, but not restricted to, the Bundle Security Protocol [BSP]) may expect convergence layer adapters that serve BP implementations conforming to those protocols to provide additional services.
此处指定的聚合层服务接口既不是详尽的，也不是独占的。也就是说，补充DTN协议规范（包括但不限于捆绑安全协议[BSP]）可能期望为符合这些协议的BP实现提供服务的汇聚层适配器提供附加服务。
The bundle protocol has taken security into concern from the outset of its design. It was always assumed that security services would be needed in the use of the bundle protocol. As a result, the bundle protocol security architecture and the available security services are specified in an accompanying document, the Bundle Security Protocol specification [BSP]; an informative overview of this architecture is provided in [SECO].
bundle协议从设计之初就考虑到了安全性。人们总是认为在使用捆绑协议时需要安全服务。因此，捆绑协议安全体系结构和可用的安全服务在随附的文档中指定，即捆绑安全协议规范[BSP]；[SECO]中提供了该体系结构的详细概述。
The bundle protocol has been designed with the notion that it will be run over networks with scarce resources. For example, the networks might have limited bandwidth, limited connectivity, constrained storage in relay nodes, etc. Therefore, the bundle protocol must ensure that only those entities authorized to send bundles over such constrained environments are actually allowed to do so. All unauthorized entities should be prevented from consuming valuable resources.
捆绑协议的设计理念是，它将在资源稀缺的网络上运行。例如，网络可能具有有限的带宽、有限的连接性、中继节点中受限的存储等。因此，捆绑协议必须确保只有授权在此类受限环境中发送捆绑包的实体才允许这样做。应防止所有未经授权的实体消耗宝贵的资源。
Likewise, because of the potentially long latencies and delays involved in the networks that make use of the bundle protocol, data sources should be concerned with the integrity of the data received at the intended destination(s) and may also be concerned with ensuring confidentiality of the data as it traverses the network. Without integrity, the bundle payload data might be corrupted while in transit without the destination able to detect it. Similarly, the data source can be concerned with ensuring that the data can only be used by those authorized, hence the need for confidentiality.
类似地，由于使用捆绑协议的网络中涉及的潜在长延迟和延迟，数据源应关注在预定目的地接收的数据的完整性，并且还可能关注在数据穿越网络时确保数据的机密性。如果没有完整性，捆绑负载数据可能在传输过程中损坏，而目标无法检测到它。同样，数据源可以确保数据只能由授权人员使用，因此需要保密。
Internal to the bundle-aware overlay network, the bundle nodes should be concerned with the authenticity of other bundle nodes as well as the preservation of bundle payload data integrity as it is forwarded between bundle nodes.
在bundle感知覆盖网络内部，bundle节点应关注其他bundle节点的真实性，以及在bundle节点之间转发时保持bundle有效负载数据的完整性。
As a result, bundle security is concerned with the authenticity, integrity, and confidentiality of bundles conveyed among bundle nodes. This is accomplished via the use of three independent security-specific bundle blocks, which may be used together to provide multiple bundle security services or independently of one another, depending on perceived security threats, mandated security requirements, and security policies that must be enforced.
因此，bundle安全性与bundle节点之间传输的bundle的真实性、完整性和机密性有关。这是通过使用三个独立的特定于安全的捆绑包块来实现的，这些捆绑包块可以一起使用以提供多个捆绑包安全服务，也可以相互独立，具体取决于感知到的安全威胁、强制执行的安全要求和必须强制执行的安全策略。
The Bundle Authentication Block (BAB) ensures the authenticity and integrity of bundles on a hop-by-hop basis between bundle nodes. The BAB allows each bundle node to verify a bundle's authenticity before processing or forwarding the bundle. In this way, entities that are not authorized to send bundles will have unauthorized transmissions blocked by security-aware bundle nodes.
Bundle身份验证块（BAB）在Bundle节点之间逐跳确保Bundle的真实性和完整性。BAB允许每个捆绑包节点在处理或转发捆绑包之前验证捆绑包的真实性。这样，未经授权发送捆绑包的实体将被具有安全意识的捆绑包节点阻止未经授权的传输。
Additionally, to provide "security-source" to "security-destination" bundle authenticity and integrity, the Payload Security Block (PSB) is used. A "security-source" may not actually be the origination point of the bundle but instead may be the first point along the path that is security-aware and is able to apply security services. For example, an enclave of networked systems may generate bundles but only their gateway may be required and/or able to apply security services. The PSB allows any security-enabled entity along the delivery path, in addition to the "security-destination" (the recipient counterpart to the "security-source"), to ensure the bundle's authenticity.
此外，为了向“安全目的地”捆绑包提供“安全源”的真实性和完整性，使用了有效负载安全块（PSB）。“安全源”实际上可能不是捆绑包的发起点，而是路径上第一个具有安全意识并能够应用安全服务的点。例如，网络系统的飞地可能生成捆绑包，但可能只需要和/或能够应用安全服务。除了“安全目的地”（与“安全源”相对应的接收方）之外，PSB允许交付路径上的任何启用安全的实体，以确保捆绑包的真实性。
Finally, to provide payload confidentiality, the use of the Confidentiality Block (CB) is available. The bundle payload may be encrypted to provide "security-source" to "security-destination" payload confidentiality/privacy. The CB indicates the cryptographic algorithm and key IDs that were used to encrypt the payload.
最后，为了提供有效负载机密性，可以使用机密性块（CB）。捆绑有效载荷可以被加密以向“安全目的地”有效载荷保密性/隐私性提供“安全源”。CB表示用于加密有效负载的加密算法和密钥ID。
Note that removal of strings from the dictionary at a given point in a bundle's end-to-end path, and attendant adjustment of endpoint ID references in the blocks of that bundle, may make it necessary to re-compute values in one or more of the bundle's security blocks.
请注意，在捆绑包的端到端路径中的给定点从字典中删除字符串，并随之调整该捆绑包块中的端点ID引用，可能需要重新计算捆绑包的一个或多个安全块中的值。
Bundle security must not be invalidated by forwarding nodes even though they themselves might not use the Bundle Security Protocol. In particular, the sequencing of the blocks in a forwarded bundle must not be changed as it transits a node; received blocks must be transmitted in the same relative order as that in which they were
转发节点不得使捆绑包安全性失效，即使它们本身可能不使用捆绑包安全协议。特别是，在转发包传输节点时，转发包中块的顺序不得改变；接收到的数据块必须以与发送它们时相同的相对顺序进行传输
received. While blocks may be added to bundles as they transit intermediate nodes, removal of blocks that do not have their 'Discard block if it can't be processed' flag in the block processing control flags set to 1 may cause security to fail.
收到。虽然块可以在传输中间节点时添加到捆绑包中，但删除块处理控制标志中未将其“无法处理时丢弃块”标志设置为1的块可能会导致安全性失败。
Inclusion of the Bundle Security Protocol in any Bundle Protocol implementation is RECOMMENDED. Use of the Bundle Security Protocol in Bundle Protocol operations is OPTIONAL.
建议在任何捆绑协议实现中包含捆绑安全协议。在捆绑协议操作中使用捆绑安全协议是可选的。
The "dtn:" URI scheme has been provisionally registered by IANA. See http://www.iana.org/assignments/uri-schemes.html for the latest details.
“dtn:”URI方案已由IANA临时注册。看见http://www.iana.org/assignments/uri-schemes.html 了解最新详情。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", RFC 3986, STD 66, January 2005.
[URI]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 3986，STD 66，2005年1月。
[URIREG] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", RFC 4395, BCP 115, February 2006.
[URIREG]Hansen，T.，Hardie，T.，和L.Masinter，“新URI方案的指南和注册程序”，RFC 4395，BCP 115，2006年2月。
[ARCH] V. Cerf et. al., "Delay-Tolerant Network Architecture", RFC 4838, April 2007.
[ARCH]V.Cerf等人，“延迟容忍网络架构”，RFC 4838，2007年4月。
[ASN1] "Abstract Syntax Notation One (ASN.1), "ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)," ITU-T Rec. X.690 (2002) | ISO/IEC 8825- 1:2002", 2003.
[ASN1]“抽象语法符号1（ASN.1），“ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范”，ITU-T Rec.X.690（2002）| ISO/IEC 8825-1:2002，2003年。
[BSP] Symington, S., "Bundle Security Protocol Specification", Work Progress, October 2007.
[BSP]Symington，S.，“捆绑安全协议规范”，工作进展，2007年10月。
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[RFC3987]Duerst，M.和M.Suignard，“国际化资源标识符（IRIs）”，RFC 3987，2005年1月。
[SECO] Farrell, S., Symington, S., Weiss, H., and P. Lovell, "Delay-Tolerant Networking Security Overview", Work Progress, July 2007.
[SECO]Farrell，S.，Symington，S.，Weiss，H.，和P.Lovell，“延迟容忍网络安全概述”，工作进展，2007年7月。
[SIGC] Fall, K., "A Delay-Tolerant Network Architecture for Challenged Internets", SIGCOMM 2003 .
[SIGC]Fall，K.，“一种面向挑战性互联网的容迟网络架构”，SIGCOMM 2003。
[TUT] Warthman, F., "Delay-Tolerant Networks (DTNs): A Tutorial", <http://www.dtnrg.org>.
[TUT]Warthman，F.，“延迟容忍网络（DTN）：教程”<http://www.dtnrg.org>.
[UTC] Arias, E. and B. Guinot, ""Coordinated universal time UTC: historical background and perspectives" in Journees systemes de reference spatio-temporels", 2004.
[UTC]Arias，E.和B.Guinot，“协调世界时UTC：历史背景和观点”，收录于《参考时空的日记系统》，2004年。
This was an effort of the Delay Tolerant Networking Research Group. The following DTNRG participants contributed significant technical material and/or inputs: Dr. Vinton Cerf of Google, Scott Burleigh, Adrian Hooke, and Leigh Torgerson of the Jet Propulsion Laboratory, Michael Demmer of the University of California at Berkeley, Robert Durst, Keith Scott, and Susan Symington of The MITRE Corporation, Kevin Fall of Intel Research, Stephen Farrell of Trinity College Dublin, Peter Lovell of SPARTA, Inc., Manikantan Ramadas of Ohio University (most of Section 4.1), and Howard Weiss of SPARTA, Inc. (text of Section 8).
这是耐延迟网络研究小组的一项工作。以下DTNRG参与者贡献了重要的技术材料和/或输入：谷歌喷气发动机实验室的文顿·瑟夫博士、Scott Burleigh、Adrian Hooke和Leigh Torgerson、加州大学伯克利分校的Michael Demmer、Robert Durst、基思、和MITRE公司的YE；英特尔研究院的凯文·法尔、都柏林三一学院的斯蒂芬·法雷尔、斯巴达公司的彼得·洛维尔、俄亥俄大学的曼尼坎坦·拉马达斯（第4.1节的大部分内容）和斯巴达公司的霍华德·韦斯（第8节的正文）。
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.
Authors' Addresses
作者地址
Keith L. Scott The MITRE Corporation 7515 Colshire Drive McLean, VA 21102 US
基思·L·斯科特米特尔公司美国弗吉尼亚州麦克莱恩科尔郡大道7515号，邮编21102
Phone: +1 703 983 6547
Fax: +1 703 983 7142
EMail: kscott@mitre.org
Phone: +1 703 983 6547
Fax: +1 703 983 7142
EMail: kscott@mitre.org
Scott Burleigh NASA Jet Propulsion Laboratory 4800 Oak Grove Dr. Pasadena, CA 91109-8099 US
斯科特·伯利美国宇航局喷气推进实验室4800橡树林帕萨迪纳博士，加利福尼亚州91109-8099
Phone: +1 818 393 3353
Fax: +1 818 354 1075
EMail: Scott.Burleigh@jpl.nasa.gov
Phone: +1 818 393 3353
Fax: +1 818 354 1075
EMail: Scott.Burleigh@jpl.nasa.gov
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 at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78和www.rfc-editor.org/copyright.html中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.