RFC5050 日本語訳
5050 Bundle Protocol Specification. K. Scott, S. Burleigh. November 2007. (Format: TXT=120435 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Scott
Request for Comments: 5050 The MITRE Corporation
Category: Experimental S. Burleigh
NASA Jet Propulsion Laboratory
November 2007
コメントを求めるワーキンググループK.スコットの要求をネットワークでつないでください: 5050 斜め継ぎ社のカテゴリ: 実験的なS.バーレイNASAジェット推進委研究所2007年11月
Bundle Protocol Specification
バンドルプロトコル仕様
Status of This Memo
このメモの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
IESG Note
IESG注意
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
このRFCはインターネットStandardのどんなレベルの候補ではありません。 IETFは配備されたプロトコルとのセキュリティのようなもの、輻輳制御、または不適当な相互作用のために、どんな目的のためのこのRFCのフィットネスに関するどんな知識と発行するという決定がIETFレビューに基づいていないという特に注も放棄します。 RFC Editorは、自己判断でこのドキュメントを発表するのを選びました。 このドキュメントの読者は実現と展開のために値を評価する際に警戒するべきです。 詳しい情報に関してRFC3932を見てください。
Abstract
要約
This document describes the end-to-end protocol, block formats, and abstract service description for the exchange of messages (bundles) in Delay Tolerant Networking (DTN).
このドキュメントはDelay Tolerant Networking(DTN)のメッセージ(バンドル)の交換のための終わりから終わりへのプロトコル、ブロックフォーマット、および抽象的なサービス記述について説明します。
This document was produced within the IRTF's Delay Tolerant Networking Research Group (DTNRG) and represents the consensus of all of the active contributors to this group. See http://www.dtnrg.org for more information.
このドキュメントは、IRTFのDelay Tolerant Networking Research Group(DTNRG)の中で生産されて、活発な貢献者のすべてのコンセンサスをこのグループに表します。 詳しい情報に関して http://www.dtnrg.org を見てください。
Scott & Burleigh Experimental [Page 1] RFC 5050 Bundle Protocol Specification November 2007
スコットとバーレイの実験的な[1ページ]RFC5050バンドルは仕様2007年11月に議定書を作ります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Service Description . . . . . . . . . . . . . . . . . . . . . 5
3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Implementation Architectures . . . . . . . . . . . . . . . 9
3.3. Services Offered by Bundle Protocol Agents . . . . . . . . 11
4. Bundle Format . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Self-Delimiting Numeric Values (SDNVs) . . . . . . . . . . 12
4.2. Bundle Processing Control Flags . . . . . . . . . . . . . 13
4.3. Block Processing Control Flags . . . . . . . . . . . . . . 15
4.4. Endpoint IDs . . . . . . . . . . . . . . . . . . . . . . . 16
4.5. Formats of Bundle Blocks . . . . . . . . . . . . . . . . . 17
4.5.1. Primary Bundle Block . . . . . . . . . . . . . . . . . 19
4.5.2. Canonical Bundle Block Format . . . . . . . . . . . . 22
4.5.3. Bundle Payload Block . . . . . . . . . . . . . . . . . 23
4.6. Extension Blocks . . . . . . . . . . . . . . . . . . . . . 24
4.7. Dictionary Revision . . . . . . . . . . . . . . . . . . . 24
5. Bundle Processing . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Generation of Administrative Records . . . . . . . . . . . 25
5.2. Bundle Transmission . . . . . . . . . . . . . . . . . . . 26
5.3. Bundle Dispatching . . . . . . . . . . . . . . . . . . . . 26
5.4. Bundle Forwarding . . . . . . . . . . . . . . . . . . . . 27
5.4.1. Forwarding Contraindicated . . . . . . . . . . . . . . 28
5.4.2. Forwarding Failed . . . . . . . . . . . . . . . . . . 29
5.5. Bundle Expiration . . . . . . . . . . . . . . . . . . . . 29
5.6. Bundle Reception . . . . . . . . . . . . . . . . . . . . . 30
5.7. Local Bundle Delivery . . . . . . . . . . . . . . . . . . 31
5.8. Bundle Fragmentation . . . . . . . . . . . . . . . . . . . 32
5.9. Application Data Unit Reassembly . . . . . . . . . . . . . 33
5.10. Custody Transfer . . . . . . . . . . . . . . . . . . . . . 34
5.10.1. Custody Acceptance . . . . . . . . . . . . . . . . . . 34
5.10.2. Custody Release . . . . . . . . . . . . . . . . . . . 35
5.11. Custody Transfer Success . . . . . . . . . . . . . . . . . 35
5.12. Custody Transfer Failure . . . . . . . . . . . . . . . . . 35
5.13. Bundle Deletion . . . . . . . . . . . . . . . . . . . . . 36
5.14. Discarding a Bundle . . . . . . . . . . . . . . . . . . . 36
5.15. Canceling a Transmission . . . . . . . . . . . . . . . . . 36
5.16. Polling . . . . . . . . . . . . . . . . . . . . . . . . . 36
6. Administrative Record Processing . . . . . . . . . . . . . . . 37
6.1. Administrative Records . . . . . . . . . . . . . . . . . . 37
6.1.1. Bundle Status Reports . . . . . . . . . . . . . . . . 38
6.1.2. Custody Signals . . . . . . . . . . . . . . . . . . . 41
6.2. Generation of Administrative Records . . . . . . . . . . . 44
6.3. Reception of Custody Signals . . . . . . . . . . . . . . . 44
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 要件記法. . . . . . . . . . . . . . . . . . . . 4 3 記述. . . . . . . . . . . . . . . . . . . . . 5 3.1を修理してください。 定義. . . . . . . . . . . . . . . . . . . . . . . 5 3.2。 実現構造. . . . . . . . . . . . . . . 9 3.3。 バンドルによって提供されたサービスはエージェント. . . . . . . . 11 4について議定書の中で述べます。 形式. . . . . . . . . . . . . . . . . . . . . . . . 11 4.1を束ねてください。 自己を区切る数値は(SDNVs). . . . . . . . . . 12 4.2を評価します。 処理指揮旗. . . . . . . . . . . . . 13 4.3を束ねてください。 処理指揮旗. . . . . . . . . . . . . . 15 4.4を妨げてください。 終点ID. . . . . . . . . . . . . . . . . . . . . . . 16 4.5。 バンドルブロック. . . . . . . . . . . . . . . . . 17 4.5.1の形式。 第一のバンドルブロック. . . . . . . . . . . . . . . . . 19 4.5.2。 正準なバンドルブロックフォーマット. . . . . . . . . . . . 22 4.5.3。 有効搭載量ブロック. . . . . . . . . . . . . . . . . 23 4.6を束ねてください。 拡大は.244.7を妨げます。 辞書改正. . . . . . . . . . . . . . . . . . . 24 5。 処理. . . . . . . . . . . . . . . . . . . . . . 24 5.1を束ねてください。 管理記録. . . . . . . . . . . 25 5.2の世代。 トランスミッション. . . . . . . . . . . . . . . . . . . 26 5.3を束ねてください。 急. . . . . . . . . . . . . . . . . . . . 26 5.4ぎを束ねてください。 推進. . . . . . . . . . . . . . . . . . . . 27 5.4.1を束ねてください。 推進禁忌的な. . . . . . . . . . . . . . 28 5.4.2。 推進は.295.5に失敗しました。 満了. . . . . . . . . . . . . . . . . . . . 29 5.6を束ねてください。 レセプション. . . . . . . . . . . . . . . . . . . . . 30 5.7を束ねてください。 地方のバンドル配送. . . . . . . . . . . . . . . . . . 31 5.8。 断片化. . . . . . . . . . . . . . . . . . . 32 5.9を束ねてください。 アプリケーションデータユニットReassembly. . . . . . . . . . . . . 33 5.10。 保護転送. . . . . . . . . . . . . . . . . . . . . 34 5.10.1。 保護承認. . . . . . . . . . . . . . . . . . 34 5.10.2。 保護リリース. . . . . . . . . . . . . . . . . . . 35 5.11。 保護転送成功. . . . . . . . . . . . . . . . . 35 5.12。 保護転送失敗. . . . . . . . . . . . . . . . . 35 5.13。 削除. . . . . . . . . . . . . . . . . . . . . 36 5.14を束ねてください。 バンドル. . . . . . . . . . . . . . . . . . . 36 5.15を捨てます。 トランスミッション. . . . . . . . . . . . . . . . . 36 5.16を中止します。 世論調査. . . . . . . . . . . . . . . . . . . . . . . . . 36 6。 管理記録的な処理. . . . . . . . . . . . . . . 37 6.1。 管理記録. . . . . . . . . . . . . . . . . . 37 6.1.1。 現状報告. . . . . . . . . . . . . . . . 38 6.1.2を束ねてください。 保護は.416.2を示します。 管理記録. . . . . . . . . . . 44 6.3の世代。 保護信号. . . . . . . . . . . . . . . 44のレセプション
Scott & Burleigh Experimental [Page 2] RFC 5050 Bundle Protocol Specification November 2007
スコットとバーレイの実験的な[2ページ]RFC5050バンドルは仕様2007年11月に議定書を作ります。
7. Services Required of the Convergence Layer . . . . . . . . . . 44
7.1. The Convergence Layer . . . . . . . . . . . . . . . . . . 44
7.2. Summary of Convergence Layer Services . . . . . . . . . . 45
8. Security Considerations . . . . . . . . . . . . . . . . . . . 45
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
10.1. Normative References . . . . . . . . . . . . . . . . . . . 47
10.2. Informative References . . . . . . . . . . . . . . . . . . 47
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 49
Appendix B. Comments . . . . . . . . . . . . . . . . . . . . . . 49
7. サービスが集合層. . . . . . . . . . 44 7.1について必要です。 集合層. . . . . . . . . . . . . . . . . . 44 7.2。 集合層のサービス. . . . . . . . . . 45 8の概要。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 45 9。 IANA問題. . . . . . . . . . . . . . . . . . . . . 47 10。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 47 10.1。 引用規格. . . . . . . . . . . . . . . . . . . 47 10.2。 有益な参照. . . . . . . . . . . . . . . . . . 47付録A.貢献者. . . . . . . . . . . . . . . . . . . . 49付録B.コメント. . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction
1. 序論
This document describes version 6 of the Delay Tolerant Networking (DTN) "bundle" protocol (BP). Delay Tolerant Networking is an end- to-end architecture providing communications in and/or through highly stressed environments. Stressed networking environments include those with intermittent connectivity, large and/or variable delays, and high bit error rates. To provide its services, BP sits at the application layer of some number of constituent internets, forming a store-and-forward overlay network. Key capabilities of BP include:
このドキュメントはDelay Tolerant Networking(DTN)「バンドル」プロトコル(BP)のバージョン6について説明します。 終わりまで遅れTolerant Networkingは環境非常に圧力を加えられた環境を通してコミュニケーションを提供する終わりの構造です。 圧力を加えられたネットワーク環境は間欠接続性、大きい、そして/または、可変な遅れ、および高いビット誤り率があるそれらを含んでいます。 サービスを提供するために、BPは何らかの数の構成しているインターネットの応用層に座ります、店とフォワードオーバレイネットワークを形成して。 BPの主要な能力は:
o Custody-based retransmission
o 保護ベースの「再-トランスミッション」
o Ability to cope with intermittent connectivity
o 間欠接続性に対処する能力
o Ability to take advantage of scheduled, predicted, and
opportunistic connectivity (in addition to continuous
connectivity)
o 予定されていて、予測されて、便宜主義的な接続性を利用する能力(連続した接続性に加えた)
o Late binding of overlay network endpoint identifiers to
constituent internet addresses
o 構成しているインターネットアドレスへのオーバレイネットワーク終点識別子の遅延バインディング
For descriptions of these capabilities and the rationale for the DTN architecture, see [ARCH] and [SIGC]. [TUT] contains a tutorial-level overview of DTN concepts.
これらの能力の記述とDTN構造のための原理に関しては、[ARCH]と[SIGC]を見てください。 [TUT]はDTN概念の家庭教師のレベル概観を含んでいます。
This is an experimental protocol, produced within the IRTF's Delay Tolerant Networking Research Group (DTNRG) and represents the consensus of all of the active contributors to this group. If this protocol is used on the Internet, IETF standard protocols for security and congestion control should be used.
これは、実験プロトコルであり、IRTFのDelay Tolerant Networking Research Group(DTNRG)の中で生産して、活発な貢献者のすべてのコンセンサスをこのグループに表します。 このプロトコルがインターネットで使用されるなら、セキュリティと輻輳制御のためのIETF標準プロトコルは使用されるべきです。
BP's location within the standard protocol stack is as shown in Figure 1. BP uses the "native" internet protocols for communications within a given internet. Note that "internet" in the preceding is used in a general sense and does not necessarily refer to TCP/IP. The interface between the common bundle protocol and a specific
標準プロトコルスタックの中のBPの位置が図1に示されるようにあります。 BPはコミュニケーションに与えられたインターネットの中で「ネイティブ」のインターネットプロトコルを使用します。 先行における「インターネット」が一般的な意味では使用されて、必ずTCP/IPを示すというわけではないことに注意してください。 一般的なバンドルプロトコルと詳細とのインタフェース
Scott & Burleigh Experimental [Page 3] RFC 5050 Bundle Protocol Specification November 2007
スコットとバーレイの実験的な[3ページ]RFC5050バンドルは仕様2007年11月に議定書を作ります。
internetwork protocol suite is termed a "convergence layer adapter". Figure 1 shows three distinct transport and network protocols (denoted T1/N1, T2/N2, and T3/N3).
インターネットワークプロトコル群は「集合層のアダプター」と呼ばれます。 図1は3つの異なった輸送とネットワーク・プロトコル(T1/N1、T2/N2、およびT3/N3を指示する)を示しています。
+-----------+ +-----------+ | BP app | | BP app | +---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+ | BP v | | ^ BP v | | ^ BP v | | ^ BP | +---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+ | Trans1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ Trans3 | +---------v-+ +-^---------v-+ +-^---------v + +-^---------+ | Net1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ Net3 | +---------v-+ +-^---------v + +-^---------v-+ +-^---------+ | >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ | +-----------+ +-------------+ +-------------+ +-----------+ | | | | |<--- An internet --->| |<--- An internet --->| | | | |
+-----------+ +-----------+ | BP装置| | BP装置| +---------v| +、-、>>>>>>>>>>対++、-、>>>>>>>>>>v-++-^---------+ | BP v| | ^BP v| | ^BP v| | ^BP| +---------+-^対+---------+-^対+---------+-^対+---------+ | Trans1v| + ^ T1/T2 v | + ^ T2/T3 v | | ^Trans3| +---------+-^対+---------+-^対+---------+ +-^に対して---------+ | Net1v| | ^N1/N2v| | ^N2/N3v| | ^Net3| +---------+-^対+---------+ +-^に対して---------+-^対+---------+ | >>>>>>>>^>>>>>>>>>>^>>>>>>>>^| +-----------+ +-------------+ +-------------+ +-----------+ | | | | | <、-、-- インターネット--->| | <、-、-- インターネット--->|、|、|、|、|
Figure 1: The Bundle Protocol Sits at
the Application Layer of the Internet Model
図1: バンドルプロトコルはインターネットモデルの応用層に座ります。
This document describes the format of the protocol data units (called bundles) passed between entities participating in BP communications. The entities are referred to as "bundle nodes". This document does not address:
このドキュメントはBPコミュニケーションに参加しながら実体の間で通過されたプロトコルデータ単位(バンドルと呼ばれる)の形式について説明します。 実体は「バンドルノード」と呼ばれます。 このドキュメントは以下を記述しません。
o Operations in the convergence layer adapters that bundle nodes use
to transport data through specific types of internets. (However,
the document does discuss the services that must be provided by
each adapter at the convergence layer.)
o 集合における操作はバンドルノードが特定のタイプのインターネットを通してデータを輸送するのに使用するアダプターを層にします。 (しかしながら、ドキュメントは集合層の各アダプターで提供しなければならないサービスについて議論します。)
o The bundle routing algorithm.
o バンドルルーティング・アルゴリズム。
o Mechanisms for populating the routing or forwarding information
bases of bundle nodes.
o バンドルノードのルーティングか推進情報付け根に居住するためのメカニズム。
2. Requirements Notation
2. 要件記法
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Scott & Burleigh Experimental [Page 4] RFC 5050 Bundle Protocol Specification November 2007
スコットとバーレイの実験的な[4ページ]RFC5050バンドルは仕様2007年11月に議定書を作ります。
3. Service Description
3. サービス記述
3.1. Definitions
3.1. 定義
Bundle - A bundle is a protocol data unit of the DTN bundle
protocol. Each bundle comprises a sequence of two or more
"blocks" of protocol data, which serve various purposes. Multiple
instances of the same bundle (the same unit of DTN protocol data)
might exist concurrently in different parts of a network --
possibly in different representations -- in the memory local to
one or more bundle nodes and/or in transit between nodes. In the
context of the operation of a bundle node, a bundle is an instance
of some bundle in the network that is in that node's local memory.
バンドル--バンドルはDTNバンドルプロトコルのプロトコルデータ単位です。 各バンドルは2「ブロック」に関するプロトコルデータの系列を含みます。(データは様々な目的に役立ちます)。 同時に、同じバンドル(DTNプロトコルデータの同じユニット)の複数の例がノードの間にネットワークの異なった部分、異なった表現、1つ以上のバンドルノードへのローカルの記憶ことによるとトランジットで存在するかもしれません。 バンドルノードの操作の文脈では、バンドルはそのノードのローカルの記憶にあるネットワークにおける何らかのバンドルの例です。
Bundle payload - A bundle payload (or simply "payload") is the
application data whose conveyance to the bundle's destination is
the purpose for the transmission of a given bundle. The terms
"bundle content", "bundle payload", and "payload" are used
interchangeably in this document. The "nominal" payload for a
bundle forwarded in response to a bundle transmission request is
the application data unit whose location is provided as a
parameter to that request. The nominal payload for a bundle
forwarded in response to reception of that bundle is the payload
of the received bundle.
バンドルペイロード--バンドルペイロード(または、単に「ペイロード」)はバンドルの目的地への運送が与えられたバンドルの送信のための目的であるアプリケーションデータです。 用語「バンドル内容」、「バンドルペイロード」、および「ペイロード」は互換性を持って本書では使用されます。 バンドル送信要求に対応して進められたバンドルのための「名目上」のペイロードは位置がパラメタとしてその要求に提供されるアプリケーションデータ単位です。 そのバンドルのレセプションに対応して進められたバンドルのための名目上のペイロードは容認されたバンドルのペイロードです。
Fragment - A fragment is a bundle whose payload block contains a
fragmentary payload. A fragmentary payload is either the first N
bytes or the last N bytes of some other payload -- either a
nominal payload or a fragmentary payload -- of length M, such that
0 < N < M.
断片--断片はペイロードブロックが断片的なペイロードを含むバンドルです。 断片的なペイロードは、長さMのある他のペイロード(名目上のペイロードか断片的なペイロードのどちらか)の最初のNバイトかNバイトのどちらかであり、最後のそのようなものはその0<N<Mです。
Bundle node - A bundle node (or, in the context of this document,
simply a "node") is any entity that can send and/or receive
bundles. In the most familiar case, a bundle node is instantiated
as a single process running on a general-purpose computer, but in
general the definition is meant to be broader: a bundle node might
alternatively be a thread, an object in an object-oriented
operating system, a special-purpose hardware device, etc. Each
bundle node has three conceptual components, defined below: a
"bundle protocol agent", a set of zero or more "convergence layer
adapters", and an "application agent".
バンドルノード--バンドルノード(または、単にこのドキュメントの文脈の「ノード」)はバンドルを送る、そして/または、受けることができるあらゆる実体です。 最も身近な場合では、バンドルノードは汎用計算機で動くただ一つの過程として例示されますが、一般に、定義が、より広いことが意味されます: あるいはまた、バンドルノードは糸、オブジェクト指向オペレーティングシステムによる物、専用ハードウェアデバイスであるかもしれませんなど。 それぞれのバンドルノードには、以下で定義された3つの概念的なコンポーネントがあります: ゼロか以上の1セットの「バンドルプロトコルエージェント」「集合層のアダプター」、および「アプリケーションエージェント。」
Bundle protocol agent - The bundle protocol agent (BPA) of a node is
the node component that offers the BP services and executes the
procedures of the bundle protocol. The manner in which it does so
is wholly an implementation matter. For example, BPA
functionality might be coded into each node individually; it might
be implemented as a shared library that is used in common by any
バンドルプロトコルエージェント--ノードのバンドルプロトコルエージェント(BPA)は、BPサービスを提供するノードコンポーネントであり、バンドルプロトコルの手順を実行します。 それがそうする方法は完全に実現問題です。 例えば、BPAの機能性は個別に各ノードにコード化されるかもしれません。 それはいずれでも一般的で使用される共有ライブラリとして実行されるかもしれません。
Scott & Burleigh Experimental [Page 5] RFC 5050 Bundle Protocol Specification November 2007
スコットとバーレイの実験的な[5ページ]RFC5050バンドルは仕様2007年11月に議定書を作ります。
number of bundle nodes on a single computer; it might be
implemented as a daemon whose services are invoked via inter-
process or network communication by any number of bundle nodes on
one or more computers; it might be implemented in hardware.
単一のコンピュータの上のバンドルノードの数。 それはサービスが1台以上のコンピュータの上のいろいろなバンドルノードによって相互の過程かネットワークコミュニケーションで呼び出されるデーモンとして実行されるかもしれません。 それはハードウェアで実行されるかもしれません。
Convergence layer adapters - A convergence layer adapter (CLA) sends
and receives bundles on behalf of the BPA, utilizing the services
of some 'native' internet protocol that is supported in one of the
internets within which the node is functionally located. The
manner in which a CLA sends and receives bundles is wholly an
implementation matter, exactly as described for the BPA.
集合層のアダプター--集合層のアダプター(CLA)は、BPAを代表してバンドルを送って、受けます、ノードが機能上位置しているインターネットの1つでサポートされる何らかの'ネイティブ'のインターネットプロトコルのサービスを利用して。 CLAがバンドルを送って、受ける方法は完全に実現問題です、ちょうどBPAのために説明されるように。
Application agent - The application agent (AA) of a node is the node
component that utilizes the BP services to effect communication
for some purpose. The application agent in turn has two elements,
an administrative element and an application-specific element.
The application-specific element of an AA constructs, requests
transmission of, accepts delivery of, and processes application-
specific application data units; the only interface between the
BPA and the application-specific element of the AA is the BP
service interface. The administrative element of an AA constructs
and requests transmission of administrative records (status
reports and custody signals), and it accepts delivery of and
processes any custody signals that the node receives. In addition
to the BP service interface, there is a (conceptual) private
control interface between the BPA and the administrative element
of the AA that enables each to direct the other to take action
under specific circumstances. In the case of a node that serves
simply as a "router" in the overlay network, the AA may have no
application-specific element at all. The application-specific
elements of other nodes' AAs may perform arbitrarily complex
application functions, perhaps even offering multiplexed DTN
communication services to a number of other applications. As with
the BPA, the manner in which the AA performs its functions is
wholly an implementation matter; in particular, the administrative
element of an AA might be built into the library or daemon or
hardware that implements the BPA, and the application-specific
element of an AA might be implemented either in software or in
hardware.
アプリケーションエージェント--ノードのアプリケーションエージェント(AA)は何らかの目的のためのコミュニケーションに作用するのにBPサービスを利用するノードコンポーネントです。 アプリケーションエージェントには、2つの要素、管理要素、およびアプリケーション特有の要素が順番にあります。 AAのアプリケーション特有の要素が組み立てて、トランスミッションを要求して、荷渡しを承諾する、アプリケーション特定のアプリケーションデータ単位を処理する、。 BPAとAAのアプリケーション特有の要素との唯一のインタフェースがBPサービスインタフェースです。 AAの管理要素が管理記録(現状報告と保護信号)の伝達を構成して、要求して、それは、ノードが受信するというどんな保護信号も荷渡しを承諾して、処理します。 BPサービスインタフェースに加えて、それぞれが、特定の状況で行動を取るようもう片方に指示するのを可能にするAAのBPAと管理要素との(概念的)の個人的なコントロールインタフェースがあります。 単に「ルータ」としてオーバレイネットワークで機能するノードの場合では、AAはアプリケーション特有の要素を全く持っていないかもしれません。 他のノードのAAsのアプリケーション特有の要素は任意に複雑なアプリケーションの機能を実行するかもしれません、恐らく他の多くのアプリケーションへの多重送信されたDTN通信サービスを提供さえして。 BPAのように、AAが機能を実行する方法は完全に実現問題です。 特に、BPAを実行するライブラリ、デーモンまたはハードウェアがAAの管理要素に組み込まれるかもしれません、そして、AAのアプリケーション特有の要素はソフトウェアかハードウェアで実行されるかもしれません。
Bundle endpoint - A bundle endpoint (or simply "endpoint") is a set
of zero or more bundle nodes that all identify themselves for BP
purposes by some single text string, called a "bundle endpoint ID"
(or, in this document, simply "endpoint ID"; endpoint IDs are
described in detail in Section 4.4 below). The special case of an
endpoint that never contains more than one node is termed a
"singleton" endpoint; every bundle node must be a member of at
least one singleton endpoint. Singletons are the most familiar
バンドル終点--バンドル終点(または、単に「終点」)は1セットのゼロであるか以上がBP目的のために「バンドル終点ID」と呼ばれる何らかのただ一つのテキスト文字列で自分たちを特定するノードをすべて、束ねます(このドキュメント、単に「終点ID」で; 終点IDは以下のセクション4.4で詳細に説明されます)。 1つ以上のノードを決して含まない終点の特別なケースは「単独個体」終点と呼ばれます。 あらゆるバンドルノードが少なくとも1つの単独個体終点のメンバーであるに違いありません。 単独個体は最も身近です。
Scott & Burleigh Experimental [Page 6] RFC 5050 Bundle Protocol Specification November 2007
スコットとバーレイの実験的な[6ページ]RFC5050バンドルは仕様2007年11月に議定書を作ります。
sort of endpoint, but in general the endpoint notion is meant to
be broader. For example, the nodes in a sensor network might
constitute a set of bundle nodes that identify themselves by a
single common endpoint ID and thus form a single bundle endpoint.
*Note* too that a given bundle node might identify itself by
multiple endpoint IDs and thus be a member of multiple bundle
endpoints.
終点の種類、一般に、終点概念が、より広いことが意味されます。 例えば、センサネットワークにおけるノードはただ一つの一般的な終点IDで自分たちを特定して、その結果単一のバンドル終点を形成する1セットのバンドルノードを構成するかもしれません。 **また、与えられたバンドルノードが複数の終点IDでそれ自体を特定して、その結果、複数のバンドル終点のメンバーであるかもしれないことに注意してください。
Forwarding - When the bundle protocol agent of a node determines
that a bundle must be "forwarded" to an endpoint, it causes the
bundle to be sent to all of the nodes that the bundle protocol
agent currently believes are in the "minimum reception group" of
that endpoint. The minimum reception group of an endpoint may be
any one of the following: (a) ALL of the nodes registered in an
endpoint that is permitted to contain multiple nodes (in which
case forwarding to the endpoint is functionally similar to
"multicast" operations in the Internet, though possibly very
different in implementation); (b) ANY N of the nodes registered in
an endpoint that is permitted to contain multiple nodes, where N
is in the range from zero to the cardinality of the endpoint (in
which case forwarding to the endpoint is functionally similar to
"anycast" operations in the Internet); or (c) THE SOLE NODE
registered in a singleton endpoint (in which case forwarding to
the endpoint is functionally similar to "unicast" operations in
the Internet). The nature of the minimum reception group for a
given endpoint can be determined from the endpoint's ID (again,
see Section 4.4 below): for some endpoint ID "schemes", the nature
of the minimum reception group is fixed - in a manner that is
defined by the scheme - for all endpoints identified under the
scheme; for other schemes, the nature of the minimum reception
group is indicated by some lexical feature of the "scheme-specific
part" of the endpoint ID, in a manner that is defined by the
scheme.
ノードのバンドルプロトコルエージェントが、バンドルが終点に「進められなければならない」と決心しているときの推進、それで、その終点の「最小のレセプショングループ」にはあるバンドルプロトコルエージェントが、現在信じているノードのすべてにバンドルを送ります。 終点の最小のレセプショングループは以下のいずれであるかもしれませんも: (a) ノードのすべてが複数のノードを含むことが許可されている終点に登録しました(その場合、終点への推進は、インターネットにおいて「マルチキャスト」操作と機能上同様であって、もっとも、ことによると実現において非常に異なっています)。 (b) ノードのどんなNもNがゼロ〜終点の基数までの範囲にある(その場合、終点への推進はインターネットでの"anycast"操作と機能上同様です)複数のノードを含むことが許可されている終点に登録されました。 (c) または、THE SOLE NODEは単独個体終点に登録しました(その場合、終点への推進はインターネットでの「ユニキャスト」操作と機能上同様です)。 与えられた終点への最小のレセプショングループの本質は終点のIDから決定できます(もう一度、以下のセクション4.4を見てください): いくつかの終点ID「計画」において、最小のレセプショングループの本質は計画の下で特定されたすべての終点に計画によって定義される方法で固定されています。 他の計画において、最小のレセプショングループの本質は終点IDの「計画特有の部分」の何らかの語彙特徴によって示されます、計画によって定義される方法で。
Registration - A registration is the state machine characterizing a
given node's membership in a given endpoint. Any number of
registrations may be concurrently associated with a given
endpoint, and any number of registrations may be concurrently
associated with a given node. Any single registration must at any
time be in one of two states: Active or Passive. A registration
always has an associated "delivery failure action", the action
that is to be taken when a bundle that is "deliverable" (see
below) subject to that registration is received at a time when the
registration is in the Passive state. Delivery failure action
must be one of the following:
登録--登録は与えられた終点で与えられたノードの会員資格を特徴付ける州のマシンです。 いろいろな登録証明書が同時に与えられた終点に関連しているかもしれません、そして、いろいろな登録証明書が同時に、与えられたノードに関連しているかもしれません。 2つの州の1つでいつでもどんなただ一つの登録も以下の通りであるに違いありません。 アクティブであるか、または受け身です。 登録には、関連「配信障害動作」(登録がPassive状態にあるときその登録を条件とした「提出物」(以下を見る)であるバンドルを受け取るとき取ることになっている行動)がいつもあります。 配信障害動作は以下の1つであるに違いありません:
* defer "delivery" (see below) of the bundle subject to this
registration until (a) this bundle is the least recently
* (a) 最近このバンドルが最少になるまでこの登録を条件としてバンドルの「配送」(以下を見る)を延期してください。
Scott & Burleigh Experimental [Page 7] RFC 5050 Bundle Protocol Specification November 2007
スコットとバーレイの実験的な[7ページ]RFC5050バンドルは仕様2007年11月に議定書を作ります。
received of all bundles currently deliverable subject to this
registration and (b) either the registration is polled or else
the registration is in the Active state; or
受ける..バンドル..現在..提出物..登録..登録..投票..登録..状態 または
* "abandon" (see below) delivery of the bundle subject to this
registration.
* この登録を条件としたバンドルの「放棄」(以下を見る)配送。
An additional implementation-specific delivery deferral procedure
may optionally be associated with the registration. While the
state of a registration is Active, reception of a bundle that is
deliverable subject to this registration must cause the bundle to
be delivered automatically as soon as it is the least recently
received bundle that is currently deliverable subject to the
registration. While the state of a registration is Passive,
reception of a bundle that is deliverable subject to this
registration must cause delivery of the bundle to be abandoned or
deferred as mandated by the registration's current delivery
failure action; in the latter case, any additional delivery
deferral procedure associated with the registration must also be
performed.
追加実現特有の配送延期手順は任意に登録に関連しているかもしれません。 登録の状態はActiveですが、この登録への提出物の対象であるバンドルのレセプションで、それが最も最近でない容認されたバンドルであるとすぐに、自動的にバンドルを伝達しなければなりません。 登録の状態はPassiveですが、この登録への提出物の対象であるバンドルのレセプションは、登録の現在の配信障害動きで強制されるようにバンドルの配送が捨てられるか、または延期されることを引き起こさなければなりません。 また、後者の場合では、登録に関連しているどんな追加配送延期手順も実行しなければなりません。
Delivery - Upon reception, the processing of a bundle that has been
sent to a given node depends on whether or not the receiving node
is registered in the bundle's destination endpoint. If it is, and
if the payload of the bundle is non-fragmentary (possibly as a
result of successful payload reassembly from fragmentary payloads,
including the original payload of the received bundle), then the
bundle is normally "delivered" to the node's application agent
subject to the registration characterizing the node's membership
in the destination endpoint. A bundle is considered to have been
delivered at a node subject to a registration as soon as the
application data unit that is the payload of the bundle, together
with the value of the bundle's "Acknowledgement by application is
requested" flag and any other relevant metadata (an implementation
matter), has been presented to the node's application agent in a
manner consistent with the state of that registration and, as
applicable, the registration's delivery failure action.
配送--レセプションでは、与えられたノードに送られたバンドルの処理は受信ノードがバンドルの目的地終点に登録されるかどうかによります。 それがそうであり、バンドルのペイロードが非断片的であるなら(ことによると断片的なペイロードからのうまくいっているペイロード再アセンブリの結果、容認されたバンドルの元のペイロードを含んでいます)、通常、バンドルは目的地終点でノードの会員資格を特徴付ける登録を条件としてノードのアプリケーションエージェントに「渡されます」。 バンドルのペイロードであるアプリケーションデータユニットがバンドルの「承認はアプリケーションで要求されている」旗といかなる他の関連メタデータ(実現の件)の値と共にもその登録の状態と一致した方法と適切であるとしての登録の配信障害動作でノードのアプリケーションエージェントに提示されるとすぐに、ノードを登録を条件としてバンドルが果たされたと考えられます。
Deliverability, Abandonment - A bundle is considered "deliverable"
subject to a registration if and only if (a) the bundle's
destination endpoint is the endpoint with which the registration
is associated, (b) the bundle has not yet been delivered subject
to this registration, and (c) delivery of the bundle subject to
this registration has not been abandoned. To "abandon" delivery
of a bundle subject to a registration is simply to declare it no
longer deliverable subject to that registration; normally only
registrations' registered delivery failure actions cause
deliveries to be abandoned.
デリベラビリティ、Abandonment、--、バンドルが登録を条件とした「提出物」であると考えられる(a) バンドルの目的地終点である場合にだけ、関連づけられた登録、バンドルがまだこの登録を条件として伝達されていない(b)、およびこの登録を条件としたバンドルの(c)配送がどれでないかで捨てられなかった終点はそうです。 登録を条件としてバンドルの配送を「捨てること」は、それがもう提出物の対象であるとその登録に単に宣言することです。 通常登録証明書だけの登録された配信障害動作で、配送を捨てます。
Scott & Burleigh Experimental [Page 8] RFC 5050 Bundle Protocol Specification November 2007
スコットとバーレイの実験的な[8ページ]RFC5050バンドルは仕様2007年11月に議定書を作ります。
Deletion, Discarding - A bundle protocol agent "discards" a bundle
by simply ceasing all operations on the bundle and functionally
erasing all references to it; the specific procedures by which
this is accomplished are an implementation matter. Bundles are
discarded silently; i.e., the discarding of a bundle does not
result in generation of an administrative record. "Retention
constraints" are elements of the bundle state that prevent a
bundle from being discarded; a bundle cannot be discarded while it
has any retention constraints. A bundle protocol agent "deletes"
a bundle in response to some anomalous condition by notifying the
bundle's report-to endpoint of the deletion (provided such
notification is warranted; see Section 5.13 for details) and then
arbitrarily removing all of the bundle's retention constraints,
enabling the bundle to be discarded.
削除、Discarding--バンドルプロトコルエージェントはそれのすべての参照を消しながら、単にすべての操作をバンドルと機能上やめることによって、バンドルを「捨てます」。 これが優れている特定の手順は実現問題です。 バンドルは静かに捨てられます。 すなわち、バンドルを捨てることは管理記録の世代で結果として生じません。 「保有規制」はバンドルが捨てられるのを防ぐバンドル状態の要素です。 それにはどんな保有規制もある間、バンドルを捨てることができません。 バンドルプロトコルエージェントが通知するのによる何らかの変則的な状態に対応してバンドルを「削除する」、バンドルのもの、レポート、-、終点、削除(提供されたそのような通知は保証されます; 詳細に関してセクション5.13を見る)と次に、バンドルが捨てられるのを可能にして、任意にバンドルの保有規制のすべてを取り除くのについて。
Transmission - A transmission is a sustained effort by a node's
bundle protocol agent to cause a bundle to be sent to all nodes in
the minimum reception group of some endpoint (which may be the
bundle's destination or may be some intermediate forwarding
endpoint) in response to a transmission request issued by the
node's application agent. Any number of transmissions may be
concurrently undertaken by the bundle protocol agent of a given
node.
トランスミッション--トランスミッションは、ノードのアプリケーションエージェントによって発行された送信要求に対応してバンドルがいくつかの終点(バンドルの目的地であるかもしれないかいくつかの中間的推進終点であるかもしれない)の最小のレセプショングループですべてのノードに送られることを引き起こすためのノードのバンドルプロトコルエージェントによる持続している努力です。 いろいろなトランスミッションが同時に与えられたノードのバンドルプロトコルエージェントによって引き受けられるかもしれません。
Custody - To "accept custody" upon forwarding a bundle is to commit
to retaining a copy of the bundle -- possibly re-forwarding the
bundle when necessary -- until custody of that bundle is
"released". Custody of a bundle whose destination is a singleton
endpoint is released when either (a) notification is received that
some other node has accepted custody of the same bundle; (b)
notification is received that the bundle has been delivered at the
(sole) node registered in the bundle's destination endpoint; or
(c) the bundle is explicitly deleted for some reason, such as
lifetime expiration. The condition(s) under which custody of a
bundle whose destination is not a singleton endpoint may be
released are not defined in this specification. To "refuse
custody" of a bundle is to decide not to accept custody of the
bundle. A "custodial node" of a bundle is a node that has
accepted custody of the bundle and has not yet released that
custody. A "custodian" of a bundle is a singleton endpoint whose
sole member is one of the bundle's custodial nodes.
保護--バンドルを進めるとき「保護を受け入れること」は、必要であるときに、そのバンドルの保護が「リリースされる」までことによるとバンドルを再進めて、バンドルのコピーを保有するのに公約することです。 ある他のノードが同じバンドルの保護を受け入れたという(a)通知が受信されているとき、目的地が単独個体終点であるバンドルの保護はリリースされます。 (b) バンドルがバンドルの目的地終点に登録された(唯一)のノードで提供されたという通知は受信されています。 (c) または、バンドルは生涯満了などのように明らかにある理由で削除されます。 目的地が単独個体終点でないバンドルの保護がリリースされるかもしれない状態はこの仕様に基づき定義されません。 バンドルの「廃物保護」には、受け入れないと決めるために、バンドルの保護があります。 バンドルの「保管のノード」はバンドルの保護を受け入れて、まだその保護をリリースしていないノードです。 バンドルの「管理人」は唯一のメンバーがバンドルの保管のノードの1つである単独個体終点です。
3.2. Implementation Architectures
3.2. 実装アーキテクチャ
The above definitions are intended to enable the bundle protocol's operations to be specified in a manner that minimizes bias toward any particular implementation architecture. To illustrate the range of interoperable implementation models that might conform to this
上の定義が、バンドルプロトコルの操作がどんな特定の実装アーキテクチャに向かってもバイアスを最小にする方法で指定されるのを可能にすることを意図します。 これに従うかもしれない共同利用できる実装モデルの範囲を例証するために
Scott & Burleigh Experimental [Page 9] RFC 5050 Bundle Protocol Specification November 2007
スコットとバーレイの実験的な[9ページ]RFC5050バンドルは仕様2007年11月に議定書を作ります。
specification, four example architectures are briefly described below.
仕様、4つの例のアーキテクチャが以下で簡潔に説明されます。
1. Bundle protocol application server
1. バンドルプロトコルアプリケーション・サーバー
A single bundle protocol application server, constituting a
single bundle node, runs as a daemon process on each computer.
The daemon's functionality includes all functions of the bundle
protocol agent, all convergence layer adapters, and both the
administrative and application-specific elements of the
application agent. The application-specific element of the
application agent functions as a server, offering bundle protocol
service over a local area network: it responds to remote
procedure calls from application processes (on the same computer
and/or remote computers) that need to communicate via the bundle
protocol. The server supports its clients by creating a new
(conceptual) node for each one and registering each such node in
a client-specified endpoint. The conceptual nodes managed by the
server function as clients' bundle protocol service access
points.
ただ一つのバンドルノードを構成して、ただ一つのバンドルプロトコルアプリケーション・サーバーはデーモンプロセスとして各コンピュータで稼働しています。 デーモンの機能性はバンドルプロトコルエージェントのすべての機能、すべての集合層のアダプター、およびアプリケーションエージェントの管理の、そして、アプリケーション特有の要素の両方を含んでいます。 バンドルプロトコルサービスオーバーにローカル・エリア・ネットワークを提供して、アプリケーションエージェントのアプリケーション特有の要素はサーバとして機能します: それはバンドルプロトコルで交信する必要があるアプリケーション・プロセス(同じコンピュータ、そして/または、リモート・コンピュータの)から遠隔手続き呼び出しに応じます。 サーバは、それぞれのために新しい(概念的な)ノードを作成して、クライアントによって指定された終点にそのような各ノードを登録することによって、クライアントをサポートします。 概念的なノードはクライアントのバンドルプロトコルサービスアクセスポイントとしてサーバ機能で管理しました。
2. Peer application nodes
2. 同輩アプリケーションノード
Any number of bundle protocol application processes, each one
constituting a single bundle node, run in ad-hoc fashion on each
computer. The functionality of the bundle protocol agent, all
convergence layer adapters, and the administrative element of the
application agent is provided by a library to which each node
process is dynamically linked at run time. The application-
specific element of each node's application agent is node-
specific application code.
いろいろなバンドルプロトコルアプリケーション・プロセス(ただ一つのバンドルノードを構成するそれぞれ)が各コンピュータにおける臨時のファッションに立候補します。 バンドルプロトコルエージェントの機能性、すべての集合層のアダプター、およびアプリケーションエージェントの管理要素はそれぞれのノードプロセスがランタイムのときにダイナミックにリンクされるライブラリによって提供されます。 各ノードのアプリケーションエージェントのアプリケーションの特定の要素はノードの特定の応用コードです。
3. Sensor network nodes
3. センサネットワーク・ノード
Each node of the sensor network is the self-contained
implementation of a single bundle node. All functions of the
bundle protocol agent, all convergence layer adapters, and the
administrative element of the application agent are implemented
in simplified form in Application-Specific Integrated Circuits
(ASICs), while the application-specific element of each node's
application agent is implemented in a programmable
microcontroller. Forwarding is rudimentary: all bundles are
forwarded on a hard-coded default route.
センサネットワークの各ノードはただ一つのバンドルノードの自己充足的な実装です。 バンドルプロトコルエージェントのすべての機能、すべての集合層のアダプター、およびアプリケーションエージェントの管理要素はApplication特有のIntegrated Circuits(ASICs)の簡易慣用字体で実装されます、各ノードのアプリケーションエージェントのアプリケーション特有の要素がプログラマブルマイクロコントローラで実装されますが。 推進は初歩的です: 一生懸命コード化されたデフォルトルートですべてのバンドルを進めます。
Scott & Burleigh Experimental [Page 10] RFC 5050 Bundle Protocol Specification November 2007
スコットとバーレイの実験的な[10ページ]RFC5050バンドルは仕様2007年11月に議定書を作ります。
4. Dedicated bundle router
4. ひたむきなバンドルルータ
Each computer constitutes a single bundle node that functions
solely as a high-performance bundle forwarder. Many standard
functions of the bundle protocol agent, the convergence layer
adapters, and the administrative element of the application agent
are implemented in ASICs, but some functions are implemented in a
high-speed processor to enable reprogramming as necessary. The
node's application agent has no application-specific element.
Substantial non-volatile storage resources are provided, and
arbitrarily complex forwarding algorithms are supported.
各コンピュータは唯一高性能バンドル混載業者として機能するただ一つのバンドルノードを構成します。 バンドルプロトコルエージェントの多くの標準関数、集合層のアダプター、およびアプリケーションエージェントの管理要素はASICsで実装されますが、いくつかの機能が、必要に応じてプログラムを変えることを可能にするために高速演算処理装置で実装されます。 ノードのアプリケーションエージェントには、どんなアプリケーション特有の要素もありません。 かなりの非揮発性記憶装置リソースを提供します、そして、任意に複雑な推進アルゴリズムをサポートします。
3.3. Services Offered by Bundle Protocol Agents
3.3. バンドルプロトコルエージェントによって提供されたサービス
The bundle protocol agent of each node is expected to provide the following services to the node's application agent:
それぞれのノードのバンドルプロトコルエージェントがノードのアプリケーションエージェントに対する以下のサービスを提供すると予想されます:
o commencing a registration (registering a node in an endpoint);
o 登録(終点にノードを登録する)を始めます。
o terminating a registration;
o 登録を終えます。
o switching a registration between Active and Passive states;
o ActiveとPassive州の間に登録を切り換えます。
o transmitting a bundle to an identified bundle endpoint;
o 特定されたバンドル終点にバンドルを送ります。
o canceling a transmission;
o トランスミッションを中止します。
o polling a registration that is in the passive state;
o 登録に投票して、それが不動態にいます。
o delivering a received bundle.
o 容認されたバンドルを提供します。
4. Bundle Format
4. バンドル形式
Each bundle shall be a concatenated sequence of at least two block structures. The first block in the sequence must be a primary bundle block, and no bundle may have more than one primary bundle block. Additional bundle protocol blocks of other types may follow the primary block to support extensions to the bundle protocol, such as the Bundle Security Protocol [BSP]. At most one of the blocks in the sequence may be a payload block. The last block in the sequence must have the "last block" flag (in its block processing control flags) set to 1; for every other block in the bundle after the primary block, this flag must be set to zero.
各バンドルは少なくとも2つのブロック構造の連結された系列になるでしょう。 系列における最初のブロックはプライマリバンドルブロックでなければなりません、そして、どんなバンドルにも、1つ以上のプライマリバンドルブロック以上があってはいけません。 他の追加バンドルプロトコルブロックのタイプはバンドルプロトコルに拡大をサポートするためにプライマリブロックに従うかもしれません、Bundle Securityプロトコル[BSP]などのように。 高々系列でのブロックの1つはペイロードブロックであるかもしれません。 系列における最後のブロックで、「最後のブロック」旗(ブロック処理指揮旗による)を1に設定しなければなりません。 プライマリブロックの後のバンドルでの他のあらゆるブロックにおいて、この旗をゼロに設定しなければなりません。
Scott & Burleigh Experimental [Page 11] RFC 5050 Bundle Protocol Specification November 2007
スコットとバーレイの実験的な[11ページ]RFC5050バンドルは仕様2007年11月に議定書を作ります。
4.1. Self-Delimiting Numeric Values (SDNVs)
4.1. 自己を区切る数値(SDNVs)
The design of the bundle protocol attempts to reconcile minimal consumption of transmission bandwidth with:
バンドルプロトコルのデザインは、トランスミッション帯域幅の最小量の消費を以下に和解させるのを試みます。
o extensibility to address requirements not yet identified, and
o そしてまだ特定されていなかった要件を扱う伸展性。
o scalability across a wide range of network scales and payload
sizes.
o さまざまなネットワークスケールとペイロードサイズの向こう側のスケーラビリティ。
A key strategic element in the design is the use of self-delimiting numeric values (SDNVs). The SDNV encoding scheme is closely adapted from the Abstract Syntax Notation One Basic Encoding Rules for subidentifiers within an object identifier value [ASN1]. An SDNV is a numeric value encoded in N octets, the last of which has its most significant bit (MSB) set to zero; the MSB of every other octet in the SDNV must be set to 1. The value encoded in an SDNV is the unsigned binary number obtained by concatenating into a single bit string the 7 least significant bits of each octet of the SDNV.
デザインにおける主要な戦略の要素は自己を区切る数値(SDNVs)の使用です。 体系をコード化するSDNVは「副-識別子」のためにオブジェクト識別子価値[ASN1]の中で抽象的なSyntax Notation One Basic Encoding Rulesから密接に適合させられます。 SDNVはそれの最終が最上位ビット(MSB)をゼロに設定させるN八重奏でコード化された数値です。 SDNVの他のあらゆる八重奏のMSBは1に用意ができなければなりません。 SDNVでコード化された値はSDNVのそれぞれの八重奏の7つの最下位ビットをただ一つのビット列に連結することによって得られた未署名の2進の数です。
The following examples illustrate the encoding scheme for various hexadecimal values.
以下の例は様々な16進値のコード化体系を例証します。
0xABC : 1010 1011 1100
is encoded as
{1 00 10101} {0 0111100}
= 10010101 00111100
0xABC: 1010 1011 1100がコード化される、1、00 10101、0、0111100、=10010101 00111100
0x1234 : 0001 0010 0011 0100
= 1 0010 0011 0100
is encoded as
{1 0 100100} {0 0110100}
= 10100100 00110100
0×1234: 0001 0010 0011 0100 = 1 0010 0011 0100がコード化される、1 0、100100、0、0110100、=10100100 00110100
0x4234 : 0100 0010 0011 0100
= 100 0010 0011 0100
is encoded as
{1 000000 1} {1 0000100} {0 0110100}
= 10000001 10000100 00110100
0×4234: 0100 0010 0011 0100 = 100 0010 0011 0100がコード化される、1、000000、1、1、0000100、0、0110100、=10000001 10000100 00110100
0x7F : 0111 1111
= 111 1111
is encoded as
{0 1111111}
= 01111111
0x7F: 0111 1111 = 111 1111がコード化される、0、1111111、=01111111
Figure 2: SDNV Example
図2: SDNVの例
Scott & Burleigh Experimental [Page 12] RFC 5050 Bundle Protocol Specification November 2007
スコットとバーレイの実験的な[12ページ]RFC5050バンドルは仕様2007年11月に議定書を作ります。
Note: Care must be taken to make sure that the value to be encoded is (in concept) padded with high-order zero bits to make its bitwise length a multiple of 7 before encoding. Also note that, while there is no theoretical limit on the size of an SDNV field, the overhead of the SDNV scheme is 1:7, i.e., one bit of overhead for every 7 bits of actual data to be encoded. Thus, a 7-octet value (a 56-bit quantity with no leading zeroes) would be encoded in an 8-octet SDNV; an 8-octet value (a 64-bit quantity with no leading zeroes) would be encoded in a 10-octet SDNV (one octet containing the high-order bit of the value padded with six leading zero bits, followed by nine octets containing the remaining 63 bits of the value). 148 bits of overhead would be consumed in encoding a 1024-bit RSA encryption key directly in an SDNV. In general, an N-bit quantity with no leading zeroes is encoded in an SDNV occupying ceil(N/7) octets, where ceil is the integer ceiling function.
以下に注意してください。 作る高位ゼロ・ビットでそっと歩いて、コード化されるべき値がそうであることを確信しているのに(概念の)作るために注意しなければならない、それ、bitwiseする、コード化の前の7の長さのa倍数。 また、どんな理論上の限界もSDNV分野のサイズにありませんが、SDNV体系のオーバーヘッドは1:7です、すなわち、オーバーヘッドの1ビットに注意して、7ビット毎の実際のデータはコード化されてください。 したがって、7八重奏の値(主なゼロのない56ビットの量)は8八重奏のSDNVでコード化されるでしょう。 8八重奏の値(いいえがゼロを導いている64ビットの量)は10八重奏のSDNV(価値の残っている63ビットを含む9つの八重奏があとに続いた6先行ゼロビットで水増しされた価値の高位のビットを含む1つの八重奏)でコード化されるでしょう。 オーバーヘッドの148ビットは直接SDNVで主要な1024年のビットのRSA暗号化をコード化する際に消費されるでしょう。 一般に、主なゼロのないN-ビット量はceil(N/7)八重奏を占領するSDNVでコード化されます。そこでは、ceilは整数天井機能です。
Implementations of the bundle protocol may handle as an invalid numeric value any SDNV that encodes an integer that is larger than (2^64 - 1).
バンドルプロトコルの実装は無効の数値として(2^64--1)より大きい整数をコード化するどんなSDNVも扱うかもしれません。
An SDNV can be used to represent both very large and very small integer values. However, SDNV is clearly not the best way to represent every numeric value. For example, an SDNV is a poor way to represent an integer whose value typically falls in the range 128 to 255. In general, though, we believe that SDNV representation of numeric values in bundle blocks yields the smallest block sizes without sacrificing scalability.
非常に大きいものと同様に非常に小さい整数値を表すのにSDNVを使用できます。 しかしながら、SDNVは明確にあらゆる数値を表す最も良い方法ではありません。 例えば、SDNVは値が範囲で128〜255に通常下落する整数を表す貧しい方法です。 一般に、もっとも、私たちは、バンドルブロックでの数値のSDNV表現がスケーラビリティを犠牲にしないで最もわずかなブロック・サイズをもたらすと信じています。
4.2. Bundle Processing Control Flags
4.2. バンドル処理指揮旗
The bundle processing control flags field in the primary bundle block
of each bundle is an SDNV; the value encoded in this SDNV is a string
of bits used to invoke selected bundle processing control features.
The significance of the value in each currently defined position of
this bit string is described here. Note that in the figure and
descriptions, the bit label numbers denote position (from least
significant ('0') to most significant) within the decoded bit string,
and not within the representation of the bits on the wire. This is
why the descriptions in this section and the next do not follow
standard RFC conventions with bit 0 on the left; if fields are added
in the future, the SDNV will grow to the left, and using this
representation allows the references here to remain valid.
それぞれのバンドルのプライマリバンドルブロックのバンドル処理指揮旗分野はSDNVです。 このSDNVでコード化された値は選択されたバンドル処理コントロール機能を呼び出すのに使用される一連のビットです。 このビット列のそれぞれの現在定義された位置の価値の意味はここで説明されます。 図と記述では、噛み付いているラベル番号がワイヤにおけるビットの表現の中で指示するのではなく、解読されたビット列の中で位置(最も重要でない('0')から最も重要な)までの)を指示することに注意してください。 これはビット0が左にある状態でこのセクションの記述と次が一般的なRFCコンベンションを次に続かせない理由です。 分野が将来加えられると、SDNVは左まで成長するでしょう、そして、この表現を使用するのはここでの参照が有効なままで残っているのを許容します。
Scott & Burleigh Experimental [Page 13] RFC 5050 Bundle Protocol Specification November 2007
スコットとバーレイの実験的な[13ページ]RFC5050バンドルは仕様2007年11月に議定書を作ります。
2 1 0
0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Status Report|Class of Svc.| General |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 1 0 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |現状報告|Svc| 一般のクラス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Bundle Processing Control Flags Bit Layout
図3: バンドル処理コントロールはビットレイアウトに旗を揚げさせます。
The bits in positions 0 through 6 are flags that characterize the bundle as follows:
位置0〜6のビットは以下のバンドルを特徴付ける旗です:
0 -- Bundle is a fragment.
0--バンドルは断片です。
1 -- Application data unit is an administrative record.
1--アプリケーションデータ単位は管理記録です。
2 -- Bundle must not be fragmented.
2--バンドルを断片化してはいけません。
3 -- Custody transfer is requested.
3--保護転送は要求されています。
4 -- Destination endpoint is a singleton.
4--目的地終点は単独個体です。
5 -- Acknowledgement by application is requested.
5--アプリケーションによる承認は要求されています。
6 -- Reserved for future use.
6--今後の使用のために、予約されます。
The bits in positions 7 through 13 are used to indicate the bundle's class of service. The bits in positions 8 and 7 constitute a two-bit priority field indicating the bundle's priority, with higher values being of higher priority: 00 = bulk, 01 = normal, 10 = expedited, 11 is reserved for future use. Within this field, bit 8 is the most significant bit. The bits in positions 9 through 13 are reserved for future use.
位置7〜13のビットは、バンドルのサービスのクラスを示すのに使用されます。 位置8と7のビットはバンドルの優先権が、より高い値がある、より高い優先度のそうであることを示す安っぽい優先権分野を構成します: 00 = 大量、01=標準、=が速めた10、11は今後の使用のために予約されます。 この分野の中では、ビット8は最も重要なビットです。 位置9〜13のビットは今後の使用のために予約されます。
The bits in positions 14 through 20 are status report request flags. These flags are used to request status reports as follows:
位置14〜20のビットは現状報告要求旗です。 これらの旗は以下の現状報告を要求するのに使用されます:
14 -- Request reporting of bundle reception.
14--バンドルレセプションの報告を要求してください。
15 -- Request reporting of custody acceptance.
15--保護承認の報告を要求してください。
16 -- Request reporting of bundle forwarding.
16--バンドル推進の報告を要求してください。
17 -- Request reporting of bundle delivery.
17--バンドル配送の報告を要求してください。
18 -- Request reporting of bundle deletion.
18--バンドル削除の報告を要求してください。
19 -- Reserved for future use.
19--今後の使用のために、予約されます。
Scott & Burleigh Experimental [Page 14] RFC 5050 Bundle Protocol Specification November 2007
スコットとバーレイの実験的な[14ページ]RFC5050バンドルは仕様2007年11月に議定書を作ります。
20 -- Reserved for future use.
20--今後の使用のために、予約されます。
If the bundle processing control flags indicate that the bundle's application data unit is an administrative record, then the custody transfer requested flag must be zero and all status report request flags must be zero. If the custody transfer requested flag is 1, then the sending node requests that the receiving node accept custody of the bundle. If the bundle's source endpoint ID is "dtn:none" (see below), then the bundle is not uniquely identifiable and all bundle protocol features that rely on bundle identity must therefore be disabled: the bundle's custody transfer requested flag must be zero, the "Bundle must not be fragmented" flag must be 1, and all status report request flags must be zero.
バンドル処理指揮旗が、バンドルのアプリケーションデータ単位が管理記録であることを示すなら、保護転送は、旗がゼロであるに違いないよう要求しました、そして、すべての現状報告要求旗がゼロであるに違いありません。 保護転送が、旗が1であるよう要求したなら、送付ノードは、受信ノードがバンドルの保護を受け入れるよう要求します。 バンドルのソース終点IDがそうなら、次に、「dtn: なにも」(以下を見る)、バンドルは唯一身元保証可能ではありません、そして、したがって、バンドルのアイデンティティを当てにするすべてのバンドルプロトコル機能を無効にしなければなりません: バンドルの保護転送は、旗がゼロであるに違いないよう要求しました、そして、「バンドルを断片化してはいけない」という旗は1であるに違いありません、そして、すべての現状報告要求旗がゼロであるに違いありません。
4.3. Block Processing Control Flags
4.3. ブロック処理指揮旗
The block processing control flags field in every block other than the primary bundle block is an SDNV; the value encoded in this SDNV is a string of bits used to invoke selected block processing control features. The significance of the values in all currently defined positions of this bit string, in order from least significant position in the decoded bit string (labeled '0') to most significant (labeled '6'), is described here.
一丁目ごとにプライマリバンドルブロック以外のブロック処理指揮旗分野はSDNVです。 このSDNVでコード化された値は選択されたブロック処理コントロール機能を呼び出すのに使用される一連のビットです。 このビット列のすべての現在定義された位置の値の解読されたビット列('0'とラベルされる)で最も重要でない位置から最も重要な('6'とラベルされる)位置まで整然としている意味はここで説明されます。
0
0
6 5 4 3 2 1 0
+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+
6 5 4 3 2 1 0 +-+-+-+-+-+-+-+ | 旗| +-+-+-+-+-+-+-+
Figure 4: Block Processing Control Flags Bit Layout
図4: ブロック処理コントロールはビットレイアウトに旗を揚げさせます。
0 - Block must be replicated in every fragment.
0 --あらゆる断片でブロックを模写しなければなりません。
1 - Transmit status report if block can't be processed.
1--ブロックを処理できないなら、現状報告を伝えてください。
2 - Delete bundle if block can't be processed.
2--ブロックを処理できないなら、バンドルを削除してください。
3 - Last block.
3--最後のブロック。
4 - Discard block if it can't be processed.
4--それを処理できないなら、ブロックを捨ててください。
5 - Block was forwarded without being processed.
5 --処理されないで、ブロックを転送しました。
6 - Block contains an EID-reference field.
6 --ブロックはEID-参照分野を含んでいます。
Scott & Burleigh Experimental [Page 15] RFC 5050 Bundle Protocol Specification November 2007
スコットとバーレイの実験的な[15ページ]RFC5050バンドルは仕様2007年11月に議定書を作ります。
For each bundle whose primary block's bundle processing control flags (see above) indicate that the bundle's application data unit is an administrative record, the "Transmit status report if block can't be processed" flag in the block processing flags field of every other block in the bundle must be zero.
各バンドルのために、プライマリブロックのバンドル処理コントロールが弛むかが(上を見ます)バンドルのアプリケーションデータ単位が管理記録であることを示して、旗がさばくバンドルでの他のあらゆるブロックのブロック処理における「ブロックを処理できないなら、現状報告を伝えてください」旗はゼロであるに違いありません。
The 'Block must be replicated in every fragment' bit in the block processing flags must be set to zero on all blocks that follow the payload block.
ブロック処理旗による'あらゆる断片でブロックを模写しなければならない'ビットをペイロードブロックに従うすべてのブロックのゼロに設定しなければなりません。
4.4. Endpoint IDs
4.4. 終点ID
The destinations of bundles are bundle endpoints, identified by text strings termed "endpoint IDs" (see Section 3.1). Each endpoint ID conveyed in any bundle block takes the form of a Uniform Resource Identifier (URI; [URI]). As such, each endpoint ID can be characterized as having this general structure:
バンドルの目的地は「終点ID」と呼ばれたテキスト文字列によって特定されたバンドル終点(セクション3.1を見る)です。 IDがどんなバンドルブロックも運んだ各終点はUniform Resource Identifier(URI;[URI])の形を取ります。 そういうものとして、この一般構造体を持っているとしてそれぞれの終点IDを特徴付けることができます:
< scheme name > : < scheme-specific part, or "SSP" >
<体系名前>: <の体系特有の部分、または"SSP">。
As used for the purposes of the bundle protocol, neither the length of a scheme name nor the length of an SSP may exceed 1023 bytes.
バンドルプロトコルの目的に使用されるように、体系名の長さもSSPの長さも1023バイトを超えないかもしれません。
Bundle blocks cite a number of endpoint IDs for various purposes of the bundle protocol. Many, though not necessarily all, of the endpoint IDs referred to in the blocks of a given bundle are conveyed in the "dictionary" byte array in the bundle's primary block. This array is simply the concatenation of any number of null-terminated scheme names and SSPs.
バンドルブロックはバンドルプロトコルの様々な目的のために多くの終点IDを引用します。 多くです、必ずすべてであるというわけではありませんが、終点では、与えられたバンドルのブロックに示されたIDはバンドルのプライマリブロックの「辞書」バイト配列で伝えられます。 この配列は単にいろいろなヌルで終えられた体系名とSSPsの連結です。
"Endpoint ID references" are used to cite endpoint IDs that are contained in the dictionary; all endpoint ID citations in the primary bundle block are endpoint ID references, and other bundle blocks may contain endpoint ID references as well. Each endpoint ID reference is an ordered pair of SDNVs:
「終点ID参照」は辞書に含まれている終点IDを引用するのに使用されます。 プライマリバンドルブロックでのすべての終点ID引用が終点ID参照です、そして、他のバンドルブロックはまた、終点ID参照を含むかもしれません。 それぞれの終点ID参照は1順序対のSDNVsです:
o The first SDNV contains the offset within the dictionary of the
first character of the referenced endpoint ID's scheme name.
o 最初のSDNVはIDの体系が命名する参照をつけられた終点の最初のキャラクタの辞書の中にオフセットを含んでいます。
o The second SDNV contains the offset within the dictionary of the
first character of the referenced endpoint ID's SSP.
o 第2SDNVはIDの参照をつけられた終点SSPの最初のキャラクタの辞書の中にオフセットを含んでいます。
This encoding enables a degree of block compression: when the source and report-to of a bundle are the same endpoint, for example, the text of that endpoint's ID may be cited twice yet appear only once in the dictionary.
このコード化はブロック圧縮の度合いを可能にします: そして、ソースである、レポート、-、aでは、バンドルが同じ終点である、例えば、その終点のIDのテキストは、二度引用されますが、辞書に一度だけ載るかもしれません。
Scott & Burleigh Experimental [Page 16] RFC 5050 Bundle Protocol Specification November 2007
スコットとバーレイの実験的な[16ページ]RFC5050バンドルは仕様2007年11月に議定書を作ります。
The scheme identified by the < scheme name > in an endpoint ID is a set of syntactic and semantic rules that fully explain how to parse and interpret the SSP. The set of allowable schemes is effectively unlimited. Any scheme conforming to [URIREG] may be used in a bundle protocol endpoint ID. In addition, a single additional scheme is defined by the present document:
終点IDで<体系名前>によって特定された体系はどのようにSSPを分析して、解釈するかが完全にわかる1セットの構文的、そして、意味的な規則です。 事実上、許容できる体系のセットは無制限です。 [URIREG]に従うどんな体系もバンドルプロトコル終点IDに使用されるかもしれません。 さらに、ただ一つの追加体系は現在のドキュメントによって定義されます:
o The "dtn" scheme, which is used at minimum in the representation
of the null endpoint ID "dtn:none". The forwarding of a bundle to
the null endpoint is never contraindicated, and the minimum
reception group for the null endpoint is the empty set.
o "dtn"体系。(その体系は最小限でヌル終点ID「:dtnでないなにも」の表現に使用されます)。 ヌル終点へのバンドルの推進は決して禁忌的ではありません、そして、ヌル終点への最小のレセプショングループは空集合です。
Note that, although the endpoint IDs conveyed in bundle blocks are expressed as URIs, implementations of the BP service interface may support expression of endpoint IDs in some internationalized manner (e.g., Internationalized Resource Identifiers (IRIs); see [RFC3987]).
バンドルブロックで伝えられた終点IDがURIとして言い表されますが、BPサービスインタフェースの実装が何らかの国際化している方法で終点IDの式をサポートするかもしれないことに注意してください(例えば、Internationalized Resource Identifiers(IRIs); [RFC3987]を見てください)。
4.5. Formats of Bundle Blocks
4.5. バンドルブロックの形式
This section describes the formats of the primary block and payload block. Rules for processing these blocks appear in Section 5 of this document.
このセクションはプライマリブロックとペイロードブロックの形式について説明します。 これらのブロックを処理するための規則はこのドキュメントのセクション5に現れます。
Note that supplementary DTN protocol specifications (including, but not restricted to, the Bundle Security Protocol [BSP]) may require that BP implementations conforming to those protocols construct and process additional blocks.
補っているDTNが仕様を議定書の中で述べることに注意してください。(含んでいますが、部外秘でないことで、Bundle Securityプロトコル[BSP)は、それらのプロトコルに従うBP実装が追加ブロックを構成して、処理するのを必要としてもよいです。
The format of the two basic BP blocks is shown in Figure 5 below.
2つの基本のBPブロックの書式は以下の図5に示されます。
Scott & Burleigh Experimental [Page 17] RFC 5050 Bundle Protocol Specification November 2007
スコットとバーレイの実験的な[17ページ]RFC5050バンドルは仕様2007年11月に議定書を作ります。
Primary Bundle Block +----------------+----------------+----------------+----------------+ | Version | Proc. Flags (*) | +----------------+----------------+----------------+----------------+ | Block length (*) | +----------------+----------------+---------------------------------+ | Destination scheme offset (*) | Destination SSP offset (*) | +----------------+----------------+----------------+----------------+ | Source scheme offset (*) | Source SSP offset (*) | +----------------+----------------+----------------+----------------+ | Report-to scheme offset (*) | Report-to SSP offset (*) | +----------------+----------------+----------------+----------------+ | Custodian scheme offset (*) | Custodian SSP offset (*) | +----------------+----------------+----------------+----------------+ | Creation Timestamp time (*) | +---------------------------------+---------------------------------+ | Creation Timestamp sequence number (*) | +---------------------------------+---------------------------------+ | Lifetime (*) | +----------------+----------------+----------------+----------------+ | Dictionary length (*) | +----------------+----------------+----------------+----------------+ | Dictionary byte array (variable) | +----------------+----------------+---------------------------------+ | [Fragment offset (*)] | +----------------+----------------+---------------------------------+ | [Total application data unit length (*)] | +----------------+----------------+---------------------------------+
プライマリバンドルブロック+----------------+----------------+----------------+----------------+ | バージョン| Proc。 旗(*)| +----------------+----------------+----------------+----------------+ | ブロック長(*)| +----------------+----------------+---------------------------------+ | 目的地体系オフセット(*)| 目的地SSPオフセット(*)| +----------------+----------------+----------------+----------------+ | ソース体系オフセット(*)| ソースSSPは(*)を相殺します。| +----------------+----------------+----------------+----------------+ | レポート、-、オフセット(*)を計画してください。| レポート、-、SSPは(*)を相殺します。| +----------------+----------------+----------------+----------------+ | 管理人体系オフセット(*)| 管理人SSPは(*)を相殺します。| +----------------+----------------+----------------+----------------+ | 作成Timestamp時間(*)| +---------------------------------+---------------------------------+ | 作成Timestamp一連番号(*)| +---------------------------------+---------------------------------+ | 生涯(*)| +----------------+----------------+----------------+----------------+ | 辞書の長さ(*)| +----------------+----------------+----------------+----------------+ | 辞書バイト配列(可変)| +----------------+----------------+---------------------------------+ | [断片オフセット(*)]| +----------------+----------------+---------------------------------+ | [総アプリケーションデータユニット長(*)]| +----------------+----------------+---------------------------------+
Bundle Payload Block +----------------+----------------+----------------+----------------+ | Block type | Proc. Flags (*)| Block length(*) | +----------------+----------------+----------------+----------------+ / Bundle Payload (variable) / +-------------------------------------------------------------------+
有効搭載量ブロックが+であると添付してください。----------------+----------------+----------------+----------------+ | ゴシック体| Proc。 旗(*)| ブロック長(*)| +----------------+----------------+----------------+----------------+/バンドル有効搭載量(変数)/+-------------------------------------------------------------------+
Figure 5: Bundle Block Formats
図5: バンドルブロックフォーマット
(*) Notes:
(*)注意:
The bundle processing control ("Proc.") flags field in the Primary
Bundle Block is an SDNV and is therefore variable length. A three-
octet SDNV is shown here for convenience in representation.
旗がPrimary Bundle Blockでさばくバンドル処理コントロール("Proc")は、SDNVであり、したがって、可変長です。 3八重奏SDNVは表現における便宜のためにここに示されます。
The block length field of the Primary Bundle Block is an SDNV and is therefore variable length. A four-octet SDNV is shown here for convenience in representation.
Primary Bundle Blockのブロック長分野は、SDNVであり、したがって、可変長です。 4八重奏のSDNVは表現における便宜のためにここに示されます。
Scott & Burleigh Experimental [Page 18] RFC 5050 Bundle Protocol Specification November 2007
スコットとバーレイの実験的な[18ページ]RFC5050バンドルは仕様2007年11月に議定書を作ります。
Each of the eight offset fields in the Primary Bundle Block is an SDNV and is therefore variable length. Two-octet SDNVs are shown here for convenience in representation.
Primary Bundle Blockのそれぞれの8つのオフセット分野が、SDNVであり、したがって、可変長です。 2八重奏のSDNVsは表現における便宜のためにここに示されます。
The Creation Timestamp time field in the Primary Bundle Block is an SDNV and is therefore variable length. A four-octet SDNV is shown here for convenience in representation.
Primary Bundle BlockのCreation Timestamp時間分野は、SDNVであり、したがって、可変長です。 4八重奏のSDNVは表現における便宜のためにここに示されます。
The Creation Timestamp sequence number field in the Primary Bundle Block is an SDNV and is therefore variable length. A four-octet SDNV is shown here for convenience in representation.
Primary Bundle BlockのCreation Timestamp一連番号分野は、SDNVであり、したがって、可変長です。 4八重奏のSDNVは表現における便宜のためにここに示されます。
The Lifetime field in the Primary Bundle Block is an SDNV and is therefore variable length. A four-octet SDNV is shown here for convenience in representation.
Primary Bundle BlockのLifetime分野は、SDNVであり、したがって、可変長です。 4八重奏のSDNVは表現における便宜のためにここに示されます。
The dictionary length field of the Primary Bundle Block is an SDNV and is therefore variable length. A four-octet SDNV is shown here for convenience in representation.
Primary Bundle Blockの辞書長さの分野は、SDNVであり、したがって、可変長です。 4八重奏のSDNVは表現における便宜のためにここに示されます。
The fragment offset field of the Primary Bundle Block is present only if the Fragment flag in the block's processing flags byte is set to 1. It is an SDNV and is therefore variable length; a four-octet SDNV is shown here for convenience in representation.
Primary Bundle Blockの断片オフセット分野はブロックの処理におけるFragment旗がバイトに旗を揚げさせる場合にだけプレゼントが1に設定されるということです。 それは、SDNVであり、したがって、可変長です。 4八重奏のSDNVは表現における便宜のためにここに示されます。
The total application data unit length field of the Primary Bundle Block is present only if the Fragment flag in the block's processing flags byte is set to 1. It is an SDNV and is therefore variable length; a four-octet SDNV is shown here for convenience in representation.
Primary Bundle Blockの総アプリケーションデータユニット長分野はブロックの処理におけるFragment旗がバイトに旗を揚げさせる場合にだけプレゼントが1に設定されるということです。 それは、SDNVであり、したがって、可変長です。 4八重奏のSDNVは表現における便宜のためにここに示されます。
The block processing control ("Proc.") flags field of the Payload
Block is an SDNV and is therefore variable length. A one-octet SDNV
is shown here for convenience in representation.
旗がさばく有効搭載量Blockのブロック処理コントロール("Proc")は、SDNVであり、したがって、可変長です。 1八重奏のSDNVは表現における便宜のためにここに示されます。
The block length field of the Payload Block is an SDNV and is therefore variable length. A two-octet SDNV is shown here for convenience in representation.
有効搭載量Blockのブロック長分野は、SDNVであり、したがって、可変長です。 2八重奏のSDNVは表現における便宜のためにここに示されます。
4.5.1. Primary Bundle Block
4.5.1. プライマリバンドルブロック
The primary bundle block contains the basic information needed to route bundles to their destinations. The fields of the primary bundle block are:
プライマリバンドルブロックはそれらの目的地にバンドルを発送するのに必要である基本情報を含んでいます。 プライマリバンドルブロックの分野は以下の通りです。
Scott & Burleigh Experimental [Page 19] RFC 5050 Bundle Protocol Specification November 2007
スコットとバーレイの実験的な[19ページ]RFC5050バンドルは仕様2007年11月に議定書を作ります。
Version: A 1-byte field indicating the version of the bundle
protocol that constructed this block. The present document
describes version 0x06 of the bundle protocol.
バージョン: このブロックを構成したバンドルプロトコルのバージョンを示す1バイトの分野。 現在のドキュメントはバンドルプロトコルのバージョン0x06について説明します。
Bundle Processing Control Flags: The Bundle Processing Control
Flags field is an SDNV that contains the bundle processing control
flags discussed in Section 4.2 above.
バンドル処理コントロールは弛みます: Bundle Processing Control Flags分野は上のセクション4.2で議論したバンドル処理指揮旗を含むSDNVです。
Block Length: The Block Length field is an SDNV that contains the
aggregate length of all remaining fields of the block.
ブロック長: Block Length分野はブロックのすべての残っているフィールドの集合長さを含むSDNVです。
Destination Scheme Offset: The Destination Scheme Offset field
contains the offset within the dictionary byte array of the scheme
name of the endpoint ID of the bundle's destination, i.e., the
endpoint containing the node(s) at which the bundle is to be
delivered.
目的地体系は相殺されました: Destination Scheme Offset分野はバンドルの目的地(すなわち、提供されるバンドルがことであるノードを含む終点)の終点IDの体系名の辞書バイト勢ぞろいの中にオフセットを含んでいます。
Destination SSP Offset: The Destination SSP Offset field contains
the offset within the dictionary byte array of the scheme-specific
part of the endpoint ID of the bundle's destination.
目的地SSPは相殺します: Destination SSP Offset分野はバンドルの目的地の終点IDの体系特有の部分の辞書バイト配列の中にオフセットを含んでいます。
Source Scheme Offset: The Source Scheme Offset field contains the
offset within the dictionary byte array of the scheme name of the
endpoint ID of the bundle's nominal source, i.e., the endpoint
nominally containing the node from which the bundle was initially
transmitted.
Source Scheme Offset: The Source Scheme Offset field contains the offset within the dictionary byte array of the scheme name of the endpoint ID of the bundle's nominal source, i.e., the endpoint nominally containing the node from which the bundle was initially transmitted.
Source SSP Offset: The Source SSP Offset field contains the offset
within the dictionary byte array of the scheme-specific part of
the endpoint ID of the bundle's nominal source.
Source SSP Offset: The Source SSP Offset field contains the offset within the dictionary byte array of the scheme-specific part of the endpoint ID of the bundle's nominal source.
Report-to Scheme Offset: The Report-to Scheme Offset field contains
the offset within the dictionary byte array of the scheme name of
the ID of the endpoint to which status reports pertaining to the
forwarding and delivery of this bundle are to be transmitted.
Report-to Scheme Offset: The Report-to Scheme Offset field contains the offset within the dictionary byte array of the scheme name of the ID of the endpoint to which status reports pertaining to the forwarding and delivery of this bundle are to be transmitted.
Report-to SSP Offset: The Report-to SSP Offset field contains the
offset within the dictionary byte array of the scheme-specific
part of the ID of the endpoint to which status reports pertaining
to the forwarding and delivery of this bundle are to be
transmitted.
Report-to SSP Offset: The Report-to SSP Offset field contains the offset within the dictionary byte array of the scheme-specific part of the ID of the endpoint to which status reports pertaining to the forwarding and delivery of this bundle are to be transmitted.
Custodian Scheme Offset: The "current custodian endpoint ID" of a
primary bundle block identifies an endpoint whose membership
includes the node that most recently accepted custody of the
bundle upon forwarding this bundle. The Custodian Scheme Offset
field contains the offset within the dictionary byte array of the
scheme name of the current custodian endpoint ID.
Custodian Scheme Offset: The "current custodian endpoint ID" of a primary bundle block identifies an endpoint whose membership includes the node that most recently accepted custody of the bundle upon forwarding this bundle. The Custodian Scheme Offset field contains the offset within the dictionary byte array of the scheme name of the current custodian endpoint ID.
Scott & Burleigh Experimental [Page 20] RFC 5050 Bundle Protocol Specification November 2007
Scott & Burleigh Experimental [Page 20] RFC 5050 Bundle Protocol Specification November 2007
Custodian SSP Offset: The Custodian SSP Offset field contains the
offset within the dictionary byte array of the scheme-specific
part of the current custodian endpoint ID.
Custodian SSP Offset: The Custodian SSP Offset field contains the offset within the dictionary byte array of the scheme-specific part of the current custodian endpoint ID.
Creation Timestamp: The creation timestamp is a pair of SDNVs that,
together with the source endpoint ID and (if the bundle is a
fragment) the fragment offset and payload length, serve to
identify the bundle. The first SDNV of the timestamp is the
bundle's creation time, while the second is the bundle's creation
timestamp sequence number. Bundle creation time is the time --
expressed in seconds since the start of the year 2000, on the
Coordinated Universal Time (UTC) scale [UTC] -- at which the
transmission request was received that resulted in the creation of
the bundle. Sequence count is the latest value (as of the time at
which that transmission request was received) of a monotonically
increasing positive integer counter managed by the source node's
bundle protocol agent that may be reset to zero whenever the
current time advances by one second. A source Bundle Protocol
Agent must never create two distinct bundles with the same source
endpoint ID and bundle creation timestamp. The combination of
source endpoint ID and bundle creation timestamp therefore serves
to identify a single transmission request, enabling it to be
acknowledged by the receiving application (provided the source
endpoint ID is not "dtn:none").
Creation Timestamp: The creation timestamp is a pair of SDNVs that, together with the source endpoint ID and (if the bundle is a fragment) the fragment offset and payload length, serve to identify the bundle. The first SDNV of the timestamp is the bundle's creation time, while the second is the bundle's creation timestamp sequence number. Bundle creation time is the time -- expressed in seconds since the start of the year 2000, on the Coordinated Universal Time (UTC) scale [UTC] -- at which the transmission request was received that resulted in the creation of the bundle. Sequence count is the latest value (as of the time at which that transmission request was received) of a monotonically increasing positive integer counter managed by the source node's bundle protocol agent that may be reset to zero whenever the current time advances by one second. A source Bundle Protocol Agent must never create two distinct bundles with the same source endpoint ID and bundle creation timestamp. The combination of source endpoint ID and bundle creation timestamp therefore serves to identify a single transmission request, enabling it to be acknowledged by the receiving application (provided the source endpoint ID is not "dtn:none").
Lifetime: The lifetime field is an SDNV that indicates the time at
which the bundle's payload will no longer be useful, encoded as a
number of seconds past the creation time. When the current time
is greater than the creation time plus the lifetime, bundle nodes
need no longer retain or forward the bundle; the bundle may be
deleted from the network.
Lifetime: The lifetime field is an SDNV that indicates the time at which the bundle's payload will no longer be useful, encoded as a number of seconds past the creation time. When the current time is greater than the creation time plus the lifetime, bundle nodes need no longer retain or forward the bundle; the bundle may be deleted from the network.
Dictionary Length: The Dictionary Length field is an SDNV that
contains the length of the dictionary byte array.
Dictionary Length: The Dictionary Length field is an SDNV that contains the length of the dictionary byte array.
Dictionary: The Dictionary field is an array of bytes formed by
concatenating the null-terminated scheme names and SSPs of all
endpoint IDs referenced by any fields in this Primary Block
together with, potentially, other endpoint IDs referenced by
fields in other TBD DTN protocol blocks. Its length is given by
the value of the Dictionary Length field.
Dictionary: The Dictionary field is an array of bytes formed by concatenating the null-terminated scheme names and SSPs of all endpoint IDs referenced by any fields in this Primary Block together with, potentially, other endpoint IDs referenced by fields in other TBD DTN protocol blocks. Its length is given by the value of the Dictionary Length field.
Fragment Offset: If the Bundle Processing Control Flags of this
Primary block indicate that the bundle is a fragment, then the
Fragment Offset field is an SDNV indicating the offset from the
start of the original application data unit at which the bytes
comprising the payload of this bundle were located. If not, then
the Fragment Offset field is omitted from the block.
Fragment Offset: If the Bundle Processing Control Flags of this Primary block indicate that the bundle is a fragment, then the Fragment Offset field is an SDNV indicating the offset from the start of the original application data unit at which the bytes comprising the payload of this bundle were located. If not, then the Fragment Offset field is omitted from the block.
Scott & Burleigh Experimental [Page 21] RFC 5050 Bundle Protocol Specification November 2007
Scott & Burleigh Experimental [Page 21] RFC 5050 Bundle Protocol Specification November 2007
Total Application Data Unit Length: If the Bundle Processing
Control Flags of this Primary block indicate that the bundle is a
fragment, then the Total Application Data Unit Length field is an
SDNV indicating the total length of the original application data
unit of which this bundle's payload is a part. If not, then the
Total Application Data Unit Length field is omitted from the
block.
Total Application Data Unit Length: If the Bundle Processing Control Flags of this Primary block indicate that the bundle is a fragment, then the Total Application Data Unit Length field is an SDNV indicating the total length of the original application data unit of which this bundle's payload is a part. If not, then the Total Application Data Unit Length field is omitted from the block.
4.5.2. Canonical Bundle Block Format
4.5.2. Canonical Bundle Block Format
Every bundle block of every type other than the primary bundle block comprises the following fields, in this order:
Every bundle block of every type other than the primary bundle block comprises the following fields, in this order:
o Block type code, expressed as an 8-bit unsigned binary integer.
Bundle block type code 1 indicates that the block is a bundle
payload block. Block type codes 192 through 255 are not defined
in this specification and are available for private and/or
experimental use. All other values of the block type code are
reserved for future use.
o Block type code, expressed as an 8-bit unsigned binary integer. Bundle block type code 1 indicates that the block is a bundle payload block. Block type codes 192 through 255 are not defined in this specification and are available for private and/or experimental use. All other values of the block type code are reserved for future use.
o Block processing control flags, an unsigned integer expressed as
an SDNV. The individual bits of this integer are used to invoke
selected block processing control features.
o Block processing control flags, an unsigned integer expressed as an SDNV. The individual bits of this integer are used to invoke selected block processing control features.
o Block EID reference count and EID references (optional). If and
only if the block references EID elements in the primary block's
dictionary, the 'block contains an EID-reference field' flag in
the block processing control flags is set to 1 and the block
includes an EID reference field consisting of a count of EID
references expressed as an SDNV followed by the EID references
themselves. Each EID reference is a pair of SDNVs. The first
SDNV of each EID reference contains the offset of a scheme name in
the primary block's dictionary, and the second SDNV of each
reference contains the offset of a scheme-specific part in the
dictionary.
o Block EID reference count and EID references (optional). If and only if the block references EID elements in the primary block's dictionary, the 'block contains an EID-reference field' flag in the block processing control flags is set to 1 and the block includes an EID reference field consisting of a count of EID references expressed as an SDNV followed by the EID references themselves. Each EID reference is a pair of SDNVs. The first SDNV of each EID reference contains the offset of a scheme name in the primary block's dictionary, and the second SDNV of each reference contains the offset of a scheme-specific part in the dictionary.
o Block data length, an unsigned integer expressed as an SDNV. The
Block data length field contains the aggregate length of all
remaining fields of the block, i.e., the block-type-specific data
fields.
o Block data length, an unsigned integer expressed as an SDNV. The Block data length field contains the aggregate length of all remaining fields of the block, i.e., the block-type-specific data fields.
o Block-type-specific data fields, whose format and order are type-
specific and whose aggregate length in octets is the value of the
block data length field. All multi-byte block-type-specific data
fields are represented in network byte order.
o Block-type-specific data fields, whose format and order are type- specific and whose aggregate length in octets is the value of the block data length field. All multi-byte block-type-specific data fields are represented in network byte order.
Scott & Burleigh Experimental [Page 22] RFC 5050 Bundle Protocol Specification November 2007
Scott & Burleigh Experimental [Page 22] RFC 5050 Bundle Protocol Specification November 2007
+-----------+-----------+-----------+-----------+
|Block type | Block processing ctrl flags (SDNV)|
+-----------+-----------+-----------+-----------+
| Block length (SDNV) |
+-----------+-----------+-----------+-----------+
/ Block body data (variable) /
+-----------+-----------+-----------+-----------+
+-----------+-----------+-----------+-----------+ |Block type | Block processing ctrl flags (SDNV)| +-----------+-----------+-----------+-----------+ | Block length (SDNV) | +-----------+-----------+-----------+-----------+ / Block body data (variable) / +-----------+-----------+-----------+-----------+
Figure 6: Block Layout without EID Reference List
Figure 6: Block Layout without EID Reference List
+-----------+-----------+-----------+-----------+
|Block Type | Block processing ctrl flags (SDNV)|
+-----------+-----------+-----------+-----------+
| EID Reference Count (SDNV) |
+-----------+-----------+-----------+-----------+
| Ref_scheme_1 (SDNV) | Ref_ssp_1 (SDNV) |
+-----------+-----------+-----------+-----------+
| Ref_scheme_2 (SDNV) | Ref_ssp_2 (SDNV) |
+-----------+-----------+-----------+-----------+
| Block length (SDNV) |
+-----------+-----------+-----------+-----------+
/ Block body data (variable) /
+-----------+-----------+-----------+-----------+
+-----------+-----------+-----------+-----------+ |Block Type | Block processing ctrl flags (SDNV)| +-----------+-----------+-----------+-----------+ | EID Reference Count (SDNV) | +-----------+-----------+-----------+-----------+ | Ref_scheme_1 (SDNV) | Ref_ssp_1 (SDNV) | +-----------+-----------+-----------+-----------+ | Ref_scheme_2 (SDNV) | Ref_ssp_2 (SDNV) | +-----------+-----------+-----------+-----------+ | Block length (SDNV) | +-----------+-----------+-----------+-----------+ / Block body data (variable) / +-----------+-----------+-----------+-----------+
Figure 7: Block Layout Showing Two EID References
Figure 7: Block Layout Showing Two EID References
4.5.3. Bundle Payload Block
4.5.3. Bundle Payload Block
The fields of the bundle payload block are:
The fields of the bundle payload block are:
Block Type: The Block Type field is a 1-byte field that indicates
the type of the block. For the bundle payload block, this field
contains the value 1.
Block Type: The Block Type field is a 1-byte field that indicates the type of the block. For the bundle payload block, this field contains the value 1.
Block Processing Control Flags: The Block Processing Control Flags
field is an SDNV that contains the block processing control flags
discussed in Section 4.3 above.
Block Processing Control Flags: The Block Processing Control Flags field is an SDNV that contains the block processing control flags discussed in Section 4.3 above.
Block Length: The Block Length field is an SDNV that contains the
aggregate length of all remaining fields of the block - which is
to say, the length of the bundle's payload.
Block Length: The Block Length field is an SDNV that contains the aggregate length of all remaining fields of the block - which is to say, the length of the bundle's payload.
Payload: The Payload field contains the application data carried by
this bundle.
Payload: The Payload field contains the application data carried by this bundle.
That is, bundle payload blocks follow the canonical format of the previous section with the restriction that the 'block contains an
That is, bundle payload blocks follow the canonical format of the previous section with the restriction that the 'block contains an
Scott & Burleigh Experimental [Page 23] RFC 5050 Bundle Protocol Specification November 2007
Scott & Burleigh Experimental [Page 23] RFC 5050 Bundle Protocol Specification November 2007
EID-reference field' bit of the block processing control flags is never set. The block body data for payload blocks is the application data carried by the bundle.
EID-reference field' bit of the block processing control flags is never set. The block body data for payload blocks is the application data carried by the bundle.
4.6. Extension Blocks
4.6. Extension Blocks
"Extension blocks" are all blocks other than the primary and payload blocks. Because extension blocks are not defined in the Bundle Protocol specification (the present document), not all nodes conforming to this specification will necessarily instantiate Bundle Protocol implementations that include procedures for processing (that is, recognizing, parsing, acting on, and/or producing) all extension blocks. It is therefore possible for a node to receive a bundle that includes extension blocks that the node cannot process.
"Extension blocks" are all blocks other than the primary and payload blocks. Because extension blocks are not defined in the Bundle Protocol specification (the present document), not all nodes conforming to this specification will necessarily instantiate Bundle Protocol implementations that include procedures for processing (that is, recognizing, parsing, acting on, and/or producing) all extension blocks. It is therefore possible for a node to receive a bundle that includes extension blocks that the node cannot process.
Whenever a bundle is forwarded that contains one or more extension blocks that could not be processed, the "Block was forwarded without being processed" flag must be set to 1 within the block processing flags of each such block. For each block flagged in this way, the flag may optionally be cleared (i.e., set to zero) by another node that subsequently receives the bundle and is able to process that block; the specifications defining the various extension blocks are expected to define the circumstances under which this flag may be cleared, if any.
Whenever a bundle is forwarded that contains one or more extension blocks that could not be processed, the "Block was forwarded without being processed" flag must be set to 1 within the block processing flags of each such block. For each block flagged in this way, the flag may optionally be cleared (i.e., set to zero) by another node that subsequently receives the bundle and is able to process that block; the specifications defining the various extension blocks are expected to define the circumstances under which this flag may be cleared, if any.
4.7. Dictionary Revision
4.7. Dictionary Revision
Any strings (scheme names and SSPs) in a bundle's dictionary that are referenced neither from the bundle's primary block nor from the block EID reference field of any extension block may be removed from the dictionary at the time the bundle is forwarded.
Any strings (scheme names and SSPs) in a bundle's dictionary that are referenced neither from the bundle's primary block nor from the block EID reference field of any extension block may be removed from the dictionary at the time the bundle is forwarded.
Whenever removal of a string from the dictionary causes the offsets (within the dictionary byte array) of any other strings to change, all endpoint ID references that refer to those strings must be adjusted at the same time. Note that these references may be in the primary block and/or in the block EID reference fields of extension blocks.
Whenever removal of a string from the dictionary causes the offsets (within the dictionary byte array) of any other strings to change, all endpoint ID references that refer to those strings must be adjusted at the same time. Note that these references may be in the primary block and/or in the block EID reference fields of extension blocks.
5. Bundle Processing
5. Bundle Processing
The bundle processing procedures mandated in this section and in Section 6 govern the operation of the Bundle Protocol Agent and the Application Agent administrative element of each bundle node. They are neither exhaustive nor exclusive. That is, supplementary DTN protocol specifications (including, but not restricted to, the Bundle Security Protocol [BSP]) may require that additional measures be taken at specified junctures in these procedures. Such additional
The bundle processing procedures mandated in this section and in Section 6 govern the operation of the Bundle Protocol Agent and the Application Agent administrative element of each bundle node. They are neither exhaustive nor exclusive. That is, supplementary DTN protocol specifications (including, but not restricted to, the Bundle Security Protocol [BSP]) may require that additional measures be taken at specified junctures in these procedures. Such additional
Scott & Burleigh Experimental [Page 24] RFC 5050 Bundle Protocol Specification November 2007
Scott & Burleigh Experimental [Page 24] RFC 5050 Bundle Protocol Specification November 2007
measures shall not override or supersede the mandated bundle protocol procedures, except that they may in some cases make these procedures moot by requiring, for example, that implementations conforming to the supplementary protocol terminate the processing of a given incoming or outgoing bundle due to a fault condition recognized by that protocol.
measures shall not override or supersede the mandated bundle protocol procedures, except that they may in some cases make these procedures moot by requiring, for example, that implementations conforming to the supplementary protocol terminate the processing of a given incoming or outgoing bundle due to a fault condition recognized by that protocol.
5.1. Generation of Administrative Records
5.1. Generation of Administrative Records
All initial transmission of bundles is in response to bundle transmission requests presented by nodes' application agents. When required to "generate" an administrative record (a bundle status report or a custody signal), the bundle protocol agent itself is responsible for causing a new bundle to be transmitted, conveying that record. In concept, the bundle protocol agent discharges this responsibility by directing the administrative element of the node's application agent to construct the record and request its transmission as detailed in Section 6 below. In practice, the manner in which administrative record generation is accomplished is an implementation matter, provided the constraints noted in Section 6 are observed.
All initial transmission of bundles is in response to bundle transmission requests presented by nodes' application agents. When required to "generate" an administrative record (a bundle status report or a custody signal), the bundle protocol agent itself is responsible for causing a new bundle to be transmitted, conveying that record. In concept, the bundle protocol agent discharges this responsibility by directing the administrative element of the node's application agent to construct the record and request its transmission as detailed in Section 6 below. In practice, the manner in which administrative record generation is accomplished is an implementation matter, provided the constraints noted in Section 6 are observed.
Under some circumstances, the requesting of status reports could result in an unacceptable increase in the bundle traffic in the network. For this reason, the generation of status reports is mandatory only in one case, the deletion of a bundle for which custody transfer is requested. In all other cases, the decision on whether or not to generate a requested status report is left to the discretion of the bundle protocol agent. Mechanisms that could assist in making such decisions, such as pre-placed agreements authorizing the generation of status reports under specified circumstances, are beyond the scope of this specification.
Under some circumstances, the requesting of status reports could result in an unacceptable increase in the bundle traffic in the network. For this reason, the generation of status reports is mandatory only in one case, the deletion of a bundle for which custody transfer is requested. In all other cases, the decision on whether or not to generate a requested status report is left to the discretion of the bundle protocol agent. Mechanisms that could assist in making such decisions, such as pre-placed agreements authorizing the generation of status reports under specified circumstances, are beyond the scope of this specification.
Notes on administrative record terminology:
Notes on administrative record terminology:
o A "bundle reception status report" is a bundle status report with
the "reporting node received bundle" flag set to 1.
o A "bundle reception status report" is a bundle status report with the "reporting node received bundle" flag set to 1.
o A "custody acceptance status report" is a bundle status report
with the "reporting node accepted custody of bundle" flag set to
1.
o A "custody acceptance status report" is a bundle status report with the "reporting node accepted custody of bundle" flag set to 1.
o A "bundle forwarding status report" is a bundle status report with
the "reporting node forwarded the bundle" flag set to 1.
o A "bundle forwarding status report" is a bundle status report with the "reporting node forwarded the bundle" flag set to 1.
o A "bundle delivery status report" is a bundle status report with
the "reporting node delivered the bundle" flag set to 1.
o A "bundle delivery status report" is a bundle status report with the "reporting node delivered the bundle" flag set to 1.
Scott & Burleigh Experimental [Page 25] RFC 5050 Bundle Protocol Specification November 2007
Scott & Burleigh Experimental [Page 25] RFC 5050 Bundle Protocol Specification November 2007
o A "bundle deletion status report" is a bundle status report with
the "reporting node deleted the bundle" flag set to 1.
o A "bundle deletion status report" is a bundle status report with the "reporting node deleted the bundle" flag set to 1.
o A "Succeeded" custody signal is a custody signal with the "custody
transfer succeeded" flag set to 1.
o A "Succeeded" custody signal is a custody signal with the "custody transfer succeeded" flag set to 1.
o A "Failed" custody signal is a custody signal with the "custody
transfer succeeded" flag set to zero.
o A "Failed" custody signal is a custody signal with the "custody transfer succeeded" flag set to zero.
o The "current custodian" of a bundle is the endpoint identified by
the current custodian endpoint ID in the bundle's primary block.
o The "current custodian" of a bundle is the endpoint identified by the current custodian endpoint ID in the bundle's primary block.
5.2. Bundle Transmission
5.2. Bundle Transmission
The steps in processing a bundle transmission request are:
The steps in processing a bundle transmission request are:
Step 1: If custody transfer is requested for this bundle
transmission and, moreover, custody acceptance by the source node
is required, then either the bundle protocol agent must commit to
accepting custody of the bundle -- in which case processing
proceeds from Step 2 -- or the request cannot be honored and all
remaining steps of this procedure must be skipped. The bundle
protocol agent must not commit to accepting custody of a bundle if
the conditions under which custody of the bundle may be accepted
are not satisfied. The conditions under which a node may accept
custody of a bundle whose destination is not a singleton endpoint
are not defined in this specification.
Step 1: If custody transfer is requested for this bundle transmission and, moreover, custody acceptance by the source node is required, then either the bundle protocol agent must commit to accepting custody of the bundle -- in which case processing proceeds from Step 2 -- or the request cannot be honored and all remaining steps of this procedure must be skipped. The bundle protocol agent must not commit to accepting custody of a bundle if the conditions under which custody of the bundle may be accepted are not satisfied. The conditions under which a node may accept custody of a bundle whose destination is not a singleton endpoint are not defined in this specification.
Step 2: Transmission of the bundle is initiated. An outbound
bundle must be created per the parameters of the bundle
transmission request, with current custodian endpoint ID set to
the null endpoint ID "dtn:none" and with the retention constraint
"Dispatch pending". The source endpoint ID of the bundle must be
either the ID of an endpoint of which the node is a member or the
null endpoint ID "dtn:none".
Step 2: Transmission of the bundle is initiated. An outbound bundle must be created per the parameters of the bundle transmission request, with current custodian endpoint ID set to the null endpoint ID "dtn:none" and with the retention constraint "Dispatch pending". The source endpoint ID of the bundle must be either the ID of an endpoint of which the node is a member or the null endpoint ID "dtn:none".
Step 3: Processing proceeds from Step 1 of Section 5.4.
Step 3: Processing proceeds from Step 1 of Section 5.4.
5.3. Bundle Dispatching
5.3. Bundle Dispatching
The steps in dispatching a bundle are:
The steps in dispatching a bundle are:
Step 1: If the bundle's destination endpoint is an endpoint of
which the node is a member, the bundle delivery procedure defined
in Section 5.7 must be followed.
Step 1: If the bundle's destination endpoint is an endpoint of which the node is a member, the bundle delivery procedure defined in Section 5.7 must be followed.
Step 2: Processing proceeds from Step 1 of Section 5.4.
Step 2: Processing proceeds from Step 1 of Section 5.4.
Scott & Burleigh Experimental [Page 26] RFC 5050 Bundle Protocol Specification November 2007
Scott & Burleigh Experimental [Page 26] RFC 5050 Bundle Protocol Specification November 2007
5.4. Bundle Forwarding
5.4. Bundle Forwarding
The steps in forwarding a bundle are:
The steps in forwarding a bundle are:
Step 1: The retention constraint "Forward pending" must be added to
the bundle, and the bundle's "Dispatch pending" retention
constraint must be removed.
Step 1: The retention constraint "Forward pending" must be added to the bundle, and the bundle's "Dispatch pending" retention constraint must be removed.
Step 2: The bundle protocol agent must determine whether or not
forwarding is contraindicated for any of the reasons listed in
Figure 12. In particular:
Step 2: The bundle protocol agent must determine whether or not forwarding is contraindicated for any of the reasons listed in Figure 12. In particular:
* The bundle protocol agent must determine which endpoint(s) to
forward the bundle to. The bundle protocol agent may choose
either to forward the bundle directly to its destination
endpoint (if possible) or to forward the bundle to some other
endpoint(s) for further forwarding. The manner in which this
decision is made may depend on the scheme name in the
destination endpoint ID but in any case is beyond the scope of
this document. If the agent finds it impossible to select any
endpoint(s) to forward the bundle to, then forwarding is
contraindicated.
* The bundle protocol agent must determine which endpoint(s) to forward the bundle to. The bundle protocol agent may choose either to forward the bundle directly to its destination endpoint (if possible) or to forward the bundle to some other endpoint(s) for further forwarding. The manner in which this decision is made may depend on the scheme name in the destination endpoint ID but in any case is beyond the scope of this document. If the agent finds it impossible to select any endpoint(s) to forward the bundle to, then forwarding is contraindicated.
* Provided the bundle protocol agent succeeded in selecting the
endpoint(s) to forward the bundle to, the bundle protocol agent
must select the convergence layer adapter(s) whose services
will enable the node to send the bundle to the nodes of the
minimum reception group of each selected endpoint. The manner
in which the appropriate convergence layer adapters are
selected may depend on the scheme name in the destination
endpoint ID but in any case is beyond the scope of this
document. If the agent finds it impossible to select
convergence layer adapters to use in forwarding this bundle,
then forwarding is contraindicated.
* Provided the bundle protocol agent succeeded in selecting the endpoint(s) to forward the bundle to, the bundle protocol agent must select the convergence layer adapter(s) whose services will enable the node to send the bundle to the nodes of the minimum reception group of each selected endpoint. The manner in which the appropriate convergence layer adapters are selected may depend on the scheme name in the destination endpoint ID but in any case is beyond the scope of this document. If the agent finds it impossible to select convergence layer adapters to use in forwarding this bundle, then forwarding is contraindicated.
Step 3: If forwarding of the bundle is determined to be
contraindicated for any of the reasons listed in Figure 12, then
the Forwarding Contraindicated procedure defined in Section 5.4.1
must be followed; the remaining steps of Section 5 are skipped at
this time.
Step 3: If forwarding of the bundle is determined to be contraindicated for any of the reasons listed in Figure 12, then the Forwarding Contraindicated procedure defined in Section 5.4.1 must be followed; the remaining steps of Section 5 are skipped at this time.
Step 4: If the bundle's custody transfer requested flag (in the
bundle processing flags field) is set to 1, then the custody
transfer procedure defined in Section 5.10.2 must be followed.
Step 4: If the bundle's custody transfer requested flag (in the bundle processing flags field) is set to 1, then the custody transfer procedure defined in Section 5.10.2 must be followed.
Scott & Burleigh Experimental [Page 27] RFC 5050 Bundle Protocol Specification November 2007
Scott & Burleigh Experimental [Page 27] RFC 5050 Bundle Protocol Specification November 2007
Step 5: For each endpoint selected for forwarding, the bundle
protocol agent must invoke the services of the selected
convergence layer adapter(s) in order to effect the sending of the
bundle to the nodes constituting the minimum reception group of
that endpoint. Determining the time at which the bundle is to be
sent by each convergence layer adapter is an implementation
matter.
Step 5: For each endpoint selected for forwarding, the bundle protocol agent must invoke the services of the selected convergence layer adapter(s) in order to effect the sending of the bundle to the nodes constituting the minimum reception group of that endpoint. Determining the time at which the bundle is to be sent by each convergence layer adapter is an implementation matter.
To keep from possibly invalidating bundle security, the sequencing
of the blocks in a forwarded bundle must not be changed as it
transits a node; received blocks must be transmitted in the same
relative order as that in which they were received. While blocks
may be added to bundles as they transit intermediate nodes,
removal of blocks that do not have their 'Discard block if it
can't be processed' flag in the block processing control flags set
to 1 may cause security to fail.
To keep from possibly invalidating bundle security, the sequencing of the blocks in a forwarded bundle must not be changed as it transits a node; received blocks must be transmitted in the same relative order as that in which they were received. While blocks may be added to bundles as they transit intermediate nodes, removal of blocks that do not have their 'Discard block if it can't be processed' flag in the block processing control flags set to 1 may cause security to fail.
Step 6: When all selected convergence layer adapters have informed
the bundle protocol agent that they have concluded their data
sending procedures with regard to this bundle:
Step 6: When all selected convergence layer adapters have informed the bundle protocol agent that they have concluded their data sending procedures with regard to this bundle:
* If the "request reporting of bundle forwarding" flag in the
bundle's status report request field is set to 1, then a bundle
forwarding status report should be generated, destined for the
bundle's report-to endpoint ID. If the bundle has the
retention constraint "custody accepted" and all of the nodes in
the minimum reception group of the endpoint selected for
forwarding are known to be unable to send bundles back to this
node, then the reason code on this bundle forwarding status
report must be "forwarded over unidirectional link"; otherwise,
the reason code must be "no additional information".
* If the "request reporting of bundle forwarding" flag in the bundle's status report request field is set to 1, then a bundle forwarding status report should be generated, destined for the bundle's report-to endpoint ID. If the bundle has the retention constraint "custody accepted" and all of the nodes in the minimum reception group of the endpoint selected for forwarding are known to be unable to send bundles back to this node, then the reason code on this bundle forwarding status report must be "forwarded over unidirectional link"; otherwise, the reason code must be "no additional information".
* The bundle's "Forward pending" retention constraint must be
removed.
* The bundle's "Forward pending" retention constraint must be removed.
5.4.1. Forwarding Contraindicated
5.4.1. Forwarding Contraindicated
The steps in responding to contraindication of forwarding for some reason are:
The steps in responding to contraindication of forwarding for some reason are:
Step 1: The bundle protocol agent must determine whether or not to
declare failure in forwarding the bundle for this reason. Note:
this decision is likely to be influenced by the reason for which
forwarding is contraindicated.
Step 1: The bundle protocol agent must determine whether or not to declare failure in forwarding the bundle for this reason. Note: this decision is likely to be influenced by the reason for which forwarding is contraindicated.
Scott & Burleigh Experimental [Page 28] RFC 5050 Bundle Protocol Specification November 2007
Scott & Burleigh Experimental [Page 28] RFC 5050 Bundle Protocol Specification November 2007
Step 2: If forwarding failure is declared, then the Forwarding
Failed procedure defined in Section 5.4.2 must be followed.
Otherwise, (a) if the bundle's custody transfer requested flag (in
the bundle processing flags field) is set to 1, then the custody
transfer procedure defined in Section 5.10 must be followed; (b)
when -- at some future time - the forwarding of this bundle ceases
to be contraindicated, processing proceeds from Step 5 of
Section 5.4.
Step 2: If forwarding failure is declared, then the Forwarding Failed procedure defined in Section 5.4.2 must be followed. Otherwise, (a) if the bundle's custody transfer requested flag (in the bundle processing flags field) is set to 1, then the custody transfer procedure defined in Section 5.10 must be followed; (b) when -- at some future time - the forwarding of this bundle ceases to be contraindicated, processing proceeds from Step 5 of Section 5.4.
5.4.2. Forwarding Failed
5.4.2. Forwarding Failed
The steps in responding to a declaration of forwarding failure for some reason are:
The steps in responding to a declaration of forwarding failure for some reason are:
Step 1: If the bundle's custody transfer requested flag (in the
bundle processing flags field) is set to 1, custody transfer
failure must be handled. Procedures for handling failure of
custody transfer for a bundle whose destination is not a singleton
endpoint are not defined in this specification. For a bundle
whose destination is a singleton endpoint, the bundle protocol
agent must handle the custody transfer failure by generating a
"Failed" custody signal for the bundle, destined for the bundle's
current custodian; the custody signal must contain a reason code
corresponding to the reason for which forwarding was determined to
be contraindicated. (Note that discarding the bundle will not
delete it from the network, since the current custodian still has
a copy.)
Step 1: If the bundle's custody transfer requested flag (in the bundle processing flags field) is set to 1, custody transfer failure must be handled. Procedures for handling failure of custody transfer for a bundle whose destination is not a singleton endpoint are not defined in this specification. For a bundle whose destination is a singleton endpoint, the bundle protocol agent must handle the custody transfer failure by generating a "Failed" custody signal for the bundle, destined for the bundle's current custodian; the custody signal must contain a reason code corresponding to the reason for which forwarding was determined to be contraindicated. (Note that discarding the bundle will not delete it from the network, since the current custodian still has a copy.)
Step 2: If the bundle's destination endpoint is an endpoint of
which the node is a member, then the bundle's "Forward pending"
retention constraint must be removed. Otherwise, the bundle must
be deleted: the bundle deletion procedure defined in Section 5.13
must be followed, citing the reason for which forwarding was
determined to be contraindicated.
Step 2: If the bundle's destination endpoint is an endpoint of which the node is a member, then the bundle's "Forward pending" retention constraint must be removed. Otherwise, the bundle must be deleted: the bundle deletion procedure defined in Section 5.13 must be followed, citing the reason for which forwarding was determined to be contraindicated.
5.5. Bundle Expiration
5.5. Bundle Expiration
A bundle expires when the current time is greater than the bundle's creation time plus its lifetime as specified in the primary bundle block. Bundle expiration may occur at any point in the processing of a bundle. When a bundle expires, the bundle protocol agent must delete the bundle for the reason "lifetime expired": the bundle deletion procedure defined in Section 5.13 must be followed.
A bundle expires when the current time is greater than the bundle's creation time plus its lifetime as specified in the primary bundle block. Bundle expiration may occur at any point in the processing of a bundle. When a bundle expires, the bundle protocol agent must delete the bundle for the reason "lifetime expired": the bundle deletion procedure defined in Section 5.13 must be followed.
Scott & Burleigh Experimental [Page 29] RFC 5050 Bundle Protocol Specification November 2007
Scott & Burleigh Experimental [Page 29] RFC 5050 Bundle Protocol Specification November 2007
5.6. Bundle Reception
5.6. Bundle Reception
The steps in processing a bundle received from another node are:
The steps in processing a bundle received from another node are:
Step 1: The retention constraint "Dispatch pending" must be added
to the bundle.
Step 1: The retention constraint "Dispatch pending" must be added to the bundle.
Step 2: If the "request reporting of bundle reception" flag in the
bundle's status report request field is set to 1, then a bundle
reception status report with reason code "No additional
information" should be generated, destined for the bundle's
report-to endpoint ID.
Step 2: If the "request reporting of bundle reception" flag in the bundle's status report request field is set to 1, then a bundle reception status report with reason code "No additional information" should be generated, destined for the bundle's report-to endpoint ID.
Step 3: For each block in the bundle that is an extension block
that the bundle protocol agent cannot process:
Step 3: For each block in the bundle that is an extension block that the bundle protocol agent cannot process:
* If the block processing flags in that block indicate that a
status report is requested in this event, then a bundle
reception status report with reason code "Block unintelligible"
should be generated, destined for the bundle's report-to
endpoint ID.
* If the block processing flags in that block indicate that a status report is requested in this event, then a bundle reception status report with reason code "Block unintelligible" should be generated, destined for the bundle's report-to endpoint ID.
* If the block processing flags in that block indicate that the
bundle must be deleted in this event, then the bundle protocol
agent must delete the bundle for the reason "Block
unintelligible"; the bundle deletion procedure defined in
Section 5.13 must be followed and all remaining steps of the
bundle reception procedure must be skipped.
* If the block processing flags in that block indicate that the bundle must be deleted in this event, then the bundle protocol agent must delete the bundle for the reason "Block unintelligible"; the bundle deletion procedure defined in Section 5.13 must be followed and all remaining steps of the bundle reception procedure must be skipped.
* If the block processing flags in that block do NOT indicate
that the bundle must be deleted in this event but do indicate
that the block must be discarded, then the bundle protocol
agent must remove this block from the bundle.
* If the block processing flags in that block do NOT indicate that the bundle must be deleted in this event but do indicate that the block must be discarded, then the bundle protocol agent must remove this block from the bundle.
* If the block processing flags in that block indicate NEITHER
that the bundle must be deleted NOR that the block must be
discarded, then the bundle protocol agent must set to 1 the
"Block was forwarded without being processed" flag in the block
processing flags of the block.
* If the block processing flags in that block indicate NEITHER that the bundle must be deleted NOR that the block must be discarded, then the bundle protocol agent must set to 1 the "Block was forwarded without being processed" flag in the block processing flags of the block.
Step 4: If the bundle's custody transfer requested flag (in the
bundle processing flags field) is set to 1 and the bundle has the
same source endpoint ID, creation timestamp, and (if the bundle is
a fragment) fragment offset and payload length as another bundle
that (a) has not been discarded and (b) currently has the
retention constraint "Custody accepted", custody transfer
redundancy must be handled. Otherwise, processing proceeds from
Step 5. Procedures for handling redundancy in custody transfer
Step 4: If the bundle's custody transfer requested flag (in the bundle processing flags field) is set to 1 and the bundle has the same source endpoint ID, creation timestamp, and (if the bundle is a fragment) fragment offset and payload length as another bundle that (a) has not been discarded and (b) currently has the retention constraint "Custody accepted", custody transfer redundancy must be handled. Otherwise, processing proceeds from Step 5. Procedures for handling redundancy in custody transfer
Scott & Burleigh Experimental [Page 30] RFC 5050 Bundle Protocol Specification November 2007
Scott & Burleigh Experimental [Page 30] RFC 5050 Bundle Protocol Specification November 2007
for a bundle whose destination is not a singleton endpoint are not
defined in this specification. For a bundle whose destination is
a singleton endpoint, the bundle protocol agent must handle
custody transfer redundancy by generating a "Failed" custody
signal for this bundle with reason code "Redundant reception",
destined for this bundle's current custodian, and removing this
bundle's "Dispatch pending" retention constraint.
for a bundle whose destination is not a singleton endpoint are not defined in this specification. For a bundle whose destination is a singleton endpoint, the bundle protocol agent must handle custody transfer redundancy by generating a "Failed" custody signal for this bundle with reason code "Redundant reception", destined for this bundle's current custodian, and removing this bundle's "Dispatch pending" retention constraint.
Step 5: Processing proceeds from Step 1 of Section 5.3.
Step 5: Processing proceeds from Step 1 of Section 5.3.
5.7. Local Bundle Delivery
5.7. Local Bundle Delivery
The steps in processing a bundle that is destined for an endpoint of which this node is a member are:
The steps in processing a bundle that is destined for an endpoint of which this node is a member are:
Step 1: If the received bundle is a fragment, the application data
unit reassembly procedure described in Section 5.9 must be
followed. If this procedure results in reassembly of the entire
original application data unit, processing of this bundle (whose
fragmentary payload has been replaced by the reassembled
application data unit) proceeds from Step 2; otherwise, the
retention constraint "Reassembly pending" must be added to the
bundle and all remaining steps of this procedure are skipped.
Step 1: If the received bundle is a fragment, the application data unit reassembly procedure described in Section 5.9 must be followed. If this procedure results in reassembly of the entire original application data unit, processing of this bundle (whose fragmentary payload has been replaced by the reassembled application data unit) proceeds from Step 2; otherwise, the retention constraint "Reassembly pending" must be added to the bundle and all remaining steps of this procedure are skipped.
Step 2: Delivery depends on the state of the registration whose
endpoint ID matches that of the destination of the bundle:
Step 2: Delivery depends on the state of the registration whose endpoint ID matches that of the destination of the bundle:
* If the registration is in the Active state, then the bundle
must be delivered subject to this registration (see Section 3.1
above) as soon as all previously received bundles that are
deliverable subject to this registration have been delivered.
* If the registration is in the Active state, then the bundle must be delivered subject to this registration (see Section 3.1 above) as soon as all previously received bundles that are deliverable subject to this registration have been delivered.
* If the registration is in the Passive state, then the
registration's delivery failure action must be taken (see
Section 3.1 above).
* If the registration is in the Passive state, then the registration's delivery failure action must be taken (see Section 3.1 above).
Step 3: As soon as the bundle has been delivered:
Step 3: As soon as the bundle has been delivered:
* If the "request reporting of bundle delivery" flag in the
bundle's status report request field is set to 1, then a bundle
delivery status report should be generated, destined for the
bundle's report-to endpoint ID. Note that this status report
only states that the payload has been delivered to the
application agent, not that the application agent has processed
that payload.
* If the "request reporting of bundle delivery" flag in the bundle's status report request field is set to 1, then a bundle delivery status report should be generated, destined for the bundle's report-to endpoint ID. Note that this status report only states that the payload has been delivered to the application agent, not that the application agent has processed that payload.
Scott & Burleigh Experimental [Page 31] RFC 5050 Bundle Protocol Specification November 2007
Scott & Burleigh Experimental [Page 31] RFC 5050 Bundle Protocol Specification November 2007
* If the bundle's custody transfer requested flag (in the bundle
processing flags field) is set to 1, custodial delivery must be
reported. Procedures for reporting custodial delivery for a
bundle whose destination is not a singleton endpoint are not
defined in this specification. For a bundle whose destination
is a singleton endpoint, the bundle protocol agent must report
custodial delivery by generating a "Succeeded" custody signal
for the bundle, destined for the bundle's current custodian.
* If the bundle's custody transfer requested flag (in the bundle processing flags field) is set to 1, custodial delivery must be reported. Procedures for reporting custodial delivery for a bundle whose destination is not a singleton endpoint are not defined in this specification. For a bundle whose destination is a singleton endpoint, the bundle protocol agent must report custodial delivery by generating a "Succeeded" custody signal for the bundle, destined for the bundle's current custodian.
5.8. Bundle Fragmentation
5.8. Bundle Fragmentation
It may at times be necessary for bundle protocol agents to reduce the sizes of bundles in order to forward them. This might be the case, for example, if the endpoint to which a bundle is to be forwarded is accessible only via intermittent contacts and no upcoming contact is long enough to enable the forwarding of the entire bundle.
It may at times be necessary for bundle protocol agents to reduce the sizes of bundles in order to forward them. This might be the case, for example, if the endpoint to which a bundle is to be forwarded is accessible only via intermittent contacts and no upcoming contact is long enough to enable the forwarding of the entire bundle.
The size of a bundle can be reduced by "fragmenting" the bundle. To fragment a bundle whose payload is of size M is to replace it with two "fragments" -- new bundles with the same source endpoint ID and creation timestamp as the original bundle -- whose payloads are the first N and the last (M - N) bytes of the original bundle's payload, where 0 < N < M. Note that fragments may themselves be fragmented, so fragmentation may in effect replace the original bundle with more than two fragments. (However, there is only one 'level' of fragmentation, as in IP fragmentation.)
The size of a bundle can be reduced by "fragmenting" the bundle. To fragment a bundle whose payload is of size M is to replace it with two "fragments" -- new bundles with the same source endpoint ID and creation timestamp as the original bundle -- whose payloads are the first N and the last (M - N) bytes of the original bundle's payload, where 0 < N < M. Note that fragments may themselves be fragmented, so fragmentation may in effect replace the original bundle with more than two fragments. (However, there is only one 'level' of fragmentation, as in IP fragmentation.)
Any bundle whose primary block's bundle processing flags do NOT indicate that it must not be fragmented may be fragmented at any time, for any purpose, at the discretion of the bundle protocol agent.
Any bundle whose primary block's bundle processing flags do NOT indicate that it must not be fragmented may be fragmented at any time, for any purpose, at the discretion of the bundle protocol agent.
Fragmentation shall be constrained as follows:
Fragmentation shall be constrained as follows:
o The concatenation of the payloads of all fragments produced by
fragmentation must always be identical to the payload of the
bundle that was fragmented. Note that the payloads of fragments
resulting from different fragmentation episodes, in different
parts of the network, may be overlapping subsets of the original
bundle's payload.
o The concatenation of the payloads of all fragments produced by fragmentation must always be identical to the payload of the bundle that was fragmented. Note that the payloads of fragments resulting from different fragmentation episodes, in different parts of the network, may be overlapping subsets of the original bundle's payload.
o The bundle processing flags in the primary block of each fragment
must be modified to indicate that the bundle is a fragment, and
both fragment offset and total application data unit length must
be provided at the end of each fragment's primary bundle block.
o The bundle processing flags in the primary block of each fragment must be modified to indicate that the bundle is a fragment, and both fragment offset and total application data unit length must be provided at the end of each fragment's primary bundle block.
o The primary blocks of the fragments will differ from that of the
fragmented bundle as noted above.
o The primary blocks of the fragments will differ from that of the fragmented bundle as noted above.
Scott & Burleigh Experimental [Page 32] RFC 5050 Bundle Protocol Specification November 2007
Scott & Burleigh Experimental [Page 32] RFC 5050 Bundle Protocol Specification November 2007
o The payload blocks of fragments will differ from that of the
fragmented bundle as noted above.
o The payload blocks of fragments will differ from that of the fragmented bundle as noted above.
o All blocks that precede the payload block at the time of
fragmentation must be replicated in the fragment with the lowest
offset.
o All blocks that precede the payload block at the time of fragmentation must be replicated in the fragment with the lowest offset.
o All blocks that follow the payload block at the time of
fragmentation must be replicated in the fragment with the highest
offset.
o All blocks that follow the payload block at the time of fragmentation must be replicated in the fragment with the highest offset.
o If the 'Block must be replicated in every fragment' bit is set to
1, then the block must be replicated in every fragment.
o If the 'Block must be replicated in every fragment' bit is set to 1, then the block must be replicated in every fragment.
o If the 'Block must be replicated in every fragment' bit is set to
zero, the block should be replicated in only one fragment.
o If the 'Block must be replicated in every fragment' bit is set to zero, the block should be replicated in only one fragment.
o The relative order of all blocks that are present in a fragment
must be the same as in the bundle prior to fragmentation.
o The relative order of all blocks that are present in a fragment must be the same as in the bundle prior to fragmentation.
5.9. Application Data Unit Reassembly
5.9. Application Data Unit Reassembly
If the concatenation -- as informed by fragment offsets and payload lengths -- of the payloads of all previously received fragments with the same source endpoint ID and creation timestamp as this fragment, together with the payload of this fragment, forms a byte array whose length is equal to the total application data unit length in the fragment's primary block, then:
If the concatenation -- as informed by fragment offsets and payload lengths -- of the payloads of all previously received fragments with the same source endpoint ID and creation timestamp as this fragment, together with the payload of this fragment, forms a byte array whose length is equal to the total application data unit length in the fragment's primary block, then:
o This byte array -- the reassembled application data unit -- must
replace the payload of this fragment.
o This byte array -- the reassembled application data unit -- must replace the payload of this fragment.
o The "Reassembly pending" retention constraint must be removed from
every other fragment whose payload is a subset of the reassembled
application data unit.
o The "Reassembly pending" retention constraint must be removed from every other fragment whose payload is a subset of the reassembled application data unit.
Note: reassembly of application data units from fragments occurs at destination endpoints as necessary; an application data unit may also be reassembled at some other endpoint on the route to the destination.
Note: reassembly of application data units from fragments occurs at destination endpoints as necessary; an application data unit may also be reassembled at some other endpoint on the route to the destination.
Scott & Burleigh Experimental [Page 33] RFC 5050 Bundle Protocol Specification November 2007
Scott & Burleigh Experimental [Page 33] RFC 5050 Bundle Protocol Specification November 2007
5.10. Custody Transfer
5.10. Custody Transfer
The conditions under which a node may accept custody of a bundle whose destination is not a singleton endpoint are not defined in this specification.
The conditions under which a node may accept custody of a bundle whose destination is not a singleton endpoint are not defined in this specification.
The decision as to whether or not to accept custody of a bundle whose destination is a singleton endpoint is an implementation matter that may involve both resource and policy considerations; however, if the bundle protocol agent has committed to accepting custody of the bundle (as described in Step 1 of Section 5.2), then custody must be accepted.
The decision as to whether or not to accept custody of a bundle whose destination is a singleton endpoint is an implementation matter that may involve both resource and policy considerations; however, if the bundle protocol agent has committed to accepting custody of the bundle (as described in Step 1 of Section 5.2), then custody must be accepted.
If the bundle protocol agent elects to accept custody of the bundle, then it must follow the custody acceptance procedure defined in Section 5.10.1.
If the bundle protocol agent elects to accept custody of the bundle, then it must follow the custody acceptance procedure defined in Section 5.10.1.
5.10.1. Custody Acceptance
5.10.1. Custody Acceptance
Procedures for acceptance of custody of a bundle whose destination is not a singleton endpoint are not defined in this specification.
Procedures for acceptance of custody of a bundle whose destination is not a singleton endpoint are not defined in this specification.
Procedures for acceptance of custody of a bundle whose destination is a singleton endpoint are defined as follows.
Procedures for acceptance of custody of a bundle whose destination is a singleton endpoint are defined as follows.
The retention constraint "Custody accepted" must be added to the bundle.
The retention constraint "Custody accepted" must be added to the bundle.
If the "request reporting of custody acceptance" flag in the bundle's status report request field is set to 1, a custody acceptance status report should be generated, destined for the report-to endpoint ID of the bundle. However, if a bundle reception status report was generated for this bundle (Step 1 of Section 5.6), then this report should be generated by simply turning on the "Reporting node accepted custody of bundle" flag in that earlier report's status flags byte.
If the "request reporting of custody acceptance" flag in the bundle's status report request field is set to 1, a custody acceptance status report should be generated, destined for the report-to endpoint ID of the bundle. However, if a bundle reception status report was generated for this bundle (Step 1 of Section 5.6), then this report should be generated by simply turning on the "Reporting node accepted custody of bundle" flag in that earlier report's status flags byte.
The bundle protocol agent must generate a "Succeeded" custody signal for the bundle, destined for the bundle's current custodian.
The bundle protocol agent must generate a "Succeeded" custody signal for the bundle, destined for the bundle's current custodian.
The bundle protocol agent must assert the new current custodian for the bundle. It does so by changing the current custodian endpoint ID in the bundle's primary block to the endpoint ID of one of the singleton endpoints in which the node is registered. This may entail appending that endpoint ID's null-terminated scheme name and SSP to the dictionary byte array in the bundle's primary block, and in some case it may also enable the (optional) removal of the current custodian endpoint ID's scheme name and/or SSP from the dictionary.
The bundle protocol agent must assert the new current custodian for the bundle. It does so by changing the current custodian endpoint ID in the bundle's primary block to the endpoint ID of one of the singleton endpoints in which the node is registered. This may entail appending that endpoint ID's null-terminated scheme name and SSP to the dictionary byte array in the bundle's primary block, and in some case it may also enable the (optional) removal of the current custodian endpoint ID's scheme name and/or SSP from the dictionary.
Scott & Burleigh Experimental [Page 34] RFC 5050 Bundle Protocol Specification November 2007
Scott & Burleigh Experimental [Page 34] RFC 5050 Bundle Protocol Specification November 2007
The bundle protocol agent may set a custody transfer countdown timer for this bundle; upon expiration of this timer prior to expiration of the bundle itself and prior to custody transfer success for this bundle, the custody transfer failure procedure detailed in Section 5.12 must be followed. The manner in which the countdown interval for such a timer is determined is an implementation matter.
The bundle protocol agent may set a custody transfer countdown timer for this bundle; upon expiration of this timer prior to expiration of the bundle itself and prior to custody transfer success for this bundle, the custody transfer failure procedure detailed in Section 5.12 must be followed. The manner in which the countdown interval for such a timer is determined is an implementation matter.
The bundle should be retained in persistent storage if possible.
The bundle should be retained in persistent storage if possible.
5.10.2. Custody Release
5.10.2. Custody Release
Procedures for release of custody of a bundle whose destination is not a singleton endpoint are not defined in this specification.
Procedures for release of custody of a bundle whose destination is not a singleton endpoint are not defined in this specification.
When custody of a bundle is released, where the destination of the bundle is a singleton endpoint, the "Custody accepted" retention constraint must be removed from the bundle and any custody transfer timer that has been established for this bundle must be destroyed.
When custody of a bundle is released, where the destination of the bundle is a singleton endpoint, the "Custody accepted" retention constraint must be removed from the bundle and any custody transfer timer that has been established for this bundle must be destroyed.
5.11. Custody Transfer Success
5.11. Custody Transfer Success
Procedures for determining custody transfer success for a bundle whose destination is not a singleton endpoint are not defined in this specification.
Procedures for determining custody transfer success for a bundle whose destination is not a singleton endpoint are not defined in this specification.
Upon receipt of a "Succeeded" custody signal at a node that is a custodial node of the bundle identified in the custody signal, where the destination of the bundle is a singleton endpoint, custody of the bundle must be released as described in Section 5.10.2.
Upon receipt of a "Succeeded" custody signal at a node that is a custodial node of the bundle identified in the custody signal, where the destination of the bundle is a singleton endpoint, custody of the bundle must be released as described in Section 5.10.2.
5.12. Custody Transfer Failure
5.12. Custody Transfer Failure
Procedures for determining custody transfer failure for a bundle whose destination is not a singleton endpoint are not defined in this specification. Custody transfer for a bundle whose destination is a singleton endpoint is determined to have failed at a custodial node for that bundle when either (a) that node's custody transfer timer for that bundle (if any) expires or (b) a "Failed" custody signal for that bundle is received at that node.
Procedures for determining custody transfer failure for a bundle whose destination is not a singleton endpoint are not defined in this specification. Custody transfer for a bundle whose destination is a singleton endpoint is determined to have failed at a custodial node for that bundle when either (a) that node's custody transfer timer for that bundle (if any) expires or (b) a "Failed" custody signal for that bundle is received at that node.
Upon determination of custody transfer failure, the action taken by the bundle protocol agent is implementation-specific and may depend on the nature of the failure. For example, if custody transfer failure was inferred from expiration of a custody transfer timer or was asserted by a "Failed" custody signal with the "Depleted storage" reason code, the bundle protocol agent might choose to re-forward the bundle, possibly on a different route (Section 5.4). Receipt of a "Failed" custody signal with the "Redundant reception" reason code,
Upon determination of custody transfer failure, the action taken by the bundle protocol agent is implementation-specific and may depend on the nature of the failure. For example, if custody transfer failure was inferred from expiration of a custody transfer timer or was asserted by a "Failed" custody signal with the "Depleted storage" reason code, the bundle protocol agent might choose to re-forward the bundle, possibly on a different route (Section 5.4). Receipt of a "Failed" custody signal with the "Redundant reception" reason code,
Scott & Burleigh Experimental [Page 35] RFC 5050 Bundle Protocol Specification November 2007
Scott & Burleigh Experimental [Page 35] RFC 5050 Bundle Protocol Specification November 2007
on the other hand, might cause the bundle protocol agent to release custody of the bundle and to revise its algorithm for computing countdown intervals for custody transfer timers.
on the other hand, might cause the bundle protocol agent to release custody of the bundle and to revise its algorithm for computing countdown intervals for custody transfer timers.
5.13. Bundle Deletion
5.13. Bundle Deletion
The steps in deleting a bundle are:
The steps in deleting a bundle are:
Step 1: If the retention constraint "Custody accepted" currently
prevents this bundle from being discarded, and the destination of
the bundle is a singleton endpoint, then:
Step 1: If the retention constraint "Custody accepted" currently prevents this bundle from being discarded, and the destination of the bundle is a singleton endpoint, then:
* Custody of the node is released as described in Section 5.10.2.
* Custody of the node is released as described in Section 5.10.2.
* A bundle deletion status report citing the reason for deletion
must be generated, destined for the bundle's report-to endpoint
ID.
* A bundle deletion status report citing the reason for deletion must be generated, destined for the bundle's report-to endpoint ID.
Otherwise, if the "request reporting of bundle deletion" flag in
the bundle's status report request field is set to 1, then a
bundle deletion status report citing the reason for deletion
should be generated, destined for the bundle's report-to endpoint
ID.
Otherwise, if the "request reporting of bundle deletion" flag in the bundle's status report request field is set to 1, then a bundle deletion status report citing the reason for deletion should be generated, destined for the bundle's report-to endpoint ID.
Step 2: All of the bundle's retention constraints must be removed.
Step 2: All of the bundle's retention constraints must be removed.
5.14. Discarding a Bundle
5.14. Discarding a Bundle
As soon as a bundle has no remaining retention constraints it may be discarded.
As soon as a bundle has no remaining retention constraints it may be discarded.
5.15. Canceling a Transmission
5.15. Canceling a Transmission
When requested to cancel a specified transmission, where the bundle created upon initiation of the indicated transmission has not yet been discarded, the bundle protocol agent must delete that bundle for the reason "transmission cancelled". For this purpose, the procedure defined in Section 5.13 must be followed.
When requested to cancel a specified transmission, where the bundle created upon initiation of the indicated transmission has not yet been discarded, the bundle protocol agent must delete that bundle for the reason "transmission cancelled". For this purpose, the procedure defined in Section 5.13 must be followed.
5.16. Polling
5.16. Polling
When requested to poll a specified registration that is in the Passive state, the bundle protocol agent must immediately deliver the least recently received bundle that is deliverable subject to the indicated registration, if any.
When requested to poll a specified registration that is in the Passive state, the bundle protocol agent must immediately deliver the least recently received bundle that is deliverable subject to the indicated registration, if any.
Scott & Burleigh Experimental [Page 36] RFC 5050 Bundle Protocol Specification November 2007
Scott & Burleigh Experimental [Page 36] RFC 5050 Bundle Protocol Specification November 2007
6. Administrative Record Processing
6. Administrative Record Processing
6.1. Administrative Records
6.1. Administrative Records
Administrative records are standard application data units that are used in providing some of the features of the Bundle Protocol. Two types of administrative records have been defined to date: bundle status reports and custody signals.
Administrative records are standard application data units that are used in providing some of the features of the Bundle Protocol. Two types of administrative records have been defined to date: bundle status reports and custody signals.
Every administrative record consists of a four-bit record type code followed by four bits of administrative record flags, followed by record content in type-specific format. Record type codes are defined as follows:
Every administrative record consists of a four-bit record type code followed by four bits of administrative record flags, followed by record content in type-specific format. Record type codes are defined as follows:
+---------+--------------------------------------------+
| Value | Meaning |
+=========+============================================+
| 0001 | Bundle status report. |
+---------+--------------------------------------------+
| 0010 | Custody signal. |
+---------+--------------------------------------------+
| (other) | Reserved for future use. |
+---------+--------------------------------------------+
+---------+--------------------------------------------+ | Value | Meaning | +=========+============================================+ | 0001 | Bundle status report. | +---------+--------------------------------------------+ | 0010 | Custody signal. | +---------+--------------------------------------------+ | (other) | Reserved for future use. | +---------+--------------------------------------------+
Figure 8: Administrative Record Type Codes
Figure 8: Administrative Record Type Codes
+---------+--------------------------------------------+
| Value | Meaning |
+=========+============================================+
| 0001 | Record is for a fragment; fragment |
| | offset and length fields are present. |
+---------+--------------------------------------------+
| (other) | Reserved for future use. |
+---------+--------------------------------------------+
+---------+--------------------------------------------+ | Value | Meaning | +=========+============================================+ | 0001 | Record is for a fragment; fragment | | | offset and length fields are present. | +---------+--------------------------------------------+ | (other) | Reserved for future use. | +---------+--------------------------------------------+
Figure 9: Administrative Record Flags
Figure 9: Administrative Record Flags
All time values in administrative records are UTC times expressed in "DTN time" representation. A DTN time consists of an SDNV indicating the number of seconds since the start of the year 2000, followed by an SDNV indicating the number of nanoseconds since the start of the indicated second.
All time values in administrative records are UTC times expressed in "DTN time" representation. A DTN time consists of an SDNV indicating the number of seconds since the start of the year 2000, followed by an SDNV indicating the number of nanoseconds since the start of the indicated second.
The contents of the various types of administrative records are described below.
The contents of the various types of administrative records are described below.
Scott & Burleigh Experimental [Page 37] RFC 5050 Bundle Protocol Specification November 2007
Scott & Burleigh Experimental [Page 37] RFC 5050 Bundle Protocol Specification November 2007
6.1.1. Bundle Status Reports
6.1.1. Bundle Status Reports
The transmission of 'bundle status reports' under specified conditions is an option that can be invoked when transmission of a bundle is requested. These reports are intended to provide information about how bundles are progressing through the system, including notices of receipt, custody transfer, forwarding, final delivery, and deletion. They are transmitted to the Report-to endpoints of bundles.
The transmission of 'bundle status reports' under specified conditions is an option that can be invoked when transmission of a bundle is requested. These reports are intended to provide information about how bundles are progressing through the system, including notices of receipt, custody transfer, forwarding, final delivery, and deletion. They are transmitted to the Report-to endpoints of bundles.
+----------------+----------------+----------------+----------------+
| Status Flags | Reason code | Fragment offset (*) (if
+----------------+----------------+----------------+----------------+
present) | Fragment length (*) (if present) |
+----------------+----------------+----------------+----------------+
| Time of receipt of bundle X (a DTN time, if present) |
+----------------+----------------+----------------+----------------+
| Time of custody acceptance of bundle X (a DTN time, if present) |
+----------------+----------------+----------------+----------------+
| Time of forwarding of bundle X (a DTN time, if present) |
+----------------+----------------+----------------+----------------+
| Time of delivery of bundle X (a DTN time, if present) |
+----------------+----------------+----------------+----------------+
| Time of deletion of bundle X (a DTN time, if present) |
+----------------+----------------+----------------+----------------+
| Copy of bundle X's Creation Timestamp time (*) |
+----------------+----------------+----------------+----------------+
| Copy of bundle X's Creation Timestamp sequence number (*) |
+----------------+----------------+----------------+----------------+
| Length of X's source endpoint ID (*) | Source
+----------------+---------------------------------+ +
endpoint ID of bundle X (variable) |
+----------------+----------------+----------------+----------------+
+----------------+----------------+----------------+----------------+ | Status Flags | Reason code | Fragment offset (*) (if +----------------+----------------+----------------+----------------+ present) | Fragment length (*) (if present) | +----------------+----------------+----------------+----------------+ | Time of receipt of bundle X (a DTN time, if present) | +----------------+----------------+----------------+----------------+ | Time of custody acceptance of bundle X (a DTN time, if present) | +----------------+----------------+----------------+----------------+ | Time of forwarding of bundle X (a DTN time, if present) | +----------------+----------------+----------------+----------------+ | Time of delivery of bundle X (a DTN time, if present) | +----------------+----------------+----------------+----------------+ | Time of deletion of bundle X (a DTN time, if present) | +----------------+----------------+----------------+----------------+ | Copy of bundle X's Creation Timestamp time (*) | +----------------+----------------+----------------+----------------+ | Copy of bundle X's Creation Timestamp sequence number (*) | +----------------+----------------+----------------+----------------+ | Length of X's source endpoint ID (*) | Source +----------------+---------------------------------+ + endpoint ID of bundle X (variable) | +----------------+----------------+----------------+----------------+
Figure 10: Bundle Status Report Format
Figure 10: Bundle Status Report Format
(*) Notes:
(*) Notes:
The Fragment Offset field, if present, is an SDNV and is therefore variable length. A three-octet SDNV is shown here for convenience in representation.
The Fragment Offset field, if present, is an SDNV and is therefore variable length. A three-octet SDNV is shown here for convenience in representation.
The Fragment Length field, if present, is an SDNV and is therefore variable length. A three-octet SDNV is shown here for convenience in representation.
The Fragment Length field, if present, is an SDNV and is therefore variable length. A three-octet SDNV is shown here for convenience in representation.
Scott & Burleigh Experimental [Page 38] RFC 5050 Bundle Protocol Specification November 2007
Scott & Burleigh Experimental [Page 38] RFC 5050 Bundle Protocol Specification November 2007
The Creation Timestamp fields replicate the Creation Timestamp fields in the primary block of the subject bundle. As such they are SDNVs (see Section 4.5.1 above) and are therefore variable length. Four- octet SDNVs are shown here for convenience in representation.
The Creation Timestamp fields replicate the Creation Timestamp fields in the primary block of the subject bundle. As such they are SDNVs (see Section 4.5.1 above) and are therefore variable length. Four- octet SDNVs are shown here for convenience in representation.
The source endpoint ID length field is an SDNV and is therefore variable length. A three-octet SDNV is shown here for convenience in representation.
The source endpoint ID length field is an SDNV and is therefore variable length. A three-octet SDNV is shown here for convenience in representation.
The fields in a bundle status report are:
The fields in a bundle status report are:
Status Flags: A 1-byte field containing the following flags:
Status Flags: A 1-byte field containing the following flags:
+----------+--------------------------------------------+
| Value | Meaning |
+==========+============================================+
| 00000001 | Reporting node received bundle. |
+----------+--------------------------------------------+
| 00000010 | Reporting node accepted custody of bundle.|
+----------+--------------------------------------------+
| 00000100 | Reporting node forwarded the bundle. |
+----------+--------------------------------------------+
| 00001000 | Reporting node delivered the bundle. |
+----------+--------------------------------------------+
| 00010000 | Reporting node deleted the bundle. |
+----------+--------------------------------------------+
| 00100000 | Unused. |
+----------+--------------------------------------------+
| 01000000 | Unused. |
+----------+--------------------------------------------+
| 10000000 | Unused. |
+----------+--------------------------------------------+
+----------+--------------------------------------------+ | Value | Meaning | +==========+============================================+ | 00000001 | Reporting node received bundle. | +----------+--------------------------------------------+ | 00000010 | Reporting node accepted custody of bundle.| +----------+--------------------------------------------+ | 00000100 | Reporting node forwarded the bundle. | +----------+--------------------------------------------+ | 00001000 | Reporting node delivered the bundle. | +----------+--------------------------------------------+ | 00010000 | Reporting node deleted the bundle. | +----------+--------------------------------------------+ | 00100000 | Unused. | +----------+--------------------------------------------+ | 01000000 | Unused. | +----------+--------------------------------------------+ | 10000000 | Unused. | +----------+--------------------------------------------+
Figure 11: Status Flags for Bundle Status Reports
Figure 11: Status Flags for Bundle Status Reports
Reason Code: A 1-byte field explaining the value of the flags in
the status flags byte. The list of status report reason codes
provided here is neither exhaustive nor exclusive; supplementary
DTN protocol specifications (including, but not restricted to, the
Bundle Security Protocol [BSP]) may define additional reason
codes. Status report reason codes are defined as follows:
Reason Code: A 1-byte field explaining the value of the flags in the status flags byte. The list of status report reason codes provided here is neither exhaustive nor exclusive; supplementary DTN protocol specifications (including, but not restricted to, the Bundle Security Protocol [BSP]) may define additional reason codes. Status report reason codes are defined as follows:
Scott & Burleigh Experimental [Page 39] RFC 5050 Bundle Protocol Specification November 2007
Scott & Burleigh Experimental [Page 39] RFC 5050 Bundle Protocol Specification November 2007
+---------+--------------------------------------------+
| Value | Meaning |
+=========+============================================+
| 0x00 | No additional information. |
+---------+--------------------------------------------+
| 0x01 | Lifetime expired. |
+---------+--------------------------------------------+
| 0x02 | Forwarded over unidirectional link. |
+---------+--------------------------------------------+
| 0x03 | Transmission canceled. |
+---------+--------------------------------------------+
| 0x04 | Depleted storage. |
+---------+--------------------------------------------+
| 0x05 | Destination endpoint ID unintelligible. |
+---------+--------------------------------------------+
| 0x06 | No known route to destination from here. |
+---------+--------------------------------------------+
| 0x07 | No timely contact with next node on route.|
+---------+--------------------------------------------+
| 0x08 | Block unintelligible. |
+---------+--------------------------------------------+
| (other) | Reserved for future use. |
+---------+--------------------------------------------+
+---------+--------------------------------------------+ | 値| 意味| +=========+============================================+ | 0×00| 追加情報がありません。 | +---------+--------------------------------------------+ | 0×01| 寿命は期限が切れました。 | +---------+--------------------------------------------+ | 0×02| 単方向のリンクの上に送ります。 | +---------+--------------------------------------------+ | 0×03| トランスミッションは中止されました。 | +---------+--------------------------------------------+ | 0×04| ストレージを使い果たしました。 | +---------+--------------------------------------------+ | 0×05| 難解な目的地終点ID。 | +---------+--------------------------------------------+ | 0×06| ここから目的地への知られているルートがありません。 | +---------+--------------------------------------------+ | 0×07| ルート| +の次のノードとのタイムリーな接触がありません。---------+--------------------------------------------+ | 0×08| ブロック難解です。 | +---------+--------------------------------------------+ | (他)です。 | 今後の使用のために、予約されます。 | +---------+--------------------------------------------+
Figure 12: Status Report Reason Codes
図12: 現状報告理由コード
Fragment Offset: If the bundle fragment bit is set in the status
flags, then the offset (within the original application data unit)
of the payload of the bundle that caused the status report to be
generated is included here.
断片は相殺されました: バンドル断片ビットが状態旗で設定されるなら、現状報告を生成したバンドルのペイロードのオフセット(原出願データ単位の中の)はここに含まれています。
Fragment length: If the bundle fragment bit is set in the status
flags, then the length of the payload of the subject bundle is
included here.
長さを断片化してください: バンドル断片ビットが状態旗で設定されるなら、対象のバンドルのペイロードの長さはここに含まれています。
Time of Receipt (if present): If the bundle-received bit is set in
the status flags, then a DTN time indicating the time at which the
bundle was received at the reporting node is included here.
Receipt(存在しているなら)の時間: バンドルで容認されたビットが状態旗で設定されるなら、バンドルが報告ノードに受け取られた時を示すDTN時間はここに含まれています。
Time of Custody Acceptance (if present): If the custody-accepted
bit is set in the status flags, then a DTN time indicating the
time at which custody was accepted at the reporting node is
included here.
Custody Acceptance(存在しているなら)の時間: 保護で受け入れられたビットが状態旗で設定されるなら、保護が報告ノードで受け入れられた時を示すDTN時間はここに含まれています。
Time of Forward (if present): If the bundle-forwarded bit is set in
the status flags, then a DTN time indicating the time at which the
bundle was first forwarded at the reporting node is included here.
Forward(存在しているなら)の時間: バンドルで進められたビットが状態旗で設定されるなら、バンドルが最初に報告ノードで進められた時を示すDTN時間はここに含まれています。
Scott & Burleigh Experimental [Page 40] RFC 5050 Bundle Protocol Specification November 2007
スコットとバーレイの実験的な[40ページ]RFC5050バンドルは仕様2007年11月に議定書を作ります。
Time of Delivery (if present): If the bundle-delivered bit is set
in the status flags, then a DTN time indicating the time at which
the bundle was delivered at the reporting node is included here.
Delivery(存在しているなら)の時間: バンドルで提供されたビットが状態旗で設定されるなら、バンドルが報告ノードで提供された時を示すDTN時間はここに含まれています。
Time of Deletion (if present): If the bundle-deleted bit is set in
the status flags, then a DTN time indicating the time at which the
bundle was deleted at the reporting node is included here.
Deletion(存在しているなら)の時間: バンドルで削除されたビットが状態旗で設定されるなら、バンドルが報告ノードで削除された時を示すDTN時間はここに含まれています。
Creation Timestamp of Subject Bundle: A copy of the creation
timestamp of the bundle that caused the status report to be
generated.
対象のバンドルに関する作成タイムスタンプ: 現状報告を生成したバンドルに関する作成タイムスタンプのコピー。
Length of Source Endpoint ID: The length in bytes of the source
endpoint ID of the bundle that caused the status report to be
generated.
ソースEndpoint IDの長さ: 現状報告を生成したバンドルのソース終点IDのバイトで表現される長さ。
Source Endpoint ID text: The text of the source endpoint ID of the
bundle that caused the status report to be generated.
ソースEndpoint IDテキスト: 現状報告を生成したバンドルのソース終点IDのテキスト。
6.1.2. Custody Signals
6.1.2. 保護信号
Custody signals are administrative records that effect custody transfer operations. They are transmitted to the endpoints that are the current custodians of bundles.
保護信号は保護転送操作に作用する管理記録です。 それらはバンドルの現在の管理人である終点に送られます。
Custody signals have the following format.
保護信号には、以下の形式があります。
Custody signal regarding bundle 'X':
バンドル'X'に関する保護信号:
+----------------+----------------+----------------+----------------+
| Status | Fragment offset (*) (if present) |
+----------------+----------------+----------------+----------------+
| Fragment length (*) (if present) |
+----------------+----------------+----------------+----------------+
| Time of signal (a DTN time) |
+----------------+----------------+----------------+----------------+
| Copy of bundle X's Creation Timestamp time (*) |
+----------------+----------------+----------------+----------------+
| Copy of bundle X's Creation Timestamp sequence number (*) |
+----------------+----------------+----------------+----------------+
| Length of X's source endpoint ID (*) | Source
+----------------+---------------------------------+ +
endpoint ID of bundle X (variable) |
+----------------+----------------+----------------+----------------+
+----------------+----------------+----------------+----------------+ | 状態| 断片オフセット(*)(存在しているなら)| +----------------+----------------+----------------+----------------+ | 断片の長さ(*)(存在しているなら)| +----------------+----------------+----------------+----------------+ | 信号(DTN時間)の時間| +----------------+----------------+----------------+----------------+ | バンドルXのCreation Timestamp時間(*)のコピー| +----------------+----------------+----------------+----------------+ | バンドルXのCreation Timestamp一連番号(*)のコピー| +----------------+----------------+----------------+----------------+ | Xのソース終点ID(*)の長さ| ソース+----------------+---------------------------------+ + バンドルX(可変)の終点ID| +----------------+----------------+----------------+----------------+
Figure 13: Custody Signal Format
図13: 保護信号形式
Scott & Burleigh Experimental [Page 41] RFC 5050 Bundle Protocol Specification November 2007
スコットとバーレイの実験的な[41ページ]RFC5050バンドルは仕様2007年11月に議定書を作ります。
(*) Notes:
(*)注意:
The Fragment Offset field, if present, is an SDNV and is therefore variable length. A three-octet SDNV is shown here for convenience in representation.
Fragment Offset分野は、存在しているならSDNVであり、したがって、可変長です。 3八重奏のSDNVは表現における便宜のためにここに示されます。
The Fragment Length field, if present, is an SDNV and is therefore variable length. A four-octet SDNV is shown here for convenience in representation.
Fragment Length分野は、存在しているならSDNVであり、したがって、可変長です。 4八重奏のSDNVは表現における便宜のためにここに示されます。
The Creation Timestamp fields replicate the Creation Timestamp fields in the primary block of the subject bundle. As such they are SDNVs (see Section 4.5.1 above) and are therefore variable length. Four- octet SDNVs are shown here for convenience in representation.
Creation Timestamp分野は対象のバンドルのプライマリブロックのCreation Timestamp分野を模写します。 そういうものとして、それらは、SDNVs(セクション4.5.1が上であることを見る)であり、したがって、可変長です。 4八重奏SDNVsは表現における便宜のためにここに示されます。
The source endpoint ID length field is an SDNV and is therefore variable length. A three-octet SDNV is shown here for convenience in representation.
ソース終点ID長さの分野は、SDNVであり、したがって、可変長です。 3八重奏のSDNVは表現における便宜のためにここに示されます。
The fields in a custody signal are:
保護信号の分野は以下の通りです。
Status: A 1-byte field containing a 1-bit "custody transfer
succeeded" flag followed by a 7-bit reason code explaining the
value of that flag. Custody signal reason codes are defined as
follows:
状態: 1ビットの「転送が引き継いだ保護」旗を含む1バイトの野原はその旗の値がわかる7ビットの理由コードで続きました。 保護信号理由コードは以下の通り定義されます:
Scott & Burleigh Experimental [Page 42] RFC 5050 Bundle Protocol Specification November 2007
スコットとバーレイの実験的な[42ページ]RFC5050バンドルは仕様2007年11月に議定書を作ります。
+---------+--------------------------------------------+
| Value | Meaning |
+=========+============================================+
| 0x00 | No additional information. |
+---------+--------------------------------------------+
| 0x01 | Reserved for future use. |
+---------+--------------------------------------------+
| 0x02 | Reserved for future use. |
+---------+--------------------------------------------+
| 0x03 | Redundant reception (reception by a node |
| | that is a custodial node for this bundle).|
+---------+--------------------------------------------+
| 0x04 | Depleted storage. |
+---------+--------------------------------------------+
| 0x05 | Destination endpoint ID unintelligible. |
+---------+--------------------------------------------+
| 0x06 | No known route to destination from here. |
+---------+--------------------------------------------+
| 0x07 | No timely contact with next node on route.|
+---------+--------------------------------------------+
| 0x08 | Block unintelligible. |
+---------+--------------------------------------------+
| (other) | Reserved for future use. |
+---------+--------------------------------------------+
+---------+--------------------------------------------+ | 値| 意味| +=========+============================================+ | 0×00| 追加情報がありません。 | +---------+--------------------------------------------+ | 0×01| 今後の使用のために、予約されます。 | +---------+--------------------------------------------+ | 0×02| 今後の使用のために、予約されます。 | +---------+--------------------------------------------+ | 0×03| 余分なレセプション(ノードによるレセプション| | | それはこのバンドルのための保管のノードである)| +---------+--------------------------------------------+ | 0×04| ストレージを使い果たしました。 | +---------+--------------------------------------------+ | 0×05| 難解な目的地終点ID。 | +---------+--------------------------------------------+ | 0×06| ここから目的地への知られているルートがありません。 | +---------+--------------------------------------------+ | 0×07| ルート| +の次のノードとのタイムリーな接触がありません。---------+--------------------------------------------+ | 0×08| ブロック難解です。 | +---------+--------------------------------------------+ | (他)です。 | 今後の使用のために、予約されます。 | +---------+--------------------------------------------+
Figure 14: Custody Signal Reason Codes
図14: 保護信号理由コード
Fragment offset: If the bundle fragment bit is set in the status
flags, then the offset (within the original application data unit)
of the payload of the bundle that caused the status report to be
generated is included here.
断片は相殺されました: バンドル断片ビットが状態旗で設定されるなら、現状報告を生成したバンドルのペイロードのオフセット(原出願データ単位の中の)はここに含まれています。
Fragment length: If the bundle fragment bit is set in the status
flags, then the length of the payload of the subject bundle is
included here.
長さを断片化してください: バンドル断片ビットが状態旗で設定されるなら、対象のバンドルのペイロードの長さはここに含まれています。
Time of Signal: A DTN time indicating the time at which the signal
was generated.
信号の時間: 信号が生成された時を示すDTN時間。
Creation Timestamp of Subject Bundle: A copy of the creation
timestamp of the bundle to which the signal applies.
対象のバンドルに関する作成タイムスタンプ: 信号が適用されるバンドルに関する作成タイムスタンプのコピー。
Length of Source Endpoint ID: The length in bytes of the source
endpoint ID of the bundle to which the signal applied.
ソースEndpoint IDの長さ: 信号が適用されたバンドルのソース終点IDのバイトで表現される長さ。
Scott & Burleigh Experimental [Page 43] RFC 5050 Bundle Protocol Specification November 2007
スコットとバーレイの実験的な[43ページ]RFC5050バンドルは仕様2007年11月に議定書を作ります。
Source Endpoint ID text: The text of the source endpoint ID of the
bundle to which the signal applies.
ソースEndpoint IDテキスト: 信号が適用されるバンドルのソース終点IDのテキスト。
6.2. Generation of Administrative Records
6.2. 管理記録の世代
Whenever the application agent's administrative element is directed by the bundle protocol agent to generate an administrative record with reference to some bundle, the following procedure must be followed:
アプリケーションエージェントの管理要素が何らかのバンドルに関して管理記録を生成するようバンドルプロトコルエージェントによって指示されるときはいつも、以下の手順に従わなければなりません:
Step 1: The administrative record must be constructed. If the
referenced bundle is a fragment, the administrative record must
have the Fragment flag set and must contain the fragment offset
and fragment length fields. The value of the fragment offset
field must be the value of the referenced bundle's fragment
offset, and the value of the fragment length field must be the
length of the referenced bundle's payload.
ステップ1: 管理記録を構成しなければなりません。 参照をつけられたバンドルが断片であるなら、管理記録は、Fragment旗を設定させなければならなくて、断片オフセットと断片長さの分野を含まなければなりません。 断片の値は参照をつけられたバンドルの断片の値がオフセットでなければならなかったなら分野を相殺しました、そして、断片長さの分野の値は参照をつけられたバンドルのペイロードの長さでなければなりません。
Step 2: A request for transmission of a bundle whose payload is
this administrative record must be presented to the bundle
protocol agent.
ステップ2: ペイロードがこの管理記録であるバンドルの送信を求める要求をバンドルプロトコルエージェントに提示しなければなりません。
6.3. Reception of Custody Signals
6.3. 保護信号のレセプション
For each received custody signal that has the "custody transfer succeeded" flag set to 1, the administrative element of the application agent must direct the bundle protocol agent to follow the custody transfer success procedure in Section 5.11.
「転送が引き継いだ保護」旗を1に設定するそれぞれの受信された保護信号に関しては、アプリケーションエージェントの管理要素は、セクション5.11の保護転送成功手順に従うようバンドルプロトコルエージェントに指示しなければなりません。
For each received custody signal that has the "custody transfer succeeded" flag set to 0, the administrative element of the application agent must direct the bundle protocol agent to follow the custody transfer failure procedure in Section 5.12.
「転送が引き継いだ保護」旗を0に設定するそれぞれの受信された保護信号に関しては、アプリケーションエージェントの管理要素は、セクション5.12の保護転送失敗手順に従うようバンドルプロトコルエージェントに指示しなければなりません。
7. Services Required of the Convergence Layer
7. サービスが集合層について必要です。
7.1. The Convergence Layer
7.1. 集合層
The successful operation of the end-to-end bundle protocol depends on the operation of underlying protocols at what is termed the "convergence layer"; these protocols accomplish communication between nodes. A wide variety of protocols may serve this purpose, so long as each convergence layer protocol adapter provides a defined minimal set of services to the bundle protocol agent. This convergence layer service specification enumerates those services.
終わりから終わりへのバンドルプロトコルのうまくいっている操作は「集合層」と呼ばれることで基本的なプロトコルの操作によります。 これらのプロトコルはノードのコミュニケーションを達成します。 さまざまなプロトコルがこの目的に役立つかもしれません、それぞれの集合層のプロトコルアダプターがバンドルプロトコルエージェントに対する定義された極小集合のサービスを提供する限り。 この集合層のサービス仕様はそれらのサービスを列挙します。
Scott & Burleigh Experimental [Page 44] RFC 5050 Bundle Protocol Specification November 2007
スコットとバーレイの実験的な[44ページ]RFC5050バンドルは仕様2007年11月に議定書を作ります。
7.2. Summary of Convergence Layer Services
7.2. 集合層のサービスの概要
Each convergence layer protocol adapter is expected to provide the following services to the bundle protocol agent:
それぞれの集合層のプロトコルアダプターがバンドルプロトコルエージェントに対する以下のサービスを提供すると予想されます:
o sending a bundle to all bundle nodes in the minimum reception
group of the endpoint identified by a specified endpoint ID that
are reachable via the convergence layer protocol; and
o 集合層で届いた状態で指定された終点IDによって特定された終点の最小のレセプショングループにおけるノードをすべて添付するためにバンドルを送って、議定書を作ってください。 そして
o delivering to the bundle protocol agent a bundle that was sent by
a remote bundle node via the convergence layer protocol.
o リモートバンドルノードによって集合層のプロトコルで送られたバンドルをバンドルプロトコルエージェントに提供します。
The convergence layer service interface specified here is neither exhaustive nor exclusive. That is, supplementary DTN protocol specifications (including, but not restricted to, the Bundle Security Protocol [BSP]) may expect convergence layer adapters that serve BP implementations conforming to those protocols to provide additional services.
ここで指定された集合層のサービスインタフェースは、徹底的でなくて、また排他的ではありません。 すなわち、補っているDTNは仕様を議定書の中で述べます。(含んでいますが、部外秘でないことで、Bundle Securityプロトコル[BSP)は、それらのプロトコルに従う実装にBPに役立つ集合層のアダプターが追加サービスを提供すると予想するかもしれません。
8. Security Considerations
8. セキュリティ問題
The bundle protocol has taken security into concern from the outset of its design. It was always assumed that security services would be needed in the use of the bundle protocol. As a result, the bundle protocol security architecture and the available security services are specified in an accompanying document, the Bundle Security Protocol specification [BSP]; an informative overview of this architecture is provided in [SECO].
バンドルプロトコルはデザインの着手からの関心にセキュリティを連れていきました。 いつもセキュリティー・サービスがバンドルプロトコルの使用で必要であると思われました。 その結果、バンドルプロトコルセキュリティー体系と利用可能なセキュリティー・サービスは添付書類で指定されます、Bundle Securityプロトコル仕様[BSP]。 このアーキテクチャの有益な概要を[SECO]に提供します。
The bundle protocol has been designed with the notion that it will be run over networks with scarce resources. For example, the networks might have limited bandwidth, limited connectivity, constrained storage in relay nodes, etc. Therefore, the bundle protocol must ensure that only those entities authorized to send bundles over such constrained environments are actually allowed to do so. All unauthorized entities should be prevented from consuming valuable resources.
バンドルプロトコルは希少資源があるネットワークの上で走行になるという概念で設計されています。 例えば、ネットワークは帯域幅、限られた接続性、リレーノードにおける強制的なストレージなどを制限したかもしれません。 したがって、バンドルプロトコルは、そのような強制的な環境の上にバンドルを送るのが認可されたそれらの実体だけが実際にそうすることができるのを確実にしなければなりません。 すべての権限のない実体が貴重なリソースを消費するのが防がれるべきです。
Likewise, because of the potentially long latencies and delays involved in the networks that make use of the bundle protocol, data sources should be concerned with the integrity of the data received at the intended destination(s) and may also be concerned with ensuring confidentiality of the data as it traverses the network. Without integrity, the bundle payload data might be corrupted while in transit without the destination able to detect it. Similarly, the data source can be concerned with ensuring that the data can only be used by those authorized, hence the need for confidentiality.
同様に、データ送信端末は、バンドルプロトコルを利用するネットワークにかかわる潜在的に長い潜在と遅れのために、意図している目的地に受け取るデータの保全に関係があるべきであり、また、ネットワークを横断するのでデータの秘密性を確実にするのに関係があるかもしれません。 トランジットにはある間、保全、バンドルペイロードデータはそれを検出できる目的地なしで崩壊するかもしれません。 同様に、したがって、認可されたもの、秘密性の必要性でデータを使用できるだけであるのを確実にするのにデータ送信端末は関係がある場合があります。
Scott & Burleigh Experimental [Page 45] RFC 5050 Bundle Protocol Specification November 2007
スコットとバーレイの実験的な[45ページ]RFC5050バンドルは仕様2007年11月に議定書を作ります。
Internal to the bundle-aware overlay network, the bundle nodes should be concerned with the authenticity of other bundle nodes as well as the preservation of bundle payload data integrity as it is forwarded between bundle nodes.
バンドル意識しているオーバレイネットワークに内部です、バンドルノードの間にそれを送るとき、バンドルペイロードデータ保全の保存と同様に他のバンドルノードの信憑性にバンドルノードが関係があるべきです。
As a result, bundle security is concerned with the authenticity, integrity, and confidentiality of bundles conveyed among bundle nodes. This is accomplished via the use of three independent security-specific bundle blocks, which may be used together to provide multiple bundle security services or independently of one another, depending on perceived security threats, mandated security requirements, and security policies that must be enforced.
その結果、バンドルセキュリティはバンドルノードの中で伝えられたバンドルの信憑性、保全、および秘密性に関係があります。 これは複数のバンドルセキュリティー・サービスかお互いの如何にかかわらず提供するために一緒に使用されるかもしれない3つの独立しているセキュリティ特有のバンドルブロックの使用で達成されます、知覚された軍事的脅威、強制されたセキュリティ要件、および励行されなければならない安全保障政策によって。
The Bundle Authentication Block (BAB) ensures the authenticity and integrity of bundles on a hop-by-hop basis between bundle nodes. The BAB allows each bundle node to verify a bundle's authenticity before processing or forwarding the bundle. In this way, entities that are not authorized to send bundles will have unauthorized transmissions blocked by security-aware bundle nodes.
Bundle Authentication Block(BAB)はホップごとのバンドルノードの間のベースでバンドルの信憑性と保全を確実にします。 バンドルを処理するか、または進める前に、BABはそれぞれのバンドルノードにバンドルの信憑性について確かめさせます。 このように、バンドルを送るのは認可されない実体で、セキュリティ意識しているバンドルノードで権限のないトランスミッションを妨げるでしょう。
Additionally, to provide "security-source" to "security-destination" bundle authenticity and integrity, the Payload Security Block (PSB) is used. A "security-source" may not actually be the origination point of the bundle but instead may be the first point along the path that is security-aware and is able to apply security services. For example, an enclave of networked systems may generate bundles but only their gateway may be required and/or able to apply security services. The PSB allows any security-enabled entity along the delivery path, in addition to the "security-destination" (the recipient counterpart to the "security-source"), to ensure the bundle's authenticity.
さらに、「セキュリティ目的地」バンドルの信憑性と保全、有効搭載量Security Block(PSB)に「治安当局筋」を供給するのは使用されています。 「治安当局筋」は、実際にバンドルの創作ポイントでないかもしれませんが、代わりにセキュリティ意識している経路に沿った最初のポイントであるかもしれなく、セキュリティー・サービスを適用できます。 例えば、ネットワークでつながれたシステムの飛び地はバンドルを生成しますが、必要である、そして/または、それらのゲートウェイだけがセキュリティー・サービスを適用できるかもしれません。 PSBは配送経路に沿ったどんなセキュリティで可能にされた実体、「セキュリティ目的地」に加えた(「治安当局筋」への受取人対応者)にもバンドルの信憑性を確実にさせます。
Finally, to provide payload confidentiality, the use of the Confidentiality Block (CB) is available. The bundle payload may be encrypted to provide "security-source" to "security-destination" payload confidentiality/privacy. The CB indicates the cryptographic algorithm and key IDs that were used to encrypt the payload.
最終的に、ペイロード秘密性を提供するために、Confidentiality Block(CB)の使用は利用可能です。 バンドルペイロードは、「セキュリティ目的地」ペイロード秘密性/プライバシーに「治安当局筋」を提供するために暗号化されるかもしれません。 CBはペイロードを暗号化するのに使用された暗号アルゴリズムと主要なIDを示します。
Note that removal of strings from the dictionary at a given point in a bundle's end-to-end path, and attendant adjustment of endpoint ID references in the blocks of that bundle, may make it necessary to re- compute values in one or more of the bundle's security blocks.
終わりから端へのバンドルの経路の与えられたポイントの辞書からのストリングの取り外し、およびそのバンドルのブロックでの終点ID参照の付き添いの調整でバンドルのセキュリティブロックの1つ以上で値を再計算するのが必要になるかもしれないことに注意してください。
Bundle security must not be invalidated by forwarding nodes even though they themselves might not use the Bundle Security Protocol. In particular, the sequencing of the blocks in a forwarded bundle must not be changed as it transits a node; received blocks must be transmitted in the same relative order as that in which they were
Bundle Securityプロトコルを使用しないかもしれませんが、バンドルセキュリティは推進ノードによって無効にされてはいけません。 ノードを通過するのに従って、特に、進められたバンドルにおける、ブロックの配列を変えてはいけません。 それと同じそれらがそうであったのに相対オーダで受信されたブロックを伝えなければなりません。
Scott & Burleigh Experimental [Page 46] RFC 5050 Bundle Protocol Specification November 2007
スコットとバーレイの実験的な[46ページ]RFC5050バンドルは仕様2007年11月に議定書を作ります。
received. While blocks may be added to bundles as they transit intermediate nodes, removal of blocks that do not have their 'Discard block if it can't be processed' flag in the block processing control flags set to 1 may cause security to fail.
受け取られている。 中間的ノードを通過するときブロックがバンドルに加えられているかもしれない間、指揮旗が1に設定するブロック処理で'それを処理できないなら、ブロックを捨ててください'というそれらの旗を持っていないブロックの取り外しは、失敗するようにセキュリティを引き起こすかもしれません。
Inclusion of the Bundle Security Protocol in any Bundle Protocol implementation is RECOMMENDED. Use of the Bundle Security Protocol in Bundle Protocol operations is OPTIONAL.
どんなBundleプロトコル実装でのBundle Securityプロトコルの包含もRECOMMENDEDです。 Bundleプロトコル操作におけるBundle Securityプロトコルの使用はOPTIONALです。
9. IANA Considerations
9. IANA問題
The "dtn:" URI scheme has been provisionally registered by IANA. See http://www.iana.org/assignments/uri-schemes.html for the latest details.
「dtn:」 URI体系はIANAによって臨時に登録されました。 最新の詳細に関して http://www.iana.org/assignments/uri-schemes.html を見てください。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", RFC 3986,
STD 66, January 2005.
[URI]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC3986、STD66、2005年1月。
[URIREG] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", RFC 4395,
BCP 115, February 2006.
[URIREG] ハンセン、T.、ハーディー、T.、およびL.Masinter、「新しいURIのためのガイドラインと登録手順は計画します」、RFC4395、BCP115、2006年2月。
10.2. Informative References
10.2. 有益な参照
[ARCH] V. Cerf et. al., "Delay-Tolerant Network Architecture",
RFC 4838, April 2007.
[ARCH]V.サーフetアル、「遅れ許容性があるネットワークアーキテクチャ」、RFC4838、4月2007日
[ASN1] "Abstract Syntax Notation One (ASN.1), "ASN.1 Encoding
Rules: Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished Encoding
Rules (DER)," ITU-T Rec. X.690 (2002) | ISO/IEC 8825-
1:2002", 2003.
[ASN1]、「抽象構文記法1(ASN.1)、「ASN.1コード化は以下を統治します」。 「基本的な符号化規則(BER)、正準な符号化規則(CER)、および顕著な符号化規則(DER)の仕様」、ITU-T Rec。 X.690(2002)| 「ISO/IEC8825- 1: 2002」、2003
[BSP] Symington, S., "Bundle Security Protocol Specification",
Work Progress, October 2007.
[BSP] サイミントン、S.、「バンドルセキュリティプロトコル仕様」が2007年10月に進歩を扱います。
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005.
[RFC3987] DuerstとM.とM.Suignard、「国際化しているリソース識別子(虹彩)」、RFC3987、2005年1月。
Scott & Burleigh Experimental [Page 47] RFC 5050 Bundle Protocol Specification November 2007
スコットとバーレイの実験的な[47ページ]RFC5050バンドルは仕様2007年11月に議定書を作ります。
[SECO] Farrell, S., Symington, S., Weiss, H., and P. Lovell,
"Delay-Tolerant Networking Security Overview",
Work Progress, July 2007.
[SECO] ラベル、「遅れ許容性があるネットワークセキュリティ概要」が働かせるファレル、S.、サイミントン、S.、ウィス、H.、およびP.は2007年7月に進歩をします。
[SIGC] Fall, K., "A Delay-Tolerant Network Architecture for
Challenged Internets", SIGCOMM 2003 .
[SIGC]秋、K.、「挑戦されたインターネットのための遅れ許容性があるネットワークアーキテクチャ」SIGCOMM2003。
[TUT] Warthman, F., "Delay-Tolerant Networks (DTNs): A
Tutorial", <http://www.dtnrg.org>.
[舌打ち]Warthman、F.、「遅れ許容性があるネットワーク(DTNs):」 「チュートリアル」、<http://www.dtnrg.org>。
[UTC] Arias, E. and B. Guinot, ""Coordinated universal time UTC:
historical background and perspectives" in Journees
systemes de reference spatio-temporels", 2004.
[UTC] アリア、E.、およびB.Guinot、「「協定世界時UTC:」 Journees systemes de参照spatio-temporelsにおける「歴史的背景と見解」、」、2004
Scott & Burleigh Experimental [Page 48] RFC 5050 Bundle Protocol Specification November 2007
スコットとバーレイの実験的な[48ページ]RFC5050バンドルは仕様2007年11月に議定書を作ります。
Appendix A. Contributors
付録A.貢献者
This was an effort of the Delay Tolerant Networking Research Group. The following DTNRG participants contributed significant technical material and/or inputs: Dr. Vinton Cerf of Google, Scott Burleigh, Adrian Hooke, and Leigh Torgerson of the Jet Propulsion Laboratory, Michael Demmer of the University of California at Berkeley, Robert Durst, Keith Scott, and Susan Symington of The MITRE Corporation, Kevin Fall of Intel Research, Stephen Farrell of Trinity College Dublin, Peter Lovell of SPARTA, Inc., Manikantan Ramadas of Ohio University (most of Section 4.1), and Howard Weiss of SPARTA, Inc. (text of Section 8).
これはDelay Tolerant Networking Research Groupの取り組みでした。 以下のDTNRG関係者は重要な技工物、そして/または、入力を寄付しました: ジェット推進委研究所のGoogle、スコット・バーレイ、エードリアン・フック、およびリーTorgersonのビントン・サーフ博士、カリフォルニア大学バークレイ校のマイケルDemmer、ロバートがあえてそうして、キースがスコットであり、スーザンは、斜め継ぎ社のサイミントンと、インテルの研究のケビンFallと、トリニティー・カレッジダブリンのスティーブン・ファレルと、スパルタInc.のピーター・ラベルと、オハイオ大学のManikantan Ramadas(セクション4.1の大部分)と、スパルタInc.のハワード・ウィス(セクション8のテキスト)です。
Appendix B. Comments
付録B.コメント
Please refer comments to dtn-interest@mailman.dtnrg.org. The Delay Tolerant Networking Research Group (DTNRG) Web site is located at http://www.dtnrg.org.
dtn-interest@mailman.dtnrg.org をコメントを参照してください。 Delay Tolerant Networking Research Group(DTNRG)ウェブサイトは http://www.dtnrg.org に位置しています。
Authors' Addresses
作者のアドレス
Keith L. Scott The MITRE Corporation 7515 Colshire Drive McLean, VA 21102 US
キース・L.スコット斜め継ぎ社7515のColshireはマクリーン、ヴァージニア 21102を米国に追い立てます。
Phone: +1 703 983 6547 Fax: +1 703 983 7142 EMail: kscott@mitre.org
以下に電話をしてください。 +1 703 983、6547Fax: +1 7142年の703 983メール: kscott@mitre.org
Scott Burleigh NASA Jet Propulsion Laboratory 4800 Oak Grove Dr. Pasadena, CA 91109-8099 US
スコットバーレイNASAジェット推進委研究所4800オーク木立パサディナカリフォルニア91109-8099博士(米国)
Phone: +1 818 393 3353 Fax: +1 818 354 1075 EMail: Scott.Burleigh@jpl.nasa.gov
以下に電話をしてください。 +1 818 393、3353Fax: +1 1075年の818 354メール: Scott.Burleigh@jpl.nasa.gov
Scott & Burleigh Experimental [Page 49] RFC 5050 Bundle Protocol Specification November 2007
スコットとバーレイの実験的な[49ページ]RFC5050バンドルは仕様2007年11月に議定書を作ります。
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 at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78とwww.rfc-editor.org/copyright.htmlに含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんな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に情報を扱ってください。
Scott & Burleigh Experimental [Page 50]
スコットとバーレイ実験的です。[50ページ]
一覧
スポンサーリンク
