RFC4838 日本語訳
4838 Delay-Tolerant Networking Architecture. V. Cerf, S. Burleigh, A.Hooke, L. Torgerson, R. Durst, K. Scott, K. Fall, H. Weiss. April 2007. (Format: TXT=89265 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
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
コメントを求めるワーキンググループV.サーフの要求をネットワークでつないでください: 4838年のGoogle/ジェット推進委研究所カテゴリ: 情報のS.のバーレイA.フックL.Torgerson NASA/ジェット推進委研究所のR.ダーストK.スコット斜め継ぎ社のK.インテル社H.ワイススパルタInc.4月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).
IETFが信じる著作権(C)(2007)。
IESG Note
IESG注意
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はインターネットResearch Task Forceの製品であり、インターネットStandardのどんなレベルの候補ではありません。 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
このドキュメントは、遅れ許容性があって分裂許容性があるネットワークのためにアーキテクチャについて説明して、元々Interplanetaryインターネット(宇宙空間探検を支持して惑星間の距離の向こう側にインターネットのようなサービスを提供するために思い描かれた通信系)に設計されたアーキテクチャの発展です。 このドキュメントは従来(インターネットのような)のネットワークアプローチを「非-実行可能」であるか非実用的にする操作上と性能特性を持っているインターネットワークに関するそのさまざまな問題を訴えるアーキテクチャについて説明します。 私たちは輸送(何らかの)層を超えてそれが存在するメッセージ指向のオーバレイを定義します。
Cerf, et al. Informational [Page 1] RFC 4838 Delay-Tolerant Networking Architecture April 2007
サーフ、他 ネットワークアーキテクチャ2007年4月に遅れ許容性がある情報[1ページ]のRFC4838
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
1. 序論…3 2. 遅れ許容性があるネットワークのためのなぜアーキテクチャ? ..............4 3. DTNの建築記述…5 3.1. ストアと先物取引を使用する仮想のメッセージ交換…5 3.2. ノードと終点…7 3.3. 終点識別子(EIDs)と登録証明書…8 3.4. Anycastとマルチキャスト…10 3.5. 優先権は属します…10 3.6. 郵便の様式配送オプションと管理記録。11 3.7. プライマリバンドル分野…15 3.8. ルート設定と推進…16 3.9. 断片化とReassembly…18 3.10. 信頼性と保護は移されます…19 3.11. DTNはプロキシと応用層のためにゲートウェイを支えます…21 3.12. タイムスタンプと時間同期化…22 3.13. バンドルにおける混雑とフロー制御は層にされます…22 3.14. セキュリティ…23 4. 管理問題を述べてください…25 4.1. アプリケーション登録状態…25 4.2. 保護転送状態…26 4.3. ルート設定と推進が状態であると添付してください…26 4.4. セキュリティ関連の状態…27 4.5. 方針と構成状態…27 5. アプリケーション構造問題…28 6. 基本的なプロトコルの使用のための集合層の問題…28 7. 概要…29 8. セキュリティ問題…29 9. IANA問題…30 10. 標準の参照…30 11. 有益な参照…30 12. 承認…32
Cerf, et al. Informational [Page 2] RFC 4838 Delay-Tolerant Networking Architecture April 2007
サーフ、他 ネットワークアーキテクチャ2007年4月に遅れ許容性がある情報[2ページ]のRFC4838
1. Introduction
1. 序論
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)のためにアーキテクチャについて説明します。 アーキテクチャは頻繁なパーティションに苦しむかもしれなくて、包括されるかもしれない分岐している1セット以上のプロトコルかプロトコルファミリーの時折接続されたネットワークの概念を受け入れます。 このアーキテクチャの基礎がInterplanetaryインターネットのものにあります。(インターネットは主として高い遅れ環境における宇宙空間コミュニケーションの問題に焦点を合わせました)。 私たちは、ここで説明された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 Identifier[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
バンドル層は元のアルパネット/インターネットデザイン[CK74]で説明されたゲートウェイのインターネット層と同様の機能性を提供します。 しかしながら、それは、層の不可知論者であり、パケット交換よりむしろ仮想のメッセージ推進に集中しているので、アルパネットゲートウェイと異なっています。 しかしながら、一般に、両方が1つに特定の基本的なプロトコルの間に相互運用性を提供します。
Cerf, et al. Informational [Page 3] RFC 4838 Delay-Tolerant Networking Architecture April 2007
サーフ、他 ネットワークアーキテクチャ2007年4月に遅れ許容性がある情報[3ページ]のRFC4838
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).
別のもの、および両方に特定の環境とそれらのプロトコルは、サービスを進めながら、店とフォワードを提供します(バンドル層で、店への永続的なストレージを使って、フォワードは機能します)。
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アプリケーションとして務めている応用層プロキシによってサポートされるかもしれません。
2. Why an Architecture for Delay-Tolerant Networking?
2. 遅れ許容性があるネットワークのためのなぜアーキテクチャ?
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]では、議論する)へまとめられる多くの設計原理に基づいて:
Cerf, et al. Informational [Page 4] RFC 4838 Delay-Tolerant Networking Architecture April 2007
サーフ、他 ネットワークアーキテクチャ2007年4月に遅れ許容性がある情報[4ページ]のRFC4838
- 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の詳細でこれらの問題について議論します。
3. DTN Architectural Description
3. DTNの建築記述
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アーキテクチャの定義を誘導する設計原理をまとめました。 このセクションは前述の設計原理によって誘導されたデザイン決定から生じるアーキテクチャの主要な特徴の記述を提示します。
3.1. Virtual Message Switching Using Store-and-Forward Operation
3.1. ストアと先物取引を使用する仮想のメッセージ交換
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
DTNによって可能にされたアプリケーションはまた、Application Data UnitsかADUs[CT90]と呼ばれる任意の長さのどんな実装制限も受けることがあるメッセージを送ります。 ADUsの相対オーダは保存されないかもしれません。 ADUsに通常発信して、配送します。
Cerf, et al. Informational [Page 5] RFC 4838 Delay-Tolerant Networking Architecture April 2007
サーフ、他 ネットワークアーキテクチャ2007年4月に遅れ許容性がある情報[5ページ]のRFC4838
applications in complete units, although a system interface that behaves differently is not precluded.
それが異なって振る舞わせるシステム・インタフェースは排除されませんが、完成品一式におけるアプリケーション。
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).
ADUsはバンドル層によってDTNノードによって進められる「バンドル」と呼ばれる1つ以上のプロトコルデータ単位以上に変えられます。 バンドルには、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).
バンドルソースと目的地は(可変長)の終点Identifiers(以下で説明されたEIDs)によって特定されます。(Identifiersはそれぞれバンドルの元の送り主と最終的な目的地を特定します)。 また、バンドルがaを含んでいる、「レポート、-、」 特殊作戦が任意の実体(例えば、ソースを除いた)に診断出力を向けるよう要求されているとき使用される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
バンドルは由来しているタイムスタンプ、役に立つ人生インディケータ、サービス指示子のクラス、および長さを含んでいます。 この情報はサイズに関する先験的な知識と要求されたデータ転送の性能要件をバンドル層のルーティングに提供します。 ネットワークで起こることができるかなりの量の列を作りがあるとき(店とフォワードのDTNバージョンでそうであるように)、作成スケジューリングと経路選択決定[JFP04]に、この情報を知っていることによって提供された利点は重要であるかもしれません。 代替の抽象化(すなわち、パケットに基づく流れのベースの配送の)はそうするでしょう。
Cerf, et al. Informational [Page 6] RFC 4838 Delay-Tolerant Networking Architecture April 2007
サーフ、他 ネットワーク構造2007年4月に遅れ許容性がある情報[6ページ]のRFC4838
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.
はるかに多くがそのような計画をであるのを難しくしてください。 パケットはバンドルと同じ利益のいくつかを提供しますが、より大きい集合はネットワークがアプリケーションにより役に立つユニットのデータにスケジューリングとバッファ管理を適用する方法を提供します。
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で混雑について議論します、そして、[DTNSEC]と[DTNSOV]でDTNノードが他のノードからの権限のない交通を扱うので我が身をかばう方法を含むセキュリティー対策について議論します。
3.2. Nodes and Endpoints
3.2. ノードと終点
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ノード(または、単にこのドキュメントの「ノード」)は送受信バンドルのためのエンジンです--バンドル層の実現。 アプリケーションがバンドルで運ばれたADUsを送るか、または受け取るのにDTNノードを利用する、(また、アプリケーションが代理であるのでDTNノードを使用する、レポート、-、目的地、バンドルで運ばれた診断情報) ノードは「DTN終点」と呼ばれるグループのメンバーであるかもしれません。 したがって、DTN終点は1セットのDTNノードです。 終点のノードの何らかの最小の部分集合が誤りなしでバンドルを受けたとき、バンドルによって首尾よくDTN終点に届けられたと考えられます。 この部分集合は終点の「最小のレセプショングループ」(MRG)と呼ばれます。 終点のMRGは1つのノード(ユニキャスト)、ノードのグループ(anycast)の1つかノードのグループのすべて(マルチキャストと放送)について言及するかもしれません。 ただ一つのノードが複数の終点のMRGにあるかもしれません。
Cerf, et al. Informational [Page 7] RFC 4838 Delay-Tolerant Networking Architecture April 2007
サーフ、他 ネットワーク構造2007年4月に遅れ許容性がある情報[7ページ]のRFC4838
3.3. Endpoint Identifiers (EIDs) and Registrations
3.3. 終点識別子(EIDs)と登録証明書
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.
Endpoint Identifier(EID)はDTN終点を特定するURI(以下を見る)の一般的な構文を使用することで表された名前です。 EIDを使用して、ノードはEIDによって指定されたDTN終点のMRGを決定できます。 また、各ノードが、唯一それを特定する少なくとも1EIDを持つのに必要です。
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のために運命づけられたADUsを送って、特定のEIDに送られたADUsのために彼らに渡されるように手配するかもしれません。 使用される(以下を見ます)EIDの構造によって、支給が、しばしば病気の特徴とルーティング目的の役に立つEIDの何らかの一部をwildcardingするようにあるかもしれません。
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のために運命づけられたADUsを受け取るアプリケーションの願望は、「登録」と呼ばれて、一般に、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.
登録を確立するアプリケーションの試みは、成功するように保証されません。 例えば、アプリケーションは、それがEndpoint IDを指定することによってADUsを受け取るためにそれ自体を登録するために、要求を修理するDTNノードを「非-解明でき」であるか、または入手できないよう要求するかもしれません。 そのような要求は失敗しそうです。
3.3.1. URI Schemes
3.3.1. URI計画
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.
それぞれのEndpoint 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[RFC4088]のURI計画を1つの例と考えます。) 計画特有の構文的、そして、意味的な制限がRFC3986の基本的なルールより多くの抑制であるかもしれないことに注意してください。 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を使用して、重要な柔軟性にEIDsの構造で達します。 それらは、例えば、DNS名に基づいて組み立てられるか、または似るかもしれません。
Cerf, et al. Informational [Page 8] RFC 4838 Delay-Tolerant Networking Architecture April 2007
サーフ、他 ネットワーク構造2007年4月に遅れ許容性がある情報[8ページ]のRFC4838
"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]における、「興味がある表現」か形式のデータベースのような質問。 名前として、EIDsによってルーティングか位相的な組織に関連される必要はありません。 しかしながら、そのような関係は禁止されていません、そして、EIDsを使用するいくつかの環境で、この道は有利であるかもしれません。
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は上に示されるように1つ以上のDTNノードを含む終点について言及するかもしれません。 それがノードのユニキャスト、マルチキャスト、またはanycastセットについて言及するかどうか決定するために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は米国-ASCII文字の組を使用して、RFC3986で指定された規則に基づいて構成されます。 しかしながら、米国-ASCIIによって代理をされることができないキャラクタに対処するとき、RFC3986、セクション1.2.1からこの抜粋に注意してください: 「この表現が計画の近く、または、URIが参照をつけられるプロトコル要素で許容されているなら、パーセントでコード化された八重奏(セクション2.1)は米国ASCIIコード化文字集合の範囲の外でキャラクタの代理をするのにURIの中で使用されるかもしれません。」 「そのような定義はURIのためにパーセントによってコード化されている前に、八重奏へのそれらのキャラクタを写像するのに使用されるキャラクタコード化を指定するべきです。」
3.3.2. Late Binding
3.3.2. 遅延バインディング
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
頻繁に外されたネットワークでは、メッセージのトランジット時間が結合の正当性時間を超えるかもしれないので、遅延バインディングは有利であるかもしれません、ソースで付くのを不可能であるか無効にして。 その上、遅延バインディングがある名前ベースのルーティングの使用が管理(マッピング)情報の量を減少させるかもしれない、それ
Cerf, et al. Informational [Page 9] RFC 4838 Delay-Tolerant Networking Architecture April 2007
サーフ、他 ネットワーク構造2007年4月に遅れ許容性がある情報[9ページ]のRFC4838
must propagate through the network, and may also limit the scope of mapping synchronization requirements to a local topological neighborhood where changes are made.
ネットワークを通して伝播しなければならなくて、また、マッピング同期要件の範囲を変更が行われる地方の位相的な地域に制限するかもしれません。
3.4. Anycast and Multicast
3.4. Anycastとマルチキャスト
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以上のサイズのグループを参照するとき、配送意味論はanycastかマルチキャストのバラエティーのものであるかもしれません(放送がマルチキャストのバラエティーのものであると考えられます)。 anycastグループ配送において、潜在的に多くのノードのグループの中と、そして、正常なDTNのクラスのサービスを条件として提供されるそれらのすべてに意図するマルチキャスト配送1つのノードと最大の役に立つ生涯意味論にバンドルを伝達します。
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のために発生しているかもしれません。 アプリケーションがこのデータのどれかを受け取るように、データは送付者の後に発信がやんでいた潜在的に長い時代にグループに利用可能でなければなりません。 したがって、データは、この種類の時のグループ意味論を支持するためにネットワークの中に格納される必要があるかもしれません。 これを設計して、どう実行するかは研究課題のままで残っています、それが問題が信頼できるマルチキャストに関連したのと少なくとも同じくらい困難である傾向があるように。
3.5. Priority Classes
3.5. 優先権のクラス
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構造は、ADUsを届けるために優先権(低くて、中型の、そして、高い)の*親類*基準を提供します。 これらのプライオリティは、ADUsのために配送緊急に影響するアプリケーションの願望に基づく交通を微分して、アプリケーションで指定された情報に基づくバンドル層で発生するバンドルブロックで運ばれます。
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.
(米国か同様)の郵便のServiceはDTN構造によって提供された推進抽象化で提供された優先権のクラスに強い比喩を提供します。 通信は、一般に、対話的でなく、しばしば片道です。 一般に、タイムリーな配送のどんな強い保証もありません、しかし、いくつかのフォームのサービス、信頼性、およびセキュリティのクラスがあります。
Cerf, et al. Informational [Page 10] RFC 4838 Delay-Tolerant Networking Architecture April 2007
サーフ、他 ネットワーク構造2007年4月に遅れ許容性がある情報[10ページ]のRFC4838
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.
- 一般に、他のクラスのバンドルの前に出荷します。速められました--そうでなければ、速められたバンドルは、同じです。
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.
バンドルの優先権のクラスは同じソースから他のバンドルに関連するだけでよいです。 これは、1つのソースからの高い優先権バンドルが異なったソースから中型の優先権バンドルより速さ(またはある他の優れたサービスの質で)に伝達されないかもしれないことを意味します。 それは、1つのソースからの高い優先権バンドルが優先的に同じソースから送られた低優先度バンドルに扱われることを意味します。
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ノードでは、どんな大量のバンドルの前にもソースの如何にかかわらずいつも速められたバンドルを送るかもしれません。 多くの変化が可能です。
3.6. Postal-Style Delivery Options and Administrative Records
3.6. 郵便の様式配送オプションと管理記録
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つのタイプの管理記録を定義します: 「現状報告」と「信号。」 これらの記録は他のバンドルの配送に関して情報を提供して、配送オプションに関連して使用されるバンドルです。
Cerf, et al. Informational [Page 11] RFC 4838 Delay-Tolerant Networking Architecture April 2007
サーフ、他 ネットワーク構造2007年4月に遅れ許容性がある情報[11ページ]のRFC4838
3.6.1. Delivery Options
3.6.1. 配送オプション
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.
- 保護Transfer Requested--高められた信頼性が保護転送手順を用いていて送られたバンドルが伝達されるよう要求します。 信頼できる転送プロトコルを使用することで(利用可能であるなら)送られたバンドルはバンドル層のそばで伝えられるでしょう、そして、目的地へのバンドルの信頼できる配信への責任は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).
- ソースNode Custody Acceptance Required--ソース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".
- レポートWhen Bundle Delivered--対象のADUを意図している受取人に届けるとき、(単一)のバンドルDelivery Status Reportを発生させるよう要求します。 また、この要求は「リターン領収書」として知られています。
- 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.
- ApplicationによるレポートWhen Bundle Acknowledged--対象のADUが受信アプリケーションで承認されるとき、Acknowledgement Status Reportが発生するよう要求します。 これは、受信アプリケーションの筋で起こるだけであり、Bundle Delivery Status Reportと異なっています。 それは、アプリケーションが応用層ゲートウェイのフォームとして機能しているかもしれないケースのために意図して、要求しているソースにおける、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.
- レポートWhen Bundle Received--それぞれの送られたバンドルがDTNノードに到着するとき、Bundle Reception Status Reportが発生するよう要求します。 これは主として診断目的で設計されています。
- 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.
- レポートWhen Bundle Custody Accepted--保護転送を使用することでそれぞれの送られたバンドルを受け入れたとき、Custody Acceptance Status Reportを発生させるよう要求します。 これは主として診断目的で設計されています。
Cerf, et al. Informational [Page 12] RFC 4838 Delay-Tolerant Networking Architecture April 2007
サーフ、他 ネットワーク構造2007年4月に遅れ許容性がある情報[12ページ]のRFC4838
- 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.
- レポートWhen Bundle Forwarded--それぞれの送られたバンドルが推進の後にDTNノードを去るとき、Bundle Forwarding Status Reportが発生するよう要求します。 これは主として診断目的で設計されています。
- 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.
- レポートWhen Bundle Deleted--それぞれの送られたバンドルがDTNノードで削除されるとき、Bundle Deletion Status Reportが発生するよう要求します。 これは主として診断目的で設計されています。
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.
- 秘密性Required--ソース以外のパーティーと目的地のメンバーから人工の秘密が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.
- すなわち、認証Required--、強く人工であることで送られたバンドルのバンドルブロックのすべての非無常の分野を必要とする、証明可能である、(暗号で、強さ、) これはソース、目的地EIDs、およびバンドルのデータを含むいくつかの分野を保護します。 その他の詳細に関してセクション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.
- 変更はそれぞれの非無常の分野にバンドルを送りました。誤りDetection Required--、必要である、高い確率が各目的地にある状態で検出可能に作られてください。
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).
管理記録は、状態情報かエラー条件がバンドル層に関連したと報告するのに使用されます。 定義された管理記録の2つのタイプがあります: 現状報告(BSRs)と保護信号を束ねてください。 管理記録は対応しています。IP[RFC792]のICMPプロトコルのメッセージへの(approximately)。 しかしながら、ICMPでは、メッセージをソースに返します。 DTNでは、それらが代わりに向けられる、レポート、-、BSRsのためのEIDと保護のための現在の管理人のEID(ソースのEIDと異なるかもしれない)は合図します。 ソースEIDがあるバンドルが管理記録を発生させるDTNノードに関連しているEIDsの1つにセットしたので、管理記録を送ります。 いくつかの場合、ただ一つのバンドルかバンドル断片の到着は複数の管理記録(例えば、バンドルがマルチキャスト推進のために模写される場合における)を引き出すかもしれません。
Cerf, et al. Informational [Page 13] RFC 4838 Delay-Tolerant Networking Architecture April 2007
サーフ、他 ネットワーク構造2007年4月に遅れ許容性がある情報[13ページ]のRFC4838
The following BSRs are currently defined (also see [BSPEC] for more details):
以下のBSRsは現在、定義されます(また、その他の詳細に関して[BSPEC]を見てください):
- Bundle Reception - sent when a bundle arrives at a DTN node.
Generation of this message may be limited by local policy.
- バンドルがDTNノードに到着するとき、送って、Receptionを束ねてください。 このメッセージの世代はローカルの方針で制限されるかもしれません。
- 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.
- 保護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.
- Report When Bundle Forwardedオプションを含むバンドルが進めた後にDTNノードから出発するとき、送って、Forwardedを束ねてください。 このメッセージの世代はローカルの方針で制限されるかもしれません。
- 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.
- Report When Bundle Deletedオプションを含むバンドルが捨てるとき、DTNノードから送って、Deletionを束ねてください。 これは満了などのいくつかの理由で起こることができます。 このメッセージの世代が、ローカルの方針で制限されるかもしれませんが、削除がバンドルの現在の管理人によって実行される場合で必要です。
- 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.
- アプリケーションでReport When Bundle Deliveredオプションを含む送られたバンドルを包括する完全なADUを消費するとき、最終的な受取人の(目的地)ノードから送って、Deliveryを束ねてください。
- 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.
- アプリケーションで、承認されました--Application Acknowledgmentオプションを含む送られたバンドルを包括する完全な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.
- 保護Signal--保護が首尾よく移されたのを示します。 この信号は、ブールインディケータとして現れて、したがって、うまくいっている試みか失敗した保護転送試みを示すかもしれません。
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で議論したトランスミッションタイムスタンプと一連番号に基づくバンドルを特定するための方法で達成されます。
Cerf, et al. Informational [Page 14] RFC 4838 Delay-Tolerant Networking Architecture April 2007
サーフ、他 ネットワーク構造2007年4月に遅れ許容性がある情報[14ページ]のRFC4838
3.7. Primary Bundle Fields
3.7. 第一のバンドル分野
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データ自体を含む)、および1セットの任意の拡大ブロックで設計されています。 ブロックは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).
- 創造Timestamp--同じソースから発する各ADUにユニークな状態で一連番号を単調に増加させるバンドルの創造時間とaの連結。 創造タイムスタンプはアプリケーションが、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.
- Service Flagsのクラス--バンドルのために配送オプションと優先権のクラスを示します。 優先権のクラスは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、(最終的な意図している受取人(s))。
- 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.
- レポート、-、Endpoint ID--レポート(リターン領収書、ルートをたどる機能)がどこに送られるべきであるかを特定するEID。 これは、同じ終点がSource 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]を見てください。
Cerf, et al. Informational [Page 15] RFC 4838 Delay-Tolerant Networking Architecture April 2007
サーフ、他 ネットワーク構造2007年4月に遅れ許容性がある情報[15ページ]のRFC4838
3.8. Routing and Forwarding
3.8. ルート設定と推進
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構造はユニキャスト、anycast、およびマルチキャストメッセージのためにバンドル層でルーティングと推進に枠組みを提供します。 DTNネットワークにおけるノードが1つ以上のタイプの基本的なネットワーク技術を使用することでインタコネクトされるかもしれないので、抽象的に、*小型輪転印刷機*(頭頂が1つ以上の縁でインタコネクトされるかもしれないグラフ)を使用することで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]のために。 しかしながら、接触のボリュームを最適に使用するのは大きいADUsとバンドルをより小さい発送可能単位に分割する能力を必要とします。 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グラフによる配送経路が損失性であるか接触率とボリュームが早めに正確に知られていないと、ルーティング計算は特にやりがいがあるようになります。 どうこれらの状況を扱うかは、遅れの許容性があるネットワークの(現れること)の研究領域での仕事の活動領域です。
3.8.1. Types of Contacts
3.8.1. 接触のタイプ
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:
接触はいくつかのカテゴリの1つに通常なります、主にそれらの性能の特性と何らかの動作がそれらを生み出すのに必要であるかどうかに関する予見性に基づきます。 これまで、以下の主要なタイプの接触は定義されました:
Cerf, et al. Informational [Page 16] RFC 4838 Delay-Tolerant Networking Architecture April 2007
サーフ、他 ネットワーク構造2007年4月に遅れ許容性がある情報[16ページ]のRFC4838
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かCable Modem接続などの'いつもオンな'インターネット接続はこのクラスの代表でしょう。
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).
要求での接触は、例示しますが、しつこい接触として終えられるまで機能するように何らかの動作を必要とします。 ダイアルアップ接続がOn-要求接触に関する例である、(少なくとも、ダイヤラーの観点から; それは以下のOpportunistic Contactとして見なされるかもしれません、ダイヤルアップサービスプロバイダーの観点から)
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.
予定されている接触は特定の持続時間のための特定の時に接触を確立する協定です。 予定されている接触に関する例は低い地球地球を周回する人工衛星とのリンクです。 衛星の視点回、能力、および潜在のスケジュールからノードの衛星との接触のリストを構成できます。 かなりの遅れがあるネットワークにおいて、「特定の時間」の概念が遅れ依存していることに注意してください。 例えば、地球と火星との単一の予定されている接触は、同じ瞬間に、各位置にないでしょうが、代わりに(非取るにたらない)の伝播遅延によって相殺されるでしょう。
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)と空港の中央ホールのキオスクの間には、別のタイプの便宜主義的な接触が赤外線かブルートゥース通信リンクであるかもしれません。 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
予測された接触は、むしろどんな固定した予定にも基づいていませんが、ありそうな接触回の予測と以前に観測された接触の歴史に基づく持続時間かある他の情報です。 予測された接触での十分すごい信用を考えて、ルートは考えます。
Cerf, et al. Informational [Page 17] RFC 4838 Delay-Tolerant Networking Architecture April 2007
サーフ、他 ネットワーク構造2007年4月に遅れ許容性がある情報[17ページ]のRFC4838
be chosen based on this information. This is an active research
area, and a few approaches having been proposed [LFC05].
この情報に基づいて、選ばれてください。 これは、アクティブな研究領域と、提案されたいくつかのアプローチ[LFC05]です。
3.9. Fragmentation and Reassembly
3.9. 断片化とReassembly
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ノードは、1ブロックのアプリケーションデータを複数の、よりわずかなブロックに分割して、独立しているバンドルのような各ブロックを送るかもしれません。 この場合、*最終的な目的地*は入って来るバンドルから、よりわずかなブロックを抜粋して、オリジナルの、より大きいバンドルと結局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の範囲からの)はオリジナルのバンドルの前半から成る新しいバンドルを形成して、それが適切であると考えるどんな次のホップにもそれを送ることができます。
Cerf, et al. Informational [Page 18] RFC 4838 Delay-Tolerant Networking Architecture April 2007
サーフ、他 ネットワーク構造2007年4月に遅れ許容性がある情報[18ページ]のRFC4838
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断片化を支持するのに必要です。 その上、典型的なバンドルサイズと比べて、わずかなボリュームとの接触に関して、データ配送livelockを防ぐのに何らかの増加の配送アプローチを使用しなければなりません(例えば、チェックポイント/再開)。 反応断片化はそのようなアプローチの1つですが、他のプロトコル層は潜在的にまた、この問題を扱うかもしれません。
3.10. Reliability and Custody Transfer
3.10. 信頼性と保護は移されます。
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]を遂行してください。 保護の正確な意味とデザインはマルチキャストのために移されます、そして、anycast配送は、完全に探検されるために残っています。
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
ソースは、保護転送で、「再-トランスミッション」責任を代表として派遣して、バンドルを送った後に、比較的早く、「再-トランスミッション」関連のリソースを回復します。(最初のバンドルへの最小の往復の現代の注文のときに、(s))を飛び越してください。 DTNのすべてのノードでない
Cerf, et al. Informational [Page 19] RFC 4838 Delay-Tolerant Networking Architecture April 2007
サーフ、他 ネットワーク構造2007年4月に遅れ許容性がある情報[19ページ]のRFC4838
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構造によって必要とされます。 例えば、いくつかのノードが、管理人として時々務めることができるくらいの格納リソースを持っていますが、パワーに充血するか、または不足しているとき、そのようなサービスを提供しないのを選ぶかもしれません。
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ルーティングが実行される方法を変更できます。 いくつかの事情では、管理人がある他の届いているノードよりバンドルの最終的な目的地からさらに遠さ(距離、時間または何らかのルーティングメートル法の)にいても、できるだけはやくバンドルを管理人に動かすのは有益であるかもしれません。 この能力でシステムを設計するのは、1つ以上のルーティンググラフを作図することを伴って、継続的な研究の領域です。
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.
ノードがCustody Transfer Requestedオプションを含むバンドルのための保護を受け入れるとき、バンドル層のそばで第一のバンドルブロックに保管されていたCurrent Custodian EIDにCustody Transfer Accepted Signalを送ります。 さらに、バンドルを進める前に推進ノードの(ユニキャスト)EIDsの1つを含むようにCurrent Custodian EIDをアップデートします。
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
アプリケーションが、保護転送と共に渡されるようADUに要求するとき、要求は顧問です。 いくつかの事情では、保護転送が要求されているバンドルの源はこのサービスを提供できないかもしれません。 そのような事情では、管理人を得る前に対象のバンドルは複数のDTNノードを横断するかもしれません。 特に、この状態のバンドルはそれらのCurrent Custodian EID分野セットでヌル終点にマークされます。 アプリケーションが、ソースがバンドルの保護を取るのを必要としたがっている場合では、それらはSource Node Custody Acceptance Requiredを供給するかもしれません。
Cerf, et al. Informational [Page 20] RFC 4838 Delay-Tolerant Networking Architecture April 2007
サーフ、他 ネットワーク構造2007年4月に遅れ許容性がある情報[20ページ]のRFC4838
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.
配送オプション。 これが保護の連続した「チェーン」を望んでいるアプリケーションの役に立つかもしれませんか、またはそれらのデータが確実にされた後に出るというその願望は管理人で安全に保たれます。
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ネットワーク、1つ、方向上です(そして、逆にすることができません)、DTN保護トランスファ・メカニズムは保護信号(または、いかなる他の情報も)を経路の向こう側に受け取って戻すどんな方法の不足のためもそのようなホップの上で影響を受けるでしょう、片道ホップへのイングレスにおけるバンドルの満了をもたらして。 この状況は、必ずバンドルが失われたことを意味するというわけではありません。 ホップの反対側の上のノードは、保護を移し続けるかもしれません、そして、首尾よく送付先にバンドルを伝達するかもしれません。 しかしながら、この状況では、それがこのバンドルのために満了BSRsを受け取るよう要求した情報筋は、バンドルのための満了レポートを受け取って、ことによるとバンドルが捨てられて、伝達されていないと結論づけるでしょう(不当に)。 この状況で完全にこの問題を解決できるというわけではありませんが、バンドルが片道ホップの上に移した後に期限が切れるとき報告されるかもしれない外観上不正確な情報を改善するのを助けるためにメカニズムを提供します。 これはイングレスにおけるノードによってバンドル現状報告の異形を使用することで知られている一方通行の経路の存在を報告する片道ホップに達成されます。 対象のバンドルが'レポートWhen Bundle Forwarded'配送オプションを使用することでレポートを要求するなら、これらのタイプのレポートを提供します。
3.11. DTN Support for Proxies and Application Layer Gateways
3.11. プロキシのDTNサポートと応用層ゲートウェイ
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 ADUsを受けることの結果、開始された非DTNプロトコル操作の成否に合図するためにリモート応用層ゲートウェイに一般的な道で備えます。 この能力がなければ、そのようなインディケータはアプリケーション自体で標準的でない方法で実行されなければならないでしょう。
Cerf, et al. Informational [Page 21] RFC 4838 Delay-Tolerant Networking Architecture April 2007
サーフ、他 ネットワーク構造2007年4月に遅れ許容性がある情報[21ページ]のRFC4838
3.12. Timestamps and Time Synchronization
3.12. タイムスタンプと時間同期化
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.
バンドル識別と満了は、創造タイムスタンプと明白な満了野原(ソースタイムスタンプの何秒も後に言い表される)を各バンドルに置くことによって、支持されます。 彼らが何らかのシステム・インタフェース機能で受けるADUsのアプリケーションを消費すると、到着バンドルに関する創作タイムスタンプは入手されます。 ADUに対応するバンドルの各セットが、送付者のEIDにユニークなタイムスタンプを含むのに必要です。 一緒にEID、タイムスタンプ、およびデータのオフセット/長さの情報は唯一バンドルを特定します。 ユニークなバンドル識別はバンドル断片の保護転送と再アセンブリを含む多くの目的に使用されます。
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のために運命づけられたADUsを受け取る願望を述べるとき、この登録は、有限期間の間、維持されるだけであり、アプリケーションで指定されるかもしれません。 また、マルチキャスト登録証明書として、アプリケーションは時間範囲か「関心間隔」を登録に指定するかもしれません。 この場合、結局、指定された間隔の間にいつでも指定されたEIDに送られた交通をアプリケーションに提供するでしょう(そのような交通がソースのアプリケーションで提供された満了時間のため期限が切れたか、またはある他の理由がそのような配送を防がない場合)。
3.13. Congestion and Flow Control at the Bundle Layer
3.13. バンドル層の混雑とフロー制御
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
このドキュメントの目的のために、私たちは送付ノードが受信ノードにデータを送る平均相場が受信ノードがその送付者からデータを受け取るように準備される平均相場を超えていないことを保証する手段と「フロー制御」を定義します。 (これがエンド・ツー・エンド通信だけに適用されるものよりむしろフロー制御の一般化された概念であることに注意してください。) 私たちはすべての交通源がネットワークにデータを注ぐ集合レートがそうしないことを保証する手段と「輻輳制御」を定義します。
Cerf, et al. Informational [Page 22] RFC 4838 Delay-Tolerant Networking Architecture April 2007
サーフ、他 ネットワークアーキテクチャ2007年4月に遅れ許容性がある情報[22ページ]のRFC4838
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.
輻輳制御は継続中の研究話題です。
3.14. Security
3.14. セキュリティ
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,
いくつかの遅れ許容性があるネットワークの厳しい資源不足の可能性は、何らかの形式のネットワーク自体への認証とアクセスコントロールが多くの事情で必要であると決めます。 権限のないユーザがトラフィックでネットワークを容易にあふれさせるのは、許容できません、ことによると認定ユーザに対するサービスを否定して。 多くの場合、また、全くあるネットワークリンクの上に権限のないトラフィックを送るのも許容できません。 エキゾチックで、ミッションクリティカルなリンクに、これは特に本当です。 これらの問題の観点から
Cerf, et al. Informational [Page 23] RFC 4838 Delay-Tolerant Networking Architecture April 2007
サーフ、他 ネットワークアーキテクチャ2007年4月に遅れ許容性がある情報[23ページ]のRFC4838
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に運ばれるか保存されていることを通してそれらのデータをするのを防いでください。
- 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.
低い遅れの、そして、関連している環境における操作のために設計された多くの既存の認証とアクセス制御プロトコルはDTNsでよく振る舞わないかもしれません。 特に、アクセスコントロールリストをアップデートして、資格証明書を取り消すのは(「ブラックリストに載せる」)特に難しいかもしれません。 また、認証か承認取引を完了するために集結されたサーバへの頻繁なアクセスを必要とするアプローチも魅力的ではありません。 これらの困難の結果はコミュニケーションの開始の遅れ、システム感染から検出して、回復する遅れ、および不適当なアクセスコントロールか認証設定のために取引を完了する遅れを含んでいます。
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
上に記載された目標によると、できるだけ早く認証かアクセス制御チェックが失敗するなら、DTNノードはトラフィックを捨てます。 このアプローチには、特定の高値のリンクの上に送るのから求められていないトラフィックを取り除くという目標を達成しますが、サービス不能攻撃をかなり困難にする関連利益がまたあります。
Cerf, et al. Informational [Page 24] RFC 4838 Delay-Tolerant Networking Architecture April 2007
サーフ、他 ネットワークアーキテクチャ2007年4月に遅れ許容性がある情報[24ページ]のRFC4838
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ノードで必要です。
For more detailed information on DTN security provisions, refer to [DTNSEC] and [DTNSOV].
DTNセキュリティ条項の、より詳細な情報について、[DTNSEC]と[DTNSOV]を参照してください。
4. State Management Considerations
4. 国家管理問題
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.
どんなネットワークアーキテクチャの重要な一面も状態のその管理です。 このセクションは、バンドル層で経営された状態について説明して、どうそれを設立して、取り除くかを論じます。
4.1. Application Registration State
4.1. アプリケーション登録状態
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.
長いか変化する遅れ環境で、非同期なアプリケーション・インターフェースは最も適切に見えます。 ある引き金となる出来事が起こるとき(例えば、ADUsはいつ到着しますか)、そのようなインタフェースはアプリケーションがコールバック動作を登録するメソッドを通常含んでいます。 これらの登録証明書はアプリケーション登録状態と呼ばれる州の情報を作成します。
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.
登録を開始して、その結果、アプリケーション登録状態を証明するために、アプリケーションはそれがADUsを受け取りたがっているEndpoint IDを指定します、登録がどれくらい長い間アクティブなままで残るべきであるかを示す任意の時間的価値と共に。 この操作は一般的なソケットAPIでのひも()操作にいくらか類似しています。
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に送られたADUsの創作倍の範囲について言及します。 その他の詳細において、セクション3.4が上であることを見てください。
Cerf, et al. Informational [Page 25] RFC 4838 Delay-Tolerant Networking Architecture April 2007
サーフ、他 ネットワークアーキテクチャ2007年4月に遅れ許容性がある情報[25ページ]のRFC4838
4.2. Custody Transfer State
4.2. 保護転送状態
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つ以上のために保護を移すと関連するプロトコル状態と同様に。 バンドルが受け取られているとき、会計関連の状態は創設されます。 「再-トランスミッション」が保護の転送が保護転送に伴うバンドルを進めることによって起こされるとき、引き起こされると述べる保護転送は、配送オプションが指定したよう要求しました。 Retransmission州と会計状態は1つ以上のCustody Transfer Succeeded信号を受け取り次第リリースされるかもしれません、保護が動かされたのを示して。 さらに、それが信号の領収書のため明らかに掃除されない場合システムがこの状態から追放されるとき、バンドルの満了時間(ことによるとローカルの方針で緩和される)は上限を提供します。
4.3. Bundle Routing and Forwarding State
4.3. バンドルルート設定と状態を進めること。
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])。 推進は1つのDTNノードから別のノードまでバンドルを動かす行為を示します。 ルート設定はルーティング状態(RIB、または情報ベースを発送する)を利用します、推進が、ルーティングから得られた状態を利用して、状態(FIB、または情報ベースを進める)を進めるとして維持されますが。 FIBの構造とそれを維持するための規則は実装選択です。 いくつかのDTNsでは、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の間の分離はこのドキュメントによって必要とされません、これらがシステムimplementersによって決められるべき実装の詳細であるので。 ルーティング・アルゴリズムの選択がまだ研究であります。
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
バンドルはかなりの時間、ノードにおける待ち行列を占領するかもしれません。 ユニキャストかanycast配送において、時間はバンドルがノードに到着する時、次のホップにそれを送ることができるときの間隔である傾向があります。 バンドルのマルチキャスト配送において、これはバンドルの満了時間までかなり長いかもしれません。 マルチキャスト配送が仲間に入るノードが以前にグループに送られた情報を得ることができるような方法で利用されるとき、この状況は起こります。 そのような場合、いくつかのノードが「アーカイバ」としてそれを機能させるかもしれません。
Cerf, et al. Informational [Page 26] RFC 4838 Delay-Tolerant Networking Architecture April 2007
サーフ、他 ネットワークアーキテクチャ2007年4月に遅れ許容性がある情報[26ページ]のRFC4838
provide copies of bundles to new participants that have already been delivered to other participants.
既に他の関係者に提供された新しい関係者にバンドルのコピーを提供してください。
4.4. Security-Related State
4.4. セキュリティ関連の状態
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.
基本的な終わりから終わりとホップごとの認証に加えて、アクセスコントロールはDTNで能力かアクセスコントロールリスト(ACLs)などの1つ以上のメカニズムによって使用されるかもしれません。 ACLsは安全保障政策を実施したがっているどんなノードの現在の状態の別のブロックも表すでしょう。 ACLsをノード構成時間に通常初期化して、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.
いくつかのDTNsが、セキュリティがホップごとの資格証明書をチェックすることに加えて終わりから終わりへの資格証明書がチェックされるかもしれないネットワークにおける選択されたノードによって励行される境界であると実装するかもしれません。 (そうするのは、ルーティングが各ADUを包括するすべてのバンドルがこれらのポイントを通して終わるのを保証するように調整されるのを必要とするかもしれません。) 終わりから終わりへの認証について確かめるのに使用される公開情報はこれらのポイントで通常キャッシュされるでしょう。
4.5. Policy and Configuration State
4.5. 方針と構成状態
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を見る)、使用、異なったプライオリティのバンドルがどう予定されるべきであるか、そして、ところ、およびバンドルと他のデータがどれくらい長い間保存されるか現状報告が生成されるかもしれない何や、どんなレートなどにおいてルーティング・プロトコルがあるかか否かに関係なく
Cerf, et al. Informational [Page 27] RFC 4838 Delay-Tolerant Networking Architecture April 2007
サーフ、他 ネットワークアーキテクチャ2007年4月に遅れ許容性がある情報[27ページ]のRFC4838
5. Application Structuring Issues
5. 問題を構造化するアプリケーション
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バンドル配送が遅れ許容性がある広範囲なネットワークタイプでのファッションで作動することを意図します。 これは*中の大きい遅れがネットワークであったならそこで*必須を意味しません。 **はそこでは、非常に重要な遅れでありますように。意味する、(送付者と意図している受取人(s))の間の断線の長期間を含んでいます。 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転送と比較して、人は、ファイルデータが流れることができるポイント[DFS02]に着くように束ねられたモデルが1で丸い旅行を終了できて、FTPファイルが操作を「置きました」が、最大8つの周遊旅行を取ることができるのを見ます。
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.
遅れ許容性があるアプリケーション設計の何らかの考慮が低い遅れ環境で合理的にうまくいって、高いか非常に変化する遅れ環境で異常に苦しまないアプリケーションをもたらすことができます。
6. Convergence Layer Considerations for Use of Underlying Protocols
6. 基本的なプロトコルの使用のための集合層の問題
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
DTN構造の実現経験はDTNノード[DBFJHP04]のために重要な建築構造物とインタフェースを明らかにしました。 異なったプロトコル家族におけるすべての基本的なプロトコルが同じ正確な機能性を提供するというわけではなくて、そうは、プロトコルかプロトコル家族あたりの進行中の何らかの追加適合か増大です。
Cerf, et al. Informational [Page 28] RFC 4838 Delay-Tolerant Networking Architecture April 2007
サーフ、他 ネットワーク構造2007年4月に遅れ許容性がある情報[28ページ]のRFC4838
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.
基礎が必要であるかもしれません。 この適合はバンドル層と基本的なプロトコルの間に置かれた1セットの集合層によって実行されます。 集合層は、特定の基本的なプロトコルに連結するプロトコル特有の詳細を管理して、バンドル層に一貫したインタフェースを提示します。
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データグラムのためのカプセル化がRFC894などのプロトコルの基礎となるのあたり1個のベース[RFC894]で指定される方法と同様のファッションによる)で定義されるでしょう。
7. Summary
7. 概要
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.
それはこの構造が多くの異なったタイプの挑戦された環境に適切であるという私たちの信念です。
8. Security Considerations
8. セキュリティ問題
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]は多くのその他の詳細でセキュリティー体系を定義します。
Cerf, et al. Informational [Page 29] RFC 4838 Delay-Tolerant Networking Architecture April 2007
サーフ、他 ネットワーク構造2007年4月に遅れ許容性がある情報[29ページ]のRFC4838
9. IANA Considerations
9. IANA問題
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].
このドキュメントはDelay Tolerant Networkingに構造を指定します。(Delay Tolerant NetworkingはEndpoint Identifiersにインターネット標準URIを使用します)。 DTNとの使用のために意図するURIは[RFC3986]でガイドラインを与えていて対応するべきです。
10. Normative References
10. 引用規格
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005.
[RFC3986] バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「一般的な構文」、STD66、RFC3986、2005年1月。
11. Informative References
11. 有益な参照
[IPN01] InterPlaNetary Internet Project, Internet Society IPN
Special Interest Group, http://www.ipnsig.org.
[IPN01]惑星間のインターネットプロジェクト、インターネット協会IPN特殊利益集団、 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、7月2003日
[FW03] F. Warthman, "Delay-Tolerant Networks (DTNs): A Tutorial
v1.1", Wartham Associates, 2003. Available from
http://www.dtnrg.org.
[FW03]F.Warthman、「遅れ許容性があるネットワーク(DTNs):」 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.
2003年8月の[KF03]K.秋、「挑戦されたインターネットのための遅れ許容性があるネットワークアーキテクチャ」議事SIGCOMM。
[JFP04] S. Jain, K. Fall, R. Patra, "Routing in a Delay Tolerant
Network", Proceedings SIGCOMM, Aug/Sep 2004.
[JFP04] S.ジャイナ教徒、K.秋、R.Patra、「遅れの許容性があるネットワークにおけるルート設定」、議事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.Feighery、K.スコット、「なぜInterplanetaryインターネットにStandardインターネットSuiteを使用しませんか?」、MITREホワイトPaper、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、移-. Commに関してCOM-22(5)、5月1974日
[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、「指示された拡散:」 「センサネットワークのためのスケーラブルで強健なコミュニケーションパラダイム」、議事MobiCOM、2000年8月。
Cerf, et al. Informational [Page 30] RFC 4838 Delay-Tolerant Networking Architecture April 2007
サーフ、他 ネットワーク構造2007年4月に遅れ許容性がある情報[30ページ]のRFC4838
[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.シュワルツ、H.Balakrishnan、J.リリー、「意図的な命名システムの設計と実装」、Proc。 第17ACM SOSP、Kiawah島、サウスカロライナ、1999年12月。
[CT90] D. Clark, D. Tennenhouse, "Architectural Considerations
for a New Generation of Protocols", Proceedings SIGCOMM,
1990.
[CT90] D.クラーク、D.Tennenhouse、「プロトコルの新しい世代建築問題」、議事SIGCOMM、1990。
[ISCHEMES] IANA, Uniform Resource Identifer (URI) Schemes,
http://www.iana.org/assignments/uri-schemes.html.
[ISCHEMES]IANA、一定のリソースIdentifer(URI)計画、 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.Demmer、R.Patra、K.秋、「遅れの許容性があるネットワークで失敗に対処するのに冗長を使用します」、議事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.Martonosi、K.秋、「消去コード化は便宜主義的なネットワークでルート設定を基礎づけた」遅れの許容性があるネットワーク、2005に関する議事SIGCOMMワークショップ。
[ZAZ05] W. Zhao, M. Ammar, E. Zegura, "Multicast in Delay
Tolerant Networks", Proceedings SIGCOMM Workshop on Delay
Tolerant Networks, 2005.
[ZAZ05] W.チャオ、M.Ammar、E.Zegura、「遅れの許容性があるネットワークにおけるマルチキャスト」、遅れの許容性があるネットワーク、2005に関する議事SIGCOMMワークショップ。
[LFC05] J. Leguay, T. Friedman, V. Conan, "DTN Routing in a
Mobility Pattern Space", Proceedings SIGCOMM Workshop on
Delay Tolerant Networks, 2005.
[LFC05] J.Leguay、T.フリードマン対コナン、「移動パターンスペースのDTNルート設定」、遅れの許容性があるネットワーク、2005に関する議事SIGCOMMワークショップ
[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-TR03-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.ファレル、S.サイミントン、「遅れ許容性があるネットワークセキュリティ概観」というH.ウィスは進歩、2006年10月に働いています。
Cerf, et al. Informational [Page 31] RFC 4838 Delay-Tolerant Networking Architecture April 2007
サーフ、他 ネットワーク構造2007年4月に遅れ許容性がある情報[31ページ]のRFC4838
[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.醸造者、K.は低下します、S.ジャイナ教徒、おーい、M.R.Patra、「遅れの許容性があるネットワークを実行し」て、インテル研究技術報告書IRB-TR-04-020、2004年12月。
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[RFC792] ポステル、J.、「インターネット・コントロール・メッセージ・プロトコル」、STD5、RFC792、1981年9月。
[RFC894] Hornig, C., "A Standard for the Transmission of IP
Datagrams over Ethernet Networks", STD 41, RFC 894, April
1 1984.
[RFC894] ホーニッグ、C.、「イーサネットネットワークの上のIPデータグラムの送信の規格」、STD41、RFC894(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.の、そして、鋭いMorneault、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カッラ、M.、チャン、L.、および「流れの制御伝動プロトコル」、RFC2960(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]は黒くします、McCloghrie、K.とJ.Schoenwaelder、「簡単なネットワーク管理プロトコル(SNMP)のUniform Resource Identifier(URI)計画」RFC4088、D.、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。 2005年10月のMILCOM2005(道を非分類しました)。
[T02] W. Thies, et al., "Searching the World Wide Web in Low-
Connectivity Communities", Proc. WWW Conference (Global
Community track), May 2002.
[T02] W.ティース、他、「低い接続性共同体をWWWを捜す」Proc。 2002年5月のWWWコンファレンス(グローバルなCommunityは追跡します)。
12. Acknowledgments
12. 承認
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.
ジョンWroclawski、デヴィッド・ミルズ、グレッグ・ミラー、ジェームスP.G.Sterbenz、ジョーTouch、スティーブンLow、ロイドWood、ロバート・ブレーデン、デボラEstrin、スティーブン・ファレル、メリッサHo、Tingリュウ、マイクDemmer、ジェイコブエリクソン、スーザン・サイミントン、アンドレイGurtov、Avriドーリア、トム・ヘンダーソン、マーク・オールマン、マイケルWelzl、およびクレイグPartridgeはこのドキュメントのバージョンに役に立つ考えと批評をすべて寄付しました。 私たちは彼らの時間と参加に感謝しています。
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 Contract DAA-B07-00-CC201、DARPA AO H912の下でこの仕事をしました。 DARPA AO H870、JPLはプランNo.80-5045に仕事を課します。 そして、NASA契約NAS7-1407。
Cerf, et al. Informational [Page 32] RFC 4838 Delay-Tolerant Networking Architecture April 2007
サーフ、他 ネットワーク構造2007年4月に遅れ許容性がある情報[32ページ]のRFC4838
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
Coppermine通り博士ビントンG.サーフGoogle社のスイート384 13800 ハーンドン、ヴァージニア 20171は以下に電話をします。 +1 (703) 234-1823Fax: +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 パサディナ、カリフォルニア91109-8099は以下に電話をします。 +1 (818) 393-3353Fax: +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
斜め継ぎ社7515のColshire Blvd.、ヴァージニア 22102が電話をするロバートC.ダーストM/S H440マクリーン: +1 (703) 983-7535Fax: +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
ケビン秋インテルResearch博士、バークレー2150シャタックAve、#1300バークレー、カリフォルニア 94704は以下に電話をします。 +1 (510) 495-3014Fax: +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
エードリアンJ.フックジェット推進委研究所4800オーク木立ドライブM/S: 303-400 パサディナ、カリフォルニア91109-8099は以下に電話をします。 +1 (818) 354-3063Fax: +1 (818) 393-3575 メールしてください: Adrian.Hooke@jpl.nasa.gov
Cerf, et al. Informational [Page 33] RFC 4838 Delay-Tolerant Networking Architecture April 2007
サーフ、他 ネットワーク構造2007年4月に遅れ許容性がある情報[33ページ]のRFC4838
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
キースL.スコット斜め継ぎ社7515Colshire Blvd.博士、ヴァージニア 22102が電話をするM/S H440マクリーン: +1 (703) 983-6547Fax: +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
リーTorgersonジェット推進委研究所4800オーク木立ドライブM/S: 238-412 パサディナ、カリフォルニア91109-8099は以下に電話をします。 +1 (818) 393-0695Fax: +1 (818) 354-6825 メールしてください: ltorgerson@jpl.nasa.gov
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
コロンビア、MD 21046が電話をするハワードS.ワイススパルタInc.7075サミュエルのモースドライブ: +1 (410)872-1515x201Fax: +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 をコメントを参照してください。 Delay Tolerant Networking Research Group(DTNRG)ウェブサイトは http://www.dtnrg.org に位置しています。
Cerf, et al. Informational [Page 34] RFC 4838 Delay-Tolerant Networking Architecture April 2007
サーフ、他 ネットワーク構造2007年4月に遅れ許容性がある情報[34ページ]のRFC4838
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Cerf, et al. Informational [Page 35]
サーフ、他 情報[35ページ]
一覧
スポンサーリンク
