[要約] RFC 4838は、遅延に寛容なネットワーキングアーキテクチャに関するものであり、遅延や接続の不安定な環境での通信を可能にするためのガイドラインを提供しています。このRFCの目的は、ネットワークの信頼性と可用性を向上させ、非常に制約のあるネットワーク環境での通信をサポートすることです。
Network Working Group V. Cerf
Request for Comments: 4838 Google/Jet Propulsion Laboratory
Category: Informational S. Burleigh
A. Hooke
L. Torgerson
NASA/Jet Propulsion Laboratory
R. Durst
K. Scott
The MITRE Corporation
K. Fall
Intel Corporation
H. Weiss
SPARTA, Inc.
April 2007
Delay-Tolerant Networking Architecture
遅延耐性のあるネットワークアーキテクチャ
Status of This Memo
本文書の状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も規定していません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
Copyright（C）IETF Trust（2007）。
IESG Note
IESG Note
This RFC is a product of the Internet Research Task Force and is not a candidate for any level of Internet Standard. The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment on the public Internet.
このRFCはInternet Research Task Forceの製品であり、インターネット標準のレベルの候補ではありません。 IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、パブリックインターネットでの展開には適さない場合があります。
Abstract
概要
This document describes an architecture for delay-tolerant and disruption-tolerant networks, and is an evolution of the architecture originally designed for the Interplanetary Internet, a communication system envisioned to provide Internet-like services across interplanetary distances in support of deep space exploration. This document describes an architecture that addresses a variety of problems with internetworks having operational and performance characteristics that make conventional (Internet-like) networking approaches either unworkable or impractical. We define a message-oriented overlay that exists above the transport (or other) layers of the networks it interconnects. The document presents a motivation for the architecture, an architectural overview, review of state management required for its operation, and a discussion of application design issues. This document represents the consensus of the IRTF DTN research group and has been widely reviewed by that group.
このドキュメントでは、遅延耐性と中断耐性のあるネットワークのアーキテクチャについて説明します。これは、惑星間距離を越えてインターネットのようなサービスを提供し、深宇宙探査をサポートする通信システムである惑星間インターネット用に最初に設計されたアーキテクチャの進化形です。このドキュメントでは、従来の（インターネットのような）ネットワーキングアプローチを実行不可能または非実用的なものにする運用上およびパフォーマンス上の特性を持つインターネットワークのさまざまな問題に対処するアーキテクチャについて説明します。相互接続するネットワークのトランスポート（または他の）レイヤーの上に存在するメッセージ指向のオーバーレイを定義します。このドキュメントでは、アーキテクチャの動機、アーキテクチャの概要、操作に必要な状態管理のレビュー、アプリケーション設計の問題について説明します。この文書はIRTF DTN研究グループの合意を表し、そのグループによって広くレビューされています。
Table of Contents
目次
1. Introduction ....................................................3
2. Why an Architecture for Delay-Tolerant Networking? ..............4
3. DTN Architectural Description ...................................5
3.1. Virtual Message Switching Using Store-and-Forward
Operation ..................................................5
3.2. Nodes and Endpoints ........................................7
3.3. Endpoint Identifiers (EIDs) and Registrations ..............8
3.4. Anycast and Multicast .....................................10
3.5. Priority Classes ..........................................10
3.6. Postal-Style Delivery Options and Administrative Records ..11
3.7. Primary Bundle Fields .....................................15
3.8. Routing and Forwarding ....................................16
3.9. Fragmentation and Reassembly ..............................18
3.10. Reliability and Custody Transfer .........................19
3.11. DTN Support for Proxies and Application Layer Gateways ...21
3.12. Timestamps and Time Synchronization ......................22
3.13. Congestion and Flow Control at the Bundle Layer ..........22
3.14. Security .................................................23
4. State Management Considerations ................................25
4.1. Application Registration State ............................25
4.2. Custody Transfer State ....................................26
4.3. Bundle Routing and Forwarding State .......................26
4.4. Security-Related State ....................................27
4.5. Policy and Configuration State ............................27
5. Application Structuring Issues .................................28
6. Convergence Layer Considerations for Use of Underlying
Protocols ......................................................28
7. Summary ........................................................29
8. Security Considerations ........................................29
9. IANA Considerations ............................................30
10. Normative References ..........................................30
11. Informative References ........................................30
12. Acknowledgments ...............................................32
This document describes an architecture for delay and disruption-tolerant interoperable networking (DTN). The architecture embraces the concepts of occasionally-connected networks that may suffer from frequent partitions and that may be comprised of more than one divergent set of protocols or protocol families. The basis for this architecture lies with that of the Interplanetary Internet, which focused primarily on the issue of deep space communication in high-delay environments. We expect the DTN architecture described here to be utilized in various operational environments, including those subject to disruption and disconnection and those with high-delay; the case of deep space is one specialized example of these, and is being pursued as a specialization of this architecture (See [IPN01] and [SB03] for more details).
このドキュメントでは、遅延および中断耐性のある相互運用可能なネットワーク（DTN）のアーキテクチャについて説明します。このアーキテクチャは、頻繁にパーティション分割される可能性があり、複数の異なるプロトコルまたはプロトコルファミリの異なるセットで構成される可能性がある、時々接続されるネットワークの概念を採用しています。このアーキテクチャの基礎は、惑星間インターネットの基盤にあります。惑星間インターネットは、主に高遅延環境での深宇宙通信の問題に焦点を当てていました。ここで説明するDTNアーキテクチャは、中断や切断の影響を受けやすい環境や遅延が大きい環境など、さまざまな運用環境で利用されることが期待されます。深宇宙の場合は、これらの特殊な例の1つであり、このアーキテクチャの特殊化として追求されています（詳細については、[IPN01]および[SB03]を参照してください）。
Other networks to which we believe this architecture applies include sensor-based networks using scheduled intermittent connectivity, terrestrial wireless networks that cannot ordinarily maintain end-to-end connectivity, satellite networks with moderate delays and periodic connectivity, and underwater acoustic networks with moderate delays and frequent interruptions due to environmental factors. A DTN tutorial [FW03], aimed at introducing DTN and the types of networks for which it is designed, is available to introduce new readers to the fundamental concepts and motivation. More technical descriptions may be found in [KF03], [JFP04], [JDPF05], and [WJMF05].
このアーキテクチャが適用されると私たちが信じている他のネットワークには、スケジュールされた断続的な接続を使用するセンサーベースのネットワーク、通常はエンドツーエンドの接続を維持できない地上無線ネットワーク、適度な遅延と定期的な接続を備えた衛星ネットワーク、および適度な遅延を備えた水中音響ネットワークと環境要因による頻繁な中断。 DTNおよびそれが設計されているネットワークのタイプを紹介することを目的としたDTNチュートリアル[FW03]は、新しい読者に基本的な概念と動機を紹介するために利用できます。 [KF03]、[JFP04]、[JDPF05]、および[WJMF05]に、より技術的な説明があります。
We define an end-to-end message-oriented overlay called the "bundle layer" that exists at a layer above the transport (or other) layers of the networks on which it is hosted and below applications. Devices implementing the bundle layer are called DTN nodes. The bundle layer forms an overlay that employs persistent storage to help combat network interruption. It includes a hop-by-hop transfer of reliable delivery responsibility and optional end-to-end acknowledgement. It also includes a number of diagnostic and management features. For interoperability, it uses a flexible naming scheme (based on Uniform Resource Identifiers [RFC3986]) capable of encapsulating different naming and addressing schemes in the same overall naming syntax. It also has a basic security model, optionally enabled, aimed at protecting infrastructure from unauthorized use.
「バンドルレイヤー」と呼ばれるエンドツーエンドのメッセージ指向のオーバーレイを定義します。これは、ホストされるネットワークのトランスポート（または他の）レイヤーの上のレイヤーとアプリケーションの下のレイヤーに存在します。バンドル層を実装するデバイスは、DTNノードと呼ばれます。バンドルレイヤは、永続的なストレージを使用してネットワークの中断との戦いを支援するオーバーレイを形成します。これには、信頼できる配信責任のホップバイホップ転送と、オプションのエンドツーエンドの確認応答が含まれます。また、多数の診断および管理機能も含まれています。相互運用性のために、同じ全体的な命名構文でさまざまな命名およびアドレス指定スキームをカプセル化できる柔軟な命名スキーム（Uniform Resource Identifiers [RFC3986]に基づく）を使用します。また、インフラストラクチャを不正使用から保護することを目的とした、オプションで有効になっている基本的なセキュリティモデルもあります。
The bundle layer provides functionality similar to the internet layer of gateways described in the original ARPANET/Internet designs [CK74]. It differs from ARPANET gateways, however, because it is layer-agnostic and is focused on virtual message forwarding rather than packet switching. However, both generally provide interoperability between underlying protocols specific to one environment and those protocols specific to another, and both provide a store-and-forward forwarding service (with the bundle layer employing persistent storage for its store and forward function).
バンドル層は、元のARPANET /インターネット設計[CK74]で説明されているゲートウェイのインターネット層と同様の機能を提供します。ただし、ARPANETゲートウェイとは異なります。これは、レイヤーにとらわれず、パケット交換ではなく仮想メッセージ転送に重点を置いているためです。ただし、どちらも一般に、ある環境に固有の基本プロトコルと別の環境に固有のプロトコル間の相互運用性を提供し、ストアアンドフォワード転送サービスを提供します（バンドルレイヤーは、ストアアンドフォワード機能に永続ストレージを採用しています）。
In a sense, the DTN architecture provides a common method for interconnecting heterogeneous gateways or proxies that employ store-and-forward message routing to overcome communication disruptions. It provides services similar to electronic mail, but with enhanced naming, routing, and security capabilities. Nodes unable to support the full capabilities required by this architecture may be supported by application-layer proxies acting as DTN applications.
ある意味では、DTNアーキテクチャは、ストアアンドフォワードメッセージルーティングを使用して異種のゲートウェイまたはプロキシを相互接続し、通信の中断を克服するための一般的な方法を提供します。電子メールと同様のサービスを提供しますが、ネーミング、ルーティング、およびセキュリティ機能が強化されています。このアーキテクチャに必要なすべての機能をサポートできないノードは、DTNアプリケーションとして機能するアプリケーション層プロキシによってサポートされる場合があります。
Our motivation for pursuing an architecture for delay tolerant networking stems from several factors. These factors are summarized below; much more detail on their rationale can be explored in [SB03], [KF03], and [DFS02].
遅延耐性のあるネットワーキングのアーキテクチャを追求する動機は、いくつかの要因に由来します。これらの要因を以下にまとめます。それらの理論的根拠に関する詳細は、[SB03]、[KF03]、および[DFS02]で調べることができます。
The existing Internet protocols do not work well for some environments, due to some fundamental assumptions built into the Internet architecture:
既存のインターネットプロトコルは、インターネットアーキテクチャに組み込まれているいくつかの基本的な仮定により、一部の環境ではうまく機能しません。
- that an end-to-end path between source and destination exists for the duration of a communication session
- 通信セッションの間、送信元と宛先の間のエンドツーエンドパスが存在すること
- (for reliable communication) that retransmissions based on timely and stable feedback from data receivers is an effective means for repairing errors
- （信頼できる通信のために）データ受信者からのタイムリーで安定したフィードバックに基づく再送信は、エラーを修復するための有効な手段です
- that end-to-end loss is relatively small
- エンドツーエンドの損失は比較的小さい
- that all routers and end stations support the TCP/IP protocols
- すべてのルーターと端末がTCP / IPプロトコルをサポートしていること
- that applications need not worry about communication performance
- アプリケーションが通信パフォーマンスを気にする必要がないこと
- that endpoint-based security mechanisms are sufficient for meeting most security concerns
- エンドポイントベースのセキュリティメカニズムは、ほとんどのセキュリティ上の懸念を満たすのに十分であること
- that packet switching is the most appropriate abstraction for interoperability and performance
- パケット交換は相互運用性とパフォーマンスのための最も適切な抽象化です
- that selecting a single route between sender and receiver is sufficient for achieving acceptable communication performance
- 許容できる通信パフォーマンスを達成するには、送信者と受信者の間の単一のルートを選択するだけで十分であること
The DTN architecture is conceived to relax most of these assumptions, based on a number of design principles that are summarized here (and further discussed in [KF03]):
DTNアーキテクチャーは、ここに要約されている（さらに[KF03]でさらに説明されている）いくつかの設計原則に基づいて、これらの仮定のほとんどを緩和するように考えられています。
- Use variable-length (possibly long) messages (not streams or limited-sized packets) as the communication abstraction to help enhance the ability of the network to make good scheduling/path selection decisions when possible.
- 通信の抽象化として可変長（おそらく長い）メッセージ（ストリームや制限されたサイズのパケットではない）を使用して、可能な場合に適切なスケジューリング/パス選択の決定を行うネットワークの機能を強化します。
- Use a naming syntax that supports a wide range of naming and addressing conventions to enhance interoperability.
- 相互運用性を高めるために、幅広い命名規則とアドレス指定規則をサポートする命名構文を使用してください。
- Use storage within the network to support store-and-forward operation over multiple paths, and over potentially long timescales (i.e., to support operation in environments where many and/or no end-to-end paths may ever exist); do not require end-to-end reliability.
- ネットワーク内のストレージを使用して、複数のパスおよび潜在的に長いタイムスケールでのストアアンドフォワード操作をサポートします（つまり、エンドツーエンドパスが多数存在する、または存在しない可能性がある環境での操作をサポートします）。エンドツーエンドの信頼性は必要ありません。
- Provide security mechanisms that protect the infrastructure from unauthorized use by discarding traffic as quickly as possible.
- トラフィックをできるだけ早く破棄することにより、インフラストラクチャを不正使用から保護するセキュリティメカニズムを提供します。
- Provide coarse-grained classes of service, delivery options, and a way to express the useful lifetime of data to allow the network to better deliver data in serving the needs of applications.
- 粗粒度のサービスクラス、配信オプション、およびデータの有効期間を表現して、ネットワークがアプリケーションのニーズに応えてデータをより適切に配信できるようにする方法を提供します。
The use of the bundle layer is guided not only by its own design principles, but also by a few application design principles:
バンドルレイヤーの使用は、独自の設計原則だけでなく、いくつかのアプリケーション設計原則にも基づいています。
- Applications should minimize the number of round-trip exchanges.
- アプリケーションでは、往復交換の数を最小限に抑える必要があります。
- Applications should cope with restarts after failure while network transactions remain pending.
- ネットワークトランザクションが保留されている間、アプリケーションは障害後の再起動に対処する必要があります。
- Applications should inform the network of the useful life and relative importance of data to be delivered.
- アプリケーションは、配信されるデータの耐用年数と相対的な重要性をネットワークに通知する必要があります。
These issues are discussed in further detail in Section 5.
これらの問題については、セクション5で詳しく説明します。
The previous section summarized the design principles that guide the definition of the DTN architecture. This section presents a description of the major features of the architecture resulting from design decisions guided by the aforementioned design principles.
前のセクションでは、DTNアーキテクチャの定義を導く設計原則をまとめました。このセクションでは、前述の設計原則に基づいて設計を決定した結果として得られたアーキテクチャの主な機能について説明します。
A DTN-enabled application sends messages of arbitrary length, also called Application Data Units or ADUs [CT90], which are subject to any implementation limitations. The relative order of ADUs might not be preserved. ADUs are typically sent by and delivered to applications in complete units, although a system interface that behaves differently is not precluded.
DTN対応のアプリケーションは、任意の長さのメッセージを送信します。これは、アプリケーションデータユニットまたはADU [CT90]とも呼ばれ、実装上の制限があります。 ADUの相対的な順序は保持されない場合があります。 ADUは通常、アプリケーションによって完全な単位で送信および配信されますが、動作が異なるシステムインターフェイスは除外されません。
ADUs are transformed by the bundle layer into one or more protocol data units called "bundles", which are forwarded by DTN nodes. Bundles have a defined format containing two or more "blocks" of data. Each block may contain either application data or other information used to deliver the containing bundle to its destination(s). Blocks serve the purpose of holding information typically found in the header or payload portion of protocol data units in other protocol architectures. The term "block" is used instead of "header" because blocks may not appear at the beginning of a bundle due to particular processing requirements (e.g., digital signatures).
ADUは、バンドルレイヤーによって「バンドル」と呼ばれる1つ以上のプロトコルデータユニットに変換され、DTNノードによって転送されます。バンドルには、2つ以上の「ブロック」のデータを含む定義済みのフォーマットがあります。各ブロックには、含まれているバンドルを宛先に配信するために使用されるアプリケーションデータまたはその他の情報が含まれます。ブロックは、他のプロトコルアーキテクチャのプロトコルデータユニットのヘッダーまたはペイロード部分に通常見られる情報を保持する目的を果たします。特定の処理要件（デジタル署名など）のためにバンドルの先頭にブロックが表示されない場合があるため、「ヘッダー」の代わりに「ブロック」という用語が使用されます。
Bundles may be split up ("fragmented") into multiple constituent bundles (also called "fragments" or "bundle fragments") during transmission. Fragments are themselves bundles, and may be further fragmented. Two or more fragments may be reassembled anywhere in the network, forming a new bundle.
バンドルは、送信中に複数の構成バンドル（「フラグメント」または「バンドルフラグメント」とも呼ばれる）に分割（「フラグメント化」）される場合があります。フラグメントはそれ自体がバンドルであり、さらにフラグメント化される場合があります。 2つ以上のフラグメントがネットワーク内の任意の場所で再構成され、新しいバンドルが形成されます。
Bundle sources and destinations are identified by (variable-length) Endpoint Identifiers (EIDs, described below), which identify the original sender and final destination(s) of bundles, respectively. Bundles also contain a "report-to" EID used when special operations are requested to direct diagnostic output to an arbitrary entity (e.g., other than the source). An EID may refer to one or more DTN nodes (i.e., for multicast destinations or "report-to" destinations).
バンドルの送信元と宛先は、バンドルの元の送信者と最終的な宛先をそれぞれ識別する（可変長）エンドポイント識別子（以下で説明するEID）によって識別されます。バンドルには、診断出力を任意のエンティティ（ソース以外）に送信するように特別な操作が要求されたときに使用される「レポート先」EIDも含まれています。 EIDは、1つ以上のDTNノードを参照する場合があります（つまり、マルチキャスト宛先または「レポート先」宛先の場合）。
While IP networks are based on "store-and-forward" operation, there is an assumption that the "storing" will not persist for more than a modest amount of time, on the order of the queuing and transmission delay. In contrast, the DTN architecture does not expect that network links are always available or reliable, and instead expects that nodes may choose to store bundles for some time. We anticipate that most DTN nodes will use some form of persistent storage for this -- disk, flash memory, etc. -- and that stored bundles will survive system restarts.
IPネットワークは「ストアアンドフォワード」操作に基づいていますが、「保管」は、キューイングと伝送の遅延の順に、適度な時間を超えて存続しないという前提があります。対照的に、DTNアーキテクチャでは、ネットワークリンクが常に利用可能または信頼できるとは想定されておらず、ノードがしばらくの間バンドルを格納することを選択できると想定しています。ほとんどのDTNノードはこのために何らかの形式の永続ストレージ（ディスク、フラッシュメモリなど）を使用し、保存されたバンドルはシステムの再起動後も存続すると予想されます。
Bundles contain an originating timestamp, useful life indicator, a class of service designator, and a length. This information provides bundle-layer routing with a priori knowledge of the size and performance requirements of requested data transfers. When there is a significant amount of queuing that can occur in the network (as is the case in the DTN version of store-and-forward), the advantage provided by knowing this information may be significant for making scheduling and path selection decisions [JFP04]. An alternative abstraction (i.e., of stream-based delivery based on packets) would make such scheduling much more difficult. Although packets provide some of the same benefits as bundles, larger aggregates provide a way for the network to apply scheduling and buffer management to units of data that are more useful to applications.
バンドルには、元のタイムスタンプ、耐用年数インジケータ、サービスクラス指定子、および長さが含まれています。この情報は、要求されたデータ転送のサイズとパフォーマンス要件に関するアプリオリな知識を備えたバンドル層ルーティングを提供します。ネットワークで発生する可能性のあるかなりの量のキューイングがある場合（ストアアンドフォワードのDTNバージョンの場合のように）、この情報を知ることによって提供される利点は、スケジューリングとパス選択の決定を行うために重要になる場合があります[JFP04 ]。代替の抽象化（つまり、パケットに基づくストリームベースの配信）は、そのようなスケジューリングをはるかに困難にします。パケットはバンドルと同じ利点のいくつかを提供しますが、より大きな集合体は、ネットワークがアプリケーションにとってより有用なデータの単位にスケジューリングとバッファ管理を適用する方法を提供します。
An essential element of the bundle-based style of forwarding is that bundles have a place to wait in a queue until a communication opportunity ("contact") is available. This highlights the following assumptions:
バンドルベースの転送スタイルの重要な要素は、バンドルに、通信機会（「連絡」）が利用可能になるまでキューで待機する場所があることです。これにより、以下の前提が強調されます。
1. that storage is available and well-distributed throughout the network,
1. ストレージが利用可能であり、ネットワーク全体に適切に分散されている
2. that storage is sufficiently persistent and robust to store bundles until forwarding can occur, and
2. ストレージは、転送が発生するまでバンドルを保存するのに十分な持続性と堅牢性がある
3. (implicitly) that this "store-and-forward" model is a better choice than attempting to effect continuous connectivity or other alternatives.
3. （暗黙的に）この「ストアアンドフォワード」モデルは、継続的な接続やその他の代替手段を実現しようとするよりも良い選択です。
For a network to effectively support the DTN architecture, these assumptions must be considered and must be found to hold. Even so, the inclusion of long-term storage as a fundamental aspect of the DTN architecture poses new problems, especially with respect to congestion management and denial-of-service mitigation. Node storage in essence represents a new resource that must be managed and protected. Much of the research in DTN revolves around exploring these issues. Congestion is discussed in Section 3.13, and security mechanisms, including methods for DTN nodes to protect themselves from handling unauthorized traffic from other nodes, are discussed in [DTNSEC] and [DTNSOV].
ネットワークがDTNアーキテクチャを効果的にサポートするためには、これらの前提条件を考慮し、保持することが必要です。それでも、DTNアーキテクチャの基本的な側面として長期ストレージを含めることは、特に輻輳管理とサービス拒否の軽減に関して、新しい問題を引き起こします。本質的にノードストレージは、管理および保護する必要がある新しいリソースを表します。 DTNでの研究の多くは、これらの問題の調査を中心に展開しています。輻輳についてはセクション3.13で説明されており、DTNノードが他のノードからの不正なトラフィックを処理しないように保護する方法などのセキュリティメカニズムについては、[DTNSEC]および[DTNSOV]で説明されています。
A DTN node (or simply "node" in this document) is an engine for sending and receiving bundles -- an implementation of the bundle layer. Applications utilize DTN nodes to send or receive ADUs carried in bundles (applications also use DTN nodes when acting as report-to destinations for diagnostic information carried in bundles). Nodes may be members of groups called "DTN endpoints". A DTN endpoint is therefore a set of DTN nodes. A bundle is considered to have been successfully delivered to a DTN endpoint when some minimum subset of the nodes in the endpoint has received the bundle without error. This subset is called the "minimum reception group" (MRG) of the endpoint. The MRG of an endpoint may refer to one node (unicast), one of a group of nodes (anycast), or all of a group of nodes (multicast and broadcast). A single node may be in the MRG of multiple endpoints.
DTNノード（またはこのドキュメントでは単に「ノード」）は、バンドルを送信および受信するためのエンジンです（バンドルレイヤーの実装）。アプリケーションは、DTNノードを使用して、バンドルで運ばれるADUを送受信します（アプリケーションは、バンドルで運ばれる診断情報のレポート先として機能する場合もDTNノードを使用します）。ノードは、「DTNエンドポイント」と呼ばれるグループのメンバーである場合があります。したがって、DTNエンドポイントは一連のDTNノードです。エンドポイント内のノードのいくつかの最小サブセットがエラーなしでバンドルを受信した場合、バンドルはDTNエンドポイントに正常に配信されたと見なされます。このサブセットは、エンドポイントの「最小受信グループ」（MRG）と呼ばれます。エンドポイントのMRGは、1つのノード（ユニキャスト）、ノードのグループの1つ（エニーキャスト）、またはノードのグループのすべて（マルチキャストとブロードキャスト）を参照できます。単一のノードが複数のエンドポイントのMRGにある場合があります。
An Endpoint Identifier (EID) is a name, expressed using the general syntax of URIs (see below), that identifies a DTN endpoint. Using an EID, a node is able to determine the MRG of the DTN endpoint named by the EID. Each node is also required to have at least one EID that uniquely identifies it.
エンドポイント識別子（EID）は、URIの一般的な構文（以下を参照）を使用して表現される名前で、DTNエンドポイントを識別します。 EIDを使用すると、ノードはEIDで指定されたDTNエンドポイントのMRGを判別できます。各ノードには、それを一意に識別する少なくとも1つのEIDも必要です。
Applications send ADUs destined for an EID, and may arrange for ADUs sent to a particular EID to be delivered to them. Depending on the construction of the EID being used (see below), there may be a provision for wildcarding some portion of an EID, which is often useful for diagnostic and routing purposes.
アプリケーションは、EIDを宛先とするADUを送信し、特定のEIDに送信されるADUがそれらに配信されるように手配する場合があります。使用されているEIDの構造（以下を参照）に応じて、EIDの一部をワイルドカード化するための対策が存在する場合があります。これは、診断やルーティングの目的でしばしば役立ちます。
An application's desire to receive ADUs destined for a particular EID is called a "registration", and in general is maintained persistently by a DTN node. This allows application registration information to survive application and operating system restarts.
特定のEIDを宛先とするADUを受信したいというアプリケーションの要求は「登録」と呼ばれ、一般にDTNノードによって永続的に維持されます。これにより、アプリケーションとオペレーティングシステムの再起動後も、アプリケーション登録情報が保持されます。
An application's attempt to establish a registration is not guaranteed to succeed. For example, an application could request to register itself to receive ADUs by specifying an Endpoint ID that is uninterpretable or unavailable to the DTN node servicing the request. Such requests are likely to fail.
アプリケーションが登録を確立しようとしても、成功する保証はありません。たとえば、アプリケーションは、要求を処理するDTNノードが解釈できない、または使用できないエンドポイントIDを指定することによって、ADUを受信するためにそれ自体を登録するように要求できます。このようなリクエストは失敗する可能性があります。
Each Endpoint ID is expressed syntactically as a Uniform Resource Identifier (URI) [RFC3986]. The URI syntax has been designed as a way to express names or addresses for a wide range of purposes, and is therefore useful for constructing names for DTN endpoints.
各エンドポイントIDは、Uniform Resource Identifier（URI）[RFC3986]として構文的に表現されます。 URI構文は、幅広い目的で名前またはアドレスを表現する方法として設計されているため、DTNエンドポイントの名前を作成するのに役立ちます。
In URI terminology, each URI begins with a scheme name. The scheme name is an element of the set of globally-managed scheme names maintained by IANA [ISCHEMES]. Lexically following the scheme name in a URI is a series of characters constrained by the syntax defined by the scheme. This portion of the URI is called the scheme-specific part (SSP), and can be quite general. (See, as one example, the URI scheme for SNMP [RFC4088]). Note that scheme-specific syntactical and semantic restrictions may be more constraining than the basic rules of RFC 3986. Section 3.1 of RFC 3986 provides guidance on the syntax of scheme names.
URIの用語では、各URIはスキーム名で始まります。スキーム名は、IANA [ISCHEMES]によって維持されるグローバルに管理されたスキーム名のセットの要素です。 URIでスキーマ名の後に語彙的に続くのは、スキーマによって定義された構文によって制約された一連の文字です。 URIのこの部分は、スキーマ固有部分（SSP）と呼ばれ、非常に一般的です。 （一例として、SNMPのURIスキーム[RFC4088]を参照）。スキーム固有の構文上および意味上の制限は、RFC 3986の基本ルールよりも制約が強い場合があることに注意してください。RFC3986のセクション3.1は、スキーム名の構文に関するガイダンスを提供します。
URI schemes are a key concept in the DTN architecture, and evolved from an earlier concept called regions, which were tied more closely to assumptions of the network topology. Using URIs, significant flexibility is attained in the structuring of EIDs. They might, for example, be constructed based on DNS names, or might look like
URIスキームはDTNアーキテクチャーの主要な概念であり、ネットワークトポロジーの仮定により密接に関連付けられていた領域と呼ばれる以前の概念から発展しました。 URIを使用すると、EIDの構造化で大幅な柔軟性が得られます。たとえば、DNS名に基づいて構築されるか、次のようになります。
"expressions of interest" or forms of database-like queries as in a directed diffusion-routed network [IGE00] or in intentional naming [WSBL99]. As names, EIDs are not required to be related to routing or topological organization. Such a relationship is not prohibited, however, and in some environments using EIDs this way may be advantageous.
「関心のある表現」または有向拡散ルーティングネットワーク[IGE00]または意図的な命名[WSBL99]のようなデータベースのようなクエリの形式。名前として、EIDはルーティングやトポロジ構成に関連している必要はありません。ただし、このような関係は禁止されておらず、EIDを使用する環境によっては、この方法が有利な場合があります。
A single EID may refer to an endpoint containing more than one DTN node, as suggested above. It is the responsibility of a scheme designer to define how to interpret the SSP of an EID so as to determine whether it refers to a unicast, multicast, or anycast set of nodes. See Section 3.4 for more details.
上記のように、単一のEIDは複数のDTNノードを含むエンドポイントを参照する場合があります。 EIDのSSPを解釈して、ユニキャスト、マルチキャスト、またはエニーキャストのノードセットを参照するかどうかを決定するのは、スキーマ設計者の責任です。詳細については、セクション3.4を参照してください。
URIs are constructed based on rules specified in RFC 3986, using the US-ASCII character set. However, note this excerpt from RFC 3986, Section 1.2.1, on dealing with characters that cannot be represented by US-ASCII: "Percent-encoded octets (Section 2.1) may be used within a URI to represent characters outside the range of the US-ASCII coded character set if this representation is allowed by the scheme or by the protocol element in which the URI is referenced. Such a definition should specify the character encoding used to map those characters to octets prior to being percent-encoded for the URI".
URIは、US-ASCII文字セットを使用して、RFC 3986で指定されたルールに基づいて構築されます。ただし、US-ASCIIで表現できない文字の扱いに関するRFC 3986のセクション1.2.1からのこの抜粋に注意してください。「URI内でパーセントエンコードオクテット（セクション2.1）を使用して、この表現がスキームまたはURIが参照されるプロトコル要素によって許可されている場合、US-ASCIIコード化文字セット。このような定義では、URIのパーセントエンコードの前に、これらの文字をオクテットにマップするために使用される文字エンコードを指定する必要があります。 」
Binding means interpreting the SSP of an EID for the purpose of carrying an associated message towards a destination. For example, binding might require mapping an EID to a next-hop EID or to a lower-layer address for transmission. "Late binding" means that the binding of a bundle's destination to a particular set of destination identifiers or addresses does not necessarily happen at the bundle source. Because the destination EID is potentially re-interpreted at each hop, the binding may occur at the source, during transit, or possibly at the destination(s). This contrasts with the name-to-address binding of Internet communications where a DNS lookup at the source fixes the IP address of the destination node before data is sent. Such a circumstance would be considered "early binding" because the name-to-address translation is performed prior to data being sent into the network.
バインドとは、関連付けられたメッセージを宛先に運ぶために、EIDのSSPを解釈することを意味します。たとえば、バインディングでは、EIDをネクストホップEIDまたは送信用の下位層アドレスにマッピングする必要がある場合があります。 「遅延バインディング」とは、バンドルの宛先と特定の宛先識別子またはアドレスのセットとのバインディングが、バンドルの送信元で必ずしも発生しないことを意味します。宛先EIDは各ホップで潜在的に再解釈されるため、バインディングは送信元、転送中、または宛先で発生する可能性があります。これは、ソースでのDNSルックアップがデータが送信される前に宛先ノードのIPアドレスを修正するインターネット通信の名前とアドレスのバインディングとは対照的です。データがネットワークに送信される前に名前からアドレスへの変換が実行されるため、このような状況は「早期バインディング」と見なされます。
In a frequently-disconnected network, late binding may be advantageous because the transit time of a message may exceed the validity time of a binding, making binding at the source impossible or invalid. Furthermore, use of name-based routing with late binding may reduce the amount of administrative (mapping) information that must propagate through the network, and may also limit the scope of mapping synchronization requirements to a local topological neighborhood where changes are made.
頻繁に切断されるネットワークでは、メッセージの通過時間がバインディングの有効時間を超え、ソースでのバインディングが不可能または無効になるため、遅延バインディングは有利な場合があります。さらに、レイトバインディングで名前ベースのルーティングを使用すると、ネットワークを介して伝播する必要がある管理（マッピング）情報の量が減り、変更が行われるローカルトポロジーの近隣へのマッピング同期要件の範囲が制限される場合があります。
As mentioned above, an EID may refer to an endpoint containing one or more DTN nodes. When referring to a group of size greater than one, the delivery semantics may be of either the anycast or multicast variety (broadcast is considered to be of the multicast variety). For anycast group delivery, a bundle is delivered to one node among a group of potentially many nodes, and for multicast delivery it is intended to be delivered to all of them, subject to the normal DTN class of service and maximum useful lifetime semantics.
上記のように、EIDは1つ以上のDTNノードを含むエンドポイントを指す場合があります。 1より大きいサイズのグループを参照する場合、配信セマンティクスはエニーキャストまたはマルチキャストのいずれかになります（ブロードキャストはマルチキャストの種類と見なされます）。エニーキャストグループ配信の場合、バンドルは潜在的に多数のノードのグループ内の1つのノードに配信されます。マルチキャスト配信の場合、バンドルはすべてのノードに配信されることを意図しており、通常のDTNサービスクラスと最大の有効期間のセマンティクスが適用されます。
Multicast group delivery in a DTN presents an unfamiliar issue with respect to group membership. In relatively low-delay networks, such as the Internet, nodes may be considered to be part of the group if they have expressed interest to join it "recently". In a DTN, however, nodes may wish to receive data sent to a group during an interval of time earlier than when they are actually able to receive it [ZAZ05]. More precisely, an application expresses its desire to receive data sent to EID e at time t. Prior to this, during the interval [t0, t1], t > t1, data may have been generated for group e. For the application to receive any of this data, the data must be available a potentially long time after senders have ceased sending to the group. Thus, the data may need to be stored within the network in order to support temporal group semantics of this kind. How to design and implement this remains a research issue, as it is likely to be at least as hard as problems related to reliable multicast.
DTNでのマルチキャストグループ配信では、グループメンバーシップに関して見慣れない問題が発生します。インターネットなどの比較的低遅延のネットワークでは、ノードが「最近」参加することに興味を示した場合、そのノードはグループの一部と見なされます。ただし、DTNでは、ノードが実際に受信できる時間よりも早い時間間隔でグループに送信されたデータを受信したい場合があります[ZAZ05]。より正確には、アプリケーションは、時刻tにEID eに送信されたデータを受信したいという希望を表明します。これに先立って、間隔[t0、t1]、t> t1の間、グループeのデータが生成されている可能性があります。アプリケーションがこのデータのいずれかを受信するには、送信者がグループへの送信を停止した後、データが長い間利用可能である必要があります。したがって、この種の一時的なグループセマンティクスをサポートするために、データをネットワーク内に格納する必要がある場合があります。これを設計および実装する方法は、信頼できるマルチキャストに関連する問題と少なくとも同じくらい難しいと思われるため、研究課題のままです。
The DTN architecture offers *relative* measures of priority (low, medium, high) for delivering ADUs. These priorities differentiate traffic based upon an application's desire to affect the delivery urgency for ADUs, and are carried in bundle blocks generated by the bundle layer based on information specified by the application.
DTNアーキテクチャは、ADUを配信するための優先度（低、中、高）の*相対的な*尺度を提供します。これらの優先順位は、ADUの配信の緊急性に影響を与えるアプリケーションの要望に基づいてトラフィックを区別し、アプリケーションによって指定された情報に基づいてバンドルレイヤーによって生成されたバンドルブロックで伝送されます。
The (U.S. or similar) Postal Service provides a strong metaphor for the priority classes offered by the forwarding abstraction offered by the DTN architecture. Traffic is generally not interactive and is often one-way. There are generally no strong guarantees of timely delivery, yet there are some forms of class of service, reliability, and security.
（米国または類似の）郵便サービスは、DTNアーキテクチャによって提供される転送抽象化によって提供される優先クラスの強力な比喩を提供します。トラフィックは一般にインタラクティブではなく、多くの場合片方向です。一般に、タイムリーな配信の強力な保証はありませんが、サービスクラス、信頼性、およびセキュリティにはいくつかの形式があります。
We have defined three relative priority classes to date. These priority classes typically imply some relative scheduling prioritization among bundles in queue at a sender:
これまでに、3つの相対的な優先度クラスを定義しました。これらの優先度クラスは、通常、送信者のキューにあるバンドル間の相対的なスケジューリング優先順位付けを意味します。
- Bulk - Bulk bundles are shipped on a "least effort" basis. No bundles of this class will be shipped until all bundles of other classes bound for the same destination and originating from the same source have been shipped.
- 一括-一括バンドルは「最小限の労力」で発送されます。同じ宛先にバインドされ、同じソースから発信された他のクラスのすべてのバンドルが出荷されるまで、このクラスのバンドルは出荷されません。
- Normal - Normal-class bundles are shipped prior to any bulk-class bundles and are otherwise the same as bulk bundles.
- ノーマル-ノーマルクラスバンドルは、バルククラスバンドルの前に出荷され、それ以外はバルクバンドルと同じです。
- Expedited - Expedited bundles, in general, are shipped prior to bundles of other classes and are otherwise the same.
- Expedited-Expeditedバンドルは、通常、他のクラスのバンドルの前に出荷され、それ以外は同じです。
Applications specify their requested priority class and data lifetime (see below) for each ADU they send. This information, coupled with policy applied at DTN nodes that select how messages are forwarded and which routing algorithms are in use, affects the overall likelihood and timeliness of ADU delivery.
アプリケーションは、送信するADUごとに、要求された優先度クラスとデータの有効期間（下記参照）を指定します。この情報は、メッセージの転送方法と使用されているルーティングアルゴリズムを選択するDTNノードに適用されるポリシーと相まって、ADU配信の全体的な可能性と適時性に影響します。
The priority class of a bundle is only required to relate to other bundles from the same source. This means that a high priority bundle from one source may not be delivered faster (or with some other superior quality of service) than a medium priority bundle from a different source. It does mean that a high priority bundle from one source will be handled preferentially to a lower priority bundle sent from the same source.
バンドルの優先度クラスは、同じソースからの他のバンドルに関連付けるためにのみ必要です。つまり、あるソースからの優先度の高いバンドルは、別のソースからの優先度が中程度のバンドルよりも速く（または他の優れたサービス品質で）配信されない場合があります。つまり、あるソースからの優先度の高いバンドルは、同じソースから送信された優先度の低いバンドルよりも優先的に処理されます。
Depending on a particular DTN node's forwarding/scheduling policy, priority may or may not be enforced across different sources. That is, in some DTN nodes, expedited bundles might always be sent prior to any bulk bundles, irrespective of source. Many variations are possible.
特定のDTNノードの転送/スケジュールポリシーに応じて、優先度は異なるソース間で適用される場合と適用されない場合があります。つまり、一部のDTNノードでは、ソースに関係なく、一括バンドルの前に優先バンドルが常に送信される場合があります。多くのバリエーションが可能です。
Continuing with the postal analogy, the DTN architecture supports several delivery options that may be selected by an application when it requests the transmission of an ADU. In addition, the architecture defines two types of administrative records: "status reports" and "signals". These records are bundles that provide information about the delivery of other bundles, and are used in conjunction with the delivery options.
郵便の類推を続けると、DTNアーキテクチャは、ADUの送信を要求するときにアプリケーションによって選択される可能性があるいくつかの配信オプションをサポートします。さらに、このアーキテクチャでは、「ステータスレポート」と「シグナル」という2種類の管理レコードが定義されています。これらのレコードは、他のバンドルの配信に関する情報を提供するバンドルであり、配信オプションと組み合わせて使用されます。
We have defined eight delivery options. Applications sending an ADU (the "subject ADU") may request any combination of the following, which are carried in each of the bundles produced ("sent bundles") by the bundle layer resulting from the application's request to send the subject ADU:
8つの配信オプションを定義しました。 ADU（「サブジェクトADU」）を送信するアプリケーションは、サブジェクトADUを送信するアプリケーションの要求の結果として、バンドルレイヤーによって生成される（「送信されるバンドル」）バンドルのそれぞれで運ばれる次の任意の組み合わせを要求できます。
- Custody Transfer Requested - requests sent bundles be delivered with enhanced reliability using custody transfer procedures. Sent bundles will be transmitted by the bundle layer using reliable transfer protocols (if available), and the responsibility for reliable delivery of the bundle to its destination(s) may move among one or more "custodians" in the network. This capability is described in more detail in Section 3.10.
- 保管転送要求-バンドル送信された要求は、保管転送手順を使用して、信頼性を高めて配信されます。送信されたバンドルは、信頼できる転送プロトコル（利用可能な場合）を使用してバンドルレイヤーによって送信され、宛先へのバンドルの信頼できる配信の責任は、ネットワーク内の1つ以上の「カストディアン」間で移動する可能性があります。この機能については、セクション3.10で詳しく説明します。
- Source Node Custody Acceptance Required - requires the source DTN node to provide custody transfer for the sent bundles. If custody transfer is not available at the source when this delivery option is requested, the requested transmission fails. This provides a means for applications to insist that the source DTN node take custody of the sent bundles (e.g., by storing them in persistent storage).
- 送信元ノードの管理承認が必要-送信されたバンドルの管理転送を提供するために送信元DTNノードが必要です。この配信オプションが要求されたときにソースでカストディ転送が利用できない場合、要求された送信は失敗します。これは、ソースDTNノードが送信されたバンドルを（たとえば、永続的なストレージに格納することによって）保管することをアプリケーションに要求する手段を提供します。
- Report When Bundle Delivered - requests a (single) Bundle Delivery Status Report be generated when the subject ADU is delivered to its intended recipient(s). This request is also known as "return-receipt".
- バンドル配信時のレポート-対象のADUが目的の受信者に配信されたときに、（単一の）バンドル配信ステータスレポートの生成を要求します。このリクエストは、「return-receipt」とも呼ばれます。
- Report When Bundle Acknowledged by Application - requests an Acknowledgement Status Report be generated when the subject ADU is acknowledged by a receiving application. This only happens by action of the receiving application, and differs from the Bundle Delivery Status Report. It is intended for cases where the application may be acting as a form of application layer gateway and wishes to indicate the status of a protocol operation external to DTN back to the requesting source. See Section 11 for more details.
- バンドルがアプリケーションによって確認されたときのレポート-対象のADUが受信アプリケーションによって確認されたときに、確認ステータスレポートの生成を要求します。これは受信アプリケーションのアクションによってのみ発生し、バンドル配信ステータスレポートとは異なります。これは、アプリケーションがアプリケーション層ゲートウェイの形式として機能している可能性があり、DTNの外部にあるプロトコル操作のステータスを要求元に返したい場合に使用します。詳細については、セクション11を参照してください。
- Report When Bundle Received - requests a Bundle Reception Status Report be generated when each sent bundle arrives at a DTN node. This is designed primarily for diagnostic purposes.
- バンドル受信時のレポート-送信された各バンドルがDTNノードに到着したときに、バンドル受信ステータスレポートの生成を要求します。これは主に診断目的で設計されています。
- Report When Bundle Custody Accepted - requests a Custody Acceptance Status Report be generated when each sent bundle has been accepted using custody transfer. This is designed primarily for diagnostic purposes.
- バンドル保管が受け入れられた場合のレポート-送信された各バンドルが保管転送を使用して受け入れられたときに、保管受け入れ状況レポートの生成を要求します。これは主に診断目的で設計されています。
- Report When Bundle Forwarded - requests a Bundle Forwarding Status Report be generated when each sent bundle departs a DTN node after forwarding. This is designed primarily for diagnostic purposes.
- バンドル転送時のレポート-送信された各バンドルが転送後にDTNノードを出発するときに生成されるバンドル転送ステータスレポートを要求します。これは主に診断目的で設計されています。
- Report When Bundle Deleted - requests a Bundle Deletion Status Report be generated when each sent bundle is deleted at a DTN node. This is designed primarily for diagnostic purposes.
- バンドル削除時のレポート-送信された各バンドルがDTNノードで削除されたときに、バンドル削除ステータスレポートの生成を要求します。これは主に診断目的で設計されています。
The first four delivery options are designed for ordinary use by applications. The last four are designed primarily for diagnostic purposes and their use may be restricted or limited in environments subject to congestion or attack.
最初の4つの配信オプションは、アプリケーションによる通常の使用向けに設計されています。最後の4つは主に診断目的で設計されており、輻輳や攻撃の影響を受ける環境では、その使用が制限または制限される場合があります。
If the security procedures defined in [DTNSEC] are also enabled, then three additional delivery options become available:
[DTNSEC]で定義されたセキュリティ手順も有効になっている場合、3つの追加の配信オプションが利用可能になります。
- Confidentiality Required - requires the subject ADU be made secret from parties other than the source and the members of the destination EID.
- 機密性が必要-送信元と宛先EIDのメンバー以外の関係者から対象のADUを秘密にする必要があります。
- Authentication Required - requires all non-mutable fields in the bundle blocks of the sent bundles (i.e., those which do not change as the bundle is forwarded) be made strongly verifiable (i.e., cryptographically strong). This protects several fields, including the source and destination EIDs and the bundle's data. See Section 3.7 and [BSPEC] for more details.
- 認証が必要-送信されたバンドルのバンドルブロック内のすべての非変更可能フィールド（つまり、バンドルが転送されても変化しないフィールド）を強力に検証可能（つまり、暗号的に強力）にする必要があります。これにより、ソースと宛先のEID、バンドルのデータなど、いくつかのフィールドが保護されます。詳細については、セクション3.7および[BSPEC]を参照してください。
- Error Detection Required - requires modifications to the non-mutable fields of each sent bundle be made detectable with high probability at each destination.
- エラー検出が必要-送信された各バンドルの変更不可能なフィールドを変更して、各宛先で高い確率で検出可能にする必要があります。
3.6.2. Administrative Records: Bundle Status Reports and Custody Signals
3.6.2. 行政記録：バンドルステータスレポートと管理シグナル
Administrative records are used to report status information or error conditions related to the bundle layer. There are two types of administrative records defined: bundle status reports (BSRs) and custody signals. Administrative records correspond (approximately) to messages in the ICMP protocol in IP [RFC792]. In ICMP, however, messages are returned to the source. In DTN, they are instead directed to the report-to EID for BSRs and the EID of the current custodian for custody signals, which might differ from the source's EID. Administrative records are sent as bundles with a source EID set to one of the EIDs associated with the DTN node generating the administrative record. In some cases, arrival of a single bundle or bundle fragment may elicit multiple administrative records (e.g., in the case where a bundle is replicated for multicast forwarding).
管理レコードは、バンドルレイヤーに関連するステータス情報またはエラー状態を報告するために使用されます。定義されている管理レコードには、バンドルステータスレポート（BSR）とカストディシグナルの2つのタイプがあります。管理記録は、IPのICMPプロトコル[RFC792]のメッセージに（ほぼ）対応しています。ただし、ICMPでは、メッセージはソースに返されます。 DTNでは、代わりにBSRのレポート先EIDとカストディ信号の現在のカストディアンのEIDが送信されますが、これはソースのEIDとは異なる場合があります。管理レコードは、管理レコードを生成するDTNノードに関連付けられたEIDのいずれかにソースEIDが設定されたバンドルとして送信されます。場合によっては、単一のバンドルまたはバンドルフラグメントの到着により、複数の管理レコードが引き出されることがあります（たとえば、マルチキャスト転送のためにバンドルが複製される場合）。
The following BSRs are currently defined (also see [BSPEC] for more details):
以下のBSRが現在定義されています（詳細については、[BSPEC]も参照してください）。
- Bundle Reception - sent when a bundle arrives at a DTN node. Generation of this message may be limited by local policy.
- バンドル受信-バンドルがDTNノードに到着したときに送信されます。このメッセージの生成は、ローカルポリシーによって制限される場合があります。
- Custody Acceptance - sent when a node has accepted custody of a bundle with the Custody Transfer Requested option set. Generation of this message may be limited by local policy.
- Custody Acceptance-ノードがCustody Transfer Requestedオプションが設定されたバンドルのカストディを受け入れたときに送信されます。このメッセージの生成は、ローカルポリシーによって制限される場合があります。
- Bundle Forwarded - sent when a bundle containing a Report When Bundle Forwarded option departs from a DTN node after having been forwarded. Generation of this message may be limited by local policy.
- バンドル転送-バンドル転送オプションのレポートを含むバンドルが転送された後、DTNノードから出発したときに送信されます。このメッセージの生成は、ローカルポリシーによって制限される場合があります。
- Bundle Deletion - sent from a DTN node when a bundle containing a Report When Bundle Deleted option is discarded. This can happen for several reasons, such as expiration. Generation of this message may be limited by local policy but is required in cases where the deletion is performed by a bundle's current custodian.
- バンドル削除-バンドル削除時のレポートを含むバンドルが破棄されたときにDTNノードから送信されます。これは、有効期限などのいくつかの理由で発生する可能性があります。このメッセージの生成はローカルポリシーによって制限される場合がありますが、削除がバンドルの現在のカストディアンによって実行される場合に必要です。
- Bundle Delivery - sent from a final recipient's (destination) node when a complete ADU comprising sent bundles containing Report When Bundle Delivered options is consumed by an application.
- Bundle Delivery-Report When Bundle Deliveredオプションを含む送信済みバンドルを含む完全なADUがアプリケーションによって消費されたときに、最終受信者の（宛先）ノードから送信されます。
- Acknowledged by application - sent from a final recipient's (destination) node when a complete ADU comprising sent bundles containing Application Acknowledgment options has been processed by an application. This generally involves specific action on the receiving application's part.
- アプリケーションによる確認-アプリケーション確認オプションを含む送信済みバンドルを含む完全なADUがアプリケーションによって処理されたときに、最終受信者の（宛先）ノードから送信されます。これには通常、受信側アプリケーションの特定のアクションが含まれます。
In addition to the status reports, the custody signal is currently defined to indicate the status of a custody transfer. These are sent to the current-custodian EID contained in an arriving bundle:
ステータスレポートに加えて、カストディ信号は現在、カストディ転送のステータスを示すように定義されています。これらは、到着するバンドルに含まれている現在のカストディアンEIDに送信されます。
- Custody Signal - indicates that custody has been successfully transferred. This signal appears as a Boolean indicator, and may therefore indicate either a successful or a failed custody transfer attempt.
- 保管信号-保管が正常に転送されたことを示します。この信号はブールインジケータとして表示されるため、カストディ転送の成功または失敗を示します。
Administrative records must reference a received bundle. This is accomplished by a method for uniquely identifying bundles based on a transmission timestamp and sequence number discussed in Section 3.12.
管理記録は、受信したバンドルを参照する必要があります。これは、セクション3.12で説明した送信タイムスタンプとシーケンス番号に基づいてバンドルを一意に識別する方法によって実現されます。
The bundles carried between and among DTN nodes obey a standard bundle protocol specified in [BSPEC]. Here we provide an overview of most of the fields carried with every bundle. The protocol is designed with a mandatory primary block, an optional payload block (which contains the ADU data itself), and a set of optional extension blocks. Blocks may be cascaded in a way similar to extension headers in IPv6. The following selected fields are all present in the primary block, and therefore are present for every bundle and fragment:
DTNノード間で送信されるバンドルは、[BSPEC]で指定された標準バンドルプロトコルに従います。ここでは、すべてのバンドルに含まれるほとんどのフィールドの概要を示します。プロトコルは、必須のプライマリブロック、オプションのペイロードブロック（ADUデータ自体を含む）、およびオプションの拡張ブロックのセットで設計されています。ブロックは、IPv6の拡張ヘッダーと同様の方法でカスケードできます。次の選択されたフィールドはすべてプライマリブロックに存在するため、すべてのバンドルおよびフラグメントに存在します。
- Creation Timestamp - a concatenation of the bundle's creation time and a monotonically increasing sequence number such that the creation timestamp is guaranteed to be unique for each ADU originating from the same source. The creation timestamp is based on the time-of-day an application requested an ADU to be sent (not when the corresponding bundle(s) are sent into the network). DTN nodes are assumed to have a basic time synchronization capability (see Section 3.12).
- 作成タイムスタンプ-バンドルの作成時間と単調に増加するシーケンス番号の連結。作成タイムスタンプは、同じソースから発信された各ADUで一意であることが保証されます。作成タイムスタンプは、アプリケーションがADUの送信を要求した時刻に基づいています（対応するバンドルがネットワークに送信されたときではありません）。 DTNノードは、基本的な時刻同期機能を備えていると想定されています（セクション3.12を参照）。
- Lifespan - the time-of-day at which the message is no longer useful. If a bundle is stored in the network (including the source's DTN node) when its lifespan is reached, it may be discarded. The lifespan of a bundle is expressed as an offset relative to its creation time.
- 寿命-メッセージが不要になった時刻。バンドルがその寿命に達したときにネットワーク（送信元のDTNノードを含む）に保存されている場合、そのバンドルは破棄される可能性があります。バンドルの寿命は、その作成時間に対するオフセットとして表されます。
- Class of Service Flags - indicates the delivery options and priority class for the bundle. Priority classes may be one of bulk, normal, or expedited. See Section 3.6.1.
- サービスクラスフラグ-バンドルの配信オプションと優先度クラスを示します。優先度クラスは、一括、通常、または優先のいずれかです。セクション3.6.1を参照してください。
- Source EID - EID of the source (the first sender).
- ソースEID-ソース（最初の送信者）のEID。
- Destination EID - EID of the destination (the final intended recipient(s)).
- 宛先EID-宛先のEID（最終的に意図された受信者）。
- Report-To Endpoint ID - an EID identifying where reports (return-receipt, route-tracing functions) should be sent. This may or may not identify the same endpoint as the Source EID.
- レポートからエンドポイントへのID-レポート（リターンレシート、ルートトレース機能）の送信先を識別するEID。これは、ソースEIDと同じエンドポイントを識別する場合と識別しない場合があります。
- Custodian EID - EID of the current custodian of a bundle (if any).
- カストディアンEID-バンドルの現在のカストディアンのEID（存在する場合）。
The payload block indicates information about the contained payload (e.g., its length) and the payload itself. In addition to the fields found in the primary and payload blocks, each bundle may have fields in additional blocks carried with each bundle. See [BSPEC] for additional details.
ペイロードブロックは、含まれているペイロード（たとえば、その長さ）とペイロード自体に関する情報を示します。プライマリブロックとペイロードブロックにあるフィールドに加えて、各バンドルには、各バンドルに含まれる追加ブロックのフィールドがあります。詳細については、[BSPEC]を参照してください。
The DTN architecture provides a framework for routing and forwarding at the bundle layer for unicast, anycast, and multicast messages. Because nodes in a DTN network might be interconnected using more than one type of underlying network technology, a DTN network is best described abstractly using a *multigraph* (a graph where vertices may be interconnected with more than one edge). Edges in this graph are, in general, time-varying with respect to their delay and capacity and directional because of the possibility of one-way connectivity. When an edge has zero capacity, it is considered to not be connected.
DTNアーキテクチャは、ユニキャスト、エニーキャスト、およびマルチキャストメッセージのバンドルレイヤーでルーティングおよび転送するためのフレームワークを提供します。 DTNネットワーク内のノードは、複数のタイプの基盤となるネットワークテクノロジーを使用して相互接続される可能性があるため、DTNネットワークは、*マルチグラフ*（頂点が複数のエッジと相互接続されている可能性があるグラフ）を使用して抽象的に説明するのが最適です。このグラフのエッジは、一方向の接続の可能性があるため、一般に、遅延と容量、および方向に関して時間によって変化します。エッジの容量がゼロの場合、そのエッジは接続されていないと見なされます。
Because edges in a DTN graph may have significant delay, it is important to distinguish where time is measured when expressing an edge's capacity or delay. We adopt the convention of expressing capacity and delay as functions of time where time is measured at the point where data is inserted into a network edge. For example, consider an edge having capacity C(t) and delay D(t) at time t. If B bits are placed in this edge at time t, they completely arrive by time t + D(t) + (1/C(t))*B. We assume C(t) and D(t) do not change significantly during the interval [t, t+D(t)+(1/C(t))*B].
DTNグラフのエッジにはかなりの遅延がある可能性があるため、エッジの容量または遅延を表すときに、時間を測定する場所を区別することが重要です。ネットワークエッジにデータが挿入された時点で時間が測定される時間の関数として、容量と遅延を表すという慣例を採用しています。たとえば、時間tで容量C（t）と遅延D（t）を持つエッジを考えます。 Bビットが時間tでこのエッジに配置される場合、時間t + D（t）+（1 / C（t））* Bまでに完全に到着します。 C（t）とD（t）は、間隔[t、t + D（t）+（1 / C（t））* B]の間、大幅に変化しないと仮定します。
Because edges may vary between positive and zero capacity, it is possible to describe a period of time (interval) during which the capacity is strictly positive, and the delay and capacity can be considered to be constant [AF03]. This period of time is called a "contact". In addition, the product of the capacity and the interval is known as a contact's "volume". If contacts and their volumes are known ahead of time, intelligent routing and forwarding decisions can be made (optimally for small networks) [JFP04]. Optimally using a contact's volume, however, requires the ability to divide large ADUs and bundles into smaller routable units. This is provided by DTN fragmentation (see Section 3.9).
エッジは正とゼロの容量の間で変化する可能性があるため、容量が厳密に正である期間（間隔）を記述することが可能であり、遅延と容量は一定であると見なすことができます[AF03]。この期間は「連絡先」と呼ばれます。また、容量と間隔の積は、連絡先の「ボリューム」と呼ばれます。連絡先とそのボリュームが事前にわかっている場合、インテリジェントなルーティングと転送の決定を行うことができます（小規模なネットワークに最適）[JFP04]。ただし、連絡先のボリュームを最適に使用するには、大きなADUとバンドルを小さなルーティング可能なユニットに分割する機能が必要です。これは、DTNフラグメンテーションによって提供されます（セクション3.9を参照）。
When delivery paths through a DTN graph are lossy or contact intervals and volumes are not known precisely ahead of time, routing computations become especially challenging. How to handle these situations is an active area of work in the (emerging) research area of delay tolerant networking.
DTNグラフを介した配信パスに損失または接触間隔があり、ボリュームが事前に正確にわからない場合、ルーティングの計算は特に困難になります。これらの状況をどのように処理するかは、遅延耐性のあるネットワーキングの（新興の）研究領域における活発な作業領域です。
Contacts typically fall into one of several categories, based largely on the predictability of their performance characteristics and whether some action is required to bring them into existence. To date, the following major types of contacts have been defined: Persistent Contacts
連絡先は通常、主にそのパフォーマンス特性の予測可能性と、それらを実現するために何らかのアクションが必要かどうかに基づいて、いくつかのカテゴリのいずれかに分類されます。これまでに、次の主要なタイプの連絡先が定義されています。
Persistent contacts are always available (i.e., no connection-initiation action is required to instantiate a persistent contact). An 'always-on' Internet connection such as a DSL or Cable Modem connection would be a representative of this class.
永続的な連絡先は常に利用可能です（つまり、永続的な連絡先をインスタンス化するために接続開始アクションは必要ありません）。 DSLやケーブルモデム接続などの「常時接続」インターネット接続は、このクラスの代表です。
On-Demand Contacts
オンデマンド連絡先
On-Demand contacts require some action in order to instantiate, but then function as persistent contacts until terminated. A dial-up connection is an example of an On-Demand contact (at least, from the viewpoint of the dialer; it may be viewed as an Opportunistic Contact, below, from the viewpoint of the dial-up service provider).
オンデマンドの連絡先は、インスタンス化するために何らかのアクションを必要としますが、終了するまで永続的な連絡先として機能します。ダイヤルアップ接続は、オンデマンド連絡先の例です（少なくとも、ダイヤラの観点からは、ダイヤルアップサービスプロバイダの観点からは、便宜的連絡先と見なすことができます）。
Intermittent - Scheduled Contacts
断続的-予定された連絡先
A scheduled contact is an agreement to establish a contact at a particular time, for a particular duration. An example of a scheduled contact is a link with a low-earth orbiting satellite. A node's list of contacts with the satellite can be constructed from the satellite's schedule of view times, capacities, and latencies. Note that for networks with substantial delays, the notion of the "particular time" is delay-dependent. For example, a single scheduled contact between Earth and Mars would not be at the same instant in each location, but would instead be offset by the (non-negligible) propagation delay.
予定された連絡先とは、特定の時間に特定の時間に連絡先を確立するための合意です。予定された連絡先の例は、低地球周回衛星とのリンクです。衛星とのノードの連絡先リストは、衛星の表示時間、容量、および待機時間のスケジュールから作成できます。大幅な遅延のあるネットワークの場合、「特定の時間」の概念は遅延に依存することに注意してください。たとえば、地球と火星間の1つの予定された接触は、各場所で同時には発生しませんが、代わりに（無視できない）伝播遅延によってオフセットされます。
Intermittent - Opportunistic Contacts
断続的-日和見的な連絡先
Opportunistic contacts are not scheduled, but rather present themselves unexpectedly. For example, an unscheduled aircraft flying overhead and beaconing, advertising its availability for communication, would present an opportunistic contact. Another type of opportunistic contact might be via an infrared or Bluetooth communication link between a personal digital assistant (PDA) and a kiosk in an airport concourse. The opportunistic contact begins as the PDA is brought near the kiosk, lasting an undetermined amount of time (i.e., until the link is lost or terminated).
日和見的な連絡先は予定されていませんが、予想外に現れます。たとえば、予定外の航空機が頭上を飛行してビーコンを発し、通信可能であることを宣伝すると、日和見的な接触が生じます。別のタイプの日和見的接触は、携帯電話のデジタルアシスタント（PDA）と空港のコンコース内のキオスクとの間の赤外線またはBluetooth通信リンクを経由する場合があります。日和見的な接触は、PDAがキオスクに近づくと始まり、不確定な時間（つまり、リンクが失われるか終了するまで）続きます。
Intermittent - Predicted Contacts
断続的-予測される連絡先
Predicted contacts are based on no fixed schedule, but rather are predictions of likely contact times and durations based on a history of previously observed contacts or some other information. Given a great enough confidence in a predicted contact, routes may be chosen based on this information. This is an active research area, and a few approaches having been proposed [LFC05].
予測される連絡先は、固定されたスケジュールに基づいていませんが、以前に観察された連絡先の履歴または他の情報に基づいて、可能性のある連絡時間と期間の予測です。予測される連絡先に十分な信頼性がある場合、この情報に基づいてルートを選択できます。これは活発な研究分野であり、いくつかのアプローチが提案されています[LFC05]。
DTN fragmentation and reassembly are designed to improve the efficiency of bundle transfers by ensuring that contact volumes are fully utilized and by avoiding retransmission of partially-forwarded bundles. There are two forms of DTN fragmentation/reassembly:
DTNの断片化と再構成は、コンタクトボリュームが完全に利用されるようにし、部分的に転送されたバンドルの再送信を回避することにより、バンドル転送の効率を向上させるように設計されています。 DTNフラグメンテーション/再構成には2つの形式があります。
Proactive Fragmentation
プロアクティブフラグメンテーション
A DTN node may divide a block of application data into multiple smaller blocks and transmit each such block as an independent bundle. In this case, the *final destination(s)* are responsible for extracting the smaller blocks from incoming bundles and reassembling them into the original larger bundle and, ultimately, ADU. This approach is called proactive fragmentation because it is used primarily when contact volumes are known (or predicted) in advance.
DTNノードは、アプリケーションデータのブロックを複数の小さなブロックに分割し、そのような各ブロックを独立したバンドルとして送信します。この場合、*最終宛先*は、着信バンドルから小さなブロックを抽出し、それらを元の大きなバンドル、最終的にはADUに再構成する責任があります。このアプローチは、主に事前にコンタクトボリュームがわかっている（または予測されている）場合に使用されるため、プロアクティブフラグメンテーションと呼ばれます。
Reactive Fragmentation
反応性フラグメンテーション
DTN nodes sharing an edge in the DTN graph may fragment a bundle cooperatively when a bundle is only partially transferred. In this case, the receiving bundle layer modifies the incoming bundle to indicate it is a fragment, and forwards it normally. The previous- hop sender may learn (via convergence-layer protocols, see Section 6) that only a portion of the bundle was delivered to the next hop, and send the remaining portion(s) when subsequent contacts become available (possibly to different next-hops if routing changes). This is called reactive fragmentation because the fragmentation process occurs after an attempted transmission has taken place.
バンドルが部分的にしか転送されない場合、DTNグラフでエッジを共有するDTNノードは、バンドルを協調的にフラグメント化することがあります。この場合、受信バンドルレイヤーは受信バンドルを変更してフラグメントであることを示し、通常どおり転送します。前のホップの送信者は、バンドルの一部のみが次のホップに配信されたことを（コンバージェンスレイヤープロトコルを介して、セクション6を参照）学習し、後続の連絡先が使用可能になったときに残りの部分を送信する可能性があります（別の次の-ルーティングが変更された場合はホップします）。これは、送信の試行が行われた後にフラグメンテーションプロセスが発生するため、リアクティブフラグメンテーションと呼ばれます。
As an example, consider a ground station G, and two store-and-forward satellites S1 and S2, in opposite low-earth orbit. While G is transmitting a large bundle to S1, a reliable transport layer protocol below the bundle layer at each indicates the transmission has terminated, but that half the transfer has completed successfully. In this case, G can form a smaller bundle fragment consisting of the second half of the original bundle and forward it to S2 when available. In addition, S1 (now out of range of G) can form a new bundle consisting of the first half of the original bundle and forward it to whatever next hop(s) it deems appropriate.
例として、地上局Gと、向かい合った低地球軌道にある2つの蓄積転送衛星S1とS2を考えます。 Gが大きなバンドルをS1に送信している間、バンドルレイヤーの下の信頼性の高いトランスポートレイヤープロトコルは、それぞれ送信が終了したことを示していますが、転送の半分は正常に完了しています。この場合、Gは元のバンドルの後半からなる小さなバンドルフラグメントを形成し、利用可能な場合はS2に転送できます。さらに、S1（現在はGの範囲外）は、元のバンドルの前半で構成される新しいバンドルを形成し、それを適切と思われる次のホップに転送できます。
The reactive fragmentation capability is not required to be available in every DTN implementation, as it requires a certain level of support from underlying protocols that may not be present, and presents significant challenges with respect to handling digital signatures and authentication codes on messages. When a signed message is only partially received, most message authentication codes will fail. When DTN security is present and enabled, it may therefore be necessary to proactively fragment large bundles into smaller units that are more convenient for digital signatures.
リアクティブ断片化機能は、存在しない可能性のある基礎となるプロトコルからの特定のレベルのサポートを必要とし、メッセージのデジタル署名と認証コードの処理に関して重大な課題を提示するため、すべてのDTN実装で利用可能である必要はありません。署名付きメッセージが部分的にしか受信されない場合、ほとんどのメッセージ認証コードは失敗します。したがって、DTNセキュリティが存在し、有効になっている場合、大きなバンドルをデジタル署名に便利な小さなユニットに事前にフラグメント化する必要がある場合があります。
Even if reactive fragmentation is not present in an implementation, the ability to reassemble fragments at a destination is required in order to support DTN fragmentation. Furthermore, for contacts with volumes that are small compared to typical bundle sizes, some incremental delivery approach must be used (e.g., checkpoint/restart) to prevent data delivery livelock. Reactive fragmentation is one such approach, but other protocol layers could potentially handle this issue as well.
実装にリアクティブフラグメンテーションが存在しない場合でも、DTNフラグメンテーションをサポートするには、宛先でフラグメントを再構成する機能が必要です。さらに、通常のバンドルサイズと比較してボリュームが小さい連絡先の場合、データ配信のライブロックを防ぐために、いくつかの増分配信アプローチ（チェックポイント/再起動など）を使用する必要があります。リアクティブフラグメンテーションはそのようなアプローチの1つですが、他のプロトコルレイヤーもこの問題を処理できる可能性があります。
The most basic service provided by the bundle layer is unacknowledged, prioritized (but not guaranteed) unicast message delivery. It also provides two options for enhancing delivery reliability: end-to-end acknowledgments and custody transfer. Applications wishing to implement their own end-to-end message reliability mechanisms are free to utilize the acknowledgment. The custody transfer feature of the DTN architecture only specifies a coarse-grained retransmission capability, described next.
バンドルレイヤーによって提供される最も基本的なサービスは、未確認で優先順位が付けられた（ただし保証されていない）ユニキャストメッセージ配信です。また、配信の信頼性を高めるための2つのオプション、エンドツーエンドの確認応答とカストディ転送も提供します。独自のエンドツーエンドのメッセージ信頼性メカニズムを実装したいアプリケーションは、確認応答を自由に利用できます。 DTNアーキテクチャのカストディ転送機能は、次に説明する粗粒度の再送信機能のみを指定します。
Transmission of bundles with the Custody Transfer Requested option specified generally involves moving the responsibility for reliable delivery of an ADU's bundles among different DTN nodes in the network. For unicast delivery, this will typically involve moving bundles "closer" (in terms of some routing metric) to their ultimate destination(s), and retransmitting when necessary. The nodes receiving these bundles along the way (and agreeing to accept the reliable delivery responsibility) are called "custodians". The movement of a bundle (and its delivery responsibility) from one node to another is called a "custody transfer". It is analogous to a database commit transaction [FHM03]. The exact meaning and design of custody transfer for multicast and anycast delivery remains to be fully explored.
Custody Transfer Requestedオプションが指定されたバンドルの送信には、一般に、ネットワーク内のさまざまなDTNノード間でADUのバンドルを確実に配信する責任の移動が含まれます。ユニキャスト配信の場合、これには通常、バンドルを（一部のルーティングメトリックに関して）最終的な宛先に「より近く」移動し、必要に応じて再送信することが含まれます。途中でこれらのバンドルを受信する（そして信頼できる配信の責任を受け入れることに同意する）ノードは「カストディアン」と呼ばれます。 1つのノードから別のノードへのバンドル（およびその配信の責任）の移動は、「保管転送」と呼ばれます。これは、データベースコミットトランザクション[FHM03]に類似しています。マルチキャストおよびエニーキャスト配信の保管転送の正確な意味と設計は、完全に調査されていないままです。
Custody transfer allows the source to delegate retransmission responsibility and recover its retransmission-related resources relatively soon after sending a bundle (on the order of the minimum round-trip time to the first bundle hop(s)). Not all nodes in a DTN are required by the DTN architecture to accept custody transfers, so it is not a true 'hop-by-hop' mechanism. For example, some nodes may have sufficient storage resources to sometimes act as custodians, but may elect to not offer such services when congested or running low on power.
カストディ転送により、送信元は、バンドルを送信した後（最初のバンドルホップへの最小往復時間の順序で）比較的すぐに、再送信の責任を委任し、再送信関連のリソースを回復できます。カストディ転送を受け入れるために、DTNのすべてのノードがDTNアーキテクチャーで必要とされるわけではないため、真の「ホップバイホップ」メカニズムではありません。たとえば、一部のノードは、カストディアンとして機能するのに十分なストレージリソースを持っている場合がありますが、輻輳した場合や電力が不足している場合は、そのようなサービスを提供しないことを選択できます。
The existence of custodians can alter the way DTN routing is performed. In some circumstances, it may be beneficial to move a bundle to a custodian as quickly as possible even if the custodian is further away (in terms of distance, time or some routing metric) from the bundle's final destination(s) than some other reachable node. Designing a system with this capability involves constructing more than one routing graph, and is an area of continued research.
カストディアンの存在は、DTNルーティングの実行方法を変更する可能性があります。一部の状況では、カストディアンが他の到達可能な他のバンドルよりもバンドルの最終宛先から（距離、時間、またはルーティングメトリックに関して）遠く離れている場合でも、バンドルをカストディアンにできるだけ早く移動することが有益な場合がありますノード。この機能を備えたシステムの設計には、複数のルーティンググラフの作成が含まれ、継続的な研究の領域です。
Custody transfer in DTN not only provides a method for tracking bundles that require special handling and identifying DTN nodes that participate in custody transfer, it also provides a (weak) mechanism for enhancing the reliability of message delivery. Generally speaking, custody transfer relies on underlying reliable delivery protocols of the networks that it operates over to provide the primary means of reliable transfer from one bundle node to the next (set). However, when custody transfer is requested, the bundle layer provides an additional coarse-grained timeout and retransmission mechanism and an accompanying (bundle-layer) custodian-to-custodian acknowledgment signaling mechanism. When an application does *not* request custody transfer, this bundle layer timeout and retransmission mechanism is typically not employed, and successful bundle layer delivery depends solely on the reliability mechanisms of the underlying protocols.
DTNでの管理転送は、特別な処理を必要とするバンドルを追跡し、管理転送に参加するDTNノードを識別する方法を提供するだけでなく、メッセージ配信の信頼性を高めるための（弱い）メカニズムも提供します。一般的に言えば、カストディ転送は、1つのバンドルノードから次のノード（セット）への信頼性の高い転送の主要な手段を提供するために動作する、ネットワークの根本的な信頼性の高い配信プロトコルに依存しています。ただし、カストディ転送が要求された場合、バンドルレイヤーは、追加の粗粒度のタイムアウトと再送信のメカニズム、および付随する（バンドルレイヤー）カストディアンからカストディアンの確認応答シグナリングメカニズムを提供します。アプリケーションがカストディ転送を要求しない場合、通常、このバンドルレイヤーのタイムアウトと再送信のメカニズムは使用されず、バンドルレイヤーの配信が成功するかどうかは、基礎となるプロトコルの信頼性メカニズムにのみ依存します。
When a node accepts custody for a bundle that contains the Custody Transfer Requested option, a Custody Transfer Accepted Signal is sent by the bundle layer to the Current Custodian EID contained in the primary bundle block. In addition, the Current Custodian EID is updated to contain one of the forwarding node's (unicast) EIDs before the bundle is forwarded.
ノードがカストディ転送要求オプションを含むバンドルのカストディを受け入れると、カストディ転送受け入れ信号がバンドルレイヤーによってプライマリバンドルブロックに含まれる現在のカストディアンEIDに送信されます。さらに、バンドルが転送される前に、現在のカストディアンEIDが転送ノードの（ユニキャスト）EIDの1つを含むように更新されます。
When an application requests an ADU to be delivered with custody transfer, the request is advisory. In some circumstances, a source of a bundle for which custody transfer has been requested may not be able to provide this service. In such circumstances, the subject bundle may traverse multiple DTN nodes before it obtains a custodian. Bundles in this condition are specially marked with their Current Custodian EID field set to a null endpoint. In cases where applications wish to require the source to take custody of the bundle, they may supply the Source Node Custody Acceptance Required delivery option. This may be useful to applications that desire a continuous "chain" of custody or that wish to exit after being ensured their data is safely held in a custodian.
アプリケーションがADUをカストディ転送で配信するように要求する場合、その要求は助言です。状況によっては、管理転送が要求されたバンドルのソースがこのサービスを提供できない場合があります。このような状況では、カストディアンを取得する前に、対象のバンドルが複数のDTNノードを通過する場合があります。この状態のバンドルは、現在のカストディアンEIDフィールドがnullエンドポイントに設定されて特別にマークされます。アプリケーションがソースにバンドルの管理を要求することを希望する場合、アプリケーションはソースノードの管理の承諾が必要な配信オプションを提供できます。これは、管理の継続的な「連鎖」を希望するアプリケーション、またはデータがカストディアンに安全に保持されていることを確認した後に終了することを希望するアプリケーションに役立ちます。
In a DTN network where one or more custodian-to-custodian hops are strictly one directional (and cannot be reversed), the DTN custody transfer mechanism will be affected over such hops due to the lack of any way to receive a custody signal (or any other information) back across the path, resulting in the expiration of the bundle at the ingress to the one-way hop. This situation does not necessarily mean the bundle has been lost; nodes on the other side of the hop may continue to transfer custody, and the bundle may be delivered successfully to its destination(s). However, in this circumstance a source that has requested to receive expiration BSRs for this bundle will receive an expiration report for the bundle, and possibly conclude (incorrectly) that the bundle has been discarded and not delivered. Although this problem cannot be fully solved in this situation, a mechanism is provided to help ameliorate the seemingly incorrect information that may be reported when the bundle expires after having been transferred over a one-way hop. This is accomplished by the node at the ingress to the one-way hop reporting the existence of a known one-way path using a variant of a bundle status report. These types of reports are provided if the subject bundle requests the report using the 'Report When Bundle Forwarded' delivery option.
1つ以上のカストディアンからカストディアンへのホップが厳密に一方向である（そして、逆にすることができない）DTNネットワークでは、カストディ信号を受信する方法がないため、DTNカストディ転送メカニズムはそのようなホップで影響を受けます（またはその他の情報）パスを横切って戻ると、一方向ホップへの入口でバンドルの有効期限が切れます。この状況は、バンドルが失われたことを必ずしも意味しません。ホップの反対側のノードは管理を転送し続け、バンドルはその宛先に正常に配信される場合があります。ただし、この状況では、このバンドルの有効期限BSRの受信を要求したソースは、バンドルの有効期限レポートを受け取り、バンドルが破棄され、配信されなかったと（誤って）結論付けます。この状況ではこの問題を完全に解決することはできませんが、一方向のホップを介して転送された後にバンドルが期限切れになったときに報告される可能性のある不正確に見える情報を改善するためのメカニズムが提供されます。これは、一方向ホップの入口にあるノードが、バンドルステータスレポートのバリアントを使用して、既知の一方向パスの存在を報告することで実現されます。これらのタイプのレポートは、対象のバンドルが「バンドル転送時のレポート」配信オプションを使用してレポートを要求した場合に提供されます。
One of the aims of DTN is to provide a common method for interconnecting application layer gateways and proxies. In cases where existing Internet applications can be made to tolerate delays, local proxies can be constructed to benefit from the existing communication capabilities provided by DTN [S05, T02]. Making such proxies compatible with DTN reduces the burden on the proxy author from being concerned with how to implement routing and reliability management and allows existing TCP/IP-based applications to operate unmodified over a DTN-based network.
DTNの目的の1つは、アプリケーション層のゲートウェイとプロキシを相互接続するための一般的な方法を提供することです。既存のインターネットアプリケーションで遅延を許容できる場合は、ローカルプロキシを構築して、DTNが提供する既存の通信機能を利用できます[S05、T02]。このようなプロキシをDTNと互換性があるようにすると、プロキシ作成者がルーティングと信頼性の管理を実装する方法を気にする必要がなくなり、既存のTCP / IPベースのアプリケーションを変更せずにDTNベースのネットワークで動作させることができます。
When DTN is used to provide a form of tunnel encapsulation for other protocols, it can be used in constructing overlay networks comprised of application layer gateways. The application acknowledgment capability is designed for such circumstances. This provides a common way for remote application layer gateways to signal the success or failure of non-DTN protocol operations initiated as a result of receiving DTN ADUs. Without this capability, such indicators would have to be implemented by applications themselves in non-standard ways.
DTNを使用して他のプロトコルにトンネルカプセル化の形式を提供する場合、アプリケーション層ゲートウェイで構成されるオーバーレイネットワークの構築に使用できます。アプリケーションの確認応答機能は、このような状況向けに設計されています。これは、リモートアプリケーションレイヤーゲートウェイが、DTN ADUの受信の結果として開始された非DTNプロトコル操作の成功または失敗を通知するための一般的な方法を提供します。この機能がなければ、そのようなインジケーターは非標準的な方法でアプリケーション自体によって実装される必要があります。
The DTN architecture depends on time synchronization among DTN nodes (supported by external, non-DTN protocols) for four primary purposes: bundle and fragment identification, routing with scheduled or predicted contacts, bundle expiration time computations, and application registration expiration.
DTNアーキテクチャは、バンドルとフラグメントの識別、スケジュールされたまたは予測された連絡先によるルーティング、バンドルの有効期限の計算、およびアプリケーション登録の有効期限という4つの主な目的で、DTNノード（外部の非DTNプロトコルでサポートされる）間の時間同期に依存しています。
Bundle identification and expiration are supported by placing a creation timestamp and an explicit expiration field (expressed in seconds after the source timestamp) in each bundle. The origination timestamps on arriving bundles are made available to consuming applications in ADUs they receive by some system interface function. Each set of bundles corresponding to an ADU is required to contain a timestamp unique to the sender's EID. The EID, timestamp, and data offset/length information together uniquely identify a bundle. Unique bundle identification is used for a number of purposes, including custody transfer and reassembly of bundle fragments.
バンドルの識別と有効期限は、各バンドルに作成タイムスタンプと明示的な有効期限フィールド（ソースタイムスタンプの後の秒数で表現）を配置することによってサポートされます。到着したバンドルのオリジネーションタイムスタンプは、システムインターフェース機能によって受信したADUのアプリケーションを利用できるようになります。 ADUに対応するバンドルの各セットには、送信者のEIDに固有のタイムスタンプが含まれている必要があります。 EID、タイムスタンプ、およびデータオフセット/長さの情報は、バンドルを一意に識別します。一意のバンドルIDは、保管の転送やバンドルフラグメントの再構成など、さまざまな目的で使用されます。
Time is also used in conjunction with application registrations. When an application expresses its desire to receive ADUs destined for a particular EID, this registration is only maintained for a finite period of time, and may be specified by the application. For multicast registrations, an application may also specify a time range or "interest interval" for its registration. In this case, traffic sent to the specified EID any time during the specified interval will eventually be delivered to the application (unless such traffic has expired due to the expiration time provided by the application at the source or some other reason prevents such delivery).
時間は、アプリケーションの登録とともに使用されます。アプリケーションが特定のEIDを宛先とするADUの受信を希望する場合、この登録は限られた期間のみ維持され、アプリケーションによって指定される場合があります。マルチキャスト登録の場合、アプリケーションはその登録の時間範囲または「インタレスト間隔」も指定できます。この場合、指定された間隔中にいつでも指定されたEIDに送信されたトラフィックは、最終的にアプリケーションに配信されます（送信元でアプリケーションによって提供された有効期限が原因でそのようなトラフィックが期限切れになった場合、または他の何らかの理由で配信が妨げられた場合を除く）。
The subject of congestion control and flow control at the bundle layer is one on which the authors of this document have not yet reached complete consensus. We have unresolved concerns about the efficiency and efficacy of congestion and flow control schemes implemented across long and/or highly variable delay environments, especially with the custody transfer mechanism that may require nodes to retain bundles for long periods of time.
バンドル層での輻輳制御とフロー制御の主題は、このドキュメントの作成者がまだ完全な合意に達していないものです。特に、ノードが長期間バンドルを保持する必要がある可能性があるカストディ転送メカニズムを使用して、長い遅延環境や非常に可変的な遅延環境全体に実装された輻輳およびフロー制御スキームの効率と有効性に関する未解決の懸念があります。
For the purposes of this document, we define "flow control" as a means of assuring that the average rate at which a sending node transmits data to a receiving node does not exceed the average rate at which the receiving node is prepared to receive data from that sender. (Note that this is a generalized notion of flow control, rather than one that applies only to end-to-end communication.) We define "congestion control" as a means of assuring that the aggregate rate at which all traffic sources inject data into a network does not exceed the maximum aggregate rate at which the network can deliver data to destination nodes over time. If flow control is propagated backward from congested nodes toward traffic sources, then the flow control mechanism can be used as at least a partial solution to the problem of congestion as well.
このドキュメントでは、「フロー制御」を、送信ノードがデータを受信ノードに送信する平均レートが、受信ノードがデータを受信する準備ができている平均レートを超えないことを保証する手段として定義します。その送信者。 （これは、エンドツーエンド通信にのみ適用されるものではなく、フロー制御の一般化された概念であることに注意してください。）すべてのトラフィックソースがデータを注入する総レートを保証する手段として、「輻輳制御」を定義します。ネットワークは、時間の経過とともにネットワークが宛先ノードにデータを配信できる最大総レートを超えません。フロー制御が輻輳ノードからトラフィックソースに向かって逆方向に伝播される場合、フロー制御メカニズムは、輻輳の問題に対する少なくとも部分的なソリューションとしても使用できます。
DTN flow control decisions must be made within the bundle layer itself based on information about resources (in this case, primarily persistent storage) available within the bundle node. When storage resources become scarce, a DTN node has only a certain degree of freedom in handling the situation. It can always discard bundles which have expired -- an activity DTN nodes should perform regularly in any case. If it ordinarily is willing to accept custody for bundles, it can cease doing so. If storage resources are available elsewhere in the network, it may be able to make use of them in some way for bundle storage. It can also discard bundles which have not expired but for which it has not accepted custody. A node must avoid discarding bundles for which it has accepted custody, and do so only as a last resort. Determining when a node should engage in or cease to engage in custody transfers is a resource allocation and scheduling problem of current research interest.
DTNフロー制御の決定は、バンドルノード内で使用可能なリソース（この場合、主に永続的なストレージ）に関する情報に基づいて、バンドルレイヤー自体内で行う必要があります。ストレージリソースが不足すると、DTNノードは状況の処理においてある程度の自由度しか持ちません。有効期限が切れたバンドルは常に破棄できます。DTNノードがどのような場合でも定期的に実行する必要があるアクティビティです。通常、バンドルの保管を受け入れる用意がある場合は、そうすることをやめることができます。ストレージリソースがネットワークの他の場所で利用できる場合、バンドルストレージにそれらを何らかの方法で利用できる可能性があります。また、期限が切れていないが保管を受け入れていないバンドルを破棄することもできます。ノードは、保管を受け入れたバンドルの破棄を避け、最後の手段としてのみ破棄する必要があります。ノードがカストディ転送に関与するか、関与を停止するかを決定することは、現在の研究対象のリソース割り当てとスケジューリングの問題です。
In addition to the bundle layer mechanisms described above, a DTN node may be able to avail itself of support from lower-layer protocols in affecting its own resource utilization. For example, a DTN node receiving a bundle using TCP/IP might intentionally slow down its receiving rate by performing read operations less frequently in order to reduce its offered load. This is possible because TCP provides its own flow control, so reducing the application data consumption rate could effectively implement a form of hop-by-hop flow control. Unfortunately, it may also lead to head-of-line blocking issues, depending on the nature of bundle multiplexing within a TCP connection. A protocol with more relaxed ordering constraints (e.g. SCTP [RFC2960]) might be preferable in such circumstances.
上記のバンドルレイヤーメカニズムに加えて、DTNノードは、自身のリソース使用率に影響を与える際に、下位レイヤープロトコルからのサポートを利用できる場合があります。たとえば、TCP / IPを使用してバンドルを受信するDTNノードは、提供される負荷を減らすために読み取り操作の実行頻度を下げることで、受信レートを意図的に遅くする場合があります。これは、TCPが独自のフロー制御を提供するため可能であり、アプリケーションデータの消費率を削減すると、ホップバイホップフロー制御の形式を効果的に実装できます。残念ながら、TCP接続内でのバンドル多重化の性質によっては、ヘッドオブラインブロッキングの問題が発生する可能性もあります。このような状況では、順序付けの制約が緩和されたプロトコル（SCTP [RFC2960]など）が望ましい場合があります。
Congestion control is an ongoing research topic.
輻輳制御は現在進行中の研究トピックです。
The possibility of severe resource scarcity in some delay-tolerant networks dictates that some form of authentication and access control to the network itself is required in many circumstances. It is not acceptable for an unauthorized user to flood the network with traffic easily, possibly denying service to authorized users. In many cases it is also not acceptable for unauthorized traffic to be forwarded over certain network links at all. This is especially true for exotic, mission-critical links. In light of these considerations, several goals are established for the security component of the DTN architecture:
一部の遅延耐性のあるネットワークで深刻なリソース不足が発生する可能性があるため、多くの状況では、ネットワーク自体への認証とアクセス制御の形式が必要です。権限のないユーザーが簡単にネットワークをトラフィックで溢れさせ、権限のあるユーザーへのサービスを拒否することは許されません。多くの場合、無許可のトラフィックが特定のネットワークリンクを介して転送されることもまったく受け入れられません。これは、エキゾチックでミッションクリティカルなリンクに特に当てはまります。これらの考慮事項に照らして、DTNアーキテクチャのセキュリティコンポーネントにはいくつかの目標が設定されています。
- Promptly prevent unauthorized applications from having their data carried through or stored in the DTN.
- 無許可のアプリケーションがDTNを介してデータを運んだり、DTNに保存したりしないようにしてください。
- Prevent unauthorized applications from asserting control over the DTN infrastructure.
- 不正なアプリケーションがDTNインフラストラクチャの制御を主張することを防ぎます。
- Prevent otherwise authorized applications from sending bundles at a rate or class of service for which they lack permission.
- 他の方法で承認されたアプリケーションが、許可のないレートまたはサービスクラスでバンドルを送信しないようにします。
- Promptly discard bundles that are damaged or improperly modified in transit.
- 輸送中に破損したり、不適切に変更されたバンドルは、すぐに破棄してください。
- Promptly detect and de-authorize compromised entities.
- 侵害されたエンティティを迅速に検出して認証を解除します。
Many existing authentication and access control protocols designed for operation in low-delay, connected environments may not perform well in DTNs. In particular, updating access control lists and revoking ("blacklisting") credentials may be especially difficult. Also, approaches that require frequent access to centralized servers to complete an authentication or authorization transaction are not attractive. The consequences of these difficulties include delays in the onset of communication, delays in detecting and recovering from system compromise, and delays in completing transactions due to inappropriate access control or authentication settings.
低遅延で接続された環境での運用向けに設計された既存の認証およびアクセス制御プロトコルの多くは、DTNではうまく機能しない場合があります。特に、アクセス制御リストの更新と資格情報の取り消し（「ブラックリスト」）は特に難しい場合があります。また、認証または承認トランザクションを完了するために集中型サーバーに頻繁にアクセスする必要があるアプローチは魅力的ではありません。これらの困難の結果としては、通信の開始の遅延、システムの侵害の検出と回復の遅延、不適切なアクセス制御または認証設定によるトランザクションの完了の遅延などがあります。
To help satisfy these security requirements in light of the challenges, the DTN architecture adopts a standard but optionally deployed security architecture [DTNSEC] that utilizes hop-by-hop and end-to-end authentication and integrity mechanisms. The purpose of using both approaches is to be able to handle access control for data forwarding and storage separately from application-layer data integrity. While the end-to-end mechanism provides authentication for a principal such as a user (of which there may be many), the hop-by-hop mechanism is intended to authenticate DTN nodes as legitimate transceivers of bundles to each-other. Note that it is conceivable to construct a DTN in which only a subset of the nodes participate in the security mechanisms, resulting in a secure DTN overlay existing atop an insecure DTN overlay. This idea is relatively new and is still being explored.
課題に照らしてこれらのセキュリティ要件を満たすために、DTNアーキテクチャは、ホップバイホップおよびエンドツーエンドの認証および整合性メカニズムを利用する、標準だがオプションで配備されたセキュリティアーキテクチャ[DTNSEC]を採用しています。両方のアプローチを使用する目的は、アプリケーション層のデータ整合性とは別に、データ転送とストレージのアクセス制御を処理できるようにすることです。エンドツーエンドメカニズムは、ユーザー（多くの場合があります）などのプリンシパルに認証を提供しますが、ホップバイホップメカニズムは、DTNノードを互いにバンドルの正当なトランシーバーとして認証することを目的としています。ノードのサブセットのみがセキュリティメカニズムに参加するDTNを構築することが考えられ、安全でないDTNオーバーレイの上に安全なDTNオーバーレイが存在することに注意してください。このアイデアは比較的新しいものであり、まだ検討されています。
In accordance with the goals listed above, DTN nodes discard traffic as early as possible if authentication or access control checks fail. This approach meets the goals of removing unwanted traffic from being forwarded over specific high-value links, but also has the associated benefit of making denial-of-service attacks considerably harder to mount more generally, as compared with conventional Internet routers. However, the obvious cost for this capability is potentially larger computation and credential storage overhead required at DTN nodes.
上記の目標に従って、認証またはアクセス制御チェックが失敗した場合、DTNノードはできるだけ早くトラフィックを破棄します。このアプローチは、不要なトラフィックを特定の高価値リンクを介して転送されないようにするという目標を満たしますが、従来のインターネットルーターと比較して、サービス拒否攻撃をより一般的にマウントすることがかなり困難になるという関連する利点もあります。ただし、この機能の明らかなコストは、DTNノードで必要となる計算および資格情報ストレージのオーバーヘッドが潜在的に大きくなることです。
For more detailed information on DTN security provisions, refer to [DTNSEC] and [DTNSOV].
DTNセキュリティ規定の詳細については、[DTNSEC]および[DTNSOV]を参照してください。
An important aspect of any networking architecture is its management of state. This section describes the state managed at the bundle layer and discusses how it is established and removed.
ネットワーキングアーキテクチャの重要な側面は、その状態の管理です。このセクションでは、バンドルレイヤーで管理される状態について説明し、その状態が確立および削除される方法について説明します。
In long/variable delay environments, an asynchronous application interface seems most appropriate. Such interfaces typically include methods for applications to register callback actions when certain triggering events occur (e.g., when ADUs arrive). These registrations create state information called application registration state.
長い/可変遅延環境では、非同期アプリケーションインターフェイスが最も適切と思われます。このようなインターフェイスには通常、特定のトリガーイベントが発生したとき（ADUが到着したときなど）にアプリケーションがコールバックアクションを登録するためのメソッドが含まれます。これらの登録により、アプリケーション登録状態と呼ばれる状態情報が作成されます。
Application registration state is typically created by explicit request of the application, and is removed by a separate explicit request, but may also be removed by an application-specified timer (it is thus "firm" state). In most cases, there must be a provision for retaining this state across application and operating system termination/restart conditions because a client/server bundle round-trip time may exceed the requesting application's execution time (or hosting system's uptime). In cases where applications are not automatically restarted but application registration state remains persistent, a method must be provided to indicate to the system what action to perform when the triggering event occurs (e.g., restarting some application, ignoring the event, etc.).
アプリケーション登録状態は、通常、アプリケーションの明示的な要求によって作成され、別の明示的な要求によって削除されますが、アプリケーション指定のタイマーによって削除される場合もあります（したがって、「確定」状態です）。ほとんどの場合、クライアント/サーバーバンドルのラウンドトリップ時間は、要求しているアプリケーションの実行時間（またはホスティングシステムの稼働時間）を超える可能性があるため、アプリケーションとオペレーティングシステムの終了/再起動条件にわたってこの状態を保持するための対策が必要です。アプリケーションが自動的に再起動されないが、アプリケーションの登録状態が永続的である場合は、トリガーイベントが発生したときに実行するアクションをシステムに示すメソッドを提供する必要があります（たとえば、一部のアプリケーションの再起動、イベントの無視など）。
To initiate a registration and thereby establish application registration state, an application specifies an Endpoint ID for which it wishes to receive ADUs, along with an optional time value indicating how long the registration should remain active. This operation is somewhat analogous to the bind() operation in the common sockets API.
登録を開始してアプリケーションの登録状態を確立するには、アプリケーションは、ADUを受信するエンドポイントIDと、登録をアクティブにしておく時間を示すオプションの時間値を指定します。この操作は、一般的なソケットAPIのbind()操作に似ています。
For registrations to groups (i.e., joins), a time interval may also be specified. The time interval refers to the range of origination times of ADUs sent to the specified EID. See Section 3.4 above for more details.
グループへの登録（つまり、参加）の場合、時間間隔も指定できます。時間間隔は、指定されたEIDに送信されるADUの発信時間の範囲を指します。詳細については、上記のセクション3.4を参照してください。
Custody transfer state includes information required to keep account of bundles for which a node has taken custody, as well as the protocol state related to transferring custody for one or more of them. The accounting-related state is created when a bundle is received. Custody transfer retransmission state is created when a transfer of custody is initiated by forwarding a bundle with the custody transfer requested delivery option specified. Retransmission state and accounting state may be released upon receipt of one or more Custody Transfer Succeeded signals, indicating custody has been moved. In addition, the bundle's expiration time (possibly mitigated by local policy) provides an upper bound on the time when this state is purged from the system in the event that it is not purged explicitly due to receipt of a signal.
カストディ転送状態には、ノードがカストディを取得したバンドルのアカウントを維持するために必要な情報と、それらの1つ以上のカストディの転送に関連するプロトコル状態が含まれます。アカウンティング関連の状態は、バンドルを受信したときに作成されます。カストディ転送再送信状態は、カストディ転送要求配信オプションを指定してバンドルを転送することにより、カストディの転送が開始されたときに作成されます。再送状態とアカウンティング状態は、1つ以上の管理転送成功信号を受信すると解放され、管理が移動したことを示します。さらに、バンドルの有効期限（ローカルポリシーによって軽減される可能性があります）は、信号の受信のために明示的に削除されない場合に、この状態がシステムから削除される時間の上限を提供します。
As with the Internet architecture, we distinguish between routing and forwarding. Routing refers to the execution of a (possibly distributed) algorithm for computing routing paths according to some objective function (see [JFP04], for example). Forwarding refers to the act of moving a bundle from one DTN node to another. Routing makes use of routing state (the RIB, or routing information base), while forwarding makes use of state derived from routing, and is maintained as forwarding state (the FIB, or forwarding information base). The structure of the FIB and the rules for maintaining it are implementation choices. In some DTNs, exchange of information used to update state in the RIB may take place on network paths distinct from those where exchange of application data takes place.
インターネットアーキテクチャと同様に、ルーティングと転送を区別します。ルーティングとは、ある目的関数に従ってルーティングパスを計算するための（おそらく分散された）アルゴリズムの実行を指します（たとえば、[JFP04]を参照）。転送とは、バンドルをあるDTNノードから別のDTNノードに移動することです。ルーティングはルーティング状態（RIB、またはルーティング情報ベース）を利用し、転送はルーティングから派生した状態を利用し、転送状態（FIB、または転送情報ベース）として維持されます。 FIBの構造とそれを維持するためのルールは、実装の選択です。一部のDTNでは、RIBで状態を更新するために使用される情報の交換が、アプリケーションデータの交換が行われるものとは異なるネットワークパスで行われる場合があります。
The maintenance of state in the RIB is dependent on the type of routing algorithm being used. A routing algorithm may consider requested class of service and the location of potential custodians (for custody transfer, see section 3.10), and this information will tend to increase the size of the RIB. The separation between FIB and RIB is not required by this document, as these are implementation details to be decided by system implementers. The choice of routing algorithms is still under study.
RIBでの状態の維持は、使用されているルーティングアルゴリズムのタイプによって異なります。ルーティングアルゴリズムは、要求されたサービスクラスと潜在的なカストディアンの位置（管理転送については、セクション3.10を参照）を考慮し、この情報はRIBのサイズを大きくする傾向があります。 FIBとRIBの分離は、このドキュメントでは必要ありません。これらはシステムの実装者が決定する実装の詳細であるためです。ルーティングアルゴリズムの選択はまだ検討中です。
Bundles may occupy queues in nodes for a considerable amount of time. For unicast or anycast delivery, the amount of time is likely to be the interval between when a bundle arrives at a node and when it can be forwarded to its next hop. For multicast delivery of bundles, this could be significantly longer, up to a bundle's expiration time. This situation occurs when multicast delivery is utilized in such a way that nodes joining a group can obtain information previously sent to the group. In such cases, some nodes may act as "archivers" that provide copies of bundles to new participants that have already been delivered to other participants.
バンドルは、かなりの時間、ノードのキューを占有する場合があります。ユニキャストまたはエニーキャスト配信の場合、時間は、バンドルがノードに到着してから次のホップに転送できるまでの時間になる可能性があります。バンドルのマルチキャスト配信の場合、これはバンドルの有効期限まで、かなり長くなる可能性があります。この状況は、グループに参加しているノードが以前にグループに送信された情報を取得できるようにマルチキャスト配信が利用されている場合に発生します。このような場合、一部のノードは、すでに他の参加者に配信されている新しい参加者にバンドルのコピーを提供する「アーカイバ」として機能する場合があります。
The DTN security approach described in [DTNSEC], when used, requires maintenance of state in all DTN nodes that use it. All such nodes are required to store their own private information (including their own policy and authentication material) and a block of information used to verify credentials. Furthermore, in most cases, DTN nodes will cache some public information (and possibly the credentials) of their next-hop (bundle) neighbors. All cached information has expiration times, and nodes are responsible for acquiring and distributing updates of public information and credentials prior to the expiration of the old set (in order to avoid a disruption in network service).
[DTNSEC]で説明されているDTNセキュリティアプローチを使用する場合、それを使用するすべてのDTNノードで状態を維持する必要があります。このようなノードはすべて、独自のプライベート情報（独自のポリシーと認証資料を含む）および資格情報の検証に使用される情報のブロックを格納する必要があります。さらに、ほとんどの場合、DTNノードは次のホップ（バンドル）ネイバーの公開情報（および場合によっては資格情報）をキャッシュします。キャッシュされたすべての情報には有効期限があり、ノードは古いセットの有効期限が切れる前に公開情報と資格情報の更新を取得して配布します（ネットワークサービスの中断を回避するため）。
In addition to basic end-to-end and hop-by-hop authentication, access control may be used in a DTN by one or more mechanisms such as capabilities or access control lists (ACLs). ACLs would represent another block of state present in any node that wishes to enforce security policy. ACLs are typically initialized at node configuration time and may be updated dynamically by DTN bundles or by some out of band technique. Capabilities or credentials may be revoked, requiring the maintenance of a revocation list ("black list", another form of state) to check for invalid authentication material that has already been distributed.
基本的なエンドツーエンドおよびホップバイホップ認証に加えて、機能やアクセス制御リスト（ACL）などの1つ以上のメカニズムによって、DTNでアクセス制御を使用できます。 ACLは、セキュリティポリシーを適用したいノードに存在する別の状態ブロックを表します。 ACLは通常、ノードの構成時に初期化され、DTNバンドルまたは帯域外の技術によって動的に更新される場合があります。機能または資格情報が取り消される可能性があり、失効リスト（「ブラックリスト」、別の形式の状態）を保守して、すでに配布されている無効な認証資料をチェックする必要があります。
Some DTNs may implement security boundaries enforced by selected nodes in the network, where end-to-end credentials may be checked in addition to checking the hop-by-hop credentials. (Doing so may require routing to be adjusted to ensure all bundles comprising each ADU pass through these points.) Public information used to verify end-to-end authentication will typically be cached at these points.
一部のDTNは、ネットワーク内の選択されたノードによって実施されるセキュリティ境界を実装する場合があります。この場合、ホップごとの資格情報のチェックに加えて、エンドツーエンドの資格情報もチェックされます。 （そのためには、各ADUを構成するすべてのバンドルがこれらのポイントを通過するようにルーティングを調整する必要がある場合があります。）エンドツーエンド認証の検証に使用される公開情報は、通常これらのポイントでキャッシュされます。
DTN nodes will contain some amount of configuration and policy information. Such information may alter the behavior of bundle forwarding. Examples of policy state include the types of cryptographic algorithms and access control procedures to use if DTN security is employed, whether nodes may become custodians, what types of convergence layer (see Section 6) and routing protocols are in use, how bundles of differing priorities should be scheduled, where and for how long bundles and other data is stored, what status reports may be generated or at what rate, etc.
DTNノードには、ある程度の構成およびポリシー情報が含まれます。このような情報は、バンドル転送の動作を変更する可能性があります。ポリシー状態の例には、DTNセキュリティが採用されている場合に使用する暗号化アルゴリズムとアクセス制御手順のタイプ、ノードがカストディアンになるかどうか、どのタイプのコンバージェンスレイヤー（セクション6を参照）とルーティングプロトコルが使用されているか、異なる優先度のバンドルのバンドルが含まれますバンドルやその他のデータが保存される場所と期間、生成されるステータスレポート、生成されるレートなどをスケジュールする必要があります。
DTN bundle delivery is intended to operate in a delay-tolerant fashion over a broad range of network types. This does not mean there *must* be large delays in the network; it means there *may* be very significant delays (including extended periods of disconnection between sender and intended recipient(s)). The DTN protocols are delay tolerant, so applications using them must also be delay tolerant in order to operate effectively in environments subject to significant delay or disruption.
DTNバンドル配信は、さまざまなネットワークタイプで遅延耐性のある方法で動作することを目的としています。これは、ネットワークに大きな遅延があることを意味するわけではありません。これは、非常に重大な遅延が存在する可能性があることを意味します（送信者と目的の受信者の間の長時間の切断を含む）。 DTNプロトコルは遅延に強いので、それらを使用するアプリケーションも、大幅な遅延または混乱が発生する環境で効果的に動作するために、遅延に耐えなければなりません。
The communication primitives provided by the DTN architecture are based on asynchronous, message-oriented communication which differs from conversational request/response communication. In general, applications should attempt to include enough information in an ADU so that it may be treated as an independent unit of work by the network and receiver(s). The goal is to minimize synchronous interchanges between applications that are separated by a network characterized by long and possibly highly variable delays. A single file transfer request message, for example, might include authentication information, file location information, and requested file operation (thus "bundling" this information together). Comparing this style of operation to a classic FTP transfer, one sees that the bundled model can complete in one round trip, whereas an FTP file "put" operation can take as many as eight round trips to get to a point where file data can flow [DFS02].
DTNアーキテクチャーによって提供される通信プリミティブは、会話型の要求/応答通信とは異なる非同期のメッセージ指向の通信に基づいています。一般に、アプリケーションは、ADUに十分な情報を含めて、ネットワークとレシーバーによって独立した作業単位として扱われるようにする必要があります。目標は、長く変動する可能性のある遅延によって特徴付けられるネットワークによって分離されているアプリケーション間の同期交換を最小限に抑えることです。たとえば、単一のファイル転送要求メッセージには、認証情報、ファイルの場所の情報、および要求されたファイル操作が含まれる場合があります（したがって、この情報を一緒に「バンドル」します）。このスタイルの操作を従来のFTP転送と比較すると、バンドルされたモデルは1回のラウンドトリップで完了することができますが、FTPファイルの「put」操作では、ファイルデータが流れるポイントに到達するまでに最大8回のラウンドトリップが必要です。 [DFS02]。
Delay-tolerant applications must consider additional factors beyond the conversational implications of long delay paths. For example, an application may terminate (voluntarily or not) between the time it sends a message and the time it expects a response. If this possibility has been anticipated, the application can be "re-instantiated" with state information saved in persistent storage. This is an implementation issue, but also an application design consideration.
遅延耐性のあるアプリケーションでは、長い遅延パスによる会話上の影響を超える追加の要素を考慮する必要があります。たとえば、アプリケーションは、メッセージを送信してから応答を予期するまでの間に（自発的かどうかにかかわらず）終了する場合があります。この可能性が予想される場合は、状態情報を永続ストレージに保存して、アプリケーションを「再インスタンス化」できます。これは実装の問題ですが、アプリケーションの設計上の考慮事項でもあります。
Some consideration of delay-tolerant application design can result in applications that work reasonably well in low-delay environments, and that do not suffer extraordinarily in high or highly-variable delay environments.
遅延耐性のあるアプリケーション設計を検討すると、アプリケーションが低遅延環境で適度に機能し、高遅延または高変動の遅延環境で異常に影響を受けないアプリケーションが得られます。
Implementation experience with the DTN architecture has revealed an important architectural construct and interface for DTN nodes [DBFJHP04]. Not all underlying protocols in different protocol families provide the same exact functionality, so some additional adaptation or augmentation on a per-protocol or per-protocol-family basis may be required. This adaptation is accomplished by a set of convergence layers placed between the bundle layer and underlying protocols. The convergence layers manage the protocol-specific details of interfacing with particular underlying protocols and present a consistent interface to the bundle layer.
DTNアーキテクチャーの実装経験により、DTNノードの重要なアーキテクチャー構造とインターフェースが明らかになりました[DBFJHP04]。異なるプロトコルファミリのすべての基盤となるプロトコルがまったく同じ機能を提供するわけではないため、プロトコルごとまたはプロトコルファミリごとの追加の適応または拡張が必要になる場合があります。この適応は、バンドルレイヤーと基盤となるプロトコルの間に配置された一連の収束レイヤーによって実現されます。コンバージェンスレイヤーは、特定の基盤となるプロトコルとのインターフェイスに関するプロトコル固有の詳細を管理し、バンドルレイヤーに一貫したインターフェイスを提供します。
The complexity of one convergence layer may vary substantially from another, depending on the type of underlying protocol it adapts. For example, a TCP/IP convergence layer for use in the Internet might only have to add message boundaries to TCP streams, whereas a convergence layer for some network where no reliable transport protocol exists might be considerably more complex (e.g., it might have to implement reliability, fragmentation, flow-control, etc.) if reliable delivery is to be offered to the bundle layer.
1つのコンバージェンスレイヤーの複雑さは、適応する基本的なプロトコルのタイプに応じて、別のコンバージェンスレイヤーとはかなり異なる場合があります。たとえば、インターネットで使用するTCP / IPコンバージェンスレイヤーは、TCPストリームにメッセージ境界を追加するだけでよい場合がありますが、信頼できるトランスポートプロトコルが存在しないネットワークのコンバージェンスレイヤーは、かなり複雑になる場合があります（たとえば、信頼性、フラグメンテーション、フロー制御などを実装します。バンドルレイヤーに信頼性の高い配信が提供される場合。
As convergence layers implement protocols above and beyond the basic bundle protocol specified in [BSPEC], they will be defined in their own documents (in a fashion similar to the way encapsulations for IP datagrams are specified on a per-underlying-protocol basis, such as in RFC 894 [RFC894]).
コンバージェンスレイヤーは、[BSPEC]で指定された基本的なバンドルプロトコルを超えてプロトコルを実装するため、独自のドキュメントで定義されます（IPデータグラムのカプセル化が、基礎となるプロトコルごとに指定されるのと同様の方法など）。 RFC 894 [RFC894]のように）。
The DTN architecture addresses many of the problems of heterogeneous networks that must operate in environments subject to long delays and discontinuous end-to-end connectivity. It is based on asynchronous messaging and uses postal mail as a model of service classes and delivery semantics. It accommodates many different forms of connectivity, including scheduled, predicted, and opportunistically connected delivery paths. It introduces a novel approach to end-to-end reliability across frequently partitioned and unreliable networks. It also proposes a model for securing the network infrastructure against unauthorized access.
DTNアーキテクチャは、長い遅延と不連続なエンドツーエンド接続の影響を受ける環境で動作する必要がある異種ネットワークの問題の多くに対処します。これは非同期メッセージングに基づいており、サービスクラスと配信セマンティクスのモデルとして郵便を使用します。スケジュールされた、予測された、日和見的に接続された配信パスを含む、さまざまな形式の接続に対応します。頻繁にパーティション分割され、信頼性の低いネットワーク全体でエンドツーエンドの信頼性を確保するための新しいアプローチを紹介します。また、不正アクセスからネットワークインフラストラクチャを保護するためのモデルも提案しています。
It is our belief that this architecture is applicable to many different types of challenged environments.
このアーキテクチャは、さまざまなタイプの問題のある環境に適用できると私たちは確信しています。
Security is an integral concern for the design of the Delay Tolerant Network Architecture, but its use is optional. Sections 3.6.1, 3.14, and 4.4 of this document present some factors to consider for securing the DTN architecture, but separate documents [DTNSOV] and [DTNSEC] define the security architecture in much more detail.
セキュリティは、Delay Tolerant Network Architectureの設計にとって不可欠な問題ですが、その使用はオプションです。このドキュメントのセクション3.6.1、3.14、および4.4は、DTNアーキテクチャを保護するために考慮すべきいくつかの要素を示していますが、個別のドキュメント[DTNSOV]および[DTNSEC]は、セキュリティアーキテクチャをより詳細に定義しています。
This document specifies the architecture for Delay Tolerant Networking, which uses Internet-standard URIs for its Endpoint Identifiers. URIs intended for use with DTN should be compliant with the guidelines given in [RFC3986].
このドキュメントでは、エンドポイント識別子にインターネット標準のURIを使用する遅延許容ネットワークのアーキテクチャを指定します。 DTNでの使用を目的としたURIは、[RFC3986]で提供されているガイドラインに準拠している必要があります。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[IPN01] InterPlaNetary Internet Project, Internet Society IPN Special Interest Group, http://www.ipnsig.org.
[IPN01] InterPlaNetary Internet Project、Internet Society IPN Special Interest Group、http：//www.ipnsig.org。
[SB03] S. Burleigh, et al., "Delay-Tolerant Networking - An Approach to Interplanetary Internet", IEEE Communications Magazine, July 2003.
[SB03] S.バーレイ他、「遅延耐性ネットワーキング-惑星間インターネットへのアプローチ」、IEEE Communications Magazine、2003年7月。
[FW03] F. Warthman, "Delay-Tolerant Networks (DTNs): A Tutorial v1.1", Wartham Associates, 2003. Available from http://www.dtnrg.org.
[FW03] F. Warthman、「Delay-Tolerant Networks（DTNs）：A Tutorial v1.1」、Wartham Associates、2003。http：//www.dtnrg.orgから入手できます。
[KF03] K. Fall, "A Delay-Tolerant Network Architecture for Challenged Internets", Proceedings SIGCOMM, Aug 2003.
[KF03] K.フォール、「チャレンジドインターネットのための遅延耐性ネットワークアーキテクチャ」、Proceedings SIGCOMM、2003年8月。
[JFP04] S. Jain, K. Fall, R. Patra, "Routing in a Delay Tolerant Network", Proceedings SIGCOMM, Aug/Sep 2004.
[JFP04] S.ジェイーン、K。フォール、R。パトラ、「遅延耐性ネットワークでのルーティング」、Proceedings SIGCOMM、2004年8月/ 9月。
[DFS02] R. Durst, P. Feighery, K. Scott, "Why not use the Standard Internet Suite for the Interplanetary Internet?", MITRE White Paper, 2002. Available from http://www.ipnsig.org/reports/TCP_IP.pdf.
[DFS02] R.ダースト、P。フィーグリー、K。スコット、「惑星間インターネットに標準インターネットスイートを使用しないのはなぜですか」、MITREホワイトペーパー、2002年。http：//www.ipnsig.org/reports/から入手可能TCP_IP.pdf。
[CK74] V. Cerf, R. Kahn, "A Protocol for Packet Network Intercommunication", IEEE Trans. on Comm., COM-22(5), May 1974.
[CK74] V.サーフ、R。カーン、「パケットネットワークの相互通信のためのプロトコル」、IEEEトランス。通信、COM-22（5）、1974年5月。
[IGE00] C. Intanagonwiwat, R. Govindan, D. Estrin, "Directed Diffusion: A Scalable and Robust Communication Paradigm for Sensor Networks", Proceedings MobiCOM, Aug 2000.
[IGE00] C. Intanagonwiwat、R。Govindan、D。Estrin、「Directed Diffusion：A Scalable and Robust Communication Paradigm for Sensor Networks」、Proceedings MobiCOM、2000年8月。
[WSBL99] W. Adjie-Winoto, E. Schwartz, H. Balakrishnan, J. Lilley, "The Design and Implementation of an Intentional Naming System", Proc. 17th ACM SOSP, Kiawah Island, SC, Dec. 1999.
[WSBL99] W. Adjie-Winoto、E。Schwartz、H。Balakrishnan、J。Lilley、「意図的な命名システムの設計と実装」、Proc。 17番目のACM SOSP、サウスカロライナ州カイワー島、1999年12月。
[CT90] D. Clark, D. Tennenhouse, "Architectural Considerations for a New Generation of Protocols", Proceedings SIGCOMM, 1990.
[CT90] D.クラーク、D。テネンハウス、「新世代のプロトコルに関するアーキテクチャの考慮事項」、Proceedings SIGCOMM、1990。
[ISCHEMES] IANA, Uniform Resource Identifer (URI) Schemes, http://www.iana.org/assignments/uri-schemes.html.
[ISCHEMES] IANA、Uniform Resource Identifer（URI）Schemes、http：//www.iana.org/assignments/uri-schemes.html。
[JDPF05] S. Jain, M. Demmer, R. Patra, K. Fall, "Using Redundancy to Cope with Failures in a Delay Tolerant Network", Proceedings SIGCOMM, 2005.
[JDPF05] S.ジェイン、M。デマー、R。パトラ、K。フォール、「冗長性を使用した遅延耐性ネットワークの障害への対処」、Proceedings SIGCOMM、2005年。
[WJMF05] Y. Wang, S. Jain, M. Martonosi, K. Fall, "Erasure Coding Based Routing in Opportunistic Networks", Proceedings SIGCOMM Workshop on Delay Tolerant Networks, 2005.
[WJMF05] Y.ワン、S。ジェイン、M。マルトノシ、K。フォール、「日和見ネットワークにおける消失符号化ベースのルーティング」、遅延耐性ネットワークに関するProceedings SIGCOMM Workshop、2005年。
[ZAZ05] W. Zhao, M. Ammar, E. Zegura, "Multicast in Delay Tolerant Networks", Proceedings SIGCOMM Workshop on Delay Tolerant Networks, 2005.
[ZAZ05] W. Zhao、M。Ammar、E。Zegura、「遅延耐性ネットワークでのマルチキャスト」、Proceedings SIGCOMM Workshop on Delay Tolerant Networks、2005年。
[LFC05] J. Leguay, T. Friedman, V. Conan, "DTN Routing in a Mobility Pattern Space", Proceedings SIGCOMM Workshop on Delay Tolerant Networks, 2005.
[LFC05] J.レグアイ、T。フリードマン、V。コナン、「モビリティパターン空間でのDTNルーティング」、Proceedings SIGCOMM Workshop on Delay Tolerant Networks、2005年。
[AF03] J. Alonso, K. Fall, "A Linear Programming Formulation of Flows over Time with Piecewise Constant Capacity and Transit Times", Intel Research Technical Report IRB-TR-03-007, June 2003.
[AF03] J.アロンソ、K。フォール、「区分的定容量および通過時間を伴う経時的なフローの線形プログラミング定式化」、インテルリサーチテクニカルレポートIRB-TR-03-007、2003年6月。
[FHM03] K. Fall, W. Hong, S. Madden, "Custody Transfer for Reliable Delivery in Delay Tolerant Networks", Intel Research Technical Report IRB-TR-03-030, July 2003.
[FHM03] K.フォール、W。ホン、S。マッデン、「遅延耐性ネットワークにおける信頼できる配信のための管理転送」、インテルリサーチテクニカルレポートIRB-TR-03-030、2003年7月。
[BSPEC] K. Scott, S. Burleigh, "Bundle Protocol Specification", Work in Progress, December 2006.
[BSPEC] K.スコット、S。バーレイ、「バンドルプロトコル仕様」、進行中の作業、2006年12月。
[DTNSEC] S. Symington, S. Farrell, H. Weiss, "Bundle Security Protocol Specification", Work in Progress, October 2006.
[DTNSEC] S.シミントン、S。ファレル、H。ワイス、「バンドルセキュリティプロトコル仕様」、進行中の作業、2006年10月。
[DTNSOV] S. Farrell, S. Symington, H. Weiss, "Delay-Tolerant Networking Security Overview", Work in Progress, October 2006.
[DTNSOV] S. Farrell、S。Symington、H。Weiss、「遅延耐性のあるネットワークセキュリティの概要」、進行中の作業、2006年10月。
[DBFJHP04] M. Demmer, E. Brewer, K. Fall, S. Jain, M. Ho, R. Patra, "Implementing Delay Tolerant Networking", Intel Research Technical Report IRB-TR-04-020, Dec. 2004.
[DBFJHP04] M. Demmer、E。Brewer、K。Fall、S。Jain、M。Ho、R。Patra、「Implementing Delay Tolerant Networking」、インテルリサーチテクニカルレポートIRB-TR-04-020、2004年12月。
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC792] Postel、J。、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、1981年9月。
[RFC894] Hornig, C., "A Standard for the Transmission of IP Datagrams over Ethernet Networks", STD 41, RFC 894, April 1 1984.
[RFC894] Hornig、C。、「イーサネットネットワークを介したIPデータグラムの送信に関する標準」、STD 41、RFC 894、1984年4月1日。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960]スチュワート、R。、シェイ、Q。、モーノー、K。、シャープ、C。、シュワルツバウアー、H。、テイラー、T。、リティナ、I。、カラ、M。、チャン、L.、V 。Paxson、「Stream Control Transmission Protocol」、RFC 2960、2000年10月。
[RFC4088] Black, D., McCloghrie, K., and J. Schoenwaelder, "Uniform Resource Identifier (URI) Scheme for the Simple Network Management Protocol (SNMP)", RFC 4088, June 2005.
[RFC4088] Black、D.、McCloghrie、K。、およびJ. Schoenwaelder、「Uniform Resource Identifier（URI）Scheme for the Simple Network Management Protocol（SNMP）」、RFC 4088、2005年6月。
[S05] K. Scott, "Disruption Tolerant Networking Proxies for On-the-Move Tactical Networks", Proc. MILCOM 2005 (unclassified track), Oct. 2005.
[S05] K.スコット、「移動中の戦術ネットワークのための耐障害性ネットワーキングプロキシ」、Proc。 MILCOM 2005（未分類のトラック）、2005年10月。
[T02] W. Thies, et al., "Searching the World Wide Web in Low-Connectivity Communities", Proc. WWW Conference (Global Community track), May 2002.
[T02] W. Thies、et al。、 "Searching the World Wide Web in Low-Connectivity Communitys"、Proc。 WWWカンファレンス（グローバルコミュニティトラック）、2002年5月。
John Wroclawski, David Mills, Greg Miller, James P. G. Sterbenz, Joe Touch, Steven Low, Lloyd Wood, Robert Braden, Deborah Estrin, Stephen Farrell, Melissa Ho, Ting Liu, Mike Demmer, Jakob Ericsson, Susan Symington, Andrei Gurtov, Avri Doria, Tom Henderson, Mark Allman, Michael Welzl, and Craig Partridge all contributed useful thoughts and criticisms to versions of this document. We are grateful for their time and participation.
ジョンブロツラフスキー、デビッドミルズ、グレッグミラー、ジェームズPGスターベンツ、ジョータッチ、スティーブンロウ、ロイドウッド、ロバートブレーデン、デボラエストリン、スティーブンファレル、メリッサホー、ティンリュー、マイクデマー、ヤコブエリクソン、スーザンシミントン、アンドレイグルトフ、アヴリドリア、トムヘンダーソン、マークオールマン、マイケルウェルズル、クレイグパートリッジは、このドキュメントのバージョンに対して有用な考えと批判を寄せてくれました。彼らの時間と参加に感謝します。
This work was performed in part under DOD Contract DAA-B07-00-CC201, DARPA AO H912; JPL Task Plan No. 80-5045, DARPA AO H870; and NASA Contract NAS7-1407.
この作業の一部は、DOD契約DAA-B07-00-CC201、DARPA AO H912に基づいて行われました。 JPLタスクプラン番号80-5045、DARPA AO H870;およびNASA契約NAS7-1407。
Authors' Addresses
著者のアドレス
Dr. Vinton G. Cerf Google Corporation Suite 384 13800 Coppermine Rd. Herndon, VA 20171 Phone: +1 (703) 234-1823 Fax: +1 (703) 848-0727 EMail: vint@google.com
ビントンG.サーフGoogle Corporation Suite 384 13800 Coppermine Rd。バージニア州ハーンドン20171電話：+1（703）234-1823ファックス：+1（703）848-0727メール：vint@google.com
Scott C. Burleigh Jet Propulsion Laboratory 4800 Oak Grove Drive M/S: 179-206 Pasadena, CA 91109-8099 Phone: +1 (818) 393-3353 Fax: +1 (818) 354-1075 EMail: Scott.Burleigh@jpl.nasa.gov
スコットC.バーレイジェット推進研究所4800オークグローブドライブM / S：179-206 Pasadena、CA 91109-8099電話：+1（818）393-3353ファックス：+1（818）354-1075メール：Scott.Burleigh @ jpl.nasa.gov
Robert C. Durst The MITRE Corporation 7515 Colshire Blvd., M/S H440 McLean, VA 22102 Phone: +1 (703) 983-7535 Fax: +1 (703) 983-7142 EMail: durst@mitre.org
ロバートC.ダーストザマイターコーポレーション7515 Colshire Blvd.、M / S H440 McLean、VA 22102電話：+1（703）983-7535ファックス：+1（703）983-7142メール：durst@mitre.org
Dr. Kevin Fall Intel Research, Berkeley 2150 Shattuck Ave., #1300 Berkeley, CA 94704 Phone: +1 (510) 495-3014 Fax: +1 (510) 495-3049 EMail: kfall@intel.com
ケビンフォールインテルリサーチ、バークレー2150シャタックアベニュー、＃1300バークレー、カリフォルニア94704電話：+1（510）495-3014ファックス：+1（510）495-3049メール：kfall@intel.com
Adrian J. Hooke Jet Propulsion Laboratory 4800 Oak Grove Drive M/S: 303-400 Pasadena, CA 91109-8099 Phone: +1 (818) 354-3063 Fax: +1 (818) 393-3575 EMail: Adrian.Hooke@jpl.nasa.gov Dr. Keith L. Scott The MITRE Corporation 7515 Colshire Blvd., M/S H440 McLean, VA 22102 Phone: +1 (703) 983-6547 Fax: +1 (703) 983-7142 EMail: kscott@mitre.org
Adrian J. Hooke Jet Propulsion Laboratory 4800 Oak Grove Drive M / S：303-400 Pasadena、CA 91109-8099 Phone：+1（818）354-3063 Fax：+1（818）393-3575 Eメール：Adrian.Hooke @ jpl.nasa.gov Dr.キースL.スコットザマイターコーポレーション7515 Colshire Blvd.、M / S H440 McLean、VA 22102電話：+1（703）983-6547ファックス：+1（703）983-7142メール：kscott @ mitre.org
Leigh Torgerson Jet Propulsion Laboratory 4800 Oak Grove Drive M/S: 238-412 Pasadena, CA 91109-8099 Phone: +1 (818) 393-0695 Fax: +1 (818) 354-6825 EMail: ltorgerson@jpl.nasa.gov
Leigh Torgerson Jet Propulsion Laboratory 4800 Oak Grove Drive M / S：238-412 Pasadena、CA 91109-8099 Phone：+1（818）393-0695 Fax：+1（818）354-6825 EMail：ltorgerson@jpl.nasa。政府
Howard S. Weiss SPARTA, Inc. 7075 Samuel Morse Drive Columbia, MD 21046 Phone: +1 (410) 872-1515 x201 Fax: +1 (410) 872-8079 EMail: howard.weiss@sparta.com
ハワードS.ワイスSPARTA、Inc. 7075サミュエルモースドライブコロンビア、MD 21046電話：+1（410）872-1515 x201ファックス：+1（410）872-8079メール：howard.weiss@sparta.com
Please refer comments to dtn-interest@mailman.dtnrg.org. The Delay Tolerant Networking Research Group (DTNRG) web site is located at http://www.dtnrg.org.
コメントはdtn-interest@mailman.dtnrg.orgまでお寄せください。遅延耐性ネットワーク研究グループ（DTNRG）のWebサイトは、http：//www.dtnrg.orgにあります。
Full Copyright Statement
完全な著作権表示
Copyright (C) The IETF Trust (2007).
Copyright（C）IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP 78に含まれる権利、ライセンス、および制限の対象であり、ここに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または（もしあれば）組織、インターネット社会、IETFトラスト、およびインターネットエンジニアリングタスクフォースはすべてを否認します。明示または黙示を問わず、ここに含まれる情報の使用が商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害しないことを保証するものではありません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に対して行われたIPR開示のコピー、および使用可能にされるライセンスの保証、または一般ライセンスを取得する試みの結果、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得できるhttp://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この規格の実装に必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、利害関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。