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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
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はインターネットStandardのどんなレベルの候補ではありません。 IETFは、いかなる目的のためにと、公開する決定が展開されたプロトコルとセキュリティ、輻輳制御、または不適切な相互作用のようなもののためにIETFレビューに基づいていない特定のノートに、このRFCのフィットネスの知識を負いません。 RFC Editorはその裁量でこの文書を公開することを選択しました。このドキュメントの読者は実現と展開のためにその値を評価する際に警戒する必要があります。詳細については、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
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遅延バインディング
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）であり、このグループにアクティブな貢献者のすべての合意を表しています。このプロトコルは、インターネット上で使用されている場合は、セキュリティおよび輻輳制御のための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 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).
BPは、与えられたインターネット内の通信のために、「ネイティブ」インターネットプロトコルを使用して図1に示すように、標準的なプロトコル・スタック内のBPの位置です。直前での「インターネット」は一般的な意味で使用され、必ずしもTCP / IPを参照していないことに注意してください。共通バンドルプロトコルおよび特定のインターネットプロトコルスイートとの間のインタフェースは、「収束層アダプタ」と呼ばれます。図1は、3つの異なるトランスポート及びネットワークプロトコル（示さ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 --->|
| | | |
Figure 1: The Bundle Protocol Sits at
the Application Layer of the Internet Model
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ノードをバンドル収束層アダプタの動作はインターネットの特定のタイプを介してデータを転送するために使用します。 （ただし、文書には、コンバージェンス層でそれぞれのアダプタによって提供されなければならないサービスを議論しません。）
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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.
バンドル - バンドルはDTNバンドルプロトコルのプロトコル・データ・ユニットです。各束は、様々な目的を果たすプロトコルデータ、2つ以上の「ブロック」の配列を含みます。同じバンドル（DTNプロトコルデータの同じ単位）の複数のインスタンスは、ネットワークの異なる部分に同時に存在するかもしれない - おそらく異なる表現に - 一つ以上のバンドルノードにローカルメモリ内及び/又はノード間の輸送中。バンドルノードの動作の文脈では、バンドルは、そのノードのローカルメモリ内にあるネットワーク内のいくつかの束のインスタンスです。
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.
断片 - 断片は、そのペイロードブロック部分ペイロードを含む束です。名目ペイロードまたは断片ペイロードのいずれか - - 断片ペイロードは最初のNバイトまたはいくつかの他のペイロードの最後のNバイトのいずれかである、長さMの、例えば、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 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 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.
バンドルプロトコルエージェント - ノードのバンドルプロトコルエージェント（BPA）は、BPサービスを提供し、バンドルプロトコルの手順を実行するノードのコンポーネントです。それはそうする方法は、完全実装の問題です。例えば、BPAの機能は、個別に各ノードに符号化されるかもしれません。これは、単一のコンピュータ上でのバンドル任意の数のノードによって共通に使用される共有ライブラリとして実装されるかもしれません。それは、そのサービスの1つまたは複数のコンピュータ上でバンドルノードの任意の数のプロセス間またはネットワーク通信を介して起動されるデーモンとして実装されるかもしれません。それは、ハードウェアで実装される可能性があります。
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サービスを利用するノードのコンポーネントです。次にアプリケーションエージェントは2つの要素の管理要素と、アプリケーション固有の要素を有しています。 AAコンストラクトのアプリケーション固有の要素は、の送信を要求の配信を受け付け、アプリケーション固有のアプリケーションデータユニットを処理します。 BPA及びAAのアプリケーション固有の要素との間の唯一のインターフェースは、BPサービスインタフェースです。行政管理記録（ステータスレポートと保管信号）のA-A構築物およびリクエスト送信の要素、それはの配信を受け入れ、ノードが受信する任意保管信号を処理します。 BPサービス・インタフェースに加えて、BPA及び特定の状況下で行動を取るために他を指示するためにそれぞれを可能AAの管理要素との間の（概念的な）プライベート制御インターフェースがあります。単にオーバレイネットワーク内の「ルータ」として機能するノードの場合、AAは全くアプリケーション固有の要素を有していなくてもよいです。他のノードのAAのアプリケーション固有の要素は、おそらく他のアプリケーションの数に多重DTN通信サービスを提供する、任意の複雑なアプリケーション機能を実行することができます。 BPAと同様に、AAは、その機能を実行する方法は、全体的に実装問題です。具体的には、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 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.
バンドルエンドポイント - Aバンドルエンドポイント（または単に「エンドポイント」）は、すべてのいくつかの単一のテキスト文字列でBPのために自分自身を識別するゼロ以上バンドルノードの集合であり、単に、この文書で、「バンドルエンドポイントID」と呼ばれる（あるいは「エンドポイントID」、エンドポイントIDは、以下のセクション4.4に詳細に記載されています）。 「シングルトン」のエンドポイントと呼ばれる複数のノードが含まれていませんエンドポイントの特殊なケース。すべてのバンドルノードには、少なくとも1つのシングルトンのエンドポイントのメンバーである必要があります。シングルトンは、エンドポイントの最も身近な一種ですが、一般的には、エンドポイントの概念が広いことを意味しています。例えば、センサネットワーク内のノードは単一の共通のエンドポイントIDによって自身を識別するバンドルノードのセットを構成し、したがって、単一のバンドル終点を形成し得ます。 *注*すぎる所与のバンドルノードが複数のエンドポイントIDで自身を識別し、したがって、複数のバンドルのエンドポイントのメンバーであるかもしれないこと。
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を（エンドポイントに転送する「エニーキャスト」操作と機能的に類似している場合にインタネットの中には）;またはシングルトンエンドポイントに登録されている（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:
登録 - 登録が特定のエンドポイントで指定されたノードのメンバーシップを特徴付けるステートマシンです。登録の任意の数は、同時に与えられたエンドポイントに関連付けられてもよく、登録の任意の数が同時に指定されたノードに関連付けられてもよいです。アクティブまたはパッシブ：任意の単一の登録は任意の時点で2つの状態のいずれかでなければなりません。登録は、常に関連する「配信の失敗アクション」、「成果」であるバンドル（下記参照）、その登録を受け、登録が受動状態にある時に受信されたときに取られるべき作用を有します。配信失敗アクションは、次のいずれかでなければなりません。
* defer "delivery" (see below) of the bundle subject to this registration until (a) this bundle is the least recently 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
この登録にバンドル対象の*延期「配信」（下記参照）は、（a）このバンドルは、この登録の最も最近のすべての束から受け取った現在、成果対象であり、（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.
欠失は、破棄 - バンドルプロトコルエージェントは単にバンドルのすべての操作を中止し、機能的にそれへの参照をすべて消去することにより、バンドルを「破棄します」。これが達成されたことにより、具体的な手順は、実装の問題です。バンドルは黙って破棄されます。すなわち、バンドルの廃棄は、管理レコードの生成をもたらしません。 「保持制約は、」廃棄されるからバンドルを防ぐ束状態の要素です。それは任意の保持の制約を有しているバンドルは破棄することはできません。 、次いで任意バンドルの保持制約のすべてを除去する工程と、バンドルプロトコルエージェント（詳細については、セクション5.13を参照して提供されているこのような通知が保証されている）バンドルの欠失の終点レポートに通知することにより、いくつかの異常状態に応じてバンドルを「削除します」廃棄するバンドルを有効にします。
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.
上記の定義は、任意の特定の実装アーキテクチャに向かってバイアスを最小にするように指定するバンドルプロトコルの操作を可能にするために意図されています。この仕様に準拠する可能性がある相互運用可能な実装モデルの範囲を例示するために4つの例示的なアーキテクチャを以下に簡単に説明されています。
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.
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.
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.
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.
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つは、ペイロードブロックであってもよいです。シーケンス内の最後のブロックは、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.
設計における重要な戦略的要素は自己区切りの数値（SDNVs）の使用です。 SDNV符号化方式は密接オブジェクト識別子値[ASN1]内のサブ識別子のための抽象構文記法1の基本符号化規則から適合されています。 SDNVは、最後のその最上位ビット（MSB）がゼロに設定されている、Nオクテットで符号化された数値です。 SDNV内の他のすべてのオクテットのMSBはSDNVにエンコードされた値は、単一のビット列にSDNVの各オクテットの7つの最下位ビットを連結することによって得られた符号なし2進数で1に設定されなければなりません。
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 {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の：= 1 0010 0011 0100 0001 0010 0011 0100 {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：= 100 0010 0011 0100 0100 0010 0011 0100 {1 000000 1} {1 0000100} {0} 0110100 = 10000001 10000100 00110100として符号化されます
0x7F : 0111 1111 = 111 1111 is encoded as {0 1111111} = 01111111
0x7Fの：= 111 1111 0111 1111は、{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の倍数を作るために上位ゼロビットで埋め。符号化される実際のデータのすべての7ビットのオーバーヘッドの、すなわち、1ビット、7：またSDNVフィールドの大きさには理論的な制限はないが、SDNV方式のオーバーヘッドが1であることに留意されたいです。したがって、7オクテットの値（NO先行ゼロを持つ56ビットの量）は、8オクテットSDNVで符号化されるであろう。 8オクテット値（無先行ゼロを持つ64ビットの量）を含有する9つのオクテットが続く6先行ゼロビットでパディング値の上位ビットを含む10オクテットSDNV（1つのオクテットで符号化されます）値の63ビットを残り。オーバーヘッドの148ビットがSDNVに直接1024ビットRSA暗号化キーを符号化する際に消費されます。一般的に、無先行ゼロを有するNビット量がCEIL整数天井関数であるSDNV占有はceil（N / 7）オクテットで符号化されます。
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).
バンドルプロトコルの実装は、無効な数値として、（ - 1 2 ^ 64）よりも大きい整数をコードする任意の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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Bundle Processing Control Flags Bit Layout
図3：バンドル処理制御フラグのビット配置
The bits in positions 0 through 6 are flags that characterize the bundle as follows:
6を介して位置0のビットは次のように束を特徴付けるフラグです。
0 -- Bundle is a fragment.
0 - バンドルフラグメントです。
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.
13を介して位置7のビットは、サービスのバンドルのクラスを示すために使用されます。位置8および7のビットより高い値は、より高い優先度であると、バンドルの優先度を示す2ビットの優先度フィールドを構成する：00 =バルク、01 =正常、10 =迅速に、11は将来の使用のために予約されています。このフィールドの中で、ビット8が最上位ビットです。 13を介して位置9のビットは将来の使用のために予約されています。
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：なし」である場合（下記参照）、その後、バンドルを一意に識別可能ではないとのバンドルIDに依存しているすべてのバンドルプロトコル機能は、したがって、無効にする必要があります：バンドルの親権転送要求フラグは、ゼロでなければなりません「バンドルが断片化してはならない」フラグが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 |
+-+-+-+-+-+-+-+
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" >
<スキーム名>：<スキーマ固有部分、または「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.
バンドルブロックは、バンドルプロトコルの様々な目的のためにエンドポイントIDの数を引用します。多くは、必ずしもすべてが、与えられたバンドルのブロックで参照されるエンドポイント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の参照はSDNVsの順序対です：
o The first SDNV contains the offset within the dictionary of the first character of the referenced endpoint ID's scheme name.
最初SDNV oを参照エンドポイントIDのスキーム名の最初の文字の辞書内のオフセットが含まれています。
o The second SDNV contains the offset within the dictionary of the first character of the referenced endpoint ID's SSP.
二SDNV oを参照エンドポイント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の<スキーム名>によって識別されるスキームは、完全に解析し、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ヌルエンドポイントIDの表現で最小で使用される「DTN」方式、「DTN：なし」。ヌルエンドポイントへバンドルの転送は禁忌されることはありません、そしてヌルエンドポイントの最小受信グループは空集合です。
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の表現をサポートすることができる（例えば、国際化リソース識別子（虹彩）; [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.
（を含むが、バンドルセキュリティプロトコル[BSP]に限定されない）補助DTNプロトコル仕様はこれらのプロトコルに準拠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 (*)] |
+----------------+----------------+---------------------------------+
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.
バンドル処理制御（「PROC。」）のプライマリバンドルブロック内のフラグフィールドがSDNVであり、したがって、可変長です。 3オクテット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であり、したがって、可変長です。 4オクテットの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.
プライマリバンドルブロック内の8つのオフセットの各フィールドはSDNVであり、したがって、可変長です。 2オクテットのSDNVsは、表現の便宜上、ここで示されています。
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であり、したがって、可変長です。 4オクテットの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であり、したがって、可変長です。 4オクテットの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であり、したがって、可変長です。 4オクテットの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であり、したがって、可変長です。 4オクテットの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であり、したがって、可変長です。 4オクテットの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であり、したがって、可変長です。 4オクテットの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であり、したがって、可変長です。 1オクテット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であり、したがって、可変長です。 2オクテットの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.
処理制御フラグをバンドル：バンドル処理制御フラグフィールドは、上記のセクション4.2で説明したバンドル処理制御フラグを含むSDNVあります。
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.
先SSPは、オフセット：先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.
ソース方式はオフセット：ソーススキームオフセットフィールドは、バンドルの公称ソースのエンドポイント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.
ソースSSPは、オフセット：ソース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.
レポート-へのSSPは、オフセット：レポート-への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").
作成タイムスタンプは：作成タイムスタンプは、一緒にソースエンドポイントID及び（バンドルがフラグメントである場合）フラグメントオフセット及びペイロード長と、バンドルを識別するのに役立つ、SDNVsの対です。第二は、バンドルの作成タイムスタンプのシーケンス番号である一方、タイムスタンプの最初のSDNVは、バンドルの作成時刻です。作成時間をバンドルするのは時間である - 2000年の開始以来、秒単位で表さ、協定世界時（UTC）で[UTC]を拡張 - 送信要求がバンドルの作成をもたらしたことが受信されました。シーケンスカウントがゼロにリセットされてもよいソースノードのバンドルプロトコルエージェントによって管理される単調に増加する正の整数カウンタ（その送信要求を受信した時刻のような）最新の値であるときはいつでも1秒現在時刻進みます。ソースバンドルプロトコルエージェントは、同じソースエンドポイントIDとバンドル作成タイムスタンプを持つ2つの異なるバンドルを作成してはいけません。ソースエンドポイントIDの組み合わせおよび作成タイムスタンプをバンドルは、したがって、（ソースエンドポイントIDが「：なしDTN」ではない提供された）受信アプリケーションによって承認されることを可能にする、単一の送信要求を識別するのに役立ちます。
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.
辞書長さ：辞書Lengthフィールドは、辞書バイト配列の長さが含まれてい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のヌル終端スキーム名とのSSPを連結することによって形成されたバイトの配列である潜在的に、他のTBD DTNプロトコルブロック内のフィールドによって参照される他のエンドポイントのID 。その長さは、辞書長さフィールドの値で与えられます。
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ビットの符号なし2進整数として表さ。バンドルブロックタイプコード1ブロックは、バンドルペイロードブロックであることを示しています。 255 192ブロックタイプ・コードは、この仕様で定義され、民間および/または実験的な使用のために用意されていませんされています。ブロックタイプのコードの他のすべての値は、将来の使用のために予約されています。
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参照はSDNVsのペアです。各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) /
+-----------+-----------+-----------+-----------+
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) /
+-----------+-----------+-----------+-----------+
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.
ブロック処理制御フラグ：ブロック処理制御フラグフィールドは、上記の4.3節で述べたブロック処理制御フラグが含まれていSDNVです。
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
すなわち、バンドルペイロードブロックが「ブロックが含まれている制限を持つ前のセクションの標準形式に従っています
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 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.
このセクションでは、セクション6で義務付けバンドル処理手順は、各バンドルノードのバンドルプロトコルエージェントとアプリケーションエージェント管理要素の動作を支配します。彼らは徹底的にも排他的でもありません。すなわち、（を含むが、バンドルセキュリティプロトコル[BSP]に限定されない）補助DTNプロトコル仕様は、追加措置がこれらの手順で指定された接合部で採取されることを必要とする場合があります。補助プロトコルに準拠した実装が原因に与えられ、着信または発信束の処理を終了することを、オーバーライドまたはそれらがいくつかのケースでは、例えば、必要により議論の余地の手順を行うことができることを除いて、義務付けバンドルプロトコル手順に優先してはならないような追加的な措置そのプロトコルによって認識障害状態。
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.
バンドルのすべての最初の送信は、ノードのアプリケーションエージェントによって提示された送信要求をバンドルする応答です。管理レコード（バンドルステータスレポート又は保管信号）「を生成」するために必要な場合に、バンドルプロトコル剤自体は、そのレコードを運ぶ、送信すべき新しいバンドルを引き起こす原因です。概念では、バンドルプロトコルエージェントは、以下の第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「バンドル受信状態報告は、」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「バンドル転送ステータスレポートは」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：管理輸送はこのバンドル伝送のために要求され、更に、ソースノードによって保管受付が必要な場合は、バンドルプロトコル剤のいずれかは、バンドルの保管を受け入れるにコミットしなければならない - ステップ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：バンドルの送信が開始されます。 「：なしDTN」とリテンション制約「保留派遣」とのアウトバウンドバンドルがnullのエンドポイントIDの現在の管理人のエンドポイントIDを設定して、バンドルの送信要求のパラメータごとに作成する必要があります。バンドルのソースエンドポイントIDは、ノードがメンバーまたはヌルエンドポイントID「：なしDTN」であるエンドポイントのIDのいずれかでなければなりません。
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：バンドルプロトコルエージェントは、転送は、特に図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：バンドルの保管転送（バンドル処理フラグフィールドで）フラグを要求された場合、5.10.2項で定義された保管転送手順が従わなければならない、1に設定されています。
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：転送のために選択された各エンドポイントの場合、バンドルプロトコル剤がそのエンドポイントの最小受信グループを構成するノードに、バンドルの送信を行うために選択された収束層アダプタ（S）のサービスを呼び出す必要があります。バンドルは、各収束層アダプタによって送信される時刻を決定することは、実装上の問題です。
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：保持制約「派遣保留中は」バンドルに追加する必要があります。
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.
そのブロック内のブロックの処理フラグがステータスレポートは、このイベントに理由コードと、その後バンドル受信状況報告を要求していることを示している場合*「ブロック理解不能」バンドルのレポート-する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.
*そのブロック内のブロック処理フラグがNEITHERバンドルが削除されなければならないNORブロックが廃棄されなければならないことをことを示す場合、バンドルプロトコルエージェントはブロック処理フラグを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 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.
ステップ4：バンドルの保管転送（バンドル処理フラグフィールドで）フラグを要求した場合は1に設定され、バンドルは同じソースエンドポイントID、作成タイムスタンプを有し、（バンドルがフラグメントである場合）フラグメントオフセット及びペイロード長さ（a）は破棄され、（b）は、現在保持制約「カストディ受け入れ」を持っているされていない別のバンドルには、親権の転送の冗長性を処理する必要があります。宛先シングルトンエンドポイントではないが、本明細書で定義されていないバンドルの保管転送の冗長性を処理するためのステップ5の手順からそうでない場合には、処理を進めます。宛先シングルトンエンドポイントであるバンドルは、バンドルプロトコル剤」は、このバンドルの現在のカストディアン宛理由コード「冗長受信」、このバンドルの「失敗」保管信号を生成し、このバンドルのを除去することにより、管理輸送冗長性を処理する必要があります発送は、「保持制約を保留します。
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をエンドポイントに宛て、生成されるべきです。このステータスレポートは唯一のアプリケーションエージェントがそのペイロードを処理したことはない、ペイロードがアプリケーションエージェントに配信されたと述べていることに注意してください。
* 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.)
バンドルのサイズは、バンドルを「断片化」によって減少させることができます。ペイロード第Nと最後（Mである - 原稿束と同じソースエンドポイントIDおよび作成タイムスタンプを有する新しいバンドル - そのペイロードサイズがMであるバンドルを断片化するためには、2つの「断片」に置き換えることです - 原稿束のペイロードの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.
「ブロック毎断片で複製されなければならない」ビットが1に設定されている場合は、O、ブロックは、すべてのフラグメントで複製されなければなりません。
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.
バンドルプロトコルエージェントは、バンドルのための新しい現在のカストディアンをアサートする必要があります。これは、ノードが登録されているシングルトンエンドポイントの1つのエンドポイント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, 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.
保管転写不良の決意すると、バンドルプロトコルエージェントによって実行されるアクションは、実装固有のものであり、障害の性質に依存し得ます。親権の転写不良が親権転送タイマの満了から推測されたか、「枯渇ストレージ」理由コードと「失敗」親権信号によってアサートされた場合、例えば、バンドルプロトコルエージェントは多分に、バンドルを再転送することを選択するかもしれません別のルート（5.4節）。 「冗長受信」理由コードと「失敗」の親権信号の受信は、他の一方で、バンドルプロトコルエージェントは、バンドルの身柄を解放すると、管理転送タイマーのカウントダウン間隔を計算するためのアルゴリズムを改訂することがあります。
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:
すべての管理レコードは、タイプ固有のフォーマットで記録内容に続く行政記録フラグの4ビット、続いて4ビットのレコード・タイプ・コードから成ります。次のようにレコードタイプコードが定義されています。
+---------+--------------------------------------------+
| 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. |
+---------+--------------------------------------------+
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時間が示される第2の開始からナノ秒の数を示す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) |
+----------------+----------------+----------------+----------------+
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であり、したがって、可変長です。 3オクテット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であり、したがって、可変長です。 3オクテット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.
作成タイムスタンプフィールドは、対象バンドルの主要ブロックで作成タイムスタンプフィールドを複製します。そのようなものとして、それらはSDNVs（上記のセクション4.5.1を参照）であるため、可変長です。 4オクテットのSDNVsは、表現の便宜上、ここで示されています。
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であり、したがって、可変長です。 3オクテット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. |
+----------+--------------------------------------------+
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バイトのフィールド。ここで提供されるステータスレポート理由コードのリストは完全でも、排他的でもありません。 （を含むが、バンドルセキュリティプロトコル[BSP]に限定されない）補助DTNプロトコル仕様は、追加の理由コードを定義することができます。次のようにステータスレポート理由コードが定義されています。
+---------+--------------------------------------------+
| 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.
断片の長さ：バンドルフラグメントビットはステータスフラグに設定されている場合、被験者束のペイロードの長さがここに含まれています。
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.
受信時刻は、（存在する場合）：束受信ビットはステータスフラグに設定されている場合、バンドルを報告しているノードで受信された時刻を示すDTN時間がここに含まれています。
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.
転送の時間は、（存在する場合）：束転送ビットはステータスフラグに設定されている場合、バンドルが第1の報告ノードに転送された時刻を示すDTN時間がここに含まれています。
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.
配信の時間は（存在する場合）：バンドル配信ビットはステータスフラグに設定されている場合、バンドルを報告しているノードに配信された時刻を示すDTN時間がここに含まれています。
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.
削除の時間は、（存在する場合）：バンドル削除ビットはステータスフラグに設定されている場合、バンドルを報告しているノードで削除された時刻を示すDTN時間がここに含まれています。
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) |
+----------------+----------------+----------------+----------------+
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であり、したがって、可変長です。 3オクテット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であり、したがって、可変長です。 4オクテットの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.
作成タイムスタンプフィールドは、対象バンドルの主要ブロックで作成タイムスタンプフィールドを複製します。そのようなものとして、それらはSDNVs（上記のセクション4.5.1を参照）であるため、可変長です。 4オクテットのSDNVsは、表現の便宜上、ここで示されています。
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であり、したがって、可変長です。 3オクテット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. |
+---------+--------------------------------------------+
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.
断片の長さ：バンドルフラグメントビットはステータスフラグに設定されている場合、被験者束のペイロードの長さがここに含まれています。
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のバイト単位の長さ。
Source Endpoint ID text: The text of the source endpoint ID of the bundle to which the signal applies.
ソースエンドポイントIDのテキスト：信号が適用されるバンドルのソースエンドポイント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：ペイロードこの管理レコードは、バンドルプロトコルエージェントに提示する必要があり、バンドルの送信要求。
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.
エンド・ツー・エンドのバンドルプロトコルが正常に動作するには、「収束層」と呼ばれるもので、基本的なプロトコルの動作に依存します。これらのプロトコルは、ノード間の通信を行います。プロトコルの多様な限り、各収束層プロトコルアダプタは、バンドルプロトコルエージェントにサービスの定義された最小セットを提供するように、この目的を果たすことができます。このコンバージェンスレイヤサービスの仕様では、これらのサービスを列挙します。
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
収束層プロトコルを介して到達可能である指定されたエンドポイントのIDによって識別されるエンドポイントの最小受信グループ内のすべてのバンドルノードにバンドルを送信O。そして
o delivering to the bundle protocol agent a bundle that was sent by a remote bundle node via the convergence layer protocol.
バンドルプロトコルエージェントに収束層プロトコルを介してリモート・バンドル・ノードによって送信されたバンドルを提供O。
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.
ここで指定した収束層サービスインタフェースは、徹底的でも排他的でもありません。すなわち、（を含むが、バンドルセキュリティプロトコル[BSP]に限定されない）補助DTNプロトコル仕様は、追加のサービスを提供するために、それらのプロトコルに準拠した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].
バンドル・プロトコルは、その設計の当初から懸念にセキュリティをとっています。それは、常にセキュリティサービスがバンドルプロトコルの使用で必要とされるだろうと仮定しました。結果として、バンドルプロトコルセキュリティアーキテクチャおよび利用可能なセキュリティ・サービスは、添付文書で指定され、バンドルセキュリティプロトコル仕様[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.
それはバンドルノード間で転送されるように、バンドル認識オーバーレイネットワークの内部は、バンドルノードは、他のバンドルノードの真正性並びにバンドルペイロードデータの整合性の維持に関与すべきです。
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.
結果として、バンドルセキュリティは、バンドルノード間搬送バンドルの真正性、完全性、および機密性に関するものです。これは、知覚セキュリティの脅威、義務付けられたセキュリティ要件、および施行しなければならないセキュリティポリシーに応じて、互いに独立して複数のバンドルのセキュリティサービスを提供したりするために一緒に使用することができる三つの独立したセキュリティ特定のバンドルブロックの使用によって達成されます。
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.
バンドル認証ブロック（BAB）バンドルノード間のホップバイホップに基づいてバンドルの真正性および完全性を保証します。 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）が使用されています。 「セキュリティ・ソースは、」実際のバンドルの起点ではないかもしれないが、代わりにセキュリティを意識し、セキュリティサービスを適用することが可能である経路に沿って第1点であってもよいです。例えば、ネットワークシステムの飛び地は、バンドルを生成することができるだけで、そのゲートウェイが必要とされ得る、および/またはセキュリティサービスを適用することができます。 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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]バーナーズ - リー、T.、フィールディング、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]ハンセン、T.、ハーディ、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.サーフら。ら、 "ディレイトレラントネットワークアーキテクチャ"、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）、Canonicalの符号化規則（CER）と識別符号化規則（DER）の明細書において、" ITU-T勧告。 X.690（2002）| ISO / IEC 8825- 1：2002" 、2003年。
[BSP] Symington, S., "Bundle Security Protocol Specification", Work Progress, October 2007.
[BSP]シミントン、S.、 "バンドルセキュリティプロトコル仕様"、作業の進捗状況、2007年10月。
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[RFC3987] Duerst、M.およびM. Suignard、 "国際化リソース識別Fiers（IRI）"、RFC 3987、2005年1月。
[SECO] Farrell, S., Symington, S., Weiss, H., and P. Lovell, "Delay-Tolerant Networking Security Overview", Work Progress, July 2007.
[SECO]ファレル、S.、シミントン、S.、ワイス、H.、およびP.ラヴェル、 "遅延耐性ネットワークセキュリティの概要"、作業の進捗状況、2007年7月。
[SIGC] Fall, K., "A Delay-Tolerant Network Architecture for Challenged Internets", SIGCOMM 2003 .
[SIGC]、K.秋、「チャレンジインターネットのための遅延・トレラント・ネットワーク・アーキテクチャ」、SIGCOMM 2003。
[TUT] Warthman, F., "Delay-Tolerant Networks (DTNs): A Tutorial", <http://www.dtnrg.org>.
[TUT] Warthman、F.、 "遅延トレラントネットワーク（DTNs）：チュートリアル"、<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]アリアス、E.およびB.ギノー「」協定世界時のUTC：歴史的背景と展望「でJournees SYSTEMESデ基準時空間temporels」2004年。
Appendix A. Contributors
付録A.協力者
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).
これは、遅延耐性ネットワーク研究グループの努力でした。グーグル、スコット・バーレイ、エイドリアンフックの博士ヴィントンサーフ、及びジェット推進研究所のリーTorgerson、カリフォルニア大学バークレー校のマイケル・Demmer、ロバート・ダースト、キース・スコット：以下DTNRG参加者は、重要な技術的な材料および/または入力を拠出しましたMITRE社のスーザン・シミントン、インテル・リサーチのケビン秋、トリニティ・カレッジ・ダブリンのスティーブン・ファレル、SPARTA、Inc.の、オハイオ大学のManikantan Ramadas（4.1節のほとんど）のピーター・ラヴェルとSPARTA、Inc.のハワード・ワイス（第8のテキスト）。
Appendix B. Comments
付録B.コメント
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）Webサイトをhttp://www.dtnrg.orgに位置しています。
Authors' Addresses
著者のアドレス
Keith L. Scott The MITRE Corporation 7515 Colshire Drive McLean, VA 21102 US
キース・L.スコット・ザ・MITRE社7515 Colshireドライブマクリーン、バージニア州21102米国
Phone: +1 703 983 6547 Fax: +1 703 983 7142 EMail: kscott@mitre.org
電話：+1 703 983 6547ファックス：+1 703 983 7142 Eメール：kscott@mitre.org
Scott Burleigh NASA Jet Propulsion Laboratory 4800 Oak Grove Dr. Pasadena, CA 91109-8099 US
スコット・バーレイNASAジェット推進研究所4800オークグローブ博士はパサデナ、カリフォルニア州91109から8099米
Phone: +1 818 393 3353 Fax: +1 818 354 1075 EMail: Scott.Burleigh@jpl.nasa.gov
電話：+1 818 393 3353ファックス：+1 818 354 1075 Eメール：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。