[要約] RFC 9171は、Bundle Protocol Version 7を定義しており、遅延耐性ネットワーク（DTN）でのデータ伝送のためのプロトコルです。このプロトコルは、信頼性の低いまたは遅延の大きいネットワーク接続がある環境での通信を可能にすることを目的としています。宇宙通信、災害時の通信、リモート地域での通信など、標準的なインターネットプロトコルが不十分な場面で利用されます。
Internet Engineering Task Force (IETF) S. Burleigh
Request for Comments: 9171 IPNGROUP
Category: Standards Track K. Fall
ISSN: 2070-1721 Roland Computing Services
E. Birrane, III
APL, Johns Hopkins University
January 2022
Bundle Protocol Version 7
バンドルプロトコルバージョン7
Abstract
概要
This document presents a specification for the Bundle Protocol, adapted from the experimental Bundle Protocol specification developed by the Delay-Tolerant Networking Research Group of the Internet Research Task Force and documented in RFC 5050.
この文書は、インターネット研究タスクフォースの遅延耐性ネットワーキング研究グループによって開発され、RFC 5050に記載されている実験的バンドルプロトコル仕様から適合したバンドルプロトコルの仕様を提示しています。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
この文書はインターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それはパブリックレビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9171.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frofc9171で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF信頼と文書の著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、この文書の公開日に有効なIETF文書（https://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。この文書から抽出されたコードコンポーネントには、信託法定規定のセクション4。
Table of Contents
目次
1. Introduction
2. Conventions Used in This Document
3. Service Description
3.1. Definitions
3.2. Discussion of BP Concepts
3.3. Services Offered by Bundle Protocol Agents
4. Bundle Format
4.1. Bundle Structure
4.2. BP Fundamental Data Structures
4.2.1. CRC Type
4.2.2. CRC
4.2.3. Bundle Processing Control Flags
4.2.4. Block Processing Control Flags
4.2.5. Identifiers
4.2.5.1. Endpoint ID
4.2.5.1.1. The dtn URI Scheme
4.2.5.1.2. The ipn URI Scheme
4.2.5.2. Node ID
4.2.6. DTN Time
4.2.7. Creation Timestamp
4.2.8. Block-Type-Specific Data
4.3. Block Structures
4.3.1. Primary Bundle Block
4.3.2. Canonical Bundle Block Format
4.4. Extension Blocks
4.4.1. Previous Node
4.4.2. Bundle Age
4.4.3. Hop Count
5. Bundle Processing
5.1. Generation of Administrative Records
5.2. Bundle Transmission
5.3. Bundle Dispatching
5.4. Bundle Forwarding
5.4.1. Forwarding Contraindicated
5.4.2. Forwarding Failed
5.5. Bundle Expiration
5.6. Bundle Reception
5.7. Local Bundle Delivery
5.8. Bundle Fragmentation
5.9. Application Data Unit Reassembly
5.10. Bundle Deletion
5.11. Discarding a Bundle
5.12. Canceling a Transmission
6. Administrative Record Processing
6.1. Administrative Records
6.1.1. Bundle Status Reports
6.2. Generation of Administrative Records
7. Services Required of the Convergence Layer
7.1. The Convergence Layer
7.2. Summary of Convergence-Layer Services
8. Security Considerations
9. IANA Considerations
9.1. Bundle Block Types
9.2. Primary Bundle Protocol Version
9.3. Bundle Processing Control Flags
9.4. Block Processing Control Flags
9.5. Bundle Status Report Reason Codes
9.6. Bundle Protocol URI Scheme Types
9.7. dtn URI Scheme
9.8. ipn URI Scheme
10. References
10.1. Normative References
10.2. Informative References
Appendix A. Significant Changes from RFC 5050
Appendix B. CDDL Expression
Acknowledgments
Authors' Addresses
Since the publication of the Bundle Protocol specification (Experimental RFC 5050 [RFC5050]) in 2007, the Delay-Tolerant Networking (DTN) Bundle Protocol (BP) has been implemented in multiple programming languages and deployed to a wide variety of computing platforms. This implementation and deployment experience has identified opportunities for making the protocol simpler, more capable, and easier to use. The present document, standardizing the Bundle Protocol, is adapted from RFC 5050 in that context, reflecting lessons learned. Significant changes from the Bundle Protocol specification defined in RFC 5050 are listed in Appendix A.
2007年のバンドルプロトコル仕様書（実験的RFC 5050 [RFC5050]）の公表以来、遅延耐性ネットワーキング（DTN）バンドルプロトコル（BP）は、複数のプログラミング言語で実装されており、さまざまなコンピューティングプラットフォームに展開されています。この実装と展開エクスペリエンスは、プロトコルをより単純で、より有能、そして使いやすくする機会を特定しました。バンドルプロトコルを標準化した本文書は、その文脈においてRFC5050から、学習されたレッスンを反映している。RFC 5050で定義されているバンドルプロトコル仕様からの重要な変更は付録Aに記載されています。
This document describes BP version 7 (BPv7).
このドキュメントではBPバージョン7（BPV7）について説明します。
Delay-Tolerant Networking is a network 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 may be viewed as sitting at the application layer of some number of constituent networks, forming a store-carry-forward overlay network. Key capabilities of BP include:
遅延耐性ネットワーキングは、非常に強調された環境内および/またはそれを介して通信を提供するネットワークアーキテクチャである。強調されたネットワーキング環境には、間欠的な接続性、大部分および/または可変遅延、および高いビットエラーレートが含まれます。そのサービスを提供するために、BPは何らかの構成要素ネットワークのアプリケーション層に座っていると見なされており、ストアキャリーフォワードオーバーレイネットワークを形成する。BPの主な機能は次のとおりです。
* Ability to use physical motility for the movement of data.
* データの動きに身体運動を使用する能力。
* Ability to move the responsibility for error control from one node to another.
* あるノードから別のノードへのエラー制御に対する責任を移動する機能。
* Ability to cope with intermittent connectivity, including cases where the sender and receiver are not concurrently present in the network.
* 送信者と受信者がネットワーク内に同時に存在しない場合を含む、間欠的な接続性に対処する能力。
* Ability to take advantage of scheduled, predicted, and opportunistic connectivity, whether bidirectional or unidirectional, in addition to continuous connectivity.
* 継続的な接続性に加えて、双方向または一方向にかかわらず、予定、予測、および日和見的接続性を利用する能力。
* Late binding of overlay-network endpoint identifiers to underlying constituent network addresses.
* オーバーレイネットワークエンドポイント識別子の基礎となる構成ネットワークアドレスへの遅れバインディング
For descriptions of these capabilities and the rationale for the DTN architecture, see [ARCH] and [SIGC].
DTNアーキテクチャのこれらの機能と根拠の説明については、[ARCH]と[SIGC]を参照してください。
BP's location within the standard protocol stack is as shown in Figure 1. BP uses underlying "integrated" transport and/or network protocols for communications within a given constituent network. The layer at which those underlying protocols are located is here termed the "convergence layer", and the interface between the Bundle Protocol and a specific underlying protocol is termed a "convergence-layer adapter".
BPの標準プロトコルスタック内の位置は、図1に示す通りです.BPは、特定の構成要素ネットワーク内の通信の基礎となる「統合」トランスポートおよび/またはネットワークプロトコルを使用します。基礎となるプロトコルが配置されているレイヤは、ここでは「収束層」と呼ばれ、バンドルプロトコルと特定の基礎となるプロトコルとの間のインタフェースは「収束層アダプタ」と呼ばれる。
Figure 1 shows three distinct transport and network protocols (denoted T1/N1, T2/N2, and T3/N3).
図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-+ +-^---------+
| T1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ T3 |
+---------v-+ +-^---------v-+ +-^---------v + +-^---------+
| N1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ N3 |
+---------v-+ +-^---------v + +-^---------v-+ +-^---------+
| >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ |
+-----------+ +-------------+ +-------------+ +-----------+
| | | |
|<---- A network ---->| |<---- A network ---->|
| | | |
Figure 1: The Bundle Protocol in the Protocol Stack Model
図1：プロトコルスタックモデルのバンドルプロトコル
This document describes the format of the protocol data units (PDUs) (called "bundles") passed between entities participating in BP communications.
この文書では、BP通信に参加しているエンティティ間で渡されたプロトコルデータユニット（PDU）（「バンドル」と呼ばれる）のフォーマットを記述します。
The entities are referred to as "bundle nodes". This document does not address:
エンティティは「バンドルノード」と呼ばれます。この文書はアドレス指定されていません。
* 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.)
* バンドルノードが特定の種類のインターネットを介してデータを転送するために使用する収束層アダプタの操作。（ただし、ドキュメントはコンバージェンスレイヤで各アダプタによって提供されなければならないサービスについて議論します。）
* The bundle route computation algorithm.
* バンドル経路計算アルゴリズム
* Mechanisms for populating the routing or forwarding information bases of bundle nodes.
* バンドルノードのルーティングまたは転送情報ベースを入力するためのメカニズム。
* The mechanisms for securing bundles en route.
* バンドルを保護するためのメカニズム。
* The mechanisms for managing bundle nodes.
* バンドルノードを管理するためのメカニズム。
Note that implementations of the specification presented in this document will not be interoperable with implementations of RFC 5050.
この文書に記載されている仕様の実装は、RFC 5050の実装と相互運用可能ではないことに注意してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
Bundle: A bundle is a PDU of BP, so named because negotiation of the parameters of a data exchange may be impractical in a delay-tolerant network: it is often better practice to "bundle" with a unit of application data all metadata that might be needed in order to make the data immediately usable when delivered to the application. Each bundle comprises a sequence of two or more "blocks" of protocol data, which serve various purposes.
バンドル：バンドルはBPのPDUであるため、データ交換のパラメータのネゴシエーションは遅延耐性ネットワークでは実用的ではない可能性があるため、「バンドル」の場合、すべてのメタデータをすべてのメタデータに適用することができます。アプリケーションに配信されたときにデータを直ちに使用できるようにするために必要です。各バンドルは、さまざまな目的を果たすプロトコルデータの2つ以上の「ブロック」のシーケンスを備える。
Block: A Bundle Protocol block is one of the protocol data structures that together constitute a well-formed bundle.
ブロック：バンドルプロトコルブロックは、一緒になった束を構成するプロトコルデータ構造の1つである。
Application Data Unit: An application data unit (ADU) is the unit of data whose conveyance to the bundle's destination is the purpose for the transmission of some bundle that is not a fragment (as defined below).
アプリケーションデータユニット：アプリケーションデータユニット（ADU）は、バンドルの宛先への搬送がフラグメントではない一部のバンドルの送信の目的であるデータの単位です（以下に定義されているように）。
Bundle payload: A bundle payload (or simply "payload") is the content of the bundle's payload block. The terms "bundle content", "bundle payload", and "payload" are used interchangeably in this document. For a bundle that is not a fragment (as defined below), the payload is an ADU.
バンドルペイロード：バンドルペイロード（または単に「ペイロード」）は、バンドルのペイロードブロックの内容です。この文書では、「バンドルコンテンツ」、「バンドルペイロード」、および「ペイロード」という用語が互換的に使用されます。フラグメントではないバンドルの場合（以下に定義されているように）ペイロードはADUです。
Partial payload: A partial payload is a payload that comprises either the first N bytes or the last N bytes of some other payload of length M, such that 0 < N < M. Note that every partial payload is a payload and therefore can be further subdivided into partial payloads.
部分ペイロード：部分ペイロードは、1つの部分ペイロードがペイロードであり、したがってペイロードであることに注意してください。部分ペイロードに細分されました。
Fragment: A fragment, a.k.a. "fragmentary bundle", is a bundle whose payload block contains a partial payload.
フラグメント：フラグメント、a.k.a. "francmentarary bundle"は、ペイロードブロックが部分ペイロードを含むバンドルです。
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. Each bundle node has three conceptual components, defined below, as shown in Figure 2: a "Bundle Protocol Agent", a set of zero or more "convergence-layer adapters", and an "application agent". ("CL1 PDUs" are the PDUs of the convergence-layer protocol used in network 1.)
バンドルノード：バンドルノード（または、このドキュメントのコンテキストでは、単に "ノード"）はバンドルを送受信できる任意のエンティティです。各バンドルノードには、図2に示すように、以下に定義されている3つの概念構成要素があります。「バンドルプロトコルエージェント」、0個以上の「収束層アダプタ」と「アプリケーションエージェント」のセットです。（「CL1 PDU」は、ネットワーク1で使用されている収束層プロトコルのPDUです。）
+-----------------------------------------------------------+
|Node |
| |
| +-------------------------------------------------------+ |
| |Application Agent | |
| | | |
| | +--------------------------+ +----------------------+ | |
| | |Administrative element | |Application-specific | | |
| | | | |element | | |
| | | | | | | |
| | +--------------------------+ +----------------------+ | |
| | ^ ^ | |
| | Admin|records Application|data | |
| | | | | |
| +----------------v--------------------------v-----------+ |
| ^ |
| | ADUs |
| | |
| +-----------------------------v-------------------------+ |
| |Bundle Protocol Agent | |
| | | |
| | | |
| +-------------------------------------------------------+ |
| ^ ^ ^ |
| | Bundles | Bundles Bundles | |
| | | | |
| +------v-----+ +-----v------+ +-----v-----+ |
| |CLA 1 | |CLA 2 | |CLA n | |
| | | | | . . . | | |
| | | | | | | |
+-+------------+-----+------------+-----------+-----------+-+
^ ^ ^
CL1|PDUs CL2|PDUs CLn|PDUs
| | |
+------v-----+ +-----v------+ +-----v-----+
Network 1 Network 2 Network n
Figure 2: Components of a Bundle Node
図2：バンドルノードのコンポーネント
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.
バンドルプロトコルエージェント：ノードのバンドルプロトコルエージェント（BPA）は、BPサービスを提供し、バンドルプロトコルの手順を実行するノードコンポーネントです。
Convergence-layer adapter: A convergence-layer adapter (CLA) is a node component that sends and receives bundles on behalf of the BPA, utilizing the services of some "integrated" protocol stack that is supported in one of the networks within which the node is functionally located.
収束層アダプタ：収束層アダプタ（CLA）は、ノードの1つでサポートされているいくつかの「統合」プロトコルスタックのサービスを利用して、BPAに代わってバンドルを送受信するノードコンポーネントです。機能的に配置されています。
Application agent: The application agent (AA) of a node is the node component that utilizes the BP services to effect communication for some user purpose. The application agent in turn has two elements: an administrative element and an application-specific element.
アプリケーションエージェント：ノードのアプリケーションエージェント（aa）は、BPサービスを利用していくつかのユーザ目的のために通信を有効にするノードコンポーネントです。Application Agentには、管理要素とアプリケーション固有の要素の2つの要素があります。
Application-specific element: The application-specific element of an AA is the node component that constructs, requests transmission of, accepts delivery of, and processes units of user application data.
アプリケーション固有の要素：AAのアプリケーション固有の要素は、構築するノードコンポーネントであり、ユーザーアプリケーションデータの配信、およびプロセスの配信、およびプロセスを処理します。
Administrative element: The administrative element of an AA is the node component that constructs and requests transmission of administrative records (defined below), including status reports, and accepts delivery of and processes any administrative records that the node receives.
管理要素：AAの管理要素は、ステータスレポートを含む管理レコードの送信を構築して要求するノードコンポーネントであり、ノードが受信する管理レコードの配信と処理を受け入れます。
Administrative record: A BP administrative record is an ADU that is exchanged between the administrative elements of nodes' application agents for some BP administrative purpose. The only administrative record defined in this specification is the status report, discussed later.
管理レコード：BP管理レコードは、いくつかのBP管理目的のためにノードのアプリケーションエージェントの管理要素間で交換されるADUです。この仕様で定義されている唯一の管理レコードは、後述するステータスレポートです。
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 common identifier, called a "bundle endpoint ID" (or, in this document, simply "endpoint ID"); endpoint IDs are described in detail in Section 4.2.5.1.
バンドルエンドポイント：バンドルエンドポイント（または単に "エンドポイント"）は、「バンドルエンドポイントID」（または単にこのドキュメントでは、単にこのドキュメントでは、単に）と呼ばれる一般的な識別子によってBP目的のために自分自身を識別する0個以上のバンドルノードのセットです。エンドポイントID」;エンドポイントIDは、4.2.5.1項で詳細に説明されています。
Singleton endpoint: A singleton endpoint is an endpoint that always contains exactly one member.
シングルトンエンドポイント：シングルトンエンドポイントは、常に1つのメンバーを含むエンドポイントです。
Registration: A registration is the state machine characterizing a given node's membership in a given endpoint. Any single registration has an associated delivery failure action as defined below and must at any time be in one of two states: Active or Passive. Registrations are local; information about a node's registrations is not expected to be available at other nodes, and the Bundle Protocol does not include a mechanism for distributing information about registrations.
登録：登録は、特定のエンドポイントで特定のノードのメンバーシップを特徴付けるステートマシンです。任意の単一の登録は、以下に定義されているように関連する配信失敗アクションを持ち、いつでも2つの状態のうちの1つにあります。アクティブまたはパッシブです。登録はローカルです。ノードの登録に関する情報は他のノードで利用可能であると予想されず、バンドルプロトコルには登録に関する情報を配信するためのメカニズムは含まれていません。
Delivery: A bundle is considered to have been delivered at a node subject to a registration as soon as the ADU that is the payload of the bundle, together with any relevant metadata (an implementation matter), has been presented to the node's application agent in a manner consistent with the state of that registration.
配信：バンドルのペイロードであるADUが関連するメタデータ（実装問題）とともに、登録の対象となるノードでバンドルが配信されていると考えられています。その登録の状態と一致する方法。
Deliverability: 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) the bundle has not yet been "abandoned" (as defined below) subject to this registration.
配信可能性：バンドルは、（a）登録の宛先エンドポイントが登録が関連付けられているエンドポイントである場合（a）登録の対象と見なされます。（b）バンドルはまだこの登録の対象に配信されていない場合、（c）この登録に従って、バンドルはまだ「放棄されていない」（下に定義されているように）されていません。
Abandonment: To abandon a bundle subject to some registration is to assert that the bundle is not deliverable subject to that registration.
放棄：いくつかの登録の対象となるバンドルを放棄することは、バンドルがその登録の対象となる成果物ではないことを主張することです。
Delivery failure action: The delivery failure action of a registration is the action that is to be taken when a bundle that is "deliverable" subject to that registration is received at a time when the registration is in the Passive state.
配達失敗処置：登録の納入障害行動は、その登録の対象となるバンドルが受渡状態にあるときに受信されたときに取られるべき行動です。
Destination: The destination of a bundle is the endpoint comprising the node(s) at which the bundle is to be delivered (as defined above).
宛先：バンドルの宛先は、バンドルが配信されるノードを含むエンドポイントです（上で定義されているように）。
Transmission: A transmission is an attempt by a node's BPA to cause copies of a bundle to be delivered to one or more of the nodes that are members of some endpoint (the bundle's destination) in response to a transmission request issued by the node's application agent.
送信：送信は、ノードのBPAがノードのアプリケーションエージェントによって発行された送信要求に応答して、バンドルのコピーを一部のエンドポイントのメンバーである1つまたは複数のノードに配信するための試みです。。
Forwarding: To forward a bundle to a node is to invoke the services of one or more CLAs in a sustained effort to cause a copy of the bundle to be received by that node.
転送：バンドルをノードに転送することは、バンドルのコピーをそのノードによって受信させるために、1つ以上のCLAのサービスを持続的な努力で起動することです。
Discarding: To discard a bundle is to cease all operations on the bundle and functionally erase all references to it. The specific procedures by which this is accomplished are an implementation matter.
廃棄：バンドルを破棄することは、バンドル上のすべての操作を中止し、それへのすべての参照を解放することです。これが達成される具体的な手順は実装問題です。
Retention constraint: A retention constraint is an element of the state of a bundle that prevents the bundle from being discarded. That is, a bundle cannot be discarded while it has any retention constraints.
保持制約：保持制約は、バンドルが破棄されるのを防ぐバンドルの状態の要素です。つまり、保持制約がある間、バンドルを破棄することはできません。
Deletion: To delete a bundle is to remove unconditionally all of the bundle's retention constraints, enabling the bundle to be discarded.
削除：バンドルを削除することは、無条件にすべてのバンドルの保持制約を削除することで、バンドルを破棄することができます。
Multiple instances of the same bundle (the same unit of DTN protocol data) might exist concurrently in different parts of a network -- possibly differing in some blocks -- 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 (copy), in that node's local memory, of some bundle that is in the network.
同じバンドルの複数のインスタンス（同じ単位DTNプロトコルデータ）がネットワークのさまざまな部分で並行して存在する可能性があります。。バンドルノードの動作のコンテキストでは、バンドルは、ネットワーク内のいくつかのバンドルのそのノードのローカルメモリ内のインスタンス（コピー）です。
The payload for a bundle forwarded in response to a bundle transmission request is the ADU whose location is provided as a parameter to that request. The payload for a bundle forwarded in response to reception of a bundle is the payload of the received bundle.
バンドル送信要求に応答して転送されたバンドルのペイロードは、そのリクエストに対するパラメータとしてその位置が提供されるADUである。バンドルの受信に応じて転送されたバンドルのペイロードは、受信したバンドルのペイロードです。
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.
最もよく知られている場合、バンドルノードは汎用のコンピュータ上で実行されている単一のプロセスとしてインスタンス化されますが、一般的に定義はより広いことを意味します。バンドルノードは、代わりにスレッド、オブジェクト指向のオブジェクトである可能性があります。オペレーティングシステム、専用ハードウェアデバイスなど
The manner in which the functions of the BPA are performed 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の機能が実行される方法は、全体的に実装問題である。たとえば、BPA機能は各ノードに個別にコーディングされる可能性があります。単一のコンピュータ上の任意の数のバンドルノードによって共通に使用される共有ライブラリとして実装される可能性があります。1つまたは複数のコンピュータ上の任意の数のバンドルノードによる、プロセス間またはネットワーク通信によってサービスが呼び出されるデモンとして実装される可能性があります。ハードウェアで実装される可能性があります。
Every CLA implements its own thin layer of protocol, interposed between BP and the (usually "top") protocol(s) of the underlying integrated protocol stack; this "CL protocol" may only serve to multiplex and demultiplex bundles to and from the underlying integrated protocol, or it may offer additional CL-specific functionality. The manner in which a CLA sends and receives bundles, as well as the definitions of CLAs and CL protocols, are beyond the scope of this specification.
すべてのCLAは、基礎となる統合プロトコルスタックのBPと（通常は「トップ」）プロトコルの間に挿入された独自のプロトコル層を実装しています。この「CLプロトコル」は、基礎となる統合プロトコルとの間で、およびその下にある統合プロトコルとの間でのみマルチプレックスバンドルのみに役立ち、または追加のCL固有機能を提供することができる。CLAがバンドルを送受信する方法、ならびにCLASおよびCLプロトコルの定義は、この仕様の範囲を超えています。
Note that the administrative element of a node's application agent may itself, in some cases, function as a CLA. That is, outgoing bundles may be "tunneled" through encapsulating bundles:
ノードのアプリケーションエージェントの管理要素それ自体が、場合によってはCLAとして機能することがあります。つまり、カプセル化バンドルを介して発信バンドルを「トンネリング」できます。
* An outgoing bundle constitutes a byte array. This byte array may, like any other, be presented to the BPA as an ADU that is to be transmitted to some endpoint.
* 発信バンドルはバイト配列を構成します。このバイト配列は、他のものと同様に、一部のエンドポイントに送信されるべきADUとしてBPAに提示されてもよい。
* The original bundle thus forms the payload of an encapsulating bundle that is forwarded using some other convergence-layer protocol(s).
* したがって、元のバンドルは、他の収束層プロトコルを使用して転送されるカプセル化バンドルのペイロードを形成する。
* When the encapsulating bundle is received, its payload is delivered to the peer application agent administrative element, which then instructs the BPA to dispatch that original bundle in the usual way.
* カプセル化バンドルが受信されると、そのペイロードはピアアプリケーションエージェント管理要素に配信されます。これは、その後、BPAにオリジナルのバンドルを通常の方法でディスパッチするように指示します。
The purposes for which this technique may be useful (such as cross-domain security) are beyond the scope of this specification.
この技術が有用である可能性があること（クロスドメインセキュリティなど）は、この仕様の範囲を超えています。
The only interface between the BPA and the application-specific element of the AA is the BP service interface. But between the BPA and the administrative element of the AA there is a (conceptual) private control interface in addition to the BP service interface. This private control interface enables the BPA and the administrative element of the AA to direct each other to take action under specific circumstances.
BPAとAAのアプリケーション固有の要素の間の唯一のインターフェイスはBPサービスインタフェースです。しかし、BPAとAAの管理要素の間には、BPサービスインタフェースに加えて（概念的な）プライベートコントロールインターフェイスがあります。このプライベートコントロールインタフェースにより、BPAとAAの管理要素は互いに特定の状況下で行動を起こすように指示することができます。
In the case of a node that serves simply as a BP "router", 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.
BP "ルータ"として単に機能するノードの場合、AAはアプリケーション固有の要素はまったくない可能性があります。他のノードのAASのアプリケーション固有の要素は、多重化されたDTN通信サービスを他の多くのアプリケーションに提供することさえ任意に複雑なアプリケーション機能を実行することができる。BPAと同様に、AAがその機能を実行する方法は完全に実装問題です。
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 are all registered in a single common endpoint and will all receive any data delivered at that endpoint. *Note* too that any given bundle node might be registered in multiple bundle endpoints and receive all data delivered at each of those endpoints.
シングルトンは最もよく知られているエンドポイントですが、一般にエンドポイントの概念はより広くなることを意図しています。たとえば、センサネットワーク内のノードは、すべて単一の共通のエンドポイントに登録されている一連のバンドルノードを構成し、そのエンドポイントで配信されたデータをすべて受け取ることができます。*注*指定されたバンドルノードが複数のバンドルエンドポイントに登録され、それぞれのエンドポイントで配信されたすべてのデータを受信することがあります。
Recall that every node, by definition, includes an application agent, which in turn includes an administrative element, which exchanges administrative records with the administrative elements of other nodes. As such, every node is permanently, structurally registered in the singleton endpoint at which administrative records received from other nodes are delivered. Registration in no other endpoint can ever be assumed to be permanent. This endpoint, termed the node's "administrative endpoint", is therefore uniquely and permanently associated with the node, and for this reason the ID of a node's administrative endpoint may always serve as the "node ID" (see Section 4.2.5.2) of the node.
定義ごとにすべてのノードにアプリケーションエージェントが含まれていることを確認します。これには、管理要素を他のノードの管理要素と交換する管理要素が含まれています。そのため、すべてのノードは恒久的に、他のノードから受信した管理レコードが配信されるシングルトンエンドポイントに構造的に登録されています。他のエンドポイントの登録は永続的であると想定することができます。そのため、ノードの「管理エンドポイント」と呼ばれるこのエンドポイントは、ノードに一意にかつ恒久的に関連付けられており、この理由でノードの管理エンドポイントのIDは常に「ノードID」として機能することがあります（セクション4.2.5.2を参照）。ノード。
The destination of every bundle is an endpoint, which may or may not be singleton. The source of every bundle is a node, identified by node ID. Note, though, that the source node ID asserted in a given bundle may be the null endpoint ID (as described later) rather than the ID of the source node; bundles for which the asserted source node ID is the null endpoint ID are termed "anonymous" bundles.
すべてのバンドルの宛先はエンドポイントです。これはシングルトンであるかもしれません。すべてのバンドルのソースは、ノードIDによって識別されるノードです。ただし、指定されたバンドルでアサートされたソースノードIDは、ソースノードのIDではなく、（後述するように）NULLエンドポイントIDです。アサートされたソースノードIDがNULLエンドポイントIDのバンドルは、「匿名」バンドルと呼ばれます。
Any number of transmissions may be concurrently undertaken by the BPA of a given node.
特定のノードのBPAによって任意の数の送信が同時に行われてもよい。
When the BPA of a node determines that it must forward a bundle either to a node that is a member of the bundle's destination endpoint or to some intermediate forwarding node, the BPA invokes the services of one or more CLAs in a sustained effort to cause a copy of the bundle to be received by that node.
ノードのBPAが、バンドルの宛先エンドポイントのメンバーまたは中間転送ノードのメンバーであるノードにバンドルを転送する必要があると判断した場合、BPAは持続的な努力で1つ以上のCLAのサービスを呼び出しています。そのノードによって受信されるバンドルのコピー。
Upon reception, the processing of a bundle 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 newly 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.
受信すると、バンドルの処理は、受信ノードがバンドルの宛先エンドポイントに登録されているか否かによって異なる。そうであれば、バンドルのペイロードが非断片的であれば（おそらく、新しく受信されたバンドルの元のペイロードを含む断片的なペイロードからの再構成の結果として、）、バンドルは通常ノードのアプリケーションエージェントに配信されます。宛先のエンドポイントでのノードのメンバーシップを特徴付ける登録に従います。
The Bundle Protocol itself does not ensure delivery of a bundle to its destination. Data loss along the path to the destination node can be minimized by utilizing reliable convergence-layer protocols between neighbors on all segments of the end-to-end path; however, for end-to-end bundle delivery assurance it will be necessary to develop extensions to the Bundle Protocol and/or application-layer mechanisms.
バンドルプロトコル自体は、その宛先へのバンドルの配信を確実にしません。宛先ノードへのパスに沿ったデータ損失は、エンドツーエンドパスのすべてのセグメント上の隣接者間の信頼性の高い収束層プロトコルを利用することによって最小限に抑えることができます。ただし、エンドツーエンドバンドル配信保証のためには、バンドルプロトコルおよび/またはアプリケーション層のメカニズムへの拡張機能を開発する必要があります。
The Bundle Protocol is designed for extensibility. Bundle Protocol extensions, documented elsewhere, may extend this specification by defining additional:
バンドルプロトコルは拡張性のために設計されています。他の場所で文書化されたバンドルプロトコル拡張機能は、追加を定義することによってこの仕様を拡張することができます。
* blocks
* ブロック
* administrative records
* 管理記録
* bundle processing control flags
* バンドル処理制御フラグ
* block processing control flags
* ブロック処理制御フラグ
* types of bundle status reports
* バンドルステータスレポートの種類
* bundle status report reason codes
* バンドルステータスレポート理由コード
* mandates and constraints on processing that conformant BPAs must perform at specified points in the inbound and outbound bundle processing cycles
* 適合性BPAがインバウンドおよびアウトバウンドバンドル処理サイクルの指定された点で実行する必要がある処理に対する義務と制約
The BPA of each node is expected to provide the following services to the node's application agent:
各ノードのBPAは、ノードのアプリケーションエージェントに次のサービスを提供することが期待されています。
* commencing a registration (registering the node in an endpoint).
* 登録を開始します（エンドポイントにノードを登録する）。
* terminating a registration.
* 登録を終了します。
* switching a registration between Active and Passive states.
* アクティブ状態とパッシブ状態との間の登録を切り替えます。
* transmitting a bundle to an identified bundle endpoint.
* 識別されたバンドルエンドポイントにバンドルを送信します。
* canceling a transmission.
* 送信をキャンセルする。
* polling a registration that is in the Passive state.
* パッシブ状態にある登録をポーリングします。
* delivering a received bundle.
* 受信したバンドルを配信する。
Note that the details of registration functionality are an implementation matter and are beyond the scope of this specification.
登録機能の詳細は実装問題であり、この仕様の範囲を超えています。
The format of bundles SHALL conform to the Concise Binary Object Representation (CBOR) [RFC8949].
バンドルの形式は、簡潔なバイナリオブジェクト表現（CBOR）[RFC8949]に準拠しなければならない。
Cryptographic verification of a block is possible only if the sequence of octets on which the verifying node computes its hash -- the canonicalized representation of the block -- is identical to the sequence of octets on which the hash declared for that block was computed. To ensure that blocks are always in canonical representation when they are transmitted and received, the CBOR encodings of the values of all fields in all blocks MUST conform to the core deterministic encoding requirements as specified in [RFC8949], except that indefinite-length items are not prohibited.
ブロックの暗号検証は、検証ノードがそのハッシュを計算するオクテットのシーケンスがブロックの正規化表現を計算する場合にのみ可能である。ブロックが送信および受信されたときに常に正規表現にあることを確認するために、すべてのブロック内のすべてのフィールドの値のCBORエンコーディングは、[RFC8949]で指定されているコアの決定論的エンコード要件に準拠している必要があります。禁止されていません。
Each bundle SHALL be a concatenated sequence of at least two blocks, represented as a CBOR indefinite-length array. The first block in the sequence (the first item of the array) MUST be a primary bundle block in CBOR encoding as described below; the bundle MUST have exactly one primary bundle block. The primary block MUST be followed by one or more canonical bundle blocks (additional array items) in CBOR encoding as described in Section 4.3.2. Every block following the primary block SHALL be the CBOR encoding of a canonical block. The last such block MUST be a payload block; the bundle MUST have exactly one payload block. The payload block SHALL be followed by a CBOR "break" stop code, terminating the array.
各束は、CBOR不定長さのアレイとして表される、少なくとも2つのブロックの連結シーケンスとする。シーケンス内の最初のブロック（アレイの最初の項目）は、後述のようにCBOR符号化におけるプライマリバンドルブロックでなければならない。バンドルには正確に1つのプライマリバンドルブロックが必要です。第4.3.2節で説明されているように、1次ブロックの後に1つ以上の正規バンドルブロック（追加の配列項目）が続く必要があります。一次ブロックの後の各ブロックは、標準ブロックのCBOR符号化とする。最後のそのようなブロックはペイロードブロックでなければなりません。バンドルには1つのペイロードブロックが必要です。ペイロードブロックの後には、ARRAYを終了して、CBOR「ブレーク」の停止コードが続くものとします。
| (Note that, while CBOR permits considerable flexibility in the
| encoding of bundles, this flexibility must not be interpreted
| as inviting increased complexity in PDU structure.)
Associated with each block of a bundle is a block number. The block number uniquely identifies the block within the bundle, enabling blocks (notably Bundle Protocol Security blocks) to reference other blocks in the same bundle without ambiguity. The block number of the primary block is implicitly zero; the block numbers of all other blocks are explicitly stated in block headers as noted below. Block numbering is unrelated to the order in which blocks are sequenced in the bundle. The block number of the payload block is always 1.
バンドルの各ブロックに関連付けられているのはブロック番号です。ブロック番号はバンドル内のブロックを一意に識別し、ブロック（特にバンドルセキュリティブロック）を有効にして、あいまいさなく同じバンドル内の他のブロックを参照することができます。プライマリブロックのブロック番号は暗黙的にゼロです。他のすべてのブロックのブロック番号は、以下のようにブロックヘッダーに明示的に記載されています。ブロック番号付けは、バンドル内でブロックがシーケンスされている順序とは無関係です。ペイロードブロックのブロック番号は常に1です。
An implementation of the Bundle Protocol MAY discard any sequence of bytes that does not conform to the Bundle Protocol specification.
バンドルプロトコルの実装は、バンドルプロトコル仕様に準拠していない一連のバイトを破棄する可能性があります。
An implementation of the Bundle Protocol MAY accept a sequence of bytes that does not conform to the Bundle Protocol specification (e.g., one that represents data elements in fixed-length arrays rather than indefinite-length arrays) and transform it into conformant BP structure before processing it. Procedures for accomplishing such a transformation are beyond the scope of this specification.
バンドルプロトコルの実装は、バンドルプロトコル仕様に準拠していない一連のバイト（例えば、不定長のアレイではなく固定長アレイ内のデータ要素を表すもの）を受け入れ、処理前にそれを準拠BP構造に変換することができる。それ。そのような変換を達成するための手順は、本明細書の範囲を超えている。
CRC type is an unsigned integer type code for which the following values (and no others) are valid:
CRCタイプは、以下の値（および他のものがない）が有効な符号なし整数型コードです。
* 0 indicates "no Cyclic Redundancy Check (CRC) is present."
* 0は「巡回冗長検査（CRC）が存在しないことを示します。
* 1 indicates "a standard X-25 CRC-16 is present." [CRC16]
* 1は「標準X-25 CRC-16が存在する」を示します。[CRC16]
* 2 indicates "a standard CRC32C (Castagnoli) CRC-32 is present." [RFC4960]
* 2は「標準的なCRC32C（Castagnoli）CRC-32が存在することを示しています。」[RFC4960]
CRC type SHALL be represented as a CBOR unsigned integer.
CRCタイプは、CBOR符号なし整数として表されます。
For examples of CRC32C CRCs, see Appendix A.4 of [RFC7143].
CRC32C CRCの例については、[RFC7143]の付録A.4を参照してください。
Note that more robust protection of BP data integrity, as needed, may be provided by means of Block Integrity Blocks (BIBs) as defined in the Bundle Protocol Security specification [BPSEC].
必要に応じて、BPデータの整合性をより堅牢な保護することで、バンドルプロトコルセキュリティ仕様[BPSEC]で定義されているブロックの整合性ブロック（BIB）によって提供されてもよい。
The CRC SHALL be omitted from a block if and only if the block's CRC type code is zero.
ブロックのCRCタイプコードがゼロの場合に限り、CRCはブロックから省略されなければならない。
When not omitted, the CRC SHALL be represented as a CBOR byte string of two bytes (that is, CBOR additional information 2, if CRC type is 1) or of four bytes (that is, CBOR additional information 4, if CRC type is 2); in each case, the sequence of bytes SHALL constitute an unsigned integer value (of 16 or 32 bits, respectively) in network byte order.
省略されていない場合、CRCは、2バイトのCBORバイト文字列（すなわち、CRCタイプが1の場合はCBOR付加情報2）または4バイト（すなわち、CBOR追加情報4、CRCタイプが2の場合、CBOR付す。）;いずれの場合も、バイトのシーケンスは（それぞれ16または32ビット）ネットワークバイトオーダーで符号なし整数値を構成しなければならない。
Bundle processing control flags assert properties of the bundle as a whole rather than of any particular block of the bundle. They are conveyed in the primary block of the bundle.
バンドル処理制御フラグは、バンドルの特定のブロックではなく、バンドル全体のプロパティをアサートします。それらはバンドルの主ブロックで伝えられます。
The following properties are asserted by the bundle processing control flags:
次のプロパティは、バンドル処理制御フラグによってアサートされます。
* The bundle is a fragment. (Boolean)
* バンドルはフラグメントです。（ブール人）
* The bundle's payload is an administrative record. (Boolean)
* バンドルのペイロードは管理レコードです。（ブール人）
* The bundle must not be fragmented. (Boolean)
* バンドルを断片化してはいけません。（ブール人）
* Acknowledgment by the user application is requested. (Boolean)
* ユーザーアプリケーションによる確認応答が要求されます。（ブール人）
* Status time is requested in all status reports. (Boolean)
* ステータス時間はすべてのステータスレポートで要求されます。（ブール人）
* Flags requesting types of status reports (all Boolean):
* ステータスレポートの種類を要求するフラグ（All Boolean）：
- Request reporting of bundle reception.
- バンドル受信の報告を要求します。
- Request reporting of bundle forwarding.
- バンドル転送の報告を要求します。
- Request reporting of bundle delivery.
- バンドル配信の報告を要求します。
- Request reporting of bundle deletion.
- バンドル削除の報告を要求します。
If the bundle processing control flags indicate that the bundle's ADU is an administrative record, then all status report request flag values MUST be zero.
バンドル処理制御フラグがバンドルのADUが管理レコードであることを示す場合は、すべてのステータスレポート要求フラグ値がゼロでなければなりません。
If the bundle's source node is omitted (i.e., the source node ID is the ID of the null endpoint, which has no members as discussed below; this option enables anonymous bundle transmission), then the bundle is not uniquely identifiable and all Bundle Protocol features that rely on bundle identity must therefore be disabled: the "Bundle must not be fragmented" flag value MUST be 1, and all status report request flag values MUST be zero.
バンドルのソースノードが省略されている場合（すなわち、送信元ノードIDは、後述のメンバーがないNULLエンドポイントのIDです。このオプションは匿名バンドル送信を有効にします）、バンドルは一意に識別可能で、すべてのバンドルプロトコル機能ではありません。バンドルアイデンティティに依存する必要があるため、「バンドルを断片化してはいけません」フラグ値は1でなければならず、すべてのステータスレポート要求フラグ値はゼロでなければなりません。
Bundle processing control flags that are unrecognized MUST be ignored, as future definitions of additional flags might not be integrated simultaneously into the Bundle Protocol implementations operating at all nodes.
追加のフラグの将来の定義がすべてのノードで動作するバンドルプロトコル実装に同時に統合されない可能性があるため、認識されないバンドル処理制御フラグは無視されなければなりません。
The bundle processing control flags SHALL be represented as a CBOR unsigned integer item, the value of which SHALL be processed as a bit field indicating the control flag values as follows (note that bit numbering in this instance is reversed from the usual practice, beginning with the low-order bit instead of the high-order bit, in recognition of the potential definition of additional control flag values in the future):
バンドル処理制御フラグはCBOR符号なし整数項目として表され、その値は以下のように制御フラグ値を示すビットフィールドとして処理されるものとする（この場合のビット番号付けは通常の慣行から逆にすることに注意してください。高次ビットの代わりに下位ビットの代わりに、将来の追加制御フラグ値の潜在的な定義を認識しています。
Bit 0 (the low-order bit, 0x000001): Bundle is a fragment.
ビット0（下位ビット、0x000001）：バンドルはフラグメントです。
Bit 1 (0x000002): ADU is an administrative record.
ビット1（0x000002）：ADUは管理レコードです。
Bit 2 (0x000004): Bundle must not be fragmented.
ビット2（0x000004）：バンドルを断片化しないでください。
Bit 3 (0x000008): Reserved.
ビット3（0x000008）：予約済み。
Bit 4 (0x000010): Reserved.
ビット4（0x000010）：予約済み。
Bit 5 (0x000020): Acknowledgement by application is requested.
ビット5（0x000020）：アプリケーションによる確認応答が要求されます。
Bit 6 (0x000040): Status time requested in reports.
ビット6（0x000040）：レポートで要求されたステータス時間。
Bit 7 (0x000080): Reserved.
ビット7（0x000080）：予約済み。
Bit 8 (0x000100): Reserved.
ビット8（0x000100）：予約済み。
Bit 9 (0x000200): Reserved.
ビット9（0x000200）：予約済み。
Bit 10 (0x000400): Reserved.
ビット10（0x000400）：予約済み。
Bit 11 (0x000800): Reserved.
ビット11（0x000800）：予約済み。
Bit 12 (0x001000): Reserved.
ビット12（0x001000）：予約済み。
Bit 13 (0x002000): Reserved.
ビット13（0x002000）：予約済み。
Bit 14 (0x004000): Request reporting of bundle reception.
ビット14（0x004000）：バンドル受信の報告を要求します。
Bit 15 (0x008000): Reserved.
ビット15（0x008000）：予約済み。
Bit 16 (0x010000): Request reporting of bundle forwarding.
ビット16（0x010000）：バンドル転送の報告を要求します。
Bit 17 (0x020000): Request reporting of bundle delivery.
ビット17（0x020000）：バンドル配信の報告を要求します。
Bit 18 (0x040000): Request reporting of bundle deletion.
ビット18（0x040000）：バンドル削除の報告を要求します。
Bits 19-20: Reserved.
ビット19-20：予約済み。
Bits 21-63: Unassigned.
ビット21-63：割り当てられていません。
The block processing control flags assert properties of canonical bundle blocks. They are conveyed in the header of the block to which they pertain.
ブロック処理制御フラグは、正規バンドルブロックのプロパティをアサートします。それらはそれらがそれに関係するブロックのヘッダーに運ばれます。
Block processing control flags that are unrecognized MUST be ignored, as future definitions of additional flags might not be integrated simultaneously into the Bundle Protocol implementations operating at all nodes.
追加のフラグの将来の定義がすべてのノードで動作するバンドルプロトコル実装に同時に統合されない可能性があるため、認識されないブロック処理制御フラグは無視されなければなりません。
The block processing control flags SHALL be represented as a CBOR unsigned integer item, the value of which SHALL be processed as a bit field indicating the control flag values as follows (note that bit numbering in this instance is reversed from the usual practice, beginning with the low-order bit instead of the high-order bit, for agreement with the bit numbering of the bundle processing control flags):
ブロック処理制御フラグはCBOBOR符号なし整数項目として表され、その値は、以下のように制御フラグ値を示すビットフィールドとして処理されるものとする（この場合のビット番号付けが通常の慣行から逆にすることに注意することに注意してください）。バンドル処理制御フラグのビット番号付けと一致するように、高次ビットの代わりに下位ビット）。
Bit 0 (the low-order bit, 0x01): Block must be replicated in every fragment.
ビット0（下位ビット、0x01）：ブロックはフラグメントごとに複製されなければなりません。
Bit 1 (0x02): Transmit status report if block can't be processed.
ビット1（0x02）：ブロックを処理できない場合はステータスレポートを送信します。
Bit 2 (0x04): Delete bundle if block can't be processed.
ビット2（0x04）：ブロックを処理できない場合は、バンドルを削除します。
Bit 3 (0x08): Reserved.
ビット3（0x08）：予約済み。
Bit 4 (0x10): Discard block if it can't be processed.
ビット4（0x10）：処理できない場合は、ブロックを破棄します。
Bit 5 (0x20): Reserved.
ビット5（0x20）：予約済み。
Bit 6 (0x40): Reserved.
ビット6（0x40）：予約済み。
Bits 7-63: Unassigned.
ビット7-63：割り当てられていません。
For each bundle whose bundle processing control flags indicate that the bundle's ADU is an administrative record, or whose source node ID is the null endpoint ID as defined below, the value of the "Transmit status report if block can't be processed" flag in every canonical block of the bundle MUST be zero.
バンドル処理制御フラグがバンドルのADUが管理レコードであることを示すバンドルごとに、またはソースノードIDが以下に定義されているようなNULLエンドポイントIDの場合、「ブロックを処理できない場合は送信ステータスレポート」の値が含まれています。バンドルのすべての正規ブロックはゼロでなければなりません。
The destinations of bundles are bundle endpoints, identified by text strings termed "endpoint IDs" (see Section 3.1). Each endpoint ID (EID) is a Uniform Resource Identifier [URI]. As such, each endpoint ID can be characterized as having this general structure:
バンドルの宛先はバンドルエンドポイントで、「エンドポイントID」と呼ばれるテキスト文字列によって識別されます（セクション3.1を参照）。各エンドポイントID（EID）は、統一リソース識別子[URI]です。そのため、各エンドポイントIDは、この一般的な構造を持つように特徴付けることができます。
< scheme name > : < scheme-specific part, or "SSP" >
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 scheme-specific part (SSP). Each scheme that may be used to form a BP endpoint ID must be added to the "Bundle Protocol URI Scheme Types" registry, maintained by IANA as described in Section 9.6; association of a unique URI scheme code number with each scheme name in this registry helps to enable compact representation of endpoint IDs in bundle blocks. Note that the set of allowable schemes is effectively unlimited. Any scheme conforming to [URIREG] may be added to the registry of URI scheme code numbers and thereupon used in a Bundle Protocol endpoint ID.
エンドポイントIDの<scheme name>で識別される方式は、スキーム固有部分（SSP）の解析と解釈方法を完全に説明する構文と意味規則のセットです。BPエンドポイントIDを形成するために使用され得る各方式は、セクション9.6で説明されているように、IANAによって維持される「バンドルプロトコルURIスキームタイプ」レジストリに追加する必要があります。このレジストリ内の固有のURIスキームコード番号の関連付けは、このレジストリ内の各スキーム名との関連付けを使用して、バンドルブロック内のエンドポイントIDをコンパクトな表現を有効にするのに役立ちます。許容スキームのセットは効果的に無制限であることに注意してください。URIREG]に準拠したスキームは、URIスキームコード番号のレジストリに追加され、その後はバンドルプロトコルエンドポイントIDで使用されてもよい。
Each entry in the registry of URI scheme code numbers MUST contain a reference to a scheme code number definition document, which defines the manner in which the scheme-specific part of any URI formed in that scheme is parsed and interpreted and MUST be CBOR encoded for transmission as a BP endpoint ID. The scheme code number definition document may also contain information as to (a) which convergence-layer protocol(s) may be used to forward a bundle to a BP destination endpoint identified by such an ID and (b) how the ID of the convergence-layer protocol endpoint to use for that purpose can be inferred from that destination endpoint ID.
URIスキームコード番号のレジストリ内の各エントリは、そのスキームで形成された任意のURIの方式固有の部分が解析され、CBORエンコードされている方法を定義する、スキームコード番号定義文書への参照を含める必要があります。BPエンドポイントIDとしての送信。このようなIDによって識別されるBP宛先エンドポイントにバンドルを転送するために、（a）の情報を用いて（a）を使用して（b）、（b）収束のIDのIDを転送するために使用され得る（a）の情報を含むことができる。その目的のために使用するための - レイヤプロトコルエンドポイントは、その目的のエンドポイントIDから推測できます。
Note that, although endpoint IDs are 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サービスインタフェースの実装は、国際化された方法（例えば、国際化されたリソース識別子（IRIS）においてエンドポイントIDの表現をサポートすることがあることに留意されたい。[RFC3987]を参照）。
Each BP endpoint ID (EID) SHALL be represented as a CBOR array comprising two items.
各BPエンドポイントID（EID）は、2つの項目を含むCBORアレイとして表されます。
The first item of the array SHALL be the code number identifying the endpoint ID's URI scheme, as defined in the registry of URI scheme code numbers for the Bundle Protocol. Each URI scheme code number SHALL be represented as a CBOR unsigned integer.
アレイの最初の項目は、バンドルプロトコルのURIスキームコード番号のレジストリで定義されているように、エンドポイントIDのURIスキームを識別するコード番号とする。各URIスキームコード番号は、CBOR符号なし整数として表されます。
The second item of the array SHALL be the applicable CBOR encoding of the scheme-specific part of the EID, defined as noted in the references(s) for the URI scheme code number registry entry for the EID's URI scheme.
アレイの2番目の項目は、EIDのURIスキームのURIスキームコード番号レジストリエントリの参照に記載されているように定義された、EIDのスキーム固有の部分の適用可能なCBORエンコーディングとする。
The "dtn" scheme supports the identification of BP endpoints by arbitrarily expressive character strings. It is specified as follows:
「DTN」方式は、任意の表現性の文字列によるBPエンドポイントの識別をサポートする。次のように指定されています。
Scheme syntax: This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234].
Scheme Syntax：この仕様では、[RFC5234]の拡張された背景 - Naur形式（ABNF）表記を使用しています。
dtn-uri = "dtn:" ("none" / dtn-hier-part)
dtn-hier-part = "//" node-name name-delim demux ; a path-rootless
node-name = reg-name
name-delim = "/"
name-delim = "/"
demux = *VCHAR
Scheme semantics: URIs of the dtn scheme are used as endpoint identifiers in the Delay-Tolerant Networking (DTN) Bundle Protocol (BP) as described in the present document.
Scheme Semantics：DTN方式のURIは、本文書に記載されているように、遅延耐性ネットワーキング（DTN）バンドルプロトコル（BP）内のエンドポイント識別子として使用されます。
The endpoint ID "dtn:none" identifies the "null endpoint", the endpoint that by definition never has any members.
エンドポイントID "dtn：none"は "NULL Endpoint"を識別し、定義によって決してメンバーを持っていないエンドポイントです。
All BP endpoints identified by all other dtn-scheme endpoint IDs for which the first character of demux is a character other than '~' (tilde) are singleton endpoints. All BP endpoints identified by dtn-scheme endpoint IDs for which the first character *is* '~' (tilde) are *not* singleton endpoints.
Demuxの最初の文字が '〜'（チルダ）以外の文字である他のすべてのDTN方式のエンドポイントIDによって識別されるすべてのBPエンドポイントはシングルトンエンドポイントです。最初の文字*が* '〜'（チルダ）であるDTN方式のエンドポイントIDによって識別されるすべてのBPエンドポイントは*シングルトンエンドポイントではありません。
A dtn-scheme endpoint ID for which the demux is of length zero MAY identify the administrative endpoint for the node identified by node-name, and as such may serve as a node ID. No dtn-scheme endpoint ID for which the demux is of non-zero length may do so.
dtn-schemeエンドポイントIDは、demuxが長さゼロの場合、ノード名によって識別されたノードの管理エンドポイントを識別することができ、そのようにノードIDとして機能することがあります。DTN方式のエンドポイントIDは、DEMUXがゼロ以外の長さである可能性があります。
Note that these syntactic rules impose constraints on dtn-scheme endpoint IDs that were not imposed by the original specification of the dtn scheme as provided in [RFC5050]. It is believed that the dtn-scheme endpoint IDs employed by BP applications conforming to [RFC5050] are in most cases unlikely to be in violation of these rules, but the developers of such applications are advised of the potential for compromised interoperation.
これらの構文規則は、[RFC5050]で提供されているDTN方式の元の仕様によって課されなかったDTN方式のエンドポイントIDに制約を課します。[RFC5050]に準拠しているBPアプリケーションによって採用されているDTN-SchemeエンドポイントIDは、ほとんどの場合、これらの規則に違反している可能性がほとんどありませんが、そのようなアプリケーションの開発者は侵害された相互運用の可能性についてお勧めします。
Encoding considerations: For transmission as a BP endpoint ID, the scheme-specific part of a URI of the dtn scheme SHALL be represented as a CBOR text string unless the EID's SSP is "none", in which case the SSP SHALL be represented as a CBOR unsigned integer with the value zero. For all other purposes, URIs of the dtn scheme are encoded exclusively in US-ASCII characters.
符号化に関する考慮事項：BPエンドポイントIDとしての送信のために、EIDのSSPが「なし」でない限り、DTN方式のURIの方式固有の部分はCBOBERテキスト文字列として表され、その場合SSPはAとして表されます。値ゼロのCBOR符号なし整数。他のすべての目的のために、DTNスキームのURIは排他的にUS-ASCII文字でエンコードされています。
Interoperability considerations: None.
相互運用性の考慮事項：なし。
Security considerations:
セキュリティ上の考慮事項
Reliability and consistency: None of the BP endpoints identified by the URIs of the dtn scheme are guaranteed to be reachable at any time, and the identity of the processing entities operating on those endpoints is never guaranteed by the Bundle Protocol itself. Verification of the signature provided by the Block Integrity Block targeting the bundle's primary block, as defined by Bundle Protocol Security [BPSEC], is required for this purpose.
信頼性と一貫性：DTN方式のURIによって識別されるBPエンドポイントのどれもいつでも到達可能ではありません。また、これらのエンドポイントで動作する処理エンティティの識別情報は、バンドルプロトコル自体によって保証されません。バンドルプロトコルセキュリティ[BPSEC]で定義されているように、Bundleのプライマリブロックをターゲットとするブロックインテグリティブロックによって提供される署名の検証は、この目的のために必要です。
Malicious construction: Malicious construction of a conformant dtn-scheme URI is limited to the malicious selection of node names and the malicious selection of demux strings. That is, a maliciously constructed dtn-scheme URI could be used to direct a bundle to an endpoint that might be damaged by the arrival of that bundle or, alternatively, to declare a false source for a bundle and thereby cause incorrect processing at a node that receives the bundle. In both cases (and indeed in all bundle processing), the node that receives a bundle should verify its authenticity and validity before operating on it in any way.
悪意のある構造：適合性DTN方式のURIの悪意のある構造は、ノード名の悪意のある選択とDemux文字列の悪意のある選択に制限されています。つまり、悪意を持って構築されたDTN-Scheme URIを使用して、そのバンドルの到着によって損傷を受ける可能性があるエンドポイントにバンドルを指示することもできます。代替的に、バンドルの誤ったソースを宣言し、それによってノードで誤った処理を引き起こすことができます。それはバンドルを受け取ります。どちらの場合（そしてすべてのバンドル処理では実際に）、バンドルを受信するノードは、その真正性と有効性を検証する必要があります。
Back-end transcoding: The limited expressiveness of URIs of the dtn scheme effectively eliminates the possibility of threat due to errors in back-end transcoding.
バックエンドトランスコーディング：DTN方式のURIの限定的な表現性は、バックエンドトランスコーディングのエラーによる脅威の可能性を効果的に排除します。
Rare IP address formats: Not relevant, as IP addresses do not appear anywhere in conformant dtn-scheme URIs.
まれなIPアドレスフォーマット：IPアドレスが準拠のDTNスキームURIのどこにも表示されないため、関連性がありません。
Sensitive information: Because dtn-scheme URIs are used only to represent the identities of Bundle Protocol endpoints, the risk of disclosure of sensitive information due to interception of these URIs is minimal. Examination of dtn-scheme URIs could be used to support traffic analysis; where traffic analysis is a plausible danger, bundles should be conveyed by secure convergence-layer protocols that do not expose endpoint IDs.
機密情報：DTN方式のURIは、バンドルプロトコルエンドポイントのIDを表すのにのみ使用されているため、これらのURIの傍受による機密情報の開示のリスクは最小限です。トラフィック分析をサポートするためにDTNスキームURIの検査を使用することができます。トラフィック分析がもっともらしい危険である場合、束はエンドポイントIDを公開しない安全な収束層プロトコルによって伝えられるべきです。
Semantic attacks: The simplicity of dtn-scheme URI syntax minimizes the possibility of misinterpretation of a URI by a human user.
意味発作：DTN方式のURI構文の単純さは、人間のユーザーによるURIの誤解の可能性を最小限に抑えます。
The "ipn" scheme supports the identification of BP endpoints by pairs of unsigned integers, for compact representation in bundle blocks. It is specified as follows:
「IPN」方式は、バンドルブロック内のコンパクトな表現のために、符号なし整数のペアによるBPエンドポイントの識別をサポートします。次のように指定されています。
Scheme syntax: This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234], including the core ABNF syntax rule for DIGIT defined by that specification.
Scheme Syntax：この仕様では、その仕様で定義された桁のコアABNF構文規則を含む、[RFC5234]の拡張BACKUS-NAUR形式（ABNF）表記を使用します。
ipn-uri = "ipn:" ipn-hier-part
ipn-uri = "IPN：" IPN-Hier-Part
ipn-hier-part = node-nbr nbr-delim service-nbr ; a path-rootless
IPN-hier-part =ノード-NBR NBR-DELIM SERVICE-NBR。パス - 根のない
node-nbr = 1*DIGIT
nbr-delim = "."
NBR-DELIM = "。"
service-nbr = 1*DIGIT
Scheme semantics: URIs of the ipn scheme are used as endpoint identifiers in the Delay-Tolerant Networking (DTN) Bundle Protocol (BP) as described in the present document.
Scheme Semantics：IPN方式のURIは、本文書に記載されているように、遅延耐性ネットワーキング（DTN）バンドルプロトコル（BP）内のエンドポイント識別子として使用されています。
All BP endpoints identified by ipn-scheme endpoint IDs are singleton endpoints.
IPN-SchemeエンドポイントIDによって識別されるすべてのBPエンドポイントはシングルトンエンドポイントです。
An ipn-scheme endpoint ID for which service-nbr is zero MAY identify the administrative endpoint for the node identified by node-nbr, and as such may serve as a node ID. No ipn-scheme endpoint ID for which service-nbr is non-zero may do so.
サービス-NBRがゼロであるIPN方式のエンドポイントIDは、ノード-NBRによって識別されたノードの管理エンドポイントを識別することができ、そのようにノードIDとして機能することがあります。Service-NBRがゼロ以外のIPN-SchemeエンドポイントIDはそうできません。
Encoding considerations: For transmission as a BP endpoint ID, the scheme-specific part of a URI of the ipn scheme SHALL be represented as a CBOR array comprising two items. The first item of this array SHALL be the EID's node number (a number that identifies the node) represented as a CBOR unsigned integer. The second item of this array SHALL be the EID's service number (a number that identifies some application service) represented as a CBOR unsigned integer. For all other purposes, URIs of the ipn scheme are encoded exclusively in US-ASCII characters.
符号化の考慮事項：BPエンドポイントIDとしての送信のために、IPN方式のURIの方式固有部分は、2つの項目を含むCBOR配列として表されるものとします。この配列の最初の項目は、CBOR符号なし整数として表されるEIDのノード番号（ノードを識別する数字）です。この配列の2番目の項目は、CBOR符号なし整数として表されるEIDのサービス番号（一部のアプリケーションサービスを識別する数字）とする。他のすべての目的で、IPNスキームのURIは排他的にUS-ASCII文字でエンコードされています。
Interoperability considerations: None.
相互運用性の考慮事項：なし。
Security considerations:
セキュリティ上の考慮事項
Reliability and consistency: None of the BP endpoints identified by the URIs of the ipn scheme are guaranteed to be reachable at any time, and the identity of the processing entities operating on those endpoints is never guaranteed by the Bundle Protocol itself. Verification of the signature provided by the Block Integrity Block targeting the bundle's primary block, as defined by Bundle Protocol Security [BPSEC], is required for this purpose.
信頼性と一貫性：IPNスキームのURIによって識別されるBPエンドポイントのどれもいつでも到達可能ではなく、それらのエンドポイントで動作する処理エンティティの識別はバンドルプロトコル自体によって保証されることはありません。バンドルプロトコルセキュリティ[BPSEC]で定義されているように、Bundleのプライマリブロックをターゲットとするブロックインテグリティブロックによって提供される署名の検証は、この目的のために必要です。
Malicious construction: Malicious construction of a conformant ipn-scheme URI is limited to the malicious selection of node numbers and the malicious selection of service numbers. That is, a maliciously constructed ipn-scheme URI could be used to direct a bundle to an endpoint that might be damaged by the arrival of that bundle or, alternatively, to declare a false source for a bundle and thereby cause incorrect processing at a node that receives the bundle. In both cases (and indeed in all bundle processing), the node that receives a bundle should verify its authenticity and validity before operating on it in any way.
悪意のある構造：適合性IPN方式のURIの悪意のある構造は、ノード番号の悪意のある選択および悪意のあるサービス番号の選択に限定されています。つまり、悪意を持って構築されたIPN-Scheme URIを使用して、そのバンドルの到着によって損傷を受ける可能性があるエンドポイントにバンドルを指示することもできます。あるいは、またはあるいは、バンドルの誤ったソースを宣言し、それによってノードで誤った処理を引き起こすことができます。それはバンドルを受け取ります。どちらの場合（そしてすべてのバンドル処理では実際に）、バンドルを受信するノードは、その真正性と有効性を検証する必要があります。
Back-end transcoding: The limited expressiveness of URIs of the ipn scheme effectively eliminates the possibility of threat due to errors in back-end transcoding.
バックエンドトランスコーディング：IPN方式のURIの限定的な表現性は、バックエンドトランスコーディングのエラーによる脅威の可能性を効果的に排除します。
Rare IP address formats: Not relevant, as IP addresses do not appear anywhere in conformant ipn-scheme URIs.
まれなIPアドレスフォーマット：IPアドレスが適合性IPN-Syme URIのどこにも表示されないため、関連性がありません。
Sensitive information: Because ipn-scheme URIs are used only to represent the identities of Bundle Protocol endpoints, the risk of disclosure of sensitive information due to interception of these URIs is minimal. Examination of ipn-scheme URIs could be used to support traffic analysis; where traffic analysis is a plausible danger, bundles should be conveyed by secure convergence-layer protocols that do not expose endpoint IDs.
機密情報：IPN-Scheme URIは、バンドルプロトコルエンドポイントのIDを表すためにのみ使用されているため、これらのURIの傍受による機密情報の開示のリスクは最小限です。IPN方式のURIの検査は、交通分析をサポートするために使用され得る。トラフィック分析がもっともらしい危険である場合、束はエンドポイントIDを公開しない安全な収束層プロトコルによって伝えられるべきです。
Semantic attacks: The simplicity of ipn-scheme URI syntax minimizes the possibility of misinterpretation of a URI by a human user.
意味発作：IPN方式のURI構文の単純さは、人間のユーザーによるURIの誤解の可能性を最小限に抑えます。
For many purposes of the Bundle Protocol, it is important to identify the node that is operative in some context.
バンドルプロトコルの多くの目的のためには、いくつかの文脈で動作するノードを識別することが重要です。
As discussed in Section 3.1, nodes are distinct from endpoints; specifically, an endpoint is a set of zero or more nodes. But rather than define a separate namespace for node identifiers, we instead use endpoint identifiers to identify nodes as discussed in Section 3.2. Formally:
セクション3.1で説明したように、ノードはエンドポイントとは異なります。具体的には、エンドポイントは0個以上のノードのセットです。しかし、ノード識別子の別の名前空間を定義するのではなく、代わりにエンドポイント識別子を使用してセクション3.2で説明したようにノードを識別します。正式に：
* Every node is, by definition, permanently registered in the singleton endpoint at which administrative records are delivered to its application agent's administrative element, termed the node's "administrative endpoint".
* すべてのノードは、管理レコードがアプリケーションエージェントの管理要素に配信されるシングルトンエンドポイントに恒久的に登録され、ノードの「管理エンドポイント」と呼びました。
* As such, the EID of a node's administrative endpoint SHALL uniquely identify that node.
* そのため、ノードの管理エンドポイントのEIDはそのノードを一意に識別しなければならない。
* The EID of any singleton endpoint is allowed to serve as a "node ID" identifying the node that is the sole member of that endpoint.
* シングルトンエンドポイントのEIDは、そのエンドポイントのソールメンバーであるノードを識別する「ノードID」として機能することができます。
A DTN time is an unsigned integer indicating the number of milliseconds that have elapsed since the DTN Epoch, 2000-01-01 00:00:00 +0000 (UTC). DTN time is not affected by leap seconds.
DTN時間は、DTN Epoch、2000-01-01 00:00:00 0000（UTC）以降に経過したミリ秒数を示す符号なし整数です。DTN時間はうるう秒の影響を受けません。
Each DTN time SHALL be represented as a CBOR unsigned integer item. Implementers need to be aware that DTN time values conveyed in CBOR encoding in bundles will nearly always exceed (2^32 - 1); the manner in which a DTN time value is represented in memory is an implementation matter. The DTN time value zero indicates that the time is unknown.
各DTN時間は、CBOBOR符号なし整数項目として表されます。実装者は、バンドル内のCBORエンコーディングで伝達されたDTN時間値がほぼ常に超えることを認識する必要があります（2 ^ 32 - 1）。DTN時間値がメモリに表される方法は実装問題です。DTN時間値ゼロは、時間が不明であることを示します。
Each bundle's creation timestamp SHALL be represented as a CBOR array comprising two items.
各バンドルの作成タイムスタンプは、2つの項目を含むCBOR配列として表されます。
The first item of the array, termed "bundle creation time", SHALL be the DTN time at which the transmission request was received that resulted in the creation of the bundle, represented as a CBOR unsigned integer.
「バンドル作成時刻」と呼ばれるアレイの最初の項目は、CBOR符号なし整数として表されるバンドルの作成をもたらした送信要求が受信されたDTN時刻とする。
The second item of the array, termed the creation timestamp's "sequence number", SHALL be the latest value (as of the time at which the transmission request was received) of a monotonically increasing positive integer counter managed by the source node's BPA, represented as a CBOR unsigned integer. The sequence counter MAY be reset to zero whenever the current time advances by one millisecond.
作成タイムスタンプの「シーケンス番号」と呼ばれるアレイの2番目の項目は、ソースノードのBPAによって管理されている単調に増加する正の正の整数カウンタの最新の値（送信要求が受信された時点）とする。CBOR符号なし整数。現在の時間が1ミリ秒だけ進むたびに、シーケンスカウンタはゼロにリセットされてもよい。
For nodes that lack accurate clocks, it is recommended that bundle creation time be set to zero and that the counter used as the source of the bundle sequence count never be reset to zero.
正確なクロックを欠いているノードの場合、バンドル作成時刻をゼロに設定し、バンドルシーケンスカウントのソースとして使用されるカウンタをゼロにリセットすることは推奨されます。
Note that, in general, the creation of two distinct bundles with the same source node ID and bundle creation timestamp may result in unexpected network behavior and/or suboptimal performance. The combination of source node ID and bundle creation timestamp serves to identify a single transmission request, enabling it to be acknowledged by the receiving application (provided the source node ID is not the null endpoint ID).
一般に、同じソースノードIDとバンドル作成タイムスタンプを持つ2つの異なるバンドルを作成すると、予期しないネットワークの動作や最適なパフォーマンスが向上します。ソースノードIDとバンドル作成タイムスタンプの組み合わせは、単一の送信要求を識別するために機能し、受信アプリケーションによって確認されることを可能にします（ソースノードIDがNULLエンドポイントIDではありません）。
Block-type-specific data in each block (other than the primary block) SHALL be the applicable CBOR encoding of the content of the block. Details of this representation are included in the specification defining the block type.
各ブロック内のブロック型固有のデータ（一次ブロック以外）は、ブロックの内容の適用可能なCBOR符号化とする。この表現の詳細は、ブロックタイプの定義仕様に含まれています。
This section describes the primary block in detail and non-primary blocks in general. Rules for processing these blocks appear in Section 5.
このセクションでは、プライマリブロックについて詳しく説明します。これらのブロックを処理するための規則はセクション5に表示されます。
Note that supplementary DTN protocol specifications (including, but not restricted to, Bundle Protocol Security [BPSEC]) may require that BP implementations conforming to those protocols construct and process additional blocks.
補足DTNプロトコル仕様（バンドルプロトコルセキュリティ[BPSEC]を含むが制限されていない）は、それらのプロトコルに適合するBP実装が追加のブロックを構成および処理することを必要とし得ることに留意されたい。
The primary bundle block contains the basic information needed to forward bundles to their destinations.
プライマリバンドルブロックには、バンドルを宛先に転送するのに必要な基本情報が含まれています。
Each primary block SHALL be represented as a CBOR array; the number of elements in the array SHALL be 8 (if the bundle is not a fragment and the block has no CRC), 9 (if the block has a CRC and the bundle is not a fragment), 10 (if the bundle is a fragment and the block has no CRC), or 11 (if the bundle is a fragment and the block has a CRC).
各プライマリブロックはCBORアレイとして表されます。配列内の要素数は8（バンドルがフラグメントではなくCRCがない場合）、9（ブロックがCRCを持ち、バンドルが破損していない場合）、10（バンドルがAの場合フラグメントとブロックにはCRCがありません.11（バンドルがフラグメントで、ブロックがCRCがある場合）です。
The primary block of each bundle SHALL be immutable. The CBOR-encoded values of all fields in the primary block MUST remain unchanged from the time the block is created to the time it is delivered.
各束の一次ブロックは不変でなければならない。プライマリブロック内のすべてのフィールドのCBORエンコードされた値は、ブロックが配信されるまでにブロックが作成された時点から変更されていなければなりません。
The fields of the primary bundle block SHALL be as follows, listed in the order in which they MUST appear:
プライマリバンドルブロックのフィールドは、次のようになります。
Version: An unsigned integer value indicating the version of the Bundle Protocol that constructed this block. The present document describes BPv7. This version number SHALL be represented as a CBOR unsigned integer item.
バージョン：このブロックを構築したバンドルプロトコルのバージョンを示す符号なし整数値。本文書はBPV7について説明している。このバージョン番号は、CBOBOR符号なし整数項目として表されます。
Bundle Processing Control Flags: The bundle processing control flags are discussed in Section 4.2.3.
バンドル処理制御フラグ：バンドル処理制御フラグはセクション4.2.3で説明されています。
CRC Type: CRC type codes are discussed in Section 4.2.1. The CRC type code for the primary block MAY be zero if the bundle contains a BPSec Block Integrity Block [BPSEC] whose target is the primary block; otherwise, the CRC type code for the primary block MUST be non-zero.
CRCタイプ：CRCタイプコードについては4.2.1項で説明します。バンドルにBPSEC Block Integrity Block [BPSEC]が1次ブロックであるBPSEC Block Integrityブロック[BPSEC]が含まれている場合、プライマリブロックのCRCタイプコードはゼロになることがあります。それ以外の場合、プライマリブロックのCRCタイプコードはゼロ以外でなければなりません。
Destination EID: The Destination EID field identifies the bundle endpoint that is the bundle's destination, i.e., the endpoint that contains the node(s) at which the bundle is to be delivered.
宛先EID：宛先EIDフィールドは、バンドルの宛先、すなわちバンドルが配信されるノードを含むエンドポイントであるバンドルエンドポイントを識別します。
Source node ID: The Source node ID field identifies the bundle node at which the bundle was initially transmitted, except that source node ID may be the null endpoint ID in the event that the bundle's source chooses to remain anonymous.
ソースノードID：ソースノードIDフィールドは、バンドルのソースが匿名のままであることを選択した場合に、バンドルが最初に送信されたバンドルノードを識別します。
Report-to EID: The Report-to EID field identifies the bundle endpoint to which status reports pertaining to the forwarding and delivery of this bundle are to be transmitted.
Report-to EID：Report-to EIDフィールドは、このバンドルの転送と配信に関するステータスレポートが送信されるバンドルエンドポイントを識別します。
Creation Timestamp: The creation timestamp comprises two unsigned integers that, together with the source node ID and (if the bundle is a fragment) the fragment offset and payload length, serve to identify the bundle. See Section 4.2.7 for the definition of this field.
作成タイムスタンプ：作成タイムスタンプは、ソースノードIDと（バンドルがフラグメントの場合）フラグメントオフセットとペイロード長とともに、バンドルを識別するのに役立つ2つの符号なし整数を含みます。このフィールドの定義については4.2.7項を参照してください。
Lifetime: The Lifetime field is an unsigned integer that indicates the time at which the bundle's payload will no longer be useful, encoded as a number of milliseconds past the creation time. (For high-rate deployments with very brief disruptions, fine-grained expression of bundle lifetime may be useful.) When a bundle's age exceeds its lifetime, bundle nodes need no longer retain or forward the bundle; the bundle SHOULD be deleted from the network.
LifeTime：LifeTimeフィールドは、バンドルのペイロードが有用でなくなり、作成時間を過ぎてミリ秒の数としてエンコードされた時間を示す符号なし整数です。（非常に短い混乱を伴う高速展開のために、バンドル寿命の微細な表現は有用であるかもしれません。）バンドルの年齢がその寿命を超えると、バンドルノードはバンドルを保持または転送する必要がなくなります。バンドルはネットワークから削除する必要があります。
If the asserted lifetime for a received bundle is so lengthy that retention of the bundle until its expiration time might degrade operation of the node at which the bundle is received, or if the BPA of that node determines that the bundle must be deleted in order to prevent network performance degradation (e.g., the bundle appears to be part of a denial-of-service attack), then that BPA MAY impose a temporary overriding lifetime of shorter duration; such an overriding lifetime SHALL NOT replace the lifetime asserted in the bundle but SHALL serve as the bundle's effective lifetime while the bundle resides at that node. Procedures for imposing lifetime overrides are beyond the scope of this specification.
受信されたバンドルのアサートされた有効期間が、その有効期限が受信されるまでバンドルの保持が非常に長い場合、またはそのノードのBPAがバンドルが順に削除されなければならないと判断した場合ネットワーク性能の低下を防ぐ（例えば、バンドルはサービス拒否攻撃の一部であるように見えます）、そのBPAは短い期間の一時的なオーバーライド寿命を課すことがあります。このようなオーバーライドの寿命は、バンドルにアサートされた寿命を置き換えるものではなく、バンドルがそのノードにある間にバンドルの有効な寿命として機能します。寿命のオーバーライドを課すための手順は、この仕様の範囲を超えています。
For bundles originating at nodes that lack accurate clocks, it is recommended that bundle age be obtained from the Bundle Age extension block (see Section 4.4.2) rather than from the difference between current time and bundle creation time. Bundle lifetime SHALL be represented as a CBOR unsigned integer item.
正確なクロックを欠いているノードで発信されたバンドルの場合、現在の時刻とバンドル作成時刻の違いからではなく、バンドルエグジック拡張ブロック（セクション4.4.2を参照）からバンドルエイジを取得することをお勧めします。バンドルの寿命は、CBOBOR符号なし整数項目として表されます。
Fragment offset: If and only if the bundle processing control flags of this primary block indicate that the bundle is a fragment, fragment offset SHALL be present in the primary block. Fragment offset SHALL be represented as a CBOR unsigned integer indicating the offset from the start of the original ADU at which the bytes comprising the payload of this bundle were located.
フラグメントオフセット：このプライマリブロックのバンドル処理制御フラグがバンドルがフラグメントであることを示している場合に限り、フラグメントオフセットはプライマリブロックに存在します。フラグメントオフセットは、このバンドルのペイロードを含むバイトが配置されているオリジナルADUの開始からのオフセットを示すCBOR符号なし整数として表されます。
Total Application Data Unit Length: If and only if the bundle processing control flags of this primary block indicate that the bundle is a fragment, total application data unit length SHALL be present in the primary block. Total application data unit length SHALL be represented as a CBOR unsigned integer indicating the total length of the original ADU of which this bundle's payload is a part.
総アプリケーションデータ単位長さ：このプライマリブロックのバンドル処理制御フラグがバンドルがフラグメントであることを示している場合に限り、合計アプリケーションデータ単位長がプライマリブロックに存在するものとします。総アプリケーションデータ単位長さは、このバンドルのペイロードが部分的なオリジナルADUの全長を示すCBOR符号なし整数として表されます。
CRC: A CRC SHALL be present in the primary block unless the bundle includes a BPSec Block Integrity Block [BPSEC] whose target is the primary block, in which case a CRC MAY be present in the primary block. The length and nature of the CRC SHALL be as indicated by the CRC type. The CRC SHALL be computed over the concatenation of all bytes (including CBOR "break" characters) of the primary block including the CRC field itself, which, for this purpose, SHALL be temporarily populated with all bytes set to zero.
CRC：バンドルがプライマリブロックであるBPSECブロック整合性ブロック[BPSEC]を含む限り、CRCはプライマリブロックに存在しなければならない。その場合、CRCがプライマリブロック内に存在する可能性がある。CRCの長さと性質は、CRCタイプによって示される通りでなければならない。CRCは、CRCフィールド自体を含むプライマリブロックのすべてのバイト（CBOR "ブレーク"文字を含む）の連結で計算されます。この目的のために、この目的のために一時的にゼロに設定されているすべてのバイトが一時的に入力されます。
Every block other than the primary block (all such blocks are termed "canonical" blocks) SHALL be represented as a CBOR array; the number of elements in the array SHALL be 5 (if CRC type is zero) or 6 (otherwise).
プライマリブロック以外のすべてのブロック（そのようなブロックはすべて「正準」ブロックと呼ばれます）をCBOR配列として表します。配列内の要素数は5（CRCタイプがゼロの場合）または6（そうでない場合）になります。
The fields of every canonical block SHALL be as follows, listed in the order in which they MUST appear:
すべての標準ブロックのフィールドは、それらが表示されなければならない順序でリストされている以下の通りでなければならない。
Block type code: An unsigned integer. Bundle block type code 1 indicates that the block is a Bundle Payload Block. Other block type codes are described in Section 9.1. Block type codes 192 through 255 are not reserved and are available for private and/or experimental use. All other block type code values are reserved for future use.
ブロックタイプコード：符号なし整数。バンドルブロックタイプコード1ブロックがバンドルペイロードブロックであることを示します。その他のブロックタイプコードは9.1節で説明されています。ブロックタイプコード192から255は予約されておらず、プライベートおよび/または実験的な使用に利用可能です。他のすべてのブロックタイプコード値は将来の使用のために予約されています。
Block number: An unsigned integer as discussed in Section 4.1. The block number SHALL be represented as a CBOR unsigned integer.
ブロック番号：セクション4.1で説明した符号なし整数。ブロック番号は、CBOR符号なし整数として表されます。
Block processing control flags: As discussed in Section 4.2.4.
ブロック処理制御フラグ：セクション4.2.4で説明したように。
CRC type: As discussed in Section 4.2.1.
CRCタイプ：セクション4.2.1で説明したように。
Block-type-specific data: Represented as a single definite-length CBOR byte string, i.e., a CBOR byte string that is not of indefinite length. For each type of block, the block-type-specific data byte string is the serialization, in a block-type-specific manner, of the data conveyed by that type of block; definitions of blocks are required to define the manner in which block-type-specific data are serialized within the block-type-specific data field. For the Bundle Payload Block in particular (block type 1), the block-type-specific data field, termed the "payload", SHALL be an ADU, or some contiguous extent thereof, represented as a definite-length CBOR byte string.
ブロック型固有のデータ：単一の明確なCBOBOBOBORバイト文字列、すなわち、無期限の長さのものではないCBORバイト文字列として表されます。ブロックの種類の種類ごとに、ブロック型固有のデータバイト文字列は、ブロックタイプ固有の方法で、そのタイプのブロックによって伝達されたデータのシリアル化です。ブロックの定義は、ブロックタイプ固有のデータがブロック型固有のデータフィールド内にシリアル化される方法を定義するために必要です。特にバンドルペイロードブロックの場合（ブロックタイプ1）、「ペイロード」と呼ばれるブロックタイプ固有のデータフィールドは、明確な長さのCBOBOBORバイト文字列として表されるADU、またはその隣接する範囲となります。
If and only if the value of the CRC type field of this block is non-zero: A CRC. If present, the length and nature of the CRC SHALL be as indicated by the CRC type and the CRC SHALL be computed over the concatenation of all bytes of the block (including CBOR "break" characters) including the CRC field itself, which, for this purpose, SHALL be temporarily populated with all bytes set to zero.
このブロックのCRCタイプフィールドの値がゼロ以外の場合に限り、CRCの場合に限り。存在する場合、CRCの長さと性質はCRCタイプによって示される通りでなければならず、CRCはCRCフィールド自体を含むブロックのすべてのバイト（CBOR "ブレーク"文字を含む）の連結で計算されなければならない。この目的は、ゼロに設定されているすべてのバイトを一時的に入力するものとします。
"Extension blocks" are all blocks other than the primary and payload blocks. Three types of extension blocks are defined below. All implementations of the Bundle Protocol specification (the present document) MUST include procedures for recognizing, parsing, and acting on, but not necessarily producing, these types of extension blocks.
「拡張ブロック」は、プライマリブロックとペイロードブロック以外のすべてのブロックです。以下に3種類の拡張ブロックを定義します。バンドルプロトコル仕様のすべての実装（本文書）は、これらのタイプの拡張ブロックを必ずしも生成、解析、および実行するための手順を含める必要があります。
The specifications for additional types of extension blocks must indicate whether or not BP implementations conforming to those specifications must recognize, parse, act on, and/or produce blocks of those types. As not all nodes will necessarily instantiate BP implementations that conform to those additional specifications, it is possible for a node to receive a bundle that includes extension blocks that the node cannot process. The values of the block processing control flags indicate the action to be taken by the BPA when this is the case.
追加の種類の拡張ブロックの仕様は、これらの仕様に適合するBP実装が、それらのタイプのブロックを認識、解析、行動、および/または作成する必要があるかどうかを示している必要があります。すべてのノードがそれらの追加の仕様に準拠したBP実装を必ずインスタンス化するわけではないため、ノードが処理できない拡張ブロックを含むバンドルを受信することが可能です。ブロック処理制御フラグの値は、この場合、BPAによって取られる行動を示す。
No mandated procedure in this specification is unconditionally dependent on the absence or presence of any extension block. Therefore, any BPA MAY insert or remove any extension block in any bundle, subject to all mandates in the Bundle Protocol specification and all extension block specifications to which the node's BP implementation conforms. Note that removal of an extension block will probably disable one or more elements of bundle processing that were intended by the BPA that inserted that block. In particular, note that removal of an extension block that is one of the targets of a BPSec security block may render the bundle unverifiable.
この仕様では必須の手順は無条件に任意の拡張ブロックの不在または存在に依存しています。したがって、どのBPAでも、バンドルプロトコル仕様のすべての義務と、ノードのBP実装が準拠しているすべての拡張ブロック仕様のすべての任務の対象となります。拡張ブロックの削除は、おそらくそのブロックを挿入したBPAによって意図されたバンドル処理の1つまたは複数の要素を無効にすることに注意してください。特に、BPSECセキュリティブロックのターゲットの1つである拡張ブロックを削除すると、バンドルがバンドルを確実にレンダリングできます。
The following extension blocks are defined in the current document.
以下の拡張ブロックは、現在のドキュメントで定義されています。
The Previous Node Block, block type 6, identifies the node that forwarded this bundle to the local node (i.e., to the node at which the bundle currently resides); its block-type-specific data is the node ID of that forwarder node. That node ID SHALL conform to Section 4.2.5.2. If the local node is the source of the bundle, then the bundle MUST NOT contain any Previous Node Block. Otherwise, the bundle SHOULD contain one (1) occurrence of this type of block and MUST NOT contain more than one.
前のノードブロックブロックタイプ6は、このバンドルをローカルノードに転送したノード（すなわち、バンドルが現在存在するノードに識別する）を識別する。そのブロック型固有のデータは、そのフォワーダノードのノードIDです。そのノードIDはセクション4.2.5.2に準拠しなければならない。ローカルノードがバンドルのソースである場合、バンドルは以前のノードブロックを含めてはいけません。それ以外の場合、バンドルにこのタイプのブロックの1つの発生を含める必要があり、複数のものを含めてはいけません。
The Bundle Age Block, block type 7, contains the number of milliseconds that have elapsed between the time the bundle was created and the time at which it was most recently forwarded. It is intended for use by nodes lacking access to an accurate clock, to aid in determining the time at which a bundle's lifetime expires. The block-type-specific data of this block is an unsigned integer containing the age of the bundle in milliseconds, which SHALL be represented as a CBOR unsigned integer item. (The age of the bundle is the sum of all known intervals of the bundle's residence at forwarding nodes, up to the time at which the bundle was most recently forwarded, plus the summation of signal propagation time over all episodes of transmission between forwarding nodes. Determination of these values is an implementation matter.) If the bundle's creation time is zero, then the bundle MUST contain exactly one (1) occurrence of this type of block; otherwise, the bundle MAY contain at most one (1) occurrence of this type of block. A bundle MUST NOT contain multiple occurrences of the Bundle Age Block, as this could result in processing anomalies.
Bundle Ageブロック、ブロックタイプ7は、バンドルが作成された時間と最後に転送された時刻の間に経過したミリ秒数を含みます。バンドルの寿命が期限切れになる時間を決定するのを助けるために、正確なクロックへのアクセスを欠くノードによる使用を意図しています。このブロックのブロックタイプ固有のデータは、束の時代をミリ秒単位で含む符号なし整数であり、これはCBOR符号なし整数項目として表されます。 （バンドルの時代は、転送ノードでのバンドルの住居のすべての既知の間隔の合計で、バンドルが最後に転送された時間まで、および転送ノード間の伝送のすべてのエピソードにわたる信号伝播時間の合計です。これらの値の決定は実装問題です。）バンドルの作成時間がゼロの場合、バンドルはこのタイプのブロックの正確に1つの発生を含める必要があります。さもなければ、バンドルはこのタイプのブロックの最大の（1）の出現を含み得る。バンドルにはバンドルエイジブロックの複数の出現が含まれてはいけません。これにより、異常が処理される可能性があります。
The Hop Count Block, block type 10, contains two unsigned integers: hop limit and hop count. A "hop" is here defined as an occasion on which a bundle was forwarded from one node to another node. The hop limit MUST be in the range 1 through 255. The hop limit value SHOULD NOT be changed at any time after creation of the Hop Count Block; the hop count value SHOULD initially be zero and SHOULD be increased by 1 on each hop.
ホップカウントブロック、ブロックタイプ10には、ホップリミットとホップカウント2つの符号なし整数が含まれています。「ホップ」は、ここではバンドルがあるノードから別のノードに転送された機会として定義されています。ホップ制限は1から255の範囲内でなければなりません。ホップ数の値は、ホップカウントブロックの作成後はいつでも変更しないでください。ホップカウント値は最初はゼロになり、各ホップで1だけ増加する必要があります。
The Hop Count Block is mainly intended as a safety mechanism, a means of identifying bundles for removal from the network that can never be delivered due to a persistent forwarding error. The hop count is particularly valuable as a defense against routing anomalies that might cause a bundle to be forwarded in a cyclical "ping-pong" fashion between two nodes. When a bundle's hop count exceeds its hop limit, the bundle SHOULD be deleted for the reason "Hop limit exceeded", following the Bundle Deletion procedure defined in Section 5.10.
ホップカウントブロックは、主に安全機構として意図されており、永続的な転送エラーのために絶対に配信することができるネットワークからの削除のためのバンドルを識別する手段。ホップ数は、2つのノード間の周期的な「Ping-Pong」ファッションでバンドルを転送する可能性があるルーティング異常に対する防御として特に貴重です。バンドルのホップ数がホップの制限を超えると、セクション5.10で定義されているバンドル削除手順に従って、「ホップ制限を超えた」という理由でバンドルを削除する必要があります。
Procedures for determining the appropriate hop limit for a bundle are beyond the scope of this specification.
バンドルの適切なホップ限界を決定するための手順は、この仕様の範囲を超えています。
The block-type-specific data in a Hop Count Block SHALL be represented as a CBOR array comprising two items. The first item of this array SHALL be the bundle's hop limit, represented as a CBOR unsigned integer. The second item of this array SHALL be the bundle's hop count, represented as a CBOR unsigned integer. A bundle MAY contain one occurrence of this type of block but MUST NOT contain more than one.
ホップカウントブロック内のブロック型固有のデータは、2つの項目を含むCBORアレイとして表されなければならない。この配列の最初の項目は、CBOR符号なし整数として表されるバンドルのホップリミットとする。この配列の2番目の項目は、CBOR符号なし整数として表されるバンドルのホップ数とする。バンドルには、このタイプのブロックの1つの発生を含めることができますが、複数のものを含めてはいけません。
The bundle-processing procedures mandated in this section and in Section 6 govern the operation of the BPA and the application agent administrative element of each bundle node. They are neither exhaustive nor exclusive. Supplementary DTN protocol specifications (including, but not restricted to, Bundle Protocol Security [BPSEC]) may augment, override, or supersede the mandates of this document.
このセクションおよびセクション6に義務付けられているバンドル処理手順は、各バンドルノードのBPAおよびアプリケーションエージェント管理要素の動作を管理します。それらは網羅的でも排他的でもない。補足DTNプロトコル仕様（バンドルプロトコルセキュリティ[BPSEC]を含むが、バンドルプロトコルセキュリティ[BPSEC]を含む）は、このドキュメントの義務を拡張、オーバーライド、または提供することができます。
All transmission of bundles is in response to bundle transmission requests presented by nodes' application agents. When required to "generate" an administrative record (such as a bundle status report), the BPA itself is responsible for causing a new bundle to be transmitted, conveying that record. In concept, the BPA 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. In practice, the manner in which administrative record generation is accomplished is an implementation matter, provided the constraints noted in Section 6 are observed.
バンドルの送信はすべて、ノードのアプリケーションエージェントによって提示されたバンドル送信要求に応答しています。管理レコード（バンドルステータスレポートなど）を「生成」することが必要な場合、BPA自体は新しいバンドルを送信し、そのレコードを伝送する責任があります。コンセプトでは、BPAは、ノードのアプリケーションエージェントの管理要素にレコードを構築し、その送信をセクション6に詳述するように指示することで、この責任を排出します。実際には、管理記録生成が達成される方法は実装問題です。セクション6に記載されている制約が観察されます。
Status reports are relatively small bundles. Moreover, even when the generation of status reports is enabled, the decision on whether or not to generate a requested status report is left to the discretion of the BPA. Nonetheless, note that requesting status reports for any single bundle might easily result in the generation of (1 + (2 *(N-1))) status report bundles, where N is the number of nodes on the path from the bundle's source to its destination, inclusive. That is, the requesting of status reports for large numbers of bundles could result in an unacceptable increase in the bundle traffic in the network. For this reason, the generation of status reports MUST be disabled by default and enabled only when the risk of excessive network traffic is deemed acceptable. Mechanisms that could assist in assessing and mitigating this risk, such as pre-placed agreements authorizing the generation of status reports under specified circumstances, are beyond the scope of this specification.
ステータスレポートは比較的小さなバンドルです。また、ステータスレポートの生成が有効になっていても、要求されたステータスレポートを生成するかどうかの決定はBPAの裁量に残されています。それにもかかわらず、単一のバンドルのステータスレポートを要求すると、（1（2 *（n-1））ステータスレポートバンドルの生成が容易になる可能性があるため、NはバンドルのソースからITSへのパス上のノード数です。目的地、包括的な。すなわち、多数のバンドルに対するステータスレポートの要求は、ネットワーク内のバンドルトラフィックの許容できない増加をもたらし得る。このため、ステータスレポートの生成はデフォルトで無効にされ、過度のネットワークトラフィックのリスクが許容できると見なされる場合にのみ有効にする必要があります。指定された状況下でのステータスレポートの生成を承認する事前に配置された契約など、このリスクを評価し軽減するのに役立つメカニズムは、この仕様の範囲を超えています。
Notes on administrative record terminology:
管理記録用語に関する注意事項
* A "bundle reception status report" is a bundle status report with the "Reporting node received bundle" flag set to 1.
* 「バンドル受信ステータスレポート」は、「報告ノード受信バンドル」フラグが1に設定されているバンドルステータスレポートです。
* A "bundle forwarding status report" is a bundle status report with the "Reporting node forwarded the bundle" flag set to 1.
* 「バンドル転送ステータスレポート」は、「レポーティングノード転送バンドル」フラグを1に設定したバンドルステータスレポートです。
* A "bundle delivery status report" is a bundle status report with the "Reporting node delivered the bundle" flag set to 1.
* 「バンドル配信ステータスレポート」は、「レポーティングノードがバンドルを配信する」フラグを1に設定したバンドルステータスレポートです。
* A "bundle deletion status report" is a bundle status report with the "Reporting node deleted the bundle" flag set to 1.
* 「バンドル削除ステータスレポート」は、「レポートノードがバンドルを削除したバンドル」フラグを1に設定したバンドルステータスレポートです。
The steps in processing a bundle transmission request are as follows:
バンドル送信要求を処理するステップは次のとおりです。
Step 1: Transmission of the bundle is initiated. An outbound bundle MUST be created per the parameters of the bundle transmission request, with the retention constraint "Dispatch pending". The source node ID of the bundle MUST be either (a) the null endpoint ID, indicating that the source of the bundle is anonymous or (b) the EID of a singleton endpoint whose only member is the node of which the BPA is a component.
ステップ1：バンドルの送信が開始されます。バンドル送信要求のパラメータごとにアウトバウンドバンドルを作成する必要があります。保持制約 "ディスパッチ保留"。バンドルのソースノードIDはNULLエンドポイントIDのいずれかでなければなりません.NULLエンドポイントIDは、バンドルのソースが匿名であることを示します。（b）BPAのみがコンポーネントのノードであるシングルトンエンドポイントのEID。
Step 2: Processing proceeds from Step 1 of Section 5.4.
ステップ2：処理は5.4セクション5のステップ1から進む。
(Note that this procedure is initiated only following completion of Step 4 of Section 5.6.)
（この手順は、セクション5.6のステップ4の完了後にのみ開始されます。）
The steps in dispatching a bundle are as follows:
バンドルをディスパッチする手順は次のとおりです。
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 and, for the purposes of all subsequent processing of this bundle at this node, the node's membership in the bundle's destination endpoint SHALL be disavowed; specifically, even though the node is a member of the bundle's destination endpoint, the node SHALL NOT undertake to forward the bundle to itself in the course of performing the procedure described in Section 5.4.
ステップ1：バンドルの宛先エンドポイントがノードがメンバーのエンドポイントである場合は、セクション5.7で定義されているバンドル配信手順に従う必要があります。このノードでのこのバンドルのすべての処理の目的のために、ノードのメンバーシップバンドルの宛先のエンドポイントが繰り越されます。具体的には、ノードがバンドルの宛先エンドポイントのメンバーであっても、セクション5.4で説明されている手順を実行する過程で、ノードはバンドルをそれ自体に転送することを行わないものとします。
Step 2: Processing proceeds from Step 1 of Section 5.4.
ステップ2：処理は5.4セクション5のステップ1から進む。
The steps in forwarding a bundle are as follows:
バンドルを転送する手順は次のとおりです。
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 BPA MUST determine whether or not forwarding is contraindicated (that is, rendered inadvisable) for any of the reasons listed in the IANA "Bundle Status Report Reason Codes" registry (see Section 9.5), whose initial contents are listed in Table 1. In particular:
ステップ2：BPAは、IANAの「バンドルステータスレポート理由コード」レジストリ（セクション9.5を参照）のいずれかについて、転送が禁忌（つまり、INADVITABLE）であるかどうかを判断しなければならない。特に：
* The BPA MAY choose to either forward the bundle directly to its destination node(s) (if possible) or forward the bundle to some other node(s) for further forwarding. The manner in which this decision is made may depend on the scheme name in the destination endpoint ID and/or on other state but in any case is beyond the scope of this document; one possible mechanism is described in [SABR]. If the BPA elects to forward the bundle to some other node(s) for further forwarding but finds it impossible to select any node(s) to forward the bundle to, then forwarding is contraindicated.
* BPAは、バンドルをその宛先ノードに直接転送するか（可能であれば）またはバンドルを他のノードに転送するか、さらに転送することを選択できます。この決定が行われる方法は、宛先エンドポイントIDおよび/または他の状態での方式名に依存している可能性がありますが、いずれにしても、この文書の範囲を超えています。1つの可能なメカニズムは[SABR]に記載されている。BPAがさらに転送するためにバンドルを他のノードに転送することを選択した場合、バンドルを転送するための任意のノードを選択することは不可能であると判断された場合、転送は禁忌です。
* Provided the BPA succeeded in selecting the node or nodes to forward the bundle to, the BPA MUST subsequently select the CLA(s) whose services will enable the node to send the bundle to those nodes. The manner in which specific appropriate CLAs are selected is beyond the scope of this document; the TCP CLA [TCPCL] MUST be implemented when some or all of the bundles forwarded by the BPA must be forwarded via the Internet but may not be appropriate for the forwarding of any particular bundle. If the agent finds it impossible to select any appropriate CLA(s) to use in forwarding this bundle, then forwarding is contraindicated.
* BPAがバンドルを転送するためにノードまたはノードの選択に成功した場合、その後、BPAはその後、ノードがバンドルをそれらのノードに送信できるようにするCLAを選択する必要があります。特定の適切なCLAが選択されている方法はこの文書の範囲を超えています。TCP CLA [TCPCL]は、BPAによって転送されたバンドルの一部または全部がインターネットを介して転送されなければならないが、特定のバンドルを転送するのに適していない可能性がある場合に実装する必要があります。このバンドルの転送に使用する適切なCLAを選択することは不可能な場合は、転送は禁忌です。
Step 3: If forwarding of the bundle is determined to be contraindicated for any of the reasons listed in the IANA "Bundle Status Report Reason Codes" registry (see Section 9.5), then the Forwarding Contraindicated procedure defined in Section 5.4.1 MUST be followed; the remaining steps of this Bundle Forwarding procedure are skipped at this time.
ステップ3：バンドルの転送がIANAの「バンドルステータスレポート理由コード」レジストリ（セクション9.5を参照）のいずれにも禁忌であると判断された場合は、セクション5.4.1で定義されている転送禁止手順に従う必要があります。;この束転送手順の残りの手順は現時点でスキップされています。
Step 4: For each node selected for forwarding, the BPA MUST invoke the services of the selected CLA(s) in order to effect the sending of the bundle to that node. Determining the time at which the BPA invokes CLA services is a BPA implementation matter. Determining the time at which each CLA subsequently responds to this service invocation by sending the bundle is a CLA implementation matter. Note that:
ステップ4：転送用に選択された各ノードに対して、BPAはそのノードへのバンドルの送信を実行するために選択されたCLAのサービスを呼び出す必要があります。BPAがCLAサービスを呼び出す時間を決定することはBPA実装問題です。バンドルを送信して、各CLAがこのサービス呼び出しに応答する時間を決定することはCLA実装の問題です。ご了承ください：
* If the bundle has a Previous Node Block, as defined in Section 4.4.1, then that block MUST be removed from the bundle before the bundle is forwarded.
* セクション4.4.1で定義されているように、バンドルに以前のノードブロックがある場合は、バンドルが転送される前にバンドルから削除する必要があります。
* If the BPA is configured to attach Previous Node Blocks to forwarded bundles, then a Previous Node Block containing the node ID of the forwarding node MUST be inserted into the bundle before the bundle is forwarded.
* BPAが前のノードブロックを転送バンドルに接続するように構成されている場合、バンドルが転送される前に転送ノードのノードIDを含む前のノードブロックをバンドルに挿入する必要があります。
* If the bundle has a Bundle Age Block, as defined in Section 4.4.2, then at the last possible moment before the CLA initiates conveyance of the bundle via the CL protocol the bundle age value MUST be increased by the difference between the current time and the time at which the bundle was received (or, if the local node is the source of the bundle, created).
* セクション4.4.2で定義されているようにバンドルがバンドルエイジブロックを持っている場合、CLAがCLプロトコルを介してバンドルの搬送を開始する前の最後の瞬間に、バンドルの年齢の値は現在の時刻との差によって増加されなければなりません。バンドルが受信された時刻（またはローカルノードが束のソースの場合は作成された場合）。
Step 5: When all selected CLAs have informed the BPA that they have concluded their data-sending procedures with regard to this bundle, processing may depend on the results of those procedures.
ステップ5：すべての選択されたCLAが、このバンドルに関してデータ送信手順を結論づけたことをBPAに知らせたとき、処理はそれらの手順の結果に依存する可能性があります。
If completion of the data-sending procedures by all selected CLAs has not resulted in successful forwarding of the bundle (an implementation-specific determination that is beyond the scope of this specification), then the BPA MAY choose (in an implementation-specific manner, again beyond the scope of this specification) to initiate another attempt to forward the bundle. In that event, processing proceeds from Step 4. The minimum number of times a given node will initiate another forwarding attempt for any single bundle in this event (a number that may be zero) is a node configuration parameter that must be exposed to other nodes in the network to the extent that this is required by the operating environment.
すべての選択されたCLAによるデータ送信手順が完了した場合、バンドルの転送が成功しなかった場合（この仕様の範囲を超えた実装固有の決定）、BPAは（実装固有の方法で）選択することができます。この仕様の範囲を超えて、バンドルを転送するための別の試みを開始する。そのイベントでは、ステップ4からの処理が進みます。このイベントでは、特定のノードが単一のバンドルに対して別の転送試行を開始します（ゼロになる可能性がある番号）、他のノードに公開する必要があるノード構成パラメータです。これがオペレーティング環境によって必要とされる範囲でネットワークで。
If completion of the data-sending procedures by all selected CLAs *HAS* resulted in successful forwarding of the bundle, or if it has not but the BPA does not choose to initiate another attempt to forward the bundle, then:
選択されたすべてのCLAS *でデータ送信手順が完了すると、バンドルの転送が成功した場合、またはBPAがバンドルを転送するための別の試みを開始することを選択しません。
* If the "request reporting of bundle forwarding" flag in the bundle's status report request field is set to 1 and status reporting is enabled, then a bundle forwarding status report SHOULD be generated, destined for the bundle's report-to endpoint ID. The reason code on this bundle forwarding status report MUST be "no additional information".
* 「バンドルのステータスレポート要求」フィールドに「バンドル転送の要求の要求」フラグが1に設定されているとステータスレポートが有効になっている場合は、バンドルのレポートからエンドポイントIDを宛先宛てのバンドル転送ステータスレポートを生成する必要があります。このバンドル転送ステータスレポートの理由コードは「追加情報なし」でなければなりません。
* If any applicable Bundle Protocol extensions mandate generation of status reports upon conclusion of convergence-layer data-sending procedures, all such status reports SHOULD be generated with extension-mandated reason codes.
* 該当するバンドルプロトコル拡張が、収束層データ送信手順の締結時にステータスレポートの生成を義務付けている場合、そのようなステータスレポートはすべて拡張命令の理由コードで生成されるべきです。
* The bundle's "Forward pending" retention constraint MUST be removed.
* バンドルの「前方保留中」の保持制約を削除する必要があります。
The steps in responding to contraindication of forwarding are as follows:
転送の禁忌に応答するステップは次のとおりです。
Step 1: The BPA MUST determine whether or not to declare failure in forwarding the bundle. Note: This decision is likely to be influenced by the reason for which forwarding is contraindicated.
ステップ1：BPAは、バンドルを転送する際に失敗を宣言するかどうかを判断する必要があります。注：この決定は、転送が禁忌の理由によって影響される可能性があります。
Step 2: If forwarding failure is declared, then the Forwarding Failed procedure defined in Section 5.4.2 MUST be followed.
ステップ2：転送失敗が宣言されている場合は、セクション5.4.2で定義されている転送失敗手順に従う必要があります。
Otherwise, when -- at some future time -- the forwarding of this bundle ceases to be contraindicated, processing proceeds from Step 4 of Section 5.4.
そうでなければ、 - 何らかの将来の時間に - このバンドルの転送は禁忌であることを止めるために、処理はセクション5.4のステップ4から進む。
The steps in responding to a declaration of forwarding failure are as follows:
転送障害の宣言に対応する手順は次のとおりです。
Step 1: The BPA MAY forward the bundle back to the node that sent it, as identified by the Previous Node Block, if present. This forwarding, if performed, SHALL be accomplished by performing Step 4 and Step 5 of Section 5.4 where the sole node selected for forwarding SHALL be the node that sent the bundle.
ステップ1：BPAは、以前のノードブロックによって識別された場合に、それを送信したノードにバンドルを転送することができます。この転送は、実行されれば、転送のために選択されたソールノードがバンドルを送信したノードとするセクション5.4のステップ4およびステップ5を実行することによって達成されるものとする。
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.10 MUST be followed, citing the reason for which forwarding was determined to be contraindicated.
ステップ2：バンドルの宛先エンドポイントがノードがメンバーのエンドポイントである場合は、バンドルの「前方保留中」の保持制約を削除する必要があります。それ以外の場合は、バンドルを削除する必要があります。セクション5.10で定義されているバンドル削除手順に従う必要があります。転送が禁忌であると判断された理由を引用します。
A bundle expires when the bundle's age exceeds its lifetime as specified in the primary bundle block or as overridden by the BPA. Bundle age MAY be determined by subtracting the bundle's creation timestamp time from the current time if (a) that timestamp time is not zero and (b) the local node's clock is known to be accurate; otherwise, bundle age MUST be obtained from the Bundle Age extension block. Bundle expiration MAY occur at any point in the processing of a bundle. When a bundle expires, the BPA MUST delete the bundle for the reason "Lifetime expired" (when the expired lifetime is the lifetime as specified in the primary block) or "Traffic pared" (when the expired lifetime is a lifetime override as imposed by the BPA): the Bundle Deletion procedure defined in Section 5.10 MUST be followed.
バンドルの年齢が、プライマリバンドルブロックで指定されているとき、またはBPAによってオーバーライドされているように、バンドルの有効期限が切れます。（a）タイムスタンプ時間がゼロでない場合（a）、（b）ローカルノードのクロックが正確であることがわかっている場合、バンドルの年齢は、現在時刻からバンドルの作成タイムスタンプ時間を減算することによって決定されます。それ以外の場合は、バンドルAGE拡張ブロックからBUNDLE AGEを取得する必要があります。バンドルの有効期限は、バンドルの処理の任意の時点で発生する可能性があります。バンドルが期限切れになると、BPAは「有効期限切れ」（期限切れの有効期間が一次ブロックで指定されている寿命である場合）または「期限切れの有効期間」（期限切れの有効期間が課されるように一生の上書きである場合）のためにバンドルを削除する必要があります。BPA）：セクション5.10に定義されているバンドル削除手順に従う必要があります。
The steps in processing a bundle that has been received from another node are as follows:
別のノードから受信されたバンドルを処理するステップは次のとおりです。
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 and status reporting is enabled, 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に設定されている場合は、Status Reportingが有効になっている場合は、Reason Codeのバンドル受信ステータスレポート「追加情報なし」を作成してください。バンドルのレポートからエンドポイントID。
Step 3: CRCs SHOULD be computed for every block of the bundle that has an attached CRC. If any block of the bundle is malformed according to this specification (including syntactically invalid CBOR), or if any block has an attached CRC and the CRC computed for this block upon reception differs from that attached CRC, then the BPA MUST delete the bundle for the reason "Block unintelligible". The Bundle Deletion procedure defined in Section 5.10 MUST be followed, and all remaining steps of the Bundle Reception procedure MUST be skipped.
ステップ3：接続されたCRCを持つバンドルのすべてのブロックに対してCRCを計算する必要があります。この仕様（構文的に無効な炭素を含む）に従ってバンドルのブロックが不正行為されている場合、またはブロックが接続されていて、受信時にこのブロックで計算されたCRCが接続されたCRCとは異なる場合、BPAはバンドルを削除する必要があります。その理由「無感り」をブロックします。セクション5.10で定義されているバンドル削除手順に従う必要があり、バンドル受信手順の残りの手順はすべてスキップされている必要があります。
Step 4: For each block in the bundle that is an extension block that the BPA cannot process:
ステップ4：バンドル内の各ブロックに対して、BPAが処理できない拡張ブロックである。
* If the block processing control flags in that block indicate that a status report is requested in this event and if status reporting is enabled, then a bundle reception status report with reason code "Block unsupported" SHOULD be generated, destined for the bundle's report-to endpoint ID.
* そのブロック内のブロック処理制御フラグがこのイベントでステータスレポートが要求され、ステータスレポートが有効になっていることを示す場合、Status Reportingが有効になっている場合は、Bundleのレポートへの宛先である理由コード「ブロックサポートされていない」とのバンドル受信ステータスレポートを生成する必要があります。エンドポイントID。
* If the block processing control flags in that block indicate that the bundle must be deleted in this event, then the BPA MUST delete the bundle for the reason "Block unsupported"; the Bundle Deletion procedure defined in Section 5.10 MUST be followed, and all remaining steps of the Bundle Reception procedure MUST be skipped.
* そのブロック内のブロック処理制御フラグがこのイベントでバンドルを削除する必要があることを示す場合、BPAは「ブロックサポートされていない」という理由でバンドルを削除する必要があります。セクション5.10で定義されているバンドル削除手順に従う必要があり、バンドル受信手順の残りの手順はすべてスキップされている必要があります。
* If the block processing control 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 BPA MUST remove this block from the bundle.
* そのブロックのブロック処理制御フラグがDO *ではなく、このイベントでバンドルを削除する必要があることを示していますが、ブロックを破棄する必要があることを示します。その後、BPAはバンドルからこのブロックを削除する必要があります。
* If the block processing control flags in that block neither indicate that the bundle must be deleted nor indicate that the block must be discarded, then processing continues with the next extension block that the BPA cannot process, if any; otherwise, processing proceeds from Step 5.
* そのブロック内のブロック処理制御フラグがバンドルを削除したり、ブロックを破棄しなければならないことを示したり、処理も行われていないことを示したり、処理は処理できない次の拡張ブロックを継続します。そうでなければ、処理はステップ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 as follows:
このノードがメンバーであるエンドポイント宛てのバンドルを処理する手順は次のとおりです。
Step 1: If the received bundle is a fragment, the ADU Reassembly procedure described in Section 5.9 MUST be followed. If this procedure results in reassembly of the entire original ADU, processing of the fragmentary bundle whose payload has been replaced by the reassembled ADU (whether this bundle or a previously received fragment) proceeds from Step 2; otherwise, the retention constraint "Reassembly pending" MUST be added to the bundle, and all remaining steps of this procedure MUST be skipped.
ステップ1：受信したバンドルがフラグメントである場合、セクション5.9に記載されているADUの再構成手順に従う必要があります。この手順が元のADU全体の再組み立てをもたらす場合、そのペイロードが再組み立てされたADU（このバンドルまたは以前に受信したフラグメントか）によって置き換えられた断片バンドルの処理はステップ2から進む。それ以外の場合は、保存制約 "再構成保留"をバンドルに追加する必要があり、この手順の残りの手順はすべてスキップされている必要があります。
Step 2: Delivery depends on the state of the registration whose endpoint ID matches that of the destination of the bundle:
ステップ2：配信は、エンドポイントIDがバンドルの宛先と一致する登録の状態によって異なります。
* An additional implementation-specific delivery deferral procedure MAY optionally be associated with the registration.
* 追加の実装固有の配信延期手順は、任意に登録に関連付けられてもよい。
* If the registration is in the Active state, then the bundle MUST be delivered automatically as soon as it is the next bundle that is due for delivery according to the BPA's bundle delivery scheduling policy (an implementation matter).
* 登録がアクティブ状態にある場合は、BPAのバンドル配信スケジューリングポリシー（実装問題）に従って配信予定の次のバンドルであるとすぐにバンドルを自動的に配信する必要があります。
* If the registration is in the Passive state, or if delivery of the bundle fails for some implementation-specific reason, then the registration's delivery failure action MUST be taken. The delivery failure action MUST be one of the following:
* 登録がパッシブ状態にある場合、または一括の配信が実装固有の理由で失敗した場合は、登録の配信失敗アクションを取得する必要があります。配信失敗アクションは、次のいずれかになります。
- Defer delivery 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 the registration is in the Active state, and also perform any additional delivery deferral procedure associated with the registration, or
- この登録の対象となるバンドルの配信（a）このバンドルは、現在この登録の対象となっているすべてのバンドルの最近受信されている、（b）登録または登録のいずれかがアクティブ状態にあり、また実行されます。登録に関連した追加の配信延期手順、または
- Abandon delivery of the bundle subject to this registration (as defined in Section 3.1).
- この登録に従ってバンドルの配信を放棄します（セクション3.1で定義されているように）。
Step 3: As soon as the bundle has been delivered, if the "request reporting of bundle delivery" flag in the bundle's status report request field is set to 1 and bundle status reporting is enabled, 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.
ステップ3：バンドルが配信されるとすぐに、バンドルの[ステータスレポート要求のバンドル配信の要求報告 "フラグが1に設定され、バンドルステータスレポートが有効になっている場合は、バンドル配信ステータスレポートを生成する必要があります。バンドルのレポート - エンドポイントIDを宛先。このステータスレポートは、ペイロードがアプリケーションエージェントに配信されているだけで、アプリケーションエージェントがペイロードを処理したことはありません。
It may at times be advantageous for BPAs to reduce the sizes of bundles in order to forward them. This might be the case, for example, if a node 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.
これは、BPAがそれらを転送するためにバンドルのサイズを減らすために有利であり得る。これは、例えば、バンドルが転送されるべきノードが断続的な連絡先を介してのみアクセス可能であり、束縛されていない連絡先を介してのみアクセス可能である場合がある。
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 node ID and creation timestamp as the original bundle -- whose payloads MUST be the first N and the last (M - N) bytes of the original bundle's payload, where 0 < N < M.
バンドルのサイズは、バンドルを「断片化」することによって減らすことができます。ペイロードがサイズMのサイズであるバンドルをフラグメント化するには、2つの「フラグメント」 - 同じソースノードIDと作成タイムスタンプを持つ新しいバンドルを元のバンドルとして置き換えることです。そのペイロードは最初のNと最後の（m） - n）元のバンドルのペイロードのバイト。ここで、0 <n <m。
Note that fragments are bundles and therefore may themselves be fragmented, so multiple episodes of 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.)
フラグメントはバンドルであり、したがってそれら自体が断片化されている可能性があるため、フラグメンテーションの複数のエピソードが有効になっても元のバンドルを2つ以上のフラグメントに置き換えます。（ただし、IPフラグメンテーションのように、フラグメンテーションのレベルは1つしかありません。）
Any bundle whose primary block's bundle processing control flags do *NOT* indicate that it must not be fragmented MAY be fragmented at any time, for any purpose, at the discretion of the BPA. *NOTE*, however, that some combinations of bundle fragmentation, replication, and routing might result in unexpected traffic patterns.
プライマリブロックのバンドル処理制御フラグがDO * NOT * NOT *ではないバンドルは、断片化されていなければならないことを示しています。* NOTE *は、バンドルの断片化、複製、およびルーティングのいくつかの組み合わせが予期せぬトラフィックパターンをもたらす可能性があります。
Fragmentation SHALL be constrained as follows:
断片化は次のように制限されるものとします。
* The concatenation of the payloads of all fragments produced by fragmentation MUST always be identical to the payload of the fragmented bundle (that is, the bundle that is being fragmented). Note that the payloads of fragments resulting from different fragmentation episodes, in different parts of the network, may be overlapping subsets of the fragmented bundle's payload.
* フラグメンテーションによって生成されたすべてのフラグメントのペイロードの連結は、断片化されたバンドルのペイロード（つまり、断片化されているバンドル）と同じでなければなりません。ネットワークの異なる部分では、異なる断片化エピソードから生じるフラグメントのペイロードは、断片化されたバンドルのペイロードの重複サブセットであり得ることに留意されたい。
* The primary block of each fragment MUST differ from that of the fragmented bundle, in that the bundle processing control flags of the fragment MUST indicate that the bundle is a fragment and both fragment offset and total application data unit length must be provided. Additionally, the CRC of the primary block of the fragmented bundle, if any, MUST be replaced in each fragment by a new CRC computed for the primary block of that fragment.
* フラグメントのバンドル処理制御フラグは、バンドルがフラグメントであり、フラグメントオフセットと総アプリケーションデータ単位長の両方が提供されなければならないという点で、各フラグメントの一次ブロックは断片化されたバンドルのそれとは異なりなければならない。さらに、断片化されたバンドルの一次ブロックのCRCは、あらゆるフラグメントに置き換えられなければならない。そのフラグメントの一次ブロックについて計算された新しいCRCによって置き換えられなければならない。
* The payload blocks of fragments will differ from that of the fragmented bundle as noted above.
* フラグメントのペイロードブロックは、上記のように断片化されたバンドルのそれとは異なります。
* If the fragmented bundle is not a fragment or is the fragment with offset zero, then all extension blocks of the fragmented bundle MUST be replicated in the fragment whose offset is zero.
* 断片化されたバンドルがフラグメントではないか、オフセットゼロを持つフラグメントである場合、断片化されたバンドルのすべての拡張ブロックは、オフセットがゼロのフラグメントに複製されなければなりません。
* Each of the fragmented bundle's extension blocks whose "Block must be replicated in every fragment" flag is set to 1 MUST be replicated in every fragment.
* 「ブロックをすべてのフラグメントに複製する必要がある」フラグが1に設定されているフラグ内の各断片化ブロックは、すべてのフラグメントで複製されなければなりません。
* Beyond these rules, rules for the replication of extension blocks in the fragments must be defined in the specifications for those extension block types.
* これらの規則を超えて、フラグメント内の拡張ブロックを複製するための規則は、それらの拡張ブロックタイプの仕様で定義する必要があります。
Note that the Bundle Fragmentation procedure described in Section 5.8 may result in the replacement of a single original bundle with an arbitrarily large number of fragmentary bundles. In order to be delivered at a destination node, the original bundle's payload must be reassembled from the payloads of those fragments.
セクション5.8に記載されているバンドルフラグメンテーション手順は、単一のオリジナルバンドルを任意に多数の断片バンドルに置き換えることができることに留意されたい。宛先ノードで配信されるためには、元のバンドルのペイロードをそれらのフラグメントのペイロードから再組み立てする必要があります。
The "material extents" of a received fragment's payload are all continuous sequences of bytes in that payload that do not overlap with the material extents of the payloads of any previously received fragments with the same source node ID and creation timestamp. If the concatenation -- as informed by fragment offsets and payload lengths -- of the material extents of the payloads of this fragment and all previously received fragments with the same source node ID and creation timestamp as this fragment forms a continuous byte array whose length is equal to the total application data unit length noted in the fragment's primary block, then:
受信されたフラグメントのペイロードの「材料エクステント」は、同じ送信元ノードIDおよび作成タイムスタンプを有する任意の以前に受信されたフラグメントのペイロードの材料範囲と重ならないというそのペイロード内のすべての連続シーケンスである。このフラグメントのペイロードの重複負荷の材料のエクステントのフラグメントオフセットおよびペイロード長の連結である場合 - このフラグメントとして同じソースノードIDおよび作成タイムスタンプを持つすべての以前に受信されたフラグメントは、長さがある連続バイト配列を形成します。フラグメントのプライマリブロックに記載されている合計アプリケーションデータ単位長に等しい。
* This byte array -- the reassembled ADU -- MUST replace the payload of that fragment whose material extents include the extent at offset zero. Note that this will enable delivery of the reconstituted original bundle as described in Step 1 of Section 5.7.
* このバイト配列 - 再組み立てされたADU - そのフラグメントのペイロードを、そのフラグメントのペイロードをオフセットゼロの範囲が含まれていなければなりません。これにより、セクション5.7のステップ1で説明されているように、再構成元のバンドルの配信が可能になることに注意してください。
* The "Reassembly pending" retention constraint MUST be removed from every other fragment with the same source node ID and creation timestamp as this fragment.
* このフラグメントとして、同じソースノードIDと作成タイムスタンプを使用して、「再構成保留中の」保持制約を他のすべてのフラグメントから削除する必要があります。
Note: Reassembly of ADUs from fragments occurs at the nodes that are members of destination endpoints as necessary; an ADU MAY also be reassembled at some other node on the path to the destination.
注：フラグメントからのADUの再組み立ては、必要に応じて宛先エンドポイントのメンバーであるノードで発生します。ADUは、宛先へのパス上の他のノードでも再組み立てされる可能性があります。
The steps in deleting a bundle are as follows:
バンドルを削除する手順は次のとおりです。
Step 1: If the "request reporting of bundle deletion" flag in the bundle's status report request field is set to 1 and if status reporting is enabled, then a bundle deletion status report citing the reason for deletion SHOULD be generated, destined for the bundle's report-to endpoint ID.
ステップ1：BundleのStatus Report Requestフィールドの「バンドル削除の要求の要求」フラグが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, thereby releasing any persistent storage that may have been allocated to it.
バンドルに残りの保持制約がないとすぐに、それは廃棄される可能性があり、それによってそれに割り当てられている可能性がある永続的な記憶域を解放する。
When requested to cancel a specified transmission, where the bundle created upon initiation of the indicated transmission has not yet been discarded, the BPA MUST delete that bundle for the reason "Transmission canceled". For this purpose, the procedure defined in Section 5.10 MUST be followed.
指定された送信の開始時に作成されたバンドルがまだ破棄されていない、指定された送信をキャンセルするように要求された場合、BPAはそのバンドルを削除しなければなりません。この目的のために、セクション5.10に定義されている手順に従う必要があります。
Administrative records are standard ADUs that are used in providing some of the features of the Bundle Protocol. Bundle Protocol administrative record types are registered in the IANA "Bundle Administrative Record Types" registry [RFC5050]; of these, only administrative record type 1, "Bundle status report", is defined for BPv7 at this time. Note that additional types of administrative records may be defined by supplementary DTN protocol specification documents.
管理レコードは、バンドルプロトコルのいくつかの機能を提供するのに使用される標準のADUです。バンドルプロトコル管理レコードタイプは、IANA "Bundle管理レコードタイプ"レジストリ[RFC5050]に登録されています。このうち、この時点でBPV7に対して管理レコードタイプ1、「バンドルステータスレポート」のみが定義されています。追加の種類の管理レコードは、補足DTNプロトコル仕様書類によって定義されてもよい。
Every administrative record consists of:
すべての管理レコードは次のものから構成されています。
* A record type code (an unsigned integer for which valid values are as defined below).
* レコードタイプコード（有効な値が以下のような符号なし整数）。
* Record content in type-specific format.
* 型固有の形式でコンテンツを記録します。
Each BP administrative record SHALL be represented as a CBOR array comprising two items.
各BP管理記録は、2つの項目を含むCBORアレイとして表されるものとします。
The first item of the array SHALL be a record type code, which SHALL be represented as a CBOR unsigned integer.
配列の最初の項目はレコードタイプのコードであり、これはCBOBOR符号なし整数として表されます。
The second element of this array SHALL be the applicable CBOR encoding of the content of the record. Details of the CBOR encoding of administrative record type 1 are provided below. Details of the CBOR encoding of other types of administrative records are included in the specifications defining those records.
この配列の2番目の要素は、レコードの内容の適用可能なCBOBORエンコードとする。管理記録タイプ1のCBOR符号化の詳細は以下の通りである。他のタイプの管理レコードのCBORエンコードの詳細は、それらのレコードを定義する仕様に含まれています。
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, forwarding, final delivery, and deletion. They are transmitted to the report-to endpoints of bundles.
指定された条件下での「バンドルステータスレポート」の送信は、バンドルの送信が要求されたときに呼び出すことができるオプションです。これらの報告は、領収書、転送、最終配信、削除の通知など、バンドルがシステムを介してどのように進行しているかについての情報を提供することを目的としています。それらは、バンドルの報告からエンドポイントに送信されます。
Each bundle status report SHALL be represented as a CBOR array. The number of elements in the array SHALL be either 6 (if the subject bundle is a fragment) or 4 (otherwise).
各バンドルステータスレポートはCBORアレイとして表されます。配列内の要素数は6（被写体バンドルがフラグメントである場合）または4（そうでない場合）のいずれかでなければならない。
The first element of the bundle status report SHALL be bundle status information represented as a CBOR array of at least four elements. The first four elements of the bundle status information shall provide information on the following four status assertions, in this order:
バンドルステータスレポートの最初の要素は、少なくとも4つの要素のCBOR配列として表されるバンドルステータス情報とする。バンドルステータス情報の最初の4つの要素は、次の4つのステータスアサーションに関する情報をこの順序で提供しなければならない。
* Reporting node received bundle.
* レポートノードがバンドルを受信しました。
* Reporting node forwarded the bundle.
* レポートノードはバンドルを転送しました。
* Reporting node delivered the bundle.
* レポートノードはバンドルを配信しました。
* Reporting node deleted the bundle.
* レポートノードバンドルを削除しました。
Each element of the bundle status information SHALL be a bundle status item encoded as a CBOR array.
バンドルステータス情報の各要素は、CBOBOR配列として符号化されたバンドルステータス項目とする。
The number of elements in each bundle status item SHALL be either 2 (if the value of the first element of the bundle status item is 1 AND the "Report status time" flag was set to 1 in the bundle processing control flags of the bundle whose status is being reported) or 1 (otherwise).
各バンドルステータス項目の要素数は、2（バンドルステータス項目の最初の要素の値が1の場合は「レポートステータスタイム」フラグが1に設定されている場合、バンドルのバンドル処理制御フラグで1に設定されています。ステータスが報告されています）または1（それ以外の場合）。
The first element of each bundle status item SHALL be a status indicator, a Boolean value indicating whether or not the corresponding bundle status is asserted, encoded as a CBOR Boolean value. If present, the second element of each bundle status item SHALL indicate the time (as reported by the local system clock; this is an implementation matter) at which the indicated status was asserted for this bundle, represented as a DTN time as described in Section 4.2.6.
各バンドルステータス項目の最初の要素はステータスインジケータとなり、対応するバンドルステータスがアサートされているかどうかを示すブール値は、CBOBORブール値としてエンコードされます。存在する場合、各バンドルステータス項目の2番目の要素は（ローカルシステムクロックによって報告されているように）時間を示します（これは実装問題です。これは実装問題です）。4.2.6。
The second element of the bundle status report SHALL be the bundle status report reason code explaining the value of the status indicator, represented as a CBOR unsigned integer. Valid status report reason codes are registered in the IANA "Bundle Status Report Reason Codes" subregistry in the "Bundle Protocol" registry (see Section 9.5). The initial contents of that registry are listed in Table 1, but the list of status report reason codes provided here is neither exhaustive nor exclusive; supplementary DTN protocol specifications (including, but not restricted to, Bundle Protocol Security [BPSEC]) may define additional reason codes.
バンドルステータスレポートの2番目の要素は、CBOR符号なし整数として表されるステータスインジケータの値を説明するバンドルステータスレポート理由コードとする。有効なステータスレポート理由コードは、「バンドルプロトコル」レジストリの「バンドルステータスレポート理由コード」サブリュージストリートに登録されています（セクション9.5を参照）。そのレジストリの初期内容を表1にリストしますが、ここで提供されるステータスレポート理由コードのリストは網羅的でも排他的でもない。補足DTNプロトコルの仕様（バンドルプロトコルセキュリティ[BPSEC]を含むが制限されていない）は、追加の理由コードを定義することができる。
+========+============================================+
| Value | Meaning |
+========+============================================+
| 0 | No additional information. |
+--------+--------------------------------------------+
| 1 | Lifetime expired. |
+--------+--------------------------------------------+
| 2 | Forwarded over unidirectional link. |
+--------+--------------------------------------------+
| 3 | Transmission canceled. |
+--------+--------------------------------------------+
| 4 | Depleted storage. |
+--------+--------------------------------------------+
| 5 | Destination endpoint ID unavailable. |
+--------+--------------------------------------------+
| 6 | No known route to destination from here. |
+--------+--------------------------------------------+
| 7 | No timely contact with next node on route. |
+--------+--------------------------------------------+
| 8 | Block unintelligible. |
+--------+--------------------------------------------+
| 9 | Hop limit exceeded. |
+--------+--------------------------------------------+
| 10 | Traffic pared (e.g., status reports). |
+--------+--------------------------------------------+
| 11 | Block unsupported. |
+--------+--------------------------------------------+
| 17-254 | Unassigned |
+--------+--------------------------------------------+
| 255 | Reserved |
+--------+--------------------------------------------+
Table 1: Status Report Reason Codes
表1：ステータスレポート理由コード
The third element of the bundle status report SHALL be the source node ID identifying the source of the bundle whose status is being reported, represented as described in Section 4.2.5.1.1.
バンドルステータスレポートの3番目の要素は、セクション4.2.5.1.1で説明されているように、ステータスが報告されているバンドルのソースを識別するソースノードIDとする。
The fourth element of the bundle status report SHALL be the creation timestamp of the bundle whose status is being reported, represented as described in Section 4.2.7.
バンドルステータスレポートの4番目の要素は、セクション4.2.7に記載されているように、ステータスが報告されているバンドルの作成タイムスタンプです。
The fifth element of the bundle status report SHALL be present if and only if the bundle whose status is being reported contained a fragment offset. If present, it SHALL be the subject bundle's fragment offset represented as a CBOR unsigned integer item.
バンドルステータスレポートの5番目の要素は、ステータスが報告されているバンドルがフラグメントオフセットを含んでいた場合に限り、存在します。存在する場合、それはCBOBOR符号なし整数項目として表されるサブジェクトバンドルのフラグメントオフセットとする。
The sixth element of the bundle status report SHALL be present if and only if the bundle whose status is being reported contained a fragment offset. If present, it SHALL be the length of the subject bundle's payload represented as a CBOR unsigned integer item.
バンドルステータスレポートの6番目の要素は、ステータスが報告されているバンドルがフラグメントオフセットを含んでいた場合に限り、存在するものとします。存在する場合、それはCBOBOR符号なし整数項目として表されるサブジェクトバンドルのペイロードの長さでなければならない。
Note that the forwarding parameters (such as lifetime, applicable security measures, etc.) of the bundle whose status is being reported MAY be reflected in the parameters governing the forwarding of the bundle that conveys a status report, but this is an implementation matter. Bundle Protocol deployment experience to date has not been sufficient to suggest any clear guidance on this topic.
ステータスが報告されているバンドルの転送パラメータ（寿命、適用可能なセキュリティ対策など）は、ステータスレポートを伝えるバンドルの転送を行うパラメータに反映されますが、これは実装問題です。このトピックに関する明確なガイダンスを示唆するのに十分ではありませんでした。
Whenever the application agent's administrative element is directed by the BPA to generate an administrative record, the following procedure must be followed:
アプリケーションエージェントの管理要素が管理レコードを生成するためにBPAによって指示されるたびに、次の手順に従う必要があります。
Step 1: The administrative record must be constructed. If the administrative record references a bundle and the referenced bundle is a fragment, the administrative record MUST contain the fragment offset and fragment length.
ステップ1：管理レコードを構築する必要があります。管理レコードがバンドルと参照されているバンドルがフラグメントである場合、管理レコードはフラグメントオフセットとフラグメントの長さを含める必要があります。
Step 2: A request for transmission of a bundle whose payload is this administrative record MUST be presented to the BPA.
ステップ2：この管理レコードのペイロードがBPAに提示されなければならないバンドルの送信要求。
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 CLA provides a defined minimal set of services to the BPA. This convergence-layer service specification enumerates those services.
エンドツーエンドバンドルプロトコルの成功した動作は、「コンバージェンスレイヤ」と呼ばれるものにおける基礎となるプロトコルの動作によって異なります。これらのプロトコルはノード間の通信を実現します。各CLAが定義された最小限のサービスをBPAに提供する限り、さまざまなプロトコルがこの目的に役立ちます。この収束層サービス仕様はそれらのサービスを列挙します。
Each CLA is expected to provide the following services to the BPA:
各CLAは、以下のサービスをBPAに提供すると予想されます。
* sending a bundle to a bundle node that is reachable via the convergence-layer protocol.
* コンバージェンス層プロトコルを介して到達可能なバンドルノードにバンドルを送信します。
* notifying the BPA of the disposition of its data-sending procedures with regard to a bundle, upon concluding those procedures.
* これらの手順を締めくくり、バンドルに関してデータ送信手順の配置のBPAに通知する。
* delivering to the BPA a bundle that was sent by a bundle node via the convergence-layer protocol.
* BPAにコンバージェンスレイヤプロトコルを介してバンドルノードによって送信されたバンドルをバンドルに配信します。
The convergence-layer service interface specified here is neither exhaustive nor exclusive. That is, supplementary DTN protocol specifications (including, but not restricted to, Bundle Protocol Security [BPSEC]) may expect CLAs that serve BP implementations conforming to those protocols to provide additional services such as reporting on the transmission and/or reception progress of individual bundles (at completion and/or incrementally), retransmitting data that were lost in transit, discarding bundle-conveying data units that the convergence-layer protocol determines are corrupt or inauthentic, or reporting on the integrity and/or authenticity of delivered bundles.
ここで指定されている収束層サービスインタフェースは、徹底的でも排他的でもない。つまり、補足DTNプロトコル仕様（バンドルプロトコルセキュリティ[BPSEC]を含むが、バンドルプロトコルセキュリティ[BPSEC]を含む）は、それらのプロトコルに準拠したBP実装を提供するCLAが、個人の送信や受信の進行状況に関する報告などの追加のサービスを提供することを期待しています。バンドル（完了時および/または段階的に）再送されたデータを再送信し、コンバージェンス層プロトコルが決定するバンドル搬送データユニットが破損しているか、または納入されたバンドルの完全性および/または信頼性に関する報告を廃棄します。
In addition, the Bundle Protocol relies on the capabilities of protocols at the convergence layer to minimize congestion in the store-carry-forward overlay network. The potentially long round-trip times characterizing delay-tolerant networks are incompatible with end-to-end, reactive congestion-control mechanisms, so convergence-layer protocols MUST provide rate limiting or congestion control.
さらに、バンドルプロトコルは、ストアキャリーフォワードオーバーレイネットワークにおける輻輳を最小限に抑えるために、コンバージェンスレイヤのプロトコルの機能に依存しています。遅延耐性ネットワークを特徴付ける潜在的に長い往復時間は、エンドツーエンド、反応性輻輳制御メカニズムと互換性がなく、コンバージェンス層プロトコルはレート制限または輻輳制御を提供しなければなりません。
The Bundle Protocol security architecture and the available security services are specified in an accompanying document, the Bundle Protocol Security (BPSec) specification [BPSEC]. Whenever Bundle Protocol security services (as opposed to the security services provided by overlying application protocols or underlying convergence-layer protocols) are required, those services SHALL be provided by BPSec rather than by some other mechanism with the same or similar scope.
バンドルプロトコルセキュリティアーキテクチャと利用可能なセキュリティサービスは、付随する文書、バンドルプロトコルセキュリティ（BPSEC）仕様[BPSEC]で指定されています。（アプリケーションプロトコルまたは基礎となるコンバージェンス層プロトコルによって提供されるセキュリティサービスとは対照的に）バンドルプロトコルセキュリティサービスが必要とされるときはいつでも、それらのサービスは同じまたは類似のスコープを持つ他のメカニズムではなくBPSECによって提供されなければならない。
A Bundle Protocol Agent (BPA) that sources, cryptographically verifies, and/or accepts a bundle MUST implement support for BPSec. Use of BPSec for any single bundle is optional.
バンドルをソース化、暗号化して、および/または受け入れるバンドルプロトコルエージェント（BPA）は、BPSECのサポートを実装する必要があります。単一のバンドルのBPSECの使用はオプションです。
The BPSec extensions to the Bundle Protocol enable each block of a bundle (other than a BPSec extension block) to be individually authenticated by a signature block (Block Integrity Block, or BIB) and also enable each block of a bundle other than the primary block (and the BPSec extension blocks themselves) to be individually encrypted by a Block Confidentiality Block (BCB).
バンドルプロトコルへのBPSEC拡張機能は、バンドルの各ブロック（BPSEC拡張ブロック以外）を個別に認証され（Block Integrityブロック、またはBIB）、プライマリブロック以外のバンドルの各ブロックも有効にします。（およびBPSECエクステンションブロック自体）は、ブロック機密性ブロック（BCB）によって個別に暗号化されるようにします。
Because the security mechanisms are extension blocks that are themselves inserted into the bundle, the protections they afford apply while the bundle is at rest, awaiting transmission at the next forwarding opportunity, as well as in transit.
セキュリティメカニズムは、バンドルに挿入されているエクステンションブロックであるため、バンドルが残りの間に適用される保護、次回の転送機会、ならびに輸送中の送信を待っています。
Additionally, convergence-layer protocols that ensure authenticity of communication between adjacent nodes in a BP network topology SHOULD be used where available, to minimize the ability of unauthenticated nodes to introduce inauthentic traffic into the network. Convergence-layer protocols that ensure confidentiality of communication between adjacent nodes in a BP network topology SHOULD also be used where available, to minimize exposure of the bundle's primary block and other cleartext blocks, thereby offering some defense against traffic analysis.
さらに、BPネットワークトポロジ内の隣接ノード間の通信の信頼性を確保するコンバージェンスレイヤプロトコルは、認証されていないノードのネットワークへの不正なトラフィックを導入する能力を最小限に抑えるために使用されるべきである。BPネットワークトポロジ内の隣接ノード間の通信の機密性を確保するコンバージェンスレイヤプロトコルも、バンドルのプライマリブロックおよび他のクリアテキストブロックの露出を最小限に抑えるために、利用可能な場合には、トラフィック分析に対するいくつかの防御を提供する必要があります。
In order to provide authenticity and/or confidentiality of communication between BP nodes, the convergence-layer protocol requires as input the name or names of the expected communication peer(s). These must be supplied by the CLA. Details of the means by which the CLA determines which CL endpoint name(s) must be provided to the CL protocol are out of scope for this specification. Note, though, that when the CL endpoint names are a function of BP endpoint IDs, the correctness and authenticity of that mapping will be vital to the overall security properties that the CL provides to the system.
BPノード間の通信の信頼性および/または機密性を提供するために、収束層プロトコルは、入力として予想通信ピアの名前または名前を必要とする。これらはCLAによって供給されなければなりません。CLAがCLプロトコルに提供されなければならないCLAエンドポイント名を決定する手段の詳細は、この仕様に対して範囲外である。ただし、CLエンドポイント名がBPエンドポイントIDの関数である場合、そのマッピングの正当性と信頼性は、CLがシステムに提供する全体的なセキュリティプロパティに対して不可欠です。
Note that, while the primary block must remain in the clear for routing purposes, the Bundle Protocol could be protected against traffic analysis to some extent by using bundle-in-bundle encapsulation [BIBE] to tunnel bundles to a safe forward distribution point: the encapsulated bundle could form the payload of an encapsulating bundle, and that payload block could be encrypted by a BCB.
プライマリブロックはルーティングの目的で明確なままにする必要があるが、バンドルインバンドルカプセル化[BIBE]を使用することによって、バンドルプロトコルをある程度トラフィック分析から保護することができます。カプセル化されたバンドルは、カプセル化バンドルのペイロードを形成することができ、ペイロードブロックはBCBによって暗号化され得る。
Note that the generation of bundle status reports is disabled by default because malicious initiation of bundle status reporting could result in the transmission of extremely large numbers of bundles, effecting a denial-of-service attack. Imposing bundle lifetime overrides would constitute one defense against such an attack.
バンドルステータスレポートの生成はデフォルトで無効になっていることに注意してください。バンドルの生涯のオーバーライドを課すと、そのような攻撃に対する一つの防御が構成されます。
Note also that the reception of large numbers of fragmentary bundles with very long lifetimes could constitute a denial-of-service attack, occupying storage while pending reassembly that will never occur. Imposing bundle lifetime overrides would, again, constitute one defense against such an attack.
また、非常に長い寿命を持つ大量の断片的バンドルの受信は、耐用拒否攻撃を構成することができ、それは決して発生することはありません。バンドルの寿命の上書きを課すことは、再びそのような攻撃に対して1つの防御を構成するだろう。
This protocol makes use of absolute timestamps for several purposes. Provisions are included for nodes without accurate clocks to retain most of the protocol functionality, but nodes that are unaware that their clock is inaccurate may exhibit unexpected behavior.
このプロトコルは、いくつかの目的のために絶対タイムスタンプを利用します。プロトコル機能の大部分を保持するための正確なクロックなしでは、規定はノードに含まれていますが、その時計が不正確であることを認識していないノードは予期しない動作を示します。
The Bundle Protocol includes fields requiring registries managed by IANA.
バンドルプロトコルには、IANAが管理するレジストリが必要なフィールドが含まれています。
The "Bundle Block Types" subregistry in the "Bundle Protocol" registry has been augmented by adding a column identifying the version of the Bundle Protocol (Bundle Protocol Version) that applies to the values. IANA has added the following values, as described in Section 4.3.1, to the "Bundle Block Types" registry with a value of "7" for the Bundle Protocol Version. IANA has set the Bundle Protocol Version to "6" or "6,7" for preexisting values in the "Bundle Block Types" registry, as shown below.
「バンドルプロトコル」レジストリの「バンドルブロックタイプ」サブレイストは、値に適用されるバンドルプロトコル（バンドルプロトコルバージョン）のバージョンを識別する列を追加することによって拡張されました。IANAは、セクション4.3.1で説明されているように、バンドルプロトコルバージョンの値 "7"の "7"を持つ "Bundle Block Types"レジストリを追加しました。以下に示すように、IANAはバンドルプロトコルのバージョンを "6"または "6,7"に設定しました。
+=================+=========+=========================+===========+
| Bundle Protocol | Value | Description | Reference |
| Version | | | |
+=================+=========+=========================+===========+
| none | 0 | Reserved | [RFC6255] |
+-----------------+---------+-------------------------+-----------+
| 6,7 | 1 | Bundle Payload Block | [RFC5050] |
| | | | [RFC9171] |
+-----------------+---------+-------------------------+-----------+
| 6 | 2 | Bundle Authentication | [RFC6257] |
| | | Block | |
+-----------------+---------+-------------------------+-----------+
| 6 | 3 | Payload Integrity Block | [RFC6257] |
+-----------------+---------+-------------------------+-----------+
| 6 | 4 | Payload Confidentiality | [RFC6257] |
| | | Block | |
+-----------------+---------+-------------------------+-----------+
| 6 | 5 | Previous-Hop Insertion | [RFC6259] |
| | | Block | |
+-----------------+---------+-------------------------+-----------+
| 7 | 6 | Previous node | [RFC9171] |
| | | (proximate sender) | |
+-----------------+---------+-------------------------+-----------+
| 7 | 7 | Bundle age (in | [RFC9171] |
| | | milliseconds) | |
+-----------------+---------+-------------------------+-----------+
| 6 | 8 | Metadata Extension | [RFC6258] |
| | | Block | |
+-----------------+---------+-------------------------+-----------+
| 6 | 9 | Extension Security | [RFC6257] |
| | | Block | |
+-----------------+---------+-------------------------+-----------+
| 7 | 10 | Hop count (#prior xmit | [RFC9171] |
| | | attempts) | |
+-----------------+---------+-------------------------+-----------+
| 7 | 11-191 | Unassigned | |
+-----------------+---------+-------------------------+-----------+
| 6,7 | 192-255 | Reserved for Private | [RFC5050] |
| | | and/or Experimental Use | [RFC9171] |
+-----------------+---------+-------------------------+-----------+
Table 2: "Bundle Block Types" Registry
表2：「バンドルブロックタイプ」レジストリ
IANA has added the following value to the "Primary Bundle Protocol Version" subregistry in the "Bundle Protocol" registry.
IANAは、「バンドルプロトコル」レジストリの「プライマリバンドルプロトコルバージョン」サブレイストに次の値を追加しました。
+=======+=============+===========+
| Value | Description | Reference |
+=======+=============+===========+
| 7 | Assigned | [RFC9171] |
+-------+-------------+-----------+
Table 3: "Primary Bundle Protocol Version" Registry
表3：「プライマリバンドルプロトコルバージョン」レジストリ
Values 8-255 (rather than 7-255) are now Unassigned.
値8-255（7-255ではなく）は割り当てられていません。
The "Bundle Processing Control Flags" subregistry in the "Bundle Protocol" registry has been augmented by adding a column identifying the version of the Bundle Protocol (Bundle Protocol Version) that applies to the new values. IANA has added the following values, as described in Section 4.2.3, to the "Bundle Processing Control Flags" registry with a value of "7" for the Bundle Protocol Version. IANA has set the Bundle Protocol Version to the value "6" or "6,7" for preexisting values in the "Bundle Processing Control Flags" registry, as shown below.
「バンドルプロトコル」レジストリの「バンドル処理制御フラグ」サブレクシストは、新しい値に適用されるバンドルプロトコル（バンドルプロトコルバージョン）のバージョンを識別する列を追加することによって拡張されています。バンドルプロトコルのバージョンの値 "7"の "7"の "7"にある "Bundle Processing Control Flags"レジストリを "7"に "Bundle Processing Control Flags"レジストリに記述されているように、IANAは次の値を追加しました。次に示すように、IANAはバンドルプロトコルのバージョンを「バンドル処理制御フラグ」レジストリの既存の値については、「6」または「6,7」に設定しました。
+=================+=================+===================+===========+
| Bundle Protocol | Bit Position | Description | Reference |
| Version | (right to | | |
| | left) | | |
+=================+=================+===================+===========+
| 6,7 | 0 | Bundle is a | [RFC5050] |
| | | fragment | [RFC9171] |
+-----------------+-----------------+-------------------+-----------+
| 6,7 | 1 | ADU is an | [RFC5050] |
| | | administrative | [RFC9171] |
| | | record | |
+-----------------+-----------------+-------------------+-----------+
| 6,7 | 2 | Bundle must not | [RFC5050] |
| | | be fragmented | [RFC9171] |
+-----------------+-----------------+-------------------+-----------+
| 6 | 3 | Custody transfer | [RFC5050] |
| | | is requested | |
+-----------------+-----------------+-------------------+-----------+
| 6 | 4 | Destination | [RFC5050] |
| | | endpoint is a | |
| | | singleton | |
+-----------------+-----------------+-------------------+-----------+
| 6,7 | 5 | Acknowledgement | [RFC5050] |
| | | by application is | [RFC9171] |
| | | requested | |
+-----------------+-----------------+-------------------+-----------+
| 7 | 6 | Status time | [RFC9171] |
| | | requested in | |
| | | reports | |
+-----------------+-----------------+-------------------+-----------+
| 6 | 7-8 | Class of service: | [RFC5050] |
| | | priority | |
+-----------------+-----------------+-------------------+-----------+
| 6 | 9-13 | Class of service: | [RFC5050] |
| | | reserved | |
+-----------------+-----------------+-------------------+-----------+
| 6,7 | 14 | Request reporting | [RFC5050] |
| | | of bundle | [RFC9171] |
| | | reception | |
+-----------------+-----------------+-------------------+-----------+
| 6 | 15 | Request reporting | [RFC5050] |
| | | of custody | |
| | | acceptance | |
+-----------------+-----------------+-------------------+-----------+
| 6,7 | 16 | Request reporting | [RFC5050] |
| | | of bundle | [RFC9171] |
| | | forwarding | |
+-----------------+-----------------+-------------------+-----------+
| 6,7 | 17 | Request reporting | [RFC5050] |
| | | of bundle | [RFC9171] |
| | | delivery | |
+-----------------+-----------------+-------------------+-----------+
| 6,7 | 18 | Request reporting | [RFC5050] |
| | | of bundle | [RFC9171] |
| | | deletion | |
+-----------------+-----------------+-------------------+-----------+
| 6,7 | 19 | Reserved | [RFC5050] |
| | | | [RFC9171] |
+-----------------+-----------------+-------------------+-----------+
| 6,7 | 20 | Reserved | [RFC5050] |
| | | | [RFC9171] |
+-----------------+-----------------+-------------------+-----------+
| | 21-63 | Unassigned | |
+-----------------+-----------------+-------------------+-----------+
Table 4: "Bundle Processing Control Flags" Registry
表4：「バンドル処理制御フラグ」レジストリ
The "Block Processing Control Flags" subregistry in the "Bundle Protocol" registry has been augmented by adding a column identifying the version of the Bundle Protocol (Bundle Protocol Version) that applies to the related BP version. IANA has set the Bundle Protocol Version to the value "6" or "6,7" for preexisting values in the "Bundle Processing Control Flags" registry, as shown below.
「バンドルプロトコル」レジストリの「ブロック処理制御フラグ」サブリュジストは、関連するBPバージョンに適用されるバンドルプロトコル（バンドルプロトコルバージョン）のバージョンを識別する列を追加することによって増強されている。次に示すように、IANAはバンドルプロトコルのバージョンを「バンドル処理制御フラグ」レジストリの既存の値については、「6」または「6,7」に設定しました。
+=================+==============+====================+===========+
| Bundle Protocol | Bit Position | Description | Reference |
| Version | (right to | | |
| | left) | | |
+=================+==============+====================+===========+
| 6,7 | 0 | Block must be | [RFC5050] |
| | | replicated in | [RFC9171] |
| | | every fragment | |
+-----------------+--------------+--------------------+-----------+
| 6,7 | 1 | Transmit status | [RFC5050] |
| | | report if block | [RFC9171] |
| | | can't be processed | |
+-----------------+--------------+--------------------+-----------+
| 6,7 | 2 | Delete bundle if | [RFC5050] |
| | | block can't be | [RFC9171] |
| | | processed | |
+-----------------+--------------+--------------------+-----------+
| 6 | 3 | Last block | [RFC5050] |
+-----------------+--------------+--------------------+-----------+
| 6,7 | 4 | Discard block if | [RFC5050] |
| | | it can't be | [RFC9171] |
| | | processed | |
+-----------------+--------------+--------------------+-----------+
| 6 | 5 | Block was | [RFC5050] |
| | | forwarded without | |
| | | being processed | |
+-----------------+--------------+--------------------+-----------+
| 6 | 6 | Block contains an | [RFC5050] |
| | | EID-reference | |
| | | field | |
+-----------------+--------------+--------------------+-----------+
| | 7-63 | Unassigned | |
+-----------------+--------------+--------------------+-----------+
Table 5: "Block Processing Control Flags" Registry
表5：「ブロック処理制御フラグ」レジストリ
The "Bundle Status Report Reason Codes" subregistry in the "Bundle Protocol" registry has been augmented by adding a column identifying the version of the Bundle Protocol (Bundle Protocol Version) that applies to the new values. IANA has added the following values, as described in Section 6.1.1, to the "Bundle Status Report Reason Codes" registry with a value of "7" for the Bundle Protocol Version. IANA has set the Bundle Protocol Version to the value "6,7" for preexisting values in the "Bundle Status Report Reason Codes" registry, as shown below.
「バンドルプロトコル」レジストリの「バンドルステータスレポート理由コード」サブレイストは、新しい値に適用されるバンドルプロトコルのバージョン（バンドルプロトコルバージョン）を識別する列を追加することによって増強されました。IANAは、セクション6.1.1で説明されているように、バンドルプロトコルのバージョンの値 "7"の "7"にある "7"を含む次の値を追加しました。下図のように、Bundle Protocolバージョンを「バンドルステータスレポート理由コード」レジストリの既存の値については、バンドルプロトコルバージョンを値 "6,7"に設定しました。
+=================+========+========================+===========+
| Bundle Protocol | Value | Description | Reference |
| Version | | | |
+=================+========+========================+===========+
| 6,7 | 0 | No additional | [RFC5050] |
| | | information | [RFC9171] |
+-----------------+--------+------------------------+-----------+
| 6,7 | 1 | Lifetime expired | [RFC5050] |
| | | | [RFC9171] |
+-----------------+--------+------------------------+-----------+
| 6,7 | 2 | Forwarded over | [RFC5050] |
| | | unidirectional link | [RFC9171] |
+-----------------+--------+------------------------+-----------+
| 6,7 | 3 | Transmission canceled | [RFC5050] |
| | | | [RFC9171] |
+-----------------+--------+------------------------+-----------+
| 6,7 | 4 | Depleted storage | [RFC5050] |
| | | | [RFC9171] |
+-----------------+--------+------------------------+-----------+
| 6,7 | 5 | Destination endpoint | [RFC5050] |
| | | ID unavailable | [RFC9171] |
+-----------------+--------+------------------------+-----------+
| 6,7 | 6 | No known route to | [RFC5050] |
| | | destination from here | [RFC9171] |
+-----------------+--------+------------------------+-----------+
| 6,7 | 7 | No timely contact with | [RFC5050] |
| | | next node on route | [RFC9171] |
+-----------------+--------+------------------------+-----------+
| 6,7 | 8 | Block unintelligible | [RFC5050] |
| | | | [RFC9171] |
+-----------------+--------+------------------------+-----------+
| 7 | 9 | Hop limit exceeded | [RFC9171] |
+-----------------+--------+------------------------+-----------+
| 7 | 10 | Traffic pared | [RFC9171] |
+-----------------+--------+------------------------+-----------+
| 7 | 11 | Block unsupported | [RFC9171] |
+-----------------+--------+------------------------+-----------+
| | 17-254 | Unassigned | |
+-----------------+--------+------------------------+-----------+
| 6,7 | 255 | Reserved | [RFC6255] |
| | | | [RFC9171] |
+-----------------+--------+------------------------+-----------+
Table 6: "Bundle Status Report Reason Codes" Registry
表6：「バンドルステータスレポート理由コード」レジストリ
The Bundle Protocol has a URI scheme type field -- an unsigned integer of indefinite length -- for which IANA has created, and will maintain, a new "Bundle Protocol URI Scheme Types" subregistry in the "Bundle Protocol" registry. The "Bundle Protocol URI Scheme Types" registry governs a namespace of unsigned integers. Initial values for the "Bundle Protocol URI Scheme Types" registry are given below.
バンドルプロトコルには、IANAが作成され、「バンドルプロトコル」レジストリの新しい「バンドルプロトコルURIスキームタイプ」サブリュージストリートが作成され、維持され、維持されます。「バンドルプロトコルURIスキームタイプ」レジストリは、符号なし整数のネームスペースを管理します。「バンドルプロトコルURIスキームタイプ」レジストリの初期値を以下に示します。
The registration policy for this registry is Standards Action [RFC8126]. The allocation should only be granted for a Standards Track RFC approved by the IESG.
このレジストリの登録ポリシーは標準アクション[RFC8126]です。割り当ては、IESGによって承認された標準トラックRFCに対してのみ付与されるべきです。
The range of values is provided as unsigned integers.
値の範囲は符号なし整数として提供されています。
Each assignment consists of a URI scheme type name and its associated description, a reference to the document that defines the URI scheme, and a reference to the document that defines the use of this URI scheme in BP endpoint IDs (including the CBOR encoding of those endpoint IDs in transmitted bundles).
各割り当ては、URIスキームタイプ名とそれに関連する説明、URIスキームを定義する文書への参照と、BPエンドポイントID（それらのCBORエンコーディングを含む）のこのURIスキームの使用を定義する文書への参照で構成されています。送信されたバンドル内のエンドポイントID）。
+===========+==============+================+================+
| Value | Description | BP Utilization | URI Definition |
| | | Reference | Reference |
+===========+==============+================+================+
| 0 | Reserved | n/a | |
+-----------+--------------+----------------+----------------+
| 1 | dtn | [RFC9171] | [RFC9171] |
+-----------+--------------+----------------+----------------+
| 2 | ipn | [RFC9171] | [RFC6260] |
| | | | [RFC9171] |
+-----------+--------------+----------------+----------------+
| 3-254 | Unassigned | n/a | |
+-----------+--------------+----------------+----------------+
| 255-65535 | Reserved | n/a | |
+-----------+--------------+----------------+----------------+
| >65535 | Reserved for | n/a | |
| | Private Use | | |
+-----------+--------------+----------------+----------------+
Table 7: "Bundle Protocol URI Scheme Types" Registry
表7：「バンドルプロトコルURIスキームタイプ」レジストリ
In the "Uniform Resource Identifier (URI) Schemes" (uri-schemes) registry, IANA has updated the registration of the URI scheme with the string "dtn" as the scheme name, as follows:
「Uniform Resource Identifier（URIスキーム」方式）（URIスキーム）レジストリでは、IANAは次のように、Scheme Nameとして文字列 "DTN"を使用してURI方式の登録を更新しました。
URI scheme name: "dtn"
URIスキーム名： "DTN"
Status: Permanent
ステータス：永続的な
Applications and/or protocols that use this URI scheme name: The Delay-Tolerant Networking (DTN) Bundle Protocol (BP).
このURIスキーム名を使用するアプリケーションおよび/またはプロトコル：遅延トレラントネットワーキング（DTN）バンドルプロトコル（BP）。
Contact: Scott Burleigh <sburleig.sb@gmail.com>
Change controller: IETF (iesg@ietf.org)
変更コントローラー：IETF（iesg@ietf.org）
Reference: [RFC9171]
参照：[RFC9171]
In the "Uniform Resource Identifier (URI) Schemes" (uri-schemes) registry, IANA has updated the registration of the URI scheme with the string "ipn" as the scheme name, originally documented in RFC 6260 [RFC6260], as follows.
「統一リソース識別子（URIスキーム」方式）（URIスキーム）レジストリでは、最初にRFC 6260 [RFC6260]に記載されているスキーム名として、String "IPN"を使用してURIスキームの登録を更新しました。
URI scheme name: "ipn"
URIスキーム名： "IPN"
Status: Permanent
ステータス：永続的な
Applications and/or protocols that use this URI scheme name: The Delay-Tolerant Networking (DTN) Bundle Protocol (BP).
このURIスキーム名を使用するアプリケーションおよび/またはプロトコル：遅延トレラントネットワーキング（DTN）バンドルプロトコル（BP）。
Contact: Scott Burleigh <sburleig.sb@gmail.com>
Change controller: IETF (iesg@ietf.org)
変更コントローラー：IETF（iesg@ietf.org）
Reference: [RFC9171]
参照：[RFC9171]
[BPSEC] Birrane, III, E. and K. McKeever, "Bundle Protocol Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172, January 2022, <https://www.rfc-editor.org/info/rfc9172>.
[BPSEC] Birrane、III、E.およびK.Mckeever、「バンドルプロトコルセキュリティ（BPSEC）」、RFC 9172、DOI 10.17487 / RFC9172、2022年1月、<https：//www.rfc-editor.org/info/rfc9172>。
[CRC16] ITU-T, "X.25: Interface between Data Terminal Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for terminals operating in the packet mode and connected to public data networks by dedicated circuit", p. 9, Section 2.2.7.4, ITU-T Recommendation X.25, October 1996, <https://www.itu.int/rec/T-REC-X.25-199610-I/>.
[CRC16] ITU-T、 "x.25：パケットモードで動作し、専用回路でパブリックデータネットワークに接続されている端末のデータ端末装置（DTE）とデータ回線終端装置（DCE）との間のインタフェース"、p。9、セクション2.2.7.4、ITU-T勧告X.25、1996年10月、<https：//www.itu.int/rec/t-rec-x.25-199610-i/>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>.
[RFC4960] Stewart、R.、Ed。、「ストリーム制御伝送プロトコル」、RFC 4960、DOI 10.17487 / RFC4960、2007年9月、<https：//www.rfc-editor.org/info/rfc4960>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234] Crocker、D.、ED。2008年1月、<https://www.rfc-editor.org/info/rfc-editor.org/info/rfc- editor.org/info/rfc5234、<https://www.rfc-editor.org/info/rfc-editor.org/info/rfc- editor.org/info/rfc5234,2008、<https://www.rfc-editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc5234>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B.、RFC 2119キーワードの「大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/info/rfc8949>.
[RFC8949] Bormann、C.およびP.HOFFMAN、「簡潔なバイナリオブジェクト表現（CBOR）」、STD 94、RFC 8949、DOI 10.17487 / RFC8949、2020年12月、<https：//www.rfc-editor.org/info/ RFC8949>。
[SABR] Consultative Committee for Space Data Systems, "Schedule-Aware Bundle Routing", CCSDS Recommended Standard 734.3-B-1, July 2019, <https://public.ccsds.org/Pubs/734x3b1.pdf>.
[SABR]宇宙データシステムのための諮問委員会、「スケジュール対応バンドルルーティング」、CCSDS推奨規格734.3-B-1、<https：//public.ccsds.org/pubs/734x3b1.pdf>。
[TCPCL] Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay-Tolerant Networking TCP Convergence-Layer Protocol Version 4", RFC 9174, DOI 10.17487/RFC9174, January 2022, <https://www.rfc-editor.org/info/rfc9174>.
[TCPCL] SIPOS、B.、DEMMER、M.、OTT、J.、およびS. PerreAll、「遅延耐性ネットワーキングTCPコンバージェンス層プロトコルバージョン4」、RFC 9174、DOI 10.17487 / RFC9174、2022年1月、<HTTPS//www.rfc-editor.org/info/rfc9174>。
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[URI] Berners-Lee、T.、Fielding、R.、およびL.Masinter、 "Uniform Resource Identifier（URI）：汎用シンタックス"、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<https：//www.rfc-editor.org/info/rfc3986>。
[URIREG] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015, <https://www.rfc-editor.org/info/rfc7595>.
[URIREG] Thaler、D.、ED。、Hansen、T.、およびT. hardie、「URIスキームのガイドラインと登録手順」、BCP 35、RFC 7595、DOI 10.17487 / RFC7595、2015年6月、<https：//www.rfc-editor.org/info/rfc7595>。
[ARCH] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, April 2007, <https://www.rfc-editor.org/info/rfc4838>.
[アーチ] CERF、V.、Burleigh、S.、Hooke、A.、Torgerson、L.、Durst、R.、Scott、K.、Fall、K.、およびH.Weiss、「遅延耐性ネットワーキングアーキテクチャ」、RFC 4838、DOI 10.17487 / RFC4838、2007年4月、<https：//www.rfc-editor.org/info/rfc4838>。
[BIBE] Burleigh, S., "Bundle-in-Bundle Encapsulation", Work in Progress, Internet-Draft, draft-ietf-dtn-bibect-03, 18 February 2020, <https://datatracker.ietf.org/doc/html/ draft-ietf-dtn-bibect-03>.
[Bibe] Burleigh、S、「バンドル束カプセル化」、進行中の作業、インターネットドラフト、ドラフト-IETF-DTN-Bibect-03,2020、<https：//datatracker.ietf.org/doc / html / fromp-ietf-dtn-bibect-03>。
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, January 2005, <https://www.rfc-editor.org/info/rfc3987>.
[RFC3987] 2005年1月、<https://ww.rfc-editor.org/info/rfc- editor.org/info/rfc3987、<https://ww.rfc-editor.org/info/rfc- editor.org/info/rfc3987、<https://www.rfc-editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc3987>。
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, DOI 10.17487/RFC5050, November 2007, <https://www.rfc-editor.org/info/rfc5050>.
[RFC5050] Scott、K.およびS. Burleigh、 "Bundle Protocol Specification"、RFC 5050、DOI 10.17487 / RFC5050、2007年11月、<https：//www.rfc-editor.org/info/rfc5050>。
[RFC6255] Blanchet, M., "Delay-Tolerant Networking Bundle Protocol IANA Registries", RFC 6255, DOI 10.17487/RFC6255, May 2011, <https://www.rfc-editor.org/info/rfc6255>.
[RFC6255] Blanchet、M。、「遅延寛容ネットワークバンドルプロトコルIANAレジストリ」、RFC 6255、DOI 10.17487 / RFC6255、2011年5月、<https：//www.rfc-editor.org/info/rfc6255>。
[RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell, "Bundle Security Protocol Specification", RFC 6257, DOI 10.17487/RFC6257, May 2011, <https://www.rfc-editor.org/info/rfc6257>.
[RFC6257] Symington、S.、Farrell、S.、Weiss、H.、およびP. Lovell、「バンドルセキュリティプロトコル仕様」、RFC 6257、DOI 10.17487 / RFC6257、2011年5月、<https：///www.rfc-editor.org/info/rfc6257>。
[RFC6258] Symington, S., "Delay-Tolerant Networking Metadata Extension Block", RFC 6258, DOI 10.17487/RFC6258, May 2011, <https://www.rfc-editor.org/info/rfc6258>.
[RFC6258] Symington、S.、「遅延耐性ネットワークメタデータ拡張ブロック」、RFC 6258、DOI 10.17487 / RFC6258、2011年5月、<https：//www.rfc-editor.org/info/rfc6258>。
[RFC6259] Symington, S., "Delay-Tolerant Networking Previous-Hop Insertion Block", RFC 6259, DOI 10.17487/RFC6259, May 2011, <https://www.rfc-editor.org/info/rfc6259>.
[RFC6259] SymIngton、S。、「遅延耐性ネットワーク挿入ブロック」、RFC 6259、DOI 10.17487 / RFC6259、2011年5月、<https：//www.rfc-editor.org/info/rfc6259>。
[RFC6260] Burleigh, S., "Compressed Bundle Header Encoding (CBHE)", RFC 6260, DOI 10.17487/RFC6260, May 2011, <https://www.rfc-editor.org/info/rfc6260>.
[RFC6260] Burleigh、S、 "圧縮バンドルヘッダーエンコーディング（CBHE）"、RFC 6260、DOI 10.17487 / RFC6260、2011年5月、<https://www.rfc-editor.org/info/rfc6260>。
[RFC7143] Chadalapaka, M., Satran, J., Meth, K., and D. Black, "Internet Small Computer System Interface (iSCSI) Protocol (Consolidated)", RFC 7143, DOI 10.17487/RFC7143, April 2014, <https://www.rfc-editor.org/info/rfc7143>.
[RFC7143] Chadalapaka、M.、Satran、J.、Meth、K.、およびD. Black、 "Internet Small Computer System Interface（iSCSI）プロトコル（統合）"、RFC 7143、DOI 10.17487 / RFC7143、2014年4月、<https://www.rfc-editor.org/info/rfc7143>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M.、Leiba、B.およびT.Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www.rfc-editor.org / info / rfc8126>。
[SIGC] Fall, K., "A Delay-Tolerant Network Architecture for Challenged Internets", SIGCOMM 2003, DOI 10.1145/863955.863960, August 2003, <https://dl.acm.org/doi/10.1145/863955.863960>.
[SIGC] Fall、K。、「挑戦したインターネットのための遅延耐性ネットワークアーキテクチャ」、SIGCOMM 2003、DOI 10.1145 / 863955.863960、<https：//dl.acm.org/doi/10.1145/863955.863960>。
This document makes the following significant changes from RFC 5050:
このドキュメントはRFC 5050から次のような大きな変更を加えます。
* Clarifies the difference between transmission and forwarding.
* 送信と転送の違いを明確にします。
* Migrates custody transfer to the bundle-in-bundle encapsulation specification [BIBE].
* バンドルインバンドルカプセル化仕様[BIBE]へのCustody転送を移行します。
* Introduces the concept of "node ID" as functionally distinct from endpoint ID, while having the same syntax.
* 同じ構文を持ちながら、エンドポイントIDと機能的に異なる「ノードID」の概念を紹介します。
* Restructures primary block, making it immutable. Adds optional CRC.
* プライマリブロックを再構築し、それを不変にします。オプションのCRCを追加します。
* Adds optional CRCs to non-primary blocks.
* 非プライマリブロックにオプションのCRCを追加します。
* Adds block ID number to canonical block format (to support BPSec).
* ブロックID番号を正規ブロック形式（BPSECをサポートするには）を追加します。
* Adds definition of Bundle Age extension block.
* Bundle Age拡張ブロックの定義を追加します。
* Adds definition of Previous Node extension block.
* 前のノード拡張ブロックの定義を追加します。
* Adds definition of Hop Count extension block.
* ホップ数拡張ブロックの定義を追加します。
* Removes Quality of Service markings.
* サービスの品質マーキングを削除します。
* Changes from Self-Delimiting Numeric Values (SDNVs) to CBOR encoding.
* 自己区切り数値（SDNVS）からCBORエンコーディングへの変更。
* Adds lifetime overrides.
* ライフタイムオーバーライドを追加します。
* Clarifies that time values are denominated in milliseconds, not seconds.
* 時間値が秒ではなくミリ秒単位で表されていることを明確にします。
For informational purposes, Carsten Bormann and Brian Sipos have kindly provided an expression of the Bundle Protocol specification in the Concise Data Definition Language (CDDL). That CDDL expression is presented below. Note that wherever the CDDL expression is in disagreement with the textual representation of the BP specification presented in the earlier sections of this document, the textual representation rules.
情報提供のために、CARSTEN BormannおよびBrian Siposは、簡潔なデータ定義言語（CDDL）のバンドルプロトコル仕様の表現を優先的に提供しています。CDDL式を以下に示す。この文書の以前のセクションで提示されているBP仕様のテキスト表現との間に、CDDL式が不一致にある場合は、テキスト表現規則を示します。
bpv7_start = bundle / #6.55799(bundle)
; Times before 2000 are invalid
;2000年前の時間は無効です
dtn-time = uint
; CRC enumerated type
;CRC列挙型
crc-type = &(
crc-none: 0,
CRC - なし：0、
crc-16bit: 1,
CRC-16ビット：1、
crc-32bit: 2
CRC-32ビット：2
)
）
; Either 16-bit or 32-bit
;16ビットまたは32ビットのいずれか
crc-value = (bstr .size 2) / (bstr .size 4)
creation-timestamp = [
dtn-time, ; absolute time of creation
dtn-time、;創造の絶対時間
sequence: uint ; sequence within the time
シーケンス：uint;その間のシーケンス
]
]
eid = $eid .within eid-structure
EID = $ EID
eid-structure = [
uri-code: uint,
URIコード：uint、
SSP: any
SSP：ANY
]
]
$eid /= [
uri-code: 1,
URIコード：1、
SSP: (tstr / 0)
SSP：（TSTR / 0）
]
]
$eid /= [
uri-code: 2,
URIコード：2、
SSP: [
SSP：[
nodenum: uint,
Nodenum：uint、
servicenum: uint
ServiceNum：uint.
]
]
]
]
; The root bundle array
;ルートバンドル配列
bundle = [primary-block, *extension-block, payload-block]
primary-block = [
version: 7,
バージョン：7、
bundle-control-flags,
バンドルコントロールフラグ
crc-type,
CRCタイプ、
destination: eid,
目的地：EID、
source-node: eid,
source-node：EID、
report-to: eid,
報告書：EID、
creation-timestamp,
作成タイムスタンプ、
lifetime: uint,
寿命：uint、
? (
？）（
fragment-offset: uint,
フラグメントオフセット：UINT、
total-application-data-length: uint
総アプリケーションデータ長：uint.
),
）、
? crc-value,
？CRC値、
]
]
bundle-control-flags = uint .bits bundleflagbits
バンドルコントロールフラグ= UINT .BITS BUSTLEFLAGBITS.
bundleflagbits = &(
reserved: 20,
予約済み：20、
reserved: 19,
予約済み：19、
bundle-deletion-status-reports-are-requested: 18,
bundle-deletion-status-reports-requested：18、
bundle-delivery-status-reports-are-requested: 17,
bundle-delivery-status-reports-requested：17、
bundle-forwarding-status-reports-are-requested: 16,
バンドル転送状態 - レポート - requested：16、
reserved: 15,
予約済み：15、
bundle-reception-status-reports-are-requested: 14,
バンドル受信 - ステータス - Reports - Requested：14、
reserved: 13,
予約済み：13、
reserved: 12,
予約済み：12、
reserved: 11,
予約済み：11、
reserved: 10,
予約済み：10、
reserved: 9,
予約済み：9、
reserved: 8,
予約済み：8、
reserved: 7,
予約済み：7、
status-time-is-requested-in-all-status-reports: 6,
ステータスタイム - is all-status-in-all-status-reports：6、
user-application-acknowledgement-is-requested: 5,
ユーザアプリケーション承認 - requested：5、
reserved: 4,
予約済み：4、
reserved: 3,
予約済み：3、
bundle-must-not-be-fragmented: 2,
バンドル記念断片化：2、
payload-is-an-administrative-record: 1,
ペイロードIS-AN-AN管理レコード：1、
bundle-is-a-fragment: 0
バンドルIS-Aフラグメント：0
)
）
; Abstract shared structure of all non-primary blocks
;非プライマリブロック全体の抽象共有構造
canonical-block-structure = [
block-type-code: uint,
ブロックタイプコード：UINT、
block-number: uint,
ブロック番号：uint、
block-control-flags,
ブロックコントロールフラグ
crc-type,
CRCタイプ、
; Each block type defines the content within the byte string
;各ブロックタイプは、バイト文字列内のコンテンツを定義します。
block-type-specific-data,
ブロック型固有データ、
? crc-value
？CRC値
]
]
block-control-flags = uint .bits blockflagbits
ブロックコントロールフラグ= UINT .BITS BLOCKFLAGBITS.
blockflagbits = &(
reserved: 7,
予約済み：7、
reserved: 6,
予約済み：6、
reserved: 5,
予約済み：5、
block-must-be-removed-from-bundle-if-it-cannot-be-processed: 4,
Bundle-If-It-In-It-In-It-It処理できませんでした：4、
reserved: 3,
予約済み：3、
bundle-must-be-deleted-if-block-cannot-be-processed: 2,
Bundle-Sun-deleted-if-block-texce-mooding：2、
status-report-must-be-transmitted-if-block-cannot-be-processed: 1,
ステータスレポート - 送信不可 - ブロック化できません：1、
block-must-be-replicated-in-every-fragment: 0
ブロック記録 - すべてのフラグメント：0
)
）
block-type-specific-data = bstr / #6.24(bstr)
; Actual CBOR data embedded in a byte string, with optional tag to indicate so.
;SOを示すオプションのタグを使用して、バイト文字列に埋め込まれた実際のCBORデータ。
; Additional plain bstr allows ciphertext data.
;追加のプレーンBSTRは暗号文データを許可します。
embedded-cbor<Item> = (bstr .cbor Item) / #6.24(bstr .cbor Item) /
bstr
; Extension block type, which does not specialize other than the code/number
;コード/番号以外に特殊化されていない拡張ブロックタイプ
extension-block = $extension-block .within canonical-block-structure
拡張子ブロック= $拡張ブロック。
; Generic shared structure of all non-primary blocks
;非プライマリブロック全体の一般的な共有構造
extension-block-use<CodeValue, BlockData> = [
block-type-code: CodeValue,
ブロックタイプコード：CodeValue、
block-number: (uint .gt 1),
ブロック番号:( uint .gt 1）、
block-control-flags,
ブロックコントロールフラグ
crc-type,
CRCタイプ、
BlockData,
ブロックデータ、
? crc-value
？CRC値
]
]
; Payload block type
;ペイロードブロックタイプ
payload-block = payload-block-structure .within canonical-block-structure
payload-block = payload-block-structure。標準ブロック構造
payload-block-structure = [
block-type-code: 1,
ブロックタイプコード：1、
block-number: 1,
ブロック番号：1、
block-control-flags,
ブロックコントロールフラグ
crc-type,
CRCタイプ、
$payload-block-data,
$ payload-block-data、
? crc-value
？CRC値
]
]
; Arbitrary payload data, including non-CBOR byte string
;非CBORバイト文字列を含む任意のペイロードデータ
$payload-block-data /= block-type-specific-data
$ payload-block-data / =ブロック型固有データ
; Administrative record as a payload data specialization
;ペイロードデータの専門化としての管理レコード
$payload-block-data /= embedded-cbor<admin-record>
admin-record = $admin-record .within admin-record-structure
admin-record = $ admin-record .witchin admin-record-structure
admin-record-structure = [
record-type-code: uint,
record-type-code：uint、
record-content: any
record-content：anyです
]
]
; Only one defined record type
;定義されたレコードタイプのみです
$admin-record /= [1, status-record-content]
status-record-content = [
bundle-status-information,
バンドルステータス情報、
status-report-reason-code: uint,
ステータスレポート理由コード：UINT、
source-node-eid: eid,
source-node-eid：EID、
subject-creation-timestamp: creation-timestamp,
subject-creation-timestamp：creation-timestamp、
? (
？）（
subject-payload-offset: uint,
件名 - ペイロードオフセット：UINT、
subject-payload-length: uint
件名 - ペイロード長：uint.
)
）
]
]
bundle-status-information = [
reporting-node-received-bundle: status-info-content,
reporting-node-read-bundle：status-info-content、
reporting-node-forwarded-bundle: status-info-content,
reporting-node-forwarded-bundle：status-info-content、
reporting-node-delivered-bundle: status-info-content,
reporting-node-redual-bundle：status-info-content、
reporting-node-deleted-bundle: status-info-content
reporting-node-deleted-bundle：status-info-content
]
]
status-info-content = [
status-indicator: bool,
ステータスインジケータ：ブール、
? timestamp: dtn-time
？タイムスタンプ：DTN時刻
]
]
; Previous Node extension block
;前のノード拡張ブロック
$extension-block /=
$ extension-block / =
extension-block-use<6, embedded-cbor<ext-data-previous-node>>
ext-data-previous-node = eid
; Bundle Age extension block
;Bundle Age Extensionブロック
$extension-block /=
$ extension-block / =
extension-block-use<7, embedded-cbor<ext-data-bundle-age>>
ext-data-bundle-age = uint
; Hop Count extension block
;ホップカウント拡張ブロック
$extension-block /=
$ extension-block / =
extension-block-use<10, embedded-cbor<ext-data-hop-count>>
ext-data-hop-count = [
hop-limit: uint,
HOP-LIMIT：UINT、
hop-count: uint
ホップ数：uint.
]
]
Acknowledgments
謝辞
This work is freely adapted from RFC 5050, which was an effort of the Delay-Tolerant Networking Research Group. The following DTNRG participants contributed significant technical material and/or inputs to that document: 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 Carnegie Mellon University; Stephen Farrell of Trinity College Dublin; Howard Weiss and Peter Lovell of SPARTA, Inc.; and Manikantan Ramadas of Ohio University.
この作品はRFC 5050から自由に適応されています。これは遅延耐性ネットワーキング研究グループの努力でした。次のDTNRG参加者は、その文書への重要な技術資料や入力を貢献しました.GoogleのVinton CERF博士。ジェット推進実験室のスコット・バーレイ、エイドリアン・フーリー、およびLeigh Torgerson。カリフォルニア大学バークレー校のマイケル・デーマー。Miter CorporationのSusan SysingtonのRobert Durst、Keith Scott、Susan Sysington;カーネギーメロン大学のケビン秋。Trinity College DublinのStephen Farrel。Sparta、Inc。のハワード・ウェイスとピーター・ロバエル。オハイオ大学のマニカンタンラマダス。
Scott Burleigh would like to thank the Jet Propulsion Laboratory, California Institute of Technology, for its generous and sustained support of this work.
Scott Burleighは、カリフォルニア工科大学のJet Propulation Laboratoryに、その寛大で持続的なこの作品の支持を支持してくれたいと思います。
Authors' Addresses
著者の住所
Scott Burleigh IPNGROUP 1435 Woodhurst Blvd. McLean, VA 22102 United States of America
Scott Burleigh IpnGroup 1435 Woodhurst Blvd.McLean、VA 22102アメリカ合衆国
Email: sburleig.sb@gmail.com
Kevin Fall Roland Computing Services 3871 Piedmont Ave. Suite 8 Oakland, CA 94611 United States of America
Kevin Fall Roland Computing Services 3871 Piedmont Ave。Suite 8 Oakland、CA 94611アメリカ合衆国
Email: kfall+rcs@kfall.com
Edward J. Birrane, III Johns Hopkins University Applied Physics Laboratory 11100 Johns Hopkins Rd Laurel, MD 20723 United States of America
Edward J. Birrane、III Johns Hopkins University Physics Laboratory 11100 Johns Hopkins RD Laurel、MD 20723アメリカ
Phone: +1 443 778 7423
Email: Edward.Birrane@jhuapl.edu