[要約] RFC 5050は、Bundle Protocolの仕様を定義しており、遅延、分断、非信頼性のネットワーク環境でのデータ通信をサポートします。このプロトコルは、リソース制約のあるネットワークや非常に遠隔地の通信など、特殊な環境での通信に使用されます。
Network Working Group K. Scott
Request for Comments: 5050 The MITRE Corporation
Category: Experimental S. Burleigh
NASA Jet Propulsion Laboratory
November 2007
Bundle Protocol Specification
バンドルプロトコル仕様
Status of This Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
IESG Note
IESGノート
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
このRFCは、インターネット標準のレベルの候補者ではありません。IETFは、あらゆる目的のためにこのRFCのフィットネスに関する知識を放棄します。特に、公開する決定は、セキュリティ、混雑制御、または展開プロトコルとの不適切な相互作用のIETFレビューに基づいていないことに注意しています。RFCエディターは、その裁量でこのドキュメントを公開することを選択しました。このドキュメントの読者は、実装と展開の価値を評価する際に注意する必要があります。詳細については、RFC 3932を参照してください。
Abstract
概要
This document describes the end-to-end protocol, block formats, and abstract service description for the exchange of messages (bundles) in Delay Tolerant Networking (DTN).
このドキュメントでは、遅延許容ネットワーキング（DTN）におけるメッセージの交換（バンドル）のエンドツーエンドプロトコル、ブロック形式、および抽象サービスの説明について説明します。
This document was produced within the IRTF's Delay Tolerant Networking Research Group (DTNRG) and represents the consensus of all of the active contributors to this group. See http://www.dtnrg.org for more information.
このドキュメントは、IRTFの遅延耐性ネットワーキング研究グループ（DTNRG）内で作成され、このグループへのすべてのアクティブな貢献者のコンセンサスを表しています。詳細については、http：//www.dtnrg.orgを参照してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Service Description . . . . . . . . . . . . . . . . . . . . . 5
3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Implementation Architectures . . . . . . . . . . . . . . . 9
3.3. Services Offered by Bundle Protocol Agents . . . . . . . . 11
4. Bundle Format . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Self-Delimiting Numeric Values (SDNVs) . . . . . . . . . . 12
4.2. Bundle Processing Control Flags . . . . . . . . . . . . . 13
4.3. Block Processing Control Flags . . . . . . . . . . . . . . 15
4.4. Endpoint IDs . . . . . . . . . . . . . . . . . . . . . . . 16
4.5. Formats of Bundle Blocks . . . . . . . . . . . . . . . . . 17
4.5.1. Primary Bundle Block . . . . . . . . . . . . . . . . . 19
4.5.2. Canonical Bundle Block Format . . . . . . . . . . . . 22
4.5.3. Bundle Payload Block . . . . . . . . . . . . . . . . . 23
4.6. Extension Blocks . . . . . . . . . . . . . . . . . . . . . 24
4.7. Dictionary Revision . . . . . . . . . . . . . . . . . . . 24
5. Bundle Processing . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Generation of Administrative Records . . . . . . . . . . . 25
5.2. Bundle Transmission . . . . . . . . . . . . . . . . . . . 26
5.3. Bundle Dispatching . . . . . . . . . . . . . . . . . . . . 26
5.4. Bundle Forwarding . . . . . . . . . . . . . . . . . . . . 27
5.4.1. Forwarding Contraindicated . . . . . . . . . . . . . . 28
5.4.2. Forwarding Failed . . . . . . . . . . . . . . . . . . 29
5.5. Bundle Expiration . . . . . . . . . . . . . . . . . . . . 29
5.6. Bundle Reception . . . . . . . . . . . . . . . . . . . . . 30
5.7. Local Bundle Delivery . . . . . . . . . . . . . . . . . . 31
5.8. Bundle Fragmentation . . . . . . . . . . . . . . . . . . . 32
5.9. Application Data Unit Reassembly . . . . . . . . . . . . . 33
5.10. Custody Transfer . . . . . . . . . . . . . . . . . . . . . 34
5.10.1. Custody Acceptance . . . . . . . . . . . . . . . . . . 34
5.10.2. Custody Release . . . . . . . . . . . . . . . . . . . 35
5.11. Custody Transfer Success . . . . . . . . . . . . . . . . . 35
5.12. Custody Transfer Failure . . . . . . . . . . . . . . . . . 35
5.13. Bundle Deletion . . . . . . . . . . . . . . . . . . . . . 36
5.14. Discarding a Bundle . . . . . . . . . . . . . . . . . . . 36
5.15. Canceling a Transmission . . . . . . . . . . . . . . . . . 36
5.16. Polling . . . . . . . . . . . . . . . . . . . . . . . . . 36
6. Administrative Record Processing . . . . . . . . . . . . . . . 37
6.1. Administrative Records . . . . . . . . . . . . . . . . . . 37
6.1.1. Bundle Status Reports . . . . . . . . . . . . . . . . 38
6.1.2. Custody Signals . . . . . . . . . . . . . . . . . . . 41
6.2. Generation of Administrative Records . . . . . . . . . . . 44
6.3. Reception of Custody Signals . . . . . . . . . . . . . . . 44
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
図1：バンドルプロトコルは、インターネットモデルのアプリケーションレイヤーにあります
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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".
バンドルノード - バンドルノード（または、このドキュメントのコンテキストでは、単に「ノード」）は、バンドルを送信および/または受信できるエンティティです。最もよく知られているケースでは、バンドルノードは汎用コンピューターで実行される単一のプロセスとしてインスタンス化されますが、一般に定義はより広いことを意図しています。バンドルノードは、オブジェクト指向のオブジェクトであるスレッドである場合がありますオペレーティングシステム、特別な目的のハードウェアデバイスなど。各バンドルノードには、「バンドルプロトコルエージェント」、ゼロ以上の「収束層アダプター」のセット、および「アプリケーションエージェント」の3つの概念コンポーネントがあります。
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）は、ノードが機能的に配置されているインターネットの1つでサポートされている「ネイティブ」インターネットプロトコルのサービスを利用して、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サービスインターフェイスです。AAの管理要素は、管理記録の送信（ステータスレポートと親権シグナル）の送信を要求し、ノードが受信する保管信号の配信を受け入れ、処理します。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.
バンドルエンドポイント - バンドルエンドポイント（または単に「エンドポイント」）は、「バンドルエンドポイントID」と呼ばれる単一のテキスト文字列によって、すべてがBPの目的で自分自身を識別するゼロ以上のバンドルノードのセットです（または、このドキュメントでは、単に単純に「エンドポイント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がエンドポイントのゼロからカーディナリティまでの範囲にあります（この場合、エンドポイントへの転送は「aycast」操作と機能的に類似しています。インタネットの中には）;または（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）バンドルの宛先エンドポイントが登録が関連付けられているエンドポイントである場合にのみ、登録の影響を受ける「配信可能」と見なされます。、および（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）寿命の有効期限など、何らかの理由でバンドルが明示的に削除されます。この仕様では、目的地がシングルトンのエンドポイントではないバンドルの監護権がリリースされる可能性がある条件は定義されていません。バンドルの「監護権」を「拒否」することは、バンドルの監護権を受け入れないことを決定することです。バンドルの「管理ノード」は、バンドルの親権を受け入れ、まだその監護権をリリースしていないノードです。バンドルの「カストディアン」は、唯一のメンバーがバンドルのカストディアルノードの1つであるシングルトンエンドポイントです。
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つの例のアーキテクチャを以下に簡単に説明します。
1. Bundle protocol application server
1. バンドルプロトコルアプリケーションサーバー
A single bundle protocol application server, constituting a single bundle node, runs as a daemon process on each computer. The daemon's functionality includes all functions of the bundle protocol agent, all convergence layer adapters, and both the administrative and application-specific elements of the application agent. The application-specific element of the application agent functions as a server, offering bundle protocol service over a local area network: it responds to remote procedure calls from application processes (on the same computer and/or remote computers) that need to communicate via the bundle protocol. The server supports its clients by creating a new (conceptual) node for each one and registering each such node in a client-specified endpoint. The conceptual nodes managed by the server function as clients' bundle protocol service access points.
単一のバンドルノードを構成する単一のバンドルプロトコルアプリケーションサーバーは、各コンピューターでデーモンプロセスとして実行されます。デーモンの機能には、バンドルプロトコルエージェントのすべての機能、すべての収束層アダプター、およびアプリケーションエージェントの管理およびアプリケーション固有の要素の両方が含まれます。アプリケーションエージェントのアプリケーション固有の要素は、サーバーとして機能し、ローカルエリアネットワークでバンドルプロトコルサービスを提供します。これは、アプリケーションプロセス（同じコンピューターおよび/またはリモートコンピューター）からのリモートプロシージャコールに応答します。バンドルプロトコル。サーバーは、それぞれに新しい（概念的な）ノードを作成し、クライアント指定のエンドポイントにそのような各ノードを登録することにより、クライアントをサポートします。サーバーによって管理される概念ノードは、クライアントのバンドルプロトコルサービスアクセスポイントとして機能します。
2. Peer application nodes
2. ピアアプリケーションノード
Any number of bundle protocol application processes, each one constituting a single bundle node, run in ad-hoc fashion on each computer. The functionality of the bundle protocol agent, all convergence layer adapters, and the administrative element of the application agent is provided by a library to which each node process is dynamically linked at run time. The application-specific element of each node's application agent is node-specific application code.
それぞれが単一のバンドルノードを構成するバンドルプロトコルアプリケーションプロセスの数は、各コンピューターでアドホックファッションで実行されます。バンドルプロトコルエージェント、すべての収束層アダプター、およびアプリケーションエージェントの管理要素の機能は、各ノードプロセスが実行時に動的にリンクされるライブラリによって提供されます。各ノードのアプリケーションエージェントのアプリケーション固有の要素は、ノード固有のアプリケーションコードです。
3. Sensor network nodes
3. センサーネットワークノード
Each node of the sensor network is the self-contained implementation of a single bundle node. All functions of the bundle protocol agent, all convergence layer adapters, and the administrative element of the application agent are implemented in simplified form in Application-Specific Integrated Circuits (ASICs), while the application-specific element of each node's application agent is implemented in a programmable microcontroller. Forwarding is rudimentary: all bundles are forwarded on a hard-coded default route.
センサーネットワークの各ノードは、単一のバンドルノードの自己完結型の実装です。バンドルプロトコルエージェント、すべての収束層アダプター、およびアプリケーションエージェントの管理要素のすべての機能は、アプリケーション固有の統合回路（ASIC）で単純化された形式で実装されますが、各ノードのアプリケーションエージェントのアプリケーション固有の要素が実装されます。プログラム可能なマイクロコントローラー。転送は初歩的です。すべてのバンドルは、ハードコーディングされたデフォルトルートに転送されます。
4. Dedicated bundle router
4. 専用バンドルルーター
Each computer constitutes a single bundle node that functions solely as a high-performance bundle forwarder. Many standard functions of the bundle protocol agent, the convergence layer adapters, and the administrative element of the application agent are implemented in ASICs, but some functions are implemented in a high-speed processor to enable reprogramming as necessary. The node's application agent has no application-specific element. Substantial non-volatile storage resources are provided, and arbitrarily complex forwarding algorithms are supported.
各コンピューターは、高性能バンドルフォワーダーとしてのみ機能する単一のバンドルノードを構成します。バンドルプロトコルエージェント、収束層アダプター、およびアプリケーションエージェントの管理要素の多くの標準関数はASICに実装されていますが、必要に応じて再プログラミングを可能にするために高速プロセッサにいくつかの関数が実装されています。ノードのアプリケーションエージェントには、アプリケーション固有の要素がありません。実質的な不揮発性ストレージリソースが提供され、任意に複雑な転送アルゴリズムがサポートされています。
The bundle protocol agent of each node is expected to provide the following services to the node's application agent:
各ノードのバンドルプロトコルエージェントは、次のサービスをノードのアプリケーションエージェントに提供することが期待されています。
o commencing a registration (registering a node in an endpoint);
o 登録の開始（エンドポイントでノードを登録）;
o terminating a registration;
o 登録の終了。
o switching a registration between Active and Passive states;
o アクティブ状態と受動状態の間の登録を切り替える。
o transmitting a bundle to an identified bundle endpoint;
o 識別されたバンドルエンドポイントにバンドルを送信します。
o canceling a transmission;
o 送信のキャンセル。
o polling a registration that is in the passive state;
o 受動状態にある登録を投票する。
o delivering a received bundle.
o 受信したバンドルを配信します。
Each bundle shall be a concatenated sequence of at least two block structures. The first block in the sequence must be a primary bundle block, and no bundle may have more than one primary bundle block. Additional bundle protocol blocks of other types may follow the primary block to support extensions to the bundle protocol, such as the Bundle Security Protocol [BSP]. At most one of the blocks in the sequence may be a payload block. The last block in the sequence must have the "last block" flag (in its block processing control flags) set to 1; for every other block in the bundle after the primary block, this flag must be set to zero.
各バンドルは、少なくとも2つのブロック構造の連結シーケンスでなければなりません。シーケンスの最初のブロックはプライマリバンドルブロックである必要があり、複数のプライマリバンドルブロックを持つバンドルはありません。他のタイプの追加のバンドルプロトコルブロックは、プライマリブロックに従って、バンドルセキュリティプロトコル[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.
設計の重要な戦略的要素は、自己削減数値（SDNV）の使用です。SDNVエンコーディングスキームは、オブジェクト識別子値[ASN1]内のサブインケディファイ因子の1つの基本的なエンコードルールの抽象的構文表記から密接に適合しています。SDNVはnオクテットでエンコードされた数値であり、最後には最も重要なビット（MSB）がゼロに設定されています。SDNVの他のすべてのオクテットのMSBは1に設定する必要があります。SDNVでエンコードされた値は、SDNVの各オクテットの7つの最小ビットを単一のビットストリングに連結することにより得られる署名されていないバイナリ数です。
The following examples illustrate the encoding scheme for various hexadecimal values.
次の例は、さまざまな16進値のエンコーディングスキームを示しています。
0xABC : 1010 1011 1100
is encoded as
{1 00 10101} {0 0111100}
= 10010101 00111100
0x1234 : 0001 0010 0011 0100
= 1 0010 0011 0100
is encoded as
{1 0 100100} {0 0110100}
= 10100100 00110100
0x4234 : 0100 0010 0011 0100
= 100 0010 0011 0100
is encoded as
{1 000000 1} {1 0000100} {0 0110100}
= 10000001 10000100 00110100
0x7F : 0111 1111 = 111 1111 is encoded as {0 1111111} = 01111111
0x7f：0111 1111 = 111 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.
注：エンコードする前に、エンコードされる値が（概念上）高次のゼロビットでパッドが付いていることを確認するために注意する必要があります。また、SDNVフィールドのサイズに理論的な制限はありませんが、SDNVスキームのオーバーヘッドは1：7、つまり、エンコードする実際のデータの7ビットごとに1つのオーバーヘッドです。したがって、8オクテットのSDNVで7オクテット値（先頭ゼロのない56ビット数量）がエンコードされます。8オクテットの値（先行ゼロのない64ビット数量）は、10オクテットのSDNV（6つの先頭のゼロビットがパッド入りの高次ビットを含む1オクテットを含む1オクテット、続いて9オクテットが続き、その後にエンコードされます。値の残りの63ビット）。SDNVで1024ビットRSA暗号化キーを直接エンコードすると、148ビットのオーバーヘッドが消費されます。一般に、先行ゼロのないNビット量は、SDNV占有シル（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).
バンドルプロトコルの実装は、（2^64-1）よりも大きい整数をコードするSDNVを無効な数値として処理できます。
An SDNV can be used to represent both very large and very small integer values. However, SDNV is clearly not the best way to represent every numeric value. For example, an SDNV is a poor way to represent an integer whose value typically falls in the range 128 to 255. In general, though, we believe that SDNV representation of numeric values in bundle blocks yields the smallest block sizes without sacrificing scalability.
SDNVを使用して、非常に大きい整数値と非常に小さな整数値の両方を表すことができます。ただし、SDNVは明らかにすべての数値を表す最良の方法ではありません。たとえば、SDNVは、値が通常128〜255の範囲にある整数を表す貧弱な方法です。ただし、一般的には、バンドルブロックの数値のSDNV表現は、スケーラビリティを犠牲にすることなく最小のブロックサイズを生成すると考えています。
The bundle processing control flags field in the primary bundle block of each bundle is an SDNV; the value encoded in this SDNV is a string of bits used to invoke selected bundle processing control features. The significance of the value in each currently defined position of this bit string is described here. Note that in the figure and descriptions, the bit label numbers denote position (from least significant ('0') to most significant) within the decoded bit string, and not within the representation of the bits on the wire. This is why the descriptions in this section and the next do not follow standard RFC conventions with bit 0 on the left; if fields are added in the future, the SDNV will grow to the left, and using this representation allows the references here to remain valid.
各バンドルのプライマリバンドルブロックのバンドル処理制御フラグフィールドはSDNVです。このSDNVでエンコードされた値は、選択したバンドル処理制御機能を呼び出すために使用される一連のビットです。このビット文字列の現在定義されている各位置の値の重要性については、ここで説明します。図と説明では、ビットラベル番号は、ワイヤー上のビットの表現内ではなく、デコードされたビット文字列内の位置（最も重要ではない（ '0'）から最も重要なものまで）を示していることに注意してください。これが、このセクションと次のセクションの説明が、左側にビット0を持つ標準のRFC規則に従わない理由です。将来フィールドが追加された場合、SDNVは左に成長し、この表現を使用すると、ここの参照が有効なままになります。
2 1 0
0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Status Report|Class of Svc.| General |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Bundle Processing Control Flags Bit Layout
図3：バンドル処理制御フラグビットレイアウト
The bits in positions 0 through 6 are flags that characterize the bundle as follows:
位置0〜6のビットは、次のようにバンドルを特徴付けるフラグです。
0 -- Bundle is a fragment.
0-バンドルはフラグメントです。
1 -- Application data unit is an administrative record.
1-アプリケーションデータユニットは管理記録です。
2 -- Bundle must not be fragmented.
2-バンドルを断片化してはなりません。
3 -- Custody transfer is requested.
3-監護権の譲渡が要求されます。
4 -- Destination endpoint is a singleton.
4-宛先エンドポイントはシングルトンです。
5 -- Acknowledgement by application is requested.
5-申請による承認が要求されます。
6 -- Reserved for future use.
6-将来の使用のために予約されています。
The bits in positions 7 through 13 are used to indicate the bundle's class of service. The bits in positions 8 and 7 constitute a two-bit priority field indicating the bundle's priority, with higher values being of higher priority: 00 = bulk, 01 = normal, 10 = expedited, 11 is reserved for future use. Within this field, bit 8 is the most significant bit. The bits in positions 9 through 13 are reserved for future use.
位置7〜13のビットは、バンドルのサービスクラスを示すために使用されます。位置8および7のビットは、バンドルの優先度を示す2ビット優先フィールドを構成し、より高い値は優先度が高い：00 = bulk、01 = normal、10 = expedited、11は将来の使用のために予約されています。このフィールド内では、ビット8が最も重要なビットです。位置9〜13のビットは、将来の使用のために予約されています。
The bits in positions 14 through 20 are status report request flags. These flags are used to request status reports as follows:
位置14〜20のビットは、ステータスレポート要求フラグです。これらのフラグは、次のようにステータスレポートを要求するために使用されます。
14 -- Request reporting of bundle reception.
14-バンドル受信のレポートをリクエストします。
15 -- Request reporting of custody acceptance.
15-監護権の受け入れの報告を要求します。
16 -- Request reporting of bundle forwarding.
16-バンドル転送のレポートをリクエストします。
17 -- Request reporting of bundle delivery.
17-バンドル配信のリクエストレポート。
18 -- Request reporting of bundle deletion.
18-バンドル削除のレポートをリクエストします。
19 -- Reserved for future use.
19-将来の使用のために予約されています。
20 -- Reserved for future use.
20-将来の使用のために予約されています。
If the bundle processing control flags indicate that the bundle's application data unit is an administrative record, then the custody transfer requested flag must be zero and all status report request flags must be zero. If the custody transfer requested flag is 1, then the sending node requests that the receiving node accept custody of the bundle. If the bundle's source endpoint ID is "dtn:none" (see below), then the bundle is not uniquely identifiable and all bundle protocol features that rely on bundle identity must therefore be disabled: the bundle's custody transfer requested flag must be zero, the "Bundle must not be fragmented" flag must be 1, and all status report request flags must be zero.
バンドル処理制御フラグがバンドルのアプリケーションデータユニットが管理レコードであることを示している場合、監護譲渡要求フラグはゼロでなければならず、すべてのステータスレポート要求フラグはゼロでなければなりません。Custody Requiredのフラグが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 -Referenceフィールドが含まれています。
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" >
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の多くは、バンドルのプライマリブロックの「辞書」バイト配列で伝達されます。この配列は、単に任意の数のヌル終端スキーム名とSSPの連結です。
"Endpoint ID references" are used to cite endpoint IDs that are contained in the dictionary; all endpoint ID citations in the primary bundle block are endpoint ID references, and other bundle blocks may contain endpoint ID references as well. Each endpoint ID reference is an ordered pair of SDNVs:
「エンドポイントID参照」は、辞書に含まれるエンドポイントIDを引用するために使用されます。プライマリバンドルブロックのすべてのエンドポイントID引用はエンドポイントID参照であり、他のバンドルブロックにはエンドポイントID参照も含まれる場合があります。各エンドポイントIDリファレンスは、SDNVの順序付けられたペアです。
o The first SDNV contains the offset within the dictionary of the first character of the referenced endpoint ID's scheme name.
o 最初のSDNVには、参照されたエンドポイントIDのスキーム名の最初の文字の辞書内のオフセットが含まれています。
o The second SDNV contains the offset within the dictionary of the first character of the referenced endpoint ID's SSP.
o 2番目のSDNVには、参照されたエンドポイントIDのSSPの最初の文字の辞書内のオフセットが含まれています。
This encoding enables a degree of block compression: when the source and report-to of a bundle are the same endpoint, for example, the text of that endpoint's ID may be cited twice yet appear only once in the dictionary.
このエンコードは、ある程度のブロック圧縮を可能にします。たとえば、バンドルのソースとレポートへのレポートが同じエンドポイントである場合、たとえば、そのエンドポイントのIDのテキストは2回引用されますが、辞書には1回だけ表示されます。
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 nullエンドポイント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の表現をサポートする可能性があることに注意してください（例：国際化されたリソース識別子（IRIS）; [RFC3987]を参照）。
This section describes the formats of the primary block and payload block. Rules for processing these blocks appear in Section 5 of this document.
このセクションでは、プライマリブロックとペイロードブロックの形式について説明します。これらのブロックを処理するためのルールは、このドキュメントのセクション5に表示されます。
Note that supplementary DTN protocol specifications (including, but not restricted to, the Bundle Security Protocol [BSP]) may require that BP implementations conforming to those protocols construct and process additional blocks.
補足的なDTNプロトコル仕様（バンドルセキュリティプロトコル[BSP]を含むが制限されていない）が、それらのプロトコルに準拠したBP実装が追加のブロックを構築および処理する必要がある場合があることに注意してください。
The format of the two basic BP blocks is shown in Figure 5 below.
2つの基本的な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オクテットのSDNVがここに示されています。
The Creation Timestamp time field in the Primary Bundle Block is an SDNV and is therefore variable length. A four-octet SDNV is shown here for convenience in representation.
プライマリバンドルブロックの作成タイムスタンプタイムフィールドはSDNVであるため、長さは可変です。表現の利便性のために、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と（バンドルがフラグメントの場合）フラグメントオフセットとペイロードの長さとともに、バンドルを識別するのに役立つSDNVのペアです。タイムスタンプの最初のSDNVはバンドルの作成時間、2番目はバンドルの作成タイムスタンプシーケンス番号です。バンドルの作成時間は、2000年の初めから数秒で表現され、調整されたユニバーサルタイム（UTC）スケール[UTC]で、バンドルの作成をもたらした送信要求が受信されました。シーケンスカウントは、ソースノードのバンドルプロトコルエージェントによって管理される単調に増加する正の整数カウンターの最新値（その伝送要求が受信された時点で）です。ソースバンドルプロトコルエージェントは、同じソースエンドポイント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.
Lifetime：Lifetimeフィールドは、バンドルのペイロードがもはや役に立たない時間を示すSDNVであり、作成時間を過ぎて数秒後にエンコードされます。現在の時間が作成時間と寿命よりも大きい場合、バンドルノードはバンドルを保持または転送する必要がなくなります。バンドルはネットワークから削除される場合があります。
Dictionary Length: The Dictionary Length field is an SDNV that contains the length of the dictionary byte array.
辞書の長さ：辞書の長さフィールドは、辞書バイト配列の長さを含むSDNVです。
Dictionary: The Dictionary field is an array of bytes formed by concatenating the null-terminated scheme names and SSPs of all endpoint IDs referenced by any fields in this Primary Block together with, potentially, other endpoint IDs referenced by fields in other TBD DTN protocol blocks. Its length is given by the value of the Dictionary Length field.
辞書：辞書フィールドは、このプライマリブロックの任意のフィールドによって参照されるすべてのエンドポイントIDのヌル終端スキーム名とSSPを潜在的に、他のTBD DTNプロトコルブロックのフィールドが参照する他のエンドポイントIDとともに参照するすべてのエンドポイントIDのSSPを連結することにより形成されるバイトの配列です。。その長さは、辞書の長さフィールドの値によって与えられます。
Fragment Offset: If the Bundle Processing Control Flags of this Primary block indicate that the bundle is a fragment, then the Fragment Offset field is an SDNV indicating the offset from the start of the original application data unit at which the bytes comprising the payload of this bundle were located. If not, then the Fragment Offset field is omitted from the block.
フラグメントオフセット：このプライマリブロックのバンドル処理制御フラグがバンドルがフラグメントであることを示している場合、フラグメントオフセットフィールドは、これのペイロードを含むバイトを構成するバイトが元のアプリケーションデータユニットの開始からオフセットを示すSDNVであることを示しています。バンドルがありました。そうでない場合は、ブロックからフラグメントオフセットフィールドが省略されます。
Total Application Data Unit Length: If the Bundle Processing Control Flags of this Primary block indicate that the bundle is a fragment, then the Total Application Data Unit Length field is an SDNV indicating the total length of the original application data unit of which this bundle's payload is a part. If not, then the Total Application Data Unit Length field is omitted from the block.
合計アプリケーションデータユニット長：このプライマリブロックのバンドル処理制御フラグがバンドルがフラグメントであることを示している場合、総アプリケーションデータユニット長さフィールドは、このバンドルのペイロードの元のアプリケーションデータユニットの総長さを示すSDNVです一部です。そうでない場合は、ブロックから総アプリケーションデータユニットの長さフィールドが省略されています。
Every bundle block of every type other than the primary bundle block comprises the following fields, in this order:
プライマリバンドルブロック以外のすべてのタイプのすべてのバンドルブロックは、この順序で次のフィールドを構成します。
o Block type code, expressed as an 8-bit unsigned binary integer. Bundle block type code 1 indicates that the block is a bundle payload block. Block type codes 192 through 255 are not defined in this specification and are available for private and/or experimental use. All other values of the block type code are reserved for future use.
o 8ビットの符号なしバイナリ整数として表されるブロックタイプコード。バンドルブロックタイプコード1は、ブロックがバンドルペイロードブロックであることを示します。ブロックタイプコード192〜255は、この仕様では定義されておらず、プライベートおよび/または実験的に使用できます。ブロックタイプコードの他のすべての値は、将来の使用のために予約されています。
o Block processing control flags, an unsigned integer expressed as an SDNV. The individual bits of this integer are used to invoke selected block processing control features.
o ブロック処理制御フラグは、SDNVとして表される署名のない整数です。この整数の個々のビットを使用して、選択したブロック処理制御機能を呼び出します。
o Block EID reference count and EID references (optional). If and only if the block references EID elements in the primary block's dictionary, the 'block contains an EID-reference field' flag in the block processing control flags is set to 1 and the block includes an EID reference field consisting of a count of EID references expressed as an SDNV followed by the EID references themselves. Each EID reference is a pair of SDNVs. The first SDNV of each EID reference contains the offset of a scheme name in the primary block's dictionary, and the second SDNV of each reference contains the offset of a scheme-specific part in the dictionary.
o EID参照カウントとEID参照をブロック（オプション）。ブロックがプライマリブロックの辞書のEID要素を参照している場合にのみ、「ブロックにはEid-Referenceフィールドが含まれている」ブロック処理コントロールフラグのフラグが1に設定され、ブロックにはEidのカウントで構成されるEID参照フィールドが含まれます。SDNVとして表現された参照に続いて、EID参照自体が続きます。各EIDリファレンスは、SDNVのペアです。各EIDリファレンスの最初のSDNVには、プライマリブロックの辞書のスキーム名のオフセットが含まれており、各参照の2番目の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：2つの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-referenceフィールドが含まれている」ビットが設定されないという制限を伴う、前のセクションの標準形式に従います。ペイロードブロックのブロックボディデータは、バンドルによって運ばれるアプリケーションデータです。
"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つ以上の拡張ブロックを含むバンドルが転送されるときはいつでも、「ブロックが処理されずに転送された」フラグは、そのような各ブロックのブロック処理フラグ内で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.
バンドルのプライマリブロックからも参照されないバンドルの辞書の文字列（スキーム名とSSP）も、バンドルが転送された時点で辞書から延長ブロックのブロックEID参照フィールドから削除される場合があります。
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で義務付けられているバンドル処理手順は、各バンドルノードのバンドルプロトコルエージェントとアプリケーションエージェントの管理要素の操作を規定しています。彼らは網羅的でも排他的でもありません。つまり、補足的なDTNプロトコル仕様（バンドルセキュリティプロトコル[BSP]を含むが制限されていない）が、これらの手順で指定された接合部で追加のメジャーを取る必要がある場合があります。このような追加の措置は、義務付けられたバンドルプロトコル手順を無効にしたり、置き換えたりしてはなりません。たとえば、補足プロトコルに準拠した実装が特定の受信または発信バンドルの処理を終了することを要求することにより、これらの手順を緩和することができます。そのプロトコルによって認識される断層状態。
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.
状況によっては、ステータスレポートの要求により、ネットワーク内のバンドルトラフィックが許容できない増加につながる可能性があります。このため、ステータスレポートの生成は、1つのケースでのみ必須であり、監護権の移転が要求されるバンドルの削除です。他のすべての場合、要求されたステータスレポートを生成するかどうかについての決定は、バンドルプロトコルエージェントの裁量に任されます。特定の状況下でのステータスレポートの生成を許可する事前に配置された契約など、そのような決定を下すのに役立つメカニズムは、この仕様の範囲を超えています。
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 「Custody Acceptance Status Report」は、「バンドルの監護権を受け入れた」フラグを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：このバンドル送信の監護権の譲渡が要求され、さらに、ソースノードによる監護権の受け入れが必要な場合、バンドルプロトコルエージェントはバンドルの親権を受け入れることにコミットする必要があります。 - または、リクエストを尊重することはできず、この手順の残りのすべての手順をスキップする必要があります。バンドルプロトコルエージェントは、バンドルの監護権が受け入れられる可能性のある条件が満たされていない場合、バンドルの保管を受け入れることを約束してはなりません。この仕様では、宛先がシングルトンのエンドポイントではないバンドルの管理をノードが受け入れる条件。
Step 2: Transmission of the bundle is initiated. An outbound bundle must be created per the parameters of the bundle transmission request, with current custodian endpoint ID set to the null endpoint ID "dtn:none" and with the retention constraint "Dispatch pending". The source endpoint ID of the bundle must be either the ID of an endpoint of which the node is a member or the null endpoint ID "dtn:none".
ステップ2：バンドルの送信が開始されます。バンドル伝送要求のパラメーターに従って、現在のカストディアンエンドポイントIDがnullエンドポイントID「dtn：none」に設定され、保持制約「ディスパッチが保留中」に設定されたアウトバウンドバンドルを作成する必要があります。バンドルのソースエンドポイントIDは、ノードがメンバーであるエンドポイントのIDまたはnullエンドポイントID "dtn：none"のいずれかである必要があります。
Step 3: Processing proceeds from Step 1 of Section 5.4.
ステップ3：セクション5.4のステップ1からの処理収益。
The steps in dispatching a bundle are:
バンドルを発送する手順は次のとおりです。
Step 1: If the bundle's destination endpoint is an endpoint of which the node is a member, the bundle delivery procedure defined in Section 5.7 must be followed.
ステップ1：バンドルの宛先エンドポイントがノードがメンバーであるエンドポイントである場合、セクション5.7で定義されているバンドル配信手順に従う必要があります。
Step 2: Processing proceeds from Step 1 of Section 5.4.
ステップ2：セクション5.4のステップ1からの処理収益。
The steps in forwarding a bundle are:
バンドルを転送する手順は次のとおりです。
Step 1: The retention constraint "Forward pending" must be added to the bundle, and the bundle's "Dispatch pending" retention constraint must be removed.
ステップ1：保持制約「フォワード保留中」をバンドルに追加する必要があり、バンドルの「ディスパッチ保留中」保持制約を削除する必要があります。
Step 2: The bundle protocol agent must determine whether or not forwarding is contraindicated for any of the reasons listed in Figure 12. In particular:
ステップ2：バンドルプロトコルエージェントは、図12にリストされている理由のいずれかで転送が禁忌であるかどうかを判断する必要があります。
* The bundle protocol agent must determine which endpoint(s) to forward the bundle to. The bundle protocol agent may choose either to forward the bundle directly to its destination endpoint (if possible) or to forward the bundle to some other endpoint(s) for further forwarding. The manner in which this decision is made may depend on the scheme name in the destination endpoint ID but in any case is beyond the scope of this document. If the agent finds it impossible to select any endpoint(s) to forward the bundle to, then forwarding is contraindicated.
* バンドルプロトコルエージェントは、バンドルを転送するエンドポイントを決定する必要があります。バンドルプロトコルエージェントは、バンドルを宛先エンドポイントに直接転送するか（可能であれば）選択するか、さらに転送するためにバンドルを他のエンドポイントに転送することができます。この決定が行われる方法は、宛先エンドポイントIDのスキーム名に依存する場合がありますが、いずれにしてもこのドキュメントの範囲を超えています。エージェントがバンドルを転送してエンドポイントを選択することが不可能であると判断した場合、転送は禁忌です。
* Provided the bundle protocol agent succeeded in selecting the endpoint(s) to forward the bundle to, the bundle protocol agent must select the convergence layer adapter(s) whose services will enable the node to send the bundle to the nodes of the minimum reception group of each selected endpoint. The manner in which the appropriate convergence layer adapters are selected may depend on the scheme name in the destination endpoint ID but in any case is beyond the scope of this document. If the agent finds it impossible to select convergence layer adapters to use in forwarding this bundle, then forwarding is contraindicated.
* バンドルプロトコルエージェントがエンドポイントを選択してバンドルを転送することに成功した場合、バンドルプロトコルエージェントは、ノードがバンドルを最小受信グループのノードに送信できるようにするコンバージェンスレイヤーアダプターを選択する必要があります。選択した各エンドポイントの。適切な収束層アダプターが選択される方法は、宛先エンドポイントIDのスキーム名に依存する場合がありますが、いずれの場合もこのドキュメントの範囲を超えています。エージェントがこのバンドルを転送する際に使用するコンバージェンスレイヤーアダプターを選択することが不可能だと判断した場合、転送は禁忌です。
Step 3: If forwarding of the bundle is determined to be contraindicated for any of the reasons listed in Figure 12, then the Forwarding Contraindicated procedure defined in Section 5.4.1 must be followed; the remaining steps of Section 5 are skipped at this time.
ステップ3：図12にリストされている理由のいずれかで、バンドルの転送が禁忌であると判断された場合、セクション5.4.1で定義されている転送の禁忌手順に従う必要があります。セクション5の残りの手順は、現時点でスキップされています。
Step 4: If the bundle's custody transfer requested flag (in the bundle processing flags field) is set to 1, then the custody transfer procedure defined in Section 5.10.2 must be followed.
ステップ4：バンドルの監護権譲渡要求フラグ（バンドル処理フラグフィールド）が1に設定されている場合、セクション5.10.2で定義されている保管譲渡手順に従う必要があります。
Step 5: For each endpoint selected for forwarding, the bundle protocol agent must invoke the services of the selected convergence layer adapter(s) in order to effect the sending of the bundle to the nodes constituting the minimum reception group of that endpoint. Determining the time at which the bundle is to be sent by each convergence layer adapter is an implementation matter.
ステップ5：転送用に選択された各エンドポイントについて、バンドルプロトコルエージェントは、そのエンドポイントの最小受信グループを構成するノードへのバンドルの送信を実施するために、選択したコンバージェンスレイヤーアダプターのサービスを呼び出す必要があります。各コンバージェンスレイヤーアダプターによってバンドルを送信する時間を決定することは、実装の問題です。
To keep from possibly invalidating bundle security, the sequencing of the blocks in a forwarded bundle must not be changed as it transits a node; received blocks must be transmitted in the same relative order as that in which they were received. While blocks may be added to bundles as they transit intermediate nodes, removal of blocks that do not have their 'Discard block if it can't be processed' flag in the block processing control flags set to 1 may cause security to fail.
バンドルセキュリティを無効にしないようにするには、ノードを通過するため、転送されたバンドルでのブロックのシーケンスを変更しないでください。受信ブロックは、受信したものと同じ相対順序で送信する必要があります。中間ノードを通過する際にブロックがバンドルに追加される場合がありますが、1に設定されたブロック処理制御フラグのフラグを「処理できない場合は廃棄ブロックを廃棄しないブロックの削除がセキュリティが失敗する可能性があります。
Step 6: When all selected convergence layer adapters have informed the bundle protocol agent that they have concluded their data sending procedures with regard to this bundle:
ステップ6：選択したすべてのコンバージェンスレイヤーアダプターが、バンドルプロトコルエージェントに、このバンドルに関してデータ送信手順を終了したことを通知した場合：
* If the "request reporting of bundle forwarding" flag in the bundle's status report request field is set to 1, then a bundle forwarding status report should be generated, destined for the bundle's report-to endpoint ID. If the bundle has the retention constraint "custody accepted" and all of the nodes in the minimum reception group of the endpoint selected for forwarding are known to be unable to send bundles back to this node, then the reason code on this bundle forwarding status report must be "forwarded over unidirectional link"; otherwise, the reason code must be "no additional information".
* バンドルのステータスレポートリクエストフィールドの「バンドル転送のリクエストレポート」フラグが1に設定されている場合、バンドルのレポートツーエンドポイントID用に運命にあるバンドル転送ステータスレポートを生成する必要があります。バンドルに保持制約が「Custodyが受け入れられた」と、フォワーディング用に選択されたエンドポイントの最小受信グループのすべてのノードがこのノードにバンドルを送り返すことができないことが知られている場合、このバンドル転送ステータスレポートの理由コードは「単方向リンク上に転送される」必要があります。それ以外の場合、理由コードは「追加情報がない」必要があります。
* 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に設定されている場合、Bundleのレポートに向けて、Bundle Recenced Code "追加情報を生成する必要はありません。エンドポイント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.
* そのブロックのブロック処理フラグがこのイベントでステータスレポートが要求されていることを示している場合、BundleのレポートツーエンドポイントIDに運命づけられているReason Code "Block" Intelligible "を備えたバンドル受信ステータスレポートを生成する必要があります。
* 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.
* このブロックのブロック処理フラグがこのイベントでバンドルを削除する必要があることを示している場合、バンドルプロトコルエージェントは、「Intelligible」という理由でバンドルを削除する必要があります。セクション5.13で定義されているバンドル削除手順に従う必要があり、バンドル受信手順のすべての残りの手順をスキップする必要があります。
* If the block processing flags in that block do NOT indicate that the bundle must be deleted in this event but do indicate that the block must be discarded, then the bundle protocol agent must remove this block from the bundle.
* そのブロックのブロック処理フラグがこのイベントでバンドルを削除する必要があることを示していないが、ブロックを破棄する必要があることを示している場合、バンドルプロトコルエージェントはバンドルからこのブロックを削除する必要があります。
* If the block processing flags in that block indicate NEITHER that the bundle must be deleted NOR that the block must be discarded, then the bundle protocol agent must set to 1 the "Block was forwarded without being processed" flag in the block processing flags of the block.
* そのブロックのブロック処理フラグが、バンドルを削除する必要もブロックを破棄する必要もないことを示している場合、バンドルプロトコルエージェントは1に設定する必要があります。ブロック。
Step 4: If the bundle's custody transfer requested flag (in the bundle processing flags field) is set to 1 and the bundle has the same source endpoint ID, creation timestamp, and (if the bundle is a fragment) fragment offset and payload length as another bundle that (a) has not been discarded and (b) currently has the retention constraint "Custody accepted", custody transfer redundancy must be handled. Otherwise, processing proceeds from Step 5. Procedures for handling redundancy in custody transfer 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.
* Bundleのステータスレポートリクエストフィールドの「バンドル配信のリクエストレポート」フラグが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.)
バンドルのサイズは、バンドルを「断片化」することで縮小できます。ペイロードがサイズMであるバンドルをフラグメントすることは、2つの「フラグメント」に置き換えることです - 新しいバンドルは、元のバンドルと同じソースエンドポイントIDと作成タイムスタンプを備えています。n）元のバンドルのペイロードのバイト。0 <n <M。フラグメント自体が断片化される可能性があることに注意するため、断片化は事実上、元のバンドルを2つ以上のフラグメントに置き換える可能性があることに注意してください。（ただし、IPフラグメンテーションのように、断片化には1つの「レベル」しかありません。）
Any bundle whose primary block's bundle processing flags do NOT indicate that it must not be fragmented may be fragmented at any time, for any purpose, at the discretion of the bundle protocol agent.
プライマリブロックのバンドル処理フラグが断片化してはならないことを示していないバンドルは、バンドルプロトコルエージェントの裁量により、いつでも断片化される可能性があります。
Fragmentation shall be constrained as follows:
断片化は次のように制約されなければならない：
o The concatenation of the payloads of all fragments produced by fragmentation must always be identical to the payload of the bundle that was fragmented. Note that the payloads of fragments resulting from different fragmentation episodes, in different parts of the network, may be overlapping subsets of the original bundle's payload.
o 断片化によって生成されるすべてのフラグメントのペイロードの連結は、断片化されたバンドルのペイロードと常に同一でなければなりません。ネットワークのさまざまな部分で、異なる断片化エピソードに起因するフラグメントのペイロードは、元のバンドルのペイロードのサブセットに重複している可能性があることに注意してください。
o The bundle processing flags in the primary block of each fragment must be modified to indicate that the bundle is a fragment, and both fragment offset and total application data unit length must be provided at the end of each fragment's primary bundle block.
o 各フラグメントの主要なブロックのバンドル処理フラグは、バンドルがフラグメントであることを示すように変更する必要があります。各フラグメントのプライマリバンドルブロックの端にフラグメントオフセットと合計アプリケーションデータユニットの長さを提供する必要があります。
o The primary blocks of the fragments will differ from that of the fragmented bundle as noted above.
o フラグメントの主要なブロックは、上記のように断片化されたバンドルの主要なブロックとは異なります。
o The payload blocks of fragments will differ from that of the fragmented bundle as noted above.
o フラグメントのペイロードブロックは、上記のように断片化されたバンドルのペイロードブロックとは異なります。
o All blocks that precede the payload block at the time of fragmentation must be replicated in the fragment with the lowest offset.
o フラグメンテーション時にペイロードブロックに先行するすべてのブロックは、最も低いオフセットでフラグメントに複製する必要があります。
o All blocks that follow the payload block at the time of fragmentation must be replicated in the fragment with the highest offset.
o フラグメンテーション時にペイロードブロックに従うすべてのブロックは、最高のオフセットを持つフラグメントで複製する必要があります。
o If the 'Block must be replicated in every fragment' bit is set to 1, then the block must be replicated in every fragment.
o 「ブロックをすべてのフラグメントで複製する必要がある」ビットが1に設定されている場合、ブロックはすべてのフラグメントで複製する必要があります。
o If the 'Block must be replicated in every fragment' bit is set to zero, the block should be replicated in only one fragment.
o 「ブロックをすべてのフラグメントで複製する必要がある」ビットがゼロに設定されている場合、ブロックは1つのフラグメントのみで複製する必要があります。
o The relative order of all blocks that are present in a fragment must be the same as in the bundle prior to fragmentation.
o フラグメントに存在するすべてのブロックの相対順序は、フラグメンテーション前のバンドルと同じでなければなりません。
If the concatenation -- as informed by fragment offsets and payload lengths -- of the payloads of all previously received fragments with the same source endpoint ID and creation timestamp as this fragment, together with the payload of this fragment, forms a byte array whose length is equal to the total application data unit length in the fragment's primary block, then:
このフラグメントと同じソースエンドポイントIDと作成タイムスタンプを持つ以前に受信したすべてのフラグメントのペイロードの断片的なオフセットとペイロード長によって通知される連結 - このフラグメントのペイロードとともに、長さのバイト配列を形成する場合フラグメントのプライマリブロックの総アプリケーションデータユニットの長さに等しくなります。
o This byte array -- the reassembled application data unit -- must replace the payload of this fragment.
o このバイト配列 - 再構築されたアプリケーションデータユニット - は、このフラグメントのペイロードを置き換える必要があります。
o The "Reassembly pending" retention constraint must be removed from every other fragment whose payload is a subset of the reassembled application data unit.
o ペイロードが再組み立てアプリケーションデータユニットのサブセットである他のすべてのフラグメントから保持制約を削除する「再組み立て」保持制約を削除する必要があります。
Note: reassembly of application data units from fragments occurs at destination endpoints as necessary; an application data unit may also be reassembled at some other endpoint on the route to the destination.
注：フラグメントからのアプリケーションデータユニットの再組み立ては、必要に応じて宛先エンドポイントで発生します。アプリケーションデータユニットは、宛先へのルート上の他のエンドポイントで再組み立てされる場合があります。
The conditions under which a node may accept custody of a bundle whose destination is not a singleton endpoint are not defined in this specification.
この仕様では、宛先がシングルトンのエンドポイントではないバンドルの管理をノードが受け入れる条件。
The decision as to whether or not to accept custody of a bundle whose destination is a singleton endpoint is an implementation matter that may involve both resource and policy considerations; however, if the bundle protocol agent has committed to accepting custody of the bundle (as described in Step 1 of Section 5.2), then custody must be accepted.
目的地がシングルトンのエンドポイントであるバンドルの親権を受け入れるかどうかについての決定は、リソースとポリシーの両方の考慮事項を伴う可能性のある実装問題です。ただし、バンドルプロトコルエージェントがバンドルの親権を受け入れることを約束した場合（セクション5.2のステップ1で説明）、監護権を受け入れる必要があります。
If the bundle protocol agent elects to accept custody of the bundle, then it must follow the custody acceptance procedure defined in Section 5.10.1.
バンドルプロトコルエージェントがバンドルの親権を受け入れることを選択した場合、セクション5.10.1で定義されている監護権承認手順に従う必要があります。
Procedures for acceptance of custody of a bundle whose destination is not a singleton endpoint are not defined in this specification.
この仕様では、目的地がシングルトンエンドポイントではないバンドルの監護権を受け入れる手順。
Procedures for acceptance of custody of a bundle whose destination is a singleton endpoint are defined as follows.
目的地がシングルトンのエンドポイントであるバンドルの親権を受け入れる手順は、次のように定義されています。
The retention constraint "Custody accepted" must be added to the bundle.
保持制約「受け入れられた監護権」は、バンドルに追加する必要があります。
If the "request reporting of custody acceptance" flag in the bundle's status report request field is set to 1, a custody acceptance status report should be generated, destined for the report-to endpoint ID of the bundle. However, if a bundle reception status report was generated for this bundle (Step 1 of Section 5.6), then this report should be generated by simply turning on the "Reporting node accepted custody of bundle" flag in that earlier report's status flags byte.
バンドルのステータスレポートリクエストフィールドの「監護権の受け入れの要求」フラグが1に設定されている場合、バンドルのレポートツーエンドポイントIDに任されている監護権承認ステータスレポートを生成する必要があります。ただし、このバンドルに対してバンドルレセプションステータスレポートが生成された場合（セクション5.6のステップ1）、このレポートは、以前のレポートのステータスフラグバイトの「バンドルの認められたバンドルの管理」フラグをオンにするだけで生成する必要があります。
The bundle protocol agent must generate a "Succeeded" custody signal for the bundle, destined for the bundle's current custodian.
バンドルプロトコルエージェントは、バンドルの現在のカストディアンに向けて、バンドルの「成功した」親権信号を生成する必要があります。
The bundle protocol agent must assert the new current custodian for the bundle. It does so by changing the current custodian endpoint ID in the bundle's primary block to the endpoint ID of one of the singleton endpoints in which the node is registered. This may entail appending that endpoint ID's null-terminated scheme name and SSP to the dictionary byte array in the bundle's primary block, and in some case it may also enable the (optional) removal of the current custodian endpoint ID's scheme name and/or SSP from the dictionary.
バンドルプロトコルエージェントは、バンドルの新しい現在のカストディアンを主張する必要があります。これは、バンドルのプライマリブロックにある現在のカストディアンエンドポイントIDを、ノードが登録されているシングルトンエンドポイントの1つのエンドポイント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.
バンドルの宛先がSingletonエンドポイントであるCustody Signalで識別されたバンドルの保管ノードであるノードで「成功した」監護信号を受信すると、セクション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.
この仕様では、宛先がシングルトンエンドポイントではないバンドルの監護権移転障害を決定する手順。目的地がシングルトンのエンドポイントであるバンドルの親権転送は、そのバンドルのノードの監護権転送タイマー（存在する場合）の拘束譲渡タイマーまたは（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.
管理レコードは、バンドルプロトコルのいくつかの機能の提供に使用される標準的なアプリケーションデータユニットです。これまでに2種類の管理記録が定義されています。バンドルステータスレポートと親権シグナル。
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時間は、2000年の開始から秒数を示すSDNVで構成され、その後、指定された2番目の開始以来のナノ秒数を示す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.
作成タイムスタンプフィールドは、被験者バンドルの主要なブロックにある作成タイムスタンプフィールドを複製します。そのため、それらはSDNV（上記のセクション4.5.1を参照）であるため、長さは変動します。4オクテットのSDNVは、表現の利便性のためにここに示されています。
The source endpoint ID length field is an SDNV and is therefore variable length. A three-octet SDNV is shown here for convenience in representation.
ソースエンドポイントIDの長さフィールドはSDNVであるため、長さが変動します。表現の利便性のために、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バイトフィールド。ここで提供されるステータスレポートの理由コードのリストは、網羅的でも排他的でもありません。補足DTNプロトコル仕様（バンドルセキュリティプロトコル[BSP]を含むが制限されていない）が追加の理由コードを定義する場合があります。ステータスレポート理由コードは次のように定義されます。
+---------+--------------------------------------------+
| Value | Meaning |
+=========+============================================+
| 0x00 | No additional information. |
+---------+--------------------------------------------+
| 0x01 | Lifetime expired. |
+---------+--------------------------------------------+
| 0x02 | Forwarded over unidirectional link. |
+---------+--------------------------------------------+
| 0x03 | Transmission canceled. |
+---------+--------------------------------------------+
| 0x04 | Depleted storage. |
+---------+--------------------------------------------+
| 0x05 | Destination endpoint ID unintelligible. |
+---------+--------------------------------------------+
| 0x06 | No known route to destination from here. |
+---------+--------------------------------------------+
| 0x07 | No timely contact with next node on route.|
+---------+--------------------------------------------+
| 0x08 | Block unintelligible. |
+---------+--------------------------------------------+
| (other) | Reserved for future use. |
+---------+--------------------------------------------+
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.
前方の時間（存在する場合）：バンドルに搭載されたビットがステータスフラグに設定されている場合、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.
作成タイムスタンプフィールドは、被験者バンドルの主要なブロックにある作成タイムスタンプフィールドを複製します。そのため、それらはSDNV（上記のセクション4.5.1を参照）であるため、長さは変動します。4オクテットのSDNVは、表現の利便性のためにここに示されています。
The source endpoint ID length field is an SDNV and is therefore variable length. A three-octet SDNV is shown here for convenience in representation.
ソースエンドポイントIDの長さフィールドはSDNVであるため、長さが変動します。表現の利便性のために、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の長さ：信号が適用されたバンドルのソースエンドポイント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
o コンバージェンスレイヤープロトコルを介して到達可能な指定されたエンドポイントIDによって識別されたエンドポイントの最小受信グループのすべてのバンドルノードにバンドルを送信します。と
o delivering to the bundle protocol agent a bundle that was sent by a remote bundle node via the convergence layer protocol.
o バンドルプロトコルエージェントに、コンバージェンスレイヤープロトコルを介してリモートバンドルノードによって送信されたバンドルを配信します。
The convergence layer service interface specified here is neither exhaustive nor exclusive. That is, supplementary DTN protocol specifications (including, but not restricted to, the Bundle Security Protocol [BSP]) may expect convergence layer adapters that serve BP implementations conforming to those protocols to provide additional services.
ここで指定されている収束層サービスインターフェイスは、網羅的でも排他的でもありません。つまり、補足的なDTNプロトコル仕様（バンドルセキュリティプロトコル[BSP]を含むが制限されていない）は、それらのプロトコルに準拠して追加のサービスを提供するBP実装を提供する収束層アダプターを期待する場合があります。
The bundle protocol has taken security into concern from the outset of its design. It was always assumed that security services would be needed in the use of the bundle protocol. As a result, the bundle protocol security architecture and the available security services are specified in an accompanying document, the Bundle Security Protocol specification [BSP]; an informative overview of this architecture is provided in [SECO].
バンドルプロトコルは、設計の最初からセキュリティを懸念に導きました。バンドルプロトコルの使用にはセキュリティサービスが必要であると常に想定されていました。その結果、バンドルプロトコルセキュリティアーキテクチャと利用可能なセキュリティサービスは、付随するドキュメントであるバンドルセキュリティプロトコル仕様[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.
バンドルアウェアオーバーレイネットワークの内部では、バンドルノードは、バンドルノード間で転送されるバンドルペイロードデータの整合性の保存と同様に、他のバンドルノードの信ity性に関係する必要があります。
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.
その結果、バンドルセキュリティは、バンドルノード間で伝えられるバンドルの信頼性、完全性、および機密性に関係しています。これは、3つの独立したセキュリティ固有のバンドルブロックを使用することで実現されます。これは、知覚されたセキュリティの脅威、義務付けられたセキュリティ要件、および実施しなければならないセキュリティポリシーに応じて、複数のバンドルセキュリティサービスを提供するために、または互いに独立して提供するために一緒に使用できます。
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）が使用されます。「セキュリティソース」は、実際にはバンドルのオリジネーションポイントではなく、セキュリティ認識でセキュリティサービスを適用できるパスに沿った最初のポイントである可能性があります。たとえば、ネットワーク化されたシステムの飛び地はバンドルを生成する場合がありますが、ゲートウェイのみが必要になったり、セキュリティサービスを適用できる場合があります。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参照の付随する調整により、1つ以上の値を再計算する必要があることに注意してください。バンドルのセキュリティブロック。
Bundle security must not be invalidated by forwarding nodes even though they themselves might not use the Bundle Security Protocol. In particular, the sequencing of the blocks in a forwarded bundle must not be changed as it transits a node; received blocks must be transmitted in the same relative order as that in which they were received. While blocks may be added to bundles as they transit intermediate nodes, removal of blocks that do not have their 'Discard block if it can't be processed' flag in the block processing control flags set to 1 may cause security to fail.
バンドルセキュリティは、バンドルセキュリティプロトコルを使用していない場合でも、ノードを転送して無効にしてはなりません。特に、転送されたバンドルのブロックのシーケンスは、ノードを通過するため、変更してはなりません。受信ブロックは、受信したものと同じ相対順序で送信する必要があります。中間ノードを通過する際にブロックがバンドルに追加される場合がありますが、1に設定されたブロック処理制御フラグのフラグを「処理できない場合は廃棄ブロックを廃棄しないブロックの削除がセキュリティが失敗する可能性があります。
Inclusion of the Bundle Security Protocol in any Bundle Protocol implementation is RECOMMENDED. Use of the Bundle Security Protocol in Bundle Protocol operations is OPTIONAL.
バンドルプロトコルの実装にバンドルセキュリティプロトコルを含めることをお勧めします。バンドルプロトコル操作でのバンドルセキュリティプロトコルの使用はオプションです。
The "dtn:" URI scheme has been provisionally registered by IANA. See http://www.iana.org/assignments/uri-schemes.html for the latest details.
「DTN：」URIスキームは、IANAによって暫定的に登録されています。最新の詳細については、http：//www.iana.org/assignments/uri-schemes.htmlを参照してください。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", RFC 3986, STD 66, January 2005.
[URI] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、RFC 3986、STD 66、2005年1月。
[URIREG] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", RFC 4395, BCP 115, February 2006.
[Urireg] Hansen、T.、Hardie、T.、およびL. Masinter、「新しいURIスキームのガイドラインと登録手順」、RFC 4395、BCP 115、2006年2月。
[ARCH] V. Cerf et. al., "Delay-Tolerant Network Architecture", RFC 4838, April 2007.
[アーチ] V. Cerf et。al。、「遅延耐性ネットワークアーキテクチャ」、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）の仕様（BER）、標準エンコードルール（CER）、著名なエンコードルール（der）、 "itu-t rec。X.690（2002）| ISO/IEC 8825- 1：2002 "、2003。
[BSP] Symington, S., "Bundle Security Protocol Specification", Work Progress, October 2007.
[BSP] Symington、S。、「バンドルセキュリティプロトコル仕様」、Work Progress、2007年10月。
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[RFC3987] Duerst、M。およびM. Suignard、「国際化されたリソース識別子（IRIS）」、RFC 3987、2005年1月。
[SECO] Farrell, S., Symington, S., Weiss, H., and P. Lovell, "Delay-Tolerant Networking Security Overview", Work Progress, July 2007.
[Seco] Farrell、S.、Symington、S.、Weiss、H。、およびP. Lovell、「遅延耐性ネットワークセキュリティの概要」、2007年7月の作業進捗状況。
[SIGC] Fall, K., "A Delay-Tolerant Network Architecture for Challenged Internets", SIGCOMM 2003 .
[SIGC] Fall、K。、「挑戦されたインターネットのための遅延耐性ネットワークアーキテクチャ」、Sigcomm 2003。
[TUT] Warthman, F., "Delay-Tolerant Networks (DTNs): A Tutorial", <http://www.dtnrg.org>.
[TUT] Warthman、F。、「遅延耐性ネットワーク（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] Arias、E。and B. Guinot、 ""調整されたユニバーサルタイムUTC：歴史的背景と視点 "Reference Spatio-Temporels de reference spatio-temporels"、2004。
This was an effort of the Delay Tolerant Networking Research Group. The following DTNRG participants contributed significant technical material and/or inputs: Dr. Vinton Cerf of Google, Scott Burleigh, Adrian Hooke, and Leigh Torgerson of the Jet Propulsion Laboratory, Michael Demmer of the University of California at Berkeley, Robert Durst, Keith Scott, and Susan Symington of The MITRE Corporation, Kevin Fall of Intel Research, Stephen Farrell of Trinity College Dublin, Peter Lovell of SPARTA, Inc., Manikantan Ramadas of Ohio University (most of Section 4.1), and Howard Weiss of SPARTA, Inc. (text of Section 8).
これは、遅延耐性ネットワーキング研究グループの努力でした。以下のDTNRG参加者は、GoogleのヴィントンCerf博士、スコットバーリー、エイドリアンフック、ジェット推進研究所のリートーガーソン、カリフォルニア大学バークレー校のマイケルデマー、ロバートダースト、キーススコットの重要な技術資料および/またはインプットを貢献しました。、マイターコーポレーションのスーザンシミントン、ケビンフォールオブインテルリサーチ、ダブリンのトリニティカレッジのスティーブンファレル、スパルタインクのピーターラヴェル、オハイオ大学のマニカンタンラマダス（セクション4.1のほとんど）、およびスパルタ社のハワードワイス（セクション8のテキスト）。
Please refer comments to dtn-interest@mailman.dtnrg.org. The Delay Tolerant Networking Research Group (DTNRG) Web site is located at http://www.dtnrg.org.
dtn-interest@mailman.dtnrg.orgにコメントを参照してください。Delay Tolerant Networking Research Group（DTNRG）Webサイトは、http：//www.dtnrg.orgにあります。
Authors' Addresses
著者のアドレス
Keith L. Scott The MITRE Corporation 7515 Colshire Drive McLean, VA 21102 US
キース・L・スコット・ザ・マイター・コーポレーション7515コルシャー・ドライブ・マクリーン、バージニア州21102 US
Phone: +1 703 983 6547
Fax: +1 703 983 7142
EMail: kscott@mitre.org
Scott Burleigh NASA Jet Propulsion Laboratory 4800 Oak Grove Dr. Pasadena, CA 91109-8099 US
Scott Burleigh NASA Jet Propulsion Laboratory 4800 Oak Grove Dr. Pasadena、CA 91109-8099 US
Phone: +1 818 393 3353
Fax: +1 818 354 1075
EMail: Scott.Burleigh@jpl.nasa.gov
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78およびwww.rfc-editor.org/copyright.htmlに含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。