[要約] RFC 6693は、断続的に接続されたネットワークのための確率的なルーティングプロトコルに関するものです。このRFCの目的は、ネットワークの断続的な接続性を考慮しながら、信頼性の高いルーティングを提供することです。
Internet Research Task Force (IRTF) A. Lindgren
Request for Comments: 6693 SICS
Category: Experimental A. Doria
ISSN: 2070-1721 Technicalities
E. Davies
Folly Consulting
S. Grasic
Lulea University of Technology
August 2012
Probabilistic Routing Protocol for Intermittently Connected Networks
断続的に接続されたネットワークの確率的ルーティングプロトコル
Abstract
概要
This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised.
このドキュメントは、Delay Tolerant Networking Research Groupの製品であり、そのグループによってレビューされています。 RFCとしての発行に対する異議はありませんでした。
This document defines PRoPHET, a Probabilistic Routing Protocol using History of Encounters and Transitivity. PRoPHET is a variant of the epidemic routing protocol for intermittently connected networks that operates by pruning the epidemic distribution tree to minimize resource usage while still attempting to achieve the best-case routing capabilities of epidemic routing. It is intended for use in sparse mesh networks where there is no guarantee that a fully connected path between the source and destination exists at any time, rendering traditional routing protocols unable to deliver messages between hosts. These networks are examples of networks where there is a disparity between the latency requirements of applications and the capabilities of the underlying network (networks often referred to as delay and disruption tolerant). The document presents an architectural overview followed by the protocol specification.
このドキュメントでは、出会いと履歴の履歴を使用する確率的ルーティングプロトコルであるPRoPHETを定義します。 PRoPHETは断続的に接続されたネットワーク用の伝染性ルーティングプロトコルのバリアントであり、伝染性配信ツリーをプルーニングしてリソースの使用を最小限に抑えながら、伝染性ルーティングの最良のルーティング機能を実現しようとします。これは、送信元と宛先の間に完全に接続されたパスが常に存在する保証がなく、従来のルーティングプロトコルがホスト間でメッセージを配信できないスパースメッシュネットワークでの使用を目的としています。これらのネットワークは、アプリケーションのレイテンシ要件と、基盤となるネットワークの機能（遅延や破壊への耐性と呼ばれることが多い）の間に格差があるネットワークの例です。このドキュメントでは、アーキテクチャの概要とプロトコル仕様を示しています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Delay Tolerant Networking Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。この文書は、Internet Research Task Force（IRTF）の製品です。 IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適さない可能性があります。このRFCは、インターネット研究タスクフォース（IRTF）の遅延耐性ネットワーキング研究グループの合意を表します。 IRSGによる公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6693.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6693で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Relation to the Delay-Tolerant Networking Architecture . 7
1.2. Applicability of the Protocol . . . . . . . . . . . . . . 8
1.3. PRoPHET as Compared to Regular Routing Protocols . . . . 10
1.4. Requirements Notation . . . . . . . . . . . . . . . . . . 11
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1. PRoPHET . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.1. Characteristic Time Interval . . . . . . . . . . . . 12
2.1.2. Delivery Predictability Calculation . . . . . . . . . 12
2.1.3. Optional Delivery Predictability Optimizations . . . 17
2.1.4. Forwarding Strategies and Queueing Policies . . . . . 18
2.2. Bundle Protocol Agent to Routing Agent Interface . . . . 19
2.3. PRoPHET Zone Gateways . . . . . . . . . . . . . . . . . . 20
2.4. Lower-Layer Requirements and Interface . . . . . . . . . 21
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 22
3.1. Neighbor Awareness . . . . . . . . . . . . . . . . . . . 22
3.2. Information Exchange Phase . . . . . . . . . . . . . . . 23
3.2.1. Routing Information Base Dictionary . . . . . . . . . 25
3.2.2. Handling Multiple Simultaneous Contacts . . . . . . . 26
3.3. Routing Algorithm . . . . . . . . . . . . . . . . . . . . 28
3.4. Bundle Passing . . . . . . . . . . . . . . . . . . . . . 32
3.4.1. Custody . . . . . . . . . . . . . . . . . . . . . . . 33
3.5. When a Bundle Reaches Its Destination . . . . . . . . . . 33
3.6. Forwarding Strategies . . . . . . . . . . . . . . . . . . 34
3.7. Queueing Policies . . . . . . . . . . . . . . . . . . . . 36
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 38
4.1. Header . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2. TLV Structure . . . . . . . . . . . . . . . . . . . . . . 44
4.3. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3.1. Hello TLV . . . . . . . . . . . . . . . . . . . . . . 45
4.3.2. Error TLV . . . . . . . . . . . . . . . . . . . . . . 47
4.3.3. Routing Information Base Dictionary TLV . . . . . . . 48
4.3.4. Routing Information Base TLV . . . . . . . . . . . . 50
4.3.5. Bundle Offer and Response TLVs (Version 2) . . . . . 51
5. Detailed Operation . . . . . . . . . . . . . . . . . . . . . 55
5.1. High-Level State Tables . . . . . . . . . . . . . . . . . 56
5.2. Hello Procedure . . . . . . . . . . . . . . . . . . . . . 59
5.2.1. Hello Procedure State Tables . . . . . . . . . . . . 61
5.3. Information Exchange Phase . . . . . . . . . . . . . . . 62
5.3.1. State Definitions for the Initiator Role . . . . . . 66
5.3.2. State Definitions for the Listener Role . . . . . . . 71
5.3.3. Recommendations for Information Exchange Timer
Periods . . . . . . . . . . . . . . . . . . . . . . . 77
5.3.4. State Tables for Information Exchange . . . . . . . . 78
5.4. Interaction with Nodes Using Version 1 of PRoPHET . . . . 92
6. Security Considerations . . . . . . . . . . . . . . . . . . . 93
6.1. Attacks on the Operation of the Protocol . . . . . . . . 94
6.1.1. Black-Hole Attack . . . . . . . . . . . . . . . . . . 94
6.1.2. Limited Black-Hole Attack / Identity Spoofing . . . . 95
6.1.3. Fake PRoPHET ACKs . . . . . . . . . . . . . . . . . . 95
6.1.4. Bundle Store Overflow . . . . . . . . . . . . . . . . 96
6.1.5. Bundle Store Overflow with Delivery Predictability
Manipulation . . . . . . . . . . . . . . . . . . . . 96
6.2. Interactions with External Routing Domains . . . . . . . 97
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 97
7.1. DTN Routing Protocol Number . . . . . . . . . . . . . . . 98
7.2. PRoPHET Protocol Version . . . . . . . . . . . . . . . . 98
7.3. PRoPHET Header Flags . . . . . . . . . . . . . . . . . . 99
7.4. PRoPHET Result Field . . . . . . . . . . . . . . . . . . 99
7.5. PRoPHET Codes for Success and Codes for Failure . . . . . 99
7.6. PRoPHET TLV Type . . . . . . . . . . . . . . . . . . . . 100
7.7. Hello TLV Flags . . . . . . . . . . . . . . . . . . . . . 101
7.8. Error TLV Flags . . . . . . . . . . . . . . . . . . . . . 101
7.9. RIB Dictionary TLV Flags . . . . . . . . . . . . . . . . 102
7.10. RIB TLV Flags . . . . . . . . . . . . . . . . . . . . . . 102
7.11. RIB Flags . . . . . . . . . . . . . . . . . . . . . . . . 103
7.12. Bundle Offer and Response TLV Flags . . . . . . . . . . . 103
7.13. Bundle Offer and Response B Flags . . . . . . . . . . . . 104
8. Implementation Experience . . . . . . . . . . . . . . . . . . 104
9. Deployment Experience . . . . . . . . . . . . . . . . . . . . 105
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 105
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 105
11.1. Normative References . . . . . . . . . . . . . . . . . . 105
11.2. Informative References . . . . . . . . . . . . . . . . . 106
Appendix A. PRoPHET Example . . . . . . . . . . . . . . . . . . 108
Appendix B. Neighbor Discovery Example . . . . . . . . . . . . . 110
Appendix C. PRoPHET Parameter Calculation Example . . . . . . . 110
The Probabilistic Routing Protocol using History of Encounters and Transitivity (PRoPHET) algorithm enables communication between participating nodes wishing to communicate in an intermittently connected network where at least some of the nodes are mobile.
出会いの履歴と推移性（PRoPHET）アルゴリズムを使用した確率的ルーティングプロトコルにより、少なくとも一部のノードがモバイルである断続的に接続されたネットワークで通信したい参加ノード間の通信が可能になります。
One of the most basic requirements for "traditional" (IP) networking is that there must exist a fully connected path between communication endpoints for the duration of a communication session in order for communication to be possible. There are, however, a number of scenarios where connectivity is intermittent so that this is not the case (thus rendering the end-to-end use of traditional networking protocols impossible), but where it still is desirable to allow communication between nodes.
「従来の」（IP）ネットワーキングの最も基本的な要件の1つは、通信を可能にするために、通信セッションの間、通信エンドポイント間に完全に接続されたパスが存在する必要があることです。ただし、接続が断続的であるためにこれが当てはまらない（したがって、従来のネットワークプロトコルのエンドツーエンドの使用が不可能になる）シナリオがいくつかありますが、ノード間の通信を許可することが依然として望ましい場合があります。
Consider a network of mobile nodes using wireless communication with a limited range that is less than the typical excursion distances over which the nodes travel. Communication between a pair of nodes at a particular instant is only possible when the distance between the nodes is less than the range of the wireless communication. This means that, even if messages are forwarded through other nodes acting as intermediate routes, there is no guarantee of finding a viable continuous path when it is needed to transmit a message.
ノードが移動する通常の可動域距離よりも狭い範囲でワイヤレス通信を使用するモバイルノードのネットワークを考えてみます。特定の瞬間におけるノードのペア間の通信は、ノード間の距離が無線通信の範囲よりも短い場合にのみ可能です。つまり、中間ルートとして機能する他のノードを介してメッセージが転送されても、メッセージの送信が必要なときに実行可能な連続パスが見つかる保証はありません。
One way to enable communication in such scenarios is by allowing messages to be buffered at intermediate nodes for a longer time than normally occurs in the queues of conventional routers (cf. Delay-Tolerant Networking [RFC4838]). It would then be possible to exploit the mobility of a subset of the nodes to bring messages closer to their destination by transferring them to other nodes as they meet. Figure 1 shows how the mobility of nodes in such a scenario can be used to eventually deliver a message to its destination. In this figure, the four sub-figures (a) - (d) represent the physical positions of four nodes (A, B, C, and D) at four time instants, increasing from (a) to (d). The outline around each letter represents the range of the radio communication used for communication by the nodes: communication is only possible when the ranges overlap. At the start time, node A has a message -- indicated by an asterisk (*) next to that node -- to be delivered to node D, but there does not exist a path between nodes A and D because of the limited range of available wireless connections. As shown in sub-figures (a) - (d), the mobility of the nodes allows the message to first be transferred to node B, then to node C, and when finally node C moves within range of node D, it can deliver the message to its final destination. This technique is known as "transitive networking".
このようなシナリオで通信を可能にする1つの方法は、従来のルーターのキューで通常発生するよりも長い時間、中間ノードでメッセージをバッファーできるようにすることです（遅延耐性ネットワーク[RFC4838]を参照）。次に、ノードのサブセットのモビリティを活用して、メッセージを他のノードに転送することにより、メッセージを宛先に近づけることができます。図1は、このようなシナリオにおけるノードのモビリティを使用して、最終的にメッセージを宛先に配信する方法を示しています。この図では、4つのサブ図（a）から（d）は、（a）から（d）に増加する4つの時点での4つのノード（A、B、C、およびD）の物理的な位置を表しています。各文字の周囲の輪郭は、ノードによる通信に使用される無線通信の範囲を表しています。通信は、範囲が重複している場合にのみ可能です。開始時に、ノードAには、そのノードの隣にアスタリスク（*）で示されるメッセージがあり、ノードDに配信されますが、範囲が制限されているため、ノードAとDの間にパスが存在しません利用可能なワイヤレス接続。サブ図（a）から（d）に示すように、ノードの移動性により、メッセージは最初にノードB、次にノードCに転送され、最終的にノードCがノードDの範囲内に移動すると、メッセージを配信できます。最終的な宛先へのメッセージ。この手法は「推移的ネットワーキング」として知られています。
Mobility and contact patterns in real application scenarios are likely to be non-random, but rather be predictable, based on the underlying activities of the higher-level application (this could, for example, stem from human mobility having regular traffic patterns based on repeating behavioral patterns (e.g., going to work or the market and returning home) and social interactions, or from any number of other node mobility situations where a proportion of nodes are mobile and move in ways that are not completely random over time but have a degree of predictability over time). This means that if a node has visited a location or been in contact with a certain node several times before, it is likely that it will visit that location or meet that node again.
実際のアプリケーションシナリオでのモビリティと連絡先のパターンは、ランダムではない可能性が高いですが、上位レベルのアプリケーションの基になるアクティビティに基づいて予測できます（これは、たとえば、人間のモビリティが繰り返しに基づく定期的なトラフィックパターンを持っていることに起因する場合があります行動パターン（たとえば、仕事に行く、市場に行く、帰宅する）や社会的相互作用、またはノードの一部がモバイルであり、時間の経過とともに完全にランダムではないがある程度の方法で移動する他のノードモビリティ状況から時間の予測可能性の）。これは、ノードがロケーションを訪問したり、特定のノードと数回接触したりした場合、そのロケーションを訪問するか、そのノードに再び会う可能性が高いことを意味します。
PRoPHET can also be used in some networks where such mobility as described above does not take place. Predictable patterns in node contacts can also occur among static nodes where varying radio conditions or power-saving sleeping schedules cause connection between nodes to be intermittent.
PRoPHETは、上記のようなモビリティが行われない一部のネットワークでも使用できます。ノードの連絡先の予測可能なパターンは、さまざまな無線条件または節電スリープスケジュールによってノード間の接続が断続的になる静的ノード間でも発生する可能性があります。
In previously discussed mechanisms to enable communication in intermittently connected networks, such as Epidemic Routing [vahdat_00], very general approaches have been taken to the problem at hand. In an environment where buffer space and bandwidth are infinite, epidemic routing will give an optimal solution to the problem of routing in an intermittently connected network with regard to message delivery ratio and latency. However, in most cases, neither bandwidth nor buffer space is infinite, but instead they are rather scarce resources, especially in the case of sensor networks.
エピデミックルーティング[vahdat_00]など、断続的に接続されたネットワークでの通信を可能にする前述のメカニズムでは、当面の問題に対して非常に一般的なアプローチがとられてきました。バッファスペースと帯域幅が無限の環境では、伝染性ルーティングは、メッセージ配信率と遅延に関して断続的に接続されたネットワークでのルーティングの問題に対する最適なソリューションを提供します。ただし、ほとんどの場合、帯域幅もバッファスペースも無限ではありませんが、特にセンサーネットワークの場合は、それらはかなり少ないリソースです。
PRoPHET is fundamentally an epidemic protocol with strict pruning. An epidemic protocol works by transferring its data to each and every node it meets. As data is passed from node to node, it is eventually passed to all nodes, including the target node. One of the advantages of an epidemic protocol is that by trying every path, it is guaranteed to try the best path. One of the disadvantages of an epidemic protocol is the extensive use of resources with every node needing to carry every packet and the associated transmission costs. PRoPHET's goal is to gain the advantages of an epidemic protocol without paying the price in storage and communication resources incurred by the basic epidemic protocol. That is, PRoPHET offers an alternative to basic epidemic routing, with lower demands on buffer space and bandwidth, with equal or better performance in cases where those resources are limited, and without loss of generality in scenarios where it is suitable to use PRoPHET.
PRoPHETは基本的には、厳格な剪定を伴う流行のプロトコルです。伝染病プロトコルは、そのデータを、出会うすべてのノードに転送することで機能します。データがノードからノードに渡されると、最終的にはターゲットノードを含むすべてのノードに渡されます。伝染病プロトコルの利点の1つは、すべてのパスを試すことにより、最善のパスを試すことが保証されることです。流行プロトコルの欠点の1つは、すべてのノードがすべてのパケットとそれに関連する伝送コストを運ぶ必要があるため、リソースが広範囲に使用されることです。 PRoPHETの目標は、基本的な伝染病プロトコルによって発生するストレージおよび通信リソースの価格を支払うことなく、伝染病プロトコルの利点を獲得することです。つまり、PRoPHETは、バッファスペースと帯域幅への要求が少なく、リソースが制限されている場合と同等またはそれ以上のパフォーマンスで、基本的な流行ルーティングの代替手段を提供し、PRoPHETの使用に適したシナリオでは一般性を失うことはありません。
In a situation where PRoPHET is applicable, the patterns are expected to have a characteristic time (such as the expected time between encounters between mobile stations) that is in turn related to the expected time that traffic will take to reach its destination in the part of the network that is using PRoPHET. This characteristic time provides guidance for configuration of the PRoPHET protocol in a network. When appropriately configured, the PRoPHET protocol effectively builds a local model of the expected patterns in the network that can be used to optimize the usage of resources by reducing the amount of traffic sent to nodes that are unlikely to lead to eventual delivery of the traffic to its destination.
PRoPHETが適用可能な状況では、パターンには特徴的な時間（モバイルステーション間の遭遇間の予想時間など）があり、トラフィックが目的地に到達するまでにかかる予想時間に関連していることが予想されます。 PRoPHETを使用しているネットワーク。この特徴的な時間は、ネットワークでのPRoPHETプロトコルの構成に関するガイダンスを提供します。適切に構成されている場合、PRoPHETプロトコルは、ネットワークに予期されるパターンのローカルモデルを効果的に構築します。これは、最終的にトラフィックの配信につながる可能性が低いノードに送信されるトラフィックの量を減らすことにより、リソースの使用を最適化するために使用できます。その目的地。
+----------------------------+ +----------------------------+
| ___ | | ___ |
| ___ / \ | | / \ |
| / \ ( D ) | | ( D ) |
| ( B ) \___/ | | ___ \___/ |
| \___/ ___ | | /___\ ___ |
|___ / \ | | (/ B*\) / \ |
| \ ( C ) | | (\_A_/) ( C ) |
| A* ) \___/ | | \___/ \___/ |
|___/ | | |
+----------------------------+ +----------------------------+
(a) Time t (b) Time (t + dt)
+----------------------------+ +----------------------------+
| _____ ___ | | ___ ___ |
| / / \ \ / \ | | / \ /___\ |
| ( (B C* ) ( D ) | | ( B ) (/ D*\) |
| \_\_/_/ \___/ | | \___/ (\_C_/) |
| ___ | | ___ \___/ |
| / \ | | / \ |
| ( A ) | | ( A ) |
| \___/ | | \___/ |
| | | |
+----------------------------+ +----------------------------+
(c) Time (t + 2*dt) (d) Time (t + 3*dt)
Figure 1: Example of transitive communication
図1：推移的通信の例
This document presents a framework for probabilistic routing in intermittently connected networks, using an assumption of non-random mobility of nodes to improve the delivery rate of messages while keeping buffer usage and communication overhead at a low level. First, a probabilistic metric called delivery predictability is defined. The document then goes on to define a probabilistic routing protocol using this metric.
このドキュメントは、断続的に接続されたネットワークでの確率的ルーティングのフレームワークを示し、ノードのランダムでないモビリティの仮定を使用して、バッファーの使用率と通信オーバーヘッドを低いレベルに保ちながらメッセージの配信率を向上させます。最初に、配信予測可能性と呼ばれる確率論的メトリックが定義されます。次に、このメトリックを使用して確率論的ルーティングプロトコルを定義します。
The Delay-Tolerant Networking (DTN) architecture [RFC4838] defines an architecture for communication in environments where traditional communication protocols cannot be used due to excessive delays, link outages, and other extreme conditions. The intermittently connected networks considered here are a subset of those covered by the DTN architecture. The DTN architecture defines routes to be computed based on a collection of "contacts" indicating the start time, duration, endpoints, forwarding capacity, and latency of a link in the topology graph. These contacts may be deterministic or may be derived from estimates. The architecture defines some different types of intermittent contacts. The ones called "opportunistic" and "predicted" are the ones addressed by this protocol.
遅延許容ネットワーク（DTN）アーキテクチャ[RFC4838]は、過度の遅延、リンクの停止、およびその他の極端な条件のために従来の通信プロトコルを使用できない環境での通信のアーキテクチャを定義します。ここで検討されている断続的に接続されたネットワークは、DTNアーキテクチャでカバーされるネットワークのサブセットです。 DTNアーキテクチャは、トポロジグラフ内のリンクの開始時間、期間、エンドポイント、転送容量、および遅延を示す「連絡先」のコレクションに基づいて計算されるルートを定義します。これらの連絡先は、確定的であったり、推定から導き出されたりする場合があります。アーキテクチャは、いくつかの異なるタイプの断続的な連絡先を定義します。 「日和見的」および「予測的」と呼ばれるものは、このプロトコルによって対処されるものです。
Opportunistic contacts are those that are not scheduled, but rather present themselves unexpectedly and frequently arise due to node mobility. Predicted contacts are like opportunistic contacts, but, based on some information, it might be possible to draw some statistical conclusion as to whether or not a contact will be present soon.
日和見的連絡先とは、スケジュールされていない連絡先であり、ノードの移動性のために予期せずに頻繁に発生します。予測される連絡先は日和見的な連絡先のようなものですが、一部の情報に基づいて、連絡先がすぐに存在するかどうかについて統計的な結論を導き出すことが可能な場合があります。
The DTN architecture also introduces the bundle protocol [RFC5050], which provides a way for applications to "bundle" an entire session, including both data and metadata, into a single message, or bundle, that can be sent as a unit. The bundle protocol also provides end-to-end addressing and acknowledgments. PRoPHET is specifically intended to provide routing services in a network environment that uses bundles as its data transfer mechanism but could be also be used in other intermittent environments.
DTNアーキテクチャーは、バンドルプロトコル[RFC5050]も導入します。これは、アプリケーションがデータとメタデータの両方を含むセッション全体を単一のメッセージまたはバンドルにまとめて、ユニットとして送信できるようにします。バンドルプロトコルは、エンドツーエンドのアドレッシングと確認応答も提供します。 PRoPHETは特に、データ転送メカニズムとしてバンドルを使用するネットワーク環境でルーティングサービスを提供することを目的としていますが、他の断続的な環境でも使用できます。
The PRoPHET routing protocol is mainly targeted at situations where at least some of the nodes are mobile in a way that creates connectivity patterns that are not completely random over time but have a degree of predictability. Such connectivity patterns can also occur in networks where nodes switch off radios to preserve power. Human mobility patterns (often containing daily or weekly periodic activities) provide one such example where PRoPHET is expected to be applicable, but the applicability is not limited to scenarios including humans.
PRoPHETルーティングプロトコルは、主に、少なくとも一部のノードがモバイルであり、時間の経過とともに完全にランダムではないがある程度の予測可能性を持つ接続パターンを作成する状況を対象としています。このような接続パターンは、ノードが無線をオフにして電力を節約するネットワークでも発生する可能性があります。人間の移動パターン（多くの場合、毎日または毎週の定期的な活動を含む）は、PRoPHETが適用可能であると予想されるそのような例の1つですが、適用可能性は人間を含むシナリオに限定されません。
In order for PRoPHET to benefit from such predictability in the contact patterns between nodes, it is expected that the network exist under similar circumstances over a longer timescale (in terms of node encounters) so that the predictability can be accurately estimated.
PRoPHETがノード間の接触パターンでこのような予測可能性を利用するには、予測可能性を正確に推定できるように、ネットワークがより長いタイムスケール（ノードの遭遇に関して）にわたって同様の状況で存在することが期待されます。
The PRoPHET protocol expects nodes to be able to establish a local TCP link in order to exchange the information needed by the PRoPHET protocol. Protocol signaling is done out-of-band over this TCP link, without involving the bundle protocol agent [RFC5050]. However, the PRoPHET protocol is expected to interact with the bundle protocol agent to retrieve information about available bundles as well as to request that a bundle be sent to another node (it is expected that the associated bundle protocol agents are then able to establish a link (probably over the TCP convergence layer [CLAYER]) to perform this bundle transfer).
PRoPHETプロトコルは、ノードがPRoPHETプロトコルで必要な情報を交換するためにローカルTCPリンクを確立できることを期待しています。プロトコルシグナリングは、バンドルプロトコルエージェント[RFC5050]を使用せずに、このTCPリンクを介して帯域外で行われます。ただし、PRoPHETプロトコルは、バンドルプロトコルエージェントとやり取りして、利用可能なバンドルに関する情報を取得し、バンドルを別のノードに送信するように要求します（関連付けられているバンドルプロトコルエージェントがリンクを確立できることが期待されます） （おそらくTCP収束層[CLAYER]を介して）このバンドル転送を実行します）。
TCP provides a reliable bidirectional channel between two peers and guarantees in-order delivery of transmitted data. When using TCP, the guarantee of reliable, in-order delivery allows information exchanges of each category of information to be distributed across several messages without requiring the PRoPHET protocol layer to be concerned that all messages have been received before starting the exchange of the next category of information. At most, the last message of the category needs to be marked as such. This allows the receiver to process earlier messages while waiting for additional information and allows implementations to limit the size of messages so that IP fragmentation will be avoided and memory usage can be optimized if necessary. However, implementations MAY choose to build a single message for each category of information that is as large as necessary and rely on TCP to segment the message.
TCPは、2つのピア間に信頼性のある双方向チャネルを提供し、送信データの順序どおりの配信を保証します。 TCPを使用する場合、信頼性の高い順序どおりの配信の保証により、次のカテゴリの交換を開始する前にすべてのメッセージが受信されたことをPRoPHETプロトコルレイヤーが気にする必要なく、情報の各カテゴリの情報交換を複数のメッセージに分散できます。情報の。せいぜい、カテゴリーの最後のメッセージはそのようにマークされる必要があります。これにより、受信者は追加情報を待っている間に以前のメッセージを処理でき、実装でメッセージのサイズを制限できるため、IPフラグメンテーションが回避され、必要に応じてメモリ使用量を最適化できます。ただし、実装は、必要なだけの情報カテゴリごとに単一のメッセージを作成し、TCPに依存してメッセージをセグメント化することを選択できます。
While PRoPHET is currently defined to run over TCP, in future versions the information exchange may take place over other transport protocols, and these may not provide message segmentation or reliable, in-order delivery. The simple message division used with TCP MUST NOT be used when the underlying transport does not offer reliable, in-order delivery, as it would be impossible to verify that all the messages had arrived. Hence, the capability is provided to segment protocol messages into submessages directly in the PRoPHET layer. Submessages are provided with sequence numbers, and this, together with a capability for positive acknowledgements, would allow PRoPHET to operate over an unreliable protocol such as UDP or potentially directly over IP.
PRoPHETは現在TCP上で実行するように定義されていますが、将来のバージョンでは、情報交換は他のトランスポートプロトコル上で行われる可能性があり、メッセージセグメンテーションや信頼性の高い順序どおりの配信が提供されない可能性があります。すべてのメッセージが到着したことを確認することが不可能であるため、基になるトランスポートが信頼性の高い順序どおりの配信を提供しない場合は、TCPで使用される単純なメッセージ分割を使用してはなりません。したがって、プロトコルメッセージをPRoPHET層で直接サブメッセージに分割する機能が提供されます。サブメッセージにはシーケンス番号が付いており、これと肯定応答の機能により、PRoPHETは信頼性の低いプロトコル（UDPなど）を介して、またはIPを介して直接動作する可能性があります。
Since TCP offers reliable delivery, it is RECOMMENDED that the positive acknowledgment capability is not used when PRoPHET is run over a TCP transport or similar protocol. When running over TCP, implementations MAY safely ignore positive acknowledgments.
TCPは信頼性の高い配信を提供するため、TCPトランスポートまたは同様のプロトコルでPRoPHETが実行されている場合は、肯定応答機能を使用しないことをお勧めします。 TCPで実行する場合、実装は肯定的な確認応答を安全に無視できます。
Whatever transport protocol is used, PRoPHET expects to use a bidirectional link for the information exchange; this allows for the information exchange to take place in both directions over the same link avoiding the need to establish a second link for information exchange in the reverse direction.
どのトランスポートプロトコルを使用する場合でも、PRoPHETは情報交換に双方向リンクを使用することを期待しています。これにより、同じリンクを介して双方向で情報交換を行うことができ、逆方向の情報交換のために2番目のリンクを確立する必要がなくなります。
In a large Delay- and Disruption-Tolerant Network (DTN), network conditions may vary widely, and in different parts of the network, different routing protocols may be appropriate. In this specification, we consider routing within a single "PRoPHET zone", which is a set of nodes among which messages are routed using PRoPHET. In many cases, a PRoPHET zone will not span the entire DTN, but there will be other parts of the network with other characteristics that run other routing protocols. To handle this, there may be nodes within the zone that act as gateways to other nodes that are the destinations for bundles generated within the zone or that insert bundles into the zone. Thus, PRoPHET is not necessarily used end-to-end, but only within regions of the network where its use is appropriate.
大規模な遅延および破壊耐性ネットワーク（DTN）では、ネットワークの状態は大きく異なり、ネットワークの異なる部分では、異なるルーティングプロトコルが適切な場合があります。この仕様では、メッセージがPRoPHETを使用してルーティングされるノードのセットである単一の「PRoPHETゾーン」内のルーティングを検討します。多くの場合、PRoPHETゾーンはDTN全体には及びませんが、他のルーティングプロトコルを実行する他の特性を持つネットワークの他の部分があります。これを処理するために、ゾーン内に生成されたバンドルの宛先である、またはゾーンにバンドルを挿入する他のノードへのゲートウェイとして機能するノードがゾーン内にある場合があります。したがって、PRoPHETは必ずしもエンドツーエンドで使用されるわけではなく、その使用が適切なネットワークの領域内でのみ使用されます。
While PRoPHET uses a mechanism for pruning the epidemic forwarding tree that is similar to the mechanism used in metric-based vector routing protocols (where the metric might be distance or cost), it should not be confused with a metric vector protocol.
PRoPHETは、メトリックベースのベクトルルーティングプロトコルで使用されるメカニズム（メトリックは距離またはコストである可能性があります）と同様のメカニズムを流行の転送ツリーの枝刈りに使用しますが、メトリックベクトルプロトコルと混同しないでください。
In a traditional metric-based vector routing protocol, the information passed from node to node is used to create a single non-looping path from source to destination that is optimal given the metric used. The path consists of a set of directed edges selected from the complete graph of communications links between the network nodes.
従来のメトリックベースのベクトルルーティングプロトコルでは、ノードからノードに渡される情報を使用して、送信元から宛先への単一の非ループパスを作成し、使用されるメトリックが与えられた場合に最適です。パスは、ネットワークノード間の通信リンクの完全なグラフから選択された有向エッジのセットで構成されます。
In PRoPHET, that information is used to prune the epidemic tree of paths by removing paths that look less likely to provide an effective route for delivery of data to its intended destination. One of the effects of this difference is that the regular notions of split horizon, as described in [RFC1058], do not apply to PRoPHET. The purpose of split horizon is to prevent a distance vector protocol from ever passing a packet back to the node that sent it the packet because it is well known that the source does not lie in that direction as determined when the directed path was computed.
PRoPHETでは、その情報を使用して、目的の宛先にデータを配信するための効果的なルートを提供する可能性が低いと思われるパスを削除することにより、パスの流行ツリーをプルーニングします。この違いの影響の1つは、[RFC1058]で説明されているスプリットホライズンの通常の概念がPRoPHETに適用されないことです。スプリットホライズンの目的は、有向パスが計算されたときに決定されたソースがその方向にないことがよく知られているため、距離ベクトルプロトコルがパケットを送信したノードにパケットを渡さないようにすることです。
In an epidemic protocol, where that previous system already has the data, the notion of passing the data back to the node is redundant: the protocol can readily determine that such a transfer is not required. Further, given the mobility and constant churn of encounters possible in a DTN that is dominated by opportunistic encounters, it is quite possible that, on a future encounter, the node might have become a better option for reaching the destination. Such a later encounter may require a re-transfer of the data if resource constraints have resulted in the data being deleted from the original carrier between the encounters.
以前のシステムがすでにデータを保持している伝染病プロトコルでは、データをノードに戻すという概念は冗長です。プロトコルは、このような転送が不要であることを容易に判断できます。さらに、日和見的な出会いが優勢なDTNで起こり得る出会いの機動性と一定のチャーンを考えると、将来の出会いで、ノードが宛先に到達するためのより良いオプションになる可能性は十分にあります。リソースの制約によりデータが遭遇の間に元のキャリアから削除された場合、このような後の遭遇では、データの再転送が必要になることがあります。
The logic of metric routing protocols does not map directly onto the family of epidemic protocols. In particular, it is inappropriate to try to assess such protocols against the criteria used to assess conventional routing protocols such as the metric vector protocols; this is not to say that the family of epidemic protocols do not have weaknesses but they have to be considered independently of traditional protocols.
メトリックルーティングプロトコルのロジックは、伝染性プロトコルのファミリに直接マッピングされません。特に、メトリックベクトルプロトコルなどの従来のルーティングプロトコルの評価に使用される基準に照らして、そのようなプロトコルを評価しようとすることは不適切です。これは、流行プロトコルのファミリーに弱点がないと言っているわけではありませんが、伝統的なプロトコルとは無関係に考慮されなければなりません。
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 RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
This section presents an overview of the main architecture of PRoPHET, a Probabilistic Routing Protocol using History of Encounters and Transitivity. The protocol leverages the observations made on the non-randomness of mobility patterns present in many application scenarios to improve routing performance. Instead of doing blind epidemic replication of bundles through the network as previous protocols have done, it applies "probabilistic routing".
このセクションでは、出会いと履歴の履歴を使用した確率的ルーティングプロトコルであるPRoPHETの主なアーキテクチャの概要を示します。プロトコルは、ルーティングパフォーマンスを改善するために、多くのアプリケーションシナリオに存在するモビリティパターンの非ランダム性について行われた観察を活用します。以前のプロトコルが行っていたように、ネットワークを介してバンドルのブラインド流行レプリケーションを行う代わりに、「確率的ルーティング」を適用します。
To accomplish this, a metric called "delivery predictability", 0 <= P_(A,B) <= 1, is established at every node A for each known destination B. This metric is calculated so that a node with a higher value for a certain destination is estimated to be a better candidate for delivering a bundle to that destination (i.e., if P_(A,B)>P_(C,B), bundles for destination B are preferable to forward to A rather than C). It is later used when making forwarding decisions. As routes in a DTN are likely to be asymmetric, the calculation of the delivery predictability reflects this, and P_(A,B) may be different from P_(B,A).
これを達成するために、「配信予測可能性」と呼ばれるメトリック0 <= P_（A、B）<= 1は、既知の宛先BごとにすべてのノードAで確立されます。このメトリックは、特定の宛先は、その宛先にバンドルを配信するためのより良い候補であると推定されます（つまり、P_（A、B）> P_（C、B）の場合、宛先Bのバンドルは、CよりもAに転送する方が好ましいです）。後で転送の決定を行うときに使用されます。 DTN内のルートは非対称である可能性が高いため、配信の予測可能性の計算はこれを反映し、P_（A、B）はP_（B、A）と異なる場合があります。
The delivery predictability values in each node evolve over time both as a result of decay of the metrics between encounters between nodes and due to changes resulting from encounters when metric information for the encountered node is updated to reflect the encounter and metric information about other nodes is exchanged.
各ノードの配信予測可能性の値は、ノード間の遭遇間のメトリックの減衰の結果として、また、遭遇したノードのメトリック情報が他のノードの遭遇とメトリック情報を反映するように更新されたときに遭遇から生じる変更により、時間とともに進化します。交換した。
When two PRoPHET nodes have a communication opportunity, they initially enter a two-part Information Exchange Phase (IEP). In the first part of the exchange, the delivery predictabilities for all destinations known by each node are shared with the encountered node. The exchanged information is used by each node to update the internal delivery predictability vector as described below. After that, the nodes exchange information (including destination and size) about the bundles each node carries, and the information is used in conjunction with the updated delivery predictabilities to decide which bundles to request to be forwarded from the other node based on the forwarding strategy used (as discussed in Section 2.1.4). The forwarding of bundles is carried out in the latter part of the Information Exchange Phase.
2つのPRoPHETノードに通信機会がある場合、それらは最初に2部構成の情報交換フェーズ（IEP）に入ります。交換の最初の部分では、各ノードが認識しているすべての宛先の配信予測可能性が、遭遇したノードと共有されます。交換された情報は、各ノードが以下に説明するように内部配信予測可能性ベクトルを更新するために使用されます。その後、ノードは各ノードが運ぶバンドルに関する情報（宛先とサイズを含む）を交換し、その情報を更新された配信予測機能と組み合わせて使用して、転送戦略に基づいて他のノードから転送するよう要求するバンドルを決定します使用されます（セクション2.1.4で説明）。バンドルの転送は、情報交換フェーズの後半で実行されます。
When an application scenario makes PRoPHET applicable, the mobility pattern will exhibit a characteristic time interval that reflects the distribution of time intervals between encounters between nodes. The evolution of the delivery predictabilities, which reflects this mobility pattern, should reflect this same characteristic time interval. Accordingly, the parameters used in the equations that specify the evolution of delivery predictability (see Section 2.1.2) need to be configured appropriately so that the evolution reflects a model of the mobility pattern.
アプリケーションシナリオでPRoPHETを適用できる場合、モビリティパターンは、ノード間の遭遇間の時間間隔の分布を反映する特徴的な時間間隔を示します。この移動パターンを反映する配信予測可能性の進化は、この同じ特徴的な時間間隔を反映する必要があります。したがって、配信の予測可能性の進化を指定する方程式（セクション2.1.2を参照）で使用されるパラメータは、進化がモビリティパターンのモデルを反映するように適切に構成する必要があります。
As stated above, PRoPHET relies on calculating a metric based on the probability of encountering a certain node, and using that to support the decision of whether or not to forward a bundle to a certain node. This section describes the operations performed on the metrics stored in a node when it encounters another node and a communications opportunity arises. In the operations described by the equations that follow, the updates are being performed by node A, P_(A,B) is the delivery predictability value that node A will have stored for the destination B after the encounter, and P_(A,B)_old is the corresponding value that was stored before the encounter. If no delivery predictability value is stored for a particular destination B, P_(A,B) is considered to be zero.
上記のように、PRoPHETは、特定のノードに遭遇する確率に基づいてメトリックを計算し、それを使用してバンドルを特定のノードに転送するかどうかの決定をサポートすることに依存しています。このセクションでは、ノードに格納されているメトリックが別のノードに遭遇し、通信機会が生じたときに実行される操作について説明します。次の方程式で説明する操作では、更新はノードAによって実行されます。P_（A、B）は、遭遇後にノードAが宛先Bに格納する配信予測値であり、P_（A、B ）_oldは、遭遇前に保管された対応する値です。特定の宛先Bの配信予測可能性値が格納されていない場合、P_（A、B）はゼロと見なされます。
As a special case, the metric value for a node itself is always defined to be 1 (i.e., P_(A,A)=1).
特殊なケースとして、ノード自体のメトリック値は常に1と定義されます（つまり、P_（A、A）= 1）。
The equations use a number of parameters that can be selected to match the characteristics of the mobility pattern in the PRoPHET zone where the node is located (see Section 2.1.1). Recommended settings for the various parameters are given in Section 3.3. The impact on the evolution of delivery predictabilities if encountering nodes have different parameter setting is discussed in Section 2.1.2.1.
方程式は、ノードが配置されているPRoPHETゾーンのモビリティパターンの特性に一致するように選択できるいくつかのパラメータを使用します（セクション2.1.1を参照）。さまざまなパラメータの推奨設定は、セクション3.3に記載されています。遭遇するノードが異なるパラメータ設定を持っている場合の配信予測可能性の進化への影響については、2.1.2.1項で説明します。
The calculation of the updates to the delivery predictabilities during an encounter has three parts.
遭遇中の配信予測可能性の更新の計算には、3つの部分があります。
When two nodes meet, the first thing they do is to update the delivery predictability for each other, so that nodes that are often encountered have a high delivery predictability. If node B has not met node A for a long time or has never met node B, such that P_(A,B) < P_first_threshold, then P_(A,B) should be set to P_encounter_first. Because PRoPHET generally has no prior knowledge about whether this is an encounter that will be repeated relatively frequently or one that will be a rare event, P_encounter_first SHOULD be set to 0.5 unless the node has extra information obtained other than through the PRoPHET protocol about the likelihood of future encounters. Otherwise, P_(A,B) should be calculated as shown in Equation 1, where 0 <= P_encounter <= 1 is a scaling factor setting the rate at which the predictability increases on encounters after the first, and delta is a small positive number that effectively sets an upper bound for P_(A,B). The limit is set so that predictabilities between different nodes stay strictly less than 1. The value of delta should normally be very small (e.g., 0.01) so as not to significantly restrict the range of available predictabilities, but it can be chosen to make calculations efficient where this is important.
2つのノードが出会ったとき、最初に行うことは、お互いの配信予測可能性を更新することです。これにより、頻繁に遭遇するノードの配信予測可能性が高くなります。 P_（A、B）<P_first_thresholdのように、ノードBがノードAに長期間会っていないか、ノードBに会ったことがない場合、P_（A、B）をP_encounter_firstに設定する必要があります。 PRoPHETは通常、これが比較的頻繁に繰り返される遭遇であるか、またはまれなイベントである遭遇であるかについて事前の知識を持っていないため、ノードが可能性についてPRoPHETプロトコル以外で取得した追加情報を持たない限り、P_encounter_firstは0.5に設定する必要があります将来の出会いの。それ以外の場合、P_（A、B）は式1に示すように計算する必要があります。ここで、0 <= P_encounter <= 1は、最初の遭遇後の遭遇で予測可能性が増加するレートを設定するスケーリング係数であり、deltaは小さな正の数ですP_（A、B）の上限を効果的に設定します。制限は、異なるノード間の予測可能性が厳密に1未満になるように設定されます。デルタの値は、利用可能な予測可能性の範囲を大幅に制限しないように、通常は非常に小さく（たとえば、0.01）する必要がありますが、計算を行うために選択できますこれが重要な場合は効率的です。
P_(A,B) =
P_(A,B)_old + ( 1 - delta - P_(A,B)_old ) * P_encounter (Eq. 1)
There are practical circumstances where an encounter that is logically a single encounter in terms of the proximity of the node hardware and/or from the point of view of the human users of the nodes results in several communication opportunities closely spaced in time. For example, mobile nodes communicating with each other using Wi-Fi ad hoc mode may produce apparent multiple encounters with a short interval between them but these are frequently due to artifacts of the underlying physical network when using wireless connections, where transmission problems or small changes in location may result in repeated reconnections. In this case, it would be inappropriate to increase the delivery predictability by the same amount for each opportunity as it would be increased when encounters occur at longer intervals in the normal mobility pattern.
ノードハードウェアの近接性に関して、および/またはノードの人間のユーザーの観点から論理的に単一の出会いである出会いが、時間的に密集したいくつかの通信機会をもたらす実際の状況があります。たとえば、Wi-Fiアドホックモードを使用して相互に通信するモバイルノードは、短い間隔で複数の遭遇を見かけ上生成する可能性がありますが、これらはしばしば、無線接続を使用する際の基礎となる物理ネットワークのアーティファクトが原因であり、伝送の問題または小さな変更が発生しますロケーションにあると、再接続が繰り返される可能性があります。この場合、通常のモビリティパターンで遭遇がより長い間隔で発生する場合に増加するため、配信の予測可能性を機会ごとに同じ量だけ増加することは不適切です。
In order to reduce the distortion of the delivery predictability in these circumstances, P_encounter is a function of the interval since the last encounter resulted in an update of the delivery predictabilities. The form of the function is as shown in Figure 2.
これらの状況での配信予測可能性の歪みを減らすために、P_encounterは、最後の遭遇が配信予測可能性の更新をもたらしたので、間隔の関数です。関数の形式は、図2に示すとおりです。
P_encounter
^
|
P_encounter_max + - - .-------------------------------------
| /
| / .
| /
| / .
| /
| / .
|/
+-------+-------------------------------------> I
I_typ
Figure 2: P_encounter as function of time interval, I, between updates
図2：更新間の時間間隔Iの関数としてのP_encounter
The form of the function is chosen so that both the increase of P_(A,B) resulting from Equation 1 and the decrease that results from Equation 2 are related to the interval between updates for short intervals. For intervals longer than the "typical" time (I_typ) between encounters, P_encounter is set to a fixed value P_encounter_max. The break point reflects the transition between the "normal" communication opportunity regime (where opportunities result from the overall mobility pattern) and the closely spaced opportunities that result from what are effectively local artifacts of the wireless technology used to deliver those opportunities.
関数の形式は、式1から得られるP_（A、B）の増加と式2から得られる減少の両方が短い間隔の更新間隔に関連するように選択されます。遭遇間の「標準」時間（I_typ）より長い間隔の場合、P_encounterは固定値P_encounter_maxに設定されます。ブレークポイントは、「通常の」通信機会体制（全体的なモビリティパターンから機会が生じる）と、それらの機会を提供するために使用されるワイヤレステクノロジーのローカルアーティファクトが効果的に生じることから生じる間隔の狭い機会との間の移行を反映しています。
P_encounter_max is chosen so that the increment in P_(A,B) provided by Equation 1 significantly exceeds the decay of the delivery predictability over the typical interval between encounters resulting from Equation 2.
P_encounter_maxは、式1によって提供されるP_（A、B）の増分が、式2の結果である遭遇間の一般的な間隔での配信予測可能性の減衰を大幅に超えるように選択されます。
Making P_encounter dependent on the interval time also avoids inappropriate extra increments of P_(A,B) in situations where node A is in communication with several other nodes simultaneously. In this case, updates from each of the communicating nodes have to be distributed to the other nodes, possibly leading to several updates being carried out in a short period. This situation is discussed in more detail in Section 3.2.2.
P_encounterをインターバル時間に依存させることにより、ノードAが他のいくつかのノードと同時に通信している状況で、P_（A、B）の不適切な追加増分も回避されます。この場合、通信している各ノードからの更新を他のノードに配信する必要があるため、短期間にいくつかの更新が実行される可能性があります。この状況については、セクション3.2.2で詳しく説明します。
If a pair of nodes do not encounter each other during an interval, they are less likely to be good forwarders of bundles to each other, thus the delivery predictability values must age, being reduced in the process. The second part of the updates of the metric values is application of the aging equation shown in Equation 2, where 0 <= gamma <= 1 is the aging constant, and K is the number of time units that have elapsed since the last time the metric was aged. The time unit used can differ and should be defined based on the application and the expected delays in the targeted network.
ノードのペアがインターバル中に互いに遭遇しない場合、それらは互いにバンドルを適切に転送する可能性が低くなるため、配信予測可能性の値は古くなり、その過程で減少します。メトリック値の更新の2番目の部分は、式2に示すエージング方程式の適用です。ここで、0 <=ガンマ<= 1はエージング定数であり、Kは最後の時間から経過した時間単位の数ですメトリックは古くなりました。使用される時間単位は異なる場合があり、アプリケーションとターゲットネットワークでの予想される遅延に基づいて定義する必要があります。
P_(A,B) = P_(A,B)_old * gamma^K (Eq. 2)
The delivery predictabilities are aged according to Equation 2 before being passed to an encountered node so that they reflect the time that has passed since the node had its last encounter with any other node. The results of the aging process are sent to the encountered peer for use in the next stage of the process. The aged results received from node B in node A are referenced as P_(B,x)_recv.
配信の予測可能性は、ノードが他のノードと最後に遭遇してから経過した時間を反映するように、遭遇したノードに渡される前に式2に従ってエージングされます。エージングプロセスの結果は、プロセスの次のステージで使用するために、遭遇したピアに送信されます。ノードAのノードBから受信したエージング結果は、P_（B、x）_recvとして参照されます。
The delivery predictability also has a transitive property that is based on the observation that if node A frequently encounters node B, and node B frequently encounters node C, then node C probably is a good node to which to forward bundles destined for node A. Equation 3 shows how this transitivity affects the delivery predictability, where 0 <= beta <= 1 is a scaling constant that controls how large an impact the transitivity should have on the delivery predictability.
配信の予測可能性には、ノードAがノードBに頻繁に遭遇し、ノードBがノードCに頻繁に遭遇する場合、ノードCはおそらくノードA宛てのバンドルを転送する適切なノードであるという観察に基づく推移的な特性もあります。 3は、この推移性が配信の予測可能性にどのように影響するかを示しています。0<= beta <= 1は、推移性が配信の予測可能性に与える影響の大きさを制御するスケーリング定数です。
P_(A,C) = MAX( P_(A,C)_old, P_(A,B) * P_(B,C)_recv * beta ) (Eq. 3)
Node A uses Equation 3 and the metric values received from the encountered node B (e.g., P_(B,C)_recv) in the third part of updating the metric values stored in node A.
ノードAは、ノードAに格納されているメトリック値の更新の3番目の部分で、式3と、遭遇したノードBから受信したメトリック値（P_（B、C）_recvなど）を使用します。
2.1.2.1. Impact of Encounters between Nodes with Different Parameter Settings
2.1.2.1. パラメータ設定が異なるノード間の遭遇の影響
The various parameters used in the three equations described in Section 2.1.2 are set independently in each node, and it is therefore possible that encounters may take place between nodes that have been configured with different values of the parameters. This section considers whether this could be problematic for the operation of PRoPHET in that zone.
セクション2.1.2で説明する3つの方程式で使用されるさまざまなパラメーターは、各ノードで個別に設定されるため、パラメーターの異なる値で構成されたノード間で遭遇が発生する可能性があります。このセクションでは、これがそのゾーンでのPRoPHETの運用に問題があるかどうかを検討します。
It is desirable that all the nodes operating in a PRoPHET zone should use closely matched values of the parameters and that the parameters should be set to values that are appropriate for the operating zone. More details of how to select appropriate values are given in Section 3.3. Using closely matched values means that delivery predictabilities will evolve in the same way in each node, leading to consistent decision making about the bundles that should be exchanged during encounters.
PRoPHETゾーンで動作するすべてのノードは、パラメータの厳密に一致する値を使用する必要があり、パラメータは、動作ゾーンに適した値に設定する必要があります。適切な値を選択する方法の詳細については、セクション3.3を参照してください。厳密に一致する値を使用することは、配信の予測可能性が各ノードで同じように進化し、遭遇中に交換する必要のあるバンドルについて一貫した意思決定につながることを意味します。
Before going on to consider the impact of reasonable but different settings, it should be noted that malicious nodes can use inappropriate settings of the parameters to disrupt delivery of bundles in a PRoPHET zone as described in Section 6.
合理的ではあるが異なる設定の影響を検討する前に、セクション6で説明されているように、悪意のあるノードがパラメータの不適切な設定を使用して、PRoPHETゾーンでのバンドルの配信を妨害できることに注意する必要があります。
Firstly and importantly, use of different, but legitimate, settings in encountering nodes will not cause problems in the protocol itself. Apart from P_encounter_first, the other parameters control the rate of change of the metric values or limit the range of valid values that will be stored in a node. None of the calculations in a node will be invalidated or result in illegal values if the metric values received from another node were calculated using different parameters. Furthermore, the protocol is designed so that it is not possible to carry delivery predictabilities outside the permissible range of 0 to 1.
まず重要なのは、ノードに遭遇する際に異なるが正当な設定を使用しても、プロトコル自体に問題が発生しないことです。 P_encounter_first以外のパラメーターは、メトリック値の変化率を制御したり、ノードに格納される有効な値の範囲を制限したりします。別のノードから受信したメトリック値が異なるパラメーターを使用して計算された場合、ノード内の計算は無効にならず、無効な値にもなりません。さらに、プロトコルは、0から1の許容範囲外の配信予測可能性を伝送できないように設計されています。
A node MAY consider setting received values greater than (1 - delta) to (1 - delta) if this would simplify operations. However, there are some special situations where it may be appropriate for the delivery predictability for another node to be 1. For example, if a DTN using PRoPHET has multiple gateways to the continuously connected Internet, the delivery predictability seen from PRoPHET in one gateway for the other gateway nodes can be taken as 1 since they are permanently connected through the Internet. This would allow traffic to be forwarded into the DTN through the most advantageous gateway even if it initially arrives at another gateway.
操作が簡単になる場合、ノードは（1-デルタ）から（1-デルタ）より大きい受信値を設定することを検討できます（MAY）。ただし、別のノードの配信予測可能性が1であることが適切である特別な状況がいくつかあります。たとえば、PRoPHETを使用するDTNが継続的に接続されたインターネットへの複数のゲートウェイを持っている場合、1つのゲートウェイのPRoPHETから見た配信予測可能性他のゲートウェイノードはインターネット経由で永続的に接続されているため、1と見なすことができます。これにより、トラフィックが最初に別のゲートウェイに到着した場合でも、最も有利なゲートウェイを介してDTNにトラフィックを転送できます。
Simulation work indicates that the update calculations are quite stable in the face of changes to the rate parameters, so that minor discrepancies will not have a major impact on the performance of the protocol. The protocol is explicitly designed to deal with situations where there are random factors in the opportunistic nature of node encounters, and this randomness dominates over the discrepancies in the parameters.
シミュレーション作業は、更新の計算がレートパラメータの変更に直面して非常に安定していることを示しています。そのため、わずかな不一致がプロトコルのパフォーマンスに大きな影響を与えることはありません。このプロトコルは、ノードの遭遇の日和見的な性質にランダムな要因があり、このランダム性がパラメーターの不一致を支配する状況に対処するように明示的に設計されています。
More major discrepancies may lead to suboptimal behavior of the protocol, as certain paths might be more preferred or more deprecated inappropriately. However, since the protocol overall is epidemic in nature, this would not generally lead to non-delivery of bundles, as they would also be passed to other nodes and would still be delivered, though possibly not on the optimal path.
特定のパスがより優先されるか、不適切に非推奨になる可能性があるため、より大きな不一致が生じると、プロトコルの動作が最適化されない可能性があります。ただし、プロトコル全体が流行しているため、バンドルは他のノードにも渡されて配信されるため、通常はバンドルが配信されず、最適なパスではない可能性があります。
To give the delivery predictability a smoother rate of change, a node MAY apply one of the following methods:
配信の予測可能性をよりスムーズな変化率にするために、ノードは次のいずれかの方法を適用できます（MAY）。
1. Keep a list of NUM_P values for each destination instead of only a single value. (The recommended value is 4, which has been shown in simulations to give a good trade-off between smoothness and rate of response to changes.) The list is held in order of acquisition. When a delivery predictability is updated, the value at the "newest" position in the list is used as input to the equations in Section 2.1.2. The oldest value in the list is then discarded and the new value is written in the "newest" position of the list. When a delivery predictability value is needed (either for sending to a peering PRoPHET node, or for making a forwarding decision), the average of the values in the list is calculated, and that value is then used. If less than NUM_P values have been entered into the list, only the positions that have been filled should be used for the averaging.
1. 単一の値だけではなく、宛先ごとにNUM_P値のリストを保持します。 （推奨値は4です。これは、変化に対する滑らかさと応答速度の適切なトレードオフをシミュレーションで示したものです。）リストは取得順に保持されます。配信の予測可能性が更新されると、リストの「最新」の位置の値がセクション2.1.2の方程式への入力として使用されます。次に、リスト内の最も古い値が破棄され、新しい値がリストの「最新」の位置に書き込まれます。配信予測可能性の値が必要な場合（ピアPRoPHETノードへの送信、または転送の決定を行うため）、リスト内の値の平均が計算され、その値が使用されます。 NUM_P未満の値がリストに入力されている場合は、平均化に、埋められた位置のみを使用する必要があります。
2. In addition to keeping the delivery predictability as described in Section 2.1.2, a node MAY also keep an exponential weighted moving average (EWMA) of the delivery predictability. The EWMA is then used to make forwarding decisions and to report to peering nodes, but the value calculated according to Section 2.1.2 is still used as input to the calculations of new delivery predictabilities. The EWMA is calculated according to Equation 4, where 0 <= alpha <= 1 is the weight of the most current value.
2. セクション2.1.2で説明されている配信の予測可能性を維持することに加えて、ノードは配信の予測可能性の指数加重移動平均（EWMA）も維持できます（MAY）。次に、EWMAを使用して転送の決定を行い、ピアリングノードにレポートしますが、セクション2.1.2に従って計算された値は、新しい配信の予測可能性の計算への入力として引き続き使用されます。 EWMAは式4に従って計算されます。0<= alpha <= 1は最新の値の重みです。
P_ewma = P_ewma_old * (1 - alpha) + P * alpha (Eq. 4)
The appropriate choice of alpha may vary depending on application scenario circumstances. Unless prior knowledge of the scenario is available, it is suggested that alpha is set to 0.5.
アルファの適切な選択は、アプリケーションシナリオの状況によって異なります。シナリオの事前知識がない場合は、アルファを0.5に設定することをお勧めします。
To reduce the data to be transferred between two nodes, a node MAY treat delivery predictabilities smaller than P_first_threshold, where P_first_threshold is a small number, as if they were zero, and thus they do not need to be stored or included in the list sent during the Information Exchange Phase. If this optimization is used, care must be taken to select P_first_threshold to be smaller than delivery predictability values normally present in the network for destinations for which this node is a forwarder. It is possible that P_first_threshold could be calculated based on delivery predictability ranges and the amount they change historically, but this has not been investigated yet.
2つのノード間で転送されるデータを減らすために、ノードは、P_first_thresholdよりも小さい配信予測可能性を扱うことができます（P_first_thresholdは小さい数であるかのように、したがって、それらは格納または送信中に送信されるリストに含める必要はありません）情報交換フェーズ。この最適化を使用する場合、このノードがフォワーダーである宛先について、ネットワークに通常存在する配信予測可能性の値よりも小さくなるようにP_first_thresholdを選択するように注意する必要があります。 P_first_thresholdは、配信の予測可能性の範囲とそれらが過去に変化した量に基づいて計算される可能性がありますが、これはまだ調査されていません。
In traditional routing protocols, choosing where to forward a message is usually a simple task; the message is sent to the neighbor that has the path to the destination with the lowest cost (often the shortest path). Normally, the message is also sent to only a single node since the reliability of paths is relatively high. However, in the settings we envision here, things are radically different. The first possibility that must be considered when a bundle arrives at a node is that there might not be a path to the destination available, so the node has to buffer the bundle, and upon each encounter with another node, the decision must be made whether or not to transfer a particular bundle. Furthermore, having duplicates of messages (on different nodes, as the bundle offer/request mechanism described in Section 4.3.5 ensures that a node does not receive a bundle it already carries) may also be sensible, as forwarding a bundle to multiple nodes can increase the delivery probability of that bundle.
従来のルーティングプロトコルでは、通常、メッセージの転送先を選択するのは簡単な作業です。メッセージは、宛先へのパスが最小のコスト（多くの場合、最短パス）を持つネイバーに送信されます。パスの信頼性は比較的高いため、通常、メッセージは単一のノードにも送信されます。ただし、ここで想定している設定では、状況は根本的に異なります。バンドルがノードに到着したときに考慮しなければならない最初の可能性は、利用可能な宛先へのパスがない可能性があるため、ノードはバンドルをバッファリングする必要があり、別のノードと遭遇するたびに、特定のバンドルを転送するかどうか。さらに、複数のノードにバンドルを転送できるため、（セクション4.3.5で説明されているバンドルのオファー/リクエストメカニズムがノードがすでに持っているバンドルを受信しないことを保証するため、異なるノード上に）メッセージの複製があることも賢明かもしれません。そのバンドルの配達確率を高めます。
Unfortunately, these decisions are not trivial to make. In some cases, it might be sensible to select a fixed threshold and only give a bundle to nodes that have a delivery predictability over that threshold for the destination of the bundle. On the other hand, when encountering a node with a low delivery predictability, it is not certain that a node with a higher metric will be encountered within a reasonable time. Thus, there can also be situations where we might want to be less strict in deciding who to give bundles to. Furthermore, there is the problem of deciding how many nodes to give a certain bundle to. Distributing a bundle to a large number of nodes will of course increase the probability of delivering that particular bundle to its destination, but this comes at the cost of consuming more system resources for bundle storage and possibly reducing the probability of other bundles being delivered. On the other hand, giving a bundle to only a few nodes (maybe even just a single node) will use less system resources, but the probability of delivering a bundle is lower, and the delay incurred is high.
残念ながら、これらの決定は簡単なことではありません。場合によっては、固定のしきい値を選択して、バンドルの宛先のそのしきい値を超える配信予測が可能なノードにのみバンドルを与えることが賢明な場合があります。一方、配信の予測可能性が低いノードに遭遇した場合、より高いメトリックを持つノードが妥当な時間内に遭遇することは確実ではありません。したがって、バンドルを誰に渡すかを決定する際に、それほど厳密にしたくない状況もあり得ます。さらに、特定のバンドルを割り当てるノード数を決定するという問題があります。バンドルを多数のノードに配信すると、当然、その特定のバンドルを宛先に配信する可能性が高くなりますが、これにより、バンドルストレージに多くのシステムリソースが消費され、他のバンドルが配信される可能性が低くなる可能性があります。一方、バンドルを少数のノードだけに（おそらく単一のノードにさえ）与えると、システムリソースの使用量は少なくなりますが、バンドルを配信する確率は低くなり、発生する遅延は高くなります。
When resources are constrained, nodes may suffer from storage shortage, and may have to drop bundles before they have been delivered to their destinations. They may also wish to consider the length of bundles being offered by an encountered node before accepting transfer of the bundle in order to avoid the need to drop the new bundle immediately or to ensure that there is adequate space to hold the bundle offered, which might require other bundles to be dropped. As with the decision as to whether or not to forward a bundle, deciding which bundles to accept and/or drop to still maintain good performance might require different policies in different scenarios.
リソースが制限されている場合、ノードはストレージ不足に陥る可能性があり、宛先に配信される前にバンドルをドロップする必要がある場合があります。また、新しいバンドルをすぐに削除する必要がないようにするため、または提供されたバンドルを保持するための十分なスペースがあることを保証するために、バンドルの転送を受け入れる前に、遭遇したノードによって提供されているバンドルの長さを検討することもできます。他のバンドルを削除する必要があります。バンドルを転送するかどうかの決定と同様に、良好なパフォーマンスを維持するために受け入れるまたはドロップするバンドルを決定するには、シナリオごとに異なるポリシーが必要になる場合があります。
Nodes MAY define their own forwarding strategies and queueing policies that take into account the special conditions applicable to the nodes, and local resource constraints. Some default strategies and policies that should be suitable for most normal operations are defined in Section 3.6 and Section 3.7.
ノードは、ノードに適用可能な特別な条件とローカルリソースの制約を考慮に入れて、独自の転送戦略とキューイングポリシーを定義する場合があります。ほとんどの通常の操作に適したデフォルトの戦略とポリシーのいくつかは、セクション3.6とセクション3.7で定義されています。
The bundle protocol [RFC5050] introduces the concept of a "bundle protocol agent" that manages the interface between applications and the "convergence layers" that provide the transport of bundles between nodes during communication opportunities. This specification extends the bundle protocol agent with a routing agent that controls the actions of the bundle protocol agent during an (opportunistic) communications opportunity.
バンドルプロトコル[RFC5050]は、アプリケーション間のインターフェイスを管理する「バンドルプロトコルエージェント」の概念と、通信機会中にノード間のバンドルのトランスポートを提供する「コンバージェンスレイヤー」を導入します。この仕様は、（日和見的）通信機会中にバンドルプロトコルエージェントのアクションを制御するルーティングエージェントでバンドルプロトコルエージェントを拡張します。
This specification defines the details of the PRoPHET routing agent, but the interface defines a more general interface that is also applicable to alternative routing protocols.
この仕様はPRoPHETルーティングエージェントの詳細を定義しますが、インターフェースは、代替ルーティングプロトコルにも適用可能なより一般的なインターフェースを定義します。
To enable the PRoPHET routing agent to operate properly, it must be aware of the bundles stored at the node, and it must also be able to tell the bundle protocol agent of that node to send a bundle to a peering node. Therefore, the bundle protocol agent needs to provide the following interface/functionality to the routing agent:
PRoPHETルーティングエージェントが正しく動作するには、ノードに格納されているバンドルを認識している必要があり、また、そのノードのバンドルプロトコルエージェントに、バンドルをピアリングノードに送信するように指示できる必要があります。したがって、バンドルプロトコルエージェントは、ルーティングエージェントに次のインターフェイス/機能を提供する必要があります。
Get Bundle List Returns a list of the stored bundles and their attributes to the routing agent.
Get Bundle List格納されているバンドルとその属性のリストをルーティングエージェントに返します。
Send Bundle Makes the bundle protocol agent send a specified bundle.
バンドルの送信バンドルプロトコルエージェントに指定されたバンドルを送信させます。
Accept Bundle Gives the bundle protocol agent a new bundle to store.
Accept Bundleバンドルプロトコルエージェントに、保存する新しいバンドルを提供します。
Bundle Delivered Tells the bundle protocol agent that a bundle was delivered to its destination.
Bundle Deliveredバンドルが宛先に配信されたことをバンドルプロトコルエージェントに通知します。
Drop Bundle Advice Advises the bundle protocol agent that a specified bundle should not be offered for forwarding in future and may be dropped by the bundle protocol agent if appropriate.
バンドルアドバイスのドロップ指定されたバンドルは将来転送用に提供されるべきではなく、適切な場合はバンドルプロトコルエージェントによってドロップされる可能性があることをバンドルプロトコルエージェントにアドバイスします。
Route Import Can be used by a gateway node in a PRoPHET zone to import reachability information about endpoint IDs (EIDs) that are external to the PRoPHET zone. Translation functions dependent on the external routing protocol will be used to set the appropriate delivery predictabilities for imported destinations as described in Section 2.3.
ルートインポートPRoPHETゾーンのゲートウェイノードがPRoPHETゾーンの外部にあるエンドポイントID（EID）に関する到達可能性情報をインポートするために使用できます。セクション2.3で説明されているように、外部ルーティングプロトコルに依存する変換関数を使用して、インポートされた宛先に適切な配信予測可能性を設定します。
Route Export Can be used by a gateway node in a PRoPHET zone to export reachability information (destination EIDs and corresponding delivery predictabilities) for use by routing protocols in other parts of the DTN.
ルートエクスポートPRoPHETゾーンのゲートウェイノードで使用して、DTNの他の部分のルーティングプロトコルで使用するための到達可能性情報（宛先EIDおよび対応する配信予測可能性）をエクスポートできます。
Implementation Note: Depending on the distribution of functions in a complete bundle protocol agent supporting PRoPHET, reception and delivery of bundles may not be carried out directly by the PRoPHET module. In this case, PRoPHET can inform the bundle protocol agent about bundles that have been requested from communicating nodes. Then, the Accept Bundle and Bundle Delivered functions can be implemented as notifications of the PRoPHET module when the relevant bundles arrive at the node or are delivered to local applications.
実装上の注意：PRoPHETをサポートする完全なバンドルプロトコルエージェントでの機能の分散によっては、バンドルの受信と配信がPRoPHETモジュールによって直接実行されない場合があります。この場合、PRoPHETは、通信ノードから要求されたバンドルについてバンドルプロトコルエージェントに通知できます。次に、関連するバンドルがノードに到着したとき、またはローカルアプリケーションに配信されたときに、バンドルの受け入れおよび配信されたバンドル機能をPRoPHETモジュールの通知として実装できます。
PRoPHET is designed to handle routing primarily within a "PRoPHET zone", i.e., a set of nodes that all implement the PRoPHET routing scheme. However, since we recognize that a PRoPHET routing zone is unlikely to encompass an entire DTN, there may be nodes within the zone that act as gateways to other nodes that are the destinations for bundles generated within the zone or that insert bundles into the zone.
PRoPHETは、主に「PRoPHETゾーン」内でルーティングを処理するように設計されています。つまり、すべてがPRoPHETルーティングスキームを実装するノードのセットです。ただし、PRoPHETルーティングゾーンがDTN全体を含む可能性は低いと認識しているため、ゾーン内で生成されたバンドルの宛先である、またはゾーンにバンドルを挿入する他のノードへのゲートウェイとして機能するノードがゾーン内にある可能性があります。
PRoPHET MAY elect to export and import routes across a bundle protocol agent interface. The delivery predictability to use for routes that are imported depends on the routing protocol used to manage those routes. If a translation function between the external routing protocol and PRoPHET exists, it SHOULD be used to set the delivery predictability. If no such translation function exists, the delivery predictability SHOULD be set to 1. For those routes that are exported, the current delivery predictability will be exported with the route.
PRoPHETは、バンドルプロトコルエージェントインターフェイス全体でルートをエクスポートおよびインポートすることを選択できます。インポートされるルートに使用する配信の予測可能性は、それらのルートの管理に使用されるルーティングプロトコルによって異なります。外部ルーティングプロトコルとPRoPHETの間に変換機能が存在する場合、それを使用して配信の予測可能性を設定する必要があります（SHOULD）。そのような変換機能が存在しない場合は、配信の予測可能性を1に設定する必要があります（SHOULD）。エクスポートされるルートでは、現在の配信の予測可能性がルートとともにエクスポートされます。
PRoPHET can be run on a large number of underlying networking technologies. To accommodate its operation on all kinds of lower layers, it requires the lower layers to provide the following functionality and interfaces.
PRoPHETは、多数の基盤となるネットワークテクノロジで実行できます。すべての種類の下位層での操作に対応するには、下位層で次の機能とインターフェイスを提供する必要があります。
Neighbor discovery and maintenance A PRoPHET node needs to know the identity of its neighbors and when new neighbors appear and old neighbors disappear. Some wireless networking technologies might already contain mechanisms for detecting neighbors and maintaining this state. To avoid redundancies and inefficiencies, neighbor discovery is thus not included as a part of PRoPHET, but PRoPHET relies on such a mechanism in lower layers. The lower layers MUST provide the two functions listed below. If the underlying networking technology does not support such services, a simple neighbor discovery scheme using local broadcasts of beacon messages could be run in between PRoPHET and the underlying layer. An example of a simple neighbor discovery mechanism that could be used is in Appendix B.
ネイバーの検出とメンテナンスPRoPHETノードは、ネイバーのIDを知っている必要があり、新しいネイバーが表示され、古いネイバーが消えるタイミングを知る必要があります。一部のワイヤレスネットワーキングテクノロジーには、近隣を検出してこの状態を維持するためのメカニズムがすでに含まれている場合があります。したがって、冗長性と非効率性を回避するために、近隣探索はPRoPHETの一部として含まれていませんが、PRoPHETは下位層でこのようなメカニズムに依存しています。下位層は、以下に示す2つの機能を提供する必要があります。基盤となるネットワーキングテクノロジーがこのようなサービスをサポートしていない場合、ビーコンメッセージのローカルブロードキャストを使用する単純なネイバー探索スキームをPRoPHETと基盤となるレイヤーの間で実行できます。使用できる単純なネイバー探索メカニズムの例は、付録Bにあります。
New Neighbor Signals to the PRoPHET agent that a new node has become a neighbor. A neighbor is defined here as another node that is currently within communication range of the wireless networking technology in use. The PRoPHET agent should now start the Hello procedure as described in Section 5.2.
新しい隣接ノードは、新しいノードが隣接ノードになったことをPRoPHETエージェントに通知します。ここでは、ネイバーは、現在使用中のワイヤレスネットワーキングテクノロジーの通信範囲内にある別のノードとして定義されています。 PRoPHETエージェントは、セクション5.2で説明されているように、Helloプロシージャを開始します。
Neighbor Gone Signals to the PRoPHET agent that one of its neighbors has left.
ネイバーゴーンネイバーの1つが残したことをPRoPHETエージェントに通知します。
Local Address An address used by the underlying communication layer (e.g., an IP or Media Access Control (MAC) address) that identifies the sender address of the current message. This address must be unique among the nodes that can currently communicate and is only used in conjunction with an Instance Number to identify a communicating pair of nodes as described in Section 4.1. This address and its format is dependent on the communication layer that is being used by the PRoPHET layer.
ローカルアドレス現在のメッセージの送信者アドレスを識別する、基盤となる通信層（IPアドレスやメディアアクセス制御（MAC）アドレスなど）によって使用されるアドレス。このアドレスは、現在通信できるノード間で一意である必要があり、セクション4.1で説明されているように、通信するノードのペアを識別するためにインスタンス番号と組み合わせてのみ使用されます。このアドレスとそのフォーマットは、PRoPHETレイヤーで使用されている通信レイヤーに依存します。
The PRoPHET protocol involves two principal phases:
PRoPHETプロトコルには2つの主要な段階があります。
o becoming aware of new neighbors that implement the protocol and establishing a point-to-point connection between each pair of encountering nodes, and
o プロトコルを実装する新しいネイバーを認識し、遭遇するノードの各ペア間にポイントツーポイント接続を確立します。
o using the connection for information exchange needed to establish PRoPHET routing and to exchange bundles.
o PRoPHETルーティングの確立とバンドルの交換に必要な情報交換のための接続の使用。
Since the operation of the protocol is dependent on the encounters of nodes running PRoPHET, the nodes must be able to detect when a new neighbor is present. The protocol may be run on several different networking technologies, and as some of them might already have methods available for detecting neighbors, PRoPHET does not include a mechanism for neighbor discovery. Instead, it requires the underlying layer to provide a mechanism to notify the protocol of when neighbors appear and disappear as described in Section 2.4.
プロトコルの動作はPRoPHETを実行しているノードの遭遇に依存しているため、ノードは新しいネイバーが存在することを検出できる必要があります。プロトコルはいくつかの異なるネットワーキング技術で実行でき、それらのいくつかはすでに近隣を検出するために利用可能な方法を持っているかもしれないので、PRoPHETは近隣発見のためのメカニズムを含みません。代わりに、2.4で説明されているように、ネイバーがいつ現れたり消えたりするかをプロトコルに通知するメカニズムを提供するために、基礎となるレイヤーが必要です。
When a new neighbor has been detected, the protocol starts to set up a link with that node through the Hello message exchange as described in Section 5.2. The Hello message exchange allows for negotiation of capabilities between neighbors. At present, the only capability is a request that the offering node should or should not include bundle payload lengths with all offered bundles rather than just for fragments. Once the link has been set up, the protocol may continue to the Information Exchange Phase (see Section 3.2). Once this has been completed, the nodes will normally recalculate the delivery predictabilities using the equations and mechanisms described in Sections 2.1.2 and 2.1.3.
新しいネイバーが検出されると、プロトコルは、セクション5.2で説明されているように、Helloメッセージ交換を通じてそのノードとのリンクの設定を開始します。 Helloメッセージ交換により、ネイバー間の機能のネゴシエーションが可能になります。現在、唯一の機能は、提供ノードがフラグメントだけではなく、提供されたすべてのバンドルのバンドルペイロード長を含めるかどうかを指定するリクエストです。リンクが設定されると、プロトコルは情報交換フェーズ（セクション3.2を参照）に進みます。これが完了すると、ノードは通常、セクション2.1.2および2.1.3で説明されている方程式とメカニズムを使用して、配信の予測可能性を再計算します。
As described in Section 2.1.2, there are some circumstances in which a single logical encounter may result in several actual communication opportunities. To avoid the delivery predictability of the encountered node being increased excessively under these circumstances, the value of P_encounter is made dependent on the interval time between delivery predictability updates when the interval is less than the typical interval between encounters, but it is a constant for longer intervals.
セクション2.1.2で説明されているように、単一の論理的な出会いがいくつかの実際の通信機会をもたらす場合があるいくつかの状況があります。遭遇したノードの配信予測可能性がこれらの状況下で過度に増加するのを回避するために、P_encounterの値は、配信の予測可能性更新間のインターバルに依存します。間隔。
In order to make use of this time dependence, PRoPHET maintains a list of recently encountered nodes identified by the Endpoint Identifier (EID) that the node uses to identify the communication session and containing the start time of the last communication session with that node. The size of this list is controlled because nodes that are not in contact and that started their last connection more than a time I_typ before the present can be dropped from the list. It also maintains a record of the time at which the decay function (Equation 2) was last applied to the delivery predictabilities in the node.
この時間依存を利用するために、PRoPHETは、ノードが通信セッションを識別するために使用し、そのノードとの最後の通信セッションの開始時刻を含む、エンドポイント識別子（EID）によって識別される最近遭遇したノードのリストを維持します。このリストのサイズが制御されるのは、現在接続されていないノードが最後の接続を開始してからI_typが経過する前に、現在のノードをリストから削除できるためです。また、減衰関数（式2）がノードの配信予測に最後に適用された時刻の記録も保持します。
The Information Exchange Phase involves two parts:
情報交換フェーズには2つの部分があります。
o establishing the Router Information Base (RIB Exchange Sub-Phase), and
o ルーター情報ベース（RIB交換サブフェーズ）の確立、および
o exchanging bundles using this information (Bundle Passing Sub-Phase).
o この情報を使用してバンドルを交換する（Bundle Passing Sub-Phase）。
Four types of information are exchanged during this process:
このプロセスでは、4種類の情報が交換されます。
o Routing Information Base Dictionary (RIB Dictionary or RIBD),
o ルーティング情報ベース辞書（RIB辞書またはRIBD）、
o Routing Information Base (RIB),
o ルーティング情報ベース（RIB）、
o Bundle Offers, and
o バンドルオファー、および
o Bundle Responses.
o バンドル応答。
During a communication opportunity, several sets of each type of information may be transferred in each direction as explained in the rest of this section. Each set can be transferred in one or more messages. When (and only when) using a connection-oriented reliable transport protocol such as TCP as envisaged in this document, a set can be partitioned across messages by the software layer above the PRoPHET protocol engine.
このセクションの残りの部分で説明するように、通信機会中に、各タイプの情報のいくつかのセットが各方向に転送される場合があります。各セットは1つ以上のメッセージで転送できます。このドキュメントで想定されているように、TCPなどの接続指向の信頼性の高いトランスポートプロトコルを使用する場合（およびその場合のみ）、セットは、PRoPHETプロトコルエンジンの上のソフトウェア層によってメッセージ間で分割できます。
In this case, the last message in a set is flagged in the protocol. This allows the higher-level software to minimize the buffer memory requirements by avoiding the need to build very large messages in one go and allows the message size to be controlled outside of PRoPHET. However, this scheme is only usable if the transport protocol provides reliable, in-order delivery of messages, as the messages are not explicitly sequence numbered and the overall size of the set is not passed explicitly.
この場合、セット内の最後のメッセージにはプロトコルでフラグが立てられます。これにより、高レベルのソフトウェアで非常に大きなメッセージを一度に作成する必要がなくなるため、バッファーメモリ要件を最小限に抑え、メッセージサイズをPRoPHETの外部で制御できるようになります。ただし、メッセージが明示的にシーケンス番号付けされておらず、セット全体のサイズが明示的に渡されないため、このスキームは、トランスポートプロトコルが信頼性の高い順序どおりのメッセージ配信を提供する場合にのみ使用できます。
The specification of PRoPHET also provides a submessage mechanism and retransmission that allows large messages specified by the higher level to be transmitted in smaller chunks. This mechanism was originally provided to allow PRoPHET to operate over unreliable transport protocols such as UDP, but can also be used with reliable transports if the higher-level software does not want to handle message fragmentation. However, the sequencing and length adds overhead that is redundant if the transport protocol already provides reliable, in-order delivery.
PRoPHETの仕様は、より高いレベルで指定された大きなメッセージを小さなチャンクで送信できるようにするサブメッセージメカニズムと再送信も提供します。このメカニズムは元々、UDPなどの信頼性の低いトランスポートプロトコルでPRoPHETが動作できるようにするために提供されましたが、高レベルのソフトウェアがメッセージの断片化を処理したくない場合は、信頼性の高いトランスポートでも使用できます。ただし、シーケンスと長さによってオーバーヘッドが追加されますが、トランスポートプロトコルがすでに信頼性の高い順序どおりの配信を提供している場合は冗長です。
The first step in the Information Exchange Phase is for the protocol to send one or more messages containing a RIB Dictionary TLV (Type-Length-Value message component) to the node with which it is peering. This set of messages contain a dictionary of the Endpoint Identifiers (EIDs) of the nodes that will be listed in the Routing Information Base (RIB); see Section 3.2.1 for more information about this dictionary. After this, one or more messages containing a Routing Information Base TLV are sent. This TLV contains a list of the EIDs that the node has knowledge of, and the corresponding delivery predictabilities for those nodes, together with flags describing the capabilities of the sending node. Upon reception of a complete set of these messages, the peer node updates its delivery predictability table according to the equations in Section 2.1.2. The peer node then applies its forwarding strategy (see Section 2.1.4) to determine which of its stored bundles it wishes to offer the node that sent the RIB; that node will then be the receiver for any bundles to be transferred.
情報交換フェーズの最初のステップは、プロトコルがRIBディクショナリTLV（Type-Length-Valueメッセージコンポーネント）を含む1つ以上のメッセージを、ピアリングしているノードに送信することです。このメッセージのセットには、ルーティング情報ベース（RIB）にリストされるノードのエンドポイント識別子（EID）の辞書が含まれています。この辞書の詳細については、セクション3.2.1を参照してください。この後、ルーティング情報ベースTLVを含む1つ以上のメッセージが送信されます。このTLVには、ノードが認識しているEIDのリスト、およびそれらのノードの対応する配信予測可能性が、送信ノードの機能を説明するフラグとともに含まれています。これらのメッセージの完全なセットを受信すると、ピアノードは、セクション2.1.2の方程式に従って、配信予測テーブルを更新します。次に、ピアノードは、その転送戦略（セクション2.1.4を参照）を適用して、RIBを送信したノードに提供する格納されたバンドルを決定します。そのノードは、転送されるバンドルのレシーバーになります。
After making this decision, one or more Bundle Offer TLVs are prepared, listing the bundle identifiers and their destinations for all bundles the peer node wishes to offer to the receiver node that sent the RIB. As described in [RFC5050], a bundle identifier consists of up to five component parts. For a complete bundle, the identifier consists of
この決定を行った後、1つ以上のバンドルオファーTLVが準備され、RIBを送信したレシーバーノードにピアノードが提供したいすべてのバンドルのバンドル識別子とその宛先がリストされます。 [RFC5050]で説明されているように、バンドル識別子は最大5つのコンポーネントパーツで構成されます。完全なバンドルの場合、識別子は以下で構成されます
o source EID,
o あなたの誕生日の写真、
o creation timestamp - time of creation, and
o 作成タイムスタンプ-作成時刻、および
o creation timestamp - sequence number.
o 作成タイムスタンプ-シーケンス番号。
Additionally, for a bundle fragment, the identifier also contains
さらに、バンドルフラグメントの場合、識別子には
o offset within the payload at which the fragment payload data starts, and
o フラグメントペイロードデータが開始するペイロード内のオフセット
o length of the fragment payload data.
o フラグメントペイロードデータの長さ。
If any of the Bundle Offer TLVs lists a bundle for which the source or destination EID was not included in the previous set of RIBD information sent, one or more new RIBD TLVs are sent next with an incremental update of the dictionary. When the receiver node has a dictionary with all necessary EIDs, the Bundle Offer TLVs are sent to it. The Bundle Offer TLVs also contain a list of PRoPHET ACKs (see Section 3.5). If requested by the receiver node during the Hello phase, the Bundle Offer TLV will also specify the payload length for all bundles rather than for just fragments. This information can be used by the receiving node to assist with the selection of bundles to be accepted from the offered list, especially if the available bundle storage capacity is limited.
バンドルオファーTLVのいずれかに、送信されたRIBD情報の以前のセットに送信元または送信先EIDが含まれていないバンドルがリストされている場合、1つ以上の新しいRIBD TLVが次にディクショナリの増分更新とともに送信されます。レシーバーノードに必要なすべてのEIDを持つディクショナリがある場合、バンドルオファーTLVがそれに送信されます。バンドルオファーTLVには、PRoPHET ACKのリストも含まれています（セクション3.5を参照）。 Helloフェーズ中にレシーバーノードによって要求された場合、バンドルオファーTLVはフラグメントだけでなく、すべてのバンドルのペイロード長も指定します。受信ノードはこの情報を使用して、提供されたリストから受け入れるバンドルの選択を支援できます。特に、利用可能なバンドルのストレージ容量が限られている場合に役立ちます。
The receiving node then examines the list of offered bundles and selects bundles that it will accept according to its own policies, considering the bundles already present in the node and the current availability of resources in the node. The list is sorted according to the priority that the policies apply to the selected bundles, with the highest priority bundle first in the list. The offering node will forward the selected bundles in this order. The prioritized list is sent to the offering node in one or more Bundle Response TLVs using the same EID dictionary as was used for the Bundle Offer TLV.
次に、受信ノードは提供されたバンドルのリストを調べ、ノードにすでに存在するバンドルとノード内のリソースの現在の可用性を考慮して、独自のポリシーに従って受け入れるバンドルを選択します。リストは、選択したバンドルにポリシーが適用される優先順位に従ってソートされ、最も優先順位の高いバンドルがリストの最初になります。オファリングノードは、選択されたバンドルをこの順序で転送します。優先リストは、バンドルオファーTLVに使用されたのと同じEIDディクショナリを使用して、1つ以上のバンドルレスポンスTLVでオファリングノードに送信されます。
When a new bundle arrives at a node, the node MAY inspect its list of available neighbors, and if one of them is a candidate to forward the bundle, a new Bundle Offer TLV MAY be sent to that node. If two nodes remain connected over a longer period of time, the Information Exchange Phase will be periodically re-initiated to allow new delivery predictability information to be spread through the network and new bundle exchanges to take place.
新しいバンドルがノードに到着すると、ノードは使用可能なネイバーのリストを検査する場合があり、それらの1つがバンドルを転送する候補である場合、新しいバンドルオファーTLVがそのノードに送信される場合があります。 2つのノードが長期間接続されたままの場合、情報交換フェーズが定期的に再開され、新しい配信予測情報がネットワーク全体に広がり、新しいバンドル交換が行われます。
The Information Exchange Phase of the protocol is described in more detail in Section 5.3.
プロトコルの情報交換フェーズについては、セクション5.3で詳しく説明します。
To reduce the overhead of the protocol, the Routing Information Base and Bundle Offer/Response TLVs utilize an EID dictionary. This dictionary maps variable-length EIDs (as defined in [RFC4838]), which may potentially be quite long, to shorter numerical identifiers, coded as Self-Delimiting Numeric Values (SDNVs -- see Section 4.1. of RFC 5050 [RFC5050]), which are used in place of the EIDs in subsequent TLVs.
プロトコルのオーバーヘッドを削減するために、ルーティング情報ベースとバンドルオファー/レスポンスTLVはEIDディクショナリを利用します。この辞書は、（[RFC4838]で定義されている）可変長のEIDをマッピングします。これは、かなり長い可能性がありますが、Self-Delimiting Numeric Value（SDNVs-RFC 5050 [RFC5050]のセクション4.1を参照）としてコード化された短い数値識別子にマッピングされます。 、後続のTLVでEIDの代わりに使用されます。
This dictionary is a shared resource between the two peering nodes. Each can add to the dictionary by sending a RIB Dictionary TLV to its peer. To allow either node to add to the dictionary at any time, the identifiers used by each node are taken from disjoint sets: identifiers originated by the node that started the Hello procedure have the least significant bit set to 0 (i.e., are even numbers) whereas those originated by the other peer have the least significant bit set to 1 (i.e., are odd numbers). This means that the dictionary can be expanded by either node at any point in the Information Exchange Phase and the new identifiers can then be used in subsequent TLVs until the dictionary is re-initialized.
このディクショナリは、2つのピアリングノード間の共有リソースです。それぞれがRIBディクショナリTLVをピアに送信することにより、ディクショナリに追加できます。いずれかのノードがいつでもディクショナリに追加できるようにするために、各ノードで使用される識別子は互いに素なセットから取得されます。Helloプロシージャを開始したノードが発信した識別子は、最下位ビットが0に設定されています（つまり、偶数です）。一方、他のピアから発信されたものは、最下位ビットが1に設定されています（つまり、奇数です）。つまり、情報交換フェーズの任意の時点でいずれかのノードによってディクショナリを拡張でき、ディクショナリが再初期化されるまで、新しい識別子を後続のTLVで使用できます。
The dictionary that is established only persists through a single encounter with a node (i.e., while the same link set up by the Hello procedure, with the same instance numbers, remains open).
確立されたディクショナリは、ノードとの1回の遭遇を通じてのみ存続します（つまり、Helloプロシージャによってセットアップされた同じリンクが同じインスタンス番号で開いたままです）。
Having more then one identifier for the same EID does not cause any problems. This means that it is possible for the peers to create their dictionary entries independently if required by an implementation, but this may be inefficient as a dictionary entry for an EID might be sent in both directions between the peers. Implementers can choose to inspect entries sent by the node that started the Hello procedure and thereby eliminate any duplicates before sending the dictionary entries from the other peer. Whether postponing sending the other peer's entries is more efficient depends on the nature of the physical link technology and the transport protocol used. With a genuinely full-duplex link, it may be faster to accept possible duplication and send dictionary entries concurrently in both directions. If the link is effectively half-duplex (e.g., Wi-Fi), then it will generally be more efficient to wait and eliminate duplicates.
同じEIDに複数の識別子があっても問題は発生しません。つまり、実装で必要な場合、ピアがディクショナリエントリを個別に作成することは可能ですが、EIDのディクショナリエントリがピア間で双方向に送信される可能性があるため、効率が悪い場合があります。実装者は、Helloプロシージャを開始したノードによって送信されたエントリを検査し、他のピアからディクショナリエントリを送信する前に重複を排除することを選択できます。他のピアのエントリの送信を延期することがより効率的であるかどうかは、物理リンクテクノロジの性質と使用されるトランスポートプロトコルによって異なります。完全な全二重リンクを使用すると、重複の可能性を受け入れて、双方向で同時に辞書エントリを送信する方が高速になる場合があります。リンクが実質的に半二重（Wi-Fiなど）である場合、待機して重複を排除する方が一般に効率的です。
If a node receives a RIB Dictionary TLV containing an identifier that is already in use, the node MUST confirm that the EID referred to is identical to the EID in the existing entry. Otherwise, the node must send an error response to the message with the TLV containing the error and ignore the TLV containing the error. If a node receives a RIB, Bundle Offer, or Bundle Response TLV that uses an identifier that is not in its dictionary, the node MUST send an error response and ignore the TLV containing the error.
ノードがすでに使用中の識別子を含むRIBディクショナリTLVを受信した場合、ノードは、参照されるEIDが既存のエントリのEIDと同一であることを確認する必要があります。それ以外の場合、ノードはエラーを含むTLVを含むメッセージにエラー応答を送信し、エラーを含むTLVを無視する必要があります。ノードがディクショナリにない識別子を使用するRIB、バンドルオファー、またはバンドルレスポンスTLVを受信した場合、ノードはエラーレスポンスを送信し、エラーを含むTLVを無視する必要があります。
From time to time, a mobile node may, for example, be in wireless range of more than one other mobile node. The PRoPHET neighbor awareness protocol will establish multiple simultaneous contacts with these nodes and commence information exchanges with each of them.
時々、モバイルノードは、例えば、複数の他のモバイルノードの無線範囲内にあり得る。 PRoPHET近隣認識プロトコルは、これらのノードとの複数の同時接続を確立し、各ノードとの情報交換を開始します。
When updating the delivery predictabilities as described in Section 2.1.2 using the values passed from each of the contacts in turn, some special considerations apply when multiple contacts are in progress: SC1 When aging the delivery predictabilities according to Equation 2, the value of K to be used in each set of calculations is always the amount of time since the last aging was done. For example, if node Z makes contact with node A and then with node B, the value of K used when the delivery predictabilities are aged in node Z for the contact with node B will be the time since the delivery predictabilities were aged for the contact with node A.
各連絡先から順番に渡された値を使用してセクション2.1.2で説明されている配信予測可能性を更新するとき、複数の連絡先が進行中の場合、いくつかの特別な考慮事項が適用されます。各計算セットで使用されるのは、常に最後のエージングが行われてからの時間です。たとえば、ノードZがノードAと接触し、次にノードBと接触する場合、ノードBとの接触に対してノードZで配信予測可能性が古くなるときに使用されるKの値は、連絡先の配信予測可能性が古くなってからの時間になります。ノードAで。
SC2 When a new contact starts, the value of P_encounter used when applying Equation 1 for the newly contacted node is always selected according to the time since the last encounter with that node. Thus, the application of Equation 1 to update P_(Z,A) when the contact of nodes Z and A starts (in the aging example just given) and the updating of P_(Z,B) when the contact of nodes Z and B starts will use the appropriate value of P_encounter according to how long it is since node Z previously encountered node A and node B, respectively.
SC2新しい接触が始まると、新しく接触したノードに式1を適用するときに使用されるP_encounterの値は、そのノードとの最後の遭遇以降の時間に従って常に選択されます。したがって、ノードZとAの接触が開始したときにP_（Z、A）を更新するための式1の適用（上記のエージングの例）と、ノードZとBの接触が開始したときのP_（Z、B）の更新startsは、ノードZが以前にノードAおよびノードBにそれぞれ遭遇してからの時間に応じて、P_encounterの適切な値を使用します。
SC3 If, as with the contact between nodes Z and B, there is another active contact in progress, such as with node A when the contact with node B starts, Equation 1 should *also* be applied to P_(z,x) for all the nodes "x" that have ongoing contacts with node Z (i.e., node A in the example given). However, the value of P_encounter used will be selected according to the time since the previous update of the delivery predictabilities as a result of information received from any other node. In the example given here, P_(Z,A) would also have Equation 1 applied when the delivery predictabilities are received from node B, but the value of P_encounter used would be selected according to the time since the updates done when the encounter between nodes Z and A started rather than the time since the previous encounter between nodes A and Z.
SC3ノードZとBの間の接触と同様に、ノードBとの接触が開始したときにノードAなどの別のアクティブな接触が進行中の場合、式1はP_（z、x）にも*ノードZ（つまり、指定された例ではノードA）と継続的に接続しているすべてのノード "x"。ただし、使用されるP_encounterの値は、他のノードから受信した情報の結果として、配信予測可能性が前回更新されてからの時間に応じて選択されます。ここに示した例では、ノードBから配信予測可能性を受け取ったときにP_（Z、A）にも式1が適用されますが、使用されるP_encounterの値は、ノード間の遭遇時に更新が行われてからの時間に従って選択されますZとAは、ノードAとZの間の前回の遭遇以降の時間ではなく開始しました。
If these simultaneous contacts persist for some time, then, as described in Section 3.2, the Information Exchange Phase will be periodically rerun for each contact according to the configured timer interval. When the delivery predictability values are recalculated during each rerun, Equation 1 will be applied as in special consideration SC3 above, but it will be applied to the delivery predictability for each active contact using the P_encounter value selected according to the time since the last set of updates were performed on the delivery predictabilities, irrespective of which nodes triggered either the previous or current updates. This means that, in the example discussed here, P_(Z,A) and P_(Z,B) will be updated using the same value of P_encounter whether node A or node B initiated the update while the three nodes remain connected.
これらの同時コンタクトがしばらく続く場合、セクション3.2で説明されているように、情報交換フェーズは、構成されたタイマー間隔に従って各コンタクトに対して定期的に再実行されます。配信予測可能性の値が各再実行中に再計算されると、上記の特別な考慮事項SC3のように式1が適用されますが、最後のセット以降の時間に従って選択されたP_encounter値を使用して、アクティブな連絡先ごとの配信予測可能性に適用されます以前または現在の更新をトリガーしたノードに関係なく、配信の予測可能性に対して更新が実行されました。つまり、ここで説明する例では、P_（Z、A）とP_（Z、B）は、3つのノードが接続されたままノードAとノードBのどちらが更新を開始しても、同じP_encounterの値を使用して更新されます。
The interval between reruns of the information exchange will generally be set to a small fraction of the expected time between independent encounters of pairs of nodes. This ensures that, for example, the delivery predictability information obtained by node Z from node A will be passed on to node B whether or not nodes A and B can communicate directly during this encounter. This avoids problems that may arise from peculiarities of radio propagation during this sort of encounter, but the scaling of the P_encounter factor according to the time between updates of the delivery predictabilities means that the predictabilities for the nodes that are in contact are not increased excessively as would be the case if each information exchange were treated as a separate encounter with the value of P_encounter_max used each time. When several nodes are in mutual contact, the delivery predictabilities in each node stabilize after a few exchanges due to the scaling of P_encounter as well as the form of Equation 3 where a "max" function is used. This has been demonstrated by simulation.
情報交換の再実行の間隔は、通常、ノードのペアの独立した遭遇間の予想時間のごく一部に設定されます。これにより、たとえば、ノードAとノードBがこの遭遇中に直接通信できるかどうかにかかわらず、ノードZによってノードAから取得された配信予測情報がノードBに確実に渡されます。これにより、この種の遭遇中の無線伝搬の特殊性から発生する可能性のある問題が回避されますが、配信予測可能性の更新間の時間に応じたP_encounter係数のスケーリングは、接触しているノードの予測可能性が過度に増加しないことを意味します各情報交換が、毎回使用されるP_encounter_maxの値との個別の遭遇として扱われた場合が該当します。複数のノードが相互に接触している場合、P_encounterのスケーリングと「max」関数が使用される式3の形式により、数回の交換後に各ノードの配信予測可能性が安定します。これはシミュレーションで実証されています。
The effect of the updates of the delivery predictabilities when there are multiple simultaneous contacts is that the information about good routes on which to forward bundles is correctly passed between sets of nodes that are simultaneously in contact through the transitive update of Equation 3 during each information exchange, but the delivery predictabilities for the direct contacts are not exaggerated.
複数の同時コンタクトがある場合の配信予測可能性の更新の効果は、バンドルを転送する適切なルートに関する情報が、各情報交換中に式3の推移的更新を通じて同時にコンタクトしているノードのセット間で正しく渡されることです。ただし、直接連絡先の配信予測可能性は誇張されていません。
The basic routing algorithm of the protocol is described in Section 2.1. The algorithm uses some parameter values in the calculation of the delivery predictability metric. These parameters are configurable depending on the usage scenario, but Figure 3 provides some recommended default values. A brief explanation of the parameters and some advice on setting appropriate values is given below.
プロトコルの基本的なルーティングアルゴリズムについては、セクション2.1で説明します。アルゴリズムは、配信予測可能性メトリックの計算にいくつかのパラメーター値を使用します。これらのパラメーターは使用シナリオに応じて構成可能ですが、図3に推奨されるデフォルト値をいくつか示します。パラメータの簡単な説明と適切な値の設定に関するアドバイスを以下に示します。
I_typ I_typ provides a fundamental timescale for the mobility pattern in the PRoPHET scenario where the protocol is being applied. It represents the typical or mean time interval between encounters between a given pair of nodes in the normal course of mobility. The interval should reflect the "logical" time between encounters and should not give significant weight to multiple connection events as explained in Section 2.1.2. This time interval informs the settings of many of the other parameters but is not necessarily directly used as a parameter. Consideration needs to be given to the higher statistical moments (e.g., standard deviation) as well as the mean (first moment) of the distribution of intervals between encounters and the nature of that distribution (e.g., how close to a normal distribution it is). There is further discussion of this point later in this section and in Appendix C.
I_typ I_typは、プロトコルが適用されているPRoPHETシナリオでのモビリティパターンの基本的なタイムスケールを提供します。これは、通常のモビリティコースにおけるノードの特定のペア間の遭遇間の典型的なまたは平均時間間隔を表します。間隔は、遭遇間の「論理」時間を反映する必要があり、セクション2.1.2で説明されているように、複数の接続イベントに大きな重みを与えてはなりません。この時間間隔は、他の多くのパラメーターの設定を通知しますが、必ずしもパラメーターとして直接使用されるとは限りません。エンカウンター間の間隔の分布の平均（一次モーメント）とその分布の性質（たとえば、正規分布にどれだけ近いかなど）だけでなく、より高い統計モーメント（標準偏差など）も考慮する必要があります。 。この点については、このセクションの後半と付録Cで詳しく説明します。
P_encounter_max P_encounter_max is used as the upper limit of a scaling factor that increases the delivery predictability for a destination when the destination node is encountered. A larger value of P_encounter_max will increase the delivery predictability faster, and fewer encounters will be required for the delivery predictability to reach a certain level. Given that relative rather than absolute delivery predictability values are what is interesting for the forwarding mechanisms defined, the protocol is very robust to different values of P_encounter as long as the same value is chosen for all nodes. The value should be chosen so that the increase in the delivery predictability resulting from using P_encounter_max in Equation 1 more than compensates for the decay of the delivery predictability resulting from Equation 3 with a time interval of I_typ.
P_encounter_max P_encounter_maxは、宛先ノードに遭遇したときに宛先の配信予測可能性を高めるスケーリング係数の上限として使用されます。 P_encounter_maxの値を大きくすると、配信の予測可能性がより速く向上し、配信の予測可能性が特定のレベルに到達するために必要な遭遇が少なくなります。絶対ではなく相対的な配信予測可能性の値が定義された転送メカニズムにとって興味深いものであることを考えると、すべてのノードに同じ値が選択されている限り、プロトコルはP_encounterのさまざまな値に対して非常に堅牢です。値は、式1でP_encounter_maxを使用することによる配信予測可能性の増加が、式3による配信予測可能性の減衰をI_typの時間間隔で補償するように選択する必要があります。
P_encounter(intvl) As explained in Section 2.1.2, the parameter P_encounter used in Equation 1 is a function of the time interval "intvl". The function should be an approximation to
P_encounter（intvl）セクション2.1.2で説明したように、式1で使用されるパラメータP_encounterは、時間間隔「intvl」の関数です。この関数は、
P_encounter(intvl) =
P_encounter_max * (intvl / I_typ) for 0<= intvl <= I_typ
P_encounter_max for intvl > I_typ
The function can be quantized and adapted to suit the mobility pattern and to make implementation easier. The overall effect should be that be that if Equation 1 is applied a number of times during a long-lived communication opportunity lasting I_typ, the overall increase in the delivery predictability should be approximately the same as if there had been two distinct encounters spaced I_typ apart. This second case would result in one application of Equation 1 using P_encounter_max.
関数は量子化され、モビリティパターンに合わせて実装を容易にするために適合させることができます。全体的な効果は、I_typが続く長命の通信機会の間に式1が何度も適用される場合、配信の予測可能性の全体的な増加は、I_typの間隔で2つの異なるエンカウンターがあった場合とほぼ同じになるはずです。 。この2番目のケースでは、P_encounter_maxを使用して式1を1回適用します。
P_first_threshold As described in Section 2.1.2, the delivery predictability for a destination is gradually reduced over time unless increased as a result of direct encounters or through the transitive property. If the delivery predictability falls below the value P_first_threshold, then the node MAY discard the delivery predictability information for the destination and treat subsequent encounters as if they had never encountered the node previously. This allows the node to reduce the storage needed for delivery predictabilities and decreases the amount of information that has to be exchanged between nodes; otherwise, the reduction algorithm would result in very small but non-zero predictabilities being maintained for nodes that were last encountered a long time ago.
P_first_thresholdセクション2.1.2で説明したように、宛先の配信予測可能性は、直接の遭遇または推移的なプロパティの結果として増加しない限り、時間とともに徐々に減少します。配信の予測可能性が値P_first_thresholdを下回る場合、ノードは宛先の配信の予測可能性情報を破棄し、後続の遭遇を以前にノードに遭遇したことがない場合と同様に扱うことができます（MAY）。これにより、ノードは配信の予測可能性に必要なストレージを削減し、ノード間で交換する必要がある情報の量を減らすことができます。そうでない場合、削減アルゴリズムにより、非常に小さいがゼロではない予測可能性が、ずっと前に最後に遭遇したノードに対して維持されます。
P_encounter_first As described in Section 2.1.2, PRoPHET does not, by default, make any assumptions about the likelihood that an encountered node will be encountered repeatedly in the future or, alternatively, that this is a one-off chance encounter that is unlikely to be repeated. During an encounter where the encountering node has no delivery predictability information for the encountered destination node, either because this is really the first encounter between the nodes or because the previous encounter was so long ago that the predictability had fallen below P_first_threshold and therefore had been discarded, the encountering node sets the delivery predictability for the destination node to P_encounter_first. The suggested value for P_encounter_first is 0.5: this value is RECOMMENDED as appropriate in the usual case where PRoPHET has no extra (e.g., out-of-band) information about whether future encounters with this node will be regular or otherwise.
P_encounter_firstセクション2.1.2で説明したように、PRoPHETは、デフォルトでは、遭遇したノードが将来繰り返し遭遇する可能性についての想定を行いません。または、これは、繰り返されます。遭遇したノードが遭遇した宛先ノードの配信予測可能性情報を持たない遭遇の間、これは実際にはノード間の最初の遭遇であるか、または前の遭遇が非常に前に予測可能性がP_first_thresholdを下回ったために破棄されたためです、遭遇ノードは、宛先ノードの配信予測可能性をP_encounter_firstに設定します。 P_encounter_firstの推奨値は0.5です。この値は、このノードとの今後の遭遇が定期的かそうでないかに関する追加情報（たとえば、帯域外）がPRoPHETにない通常の場合に適切です。
alpha The alpha parameter is used in the optional smoothing of the delivery predictabilities described in Section 2.1.3.1. It is used to determine the weight of the most current P-value in the calculation of an EWMA.
alpha alphaパラメータは、セクション2.1.3.1で説明されている配信予測可能性のオプションの平滑化で使用されます。 EWMAの計算で最新のP値の重みを決定するために使用されます。
beta The beta parameter adjusts the weight of the transitive property of PRoPHET, that is, how much consideration should be given to information about destinations that is received from encountered nodes. If beta is set to zero, the transitive property of PRoPHET will not be active, and only direct encounters will be used in the calculation of the delivery predictability. The higher the value of beta, the more rapidly encounters will increase predictabilities through the transitive rule.
beta betaパラメータは、PRoPHETの推移的なプロパティの重み、つまり、遭遇したノードから受信した宛先に関する情報をどの程度考慮する必要があるかを調整します。ベータがゼロに設定されている場合、PRoPHETの推移的なプロパティはアクティブにならず、配信の予測可能性の計算には直接の遭遇のみが使用されます。ベータの値が高ければ高いほど、より迅速に遭遇することにより、推移的ルールによる予測可能性が向上します。
gamma The gamma parameter determines how quickly delivery predictabilities age. A lower value of gamma will cause the delivery predictability to age faster. The value of gamma should be chosen according to the scenario and environment in which the protocol will be used. If encounters are expected to be very frequent, a lower value should be chosen for gamma than if encounters are expected to be rare.
gamma gammaパラメータは、配信の予測可能性が古くなるまでの時間を決定します。ガンマの値が低いほど、配信の予測可能性が速くなります。ガンマの値は、プロトコルが使用されるシナリオと環境に応じて選択する必要があります。遭遇が非常に頻繁であると予想される場合、遭遇がまれであると予想される場合よりも低い値をガンマに選択する必要があります。
delta The delta parameter sets the maximum value of the delivery predictability for a destination other than for the node itself (i.e., P_(A,B) for all cases except P_(A,A)) as (1 - delta). Delta should be set to a small value to allow the maximum possible range for predictabilities but can be configured to make the calculation efficient if needed.
delta deltaパラメータは、ノード自体以外の宛先の配信予測可能性の最大値（つまり、P_（A、A）を除くすべてのケースでP_（A、B））を（1-delta）として設定します。予測可能性の可能な最大範囲を可能にするために、デルタは小さな値に設定する必要がありますが、必要に応じて計算を効率的にするように構成できます。
To set an appropriate gamma value, one should consider the "average expected delivery" time I_aed in the PRoPHET zone where the protocol is to be used, and the time unit used (the resolution with which the delivery predictability is being updated). The I_aed time interval can be estimated according to the average number of hops that bundles have to pass and the average interval between encounters I_typ. Clearly, if bundles have a Time To Live (TTL), i.e., the time left until the expiry time stored in the bundle occurs, that is less than I_aed, they are unlikely to survive in the network to be delivered to a node in this PRoPHET zone. However, the TTL for bundles created in nodes in this zone should not be chosen solely on this basis because they may pass through other networks.
適切なガンマ値を設定するには、プロトコルが使用されるPRoPHETゾーンの「平均予想配信」時間I_aed、および使用される時間単位（配信予測可能性が更新される解像度）を考慮する必要があります。 I_aed時間間隔は、バンドルが通過しなければならない平均ホップ数と、遭遇間の平均間隔I_typに基づいて推定できます。明らかに、バンドルに存続可能時間（TTL）がある場合、つまりバンドルに保存された有効期限が発生するまでの残り時間がI_aed未満の場合、ネットワーク内で存続してノードに配信される可能性は低いPRoPHETゾーン。ただし、このゾーンのノードで作成されたバンドルのTTLは、他のネットワークを通過する可能性があるため、これだけに基づいて選択しないでください。
After estimating I_aed and selecting how much we want the delivery
predictability to age in one I_aed time period (call this A), we can
calculate K, the number of time units in one I_aed, using
K = (I_aed / time unit). This can then be used to calculate gamma as
gamma = K'th-root( A ).
I_typ, I_aed, K, and gamma can then be used to inform the settings of P_encounter_first, P_encounter_max, P_first_threshold, delta, and the detailed form of the function P_encounter(intvl).
I_typ、I_aed、K、およびgammaを使用して、P_encounter_first、P_encounter_max、P_first_threshold、deltaの設定、および関数P_encounter（intvl）の詳細な形式を通知できます。
First, considering the evolution of the delivery predictability P_(A,B) after a single encounter between nodes A and B, P_(A,B) is initially set to P_encounter_first and will then steadily decay until it reaches P_first_threshold. The ratio between P_encounter_first and P_first_threshold should be set so that P_first_threshold is reached after a small multiple (e.g., 3 to 5) of I_aed has elapsed, making it likely that any subsequent encounter between the nodes would have occurred before P_(A,B) decays below P_first_threshold. If the statistics of the distribution of times between encounters is known, then a small multiple of the standard deviation of the distribution would be a possible period instead of using a multiple of I_aed.
まず、ノードAとBが1回遭遇した後の配信予測可能性P_（A、B）の進化を考えると、P_（A、B）は最初はP_encounter_firstに設定され、その後P_first_thresholdに達するまで徐々に減衰します。 P_encounter_firstとP_first_thresholdの比率は、I_aedの小さな倍数（たとえば、3から5）が経過した後にP_first_thresholdに達し、P_（A、B）の前にノード間のその後の遭遇が発生する可能性が高くなるように設定する必要があります。 P_first_threshold以下で減衰します。遭遇間の時間の分布の統計がわかっている場合、I_aedの倍数を使用する代わりに、分布の標準偏差の小さな倍数が可能な期間になります。
Second, if a second encounter between A and B occurs, the setting of P_encounter_max should be sufficiently high to reverse the decay that would have occurred during I_typ and to increase P_(A,B) above the value of P_encounter_first. After several further encounters, P_(A,B) will reach (1 - delta), its upper limit. As with setting up P_first_threshold, P_encounter_max should be set so that the upper limit is reached after a small number of encounters spaced apart by I_typ have occurred, but this should generally be more than 2 or 3.
次に、AとBの間に2回目の遭遇が発生した場合、P_encounter_maxの設定は、I_typの間に発生したであろう減衰を逆転させ、P_（A、B）をP_encounter_firstの値より大きくするのに十分な高さである必要があります。さらに数回遭遇した後、P_（A、B）はその上限である（1-デルタ）に到達します。 P_first_thresholdの設定と同様に、P_encounter_maxは、I_typだけ離れた少数のエンカウンターが発生した後に上限に達するように設定する必要がありますが、これは通常2または3を超える必要があります。
Finally, beta can be chosen to give some smoothing of the influence of transitivity.
最後に、推移性の影響をある程度平滑化するためにベータを選択できます。
These instructions on how to set the parameters are only given as a possible method for selecting appropriate values, but network operators are free to set parameters as they choose. Appendix C goes into some more detail on linking the parameters defined here and the more conventional ways of expressing the mobility model in terms of distributions of times between events of various types.
パラメータの設定方法に関するこれらの手順は、適切な値を選択するための可能な方法としてのみ提供されていますが、ネットワークオペレータは自由にパラメータを設定できます。付録Cでは、ここで定義されたパラメーターのリンクと、さまざまなタイプのイベント間の時間の分布に関してモビリティモデルを表現する従来の方法について、さらに詳しく説明します。
Recommended starting parameter values when specific network measurements have not been done are below. Note: There are no "one size fits all" default values, and the ideal values vary based on network characteristics. It is not inherently necessary for the parameter values to be identical at all nodes, but it is recommended that similar values are used at all nodes within a PRoPHET zone as discussed in Section 2.1.2.1.
特定のネットワーク測定が行われていない場合の推奨される開始パラメーター値は以下のとおりです。注：「1つのサイズですべてに適合する」デフォルト値はなく、理想的な値はネットワークの特性に基づいて異なります。パラメータ値がすべてのノードで同一である必要はありませんが、2.1.2.1項で説明したように、PRoPHETゾーン内のすべてのノードで同様の値を使用することをお勧めします。
+========================================+
| Parameter | Recommended value |
+========================================+
| P_encounter_max | 0.7 |
+----------------------------------------+
| P_encounter_first | 0.5 |
+----------------------------------------+
| P_first_threshold | 0.1 |
+----------------------------------------+
| alpha | 0.5 |
+----------------------------------------+
| beta | 0.9 |
+----------------------------------------+
| gamma | 0.999 |
+----------------------------------------+
| delta | 0.01 |
+========================================+
Figure 3: Default parameter settings
図3：デフォルトのパラメーター設定
Upon reception of the Bundle Offer TLV, the node inspects the list of bundles and decides which bundles it is willing to store for future forwarding or that it is able to deliver to their destinations. This decision has to be made using local policies and considering parameters such as available buffer space and, if the node requested bundle lengths, the lengths of the offered bundles. For each such acceptable bundle, the node sends a Bundle Response TLV to its peering node, which responds by sending the requested bundle. If a node has some bundles it would prefer to receive ahead of others offered (e.g., bundles that it can deliver to their final destination), it MAY request the bundles in that priority order. This is often desirable as there is no guarantee that the nodes will remain in contact with each other for long enough to transfer all the acceptable bundles. Otherwise, the node SHOULD assume that the bundles are listed in a priority order determined by the peering node's forwarding strategy and request bundles in that order.
Bundle Offer TLVを受信すると、ノードはバンドルのリストを検査し、将来の転送のために保存する用意があるバンドル、または宛先に配信できるバンドルを決定します。この決定は、ローカルポリシーを使用して、利用可能なバッファースペースや、ノードがバンドルの長さを要求した場合は提供されたバンドルの長さなどのパラメーターを考慮して行う必要があります。そのような受け入れ可能なバンドルごとに、ノードはバンドル応答TLVをピアリングノードに送信し、ピアリングノードは要求されたバンドルを送信することによって応答します。ノードがいくつかのバンドルを持っている場合、提供された他のバンドル（たとえば、最終宛先に配信できるバンドル）より先に受信したい場合、その優先順位でバンドルを要求できます（MAY）。すべての受け入れ可能なバンドルを転送するのに十分な時間、ノードが相互に接続されたままである保証がないため、これは多くの場合望ましいことです。それ以外の場合、ノードは、バンドルがピアリングノードの転送戦略によって決定された優先順位でリストされ、バンドルをその順序で要求すると想定する必要があります（SHOULD）。
To free up local resources, a node may give custody of a bundle to another node that offers custody. This is done to move the retransmission requirement further toward the destination. The concept of custody transfer, and more details on the motivation for its use can be found in [RFC4838]. PRoPHET takes no responsibilities for making custody decisions. Such decisions should be made by a higher layer.
ローカルリソースを解放するために、ノードは、カストディを提供する別のノードにバンドルのカストディを与えることができます。これは、再送信要件を宛先にさらに移動するために行われます。保管転送の概念、およびその使用の動機の詳細については、[RFC4838]を参照してください。 PRoPHETは、保管の決定を行う責任を負いません。このような決定は、上位層で行う必要があります。
A PRoPHET ACK is only a confirmation that a bundle has been delivered to its destination in the PRoPHET zone (within the part of the network where PRoPHET is used for routing, bundles might traverse several different types of networks using different routing protocols; thus, this might not be the final destination of the bundle). When nodes exchange Bundle Offer TLVs, bundles that have been ACKed are also listed, having the "PRoPHET ACK" flag set. The node that receives this list updates its own list of ACKed bundles to be the union of its previous list and the received list. To prevent the list of ACKed bundles growing indefinitely, each PRoPHET ACK should have a timeout that MUST NOT be longer than the timeout of the bundle to which the ACK corresponds.
PRoPHET ACKは、バンドルがPRoPHETゾーンの宛先に配信されたことの確認にすぎません（PRoPHETがルーティングに使用されるネットワークの一部内で、バンドルは異なるルーティングプロトコルを使用していくつかの異なるタイプのネットワークを通過する可能性があります。したがって、これはバンドルの最終的な宛先ではない場合があります）。ノードがバンドルオファーTLVを交換すると、ACKされたバンドルもリストされ、「PRoPHET ACK」フラグが設定されます。このリストを受信したノードは、ACKされたバンドルの独自のリストを更新して、前のリストと受信したリストを結合します。 ACKされたバンドルのリストが無制限に大きくなるのを防ぐために、各PRoPHET ACKには、ACKが対応するバンドルのタイムアウトより長くてはならないタイムアウトが必要です。
When a node receives a PRoPHET ACK for a bundle it is carrying, it MAY delete that bundle from its storage, unless the node holds custody of that bundle. The PRoPHET ACK only indicates that a bundle has been delivered to its destination within the PRoPHET zone, so the reception of a PRoPHET ACK is not a guarantee that the bundle has been delivered to its final destination.
ノードが運ぶバンドルのPRoPHET ACKを受信すると、ノードがそのバンドルの管理を保持していない限り、そのバンドルをストレージから削除してもよい（MAY）。 PRoPHET ACKは、バンドルがPRoPHETゾーン内の宛先に配信されたことを示すだけなので、PRoPHET ACKの受信は、バンドルが最終宛先に配信されたことを保証するものではありません。
Nodes MAY track to which nodes they have sent PRoPHET ACKs for certain bundles, and MAY in that case refrain from sending multiple PRoPHET ACKs for the same bundle to the same node.
ノードは、特定のバンドルのPRoPHET ACKを送信したノードを追跡できます（MAY）。その場合、同じバンドルの複数のPRoPHET ACKを同じノードに送信しないでください。
If necessary in order to preserve system resources, nodes MAY drop PRoPHET ACKs prematurely but SHOULD refrain from doing so if possible.
システムリソースを保持するために必要な場合、ノードは時期尚早にPRoPHET ACKをドロップする場合がありますが、可能であればそうすることは控えてください。
It is important to keep in mind that PRoPHET ACKs and bundle ACKs [RFC5050] are different things. PRoPHET ACKs are only valid within the PRoPHET part of the network, while bundle ACKs are end-to-end acknowledgments that may go outside of the PRoPHET zone.
PRoPHET ACKとバンドルACK [RFC5050]は異なるものであることを覚えておくことが重要です。 PRoPHET ACKはネットワークのPRoPHET部分内でのみ有効ですが、バンドルACKはPRoPHETゾーンの外に出る可能性があるエンドツーエンドの確認応答です。
During the Information Exchange Phase, nodes need to decide on which bundles they wish to exchange with the peering node. Because of the large number of scenarios and environments that PRoPHET can be used in, and because of the wide range of devices that may be used, it is not certain that this decision will be based on the same strategy in every case. Therefore, each node MUST operate a _forwarding strategy_ to make this decision. Nodes may define their own strategies, but this section defines a few basic forwarding strategies that nodes can use. Note: If the node being encountered is the destination of any of the bundles being carried, those bundles SHOULD be offered to the destination, even if that would violate the forwarding strategy. Some of the forwarding strategies listed here have been evaluated (together with a number of queueing policies) through simulations, and more information about that and recommendations on which strategies to use in different situations can be found in [lindgren_06]. If not chosen differently due to the characteristics of the deployment scenario, nodes SHOULD choose GRTR as the default forwarding strategy.
情報交換フェーズでは、ノードはピアリングノードと交換するバンドルを決定する必要があります。 PRoPHETを使用できるシナリオと環境の数が多いため、および使用できるデバイスの範囲が広いため、この決定がすべてのケースで同じ戦略に基づいているかどうかは不明です。したがって、各ノードはこの決定を行うために_転送戦略_を操作しなければなりません。ノードは独自の戦略を定義できますが、このセクションでは、ノードが使用できるいくつかの基本的な転送戦略を定義します。注：遭遇するノードが、運ばれているいずれかのバンドルの宛先である場合、たとえ転送戦略に違反する場合でも、それらのバンドルは宛先に提供されるべきです（SHOULD）。ここにリストされている転送戦略の一部はシミュレーションを通じて評価されており（さまざまなキューイングポリシーとともに）、その詳細と、さまざまな状況で使用する戦略に関する推奨事項は[lindgren_06]にあります。展開シナリオの特性により異なる方法で選択されていない場合、ノードはデフォルトの転送戦略としてGRTRを選択する必要があります（SHOULD）。
The short names applied to the forwarding strategies should be read as mnemonic handles rather than as specific acronyms for any set of words in the specification.
転送戦略に適用される短い名前は、仕様内の一連の単語の特定の頭字語としてではなく、ニーモニックハンドルとして読み取る必要があります。
We use the following notation in our descriptions below. A and B are the nodes that encounter each other, and the strategies are described as they would be applied by node A. The destination node is D. P_(X,Y) denotes the delivery predictability stored at node X for destination Y, and NF is the number of times node A has given the bundle to some other node.
以下の説明では、次の表記を使用します。 AとBは互いに遭遇するノードであり、戦略はノードAによって適用されるように記述されています。宛先ノードはDです。P_（X、Y）はノードXに格納されている宛先Yの配信予測可能性を示しますNFは、ノードAが他のノードにバンドルを提供した回数です。
GRTR Forward the bundle only if P_(B,D) > P_(A,D).
GRTR P_（B、D）> P_（A、D）の場合にのみバンドルを転送します。
When two nodes meet, a bundle is sent to the other node if the delivery predictability of the destination of the bundle is higher at the other node. The first node does not delete the bundle after sending it as long as there is sufficient buffer space available (since it might encounter a better node, or even the final destination of the bundle in the future).
2つのノードが出会うとき、バンドルの宛先の配信予測可能性が他のノードで高い場合、バンドルは他のノードに送信されます。最初のノードは、十分なバッファスペースが利用可能である限り、送信後にバンドルを削除しません（より良いノード、または将来的にバンドルの最終宛先に遭遇する可能性があるため）。
GTMX Forward the bundle only if P_(B,D) > P_(A,D) && NF < NF_max.
GTMXバンドルを転送するのは、P_（B、D）> P_（A、D）&& NF <NF_maxの場合のみです。
This strategy is like the previous one, but each bundle is given to at most NF_max other nodes in addition to the destination.
この戦略は前の戦略と似ていますが、各バンドルは宛先に加えて最大でNF_maxの他のノードに与えられます。
GTHR Forward the bundle only if P_(B,D) > P_(A,D) OR P_(B,D) > FORW_thres, where FORW_thres is a threshold value above which a bundle should always be given to the node unless it is already present at the other node.
GTHRは、P_（B、D）> P_（A、D）OR P_（B、D）> FORW_thresの場合にのみバンドルを転送します。ここで、FORW_thresは、バンドルがノードに既に与えられている場合を除いて、ノードにバンドルが常に与えられるしきい値です他のノードに存在します。
This strategy is similar to GRTR, but among nodes with very high delivery predictability, bundles for that particular destination are spread epidemically.
この戦略はGRTRに似ていますが、配信の予測可能性が非常に高いノード間で、その特定の宛先のバンドルが蔓延します。
GRTR+ Forward the bundle only if Equation 5 holds, where P_max is the largest delivery predictability reported by a node to which the bundle has been sent so far.
GRTR +式5が成立する場合にのみバンドルを転送します。ここで、P_maxは、これまでにバンドルが送信されたノードによって報告された最大の配信予測可能性です。
P_(B,D) > P_(A,D) && P_(B,D) > P_max (Eq. 5)
This strategy is like GRTR, but each node forwarding a bundle keeps track of the largest delivery predictability of any node it has forwarded this bundle to, and only forwards the bundle again if the currently encountered node has a greater delivery predictability than the maximum previously encountered.
この戦略はGRTRに似ていますが、バンドルを転送する各ノードは、このバンドルを転送したノードの最大の配信予測可能性を追跡し、現在遭遇しているノードが以前に遭遇した最大よりも配信予測可能性が高い場合にのみ、バンドルを再び転送します。
GTMX+ Forward the bundle only if Equation 6 holds.
GTMX +式6が成立する場合にのみバンドルを転送します。
P_(B,D) > P_(A,D) && P_(B,D) > P_max && NF < NF_max (Eq. 6)
This strategy is like GTMX, but nodes keep track of P_max as in GRTR+.
この戦略はGTMXに似ていますが、ノードはGRTR +と同様にP_maxを追跡します。
GRTRSort Select bundles in descending order of the value of P_(B,D) - P_(A,D). Forward the bundle only if P_(B,D) > P_(A,D).
GRTRSort P_（B、D）-P_（A、D）の値の降順でバンドルを選択します。 P_（B、D）> P_（A、D）の場合のみ、バンドルを転送します。
This strategy is like GRTR, but instead of just going through the bundle queue linearly, this strategy looks at the difference in delivery predictabilities for each bundle between the two nodes and forwards the bundles with the largest difference first. As bandwidth limitations or disrupted connections may result in not all bundles that would be desirable being exchanged, it could be desirable to first send bundles that get a large improvement in delivery predictability.
この戦略はGRTRに似ていますが、バンドルキューを直線的に通過するのではなく、2つのノード間の各バンドルの配信予測可能性の違いを調べ、最大の違いを持つバンドルを最初に転送します。帯域幅の制限や接続の中断により、すべてのバンドルが交換されるとは限らないため、配信の予測可能性が大幅に向上したバンドルを最初に送信することが望ましい場合があります。
GRTRMax Select bundles in descending order of P_(B,D). Forward the bundle only if P_(B,D) > P_(A,D).
GRTRMax P_（B、D）の降順でバンドルを選択します。 P_（B、D）> P_（A、D）の場合のみ、バンドルを転送します。
This strategy begins by considering the bundles for which the encountered node has the highest delivery predictability. The motivation for doing this is the same as in GRTRSort, but based on the idea that it is better to give bundles to nodes with high absolute delivery predictabilities, instead of trying to maximize the improvement.
この戦略は、遭遇したノードが最も高い配信予測可能性を持つバンドルを検討することから始まります。これを行う動機はGRTRSortと同じですが、改善を最大化しようとするよりも、絶対的な配信予測可能性が高いノードにバンドルを与える方が良いという考えに基づいています。
Because of limited buffer resources, nodes may need to drop some bundles. As is the case with the forwarding strategies, which bundle to drop is also dependent on the scenario. Therefore, each node MUST also operate a queueing policy that determines how its bundle queue is handled. This section defines a few basic queueing policies, but nodes MAY use other policies if desired. Some of the queueing policies listed here have been evaluated (together with a number of forwarding strategies) through simulations. More information about that and recommendations on which policies to use in different situations can be found in [lindgren_06]. If not chosen differently due to the characteristics of the deployment scenario, nodes SHOULD choose FIFO as the default queueing policy.
バッファリソースが限られているため、ノードは一部のバンドルを削除する必要がある場合があります。転送戦略の場合と同様に、ドロップするバンドルもシナリオに依存します。したがって、各ノードは、そのバンドルキューの処理方法を決定するキューイングポリシーも操作する必要があります。このセクションではいくつかの基本的なキューイングポリシーを定義しますが、ノードは必要に応じて他のポリシーを使用できます。ここにリストされているいくつかのキューイングポリシーは、シミュレーションを通じて（多数の転送戦略とともに）評価されています。その詳細と、さまざまな状況で使用するポリシーに関する推奨事項については、[lindgren_06]を参照してください。展開シナリオの特性により異なる方法で選択されない場合、ノードはデフォルトのキューイングポリシーとしてFIFOを選択する必要があります（SHOULD）。
The short names applied to the queueing policies should be read as mnemonic handles rather than as specific acronyms for any set of words in the specification.
キューイングポリシーに適用される短い名前は、仕様内の一連の単語の特定の頭字語としてではなく、ニーモニックハンドルとして読み取る必要があります。
FIFO - First In First Out. The bundle that was first entered into the queue is the first bundle to be dropped.
FIFO-先入れ先出し。最初にキューに入れられたバンドルは、最初にドロップされるバンドルです。
MOFO - Evict most forwarded first. In an attempt to maximize the delivery rate of bundles, this policy requires that the routing agent keep track of the number of times each bundle has been forwarded to some other node. The bundle that has been forwarded the largest number of times is the first to be dropped.
MOFO-Evictが最初に転送されます。バンドルの配信率を最大化するために、このポリシーでは、ルーティングエージェントが、各バンドルが他のノードに転送された回数を追跡する必要があります。最も多く転送されたバンドルが最初にドロップされます。
MOPR - Evict most favorably forwarded first. Keep a variable FAV for each bundle in the queue, initialized to zero. Each time the bundle is forwarded, update FAV according to Equation 7, where P is the predictability metric that the node the bundle is forwarded to has for its destination.
MOPR-Evictが最初に転送されます。ゼロに初期化されたキュー内の各バンドルの変数FAVを保持します。バンドルが転送されるたびに、式7に従ってFAVを更新します。ここで、Pは、バンドルが転送される先のノードが持つ予測可能性メトリックです。
FAV_new = FAV_old + ( 1 - FAV_old ) * P (Eq. 7)
The bundle with the highest FAV value is the first to be dropped.
最も高いFAV値を持つバンドルが最初にドロップされます。
Linear MOPR - Evict most favorably forwarded first; linear increase. Keep a variable FAV for each bundle in the queue, initialized to zero. Each time the bundle is forwarded, update FAV according to Equation 8, where P is the predictability metric that the node the bundle is forwarded to has for its destination.
リニアMOPR-Evictが最初に転送されます。線形増加。ゼロに初期化されたキュー内の各バンドルの変数FAVを保持します。バンドルが転送されるたびに、式8に従ってFAVを更新します。ここで、Pは、バンドルの転送先のノードがその宛先に対して持つ予測可能性メトリックです。
FAV_new = FAV_old + P (Eq. 8)
FAV_new = FAV_old + P（式8）
The bundle with the highest FAV value is the first to be dropped.
最も高いFAV値を持つバンドルが最初にドロップされます。
SHLI - Evict shortest life time first. As described in [RFC5050], each bundle has a timeout value specifying when it no longer is meaningful to its application and should be deleted. Since bundles with short remaining Time To Live will soon be dropped anyway, this policy decides to drop the bundle with the shortest remaining lifetime first. To successfully use a policy like this, there needs to be some form of time synchronization between nodes so that it is possible to know the exact lifetimes of bundles. However, this is not specific to this routing protocol, but a more general DTN problem.
SHLI-最短のライフタイムを最初に削除します。 [RFC5050]で説明されているように、各バンドルにはタイムアウト値があり、アプリケーションにとって意味がなくなって削除する必要がある場合を指定します。いずれにしても、残りの存続可能時間が短いバンドルはすぐにドロップされるため、このポリシーは、残りのライフタイムが最も短いバンドルを最初にドロップすることを決定します。このようなポリシーを正常に使用するには、バンドル間の正確なライフタイムを知ることができるように、ノード間に何らかの形の時間同期が必要です。ただし、これはこのルーティングプロトコルに固有のものではなく、より一般的なDTN問題です。
LEPR - Evict least probable first. Since the node is least likely to deliver a bundle for which it has a low delivery predictability, drop the bundle for which the node has the lowest delivery predictability, and that has been forwarded at least MF times, where MF is a minimum number of forwards that a bundle must have been forwarded before being dropped (if such a bundle exists).
LEPR-最初に最も可能性の低いエビクト。ノードは配信予測可能性が低いバンドルを配信する可能性が最も低いため、ノードが配信予測可能性が最も低く、少なくともMF回転送されたバンドルをドロップします。MFは転送の最小数です。バンドルがドロップされる前に転送されている必要がある（そのようなバンドルが存在する場合）。
More than one queueing policy MAY be combined in an ordered set, where the first policy is used primarily, the second only being used if there is a need to tie-break between bundles given the same eviction priority by the primary policy, and so on. As an example, one could select the queueing policy to be {MOFO; SHLI; FIFO}, which would start by dropping the bundle that has been forwarded the largest number of times. If more than one bundle has been forwarded the same number of times, the one with the shortest remaining lifetime will be dropped, and if that also is the same, the FIFO policy will be used to drop the bundle first received.
複数のキューイングポリシーを順序付けされたセットに組み合わせることができます。最初のポリシーが主に使用され、2番目は、プライマリポリシーによって同じエビクション優先度が与えられたバンドル間でタイブレークする必要がある場合にのみ使用されます。 。例として、キューイングポリシーを{MOFO;に選択できます。 SHLI;これは、転送回数が最も多いバンドルをドロップすることから始まります。複数のバンドルが同じ回数転送された場合、残りのライフタイムが最も短いものがドロップされます。それも同じ場合、FIFOポリシーを使用して、最初に受信したバンドルをドロップします。
It is worth noting that a node MUST NOT drop bundles for which it has custody unless the bundle's lifetime expires.
バンドルのライフタイムが期限切れにならない限り、ノードが管理下にあるバンドルをドロップしてはならないことに注意してください。
This section defines the message formats of the PRoPHET routing protocol. In order to allow for variable-length fields, many numeric fields are encoded as Self-Delimiting Numeric Values (SDNVs). The format of SDNVs is defined in [RFC5050]. Since many of the fields are coded as SDNVs, the size and alignment of fields indicated in many of the specification diagrams below are indicative rather than prescriptive. Where SDNVs and/or text strings are used, the octets of the fields will be packed as closely as possible with no intervening padding between fields.
このセクションでは、PRoPHETルーティングプロトコルのメッセージフォーマットを定義します。可変長フィールドを可能にするために、多くの数値フィールドは自己区切り数値（SDNV）としてエンコードされます。 SDNVのフォーマットは[RFC5050]で定義されています。フィールドの多くはSDNVとしてコード化されているため、以下の仕様図の多くに示されているフィールドのサイズと配置は、規範的なものではなく、指示的なものです。 SDNVまたはテキスト文字列、あるいはその両方が使用される場合、フィールドのオクテットは、フィールド間にパディングが介在することなく、可能な限り密にパックされます。
Explicit-length fields are specified for all variable-length string fields. Accordingly, strings are not null terminated and just contain the exact set of octets in the string.
明示長フィールドは、すべての可変長文字列フィールドに指定されます。したがって、文字列はnullで終了せず、文字列内の正確なオクテットのセットを含むだけです。
The basic message format shown in Figure 4 consists of a header (see Section 4.1) followed by a sequence of one or more Type-Length-Value components (TLVs) taken from the specifications in Section 4.2.
図4に示す基本的なメッセージ形式は、ヘッダー（セクション4.1を参照）と、それに続くセクション4.2の仕様から取得した1つ以上のType-Length-Valueコンポーネント（TLV）のシーケンスで構成されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Header ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLV 1 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
~ . ~
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLV n ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Basic PRoPHET Message Format
図4：基本的なPRoPHETメッセージ形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol Number|Version| Flags | Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Instance | Sender Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| SubMessage Number | Length (SDNV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Message Body ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: PRoPHET Message Header
図5：PRoPHETメッセージヘッダー
Protocol Number The DTN Routing Protocol Number encoded as 8-bit unsigned integer in network bit order. The value of this field is 0. The PRoPHET header is organized in this way so that in principle PRoPHET messages could be sent as the Protocol Data Unit of an IP packet if an IP protocol number was allocated for PRoPHET.
プロトコル番号ネットワークビットオーダーの8ビット符号なし整数としてエンコードされたDTNルーティングプロトコル番号。このフィールドの値は0です。PRoPHETヘッダーはこのように構成されているため、原則的にPRoPHETにIPプロトコル番号が割り当てられている場合、PRoPHETメッセージはIPパケットのプロトコルデータユニットとして送信できます。
At present, PRoPHET is only specified to use a TCP transport for carriage of PRoPHET packets, so that the protocol number serves only to identify the PRoPHET protocol within DTN. Transmitting PRoPHET packets directly as an IP protocol on a public IP network such as the Internet would generally not work well because middleboxes (such as firewalls and NAT boxes) would be unlikely to allow the protocol to pass through, and the protocol does not provide any congestion control. However, it could be so used on private networks for experimentation or in situations where all communications are between isolated pairs of nodes. Also, in the future, other protocols that require transmission of metadata between DTN nodes could potentially use the same format and protocol state machinery but with a different Protocol Number.
現在、PRoPHETは、PRoPHETパケットの伝送にTCPトランスポートを使用するようにのみ指定されているため、プロトコル番号は、DTN内のPRoPHETプロトコルを識別するためだけに機能します。インターネットなどのパブリックIPネットワークでIPプロトコルとしてPRoPHETパケットを直接送信すると、ミドルボックス（ファイアウォールやNATボックスなど）ではプロトコルの通過が許可されず、プロトコルでプロトコルが提供されないため、通常はうまく機能しません。輻輳制御。ただし、プライベートネットワークで実験用に、またはすべての通信が分離されたノードのペア間で行われる状況で使用できます。また、将来的には、DTNノード間のメタデータの送信を必要とする他のプロトコルが、同じフォーマットとプロトコル状態機構を使用する可能性がありますが、プロトコル番号が異なります。
Version The version of the PRoPHET Protocol. Encoded as a 4-bit unsigned integer in network bit order. This document defines version 2.
バージョンPRoPHETプロトコルのバージョン。ネットワークビットオーダーの4ビット符号なし整数としてエンコードされます。このドキュメントはバージョン2を定義しています。
Flags Reserved field of 4 bits.
Flags 4ビットの予約フィールド。
Result Field that is used to indicate whether a response is required to the request message if the outcome is successful. A value of "NoSuccessAck" indicates that the request message does not expect a response if the outcome is successful, and a value of "AckAll" indicates that a response is expected if the outcome is successful. In both cases, a failure response MUST be generated if the request fails. If running over a TCP transport or similar protocol that offers reliable in order delivery, deployments MAY choose not to send "Success" responses when an outcome is successful. To achieve this, the Result field is set to the "NoSuccessAck" value in all request messages.
結果が成功した場合に要求メッセージへの応答が必要かどうかを示すために使用される結果フィールド。 「NoSuccessAck」の値は、結果が成功した場合、要求メッセージが応答を期待しないことを示し、「AckAll」の値は、結果が成功した場合、応答が期待されることを示します。どちらの場合も、要求が失敗した場合、失敗応答を生成する必要があります。 TCPトランスポートまたは信頼性の高い順序配信を提供する同様のプロトコルを介して実行している場合、デプロイメントは、結果が成功したときに「成功」応答を送信しないことを選択できます。これを実現するには、すべての要求メッセージでResultフィールドを「NoSuccessAck」値に設定します。
In a response message, the result field can have two values: "Success" and "Failure". The "Success" result indicates a success response. All messages that belong to the same success response will have the same Transaction Identifier. The "Success" result indicates a success response that may be contained in a single message or the final message of a success response spanning multiple messages.
応答メッセージでは、結果フィールドに「成功」と「失敗」の2つの値を含めることができます。 「成功」の結果は、成功の応答を示します。同じ成功応答に属するすべてのメッセージは、同じトランザクション識別子を持ちます。 「成功」の結果は、単一のメッセージまたは複数のメッセージにわたる成功応答の最終メッセージに含まれる可能性がある成功応答を示します。
ReturnReceipt is a value of the result field used to indicate that an acknowledgement is required for the message. The default for messages is that the controller will not acknowledge responses. In the case where an acknowledgement is required, it will set the Result Field to ReturnReceipt in the header of the Message.
ReturnReceiptは、メッセージに肯定応答が必要であることを示すために使用される結果フィールドの値です。メッセージのデフォルトでは、コントローラーは応答を確認しません。確認が必要な場合は、メッセージのヘッダーで結果フィールドをReturnReceiptに設定します。
The result field is encoded as an 8-bit unsigned integer in network bit order. The following values are currently defined:
結果フィールドは、ネットワークビットオーダーの8ビット符号なし整数としてエンコードされます。現在、次の値が定義されています。
NoSuccessAck: Result = 1
AckAll: Result = 2
Success: Result = 3
Failure: Result = 4
ReturnReceipt Result = 5
Code This field gives further information concerning the result in a response message. It is mostly used to pass an error code in a failure response but can also be used to give further information in a success response message or an event message. In a request message, the code field is not used and is set to zero.
コードこのフィールドは、応答メッセージの結果に関する詳細情報を提供します。ほとんどの場合、失敗応答でエラーコードを渡すために使用されますが、成功応答メッセージまたはイベントメッセージで詳細情報を提供するためにも使用できます。要求メッセージでは、コードフィールドは使用されず、ゼロに設定されます。
If the Code field indicates that the Error TLV is included in the message, further information on the error will be found in the Error TLV, which MUST be the first TLV after the header.
CodeフィールドがエラーTLVがメッセージに含まれていることを示している場合、エラーに関する詳細情報はエラーTLVにあります。これはヘッダーの後の最初のTLVでなければなりません。
The Code field is encoded as an 8-bit unsigned integer in network bit order. Separate number code spaces are used for success and failure response messages. In each case, a range of values is reserved for use in specifications and another range for private and experimental use. For success messages, the following values are defined:
Codeフィールドは、ネットワークビットオーダーの8ビット符号なし整数としてエンコードされます。成功と失敗の応答メッセージには、個別の番号コードスペースが使用されます。いずれの場合も、値の範囲は仕様で使用するために予約されており、別の範囲は私的および実験的使用のために予約されています。成功メッセージには、次の値が定義されています。
Generic Success 0x00 Submessage Received 0x01 Unassigned 0x02 - 0x7F Private/Experimental Use 0x80 - 0xFF
一般的な成功0x00受信したサブメッセージ0x01未割り当て0x02-0x7Fプライベート/実験的使用0x80-0xFF
The Submessage Received code is used to acknowledge reception of a message segment. The Generic Success code is used to acknowledge receipt of a complete message and successful processing of the contents.
Submessage Receivedコードは、メッセージセグメントの受信を確認するために使用されます。 Generic Successコードは、完全なメッセージの受信とコンテンツの正常な処理を確認するために使用されます。
For failure messages, the following values are defined:
障害メッセージの場合、次の値が定義されています。
Reserved 0x00 - 0x01 Unspecified Failure 0x02 Unassigned 0x03 - 0x7F Private/Experimental Use 0x80 - 0xFE Error TLV in message 0xFF
予約済み0x00-0x01不特定の障害0x02未割り当て0x03-0x7Fプライベート/実験的使用0x80-0xFFメッセージの0xFEエラーTLV
The Unspecified Failure code can be used to report a failure for which there is no more specific code or Error TLV value defined.
未指定の障害コードを使用して、特定のコードまたはエラーTLV値が定義されていない障害を報告できます。
Sender Instance For messages during the Hello phase with the Hello SYN, Hello SYNACK, and Hello ACK functions (which are explained in Section 5.2), it is the sender's instance number for the link. It is used to detect when the link comes back up after going down or when the identity of the entity at the other end of the link changes. The instance number is a 16-bit number that is guaranteed to be unique within the recent past and to change when the link or node comes back up after going down. Zero is not a valid instance number. For the RSTACK function (also explained in detail in Section 5.2), the Sender Instance field is set to the value of the Receiver Instance field from the incoming message that caused the RSTACK function to be generated. Messages sent after the Hello phase is completed should use the sender's instance number for the link. The Sender Instance is encoded as a 16-bit unsigned integer in network bit order.
送信者インスタンスHello SYN、Hello SYNACK、およびHello ACK関数（セクション5.2で説明）を使用したHelloフェーズ中のメッセージの場合、これはリンクの送信者のインスタンス番号です。これは、リンクがダウンした後、アップに戻るとき、またはリンクのもう一方の端にあるエンティティのIDが変更されたときに検出するために使用されます。インスタンス番号は16ビットの番号であり、最近の過去で一意であることが保証されており、リンクまたはノードがダウンした後に復旧すると変更されます。ゼロは有効なインスタンス番号ではありません。 RSTACK関数（セクション5.2でも詳細に説明）の場合、Sender Instanceフィールドは、RSTACK関数が生成される原因となった着信メッセージのReceiver Instanceフィールドの値に設定されます。 Helloフェーズの完了後に送信されるメッセージは、リンクの送信者のインスタンス番号を使用する必要があります。送信者インスタンスは、ネットワークビットオーダーの16ビット符号なし整数としてエンコードされます。
Receiver Instance For messages during the Hello phase with the Hello SYN, Hello SYNACK, and Hello ACK functions, it is what the sender believes is the current instance number for the link, allocated by the entity at the far end of the link. If the sender of the message does not know the current instance number at the far end of the link, this field MUST be set to zero. For the RSTACK message, the Receiver Instance field is set to the value of the Sender Instance field from the incoming message that caused the RSTACK message to be generated. Messages sent after the Hello phase is completed should use what the sender believes is the current instance number for the link, allocated by the entity at the far end of the link. The Sender Instance is encoded as a 16-bit unsigned integer in network bit order.
レシーバーインスタンスHello SYN、Hello SYNACK、およびHello ACK機能を使用するHelloフェーズ中のメッセージの場合、送信者は、リンクの遠端にあるエンティティによって割り当てられたリンクの現在のインスタンス番号であると考えています。メッセージの送信者がリンクの遠端の現在のインスタンス番号を知らない場合は、このフィールドをゼロに設定する必要があります。 RSTACKメッセージの場合、Receiver Instanceフィールドは、RSTACKメッセージが生成される原因となった着信メッセージのSender Instanceフィールドの値に設定されます。 Helloフェーズの完了後に送信されるメッセージでは、送信者がリンクの現在のインスタンス番号であると信じているものを使用する必要があります。これは、リンクの遠端にあるエンティティによって割り当てられます。送信者インスタンスは、ネットワークビットオーダーの16ビット符号なし整数としてエンコードされます。
Transaction Identifier Used to associate a message with its response message. This should be set in request messages to a value that is unique for the sending host within the recent past. Reply messages contain the Transaction Identifier of the request to which they are responding. The Transaction Identifier is a bit pattern of 32 bits.
トランザクション識別子メッセージを応答メッセージに関連付けるために使用されます。これは、リクエストメッセージ内で、最近過去の送信ホストに固有の値に設定する必要があります。応答メッセージには、応答する要求のトランザクションIDが含まれています。トランザクション識別子は32ビットのビットパターンです。
S-flag If S is set (value 1), then the SubMessage Number field indicates the total number of SubMessage segments that compose the entire message. If it is not set (value 0), then the SubMessage Number field indicates the sequence number of this SubMessage segment within the whole message. The S field will only be set in the first submessage of a sequence.
SフラグSが設定されている場合（値1）、[サブメッセージ番号]フィールドは、メッセージ全体を構成するサブメッセージセグメントの総数を示します。設定されていない場合（値0）、[サブメッセージ番号]フィールドは、メッセージ全体内のこのサブメッセージセグメントのシーケンス番号を示します。 Sフィールドは、シーケンスの最初のサブメッセージでのみ設定されます。
SubMessage Number When a message is segmented because it exceeds the MTU of the link layer or otherwise, each segment will include a SubMessage Number to indicate its position. Alternatively, if it is the first submessage in a sequence of submessages, the S-flag will be set, and this field will contain the total count of SubMessage segments. The SubMessage Number is encoded as a 15-bit unsigned integer in network bit order. The SubMessage number is zero-based, i.e., for a message divided into n submessages, they are numbered from 0 to (n - 1). For a message that is not divided into submessages, the single message has the S-flag cleared (value 0), and the SubMessage Number is set to 0 (zero).
サブメッセージ番号リンク層のMTUを超えるなどの理由でメッセージがセグメント化される場合、各セグメントには、その位置を示すサブメッセージ番号が含まれます。または、それが一連のサブメッセージの最初のサブメッセージである場合、Sフラグが設定され、このフィールドにはSubMessageセグメントの総数が含まれます。サブメッセージ番号は、ネットワークビットオーダーで15ビットの符号なし整数としてエンコードされます。 SubMessage番号はゼロから始まります。つまり、メッセージがn個のサブメッセージに分割されている場合、0から（n-1）まで番号が付けられます。サブメッセージに分割されていないメッセージの場合、単一のメッセージはSフラグがクリアされ（値0）、サブメッセージ番号は0（ゼロ）に設定されます。
Length Length in octets of this message including headers and message body. If the message is fragmented, this field contains the length of this SubMessage. The Length is encoded as an SDNV.
ヘッダーとメッセージ本文を含む、このメッセージのオクテットの長さ。メッセージが断片化されている場合、このフィールドにはこのSubMessageの長さが含まれます。長さはSDNVとしてエンコードされます。
Message Body As specified in Section 4, the Message Body consists of a sequence of one or more of the TLVs specified in Section 4.2.
メッセージ本文セクション4で指定されているように、メッセージ本文はセクション4.2で指定された1つ以上のTLVのシーケンスで構成されています。
The protocol also requires extra information about the link that the underlying communication layer MUST provide. This information is used in the Hello procedure described in more detail in Section 5.2. Since this information is available from the underlying layer, there is no need to carry it in PRoPHET messages. The following values are defined to be provided by the underlying layer: Sender Local Address An address that is used by the underlying communication layer as described in Section 2.4 and identifies the sender address of the current message. This address must be unique among the nodes that can currently communicate, and it is only used in conjunction with the Receiver Local Address, Receiver Instance, and Sender Instance to identify a communicating pair of nodes.
プロトコルは、基礎となる通信層が提供しなければならないリンクに関する追加情報も必要とします。この情報は、セクション5.2で詳しく説明するHelloプロシージャで使用されます。この情報は基礎となる層から利用できるため、PRoPHETメッセージで伝達する必要はありません。次の値は、基礎となる層によって提供されるように定義されています。送信者ローカルアドレスセクション2.4で説明されている基礎となる通信層によって使用され、現在のメッセージの送信者アドレスを識別するアドレス。このアドレスは、現在通信できるノード間で一意である必要があり、通信するノードのペアを識別するために、Receiver Local Address、Receiver Instance、およびSender Instanceと組み合わせてのみ使用されます。
Receiver Local Address An address that is used by the underlying communication layer as described in Section 2.4 and identifies the receiver address of the current message. This address must be unique among the nodes that can currently communicate, and is only used in conjunction with the Sender Local Address, Receiver Instance, and Sender Instance to identify a communicating pair of nodes.
レシーバーローカルアドレス2.4で説明されているように、基礎となる通信層によって使用され、現在のメッセージのレシーバーアドレスを識別するアドレス。このアドレスは、現在通信可能なノード間で一意である必要があり、送信側ローカルアドレス、受信側インスタンス、および送信側インスタンスと組み合わせてのみ使用して、通信しているノードのペアを識別します。
When PRoPHET is run over TCP, the IP addresses of the communicating nodes are used as Sender and Receiver Local Addresses.
PRoPHETがTCPを介して実行される場合、通信ノードのIPアドレスは送信側および受信側ローカルアドレスとして使用されます。
All TLVs have the following format, and can be nested.
すべてのTLVは次の形式であり、ネストすることができます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type | TLV Flags | TLV Length (SDNV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLV Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: TLV Format
図6：TLVフォーマット
TLV Type Specific TLVs are defined in Section 4.3. The TLV Type is encoded as an 8-bit unsigned integer in network bit order. Each TLV will have fields defined that are specific to the function of that TLV.
TLVタイプ固有のTLVはセクション4.3で定義されています。 TLVタイプは、ネットワークビットオーダーの8ビット符号なし整数としてエンコードされます。各TLVには、そのTLVの機能に固有のフィールドが定義されています。
TLV Flags These are defined per TLV type. Flag n corresponds to bit 15-n in the TLV. Any flags that are specified as reserved in specific TLVs SHOULD be transmitted as 0 and ignored on receipt.
TLVフラグこれらはTLVタイプごとに定義されます。フラグnは、TLVのビット15-nに対応します。特定のTLVで予約済みとして指定されているフラグは、0として送信され、受信時に無視される必要があります（SHOULD）。
TLV Length Length of the TLV in octets, including the TLV header and any nested TLVs. Encoded as an SDNV. Note that TLVs are not padded to any specific alignment unless explicitly required in the description of the TLV. No TLVs in this document specify any padding.
TLV長さオクテット単位のTLVの長さ。TLVヘッダーとネストされたTLVを含みます。 SDNVとしてエンコードされます。 TLVの説明で明示的に要求されない限り、TLVは特定の配置にパディングされないことに注意してください。このドキュメントのTLVでは、パディングを指定していません。
This section describes the various TLVs that can be used in PRoPHET messages.
このセクションでは、PRoPHETメッセージで使用できるさまざまなTLVについて説明します。
The Hello TLV is used to set up and maintain a link between two PRoPHET nodes. Hello messages with the SYN function are transmitted periodically as beacons or keep-alives. The Hello TLV is the first TLV exchanged between two PRoPHET nodes when they encounter each other. No other TLVs can be exchanged until the first Hello sequence is completed.
Hello TLVは、2つのPRoPHETノード間のリンクを設定および維持するために使用されます。 SYN機能を備えたHelloメッセージは、ビーコンまたはキープアライブとして定期的に送信されます。 Hello TLVは、2つのPRoPHETノードが互いに遭遇したときに交換される最初のTLVです。最初のHelloシーケンスが完了するまで、他のTLVは交換できません。
Once a communication link is established between two PRoPHET nodes, the Hello TLV will be sent once for each interval as defined in the interval timer. If a node experiences the lapse of HELLO_DEAD Hello intervals without receiving a Hello TLV on a connection in the INFO_EXCH state (as defined in the state machine in Section 5.1), the connection SHOULD be assumed broken.
2つのPRoPHETノード間で通信リンクが確立されると、Hello TLVは、間隔タイマーで定義されている間隔ごとに1回送信されます。ノードがINFO_EXCH状態（セクション5.1のステートマシンで定義）の接続でHello TLVを受信せずにHELLO_DEAD Hello間隔の経過を経験する場合、接続は切断されていると想定する必要があります（SHOULD）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type=0x01 |L| Resv | HF | TLV Length (SDNV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timer (SDNV) |EID Length,SDNV| Sender EID (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Hello TLV Format
図7：Hello TLVフォーマット
TLV Flags The TLV Flags field contains two 1-bit flags (S and L) and a 3-bit Hello Function (HF) number that specifies one of four functions for the Hello TLV. The remaining 3 bits (Resv) are unused and reserved: HF TLV Flags bits 0, 1, and 2 are treated as an unsigned 3-bit integer coded in network bit order. The value of the integer specifies the Hello Function (HF) of the Hello TLV. Four functions are specified for the Hello TLV.
TLVフラグTLVフラグフィールドには、2つの1ビットフラグ（SおよびL）と、Hello TLVの4つの機能の1つを指定する3ビットのHello機能（HF）番号が含まれています。残りの3ビット（Resv）は未使用で予約されています。HFTLVフラグビット0、1、および2は、ネットワークビットオーダーでコード化された符号なし3ビット整数として扱われます。整数の値は、Hello TLVのHello機能（HF）を指定します。 Hello TLVには4つの関数が指定されています。
The encoding of the Hello Function is:
Hello関数のエンコーディングは次のとおりです。
SYN: HF = 1
SYNACK: HF = 2
ACK: HF = 3
RSTACK: HF = 4
The remaining values (0, 5, 6 and 7) are unused and reserved. If a Hello TLV with any of these values is received, the link should be reset.
残りの値（0、5、6、7）は未使用で、予約されています。これらの値のいずれかを持つHello TLVを受信した場合、リンクをリセットする必要があります。
Resv TLV Flags bits 3, 4, 5, and 6 are reserved. They SHOULD be set to 0 on transmission and ignored on reception.
Resv TLVフラグビット3、4、5、および6は予約されています。送信時には0に設定され、受信時には無視されるべきです（SHOULD）。
L The L bit flag (TLV Flags bit 7) is set (value 1) to request that the Bundle Offer TLV sent during the Information Exchange Phase contains bundle payload lengths for all bundles, rather than only for bundle fragments as when the L flag is cleared (value 0), when carried in a Hello TLV with Hello Function SYN or SYNACK. The flag is ignored for other Hello Function values.
L Lビットフラグ（TLVフラグビット7）が設定され（値1）、情報交換フェーズ中に送信されたバンドルオファーTLVに、Lフラグの場合のようにバンドルフラグメントだけではなく、すべてのバンドルのバンドルペイロード長が含まれるように要求します。クリア（値0）、Hello関数SYNまたはSYNACKを備えたHello TLVで実行された場合。他のHello Function値の場合、フラグは無視されます。
TLV Data
TLVデータ
Timer The Timer field is used to inform the receiver of the timer value used in the Hello processing of the sender. The timer specifies the nominal time between periodic Hello messages. It is a constant for the duration of a session. The timer field is specified in units of 100 ms and is encoded as an SDNV.
Timer Timerフィールドは、送信者のHello処理で使用されるタイマー値を受信者に通知するために使用されます。タイマーは、定期的なHelloメッセージ間の公称時間を指定します。セッションの期間中は一定です。タイマーフィールドは100ミリ秒単位で指定され、SDNVとしてエンコードされます。
EID Length The EID Length field is used to specify the length of the Sender EID field in octets. If the Endpoint Identifier (EID) has already been sent at least once in a message with the current Sender Instance, a node MAY choose to set this field to zero, omitting the Sender EID from the Hello TLV. The EID Length is encoded as an SDNV, and the field is thus of variable length.
EIDの長さEIDの長さフィールドは、送信者EIDフィールドの長さをオクテットで指定するために使用されます。エンドポイント識別子（EID）が現在の送信者インスタンスのメッセージで少なくとも1回はすでに送信されている場合、ノードはこのフィールドをゼロに設定して、Hello TLVから送信者EIDを省略してもよい（MAY）。 EID長はSDNVとしてエンコードされるため、フィールドは可変長になります。
Sender EID The Sender EID field specifies the DTN endpoint identifier (EID) of the sender that is to be used in updating routing information and making forwarding decisions. If a node has multiple EIDs, one should be chosen for PRoPHET routing. This field is of variable length.
Sender EID Sender EIDフィールドは、ルーティング情報の更新と転送の決定に使用される送信者のDTNエンドポイント識別子（EID）を指定します。ノードに複数のEIDがある場合は、PRoPHETルーティングに1つを選択する必要があります。このフィールドは可変長です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV type=0x02 | TLV Flags | TLV Length (SDNV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLV Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Error TLV Format
図8：エラーTLV形式
TLV Flags For Error TLVs, the TLV Flags field carries an identifier for the Error TLV type as an 8-bit unsigned integer encoded in network bit order. A range of values is available for private and experimental use in addition to the values defined here. The following Error TLV types are defined:
TLVフラグエラーTLVの場合、TLVフラグフィールドには、ネットワークビットオーダーでエンコードされた8ビットの符号なし整数としてエラーTLVタイプの識別子が含まれます。ここで定義されている値に加えて、さまざまな値をプライベートおよび実験的に使用できます。次のエラーTLVタイプが定義されています。
Dictionary Conflict 0x00 Bad String ID 0x01 Reserved 0x02 - 0x7F Private/Experimental Use 0x80 - 0xFF
辞書の競合0x00不正な文字列ID 0x01予約済み0x02-0x7Fプライベート/実験的使用0x80-0xFF
TLV Data The contents and interpretation of the TLV Data field are specific to the type of Error TLV. For the Error TLVs defined in this document, the TLV Data is defined as follows:
TLVデータTLVデータフィールドの内容と解釈は、エラーTLVのタイプに固有です。このドキュメントで定義されているエラーTLVの場合、TLVデータは次のように定義されます。
Dictionary Conflict The TLV Data consists of the String ID that is causing the conflict encoded as an SDNV followed by the EID string that conflicts with the previously installed value. The Endpoint Identifier is NOT null terminated. The length of the EID can be determined by subtracting the length of the TLV Header and the length of the SDNV containing the String ID from the TLV Length.
辞書の競合TLVデータは、SDNVとしてエンコードされて競合を引き起こしている文字列IDと、その後に以前にインストールされた値と競合するEID文字列で構成されます。エンドポイント識別子はnullで終了していません。 EIDの長さは、TLVの長さからTLVヘッダーの長さと文字列IDを含むSDNVの長さを引くことによって決定できます。
Bad String ID The TLV Data consists of the String ID that is not found in the dictionary encoded as an SDNV.
不正な文字列ID TLVデータは、SDNVとしてエンコードされた辞書にない文字列IDで構成されています。
The Routing Information Base Dictionary includes the list of endpoint identifiers used in making routing decisions. The referents remain constant for the duration of a session over a link where the instance numbers remain the same and can be used by both the Routing Information Base messages and the bundle offer/response messages. The dictionary is a shared resource (see Section 3.2.1) built in each of the paired peers from the contents of one or more incoming TLVs of this type and from the information used to create outgoing TLVs of this type.
ルーティング情報ベースディクショナリには、ルーティングの決定に使用されるエンドポイント識別子のリストが含まれています。リファレントは、インスタンス番号が同じであるリンクを介したセッションの期間中一定のままであり、ルーティング情報ベースメッセージとバンドルオファー/レスポンスメッセージの両方で使用できます。ディクショナリは、このタイプの1つ以上の着信TLVのコンテンツと、このタイプの発信TLVを作成するために使用される情報から、ペアにされたピアのそれぞれに組み込まれた共有リソース（セクション3.2.1を参照）です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV type=0xA0 | TLV Flags | TLV Length (SDNV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RIBD Entry Count (SDNV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
~ Variable-Length Routing Address Strings ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Routing Address String 1 ~
〜ルーティングアドレス文字列1〜
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String ID 1 (SDNV) | Length (SDNV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Endpoint Identifier 1 (variable length) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
~ Routing Address String n . ~
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String ID n (SDNV) | Length (SDNV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Endpoint Identifier n (variable length) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Routing Information Base Dictionary TLV Format
図9：ルーティング情報ベースディクショナリTLV形式
TLV Flags The encoding of the Header flag field relates to the capabilities of the source node sending the RIB Dictionary:
TLVフラグヘッダーフラグフィールドのエンコーディングは、RIBディクショナリを送信するソースノードの機能に関連しています。
Flag 0: Sent by Listener 0b1 Flag 1: Reserved 0b1 Flag 2: Reserved 0b1 Flag 3: Unassigned 0b1 Flag 4: Unassigned 0b1 Flag 5: Unassigned 0b1 Flag 6: Unassigned 0b1 Flag 7: Unassigned 0b1
フラグ0：リスナーから送信0b1フラグ1：予約済み0b1フラグ2：予約済み0b1フラグ3：未割り当て0b1フラグ4：未割り当て0b1フラグ5：未割り当て0b1フラグ6：未割り当て0b1フラグ7：未割り当て0b1
The "Sent by Listener" flag is set to 0 if this TLV was sent by a node in the Initiator role and set to 1 if this TLV was sent by a node in the Listener role (see Section 3.2 for explanations of these roles).
「リスナーによる送信」フラグは、このTLVがイニシエーターの役割のノードによって送信された場合は0に設定され、このTLVがリスナーの役割のノードによって送信された場合は1に設定されます（これらの役割の説明については、セクション3.2を参照）。
TLV Data
TLVデータ
RIBD Entry Count Number of entries in the database. Encoded as SDNV.
RIBDエントリ数データベース内のエントリ数。 SDNVとしてエンコードされます。
String ID SDNV identifier that is constant for the duration of a session. String ID zero is predefined as the node that initiates the session through sending the Hello SYN message, and String ID one is predefined as the node that responds with the Hello SYNACK message. These entries do not need to be sent explicitly as the EIDs are exchanged during the Hello procedure.
文字列IDセッションの期間中一定であるSDNV識別子。文字列IDゼロは、Hello SYNメッセージの送信を通じてセッションを開始するノードとして事前定義されており、文字列ID 1は、Hello SYNACKメッセージで応答するノードとして事前定義されています。 EIDはHello手順中に交換されるため、これらのエントリを明示的に送信する必要はありません。
In order to ensure that the String IDs originated by the two peers do not conflict, the String IDs generated in the node that sent the Hello SYN message MUST have their least significant bit set to 0 (i.e., are even numbers), and the String IDs generated in the node that responded with the Hello SYNACK message MUST have their least significant bit set to 1 (i.e., they are odd numbers).
2つのピアから発信された文字列IDが競合しないようにするには、Hello SYNメッセージを送信したノードで生成された文字列IDの最下位ビットを0に設定する必要があります（つまり、偶数です）。 Hello SYNACKメッセージで応答したノードで生成されたIDは、最下位ビットが1に設定されている必要があります（つまり、奇数です）。
Length Length of Endpoint Identifier in this entry. Encoded as SDNV.
このエントリのエンドポイント識別子の長さ。 SDNVとしてエンコードされます。
Endpoint Identifier Text string representing the Endpoint Identifier. Note that it is NOT null terminated as the entry contains the length of the identifier.
エンドポイント識別子エンドポイント識別子を表すテキスト文字列。エントリには識別子の長さが含まれているため、ヌルで終了しないことに注意してください。
The Routing Information Base lists the destinations (endpoints) a node knows of and the delivery predictabilities it has associated with them. This information is needed by the PRoPHET algorithm to make decisions on routing and forwarding.
ルーティング情報ベースは、ノードが知っている宛先（エンドポイント）と、ノードがそれらに関連付けた配信予測可能性をリストします。この情報は、ルーティングと転送に関する決定を行うためにPRoPHETアルゴリズムで必要です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type=0xA1 | TLV Flags | TLV Length (SDNV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RIB String Count (SDNV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RIBD String ID 1 (SDNV) | P-value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RIB Flags 1 | . ~
+-+-+-+-+-+-+-+-+ . ~
~ . ~
~ . ~
~ . ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RIBD String ID n (SDNV) | P-value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RIB Flags n |
+-+-+-+-+-+-+-+-+
Figure 10: Routing Information Base TLV Format
図10：ルーティング情報ベースTLV形式
TLV Flags The encoding of the Header flag field relates to the capabilities of the Source node sending the RIB:
TLVフラグヘッダーフラグフィールドのエンコーディングは、RIBを送信する送信元ノードの機能に関連しています。
Flag 0: More RIB TLVs 0b1 Flag 1: Reserved 0b1 Flag 2: Reserved 0b1 Flag 3: Unassigned 0b1 Flag 4: Unassigned 0b1 Flag 5: Unassigned 0b1 Flag 6: Unassigned 0b1 Flag 7: Unassigned 0b1
フラグ0：その他のRIB TLV 0b1フラグ1：予約済み0b1フラグ2：予約済み0b1フラグ3：未割り当て0b1フラグ4：未割り当て0b1フラグ5：未割り当て0b1フラグ6：未割り当て0b1フラグ7：未割り当て0b1
The "More RIB TLVs" flag is set to 1 if the RIB requires more TLVs to be sent in order to be fully transferred. This flag is set to 0 if this is the final TLV of this RIB.
RIBが完全に転送されるために送信するTLVがさらに必要な場合、「More RIB TLVs」フラグは1に設定されます。これがこのRIBの最後のTLVである場合、このフラグは0に設定されます。
TLV Data
TLVデータ
RIB String Count Number of routing entries in the TLV. Encoded as an SDNV.
RIB String Count TLVのルーティングエントリの数。 SDNVとしてエンコードされます。
RIBD String ID String ID of the endpoint identifier of the destination for which this entry specifies the delivery predictability as predefined in a dictionary TLV. Encoded as an SDNV.
RIBD文字列IDこのエントリがディクショナリTLVで事前定義された配信予測可能性を指定する宛先のエンドポイントIDの文字列ID。 SDNVとしてエンコードされます。
P-value Delivery predictability for the destination of this entry as calculated from previous encounters according to the equations in Section 2.1.2, encoded as a 16-bit unsigned integer. The encoding of this field is a linear mapping from [0,1] to [0, 0xFFFF] (e.g., for a P-value of 0.75, the mapping would be 0.75*65535=49151=0xBFFF; thus, the P-value would be encoded as 0xBFFF).
セクション2.1.2の方程式に従って以前の遭遇から計算された、このエントリの宛先のP値配信の予測可能性。16ビットの符号なし整数としてエンコードされます。このフィールドのエンコーディングは、[0,1]から[0、0xFFFF]までの線形マッピングです（たとえば、P値が0.75の場合、マッピングは0.75 * 65535 = 49151 = 0xBFFFになるため、P値は0xBFFFとしてエンコードされます）。
RIB Flag The encoding of the 8-bit RIB Flag field is:
RIBフラグ8ビットRIBフラグフィールドのエンコーディングは次のとおりです。
Flag 0: Unassigned 0b1 Flag 1: Unassigned 0b1 Flag 2: Unassigned 0b1 Flag 3: Unassigned 0b1 Flag 4: Unassigned 0b1 Flag 5: Unassigned 0b1 Flag 6: Unassigned 0b1 Flag 7: Unassigned 0b1
フラグ0：未割り当て0b1フラグ1：未割り当て0b1フラグ2：未割り当て0b1フラグ3：未割り当て0b1フラグ4：未割り当て0b1フラグ5：未割り当て0b1フラグ6：未割り当て0b1フラグ7：未割り当て0b1
After the routing information has been passed, the node will ask the other node to review available bundles and determine which bundles it will accept for relay. The source relay will determine which bundles to offer based on relative delivery predictabilities as explained in Section 3.6.
ルーティング情報が渡された後、ノードは他のノードに利用可能なバンドルを確認して、リレー用に受け入れるバンドルを決定するように要求します。ソースリレーは、セクション3.6で説明するように、相対的な配信予測に基づいて、提供するバンドルを決定します。
Note: The original versions of these TLVs (TLV Types 0xA2 and 0xA3) used in version 1 of the PRoPHET protocol have been deprecated, as they did not contain the complete information needed to uniquely identify bundles and could not handle bundle fragments.
注：PRoPHETプロトコルのバージョン1で使用されていたこれらのTLV（TLVタイプ0xA2および0xA3）の元のバージョンには、バンドルを一意に識別するために必要な完全な情報が含まれておらず、バンドルフラグメントを処理できなかったため、非推奨になりました。
Depending on the bundles stored in the offering node, the Bundle Offer TLV might contain descriptions of both complete bundles and bundle fragments. In order to correctly identify bundle fragments, a bundle fragment descriptor MUST contain the offset of the payload fragment in the bundle payload and the length of the payload fragment. If requested by the receiving node by setting the L flag in the SYN or SYNACK message during the neighbor awareness phase, the offering node MUST include the length of the payload in the descriptor for complete bundles. The appropriate flags MUST be set in the B_flags for the descriptor to indicate if the descriptor contains the payload length field (set for fragments in all cases and for complete bundles if the L flag was set) and if the descriptor contains a payload offset field (fragments only).
オファリングノードに格納されているバンドルによっては、バンドルオファーTLVに完全なバンドルとバンドルフラグメントの両方の説明が含まれている場合があります。バンドルフラグメントを正しく識別するために、バンドルフラグメント記述子には、バンドルペイロード内のペイロードフラグメントのオフセットとペイロードフラグメントの長さが含まれている必要があります。ネイバー認識フェーズ中にSYNまたはSYNACKメッセージでLフラグを設定することによって受信ノードによって要求された場合、提供ノードは完全なバンドルの記述子にペイロードの長さを含める必要があります。ディスクリプターのペイロード長フィールド（すべての場合にフラグメントに設定され、Lフラグが設定されている場合は完全なバンドルに設定される）とディスクリプターにペイロードオフセットフィールドが含まれるかどうかを示すために、適切なフラグをディスクリプターのB_flagsに設定する必要があります（フラグメントのみ）。
The Bundle Offer TLV also lists the bundles for which a PRoPHET acknowledgement has been issued. Those bundles have the PRoPHET ACK flag set in their entry in the list. When a node receives a PRoPHET ACK for a bundle, it SHOULD, if possible, signal to the bundle protocol agent that this bundle is no longer required for transmission by PRoPHET. Despite no longer transmitting the bundle, it SHOULD keep an entry for the acknowledged bundle to be able to further propagate the PRoPHET ACK.
バンドルオファーTLVには、PRoPHET確認応答が発行されたバンドルもリストされます。これらのバンドルでは、リストのエントリにPRoPHET ACKフラグが設定されています。ノードがバンドルのPRoPHET ACKを受信すると、可能であれば、このバンドルがPRoPHETによる送信に不要であることをバンドルプロトコルエージェントに通知する必要があります（SHOULD）。バンドルを送信しなくなったにもかかわらず、承認されたバンドルがPRoPHET ACKをさらに伝播できるようにエントリを保持する必要があります（SHOULD）。
The Response TLV format is identical to the Offer TLV with the exception of the TLV Type field. Bundles that are being accepted from the corresponding Offer are explicitly marked with a B_flag. Specifications for bundles that are not being accepted MAY either be omitted or left in but not marked as accepted. The payload length field MAY be omitted for complete bundles in the Response message even if it was included in the Offer message. The B_flags payload length flag MUST be set correctly to indicate if the length field is included or not. The Response message MUST include both payload offset and payload length fields for bundle fragments, and the B_flags MUST be set to indicate that both are present.
応答TLV形式は、TLVタイプフィールドを除いてオファーTLVと同じです。対応するオファーから受け入れられているバンドルは、B_flagで明示的にマークされます。受け入れられていないバンドルの仕様は、省略されるか、そのまま残されても受け入れられない場合があります。ペイロード長フィールドは、オファーメッセージに含まれていても、レスポンスメッセージの完全なバンドルでは省略される場合があります。 B_flagsペイロード長フラグは、長さフィールドが含まれているかどうかを示すために正しく設定する必要があります。応答メッセージには、バンドルフラグメントのペイロードオフセットフィールドとペイロード長フィールドの両方を含める必要があり、B_flagsを設定して、両方が存在することを示す必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type | TLV Flags | TLV Length (SDNV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bundle Offer Count (SDNV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| B_flags | Bundle Source | Bundle Destination |
| | String ID 1 (SDNV) | String ID 1 (SDNV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bundle 1 Creation Timestamp Time |
| (SDNV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bundle 1 Creation Timestamp Sequence Number |
| (SDNV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bundle 1 Payload Offset - only present if bundle is a fragment|
| (SDNV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bundle 1 Payload Length - only present if bundle is a fragment|
| or transmission of length requested (SDNV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ . ~
~ . ~
~ . ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| B_flags | Bundle Source | Bundle Destination |
| | String ID n (SDNV) | String ID n (SDNV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bundle n Creation Timestamp Time |
| (SDNV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bundle n Creation Timestamp Sequence Number |
| (SDNV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bundle n Payload Offset - only present if bundle is a fragment|
| (SDNV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bundle n Payload Length - only present if bundle is a fragment|
| or transmission of length requested (SDNV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Bundle Offer and Response TLV Format
図11：バンドルのオファーとレスポンスのTLV形式
TLV Type The TLV Type for a Bundle Offer is 0xA4. The TLV Type for a Bundle Response is 0xA5.
TLVタイプバンドルオファーのTLVタイプは0xA4です。バンドル応答のTLVタイプは0xA5です。
TLV Flags The encoding of the Header flag field relates to the capabilities of the source node sending the RIB:
TLVフラグヘッダーフラグフィールドのエンコーディングは、RIBを送信するソースノードの機能に関連しています。
Flag 0: More Offer/Response TLVs Following 0b1 Flag 1: Unassigned 0b1 Flag 2: Unassigned 0b1 Flag 3: Unassigned 0b1 Flag 4: Unassigned 0b1 Flag 5: Unassigned 0b1 Flag 6: Unassigned 0b1 Flag 7: Unassigned 0b1
フラグ0：0b1フラグに続くより多くのオファー/レスポンスTLVs 1：未割り当て0b1フラグ2：未割り当て0b1フラグ3：未割り当て0b1フラグ4：未割り当て0b1フラグ5：未割り当て0b1フラグ6：未割り当て0b1フラグ7：未割り当て0b1
If the Bundle Offers or Bundle Responses are divided between several TLVs, the "More Offer/Response TLVs Following" flag MUST be set to 1 in all but the last TLV in the sequence where it MUST be set to 0.
バンドルオファーまたはバンドルレスポンスがいくつかのTLVに分割されている場合、「More Offer / Response TLVs Following」フラグは、0に設定する必要があるシーケンスの最後のTLVを除いて、すべて1に設定する必要があります。
TLV Data
TLVデータ
Bundle Offer Count Number of bundle offer/response entries. Encoded as an SDNV. Note that 0 is an acceptable value. In particular, a Bundle Response TLV with 0 entries is used to signal that a cycle of information exchange and bundle passing is completed.
Bundle Offer Countバンドルオファー/レスポンスエントリの数。 SDNVとしてエンコードされます。 0は許容値です。特に、エントリが0のバンドル応答TLVは、情報交換とバンドル受け渡しのサイクルが完了したことを通知するために使用されます。
B Flags The encoding of the B Flags is:
BフラグBフラグのエンコードは次のとおりです。
Flag 0: Bundle Accepted 0b1 Flag 1: Bundle is a Fragment 0b1 Flag 2: Bundle Payload Length included in TLV 0b1 Flag 3: Unassigned 0b1 Flag 4: Unassigned 0b1 Flag 5: Unassigned 0b1 Flag 6: Unassigned 0b1 Flag 7: PRoPHET ACK 0b1
フラグ0：バンドル受け入れ済み0b1フラグ1：バンドルはフラグメント0b1フラグ2：TLVに含まれるバンドルペイロード長0b1フラグ3：未割り当て0b1フラグ4：未割り当て0b1フラグ5：未割り当て0b1フラグ6：未割り当て0b1フラグ7：PRoPHET ACK 0b1
Bundle Source String ID String ID of the source EID of the bundle as predefined in a dictionary TLV. Encoded as an SDNV.
バンドルソース文字列ID辞書TLVで事前定義されているバンドルのソースEIDの文字列ID。 SDNVとしてエンコードされます。
Bundle Destination String ID String ID of the destination EID of the bundle as predefined in a dictionary TLV. Encoded as an SDNV.
Bundle Destination String ID辞書TLVで事前定義されているバンドルの宛先EIDの文字列ID。 SDNVとしてエンコードされます。
Bundle Creation Timestamp Time Time component of the Bundle Creation Timestamp for the bundle. Encoded as an SDNV.
Bundle Creation Timestamp Timeバンドルのバンドル作成タイムスタンプの時間コンポーネント。 SDNVとしてエンコードされます。
Bundle Creation Timestamp Sequence Number Sequence Number component of the Bundle Creation Timestamp for the bundle. Encoded as an SDNV.
バンドル作成タイムスタンプシーケンス番号バンドルのバンドル作成タイムスタンプのシーケンス番号コンポーネント。 SDNVとしてエンコードされます。
Bundle Payload Offset Only included if the bundle is a fragment and the fragment bit is set (value 1) in the bundle B Flags. Offset of the start of the fragment payload in the complete bundle payload. Encoded as an SDNV.
バンドルペイロードオフセットバンドルがフラグメントであり、フラグメントビットがバンドルBフラグに設定されている（値1）場合にのみ含まれます。完全なバンドルペイロード内のフラグメントペイロードの開始のオフセット。 SDNVとしてエンコードされます。
Bundle Payload Length Only included if the bundle length included bit is set (value 1) in the bundle B Flags. Length of the payload in the bundle specified. This is either the total payload length if the bundle is a complete bundle or the bundle fragment payload length if the bundle is a fragment. Encoded as an SDNV.
バンドルペイロード長バンドル長を含むビットがバンドルBフラグで設定されている場合（値1）にのみ含まれます。指定されたバンドル内のペイロードの長さ。これは、バンドルが完全なバンドルの場合はペイロードの全長、またはバンドルがフラグメントの場合はフラグメントのペイロード長です。 SDNVとしてエンコードされます。
In this section, some more details on the operation of PRoPHET are given along with state tables to help in implementing the protocol.
このセクションでは、プロトコルの実装に役立つように、PRoPHETの操作に関するいくつかの詳細を状態テーブルとともに示します。
As explained in Section 1.2, it is RECOMMENDED that "Success" responses should not be requested or sent when operating over a reliable, in-order transport protocol such as TCP. If in the future PRoPHET were operated over an unreliable transport protocol, positive acknowledgements would be necessary to signal successful delivery of (sub)messages. In this section, the phrase "send a message" should be read as *successful* sending of a message, signaled by receipt of the appropriate "Success" response if running over an unreliable protocol, but guaranteed by TCP or another reliable protocol otherwise. Hence, the state descriptions below do not explicitly mention positive acknowledgements, whether they are being sent or not.
セクション1.2で説明したように、TCPなどの信頼性の高い順序のトランスポートプロトコルで動作している場合は、「成功」応答を要求または送信しないことをお勧めします。将来的にPRoPHETが信頼性の低いトランスポートプロトコルで運用された場合、（サブ）メッセージの配信が成功したことを知らせるには肯定的な確認応答が必要になります。このセクションでは、「メッセージの送信」というフレーズは、メッセージの*成功*として解釈されるべきであり、信頼性の低いプロトコルで実行されている場合は適切な「成功」応答の受信によって通知されますが、それ以外の場合はTCPまたは別の信頼できるプロトコルによって保証されます。したがって、以下の状態の説明では、送信されているかどうかにかかわらず、肯定的な確認を明示的に述べていません。
This section gives high-level state tables for the operation of PRoPHET. The following sections will describe each part of the operation in more detail (including state tables for the internal states of those procedures).
このセクションでは、PRoPHETの操作に関する高レベルの状態テーブルを示します。次のセクションでは、操作の各部分について詳しく説明します（これらの手順の内部状態の状態テーブルを含む）。
The following main or high-level states are used in the state tables:
状態テーブルでは、次のメインまたは高レベルの状態が使用されます。
WAIT_NB This is the state all nodes start in. Nodes remain in this state until they are notified that a new neighbor is available. At that point, the Hello procedure should be started with the new neighbor, and the node transitions into the HELLO state. Nodes SHOULD be able to handle multiple neighbors in parallel, maintaining separate state machines for each neighbor. This could be handled by creating a new thread or process during the transition to the HELLO state that then takes care of the communication with the new neighbor while the parent remains in state WAIT_NB waiting for additional neighbors to communicate. In this case, when the neighbor can no longer be communicated with (described as "Neighbor Gone" in the tables below), the thread or process created is destroyed and, when a connection-oriented protocol is being used to communicate with the neighbor, the connection is closed. The current version of the protocol is specified to use TCP for neighbor connections so that these will be closed when the neighbor is no longer accessible.
WAIT_NBこれは、すべてのノードが開始する状態です。ノードは、新しいネイバーが利用可能であることが通知されるまで、この状態のままです。その時点で、Helloプロシージャが新しいネイバーで開始され、ノードがHELLO状態に移行します。ノードは、複数のネイバーを並行して処理し、各ネイバーの状態マシンを個別に維持できる必要があります（SHOULD）。これは、HELLO状態への移行中に新しいスレッドまたはプロセスを作成することによって処理できます。これにより、親がWAIT_NBの状態のまま、追加のネイバーの通信を待機しながら、新しいネイバーとの通信を処理します。この場合、ネイバーと通信できなくなると（下の表では「ネイバーゴーン」と記載）、作成されたスレッドまたはプロセスが破棄され、ネイバーとの通信にコネクション型プロトコルが使用されている場合、接続が閉じています。現在のバージョンのプロトコルは、ネイバー接続にTCPを使用するように指定されているため、ネイバーにアクセスできなくなったときにこれらのプロトコルは閉じられます。
HELLO Nodes are in the HELLO state from when a new neighbor is detected until the Hello procedure is completed and a link is established (which happens when the Hello procedure enters the ESTAB state as described in Section 5.2; during this procedure, the states ESTAB, SYNSENT, and SYNRCVD will be used, but these are internal to the Hello procedure and are not listed here). If the node is notified that the neighbor is no longer in range before a link has been established, it returns to the WAIT_NB state, and, if appropriate, any additional process or thread created to handle the neighbor MAY be destroyed.
HELLOノードは、新しいネイバーが検出されてから、Helloプロシージャが完了してリンクが確立されるまで、HELLO状態にあります（これは、Helloプロシージャがセクション5.2で説明されているESTAB状態に入ったときに発生します。この手順の間、状態はESTAB、 SYNSENTおよびSYNRCVDが使用されますが、これらはHelloプロシージャの内部にあり、ここにはリストされていません。リンクが確立される前にノードが近隣が範囲外になったことが通知された場合、ノードはWAIT_NB状態に戻り、適切な場合、近隣を処理するために作成された追加のプロセスまたはスレッドは破棄される場合があります。
INFO_EXCH After a link has been set up by the Hello procedure, the node transitions to the INFO_EXCH state in which the Information Exchange Phase is done. The node remains in this state as long as Information Exchange Phase TLVs (Routing RIB, Routing RIB Dictionary, Bundle Offer, Bundle Response) are being received. If the node is notified that the neighbor is no longer in range before all information and bundles have been exchanged, any associated connection is closed and the node returns to the WAIT_NB state to await new neighbors. The Timer(keep_alive) is used to ensure that the connection remains active.
INFO_EXCH Helloプロシージャによってリンクが設定された後、ノードはINFO_EXCH状態に移行し、情報交換フェーズが実行されます。ノードは、情報交換フェーズTLV（ルーティングRIB、ルーティングRIBディクショナリ、バンドルオファー、バンドルレスポンス）が受信されている限り、この状態のままです。すべての情報とバンドルが交換される前にノードが近隣に到達しなくなったことをノードに通知すると、関連する接続はすべて閉じられ、ノードはWAIT_NB状態に戻り、新しい近隣を待機します。 Timer（keep_alive）は、接続がアクティブなままであることを確認するために使用されます。
In the INFO_EXCH state, the nodes at both ends of the established link are able to update their delivery predictability information using data from the connected peer and then make offers of bundles for exchange which may be accepted or not by the peer. To manage these processes, each node acts both as an Initiator and a Listener for the Information Exchange Phase processes, maintaining subsidiary state machines for the two roles. The Initiator and Listener terms refer to the sending of the Routing RIB information: it is perhaps counterintuitive that the Listener becomes the bundle offeror and the Initiator the bundle acceptor during the bundling passing part.
INFO_EXCH状態では、確立されたリンクの両端のノードは、接続されたピアからのデータを使用して配信予測可能性情報を更新し、ピアによって受け入れられるかどうかにかかわらず、交換のためのバンドルを提供できます。これらのプロセスを管理するために、各ノードは情報交換フェーズプロセスのイニシエーターとリスナーの両方として機能し、2つの役割の補助的な状態マシンを維持します。イニシエーターとリスナーの用語は、ルーティングRIB情報の送信を指します。バンドルの通過部分で、リスナーがバンドルの提供者になり、イニシエーターがバンドルの受け入れ者になることは、おそらく直観に反します。
The protocol is designed so that the two exchanges MAY be carried out independently but concurrently, with the messages multiplexed onto on a single bidirectional link (such as is provided by the TCP connection). Alternatively, the exchanges MAY be carried out partially or wholly sequentially if appropriate for the implementation. The Information Exchange Phase is explained in more detail in Section 3.2.
プロトコルは、2つの交換が独立して同時に実行されるように設計されており、メッセージは単一の双方向リンク（TCP接続によって提供されるものなど）に多重化されます。あるいは、交換は、実装に適切であれば、部分的または全体的に順次実行される場合があります。情報交換フェーズについては、セクション3.2で詳しく説明します。
When an empty Bundle Response TLV (i.e., no more bundles to send) is received, the node starts the Timer(next_exchange). When this timer expires, assuming that the neighbor is still connected, the Initiator reruns the Information Exchange Phase. If there is only one neighbor connected at this time, this will have the effect of further increasing the delivery predictability for this node in the neighbor, and changing the delivery predictabilities as a result of the transitive property (Equation 3). If there is more than one neighbor connected or other communication opportunities have happened since the previous information exchange occurred, then the changes resulting from these other encounters will be passed on to the connected neighbor. The next_exchange timer is restarted once the information exchange has completed again.
空のBundle Response TLV（つまり、送信するバンドルがなくなる）を受信すると、ノードはTimer（next_exchange）を開始します。このタイマーが期限切れになると、ネイバーがまだ接続されていると想定して、イニシエーターは情報交換フェーズを再実行します。この時点で接続されているネイバーが1つだけの場合、これにより、ネイバー内のこのノードの配信予測可能性がさらに向上し、推移的プロパティの結果として配信予測可能性が変更されます（式3）。複数のネイバーが接続されているか、以前の情報交換が行われてから他の通信機会が発生した場合、これらの他の遭遇による変更は、接続されたネイバーに渡されます。情報交換が再び完了すると、next_exchangeタイマーが再開されます。
If one or more new bundles are received by this node while waiting for the Timer(next_exchange) to expire and the delivery predictabilities indicate that it would be appropriate to forward some or all of the bundles to the connected node, the bundles SHOULD be immediately offered to the connected neighbor and transferred if accepted.
タイマー（next_exchange）の期限が切れるのを待っている間に1つ以上の新しいバンドルがこのノードによって受信され、配信の予測可能性により、一部またはすべてのバンドルを接続されたノードに転送することが適切であることが示された場合、バンドルはすぐに提供される必要があります（SHOULD）接続されたネイバーに送信され、受け入れられた場合は転送されます。
State: WAIT_NB
状態：WAIT_NB
+==================================================================+
| Condition | Action | New State |
+==================+===================================+===========+
| New Neighbor | Start Hello procedure for neighbor| HELLO |
| | Keep waiting for more neighbors | WAIT_NB |
+==================================================================+
State: HELLO
状態：ハロー
+==================================================================+
| Condition | Action | New State |
+==================+===================================+===========+
| Hello TLV rcvd | | HELLO |
+------------------+-----------------------------------+-----------+
| Enter ESTAB state| Start Information Exchange Phase | INFO_EXCH |
+------------------+-----------------------------------+-----------+
| Neighbor Gone | | WAIT_NB |
+==================================================================+
State: INFO_EXCH
状態：INFO_EXCH
+==================================================================+
| Condition | Action | New State |
+==================+===================================+===========+
| On entry | Start Timer(keep-alive) | |
| | Uses Hello Timer interval | INFO_EXCH |
+------------------+-----------------------------------+-----------+
|Info Exch TLV rcvd| (processed by subsidiary state | |
| | machines) | INFO_EXCH |
+------------------+-----------------------------------+-----------+
| No more bundles | Start Timer(next_exchange) | INFO_EXCH |
+------------------+-----------------------------------+-----------+
| Keep-alive expiry| Send Hello SYN message | INFO_EXCH |
+------------------+-----------------------------------+-----------+
| Hello SYN rcvd | Record reception | |
| | Restart Timer(keep-alive) | INFO_EXCH |
+------------------+-----------------------------------+-----------+
| Neighbor Gone | | WAIT_NB |
+==================================================================+
The keep-alive messages (messages with Hello SYN TLV) are processed by the high-level state machine in the INFO_EXCH state. All other messages are delegated to the subsidiary state machines of the Information Exchange Phase described in Section 5.3. The receipt of keep-alive messages is recorded and may be used by the subsidiary machines to check if the peer is still functioning. The connection will be aborted (as described in Section 4.3.1) if several keep-alive messages are not received.
キープアライブメッセージ（Hello SYN TLVのメッセージ）は、INFO_EXCH状態の高レベルステートマシンによって処理されます。他のすべてのメッセージは、セクション5.3で説明されている情報交換フェーズの補助的な状態マシンに委任されます。キープアライブメッセージの受信が記録され、ピアマシンがまだ機能しているかどうかを確認するために、補助マシンによって使用される場合があります。いくつかのキープアライブメッセージが受信されない場合、接続は（セクション4.3.1で説明されているように）中止されます。
The Hello procedure is described by the following rules and state tables. In this section, the messages sent consist of the PRoPHET header and a single Hello TLV (see Figure 4 and Section 4.3.1) with the HF (Hello Function) field set to the specified value (SYN, SYNACK, ACK or RSTACK).
Helloプロシージャは、次のルールと状態テーブルによって記述されます。このセクションでは、送信されるメッセージは、PRoPHETヘッダーと単一のHello TLV（図4およびセクション4.3.1を参照）で構成され、HF（Hello Function）フィールドが指定された値（SYN、SYNACK、ACKまたはRSTACK）に設定されます。
The state of the L flag in the latest SYN or SYNACK message is recorded in the node that receives the message. If the L flag is set (value 1), the receiving node MUST send the payload length for each bundle that it offers to the peer during the Information Exchange Phase.
最新のSYNまたはSYNACKメッセージのLフラグの状態は、メッセージを受信するノードに記録されます。 Lフラグが設定されている場合（値1）、受信ノードは、情報交換フェーズ中にピアに提供する各バンドルのペイロード長を送信する必要があります。
The rules and state tables use the following operations:
ルールと状態テーブルは、次の操作を使用します。
o The "Update Peer Verifier" operation is defined as storing the values of the Sender Instance and Sender Local Address fields from a Hello SYN or Hello SYNACK function message received from the entity at the far end of the link.
o 「Update Peer Verifier」操作は、リンクの遠端にあるエンティティから受信したHello SYNまたはHello SYNACK機能メッセージのSender InstanceおよびSender Local Addressフィールドの値を格納することと定義されています。
o The procedure "Reset the link" is defined as:
o 手順「リンクのリセット」は次のように定義されています。
When using TCP or other reliable connection-oriented transport: Close the connection and terminate any separate thread or process managing the connection.
TCPまたはその他の信頼性の高い接続指向のトランスポートを使用する場合：接続を閉じ、接続を管理している別のスレッドまたはプロセスを終了します。
Otherwise:
さもないと：
1. Generate a new instance number for the link.
1. リンクの新しいインスタンス番号を生成します。
2. Delete the peer verifier (set to zero the values of Sender Instance and Sender Local Address previously stored by the Update Peer Verifier operation).
2. ピア検証を削除します（ピア検証の更新操作で以前に保存された送信者インスタンスと送信者ローカルアドレスの値をゼロに設定します）。
3. Send a SYN message.
3. SYNメッセージを送信します。
4. Transition to the SYNSENT state.
4. SYNSENT状態に遷移します。
o The state tables use the following Boolean terms and operators:
o 状態テーブルは、次のブール用語と演算子を使用します。
A The Sender Instance in the incoming message matches the value stored from a previous message by the "Update Peer Verifier" operation.
A受信メッセージの送信者インスタンスは、「ピア検証を更新」操作によって前のメッセージから保存された値と一致します。
B The Sender Instance and Sender Local Address fields in the incoming message match the values stored from a previous message by the "Update Peer Verifier" operation.
B受信メッセージの[送信者インスタンス]および[送信者ローカルアドレス]フィールドは、 "Update Peer Verifier"操作によって前のメッセージから保存された値と一致します。
C The Receiver Instance and Receiver Local Address fields in the incoming message match the values of the Sender Instance and Sender Local Address used in outgoing Hello SYN, Hello SYNACK, and Hello ACK messages.
C受信メッセージの受信者インスタンスおよび受信者ローカルアドレスフィールドは、送信Hello SYN、Hello SYNACK、およびHello ACKメッセージで使用される送信者インスタンスおよび送信者ローカルアドレスの値と一致します。
SYN A Hello SYN message has been received.
SYN Hello SYNメッセージを受信しました。
SYNACK A Hello SYNACK message has been received.
SYNACK Hello SYNACKメッセージを受信しました。
ACK A Hello ACK message has been received.
ACK Hello ACKメッセージが受信されました。
&& Represents the logical AND operation
&&は論理AND演算を表します
|| Represents the logical OR operation
||論理OR演算を表します
! Represents the logical negation (NOT) operation.
！論理否定（NOT）操作を表します。
o A timer is required for the periodic generation of Hello SYN, Hello SYNACK, and Hello ACK messages. The value of the timer is announced in the Timer field. To avoid synchronization effects, uniformly distributed random jitter of +/-5% of the Timer field SHOULD be added to the actual interval used for the timer.
o Hello SYN、Hello SYNACK、およびHello ACKメッセージの定期的な生成にはタイマーが必要です。タイマーの値は、Timerフィールドで通知されます。同期効果を回避するために、タイマーに使用される実際の間隔に、タイマーフィールドの+/- 5％の均一に分散されたランダムジッターを追加する必要があります（SHOULD）。
There are two independent events: the timer expires, and a packet arrives. The processing rules for these events are:
2つの独立したイベントがあります。タイマーが期限切れになり、パケットが到着します。これらのイベントの処理規則は次のとおりです。
Timer Expires: Reset Timer If state = SYNSENT Send SYN message If state = SYNRCVD Send SYNACK message If state = ESTAB Send ACK message
タイマーの期限切れ：タイマーのリセット状態= SYNSENTの場合SYNメッセージを送信状態= SYNRCVDの場合SYNACKメッセージを送信状態= ESTABの場合ACKメッセージを送信
Packet Arrives: If incoming message is an RSTACK message: If (A && C && !SYNSENT) Reset the link Else discard the message. If incoming message is a SYN, SYNACK, or ACK message: Response defined by the following State Tables. If incoming message is any other PRoPHET TLV and state != ESTAB: Discard incoming message. If state = SYNSENT Send SYN message(Note 1) If state = SYNRCVD Send SYNACK message(Note 1)
パケットの到着：着信メッセージがRSTACKメッセージの場合：If（A && C &&！SYNSENT）リンクをリセットします。そうでない場合、メッセージを破棄します。着信メッセージがSYN、SYNACK、またはACKメッセージの場合：以下の状態テーブルによって定義される応答。着信メッセージが他のPRoPHET TLVであり、状態が！= ESTABの場合：着信メッセージを破棄します。状態= SYNSENTの場合SYNメッセージを送信（注1）状態= SYNRCVDの場合SYNACKメッセージを送信（注1）
Note 1: No more than two SYN or SYNACK messages should be sent within any time period of length defined by the timer.
注1：タイマーで定義された期間内に送信できるSYNまたはSYNACKメッセージは2つまでです。
o A connection across a link is considered to be achieved when the protocol reaches the ESTAB state. All TLVs, other than Hello TLVs, that are received before synchronization is achieved will be discarded.
o リンクを介した接続は、プロトコルがESTAB状態に達したときに達成されたと見なされます。同期が達成される前に受信されたHello TLV以外のすべてのTLVは破棄されます。
State: SYNSENT
状態：SYNSENT
+==================================================================+
| Condition | Action | New State |
+==================+===================================+===========+
| SYNACK && C | Update Peer Verifier; | ESTAB |
| | Send ACK message | |
+------------------+-----------------------------------+-----------+
| SYNACK && !C | Send RSTACK message | SYNSENT |
+------------------+-----------------------------------+-----------+
| SYN | Update Peer Verifier; | SYNRCVD |
| | Send SYNACK message | |
+------------------+-----------------------------------+-----------+
| ACK | Send RSTACK message | SYNSENT |
+==================================================================+
State: SYNRCVD
+==================================================================+
| Condition | Action | New State |
+==================+===================================+===========+
| SYNACK && C | Update Peer Verifier; | ESTAB |
| | Send ACK message | |
+------------------+-----------------------------------+-----------+
| SYNACK && !C | Send RSTACK message | SYNRCVD |
+------------------+-----------------------------------+-----------+
| SYN | Update Peer Verifier; | SYNRCVD |
| | Send SYNACK message | |
+------------------+-----------------------------------+-----------+
| ACK && B && C | Send ACK message | ESTAB |
+------------------+-----------------------------------+-----------+
| ACK && !(B && C) | Send RSTACK message | SYNRCVD |
+==================================================================+
State: ESTAB
状態：ESTAB
+==================================================================+
| Condition | Action | New State |
+=================+====================================+===========+
| SYN || SYNACK | Send ACK message (notes 2 and 3) | ESTAB |
+-----------------+------------------------------------+-----------+
| ACK && B && C | Send ACK message (note 3) | ESTAB |
+-----------------+------------------------------------+-----------+
| ACK && !(B && C)| Send RSTACK message | ESTAB |
+==================================================================+
Note 2: No more than two ACK messages should be sent within any time period of length defined by the timer. Thus, one ACK message MUST be sent every time the timer expires. In addition, one further ACK message may be sent between timer expirations if the incoming message is a SYN or SYNACK. This additional ACK allows the Hello functions to reach synchronization more quickly.
注2：タイマーで定義された期間内に送信できるACKメッセージは2つまでです。したがって、タイマーが期限切れになるたびに1つのACKメッセージを送信する必要があります。さらに、着信メッセージがSYNまたはSYNACKである場合、タイマーの有効期限の間に1つの追加のACKメッセージが送信されます。この追加のACKにより、Hello機能はより迅速に同期に到達できます。
Note 3: No more than one ACK message should be sent within any time period of length defined by the timer.
注3：タイマーで定義された長さの期間内に送信できるACKメッセージは1つだけです。
After the Hello messages have been exchanged, and the nodes are in the ESTAB state, the Information Exchange Phase, consisting of the RIB Exchange and Bundle Passing Sub-Phases, is initiated. This section describes the procedure and shows the state transitions necessary in these sub-phases; the following sections describe in detail the various TLVs passed in these phases. On reaching the ESTAB state in the high-level HELLO state, there is an automatic transition to the INFO_EXCH high-level state.
Helloメッセージが交換され、ノードがESTAB状態になると、RIB交換とバンドル受け渡しサブフェーズで構成される情報交換フェーズが開始されます。このセクションでは、手順を説明し、これらのサブフェーズで必要な状態遷移を示します。次のセクションでは、これらのフェーズで渡されるさまざまなTLVについて詳しく説明します。高レベルHELLO状態でESTAB状態に達すると、INFO_EXCH高レベル状態に自動的に移行します。
PRoPHET runs over a bidirectional transport as documented in Section 1.2 so that when a pair of nodes (A and B) have reached the ESTAB state, they are able to perform the Information Exchange Phase processes for both the A-to-B and B-to-A directions over the link that has just been established. In principle, these two processes are independent of each other and can be performed concurrently. However, complete concurrency may not be the most efficient way to implement the complete process. As explained in Section 3.2.1, the Routing Information Base Dictionary is a shared resource assembled from a combination of information generated locally on each node and information passed from the peer node. Overlaps in this information, and hence the amount of information that has to be passed between the nodes, can be minimized by sequential rather than concurrent operation of the dictionary generation and update processes. It may also be possible to reduce the number of bundles that need to be offered by the second offeror by examining the offers received from the first offeror -- there is no need for the second offeror to offer a bundle that is already present in the first offeror's offer list, as it will inevitably be refused.
セクション1.2に記載されているように、PRoPHETは双方向トランスポートで実行されるため、ノードのペア（AとB）がESTAB状態に到達すると、A-to-BとB-の両方に対して情報交換フェーズプロセスを実行できます。 to-A確立されたばかりのリンク上の方向。原則として、これら2つのプロセスは互いに独立しており、同時に実行できます。ただし、完全な同時実行は、完全なプロセスを実装するための最も効率的な方法ではない場合があります。セクション3.2.1で説明したように、ルーティング情報ベースディクショナリは、各ノードでローカルに生成された情報とピアノードから渡された情報の組み合わせから組み立てられた共有リソースです。この情報の重複、つまりノード間で渡される必要のある情報の量は、ディクショナリの生成プロセスと更新プロセスの同時ではなく順次の操作によって最小限に抑えることができます。最初の提供者から受け取ったオファーを調べることにより、2番目の提供者が提供する必要のあるバンドルの数を減らすことも可能です-最初の提供者にすでに存在するバンドルを2番目の提供者が提供する必要はありません必然的に拒否されるため、提供者の提供リスト。
All implementations MUST be capable of operating in a fully concurrent manner. Each implementation needs to define a policy, which SHOULD be configurable, as to whether it will operate in a concurrent or sequential manner during the Information Exchange Phase. If it is to operate sequentially, then further choices can be made as to whether to interleave dictionary, offer, and response exchange parts, or to complete all parts in one direction before initiating the other direction.
すべての実装は、完全に並行して動作できる必要があります。各実装は、ポリシーを定義する必要があります。ポリシーは、情報交換フェーズ中に並行して動作するか順次的に動作するかについて構成可能である必要があります（SHOULD）。順次操作する場合は、ディクショナリー、オファー、および応答の交換パーツをインターリーブするか、または他の方向を開始する前にすべてのパーツを1つの方向で完了するかを選択できます。
Sequential operation will generally minimize the amount of data transferred across the PRoPHET link and is especially appropriate if the link is half-duplex. However it is probably not desirable to postpone starting the information exchange in the second direction until the exchange of bundles has completed. If the contact between the nodes ends before all possible bundles have been exchanged, it is possible that postponing the start of bundle exchange in the second direction can lead to bundle exchange being skewed in favor of one direction over the other. It may be preferable to share the available contact time and bandwidth between directions by overlapping the Information Exchange Phases and running the actual bundle exchanges concurrently if possible. Also, if encounters expected in the current PRoPHET zone are expected to be relatively short, it MAY not be appropriate to use sequential operation.
順次操作は、一般にPRoPHETリンクを介して転送されるデータの量を最小限に抑え、リンクが半二重の場合に特に適しています。ただし、バンドルの交換が完了するまで、情報交換の開始を第2方向に延期することはおそらく望ましくありません。すべての可能なバンドルが交換される前にノード間の接触が終了した場合、バンドル交換の開始を第2方向に延期すると、バンドル交換が一方の方向に偏って歪む可能性があります。可能な場合は、情報交換フェーズをオーバーラップさせ、実際のバンドル交換を同時に実行することにより、方向間で利用可能な接触時間と帯域幅を共有することが望ましい場合があります。また、現在のPRoPHETゾーンで予想される遭遇が比較的短いと予想される場合、順次操作を使用することは適切ではない場合があります。
One possible interleaving strategy is to alternate between sending from the two nodes. For example, if the Hello SYN node sends its initial dictionary entries while the Hello SYNACK node waits until this is complete, the Hello SYNACK node can then prune its proposed dictionary entries before sending in order to avoid duplication. This approach can be repeated for the second tranche of dictionary entries needed for the Bundle Offers and Responses, and also for the Bundle Offers, where any bundles that are offered by the Hello SYN node that are already present in the Hello SYNACK node need not be offered to the Hello SYN node. This approach is well suited to a transport protocol and physical medium that is effectively half-duplex.
1つの可能なインターリーブ戦略は、2つのノードからの送信を交互に行うことです。たとえば、Hello SYNACKノードがこれが完了するまで待機している間に、Hello SYNACKノードが最初のディクショナリエントリを送信する場合、Hello SYNACKノードは、重複を避けるために、送信する前に提案されたディクショナリエントリをプルーニングできます。このアプローチは、バンドルオファーおよびレスポンスに必要なディクショナリエントリの2番目のトランシェ、およびHello SYNACKノードにすでに存在するHello SYNノードによって提供されるバンドルが不要であるバンドルオファーに対して繰り返すことができます。 Hello SYNノードに提供されます。このアプローチは、事実上半二重であるトランスポートプロトコルと物理メディアに適しています。
At present, the decision to operate concurrently or sequentially is purely a matter of local policy in each node. If nodes have inconsistent policies, the behavior at each encounter will depend on which node takes the SYN role; this is a matter of chance depending on random timing of the start of communications during the encounter.
現在、同時または順次に操作するかどうかの決定は、純粋に各ノードのローカルポリシーの問題です。ノードのポリシーに一貫性がない場合、各遭遇時の動作は、どのノードがSYNの役割を担うかによって異なります。これは、遭遇中の通信の開始のランダムなタイミングに応じて、偶然の問題です。
To manage the information transfer, two subsidiary state machines are created in each node to control the stages of the RIB Exchange Sub-Phase and Bundle Passing Sub-Phase processes within the INFO_EXCH high-level state as shown in Figure 12. Each subsidiary state machine consists of two essentially independent components known as the "Initiator role" and the "Listener role". One of these components is instantiated in each node. The Initiator role starts the Information Exchange Phase in each node and the Listener role responds to the initial messages, but it is not a passive listener as it also originates messages. The transition from the ESTAB state is a "forking" transition in that it starts both subsidiary state machines. The two subsidiary state machines operate in parallel for as long as the neighbor remains in range and connected.
情報転送を管理するために、図12に示すように、INFO_EXCH高レベル状態内のRIB Exchange Sub-PhaseプロセスとBundle Passing Sub-Phaseプロセスのステージを制御する2つの補助状態マシンが各ノードに作成されます。各補助状態マシン「イニシエーターの役割」と「リスナーの役割」と呼ばれる2つの本質的に独立したコンポーネントで構成されます。これらのコンポーネントの1つは、各ノードでインスタンス化されます。イニシエーターの役割は各ノードで情報交換フェーズを開始し、リスナーの役割は初期メッセージに応答しますが、メッセージを発信するため、パッシブリスナーではありません。 ESTAB状態からの遷移は、両方の補助的な状態マシンを開始する「分岐」遷移です。 2つの補助的なステートマシンは、ネイバーが範囲内にあり、接続されている限り、並行して動作します。
+ - - - - - - - - + + - - - - - - - - +
| SYN node | PRoPHET messages with: | SYNACK node |
| SYNノード| |のPRoPHETメッセージ： SYNACKノード|
| +-------------+ | A. Delivery Predictabilities | +-------------+ |
| Subsidiary |--->---->---->---->---->---->---->| Subsidiary |
| | State | | C. Bundle Responses | | State | |
| Machine 1: | | Machine 1: |
| | Initiator | | B. Bundle Offers | | Listener | |
| Role |<----<----<----<----<----<----<---| Role |
| +-------------+ | D. Requested Bundles | +-------------+ |
| +-------------+ | A. Delivery Predictabilities | +-------------+ |
| Subsidiary |<----<----<----<----<----<----<---| Subsidiary |
| | State | | C. Bundle Responses | | State | |
| Machine 2: | | Machine 2: |
| | Listener | | B. Bundle Offers | | Initiator | |
| Role |--->---->---->---->---->---->---->| Role |
| +-------------+ | D. Requested Bundles | +-------------+ |
+ - - - - - - - - + + - - - - - - - - +
The letters (A - D) indicate the sequencing of messages.
文字（A-D）はメッセージの順序を示します。
Figure 12: Information Exchange Phase Subsidiary State Machines
図12：情報交換フェーズの補助的な状態マシン
These subsidiary state machines can be thought of as mirror images: for each state machine, one node takes on the Initiator role while the other node takes on the Listener role. TLVs sent by a node from the Initiator role will be processed by the peer node in the Listener role and vice versa. As indicated in Figure 12, the Initiator role handles sending that node's current set of delivery predictabilities for known destinations to the Listener role node. The Listener role node uses the supplied values to update its delivery predictabilities according to the update algorithms described in Section 2.1.2. It then decides which bundles that it has in store should be offered for transfer to the Initiator role node as a result of comparing the local predictabilities and those supplied by the Initiator node. When these offers are delivered to the Initiator role node, it decides which ones to accept and supplies the Listener role node with a prioritized list of bundles that it wishes to accept. The Listener role node then sends the requested bundles.
これらの補助的なステートマシンは、ミラーイメージと考えることができます。各ステートマシンでは、一方のノードがイニシエーターの役割を果たし、もう一方のノードがリスナーの役割を果たします。イニシエーターの役割からノードによって送信されたTLVは、リスナーの役割のピアノードによって処理され、その逆も同様です。図12に示すように、イニシエーターの役割は、既知の宛先に対するそのノードの現在の配信予測可能性のセットをリスナーの役割ノードに送信することを処理します。リスナーロールノードは、指定された値を使用して、セクション2.1.2で説明されている更新アルゴリズムに従って配信予測可能性を更新します。次に、ローカル予測可能性とイニシエーターノードによって提供された予測可能性を比較した結果として、ストアにあるバンドルをイニシエーターロールノードに転送するために提供する必要があるかどうかを決定します。これらのオファーがイニシエーター役割ノードに配信されると、それは受け入れるものを決定し、受け入れたいバンドルの優先リストをリスナー役割ノードに提供します。次に、リスナーロールノードが要求されたバンドルを送信します。
These exchanges are repeated periodically for as long as the nodes remain in contact. Additionally, if new bundles arrive from other sources, they may be offered, accepted, and sent in between these exchanges.
これらの交換は、ノードが接続されている限り、定期的に繰り返されます。さらに、新しいバンドルが他のソースから到着した場合、それらは提供され、受け入れられ、これらの交換の間で送信されます。
The PRoPHET protocol is designed so that in most cases the TLV type determines the role in which it will be processed on reception. The only exception to this is that both roles may send RIB Dictionary TLVs: the Initiator role sends dictionary entries for use in the subsequent RIB TLV(s), and the Listener role may send additional dictionary entries for use in subsequent Bundle Offer TLVs. The two cases are distinguished by a TLV flag to ensure that they are processed in the right role context on reception. If this flag was not provided, there are states where both roles could accept the RIB Dictionary TLV, making it impossible to ensure that the correct role state machine accepts the RIB Dictionary TLV. Note that the correct updates would be made to the dictionary whichever role processed the TLV and that the ambiguity would not arise if the roles are adopted completely sequentially, i.e., if the RIB Exchange Sub-Phase and associated Bundle Passing Sub-Phase run to completion in one direction before the process for the reverse direction is started.
PRoPHETプロトコルは、ほとんどの場合、TLVタイプが受信時に処理される役割を決定するように設計されています。これの唯一の例外は、両方のロールがRIBディクショナリTLVを送信できることです。イニシエーターロールは後続のRIB TLVで使用するディクショナリエントリを送信し、リスナーロールは後続のバンドルオファーTLVで使用する追加のディクショナリエントリを送信できます。 2つのケースはTLVフラグによって区別され、受信時に適切なロールコンテキストで処理されるようにします。このフラグが指定されていない場合、両方のロールがRIBディクショナリTLVを受け入れることができる状態があり、正しいロールステートマシンがRIBディクショナリTLVを受け入れることを保証できなくなります。 TLVを処理した役割が正しい場合はディクショナリが正しく更新されることに注意してください。役割が完全に順次採用された場合、つまりRIB交換サブフェーズと関連するバンドル受け渡しサブフェーズが完了するまで実行された場合は、あいまいさは発生しません。逆方向のプロセスが開始される前に一方向に。
If sequential operation is selected, the node that sent the Hello SYN function message MUST be the node that sends the first message in the Information Exchange Phase process. This ensures that there is a well-defined order of events with the Initiator role in the Hello SYN node (i.e., the node identified by String ID 0) starting first. The Hello SYNACK node MAY then postpone sending its first message until the Listener role state machine in the Hello SYNACK node has reached any of a number of points in its state progression according to locally configured policy and the nature of the physical link for the current encounter between the nodes as described above. If concurrent operation is selected, the Hello SYNACK node can start sending messages immediately without waiting to receive messages from the peer.
順次操作が選択されている場合、Hello SYN機能メッセージを送信したノードは、情報交換フェーズプロセスで最初のメッセージを送信したノードでなければなりません。これにより、Hello SYNノード（つまり、文字列ID 0で識別されるノード）で開始者の役割を持つイベントの順序が明確に定義され、最初に開始されます。 Hello SYNACKノードは、ローカルで構成されたポリシーと現在のエンカウンターの物理リンクの性質に従って、Hello SYNACKノードのリスナーロールステートマシンが状態の進行におけるいくつかのポイントのいずれかに到達するまで、最初のメッセージの送信を延期する場合があります。上記のようにノード間。同時操作が選択されている場合、Hello SYNACKノードは、ピアからのメッセージの受信を待たずに、すぐにメッセージの送信を開始できます。
The original design of the PRoPHET protocol allowed it to operate over unreliable datagram-type transports as well as the reliable, in-order delivery transport of TCP that is currently specified. When running over TCP, protocol errors and repeated timeouts during the Information Exchange Phase SHOULD result in the connection being terminated.
PRoPHETプロトコルの元の設計では、信頼性の低いデータグラムタイプのトランスポートと、現在指定されているTCPの信頼性の高い順序どおりの配信トランスポートで動作することができました。 TCPで実行している場合、情報交換フェーズ中にプロトコルエラーと繰り返しタイムアウトが発生し、接続が終了する必要があります（SHOULD）。
The state machine component with the Initiator role in each node starts the transfer of information from one node to its peer during the Information Exchange Phase. The process from the Initiator's point of view does the following:
各ノードにイニシエーターの役割を持つステートマシンコンポーネントは、情報交換フェーズ中に1つのノードからそのピアへの情報の転送を開始します。イニシエーターの観点からのプロセスは、次のことを行います。
o The Initiator role determines the set of delivery predictabilities to be sent to the peer node and sends RIB dictionary entries necessary to interpret the set of RIB predictability values that are sent after the dictionary updates. On second and subsequent executions of this state machine during a single session with the same peer, there may be no RIB Dictionary entries to send. Either an empty TLV can be sent or the TLV can be omitted.
oイニシエーターの役割は、ピアノードに送信される配信予測可能性のセットを決定し、辞書の更新後に送信されるRIB予測可能性の値のセットを解釈するために必要なRIB辞書エントリを送信します。同じピアとの単一セッション中にこのステートマシンを2回目以降に実行すると、送信するRIBディクショナリエントリがない場合があります。空のTLVを送信するか、TLVを省略することができます。
o The Initiator then waits to receive any RIB Dictionary updates followed by bundle offers from the Listener role on the peer node.
o 次に、イニシエーターはRIBディクショナリの更新を受信するまで待機し、その後、ピアノードのリスナーロールからのバンドルオファーを受信します。
o The Initiator determines which of the bundle offers should be accepted and, if necessary, reorders the offers to suit its own priorities. The possibly reordered list of accepted bundles is sent to the peer node using one or more bundle responses.
o イニシエーターは、どのバンドルオファーを受け入れる必要があるかを決定し、必要に応じて、独自の優先度に合うようにオファーを並べ替えます。並べ替えられた可能性のある受け入れ済みバンドルのリストは、1つ以上のバンドル応答を使用してピアノードに送信されます。
o The peer then sends the accepted bundles to the Initiator in turn.
o 次に、ピアは受け入れたバンドルをイニシエーターに順番に送信します。
o Assuming that the link remains open during the bundle sending process, the Initiator signals that the Bundle Passing Sub-Phase is complete by sending a message with an empty Bundle Response TLV (i.e, with the Bundle Offer Count set to 0 and no bundle offers following the TLV header).
o バンドルの送信プロセス中にリンクが開いたままであると仮定すると、イニシエーターは、空のバンドル応答TLV（つまり、バンドル提供カウントが0に設定され、バンドル提供なし）でメッセージを送信することにより、バンドル通過サブフェーズが完了したことを通知しますTLVヘッダー）。
o When the bundle transfer is complete, the Initiator starts the Timer(next_exchange). Assuming that the connection to the neighbor remains open, when the timer expires, the Initiator restarts the Information Exchange Phase. During this period, Hello SYN messages are exchanged as keep-alives to check that the neighbor is still present. The keep-alive mechanism is common to the Initiator and Listener machines and is handled in the high-level state machine (see Section 5.1.
o バンドル転送が完了すると、イニシエーターはタイマー（next_exchange）を開始します。ネイバーへの接続が開いたままであると仮定すると、タイマーが期限切れになると、イニシエーターは情報交換フェーズを再開します。この期間中、Hello SYNメッセージはキープアライブとして交換され、ネイバーがまだ存在していることを確認します。キープアライブメカニズムは、イニシエーターマシンとリスナーマシンに共通であり、高レベルのステートマシンで処理されます（セクション5.1を参照）。
A timer is provided that restarts the Initiator role state machine if Bundle Offers are not received after sending the RIB. If this node receives a Hello ACK message containing an Error TLV indicating there has been a protocol problem, then the connection MUST be terminated.
RIBの送信後にバンドルオファーが受信されない場合、イニシエーターロールステートマシンを再起動するタイマーが提供されます。このノードが、プロトコルの問題があったことを示すエラーTLVを含むHello ACKメッセージを受信した場合、接続を終了する必要があります。
The following states are used:
次の状態が使用されます。
CREATE_DR The initial transition to this state from the ESTAB state is immediate and automatic for the node that sent the Hello SYN message. For the peer (Hello SYNACK sender) node, it may be immediate for nodes implementing a fully concurrent process or may be postponed until the corresponding Listener has reached a specified state if a sequential process is configured in the node policy.
CREATE_DR ESTAB状態からこの状態への最初の遷移は、Hello SYNメッセージを送信したノードに対して即時かつ自動的に行われます。ピア（Hello SYNACK送信側）ノードの場合、完全に並行するプロセスを実装するノードに即時に送信されるか、ノードポリシーで順次プロセスが構成されている場合、対応するリスナーが指定された状態になるまで延期されることがあります。
The local dictionary is initialized when this state is entered for the first time from the ESTAB state. The initial state of the dictionary contains two entries: the EID of the node that sent the Hello SYN (String ID 0) and the EID of the node that sent the Hello SYNACK (String ID 1). If the peer reports via a Hello ACK message containing an Error TLV reporting a Dictionary Conflict or Bad String ID error, then the connection MUST be terminated.
ローカル辞書は、この状態がESTAB状態から初めて入るときに初期化されます。辞書の初期状態には、Hello SYNを送信したノードのEID（文字列ID 0）と、Hello SYNACKを送信したノードのEID（文字列ID 1）の2つのエントリが含まれています。ピアが、Dictionary ConflictまたはBad String IDエラーを報告するエラーTLVを含むHello ACKメッセージを介して報告する場合、接続を終了する必要があります。
The CREATE_DR state will be entered in the same way from the REQUEST state when the Timer(next_exchange) expires, signaling the start of a new round of information exchange and bundle passing.
CREATE_DR状態は、Timer（next_exchange）が期限切れになると、REQUEST状態と同じ方法で開始され、情報交換とバンドルの受け渡しの新しいラウンドの開始を通知します。
When in this state:
この状態のとき：
* Determine the destination EIDs for which delivery predictabilities will be sent to the peer in a RIB TLV, if any. Record the prior state of the local dictionary (assuming that String IDs are numbers allocated sequentially, the state information needed is just the highest ID used before this process started) so that the process can be restarted if necessary. Update the local dictionary if any new EIDS are required; format one or more RIB Dictionary TLVs and one or more RIB TLVs and send them to the peer. If there are no dictionary entries to send, TLVs with zero entries MAY be sent, or the TLV can be omitted, but an empty RIB TLV MUST be sent if there is no data to send. The RIB Dictionary TLVs generated here MUST have the Sent by Listener flag set to 0 to indicate that they were sent by the Initiator.
* 配信予測可能性がRIB TLVのピアに送信される宛先EIDを決定します（ある場合）。ローカルディクショナリの以前の状態を記録します（文字列IDは連続して割り当てられた番号であり、必要な状態情報はこのプロセスが開始する前に使用された最高のIDであると仮定します）。これにより、必要に応じてプロセスを再起動できます。新しいEIDSが必要な場合は、ローカルディクショナリを更新します。 1つ以上のRIBディクショナリTLVと1つ以上のRIB TLVをフォーマットして、ピアに送信します。送信するディクショナリエントリがない場合は、エントリがゼロのTLVを送信するか、TLVを省略できますが、送信するデータがない場合は空のRIB TLVを送信する必要があります。ここで生成されたRIBディクショナリTLVは、イニシエーターによって送信されたことを示すために、「リスナーによる送信」フラグを0に設定する必要があります。
* If an Error TLV indicating a Dictionary Conflict or Bad String ID is received during or after sending the RIB Dictionary TLVs and/or the RIB TLVs, abort any in-progress Initiator or Listener process, and terminate the connection to the peer.
* RIB辞書TLVやRIB TLVの送信中または送信後に、辞書の競合または不正な文字列IDを示すエラーTLVを受信した場合は、進行中のイニシエーターまたはリスナープロセスを中止し、ピアへの接続を終了します。
* Start a timer (known as Timer(info)) and transition to the SEND_DR state.
* タイマーを開始し（Timer（info）として知られています）、SEND_DR状態に遷移します。
Note that when (and only when) running over a transport protocol such as TCP, both the RIB Dictionary and RIB information MAY be spread across multiple TLVs and messages if required by known constraints of the transport protocol or to reduce the size of memory buffers. Alternatively, the information can be formatted using a single RIB Dictionary TLV and a single RIB TLV. These TLVs may be quite large, so it may be necessary to segment the message either using the PRoPHET submessage capability or, if the transport protocol has appropriate capabilities, using those inherent capabilities. This discussion of segmentation applies to the other states and the bundle offer and bundle response messages and will not be repeated.
TCPなどのトランスポートプロトコルを介して実行している場合（およびその場合のみ）、トランスポートプロトコルの既知の制約によって、またはメモリバッファーのサイズを削減するために、RIBディクショナリとRIB情報の両方を複数のTLVとメッセージに分散できます（MAY）。または、単一のRIBディクショナリTLVと単一のRIB TLVを使用して情報をフォーマットすることもできます。これらのTLVは非常に大きい可能性があるため、PRoPHETサブメッセージ機能を使用するか、トランスポートプロトコルに適切な機能がある場合は、それらの固有の機能を使用してメッセージをセグメント化する必要があります。このセグメンテーションの説明は、他の状態とバンドルオファーおよびバンドルレスポンスメッセージに適用され、繰り返されません。
If more than one RIB TLV is to be used, all but the last one have the "More RIB TLVs" flag set to 1 in the TLV flags. It is not necessary to distinguish the last RIB Dictionary TLV because the actions taken at the receiver are essentially passive (recording the contents), and the sequence is ended by the sending of the first RIB TLV.
複数のRIB TLVを使用する場合、最後のものを除くすべてのTLVフラグで「More RIB TLVs」フラグが1に設定されます。レシーバーで行われるアクションは本質的にパッシブである（コンテンツを記録する）ため、最後のRIBディクショナリTLVを区別する必要はなく、シーケンスは最初のRIB TLVの送信によって終了します。
SEND_DR In this state, the Initiator node expects to be receiving Bundle Offers and sending Bundle Responses. The Initiator node builds a list of bundles offered by the peer while in this state:
SEND_DRこの状態では、イニシエーターノードはバンドルオファーを受信し、バンドルレスポンスを送信することを期待しています。イニシエーターノードは、この状態の間にピアによって提供されるバンドルのリストを作成します。
* Clear the set of bundles offered by the peer on entry to the state.
* 状態に入るときにピアによって提供されたバンドルのセットをクリアします。
* If the Timer(info) expires, re-send the RIB Dictionary and RIB information sent in the previous CREATE_DR state using the stored state to re-create the information. The RIB dictionary update process in the peer is idempotent provided that the mappings between the EID and the String ID in the re-sent RIB Dictionary TLVs are the same as in the original. This means that it does not matter if some of the RIB Dictionary TLVs had already been processed in the peer. Similarly, re-sending RIB TLVs will not cause a problem.
* Timer（info）が期限切れになった場合は、以前のCREATE_DR状態で送信されたRIBディクショナリとRIB情報を、保存された状態を使用して再送信し、情報を再作成します。ピアでのRIBディクショナリの更新プロセスは、再送信されたRIBディクショナリTLVのEIDと文字列IDの間のマッピングが元のものと同じであれば、べき等です。つまり、一部のRIBディクショナリTLVがピアですでに処理されているかどうかは問題ではありません。同様に、RIB TLVを再送信しても問題は発生しません。
* If a message with a RIB Dictionary TLV marked as sent by a Listener is received, update the local dictionary based on the received TLV. If any of the entries in the RIB Dictionary TLV conflict with existing entries (i.e., an entry is received that uses the same String ID as some previously received entry but the EID in the entry is different), send a Response message with an Error TLV containing a Dictionary Conflict indicator, abort any in-progress Initiator or Listener process, and terminate the connection to the peer. Note that in some circumstances no dictionary updates are needed, and the first message received in this state will carry a Bundle Offer TLV.
* リスナーによって送信済みとしてマークされたRIBディクショナリTLVを含むメッセージを受信した場合、受信したTLVに基づいてローカルディクショナリを更新します。 RIBディクショナリTLVのエントリのいずれかが既存のエントリと競合する場合（つまり、以前に受信したエントリと同じ文字列IDを使用するが、エントリのEIDが異なるエントリを受信した場合）、エラーTLVを含む応答メッセージを送信します。辞書競合インジケーターを含み、進行中のイニシエーターまたはリスナープロセスを中止し、ピアへの接続を終了します。状況によっては、ディクショナリの更新が不要であり、この状態で受信された最初のメッセージはバンドルオファーTLVを運ぶことに注意してください。
* If a message with a Bundle Offer TLV is received, restart the Timer(info) if the "More Offer/Response TLVs Following" flag is set in the TLV; otherwise, stop the Timer(info). Then process any PRoPHET ACKs in the TLV by informing the bundle protocol agent, and add the bundles offered in the TLV to the set of bundles offered. If the "More Offer/Response TLVs Following" flag is set in the TLV, wait for further Bundle Offer TLVs. If a Bundle Offer TLV is received with a String ID that is not in the dictionary, send a message with an Error TLV containing a Bad String ID indicator, abort any in-progress Initiator or Listener process, and terminate the connection to the peer.
*バンドルオファーTLVの付いたメッセージを受信した場合、TLVで「More Offer / Response TLVs Following」フラグが設定されていれば、Timer（info）を再起動します。それ以外の場合は、Timer（情報）を停止します。次に、バンドルプロトコルエージェントに通知してTLVのPRoPHET ACKを処理し、TLVで提供されるバンドルを提供されるバンドルのセットに追加します。 TLVで「More Offer / Response TLVs Following」フラグが設定されている場合は、さらにバンドルオファーTLVが来るのを待ちます。バンドルオファーTLVがディクショナリにない文字列IDで受信された場合、不正な文字列IDインジケーターを含むエラーTLVを含むメッセージを送信し、進行中のイニシエーターまたはリスナープロセスを中止し、ピアへの接続を終了します。
* If the "More Offer/Response TLVs Following" flag is clear in the last Bundle Offer TLV received, inspect the set of bundles offered to determine the set of bundles that are to be accepted using the configured queueing policy. Record the set of bundles accepted so that reception can be checked in the Bundle Passing Sub-Phase. Format one or more Bundle Response TLVs flagging the accepted offers and send them to the peer. If more than one Bundle Response TLV is sent, all but the last one should have the "More Offer/Response TLVs Following" flag set to 1. At least one Bundle Response TLV MUST be sent even if the node does not wish to accept any of the offers. In this case, the Bundle Response TLV contains an empty set of acceptances.
* 受信した最後のバンドルオファーTLVで「More Offer / Response TLVs Following」フラグがクリアされている場合は、提供されたバンドルのセットを調べて、設定されたキューイングポリシーを使用して受け入れられるバンドルのセットを決定します。バンドル通過サブフェーズで受信を確認できるように、受け入れられたバンドルのセットを記録します。受け入れられたオファーにフラグを付ける1つ以上のバンドル応答TLVをフォーマットし、それらをピアに送信します。複数のバンドルレスポンスTLVが送信される場合、最後のTLV以外のすべての「追加オファー/レスポンスTLVをフォロー」フラグを1に設定する必要があります。ノードがいずれも受け入れない場合でも、少なくとも1つのバンドルレスポンスTLVを送信する必要があります。オファーの。この場合、バンドル応答TLVには空の受け入れセットが含まれています。
* If an Error TLV indicating a Bad String ID is received during or after sending the Bundle Response TLVs, abort any in-progress Initiator or Listener process, re-initialize the local dictionary, and terminate the connection to the peer.
* バンドル応答TLVの送信中または送信後に、不正な文字列IDを示すエラーTLVを受信した場合は、進行中のイニシエーターまたはリスナープロセスを中止し、ローカルディクショナリを再初期化して、ピアへの接続を終了します。
* Restart the Timer(info) timer in case the peer does not start sending the requested bundles.
* ピアが要求されたバンドルの送信を開始しない場合に備えて、Timer（info）タイマーを再起動します。
* Transition to state REQUEST.
* 状態REQUESTに遷移します。
REQUEST In this state, the Initiator node expects to be receiving the bundles accepted in the Bundle Response TLV(s):
要求この状態では、イニシエーターノードは、バンドル応答TLVで受け入れられたバンドルを受信することを期待しています。
* Keep track of the bundles received and delete them from the set of bundles accepted.
* 受け取ったバンドルを追跡し、受け入れたバンドルのセットから削除します。
* If the Timer(info) expires while waiting for bundles, format and send one or more Bundle Response TLVs listing the bundles previously accepted but not yet received. If more than one Bundle Response TLV is sent, all but the last one should have the "More Offer/Response TLVs Following" flag set to 1.
* バンドルの待機中にTimer（info）が期限切れになった場合は、以前に受け入れられたがまだ受信されていないバンドルをリストする1つ以上のバンドル応答TLVをフォーマットして送信します。複数のバンドルレスポンスTLVが送信される場合、最後のTLV以外のすべてで、「次のオファー/レスポンスTLVの追加」フラグを1に設定する必要があります。
* If an Error TLV indicating a Bad String ID is received during or after sending the Bundle Response TLVs, abort any in-progress Initiator or Listener process, re-initialize the local dictionary, and terminate the connection to the peer.
* バンドル応答TLVの送信中または送信後に、不正な文字列IDを示すエラーTLVを受信した場合は、進行中のイニシエーターまたはリスナープロセスを中止し、ローカルディクショナリを再初期化して、ピアへの接続を終了します。
* Restart the Timer(info) timer after each bundle is received in case the peer does not continue sending the requested bundles.
* ピアが要求されたバンドルの送信を続行しない場合に備えて、各バンドルが受信された後、Timer（info）タイマーを再起動します。
* When all the requested bundles have been received, format a Bundle Response TLV with the Bundle Offer Count set to zero and with the "More Offer/Response TLVs Following" flag cleared to 0 to signal completion to the peer node. Also, signal the Listener in this node that the Initiator has completed. If the peer node is using a sequential policy, the Listener may still be in the initial state, in which case, it needs to start a timer to ensure that it detects if the peer fails to start the Initiator state machine. Thereafter, coordinate with the Listener state machine in the same node: when the Listener has received the completion notification from the peer node and this Initiator has sent its completion notification, start Timer(next_exchange).
* 要求されたすべてのバンドルが受信されたら、バンドルオファーカウントをゼロに設定し、「More Offer / Response TLVs Following」フラグを0にクリアしてバンドルレスポンスTLVをフォーマットし、ピアノードに完了を通知します。また、このノードのリスナーに、イニシエーターが完了したことを通知します。ピアノードがシーケンシャルポリシーを使用している場合、リスナーはまだ初期状態にある可能性があります。その場合、ピアがイニシエーターステートマシンの開始に失敗したかどうかを検出するために、タイマーを開始する必要があります。その後、同じノード内のリスナー状態マシンと調整します。リスナーがピアノードから完了通知を受信し、このイニシエーターが完了通知を送信したら、Timer（next_exchange）を開始します。
* If the Timer(next_exchange) expires, transition to state CREATE_DR to restart the Information Exchange Phase.
* Timer（next_exchange）が期限切れになると、状態CREATE_DRに遷移して、情報交換フェーズを再開します。
Note that if Timer(info) timeout occurs a number of times (configurable, typically 3) without any bundles being received, then this SHOULD generally be interpreted as the problem that the link to the peer is no longer functional and the session should be terminated. However, some bundles may be very large and take a long time to transmit. Before terminating the session, this state machine needs to check if a large bundle is actually being received although no new completed bundles have been received since the last expiry of the timer. In this case the timer should be restarted without sending the Bundle Response TLV. Also, if the bundles are being exchanged over a transport protocol that can detect link failure, then the session MUST be terminated if the bundle exchange link is shut down because it has failed.
バンドルを受信せずにTimer（info）タイムアウトが何度も（構成可能、通常は3回）発生する場合、これは一般に、ピアへのリンクが機能しなくなってセッションを終了する必要があるという問題として解釈されるべきであることに注意してください。 。ただし、一部のバンドルは非常に大きく、送信に時間がかかる場合があります。セッションを終了する前に、このステートマシンは、タイマーが最後に満了してから新しく完了したバンドルが受信されていないにもかかわらず、大きなバンドルが実際に受信されているかどうかを確認する必要があります。この場合、バンドル応答TLVを送信せずにタイマーを再起動する必要があります。また、バンドルがリンク障害を検出できるトランスポートプロトコルを介して交換されている場合、バンドル交換リンクが失敗したためにシャットダウンされた場合、セッションを終了する必要があります。
The state machine component with the Listener role in each node initially waits to receive a RIB Dictionary update followed by a set of RIB delivery predictabilities during the Information Exchange Phase. The process from the point of view of the Listener does the following:
各ノードにリスナーの役割を持つステートマシンコンポーネントは、最初にRIBディクショナリの更新を受信するまで待機し、その後、情報交換フェーズ中に一連のRIB配信の予測可能性を待機します。リスナーの観点から見たプロセスは、次のことを行います。
o Receive RIB Dictionary updates and RIB values from the peer. Note that in some circumstances no dictionary updates are needed, and the RIBD TLV will contain no entries or may be omitted completely.
o ピアからRIBディクショナリの更新とRIB値を受信します。状況によっては、辞書を更新する必要がなく、RIBD TLVにエントリが含まれていないか、完全に省略される場合があることに注意してください。
o When all RIB messages have been received, the delivery predictability update algorithms are run (see Section 2.1.2) using the values received from the Initiator node and applying any of the optional optimizations configured for this node (see Section 2.1.3).
o すべてのRIBメッセージが受信されると、イニシエーターノードから受信した値を使用して配信予測可能性更新アルゴリズムが実行され（セクション2.1.2を参照）、このノードに構成されたオプションの最適化（セクション2.1.3を参照）が適用されます。
o Using the updated delivery predictabilities and the queueing policy and forwarding strategy configured for this node (see Section 2.1.4) examine the set of bundles currently stored in the Listener node to determine the set of bundles to be offered to the Initiator and order the list according to the forwarding strategy in use. The Bundle Offer TLVs are also used to notify the peer of any PRoPHET ACKs that have been received by the Listener role node.
o 更新された配信予測機能と、このノードに構成されたキューイングポリシーおよび転送戦略（セクション2.1.4を参照）を使用して、現在リスナーノードに格納されているバンドルのセットを調べ、イニシエーターに提供するバンドルのセットを決定し、リストを注文します。使用中の転送戦略に従って。バンドルオファーTLVは、リスナーロールノードが受信したPRoPHET ACKをピアに通知するためにも使用されます。
o Send the list of bundles in one or more bundle offers, preceded if necessary by one or more RIB dictionary updates to add any EIDs required for the source or destination EIDs of the offered bundles. These updates MUST be marked as being sent by the Listener role so that they will be processed by the Initiator role in the peer.
o 1つ以上のバンドルオファーのバンドルのリストを送信します。必要に応じて、1つ以上のRIB辞書の更新を前に付けて、提供されたバンドルのソースまたは宛先EIDに必要なEIDを追加します。これらの更新は、ピアの開始者の役割によって処理されるように、リスナーの役割によって送信されるものとしてマークする必要があります。
o Wait for the Initiator to send bundle responses indicating which bundles should be sent and possibly a modified order for the sending. Send the accepted bundles in the specified order. The bundle sending will normally be carried out over a separate connection using a suitable DTN convergence layer.
o イニシエーターが、どのバンドルを送信する必要があるかを示すバンドル応答と、場合によっては送信用に変更されたオーダーを送信するまで待ちます。承認されたバンドルを指定された順序で送信します。バンドルの送信は通常、適切なDTNコンバージェンスレイヤーを使用して別の接続で実行されます。
o On completion of the sending, wait for a message with an empty Bundle Response TLV indicating correct completion of the process.
o 送信が完了したら、プロセスが正常に完了したことを示す空のバンドル応答TLVを含むメッセージを待ちます。
o The Listener process will be notified if any new bundles or PRoPHET ACKs are received by the node after the completion of the bundle sending that results from this information exchange. The forwarding policy and the current delivery predictabilities will then be applied to determine if this information should be sent to the peer. If it is determined that one or more bundles and/or ACKs ought to be forwarded, a new set of bundle offers are sent to the peer. If the peer accepts them by sending bundle responses, the bundles and/or ACKS are transferred as previously.
o この情報交換の結果であるバンドルの送信が完了した後、ノードが新しいバンドルまたはPRoPHET ACKを受信すると、リスナープロセスに通知されます。次に、転送ポリシーと現在の配信予測機能を適用して、この情報をピアに送信する必要があるかどうかを判断します。 1つ以上のバンドルまたはACK、あるいはその両方を転送する必要があると判断された場合、新しい一連のバンドルオファーがピアに送信されます。ピアがバンドル応答を送信してそれらを受け入れる場合、バンドルおよび/またはACKSは以前と同様に転送されます。
o Periodically, the Initiator in the peer will restart the complete information exchange by sending a RIB TLV that may be, optionally, preceded by RIB Dictionary entries if they are required for the updated RIB.
o 定期的に、ピアのイニシエーターは、更新されたRIBに必要な場合、RIB TLVを送信することにより、完全に情報交換を再開します。
Timers are used to ensure that the Listener does not lock up if messages are not received from the Initiator in a timely fashion. The Listener is restarted if the RIB is not received, and a Hello ACK message is sent to force the Initiator to restart. If bundle response messages are not received in a timely fashion, the Listener re-sends the bundle offers and associated dictionary updates. The following states are used: WAIT_DICT The Listener subsidiary state machine transitions to this state automatically and immediately from the state ESTAB in both peers. This state will be entered in the same way if the Timer(next_exchange) expires in the peer, signaling the start of a new round of information exchange and bundle passing. This will result in one or more RIB TLVs being sent to the Listener by the peer node's Initiator.
タイマーは、メッセージがイニシエーターからタイムリーに受信されない場合にリスナーがロックアップしないようにするために使用されます。 RIBが受信されない場合はリスナーが再起動され、イニシエーターを強制的に再起動するためにHello ACKメッセージが送信されます。バンドル応答メッセージがタイムリーに受信されない場合、リスナーはバンドルオファーおよび関連するディクショナリの更新を再送信します。次の状態が使用されます。WAIT_DICTリスナーの補助状態マシンは、両方のピアのESTAB状態から自動的かつ即座にこの状態に移行します。この状態は、ピアでTimer（next_exchange）が期限切れになった場合と同じ方法で開始され、情報交換とバンドル通過の新しいラウンドの開始を通知します。これにより、ピアノードのイニシエーターによって1つ以上のRIB TLVがリスナーに送信されます。
* When a RIB Dictionary TLV is received, use the TLV to update the local dictionary, start or (if it is running) restart the Timer(peer) and transition to state WAIT_RIB. If any of the entries in the RIB Dictionary TLV conflict with existing entries (i.e., an entry is received that uses the same String ID as some previously received entry, but the EID in the entry is different), send a Response message with an Error TLV containing a Dictionary Conflict indicator, abort any in-progress Initiator or Listener process, and terminate the connection to the peer.
* RIBディクショナリTLVを受信したら、TLVを使用してローカルディクショナリを更新し、Timer（peer）を開始または（再実行している場合は）再起動して、ステートWAIT_RIBに遷移します。 RIBディクショナリTLVのエントリのいずれかが既存のエントリと競合する場合（つまり、以前に受信したエントリと同じ文字列IDを使用するエントリを受信したが、エントリのEIDが異なる場合）、エラーを含む応答メッセージを送信します。辞書の競合インジケーターを含むTLV、進行中のイニシエーターまたはリスナープロセスを中止し、ピアへの接続を終了します。
* If a Hello ACK message is received from the peer node, transition to state WAIT_DICT and restart the process.
* ピアノードからHello ACKメッセージを受信した場合は、状態WAIT_DICTに移行して、プロセスを再開します。
If multiple timeouts occur (configurable, typically 3), assume that the link is broken and terminate the session. Note that the RIB Dictionary and RIB TLVs may be combined into a single message. The RIB TLV should be passed on to be processed in the WAIT_RIB state.
複数のタイムアウトが発生した場合（構成可能、通常は3）、リンクが切断されていると想定し、セッションを終了します。 RIBディクショナリとRIB TLVは1つのメッセージに結合される場合があることに注意してください。 RIB TLVは、WAIT_RIB状態で処理されるように渡される必要があります。
WAIT_RIB In this state, the Listener expects to be receiving one or more RIB TLVs and possibly additional RIB Dictionary TLVs.
WAIT_RIBこの状態では、リスナーは1つ以上のRIB TLVと、場合によっては追加のRIB辞書TLVを受信することを期待しています。
* On entry to this state, clear the set of received delivery predictabilities.
* この状態に入ると、受信された配信予測可能性のセットがクリアされます。
* Whenever a new message is received, restart the Timer(peer) timer.
* 新しいメッセージを受信したら、Timer（peer）タイマーを再起動します。
* If a RIB dictionary TLV is received, use it to update the local dictionary and remain in this state. If any of the entries in the RIB Dictionary TLV conflict with existing entries (i.e., an entry is received that uses the same String ID as some previously received entry, but the EID in the entry is different), send a message with an Error TLV containing a Dictionary Conflict indicator, abort any in-progress Initiator or Listener process, and terminate the connection to the peer.
* RIBディクショナリTLVを受信した場合は、それを使用してローカルディクショナリを更新し、この状態を維持します。 RIBディクショナリTLVのエントリのいずれかが既存のエントリと競合する場合（つまり、以前に受信したエントリと同じ文字列IDを使用するエントリを受信したが、エントリのEIDが異なる場合）、エラーTLVのメッセージを送信します。辞書競合インジケーターを含み、進行中のイニシエーターまたはリスナープロセスを中止し、ピアへの接続を終了します。
* If a RIB TLV is received, record the received delivery predictabilities for use in recalculating the local delivery predictabilities. If a delivery predictability value is received for an EID that is already in the set of received delivery predictabilities, overwrite the previously received value with the latest value. If a delivery predictability value is received with a String ID that is not in the dictionary, send a message with an Error TLV containing a Bad String ID indicator, abort any in-progress Initiator or Listener process, and terminate the connection to the peer.
* RIB TLVが受信された場合は、受信された配信予測可能性を記録して、ローカル配信予測可能性の再計算に使用します。受信した一連の配信予測可能性にすでに含まれているEIDの配信予測可能性値を受信した場合は、以前に受信した値を最新の値で上書きします。辞書にない文字列IDで配信予測値を受信した場合は、不正な文字列IDインジケーターを含むエラーTLVを含むメッセージを送信し、進行中のイニシエーターまたはリスナープロセスを中止して、ピアへの接続を終了します。
* When a RIB TLV is received with the "More RIB TLVs" flag cleared, initiate the recalculation of delivery predictabilities and stop the Timer(peer). Use the revised delivery predictabilities and the configured queueing and forwarding strategies to create a list of bundles to be offered to the peer node.
* 「More RIB TLVs」フラグがクリアされた状態でRIB TLVが受信されると、配信予測の再計算が開始され、Timer（peer）が停止します。修正された配信予測機能と構成されたキューイングおよび転送戦略を使用して、ピアノードに提供されるバンドルのリストを作成します。
* Record the state of the local dictionary in case the offer procedure has to be restarted. Determine if any new dictionary entries are required for use in the Bundle Offer TLV(s). If so, record them in the local dictionary, then format and send RIB Dictionary entries in zero or more RIB Dictionary TLV messages to update the dictionary in the peer if necessary.
* 提供手順を再開する必要がある場合に備えて、ローカルディクショナリの状態を記録します。バンドルオファーTLVで使用するために新しい辞書エントリが必要かどうかを判断します。その場合は、それらをローカルディクショナリに記録し、RIBディクショナリエントリを0個以上のRIBディクショナリTLVメッセージでフォーマットして送信し、必要に応じてピアのディクショナリを更新します。
* Format and send Bundle Offer TLV(s) carrying the identifiers of the bundles to be offered together with any PRoPHET ACKs received or generated by this node. If more than one Bundle Offer TLV is sent, all but the last Bundle Offer TLV sent MUST have the "More Offer/Response TLVs Following" flag set to 1.
* このノードで受信または生成されたPRoPHET ACKとともに提供されるバンドルの識別子を運ぶバンドル提供TLVをフォーマットして送信します。複数のバンドルオファーTLVが送信される場合、最後に送信されたバンドルオファーTLVを除くすべての「次のオファー/レスポンスTLVが続く」フラグを1に設定する必要があります。
* When all Bundle Offer TLVs have been sent, start the Timer(info) and transition to state OFFER.
* すべてのBundle Offer TLVが送信されたら、Timer（info）を開始し、状態OFFERに遷移します。
* If the Timer(peer) expires, send a Hello ACK TLV to the peer, restart the timer, and transition to state WAIT_DICT.
* Timer（peer）が期限切れになった場合は、Hello ACK TLVをピアに送信し、タイマーを再起動して、状態WAIT_DICTに遷移します。
* If an Error TLV indicating a Dictionary Conflict or Bad String ID is received during or after sending the RIB Dictionary TLVs and/or the Bundle Offer TLVs, abort any in-progress Initiator or Listener process, and terminate the connection to the peer.
* RIBディクショナリTLVやバンドルオファーTLVの送信中または送信後に、ディクショナリの競合または不正な文字列IDを示すエラーTLVを受信した場合は、進行中のイニシエーターまたはリスナープロセスを中止し、ピアへの接続を終了します。
* If a Hello ACK message is received from the peer node, transition to state WAIT_DICT and restart the process.
* ピアノードからHello ACKメッセージを受信した場合は、状態WAIT_DICTに移行して、プロセスを再開します。
OFFER In this state, the Listener expects to be receiving one or more Bundle Response TLVs detailing the bundles accepted by the Initiator node. The ordered list of accepted bundles is communicated to the bundle protocol agent, which controls sending them to the peer node over a separate connection.
OFFERこの状態では、リスナーは、イニシエーターノードによって受け入れられたバンドルの詳細を示す1つ以上のバンドル応答TLVを受信することを期待しています。受け入れられたバンドルの順序付けられたリストは、バンドルプロトコルエージェントに通信されます。バンドルプロトコルエージェントは、別個の接続を介してそれらをピアノードに送信することを制御します。
* When a Bundle Response TLV is received with a non-zero count of Bundle Offers, extract the list of accepted bundles and send the list to the bundle protocol agent so that it can start transmission to the peer node. Ensure that the order of offers from the TLV is maintained. Restart the Timer(info) unless the last Bundle Response TLV received has the "More Offer/ Response TLVs Following" flag set to 0. If a Bundle Response TLV is received with a String ID that is not in the dictionary, send a message with an Error TLV containing a Bad String ID indicator, abort any in-progress Initiator or Listener process, and terminate the connection to the peer.
* バンドルオファーのカウントがゼロ以外のバンドルレスポンスTLVを受信したら、受け入れられたバンドルのリストを抽出し、そのリストをバンドルプロトコルエージェントに送信して、ピアノードへの送信を開始できるようにします。 TLVからのオファーの順序が維持されていることを確認します。受信した最後のバンドル応答TLVの「More Offer / Response TLVs Following」フラグが0に設定されていない限り、Timer（info）を再起動します。辞書にない文字列IDでバンドル応答TLVを受信した場合は、 Bad String IDインジケーターを含むエラーTLV、進行中のイニシエーターまたはリスナープロセスを中止し、ピアへの接続を終了します。
* After receiving a Bundle Response TLV with the "More Offer/ Response TLVs Following" flag set to 0 stop the Timer(info) and transition to state SND_BUNDLE.
* 「More Offer / Response TLVs Following」フラグが0に設定されたバンドルレスポンスTLVを受信した後、Timer（info）を停止し、状態SND_BUNDLEに遷移します。
* If the Timer(info) expires, send a Hello ACK TLV to the peer, restart the timer and transition to state WAIT_DICT.
* Timer（info）の期限が切れた場合は、Hello ACK TLVをピアに送信し、タイマーを再起動して、状態WAIT_DICTに遷移します。
* If a Hello ACK message is received from the peer node, transition to state WAIT_DICT and restart the process.
* ピアノードからHello ACKメッセージを受信した場合は、状態WAIT_DICTに移行して、プロセスを再開します。
SND_BUNDLE In this state the Listener monitors the sending of bundles to the Initiator peer node. In the event of disruption in transmission, the Initiator node will, if possible, re-send the list of bundles that were accepted but have not yet been received. The bundle protocol agent has to be informed of any updates to the list of bundles to send (this is likely to involve re-sending one or more bundles). Otherwise, the Listener is quiescent in this state.
SND_BUNDLEこの状態では、リスナーはイニシエーターピアノードへのバンドルの送信を監視します。送信が中断された場合、イニシエーターノードは、可能であれば、受け入れられたがまだ受信されていないバンドルのリストを再送信します。バンドルプロトコルエージェントは、送信するバンドルのリストの更新を通知される必要があります（これには、1つ以上のバンドルの再送信が含まれる可能性があります）。それ以外の場合、リスナーはこの状態で静止しています。
* When a Bundle Response TLV is received with a non-zero count of Bundle Offers, extract the list of accepted bundles and update the list previously passed to the bundle protocol agent so that it can (re)start transmission to the peer node. Ensure that the order of offers from the TLV is maintained so far as is possible. Restart the Timer(info) unless the last Bundle Response TLV received has the "More Offer/Response TLVs Following" flag set to 0. If a Bundle Response TLV is received with a String ID that is not in the dictionary, send a message with an Error TLV containing a Bad String ID indicator, abort any in-progress Initiator or Listener process, re-initialize the local dictionary, and restart the Information Exchange Phase as if the ESTAB state had just been reached.
*バンドルオファーのゼロ以外のカウントでバンドル応答TLVを受信した場合、受け入れられたバンドルのリストを抽出し、以前にバンドルプロトコルエージェントに渡されたリストを更新して、ピアノードへの送信を（再）開始できるようにします。 TLVからのオファーの順序が可能な限り維持されるようにします。受信した最後のバンドル応答TLVの「More Offer / Response TLVs Following」フラグが0に設定されていない限り、Timer（info）を再起動します。辞書にない文字列IDでバンドル応答TLVを受信した場合は、不正な文字列IDインジケーターを含むエラーTLV、進行中のイニシエーターまたはリスナープロセスを中止し、ローカルディクショナリを再初期化して、ESTAB状態に達したかのように情報交換フェーズを再開します。
* After receiving a Bundle Response TLV with the "More Offer/ Response TLVs Following" flag set to 0, stop the Timer(info) and wait for completion of bundle sending.
* 「More Offer / Response TLVs Following」フラグが0に設定されたバンドル応答TLVを受信した後、Timer（info）を停止し、バンドル送信の完了を待ちます。
* If the Timer(info) expires, send a Hello ACK TLV to the peer, restart the timer, and transition to state WAIT_DICT.
* Timer（info）が期限切れになった場合は、Hello ACK TLVをピアに送信し、タイマーを再起動して、状態WAIT_DICTに遷移します。
* If a Hello ACK message is received from the peer node, transition to state WAIT_DICT and restart the process.
* ピアノードからHello ACKメッセージを受信した場合は、状態WAIT_DICTに移行して、プロセスを再開します。
* When a Bundle Response TLV is received with a zero count of Bundle Offers, the Bundle Passing Sub-Phase is complete. Notify the Initiator that the Listener process is complete and transition to state WAIT_MORE.
* バンドルオファーのカウントがゼロのバンドル応答TLVを受信すると、バンドル通過サブフェーズが完了します。リスナープロセスが完了し、状態WAIT_MOREに移行することをイニシエーターに通知します。
As explained in the Initiator state REQUEST description, depending on the transport protocol (convergence layer) used to send the bundles to the peer node, it may be necessary during the bundle sending process to monitor the liveness of the connection to the peer node in the Initiator process using a timer.
イニシエーターステートリクエストの説明で説明したように、バンドルをピアノードに送信するために使用されるトランスポートプロトコル（コンバージェンスレイヤー）によっては、バンドル送信プロセス中に、ピアノードへの接続の活性を監視する必要がある場合があります。タイマーを使用したイニシエータープロセス。
WAIT_MORE In this state, the Listener monitors the reception of new bundles that might be received from a number of sources, including
WAIT_MOREこの状態では、リスナーは、次のような多数のソースから受信される可能性がある新しいバンドルの受信を監視します
* local applications on the node,
* ノード上のローカルアプリケーション
* other mobile nodes that connect to the node while this connection is open, and
* この接続が開いている間にノードに接続する他のモバイルノード、および
* permanent connections such as might occur at an Internet gateway.
* インターネットゲートウェイで発生するような永続的な接続。
When the Listener is notified of received bundles, it determines if they should be offered to the peer. The peer may also re-initiate the Information Exchange Phase periodically.
リスナーは、受信したバンドルを通知されると、それらをピアに提供する必要があるかどうかを判断します。ピアは、定期的に情報交換フェーズを再開することもできます。
* When the bundle protocol agent notifies the Listener that new bundles and/or new PRoPHET ACKs have been received, the Listener applies the selected forwarding policy and the current delivery predictabilities to determine if any of the items ought to be offered to the connected peer. If so, it carries out the same operations as are described in the WAIT_RIB state to build and send any necessary RIB Dictionary TLVs and RIB TLVs to the Initiator in the peer.
*バンドルプロトコルエージェントが新しいバンドルや新しいPRoPHET ACKを受信したことをリスナーに通知すると、リスナーは選択された転送ポリシーと現在の配信予測機能を適用して、接続されたピアにアイテムを提供する必要があるかどうかを判断します。その場合、WAIT_RIB状態で説明されているのと同じ操作を実行して、必要なRIBディクショナリTLVとRIB TLVを作成し、ピアのイニシエーターに送信します。
* When all Bundle Offer TLVs have been sent, start the Timer(info) and transition to state OFFER.
* すべてのBundle Offer TLVが送信されたら、Timer（info）を開始し、状態OFFERに遷移します。
* If a RIB dictionary TLV is received, use it to update the local dictionary and transition to state WAIT_RIB. If any of the entries in the RIB Dictionary TLV conflict with existing entries (i.e., an entry is received that uses the same String ID as some previously received entry, but the EID in the entry is different), send a message with an Error TLV containing a Dictionary Conflict indicator, abort any in-progress Initiator or Listener process, and terminate the connection to the peer.
* RIBディクショナリTLVを受信した場合は、それを使用してローカルディクショナリを更新し、状態WAIT_RIBに移行します。 RIBディクショナリTLVのエントリのいずれかが既存のエントリと競合する場合（つまり、以前に受信したエントリと同じ文字列IDを使用するエントリを受信したが、エントリのEIDが異なる場合）、エラーTLVのメッセージを送信します。辞書競合インジケーターを含み、進行中のイニシエーターまたはリスナープロセスを中止し、ピアへの接続を終了します。
Note that the RIB Dictionary and RIB TLVs may be combined into a single message. The RIB TLV should be passed on to be processed in the WAIT_RIB state.
RIBディクショナリとRIB TLVは1つのメッセージに結合される場合があることに注意してください。 RIB TLVは、WAIT_RIB状態で処理されるように渡される必要があります。
The Information Exchange Phase (IEP) state definitions include a number of timers. This section provides advice and recommendations for the periods that are appropriate for these timers.
情報交換フェーズ（IEP）状態の定義には、いくつかのタイマーが含まれています。このセクションでは、これらのタイマーに適した期間についてのアドバイスと推奨事項を示します。
Both Timer(info) and Timer(peer) are used to ensure that the state machines do not become locked into inappropriate states if the peer node does not apparently respond to messages sent in a timely fashion either because of message loss in the network or unresponsiveness from the peer. The appropriate values are to some extent dependent on the speed of the network connection between the nodes and the capabilities of the nodes executing the PRoPHET implementations. Values in the range 1 to 10 seconds SHOULD be used, with a value of 5 seconds RECOMMENDED as default. The period should not be set to too low a value, as this might lead to inappropriate restarts if the hardware is relatively slow or there are large numbers of pieces of information to process before responding. When using a reliable transport protocol such as TCP, these timers effectively provide a keep-alive mechanism and ensure that a failed connection is detected as rapidly as possible so that remedial action can be taken (if possible) or the connection shut down tidily if the peer node has moved out of range.
Timer（info）とTimer（peer）の両方を使用して、ネットワーク内のメッセージの損失または応答がないためにピアノードがタイムリーに送信されたメッセージに明らかに応答しない場合に、状態マシンが不適切な状態にロックされないようにします。ピアから。適切な値は、ノード間のネットワーク接続の速度とPRoPHET実装を実行するノードの機能にある程度依存します。 1〜10秒の範囲の値を使用する必要があります（SHOULD）。デフォルトとして5秒の値を推奨します。ハードウェアが比較的遅い場合、または応答前に処理する情報の数が多い場合、不適切な再起動につながる可能性があるため、期間の値をあまり低く設定しないでください。 TCPなどの信頼性の高いトランスポートプロトコルを使用する場合、これらのタイマーはキープアライブメカニズムを効果的に提供し、失敗した接続が可能な限り迅速に検出されるようにします。ピアノードが範囲外に移動しました。
Timer(next_exchange) is used to determine the maximum frequency of (i.e., minimum period between) successive re-executions of the information exchange state machines during a single session between a pair of nodes. Selection of the timer period SHOULD reflect the trade-off between load on the node processor and desire for timely forwarding of bundles received from other nodes. It is RECOMMENDED that the timer periods used should be randomized over a range from 50% to 150% of the base value in order to avoid synchronization between multiple nodes. Consideration SHOULD be given to the expected length of typical encounters and the likelihood of encounters between groups of nodes when setting this period. Base values in the range of 20 to 60 seconds are RECOMMENDED.
Timer（next_exchange）は、ノードのペア間の単一セッション中に情報交換ステートマシンが連続して再実行される最大頻度（つまり、その間の最小期間）を決定するために使用されます。タイマー期間の選択は、ノードプロセッサの負荷と、他のノードから受信したバンドルをタイムリーに転送する必要性との間のトレードオフを反映する必要があります。複数のノード間の同期を回避するために、使用するタイマー期間を基本値の50％から150％の範囲でランダム化することをお勧めします。この期間を設定するときは、通常の遭遇の予想される長さとノードのグループ間の遭遇の可能性を考慮する必要があります。 20〜60秒の範囲の基本値が推奨されます。
This section shows the state transitions that nodes go through during the Information Exchange Phase. State tables are given for the Initiator role and for the Listener role of the subsidiary state machines. Both nodes will be running machines in each role during the Information Exchange Phase, and this can be done either concurrently or sequentially, depending on the implementation, as explained in Section 5.3. The state tables in this section should be read in conjunction with the state descriptions in Sections 5.3.1 and 5.3.2.
このセクションでは、情報交換フェーズ中にノードが通過する状態遷移を示します。状態テーブルは、イニシエーターの役割と、補助的な状態マシンのリスナーの役割に対して与えられます。両方のノードは、情報交換フェーズ中に各ロールでマシンを実行します。これは、セクション5.3で説明するように、実装に応じて、同時または順次のいずれかで実行できます。このセクションの状態テーブルは、セクション5.3.1および5.3.2の状態の説明と併せて読む必要があります。
The following notation is used:
次の表記が使用されます。
nS Node that sent the Hello SYN message.
Hello SYNメッセージを送信したnSノード。
nA Node that sent the Hello SYNACK message.
n Hello SYNACKメッセージを送信したノード。
The following events are common to the Initiator and Listener state tables:
次のイベントは、イニシエーターとリスナーの状態テーブルに共通です。
ErrDC Dictionary Conflict Error TLV received.
ErrDC辞書競合エラーTLVを受信しました。
ErrBadSI Bad String ID Error TLV received.
ErrBadSI不良ストリングIDエラーTLVを受信しました。
HelloAck Hello ACK TLV received. This message is delivered to both Initiator and Listener roles in order to cause a restart of the Information Exchange Phase in the event of message loss or protocol problems.
HelloAck Hello ACK TLVを受信しました。このメッセージは、メッセージの損失またはプロトコルの問題が発生した場合に情報交換フェーズを再開するために、イニシエーターとリスナーの両方の役割に配信されます。
InitStart Sent by Listener role to Initiator role to signal the Initiator role to commence sending messages to peer. If the Listener instance is running in the node that sent the Hello SYN (nS), then InitStart is signaled immediately when the state is entered. For the node that sent the Hello SYNACK (nA), InitStart may be signaled immediately if the operational policy requires concurrent operation of the Initiator and Listener roles or postponed until the Listener role state machine has reached a state defined by the configured policy.
InitStartリスナーロールからイニシエーターロールに送信され、イニシエーターロールにピアへのメッセージの送信を開始するように通知します。 Hello SYN（nS）を送信したノードでリスナーインスタンスが実行されている場合、状態に入るとすぐにInitStartが通知されます。 Hello SYNACK（nA）を送信したノードでは、操作ポリシーでイニシエーターロールとリスナーロールの同時操作が必要な場合、InitStartがすぐに通知されるか、リスナーロールステートマシンが構成済みのポリシーで定義された状態に達するまで延期されます。
RIBnotlast RIB TLV received with "More RIB TLVs" flag set to 1.
「その他のRIB TLV」フラグを1に設定して受信したRIBnotlast RIB TLV
RIBlast RIB TLV received with "More RIB TLVs" flag set to 0.
「その他のRIB TLV」フラグを0に設定して受信したRIBlast RIB TLV
REQnotlast Bundle Response TLV received with More Offer/Response TLVs Following flag set to 1.
REQnotlastバンドル応答TLVが受信され、次のフラグが1に設定された後のオファー/応答TLVが増えました。
REQlast Bundle Response TLV received with More Offer/Response TLVs Following flag set to 0.
REQlastバンドル応答TLVは、0に設定された追加オファー/応答TLVフラグに続いて受信されました。
RIBDi RIBD TLV received with Sent by Listener flag set to 0 (i.e., it was sent by Initiator role).
リスナーが送信フラグを0に設定して受信したRIBDi RIBD TLV（つまり、イニシエーターの役割によって送信された）。
RIBDl RIBD TLV received with Sent by Listener flag set to 1 (i.e., it was sent by Listener role).
RIBDl RIBD TLVは、Sent by Listenerフラグが1に設定されて受信されました（つまり、Listenerロールによって送信されました）。
Timeout(info) The Timer(info) has expired.
Timeout（info）Timer（info）is expired。
Timeout(peer) The Timer(peer) has expired.
Timeout（peer）Timer（peer）is expired。
Both the Initiator and Listener state tables use the following common operations:
イニシエーターとリスナーの両方の状態テーブルは、次の一般的な操作を使用します。
o The "Initialize Dictionary" operation is defined as emptying any existing local dictionary and inserting the two initial entries: the EID of the node that sent the Hello SYN (String ID 0) and the EID of the node that sent the Hello SYNACK (String ID 1).
o 「ディクショナリの初期化」操作は、既存のローカルディクショナリを空にし、Hello SYNを送信したノードのEID（文字列ID 0）とHello SYNACKを送信したノードのEID（文字列ID 1）。
o The "Send RIB Dictionary Updates" operation is defined as:
o 「RIB辞書更新の送信」操作は次のように定義されます。
1. Determining what dictionary updates will be needed for any extra EIDs in the previously selected RIB entries set that are not already in the dictionary and updating the local dictionary with these EIDs. The set of dictionary updates may be empty if no extra EIDs are needed. The set may be empty even on the first execution if sequential operation has been selected, this is the second node to start and the necessary EIDs were in the set previously sent by the first node to start.
1.以前に選択したRIBエントリセット内の、辞書にまだない追加のEIDに必要な辞書の更新を決定し、これらのEIDでローカル辞書を更新します。追加のEIDが必要ない場合、ディクショナリ更新のセットは空である可能性があります。順次操作が選択されている場合、最初の実行でもセットは空になる可能性があります。これは開始する2番目のノードであり、必要なEIDは開始する最初のノードによって以前に送信されたセットにありました。
2. Formatting zero or more RIBD TLVs for the set of dictionary updates identified in the "Build RIB Entries" operation and sends them to the peer. The RIBD TLVs MUST have the "Sent by Listener" flag set to 0 if the updates are sent by the Initiator role and to 1 if sent by the Listener role. In the case of the Initiator role, an empty RIBD TLV MUST be sent even if the set of updates is empty in order to trigger the Listener state machine.
2. 「RIBエントリの構築」操作で識別された一連のディクショナリ更新の0個以上のRIBD TLVをフォーマットし、それらをピアに送信します。 RIBD TLVは、更新がイニシエーターの役割によって送信された場合は0に、リスナーの役割によって送信された場合は1に「リスナーが送信」フラグを設定する必要があります。イニシエーターの役割の場合、リスナーの状態マシンをトリガーするために、更新のセットが空であっても空のRIBD TLVを送信する必要があります。
o The "Update Dictionary" operation uses received RIBD TLV entries to update the local dictionary. The received entries are checked against the existing dictionary. If the String ID in the entry is already in use, the entry is accepted if the EID in the received entry is identical to that stored in the dictionary previously. If it is identical, the entry is unchanged, but if it is not a Response message with an Error TLV indicating Dictionary Conflict is sent to the peer in an Error Response message, the whole received RIBD TLV is ignored, and the Initiator and Listener processes are restarted as if the ESTAB state has just been reached.
o 「ディクショナリの更新」操作では、受信したRIBD TLVエントリを使用してローカルディクショナリを更新します。受信したエントリは、既存の辞書と照合されます。エントリの文字列IDがすでに使用されている場合、受信したエントリのEIDが以前にディクショナリに保存されたものと同じであれば、そのエントリは受け入れられます。同一である場合、エントリは変更されませんが、ディクショナリの競合がエラー応答メッセージでピアに送信されたことを示すエラーTLVのある応答メッセージでない場合、受信したRIBD TLV全体が無視され、イニシエーターおよびリスナープロセスESTAB状態に達したかのように再起動されます。
o The "Abort Exchange" operation is defined as aborting any in-progress information exchange state machines and terminating the connection to the peer.
o 「Abort Exchange」操作は、進行中の情報交換ステートマシンを中止し、ピアへの接続を終了することと定義されています。
o The "Start TI" operation is defined as (re)starting the Timer(info) timer.
o 「TIの開始」操作は、Timer（info）タイマーの（再）開始として定義されます。
o The "Start TP" operation is defined as (re)starting the Timer(peer) timer.
o 「TPの開始」操作は、Timer（peer）タイマーを（再）開始することとして定義されます。
o The "Cancel TI" operation is defined as canceling the Timer(info) timer.
o 「TIのキャンセル」操作は、Timer（info）タイマーのキャンセルとして定義されています。
o The "Cancel TP" operation is defined as canceling the Timer(info) timer.
o 「Cancel TP」操作は、Timer（info）タイマーをキャンセルすることと定義されています。
The rules and state tables for the Initiator role use the following operations:
イニシエーターの役割のルールと状態テーブルは、次の操作を使用します。
o The "Build RIB Entries" operation is defined as:
o 「RIBエントリの作成」操作は次のように定義されます。
1. Recording the state of the local dictionary.
1. ローカル辞書の状態を記録します。
2. Determining the set of EIDs for which RIB entries should be sent during this execution of the Initiator role state machine component. If this is a second or subsequent run of the state machine in this node during the current session with the connected peer, then the set of EIDs may be empty if no changes have occurred since the previous run of the state machine.
2. イニシエーターロールステートマシンコンポーネントのこの実行中にRIBエントリを送信する必要があるEIDのセットを決定します。これが、接続されたピアとの現在のセッション中にこのノードで2回目以降のステートマシンの実行である場合、前回のステートマシンの実行以降に変更が発生していなければ、EIDのセットは空である可能性があります。
3. Determining and extracting the current delivery predictability information for the set of EIDs selected.
3. 選択されたEIDのセットの現在の配信予測情報を決定および抽出します。
o The "Send RIB Entries" operation formats one or more RIB TLVs with the set of RIB entries identified in the "Build RIB Entries" operation and sends them to the peer. If the set is empty, a single RIB TLV with zero entries is sent. If more than one RIB TLV is sent, all but the last one MUST have the "More RIB TLVs" flag set to 1; the last or only one MUST have the flag set to 0.
o 「RIBエントリーの送信」操作は、「RIBエントリーの作成」操作で識別された一連のRIBエントリーで1つ以上のRIB TLVをフォーマットし、それらをピアに送信します。セットが空の場合、エントリがゼロの単一のRIB TLVが送信されます。複数のRIB TLVが送信される場合、最後の1つを除くすべてのRIB TLVフラグを1に設定する必要があります。最後または1つだけがフラグを0に設定する必要があります。
o The "Clear Bundle Lists" operation is defined as emptying the lists of bundles offered by the peer and bundles requested from the peer.
o 「バンドルリストのクリア」操作は、ピアから提供されたバンドルおよびピアから要求されたバンドルのリストを空にすることと定義されています。
o The "Notify ACKs" operation is defined as informing the bundle protocol agent that PRoPHET ACKs has been received for one or more bundles in a Bundle Offer TLV using the Bundle Delivered interface (see Section 2.2).
o 「ACKの通知」操作は、バンドル提供されたインターフェースを使用して、バンドルオファーTLVの1つ以上のバンドルのPRoPHET ACKが受信されたことをバンドルプロトコルエージェントに通知することとして定義されます（セクション2.2を参照）。
o The "Record Offers" operation is defined as recording all the bundles offered in a Bundle Offer TLV in the list of bundles offers.
o 「オファーの記録」操作は、バンドルオファーTLVで提供されるすべてのバンドルをバンドルオファーのリストに記録することと定義されています。
o The "Select for Request" operation prunes and sorts the list of offered bundles held into the list of requested bundles according to policy and the available resources ready for sending to the offering node.
o 「リクエスト用に選択」操作では、ポリシーとオファリングノードに送信する準備ができている利用可能なリソースに従って、要求されたバンドルのリストに保持されている提供されたバンドルのリストを整理およびソートします。
o The "Send Requests" operation is defined as formatting one or more non-empty Bundle Response TLVs and sending them to the offering node. If more than one Bundle Offer TLV is sent, all but the last one MUST have the "More Offer/Response TLVs Following" flag set to 1; the last or only one MUST have the flag set to 0.
o 「要求の送信」操作は、1つ以上の空でないバンドル応答TLVをフォーマットし、それらをオファリングノードに送信することと定義されています。複数のバンドルオファーTLVが送信される場合、最後のTLVを除くすべての「次のオファー/レスポンスTLVが続く」フラグを1に設定する必要があります。最後または1つだけがフラグを0に設定する必要があります。
o The "Record Bundle Received" operation deletes a successfully received bundle from the list of requests.
o 「受信したバンドルの記録」操作は、正常に受信されたバンドルを要求のリストから削除します。
o The "All Requests Done" operation is defined as formatting and sending an empty Bundle Offer TLV, with the "More Offer/Response TLVs Following" flag set to 0, to the offering node.
o 「All Requests Done」操作は、空のバンドルオファーTLVをフォーマットして、「More Offer / Response TLVs Following」フラグを0に設定してオファリングノードに送信することとして定義されます。
o The "Check Receiving" operation is defined as checking with the node bundle protocol agent if bundle reception from the peer node is currently in progress. This is needed in case a timeout occurs while waiting for bundle reception and a very large bundle is being processed.
o 「受信の確認」操作は、ピアノードからのバンドル受信が現在進行中かどうかをノードバンドルプロトコルエージェントで確認することと定義されています。これは、バンドルの受信を待機中にタイムアウトが発生し、非常に大きなバンドルが処理されている場合に必要です。
o The "Start NE" operation is defined as (re)starting the Timer(next_exchange).
o 「Start NE」操作は、Timer（next_exchange）を（再）開始することとして定義されます。
The following events are specific to the Initiator role state machine:
次のイベントは、イニシエーターロールステートマシンに固有です。
LastBndlRcvd Bundle received from peer that is the only remaining bundle in Bundle Requests List.
バンドル要求リストに残っている唯一のバンドルである、ピアから受信したLastBndlRcvdバンドル。
NotLastBndlRcvd Bundle received from peer that is not the only remaining bundle in Bundle Requests List.
NotLastBndlRcvdバンドル要求リストに残っている唯一のバンドルではない、ピアから受信したバンドル。
OFRnotlast Bundle Offer TLV received with "More Offer/Response TLVs Following" flag set to 1.
OFRnotlast Bundle Offer TLVは、「More Offer / Response TLVs Following」フラグが1に設定されて受信されました。
OFRlast Bundle Offer TLV received with "More Offer/Response TLVs Following" flag set to 0
OFRlast Bundle Offer TLVが「More Offer / Response TLVs Following」フラグが0に設定されて受信されました
Timeout(next_exch) The Timer(next_exchange) has expired
Timeout（next_exch）Timer（next_exchange）が時間切れになりました
State: CREATE_DR
状態：CREATE_DR
+==================================================================+
| Condition | Action | New State |
+==================+===================================+===========+
| On Entry | If previous state was ESTAB: | |
| | Initialize Dictionary | |
| | Always: | |
| | Build RIB Entries | |
| | Wait for Init Start | CREATE_DR |
+------------------+-----------------------------------+-----------+
| InitStart | Send RIB Dictionary Updates | |
| | Send RIB Entries | |
| | Start TI | SEND_DR |
+------------------+-----------------------------------+-----------+
| ErrDC | Abort Exchange |(finished) |
+------------------+-----------------------------------+-----------+
| ErrBadSI | Abort Exchange |(finished) |
+------------------+-----------------------------------+-----------+
| HelloAck | Abort Exchange | CREATE_DR |
+==================================================================+
State: SEND_DR
+==================================================================+
| Condition | Action | New State |
+==================+===================================+===========+
| On Entry | Clear Bundle Lists | SEND_DR |
+------------------+-----------------------------------+-----------+
| Timeout(info) | Send RIB Dictionary Updates | |
| | Send RIB Entries (note 1) | SEND_DR |
+------------------+-----------------------------------+-----------+
| RIBDl received | Update Dictionary (note 2) | |
| | If Dictionary Conflict found: | |
| | Abort Exchange | CREATE_DR |
| | Else: | |
| | Start TI | SEND_DR |
+------------------+-----------------------------------+-----------+
| OFRnotlast | Notify ACKs | |
| | Record Offers | |
| | Start TI | SEND_DR |
+------------------+-----------------------------------+-----------+
| OFRlast | Cancel TI | |
| | Notify ACKs | |
| | Record Offers | |
| | Select for Request | |
| | Send Requests | |
| | Start TI | REQUEST |
+------------------+-----------------------------------+-----------+
| ErrDC | Abort Exchange |(finished) |
+------------------+-----------------------------------+-----------+
| ErrBadSI | Abort Exchange |(finished) |
+------------------+-----------------------------------+-----------+
| HelloAck | Abort Exchange | CREATE_DR |
+==================================================================+
State: REQUEST
+==================================================================+
| Condition | Action | New State |
+==================+===================================+===========+
| Timeout(info) | Check Receiving | |
| | If bundle reception in progress: | |
| | Start TI | REQUEST |
| | Otherwise: | |
| | Send Requests | |
| | Start TI (note 3) | REQUEST |
+------------------+-----------------------------------+-----------+
| NotLastBndlRcvd | Record Bundle Received | |
| | Start TI | REQUEST |
+------------------+-----------------------------------+-----------+
| LastBndlRcvd | Cancel TI | |
| | All Requests Done | |
| | Start NE | REQUEST |
+------------------+-----------------------------------+-----------+
|Timeout(next_exch)| | CREATE_DR |
+------------------+-----------------------------------+-----------+
| HelloAck | Abort Exchange | CREATE_DR |
+==================================================================+
Note 1: No response to the RIB has been received before the timer expired, so we re-send the dictionary and RIB TLVs. If the timeout occurs repeatedly, it is likely that communication has failed and the connection MUST be terminated.
注1：タイマーが期限切れになる前にRIBへの応答が受信されなかったため、辞書とRIB TLVを再送信します。タイムアウトが繰り返し発生する場合、通信が失敗している可能性が高く、接続を終了する必要があります。
Note 2: If a Dictionary Conflict error has to be sent, the state machine will be aborted. If this event occurs repeatedly, it is likely that there is either a serious software problem or a security issue. The connection MUST be terminated.
注2：辞書の競合エラーを送信する必要がある場合、ステートマシンは中止されます。このイベントが繰り返し発生する場合は、深刻なソフトウェアの問題またはセキュリティの問題の可能性があります。接続を終了する必要があります。
Note 3: Remaining requested bundles have not arrived before the timer expired, so we re-send the list of outstanding requests. If the timeout occurs repeatedly, it is likely that communication has failed and the connection MUST be terminated.
注3：残りの要求されたバンドルは、タイマーが期限切れになる前に到着していないため、未解決の要求のリストを再送信します。タイムアウトが繰り返し発生する場合、通信が失敗している可能性が高く、接続を終了する必要があります。
The rules and state tables for the Listener role use the following operations:
リスナーロールのルールとステートテーブルは、次の操作を使用します。
o The "Clear Supplied RIBs" operation is defined as setting up an empty container to hold the set of RIBs supplied by the peer node.
o 「提供されたRIBのクリア」操作は、ピアノードによって提供されたRIBのセットを保持する空のコンテナーをセットアップすることとして定義されます。
o The "Record RIBs Supplied" operation is defined as:
o 「提供されたRIBの記録」操作は次のように定義されます。
1. Taking the RIB entries from a received RIB TLV.
1. 受信したRIB TLVからRIBエントリを取得します。
2. Verifying that the String ID used in each entry is present in the dictionary. If not, an Error TLV containing the offending String ID is sent to the peer, and the Initiator and Listener processes are aborted and restarted as if the ESTAB state had just been reached.
2. 各エントリで使用されている文字列IDが辞書に存在することを確認します。そうでない場合は、問題のストリングIDを含むエラーTLVがピアに送信され、イニシエータープロセスとリスナープロセスが中止され、ESTAB状態に達したかのように再起動されます。
3. If all the String IDs are present in the dictionary, record the delivery predictabilities for each EID in the entries.
3. すべての文字列IDがディクショナリに存在する場合は、各EIDの配信予測可能性をエントリに記録します。
o The "Recalc Dlvy Predictabilities" operation uses the algorithms defined in Section 2.1.2 to update the local set of delivery predictabilities using the using the set of delivery predictabilities supplied by the peer in RIB TLVs.
o 「Recalc Dlvy Predictabilities」操作では、セクション2.1.2で定義されたアルゴリズムを使用して、RIB TLVのピアによって提供される配信予測可能性のセットを使用して、ローカルの配信予測可能性のセットを更新します。
o The "Determine Offers" operation determines the set of bundles to be offered to the peer. The local delivery predictabilities and the delivery predictabilities supplied by the peer are compared, and a prioritized choice of the bundles stored in this node to be offered to the peer is made according to the configured queueing policy and forwarding strategy.
o 「Determine Offers」操作は、ピアに提供されるバンドルのセットを決定します。ローカル配信の予測可能性とピアによって提供される配信予測可能性が比較され、ピアに提供されるこのノードに格納されているバンドルの優先順位が付けられた選択が、構成されたキューイングポリシーと転送戦略に従って行われます。
o The "Determine ACKs" operation is defined as obtaining the set of PRoPHET ACKs recorded by the bundle protocol agent that need to be forwarded to the peer. The list of PRoPHET ACKs is maintained internally by the PRoPHET protocol implementation rather than the main bundle protocol agent (see Section 3.5).
o 「Determine ACKs」操作は、ピアに転送する必要があるバンドルプロトコルエージェントによって記録されたPRoPHET ACKのセットを取得することと定義されています。 PRoPHET ACKのリストは、メインバンドルプロトコルエージェントではなく、PRoPHETプロトコル実装によって内部的に維持されます（セクション3.5を参照）。
o The "Determine Offer Dict Updates" operation is defined as determining any extra EIDs that are not already in the dictionary, recording the previous state of the local dictionary, and then adding the required extra entries to the dictionary.
o 「オファーディクト更新の決定」操作は、まだディクショナリにない追加のEIDを決定し、ローカルディクショナリの以前の状態を記録して、必要な追加のエントリをディクショナリに追加することと定義されています。
o The "Send Offers" operation is defined as formatting one or more non-empty Bundle Offer TLVs, incorporating the sets of Offers and PRoPHET ACKs previously determined, and sending them to the peer node. If more than one Bundle Offer TLV is sent, all but the last one MUST have the "More Offer/Response TLVs Following" flag set to 1; the last or only one MUST have the flag set to 0.
o 「オファーの送信」操作は、1つ以上の空でないバンドルオファーTLVをフォーマットし、以前に決定されたオファーとPRoPHET ACKのセットを組み込み、それらをピアノードに送信することとして定義されます。複数のバンドルオファーTLVが送信される場合、最後のTLVを除くすべての「次のオファー/レスポンスTLVが続く」フラグを1に設定する必要があります。最後または1つだけがフラグを0に設定する必要があります。
o The "Record Requests" operation is defined as recording all the bundles offered in a Bundle Offer TLV in the list of bundles offers. Duplicates MUST be ignored. The order of requests in the TLVs MUST be maintained so far as is possible (it is possible that a bundle has to be re-sent, and this may result in out-of-order delivery).
o 「リクエストの記録」操作は、バンドルオファーTLVで提供されるすべてのバンドルをバンドルオファーのリストに記録することと定義されています。重複は無視する必要があります。 TLV内の要求の順序は、可能な限り維持する必要があります（バンドルを再送信する必要がある可能性があり、これにより配信が順序どおりに行われない可能性があります）。
o The "Send Bundles" operation is defined as sending, in the order requested, the bundles in the requested list. This requires the list to be communicated to the bundle protocol agent (see Section 2.2).
o 「バンドルの送信」操作は、要求された順序で、要求されたリスト内のバンドルを送信することとして定義されています。これには、リストがバンドルプロトコルエージェントに通信される必要があります（セクション2.2を参照）。
o The "Check Initiator Start Point" operation is defined as checking the configured sequential operation policy to determine if the Listener role has reached the point where the Initiator role should be started. If so, the InitStart notification is sent to the Initiator role in the same node.
o 「イニシエーター開始点の確認」操作は、リスナーの役割がイニシエーターの役割を開始する必要があるポイントに達したかどうかを判別するために構成された順次操作ポリシーを確認することとして定義されます。その場合、InitStart通知は同じノードのInitiatorロールに送信されます。
The following events are specific to the Listener role state machine:
次のイベントは、リスナーロールステートマシンに固有です。
RIBnotlast RIB TLV received with "More RIB TLVs" flag set to 1.
「その他のRIB TLV」フラグを1に設定して受信したRIBnotlast RIB TLV
RIBlast RIB TLV received with "More RIB TLVs" flag set to 0 and a non-zero count of RIB Entries.
「More RIB TLVs」フラグを0に設定し、ゼロ以外のRIBエントリの数を指定して受信したRIBlast RIB TLV。
REQnotlast Bundle Response TLV received with More Offer/Response TLVs Following flag set to 1.
REQnotlastバンドル応答TLVが受信され、次のフラグが1に設定された後のオファー/応答TLVが増えました。
REQlast Bundle Response TLV received with More Offer/Response TLVs Following flag set to 0 and a non-zero count of bundle offers.
REQlastバンドル応答TLVは、より多くのオファー/レスポンスTLVを伴って受信されました。フラグは0に設定され、バンドルオファーのカウントはゼロではありません。
REQempty Bundle Response TLV received with More Offer/Response TLVs Following flag set to 0 and a zero count of bundle offers.
REQemptyバンドル応答TLVが、より多くのオファー/レスポンスTLVで受信されました。次のフラグが0に設定され、バンドルオファーのカウントがゼロです。
State: WAIT_DICT
状態：WAIT_DICT
+==================================================================+
| Condition | Action | New State |
+==================+===================================+===========+
| On Entry | Check Initiator Start Point | WAIT_DICT |
+------------------+-----------------------------------+-----------+
| RIBDi | Update Dictionary (note 1) | |
| | If Dictionary Conflict found: | |
| | Abort Exchange |(finished) |
| | Else: | |
| | Start TP | WAIT_RIB |
+------------------+-----------------------------------+-----------+
| HelloAck | Abort Exchange | WAIT_DICT |
+==================================================================+
State: WAIT_RIB
+==================================================================+
| Condition | Action | New State |
+==================+===================================+===========+
| On Entry | Clear Supplied RIBS | WAIT_RIB |
+------------------+-----------------------------------+-----------+
| RIBDi | Update Dictionary (note 1) | |
| | If Dictionary Conflict found: | |
| | Abort Exchange |(finished) |
| | Else: | |
| | Start TP | WAIT_RIB |
+------------------+-----------------------------------+-----------+
| RIBnotlast | Record RIBS Supplied (note 2) | |
| | If EID missing in dictionary: | |
| | Abort Exchange |(finished) |
| | Else: | |
| | Start TP | WAIT_RIB |
+------------------+-----------------------------------+-----------
| RIBlast | Check Initiator Start Point | |
| | Record RIBS Supplied (note 2) | |
| | If EID missing in dictionary: | |
| | Abort Exchange |(finished) |
| | Otherwise | |
| | Recalc Dlvy | |
| | Predictabilities | |
| | Cancel TP | |
| | Determine Offers | |
| | Determine ACKs | |
| | Determine Offer | |
| | Dict Updates | |
| | Send RIB Dictionary | |
| | Updates | |
| | Send Offers | |
| | Start TI | OFFER |
+------------------+-----------------------------------+-----------+
| HelloAck | Abort Exchange | WAIT_DICT |
+------------------+-----------------------------------+-----------+
|Any Other TLV rcvd| Abort Exchange |(finished) |
+------------------+-----------------------------------+-----------+
| Timeout(peer) | Send RIB Dictionary Updates | |
| | Send Offers | |
| | Start TI (note 3) | OFFER |
+==================================================================+
State: OFFER
+==================================================================+
| Condition | Action | New State |
+==================+===================================+===========+
| REQnotlast | Send Bundles | |
| | Start TI | OFFER |
+------------------+-----------------------------------+-----------+
| REQlast | Cancel TI | |
| | Check Initiator Start Point | |
| | Send Bundles | SND_BUNDLE|
+------------------+-----------------------------------+-----------+
| REQempty | Cancel TI | |
| | Check Initiator Start Point | WAIT_MORE|
+------------------+-----------------------------------+-----------+
| HelloAck | Abort Exchange | WAIT_DICT |
+------------------+-----------------------------------+-----------+
| Timeout(info) | Send RIB Dictionary Updates | |
| | Send Offers | |
| | Start TI (note 3) | OFFER |
+==================================================================+
State: SND_BUNDLE
状態：SND_BUNDLE
+==================================================================+
| Condition | Action | New State |
+==================+===================================+===========+
| REQnotlast | Send Bundles | |
| | Start TI | SND_BUNDLE|
+------------------+-----------------------------------+-----------+
| REQlast | Cancel TI | |
| | Send Bundles | SND_BUNDLE|
+------------------+-----------------------------------+-----------+
| REQempty | Cancel TI | |
| | Check Initiator Start Point | WAIT_MORE|
+------------------+-----------------------------------+-----------+
| HelloAck | Abort Exchange | WAIT_DICT |
+------------------+-----------------------------------+-----------+
| Timeout(info) | Send RIB Dictionary Updates | |
| | Send Offers | |
| | Start TI (note 3) | OFFER |
+==================================================================+
State: WAIT_MORE
+==================================================================+
| Condition | Action | New State |
+==================+===================================+===========+
| More Bundles | Determine Offers | |
| | Determine ACKs | |
| | Determine Offer | |
| | Dict Updates | |
| | Send RIB Dictionary | |
| | Updates | |
| | Send Offers | |
| | Start TI | OFFER |
+------------------+-----------------------------------+-----------+
| RIBDi | Update Dictionary (note 1) | |
| | If Dictionary Conflict found: | |
| | Abort Exchange |(finished) |
| | Else: | |
| | Start TP | WAIT_RIB |
+------------------+-----------------------------------+-----------+
| REQnotlast | Send Bundles | |
| | Start TI | SND_BUNDLE|
+------------------+-----------------------------------+-----------+
| REQlast | Cancel TI | |
| | Send Bundles | SND_BUNDLE|
+------------------+-----------------------------------+-----------+
| REQempty | Cancel TI | |
| | Check Initiator Start Point | SND_BUNDLE|
+------------------+-----------------------------------+-----------+
| HelloAck | Abort Exchange | WAIT_DICT |
+------------------+-----------------------------------+-----------+
| Timeout(info) | Send RIB Dictionary Updates | |
| | Send Offers | |
| | Start TI (note 3) | OFFER |
+==================================================================+
Note 1: Both the dictionary and the RIB TLVs may come in the same PRoPHET message. In that case, the state will change to WAIT_RIB, and the RIB will then immediately be processed.
注1：ディクショナリとRIB TLVの両方が同じPRoPHETメッセージに含まれる場合があります。その場合、状態はWAIT_RIBに変わり、RIBはすぐに処理されます。
Note 2: Send an ACK if the timer for the peering node expires. Either the link has been broken, and then the link setup will restart, or it will trigger the Information Exchange Phase to restart.
注2：ピアリングノードのタイマーが期限切れになった場合は、ACKを送信します。リンクが切断された後、リンクのセットアップが再開されるか、情報交換フェーズが再開されます。
Note 3: When the RIB is received, it is possible for the PRoPHET agent to update its delivery predictabilities according to Section 2.1.2. The delivery predictabilities and the RIB is then used together with the forwarding strategy in use to create a bundle offer TLV. This is sent to the peering node.
注3：RIBが受信されると、PRoPHETエージェントはセクション2.1.2に従って配信予測可能性を更新できます。次に、配信の予測可能性とRIBを、使用中の転送戦略と一緒に使用して、バンドルオファーTLVを作成します。これはピアリングノードに送信されます。
Note 4: No more bundles are requested by the other node; transfer is complete.
注4：他のノードからバンドルが要求されることはありません。転送が完了しました。
Note 5: No response to the bundle offer has been received before the timer expired, so we re-send the bundle offer.
注5：タイマーが切れる前にバンドルオファーへの応答がなかったため、バンドルオファーを再送信します。
There are existing implementations of PRoPHET based on draft versions of this specification that use version 1 of the protocol. There are a number of significant areas of difference between version 1 and version 2 as described in this document:
プロトコルのバージョン1を使用する、この仕様のドラフトバージョンに基づくPRoPHETの既存の実装があります。このドキュメントで説明されているように、バージョン1とバージョン2の間には多くの重要な違いがあります。
o In version 1, the delivery predictability update equations were significantly different, and in the case of the transitivity equation (Equation 3) could lead to degraded performance or non-delivery of bundles in some circumstances.
o バージョン1では、配信の予測可能性の更新の方程式が大幅に異なり、推移性の方程式（式3）の場合、状況によっては、バンドルのパフォーマンスの低下や配信不能につながる可能性があります。
o In the current version , constraints were placed on the String IDs generated by each node to ensure that it was not possible for there to be a conflict if the IDs were generated concurrently and independently in the two nodes.
o 現在のバージョンでは、IDが2つのノードで同時に独立して生成された場合に競合が発生しないようにするために、各ノードによって生成された文字列IDに制約が課されました。
o In the current version, a flag has been added to the Routing Information Base Dictionary TLV to distinguish dictionary updates sent by the Initiator role and by the Listener role.
o 現在のバージョンでは、ルーティング情報ベースディクショナリTLVにフラグが追加され、イニシエーターロールとリスナーロールによって送信されたディクショナリの更新を区別しています。
o In the current version, the Bundle Offer and Response TLVs have been significantly revised. The version 2 TLVs have been allocated new TLV Type numbers, and the version 1 TLVs (types 0xA2 and 0xA3) are now deprecated. For each bundle specifier, the source EID is transmitted in addition to the creation timestamp by version 2 to ensure that the bundle is uniquely identified. Version 2 also transmits the fragment payload offset and length when the offered bundle is a bundle fragment. The payload length can optionally be transmitted for each bundle (whether or not it is a fragment) to give the receiver additional information that can be useful when determining which bundle offers to accept.
o 現在のバージョンでは、バンドルオファーおよびレスポンスTLVが大幅に改訂されています。バージョン2 TLVには新しいTLVタイプ番号が割り当てられ、バージョン1 TLV（タイプ0xA2および0xA3）は非推奨になりました。各バンドル指定子について、バージョン2による作成タイムスタンプに加えてソースEIDが送信され、バンドルが一意に識別されるようにします。バージョン2は、提供されたバンドルがバンドルフラグメントである場合、フラグメントペイロードのオフセットと長さも送信します。ペイロードの長さは、バンドルごとに（フラグメントであるかどうかにかかわらず）オプションで送信して、どのバンドルが受け入れるかを決定するときに役立つ追加情報をレシーバーに提供できます。
o The behavior of the system after the first Information Exchange Phase has been better defined. The state machine has been altered to better describe how the ongoing operations work. This has involved the removal of the high-level state WAIT_INFO and the addition of two states in the Listener role subsidiary state machine (SND_BUNDLE and WAIT_MORE). The protocol on the wire has not been altered by this change to the description of the state machine. However, the specification of the later stages of operation was slightly vague and might have been interpreted differently by various implementers.
o 最初の情報交換フェーズ後のシステムの動作がより明確になりました。状態マシンは、進行中の操作がどのように機能するかをよりよく説明するために変更されました。これには、高レベルの状態WAIT_INFOの削除と、リスナーロールの補助状態マシン（SND_BUNDLEおよびWAIT_MORE）の2つの状態の追加が含まれます。ワイヤ上のプロトコルは、ステートマシンの説明に対するこの変更によって変更されていません。ただし、操作の後半の仕様はややあいまいであり、さまざまな実装者によって異なる解釈がされている可能性があります。
A node implementing version 2 of the PRoPHET protocol as defined in this document MAY ignore a communication opportunity with a node that sends a HELLO message indicating that it uses version 1, or it MAY partially downgrade and respond to messages as if it were a version 1 node. This means that the version field in all message headers MUST contain 1.
このドキュメントで定義されているPRoPHETプロトコルのバージョン2を実装するノードは、バージョン1を使用していることを示すHELLOメッセージを送信するノードとの通信機会を無視するか、バージョン1であるかのように部分的にダウングレードしてメッセージに応答する場合があります。ノード。これは、すべてのメッセージヘッダーのバージョンフィールドに1が含まれている必要があることを意味します。
It is RECOMMENDED that the version 2 node use the metric update equations defined in this document even when communicating with a version 1 node as this will partially inhibit the problems with the transitivity equation in version 1, and that the version 2 node modify any received metrics that are greater than (1 - delta) to be (1 - delta) to avoid becoming a "sink" for bundles that are not destined for this node. Also version 1 nodes cannot be explicitly offered bundle fragments, and an exchange with a node supporting version 1 MUST use the, now deprecated, previous versions of the Bundle Offer and Response TLVs.
バージョン1ノードと通信する場合でも、バージョン2ノードはこのドキュメントで定義されているメトリック更新式を使用することをお勧めします。これにより、バージョン1ノードの推移性方程式の問題が部分的に抑制され、バージョン2ノードが受信したメトリックを変更します。 （1-デルタ）より大きく（1-デルタ）になり、このノードに向けられていないバンドルの「シンク」にならないようにします。また、バージョン1のノードにバンドルフラグメントを明示的に提供することはできません。バージョン1をサポートするノードとの交換では、現在提供されていない以前のバージョンのバンドルオファーおよびレスポンスTLVを使用する必要があります。
Generally, nodes using version 1 should be upgraded if at all possible because of problems that have been identified.
一般に、特定された問題のために、可能な場合はバージョン1を使用するノードをアップグレードする必要があります。
Currently, PRoPHET does not specify any special security measures. As a routing protocol for intermittently connected networks, PRoPHET is a target for various attacks. The various known possible vulnerabilities are discussed in this section.
現在、PRoPHETは特別なセキュリティ対策を規定していません。断続的に接続されたネットワークのルーティングプロトコルとして、PRoPHETはさまざまな攻撃のターゲットです。このセクションでは、考えられるさまざまな脆弱性について説明します。
The attacks described here are not problematic if all nodes in the network can be trusted and are working towards a common goal. If there exist such a set of nodes, but there also exist malicious nodes, these security problems can be solved by introducing an authentication mechanism when two nodes meet, for example, using a public key system. Thus, only nodes that are known to be members of the trusted group of nodes are allowed to participate in the routing. This of course introduces the additional problem of key distribution, but that is not addressed here.
ここで説明する攻撃は、ネットワーク内のすべてのノードが信頼でき、共通の目標に向かって機能している場合は問題ありません。このようなノードのセットが存在し、悪意のあるノードも存在する場合、これらのセキュリティの問題は、たとえば公開鍵システムを使用して2つのノードが出会ったときに認証メカニズムを導入することで解決できます。したがって、信頼できるノードのグループのメンバーであることがわかっているノードだけがルーティングに参加できます。もちろん、これは鍵の配布という別の問題を引き起こしますが、ここでは取り上げません。
Where suitable, the mechanisms (such as key management and bundle authentication or integrity checks) and terminology specified by the Bundle Security Protocol [RFC6257] are to be used.
必要に応じて、Bundle Security Protocol [RFC6257]で指定されているメカニズム（鍵管理、バンドル認証、整合性チェックなど）と用語を使用します。
There are a number of kinds of attacks on the operation of the protocol that it would be possible to stage on a PRoPHET network. The attacks and possible remedies are listed here.
プロトコルの操作に対する攻撃には、PRoPHETネットワーク上でステージングすることが可能なさまざまな種類があります。攻撃と可能な対策はここにリストされています。
A malicious node sets its delivery predictabilities for all destinations to a value close to or exactly equal to 1 and/or requests all bundles from nodes it meets, and does not forward any bundles. This has two effects, both causing messages to be drawn towards the black hole instead of to their correct destinations.
悪意のあるノードは、すべての宛先の配信予測可能性を1に近い値または正確に1に設定し、またはノードにすべてのバンドルを要求し、バンドルを転送しません。これには2つの効果があり、どちらも正しい宛先ではなく、ブラックホールに向かってメッセージを表示します。
1. A node encountering a malicious node will try to forward all its bundles to the malicious node, creating the belief that the bundle has been very favorably forwarded. Depending on the forwarding strategy and queueing policy in use, this might hamper future forwarding of the bundle and/or lead to premature dropping of the bundle.
1. 悪意のあるノードに遭遇したノードは、すべてのバンドルを悪意のあるノードに転送しようとし、バンドルが非常に好意的に転送されたという信念を生み出します。使用している転送戦略とキューイングポリシーによっては、これによりバンドルの将来の転送が妨げられたり、バンドルが早期に廃棄されたりする可能性があります。
2. Due to the transitivity, the delivery predictabilities reported by the malicious node will affect the delivery predictabilities of other nodes. This will create a gradient for all destinations with the black hole as the "center of gravity" towards which all bundles traverse. This should be particularly severe in connected parts of the network.
2. 推移性のため、悪意のあるノードによって報告された配信の予測可能性は、他のノードの配信の予測可能性に影響を与えます。これにより、すべてのバンドルが移動する「重心」としてブラックホールを持つすべての目的地のグラデーションが作成されます。これは、ネットワークの接続された部分で特に厳しいはずです。
A node receiving a set of delivery predictabilities that are all at or close to 1 should be suspicious. Similarly, a node that accepts all bundles and offers none might be considered suspicious. However, these conditions are not impossible in normal operation.
すべてが1またはそれに近い配信予測可能性のセットを受信するノードは、疑わしいはずです。同様に、すべてのバンドルを受け入れ、何も提供しないノードは、疑わしいと見なされる場合があります。ただし、これらの条件は通常の操作では不可能ではありません。
To prevent this attack, authentication between nodes that meet needs to be present. Nodes can also inspect the received metrics and bundle acceptances/offers for suspicious patterns and terminate communications with nodes that appear suspicious. The natural evolution of delivery predictabilities should mean that a genuine node would not be permanently ostracized even if the values lead to termination of a communication opportunity on one occasion. The epidemic nature of PRoPHET would mean that such a termination rarely leads to non-delivery of bundles.
この攻撃を防ぐには、条件を満たすノード間の認証が存在する必要があります。また、ノードは、受信したメトリックを検査して、疑わしいパターンの受け入れ/提供をバンドルし、疑わしいと思われるノードとの通信を終了できます。配信の予測可能性の自然な進化は、たとえ値が1つの機会に通信機会の終了につながる場合でも、本物のノードが永続的に追放されないことを意味するはずです。 PRoPHETの流行の性質は、そのような終了がバンドルの配信不能につながることはめったにないことを意味します。
A malicious node misrepresents itself by claiming to be someone else. The effects of this attack are:
悪意のあるノードは、他の誰かであると主張することにより、自分自身を偽装します。この攻撃の影響は次のとおりです。
1. The effects of the black-hole attack listed above hold for this attack as well, with the exception that only the delivery predictabilities and bundles for one particular destination are affected. This could be used to "steal" the data that should be going to a particular node.
1. 上記のブラックホール攻撃の影響は、この攻撃にも当てはまります。ただし、特定の1つの宛先の配信の予測可能性とバンドルのみが影響を受けます。これは、特定のノードに送信されるデータを「盗む」ために使用できます。
2. In addition to the above problems, PRoPHET ACKs will be issued for the bundles that are delivered to the malicious node. This will cause these bundles to be removed from the network, reducing the chance that they will reach their real destination.
2. 上記の問題に加えて、悪意のあるノードに配信されるバンドルに対してPRoPHET ACKが発行されます。これにより、これらのバンドルがネットワークから削除され、実際の宛先に到達する可能性が低くなります。
The destination can detect that this kind of attack has occurred (but it cannot prevent the attack) when it receives a PRoPHET ACK for a bundle destined to itself but for which it did not receive the corresponding bundle.
宛先は、自分宛てのバンドルで対応するバンドルを受信しなかったバンドルのPRoPHET ACKを受信すると、この種の攻撃が発生したことを検出できます（ただし、攻撃を防ぐことはできません）。
To prevent this attack, authentication between nodes that meet needs to be present.
この攻撃を防ぐには、条件を満たすノード間の認証が存在する必要があります。
A malicious node may issue fake PRoPHET ACKs for all bundles (or only bundles for a certain destination if the attack is targeted at a single node) carried by nodes it met. The affected bundles will be deleted from the network, greatly reducing their probability of being delivered to the destination.
悪意のあるノードは、それが遭遇したノードによって運ばれるすべてのバンドル（または攻撃が単一のノードを対象としている場合は特定の宛先のみのバンドル）に対して偽のPRoPHET ACKを発行する可能性があります。影響を受けるバンドルはネットワークから削除され、宛先に配信される可能性が大幅に減少します。
If a public key cryptography system is in place, this attack can be prevented by mandating that all PRoPHET ACKs be signed by the destination. Similarly to other solutions using public key cryptography, this introduces the problem of key distribution.
公開鍵暗号化システムが導入されている場合、この攻撃は、すべてのPRoPHET ACKが宛先によって署名されることを義務付けることによって防止できます。公開鍵暗号を使用する他のソリューションと同様に、これは鍵配布の問題を引き起こします。
After encountering and receiving the delivery predictability information from the victim, a malicious node may generate a large number of fake bundles for the destination for which the victim has the highest delivery predictability. This will cause the victim to most likely accept these bundles, filling up its bundle storage, possibly at the expense of other, legitimate, bundles. This problem is transient as the messages will be removed when the victim meets the destination and delivers the messages.
悪意のあるノードは、被害者から配信予測情報に出会い、それを受け取った後、被害者が最も配信予測可能性が高い宛先に対して、多数の偽のバンドルを生成する可能性があります。これにより、被害者はこれらのバンドルを受け入れる可能性が高くなり、おそらく他の正当なバンドルを犠牲にして、バンドルストレージがいっぱいになります。被害者が宛先に出会ってメッセージを配信するとメッセージが削除されるため、この問題は一時的なものです。
If it is possible for the destination to figure out that the bundles it is receiving are fake, it could report that malicious actions are underway.
宛先が受信しているバンドルが偽物であることを把握できる場合、悪意のあるアクションが進行中であると報告される可能性があります。
This attack could be prevented by requiring sending nodes to sign all bundles they send. By doing this, intermediate nodes could verify the integrity of the messages before accepting them for forwarding.
この攻撃は、送信ノードが送信するすべてのバンドルに署名することを要求することで防ぐことができます。これを行うことにより、中間ノードは、メッセージを転送のために受け入れる前に、メッセージの整合性を検証できます。
A more sophisticated version of the attack in the previous section can be attempted. The effect of the previous attack was lessened since the destination node of the fake bundles existed. This caused fake bundles to be purged from the network when the destination was encountered. The malicious node may now use the transitive property of the protocol to boost the victim's delivery predictabilities for a non-existent destination. After this, it creates a large number of fake bundles for this non-existent destination and offers them to the victim. As before, these bundles will fill up the bundle storage of the victim. The impact of this attack will be greater as there is no probability of the destination being encountered and the bundles being acknowledged. Thus, they will remain in the bundle storage until they time out (the malicious node may set the timeout to a large value) or until they are evicted by the queueing policy.
前のセクションの攻撃のより洗練されたバージョンを試すことができます。偽のバンドルの宛先ノードが存在していたため、以前の攻撃の影響は軽減されました。これにより、宛先に遭遇したときに偽のバンドルがネットワークから削除されました。悪意のあるノードは、プロトコルの推移的なプロパティを使用して、存在しない宛先に対する被害者の配信予測可能性を高める可能性があります。その後、この存在しない宛先に多数の偽のバンドルを作成し、被害者に提供します。以前と同様に、これらのバンドルは被害者のバンドルストレージをいっぱいにします。宛先に遭遇してバンドルが確認される可能性がないため、この攻撃の影響は大きくなります。したがって、タイムアウトになるまで（悪意のあるノードがタイムアウトを大きな値に設定する可能性があるまで）、またはキューイングポリシーによって削除されるまで、バンドルストレージに残ります。
The delivery predictability for the fake destination may spread in the network due to the transitivity, but this is not a problem, as it will eventually age and fade away.
偽の宛先の配信予測可能性は、推移性のためにネットワークに広がる可能性がありますが、最終的には老朽化して消えていくので、これは問題ではありません。
The impact of this attack could be increased if multiple malicious nodes collude, as network resources can be consumed at a greater speed and at many different places in the network simultaneously.
複数の悪意のあるノードが共謀すると、この攻撃の影響が増大する可能性があります。これは、ネットワークリソースがより高速で、ネットワーク内のさまざまな場所で同時に消費される可能性があるためです。
Users may opt to connect two regions of sparsely connected nodes through a connected network such as the Internet where another routing protocol is running. To this network, PRoPHET traffic would look like any other application-layer data. Extra care must be taken in setting up these gateway nodes and their interconnections to make sure that malicious nodes cannot use them to launch attacks on the infrastructure of the connected network. In particular, the traffic generated should not be significantly more than what a single regular user end host could create on the network.
ユーザーは、別のルーティングプロトコルが実行されているインターネットなどの接続ネットワークを介して、疎接続ノードの2つの領域を接続することを選択できます。このネットワークにとって、PRoPHETトラフィックは他のアプリケーション層データのように見えます。これらのゲートウェイノードとそれらの相互接続を設定する際には、悪意のあるノードがこれらを使用して、接続されたネットワークのインフラストラクチャに攻撃を仕掛けられないように、特に注意する必要があります。特に、生成されるトラフィックは、単一の通常のユーザーエンドホストがネットワーク上に作成できるトラフィックを大幅に超えてはなりません。
Following the policies outlined in "Guidelines for Writing an IANA Considerations Section in RFCs" (RFC 5226 [RFC5226]), the following name spaces are defined in PRoPHET.
「RFCのIANAに関する考慮事項セクションを作成するためのガイドライン」（RFC 5226 [RFC5226]）で概説されているポリシーに従って、PRoPHETで次の名前空間が定義されています。
o For fields in the PRoPHET message header (Section 4.1):
o PRoPHETメッセージヘッダーのフィールドの場合（セクション4.1）：
* DTN Routing Protocol Number
* DTNルーティングプロトコル番号
* PRoPHET Protocol Version
* PRoPHETプロトコルバージョン
* PRoPHET Header Flags
* PRoPHETヘッダーフラグ
* PRoPHET Result Field
* PRoPHET結果フィールド
* PRoPHET Codes for Success and Codes for Failure
* 成功のPRoPHETコードと失敗のコード
o Identifiers for TLVs carried in PRoPHET messages:
o PRoPHETメッセージで伝達されるTLVの識別子：
* PRoPHET TLV Type (Section 4.2)
* PRoPHET TLVタイプ（セクション4.2）
o Definitions of TLV Flags and other flag fields in TLVs:
o TLVフラグとTLV内の他のフラグフィールドの定義：
* Hello TLV Flags (Section 4.3.1)
* Hello TLVフラグ（セクション4.3.1）
* Error TLV Flags (Section 4.3.2)
* エラーTLVフラグ（セクション4.3.2）
* Routing Information Base (RIB) Dictionary TLV Flags (Section 4.3.3)
* ルーティング情報ベース（RIB）ディクショナリTLVフラグ（セクション4.3.3）
* Routing Information Base (RIB) TLV Flags (Section 4.3.4)
* ルーティング情報ベース（RIB）TLVフラグ（セクション4.3.4）
* Routing Information Base (RIB) Flags per entry (Section 4.3.4)
* エントリごとのルーティング情報ベース（RIB）フラグ（セクション4.3.4）
* Bundle Offer and Response TLV Flags (Section 4.3.5)
* バンドルオファーおよびレスポンスTLVフラグ（セクション4.3.5）
* Bundle Offer and Response B Flags per offer or response (Section 4.3.5)
* オファーまたはレスポンスごとのバンドルオファーおよびレスポンスBフラグ（セクション4.3.5）
The following subsections list the registries that have been created. Initial values for the registries are given below; future assignments for unassigned values are to be made through the Specification Required policy. Where specific values are defined in the IANA registries according to the specifications in the subsections below, the registry refers to this document as defining the allocation.
以下のサブセクションでは、作成されたレジストリーをリストしています。レジストリの初期値は以下のとおりです。割り当てられていない値の将来の割り当ては、「必要な仕様」ポリシーを通じて行われます。以下のサブセクションの仕様に従ってIANAレジストリに特定の値が定義されている場合、レジストリはこのドキュメントを割り当ての定義として参照します。
The encoding of the Protocol Number field in the PRoPHET header (Section 4.1) is:
PRoPHETヘッダー（セクション4.1）のプロトコル番号フィールドのエンコードは次のとおりです。
+--------------------------+-----------+---------------+
| Protocol | Value | Reference |
+--------------------------+-----------+---------------+
| PRoPHET Protocol | 0x00 | This document |
| Unassigned | 0x01-0xEF | |
| Private/Experimental Use | 0xF0-0xFF | This document |
+--------------------------+-----------+---------------+
The encoding of the PRoPHET Version field in the PRoPHET header (Section 4.1) is:
PRoPHETヘッダー（セクション4.1）のPRoPHETバージョンフィールドのエンコーディングは次のとおりです。
+----------------------------+-----------+---------------+
| Version | Value | Reference |
+----------------------------+-----------+---------------+
| Reserved (do not allocate) | 0x00 | This document |
| PRoPHET v1 | 0x01 | This document |
| PRoPHET v2 | 0x02 | This document |
| Unassigned | 0x03-0xEF | |
| Private/Experimental Use | 0xF0-0xFE | This document |
| Reserved | 0xFF | |
+----------------------------+-----------+---------------+
The following Flags are defined for the PRoPHET Header (Section 4.1):
次のフラグがPRoPHETヘッダーに対して定義されています（セクション4.1）。
+------------+--------------+-----------+
| Meaning | Bit Position | Reference |
+------------+--------------+-----------+
| Unassigned | Bit 0 | |
| Unassigned | Bit 1 | |
| Unassigned | Bit 2 | |
| Unassigned | Bit 3 | |
+------------+--------------+-----------+
The encoding of the Result field in the PRoPHET header (Section 4.1) is:
PRoPHETヘッダー（セクション4.1）のResultフィールドのエンコーディングは次のとおりです。
+--------------------------+-------------+---------------+
| Result Value | Value | Reference |
+--------------------------+-------------+---------------+
| Reserved | 0x00 | This document |
| NoSuccessAck | 0x01 | This document |
| AckAll | 0x02 | This document |
| Success | 0x03 | This document |
| Failure | 0x04 | This document |
| ReturnReceipt | 0x05 | This document |
| Unassigned | 0x06 - 0x7F | |
| Private/Experimental Use | 0x80 - 0xFF | This document |
+--------------------------+-------------+---------------+
The encoding for Code field in the PRoPHET header (Section 4.1) for "Success" messages is:
「成功」メッセージのPRoPHETヘッダー（セクション4.1）のコードフィールドのエンコーディングは次のとおりです。
+--------------------------+-------------+---------------+
| Code Name | Values | Reference |
+--------------------------+-------------+---------------+
| Generic Success | 0x00 | This document |
| Submessage Received | 0x01 | This document |
| Unassigned | 0x02 - 0x7F | |
| Private/Experimental Use | 0x80 - 0xFF | This document |
+--------------------------+-------------+---------------+
The encoding for Code in the PRoPHET header (Section 4.1) for "Failure" messages is:
「失敗」メッセージのPRoPHETヘッダー（セクション4.1）のコードのエンコードは次のとおりです。
+----------------------------+-------------+---------------+
| Code Name | Values | Reference |
+----------------------------+-------------+---------------+
| Reserved (do not allocate) | 0x00 - 0x01 | This document |
| Unspecified Failure | 0x02 | This document |
| Unassigned | 0x03 - 0x7F | |
| Private/Experimental Use | 0x80 - 0xFE | This document |
| Error TLV in Message | 0xFF | This document |
+----------------------------+-------------+---------------+
The TLV Types defined for PRoPHET (Section 4.2) are:
PRoPHET（セクション4.2）に定義されているTLVタイプは次のとおりです。
+------------------------------+-------------+---------------+
| Type | Value | Reference |
+------------------------------+-------------+---------------+
| Reserved (do not allocate) | 0x00 | This document |
| Hello TLV | 0x01 | This document |
| Error TLV | 0x02 | This document |
| Unsassigned | 0x03 - 0x9F | |
| RIB dictionary TLV | 0xA0 | This document |
| RIB TLV | 0xA1 | This document |
| Bundle Offer (deprecated) | 0xA2 | This document |
| Bundle Response (deprecated) | 0xA3 | This document |
| Bundle Offer (v2) | 0xA4 | This document |
| Bundle Response (v2) | 0xA5 | This document |
| Unassigned | 0xA6 - 0xCF | |
| Private/Experimental Use | 0xD0 - 0xFF | This document |
+------------------------------+-------------+---------------+
The following TLV Flags are defined for the Hello TLV (Section 4.3.1). Flag numbers 0, 1, and 2 are treated as a 3-bit unsigned integer with 5 of the 8 possible values allocated, and the other 3 reserved. The remaining bits are treated individually:
Hello TLVには、次のTLVフラグが定義されています（セクション4.3.1）。フラグ番号0、1、2は3ビットの符号なし整数として扱われ、8つの値のうち5つが割り当てられ、残りの3つは予約されています。残りのビットは個別に処理されます。
+----------------------------+---------------------+---------------+
| Meaning | Value | Reference |
+----------------------------+---------------------+---------------+
| | (Flags 0, 1, and 2) | |
| Reserved (do not allocate) | 0b000 | This document |
| SYN | 0b001 | This document |
| SYNACK | 0b010 | This document |
| ACK | 0b011 | This document |
| RSTACK | 0b100 | This document |
| Unassigned | 0b101 - 0b111 | |
| | (Flags 3 - 7) | |
| Unassigned | Flag 3 | |
| Unassigned | Flag 4 | |
| Unassigned | Flag 5 | |
| Unassigned | Flag 6 | |
| L Flag | Flag 7 | This document |
+----------------------------+---------------------+---------------+
The TLV Flags field in the Error TLV (Section 4.3.2) is treated as an unsigned 8-bit integer encoding the Error TLV number. The following values are defined:
エラーTLV（セクション4.3.2）のTLVフラグフィールドは、エラーTLV番号をエンコードする符号なし8ビット整数として扱われます。以下の値が定義されています。
+--------------------------+------------------+---------------+
| Error TLV Name | Error TLV Number | Reference |
+--------------------------+------------------+---------------+
| Dictionary Conflict | 0x00 | This document |
| Bad String ID | 0x01 | This document |
| Unassigned | 0x02 - 0x7F | |
| Private/Experimental Use | 0x80 - 0xFF | This document |
+--------------------------+------------------+---------------+
The following TLV Flags are defined for the RIB Base Dictionary TLV (Section 4.3.3):
次のTLVフラグは、RIBベースディクショナリTLV（セクション4.3.3）に対して定義されています。
+----------------------------+--------------+---------------+
| Meaning | Bit Position | Reference |
+----------------------------+--------------+---------------+
| Sent by Listener | Flag 0 | This document |
| Reserved (do not allocate) | Flag 1 | This document |
| Reserved (do not allocate) | Flag 2 | This document |
| Unassigned | Flag 3 | |
| Unassigned | Flag 4 | |
| Unassigned | Flag 5 | |
| Unassigned | Flag 6 | |
| Unassigned | Flag 7 | |
+----------------------------+--------------+---------------+
The following TLV Flags are defined for the RIB TLV (Section 4.3.4):
次のTLVフラグがRIB TLVに定義されています（セクション4.3.4）。
+----------------------------+--------------+---------------+
| Meaning | Bit Position | Reference |
+----------------------------+--------------+---------------+
| More RIB TLVs | Flag 0 | This document |
| Reserved (do not allocate) | Flag 1 | This document |
| Reserved (do not allocate) | Flag 2 | This document |
| Unassigned | Flag 3 | |
| Unassigned | Flag 4 | |
| Unassigned | Flag 5 | |
| Unassigned | Flag 6 | |
| Unassigned | Flag 7 | |
+----------------------------+--------------+---------------+
The following RIB Flags are defined for the individual entries in the RIB TLV (Section 4.3.4):
次のRIBフラグは、RIB TLVの個々のエントリに対して定義されています（セクション4.3.4）。
+------------+--------------+-----------+
| Meaning | Bit Position | Reference |
+------------+--------------+-----------+
| Unassigned | Flag 0 | |
| Unassigned | Flag 1 | |
| Unassigned | Flag 2 | |
| Unassigned | Flag 3 | |
| Unassigned | Flag 4 | |
| Unassigned | Flag 5 | |
| Unassigned | Flag 6 | |
| Unassigned | Flag 7 | |
+------------+--------------+-----------+
The following TLV Flags are defined for the Bundle Offer and Response TLV (Section 4.3.5):
Bundle Offer and Response TLV（セクション4.3.5）には、次のTLVフラグが定義されています。
+------------------------------------+--------------+---------------+
| Meaning | Bit Position | Reference |
+------------------------------------+--------------+---------------+
| More Offer/Response TLVs Following | Flag 0 | This document |
| Unassigned | Flag 1 | |
| Unassigned | Flag 2 | |
| Unassigned | Flag 3 | |
| Unassigned | Flag 4 | |
| Unassigned | Flag 5 | |
| Unassigned | Flag 6 | |
| Unassigned | Flag 7 | |
+------------------------------------+--------------+---------------+
The following B Flags are defined for each Bundle Offer in the Bundle Offer and Response TLV (Section 4.3.5):
次のBフラグは、バンドルオファーおよびレスポンスTLV（セクション4.3.5）の各バンドルオファーに対して定義されています。
+------------------------------------+--------------+---------------+
| Meaning | Bit Position | Reference |
+------------------------------------+--------------+---------------+
| Bundle Accepted | Flag 0 | This document |
| Bundle is a Fragment | Flag 1 | This document |
| Bundle Payload Length Included in | Flag 2 | This document |
| TLV | | |
| Unassigned | Flag 3 | |
| Unassigned | Flag 4 | |
| Unassigned | Flag 5 | |
| Unassigned | Flag 6 | |
| PRoPHET ACK | Flag 7 | This document |
+------------------------------------+--------------+---------------+
Multiple independent implementations of the PRoPHET protocol exist.
PRoPHETプロトコルの複数の独立した実装が存在します。
The first implementation is written in Java, and has been optimized to run on the Lego MindStorms platform that has very limited resources. Due to the resource constraints, some parts of the protocol have been simplified or omitted, but the implementation contains all the important mechanisms to ensure proper protocol operation. The implementation is also highly modular and can be run on another system with only minor modifications (it has currently been shown to run on the Lego MindStorms platform and on regular laptops).
最初の実装はJavaで書かれており、リソースが非常に限られているLego MindStormsプラットフォームで実行するように最適化されています。リソースの制約により、プロトコルの一部は簡略化または省略されていますが、実装には適切なプロトコル操作を保証するための重要なメカニズムがすべて含まれています。実装も高度にモジュール化されており、わずかな変更を加えるだけで別のシステムで実行できます（現在、レゴMindStormsプラットフォームと通常のラップトップで実行することが示されています）。
Another implementation is written in C++ and runs in the OmNet++ simulator to enable testing and evaluation of the protocol and new features. Experience and feedback from the implementers on early versions of the protocol have been incorporated into the current version.
別の実装はC ++で記述され、OmNet ++シミュレーターで実行され、プロトコルと新機能のテストと評価を可能にします。プロトコルの初期バージョンに関する実装者からの経験とフィードバックは、現在のバージョンに組み込まれています。
An implementation compliant to an Internet-Draft (which was posted in 2006 and eventually evolved into this RFC) has been written at Baylor University. This implementation has been integrated into the DTN2 reference implementation.
（2006年に投稿され、最終的にはこのRFCに発展した）インターネットドラフトに準拠した実装がベイラー大学で作成されました。この実装は、DTN2リファレンス実装に統合されています。
An implementation of the protocol in C++ was developed by one of the authors (Samo Grasic) at Lulea University of Technology (LTU) as part of the Saami Networking Connectivity project (see Section 9) and continues to track the development of the protocol. This work is now part of the Networking for Communications Challenged Communities (N4C) project and is used in N4C testbeds.
C ++でのプロトコルの実装は、Salea Networking Connectivityプロジェクト（セクション9を参照）の一部としてLulea工科大学（LTU）の著者（Samo Grasic）によって開発され、プロトコルの開発の追跡を続けています。この作業は現在、Networking for Communications Challenged Communities（N4C）プロジェクトの一部であり、N4Cテストベッドで使用されています。
During a week in August 2006, a proof-of-concept deployment of a DTN system, using the LTU PRoPHET implementation for routing was made in the Swedish mountains -- the target area for the Saami Network Connectivity project [ccnc07] [doria_02]. Four fixed camps with application gateways, one Internet gateway, and seven mobile relays were deployed. The deployment showed PRoPHET to be able to route bundles generated by different applications such as email and web caching.
2006年8月の1週間に、ルーティングにLTU PRoPHET実装を使用したDTNシステムの概念実証展開が、Saami Network Connectivityプロジェクト[ccnc07] [doria_02]のターゲットエリアであるスウェーデンの山で行われました。アプリケーションゲートウェイ、1つのインターネットゲートウェイ、および7つのモバイルリレーを備えた4つの固定キャンプが展開されました。デプロイメントにより、PRoPHETは、EメールやWebキャッシングなどのさまざまなアプリケーションによって生成されたバンドルをルーティングできることがわかりました。
Within the realms of the SNC and N4C projects, multiple other deployments, both during summer and winter conditions, have been done at various scales during 2007-2010 [winsdr08].
SNCおよびN4Cプロジェクトの領域では、2007年から2010年の間に、夏と冬の両方の条件で、他の複数の展開がさまざまな規模で行われています[winsdr08]。
An implementation has been made for Android-based mobile telephones in the Bytewalla project [bytewalla].
Bytewallaプロジェクト[bytewalla]で、Androidベースの携帯電話の実装が行われました。
The authors would like to thank Olov Schelen and Kaustubh S. Phanse for contributing valuable feedback regarding various aspects of the protocol. We would also like to thank all other reviewers and the DTNRG chairs for the feedback in the process of developing the protocol. The Hello TLV mechanism is loosely based on the Adjacency message developed for RFC 3292. Luka Birsa and Jeff Wilson have provided us with feedback from doing implementations of the protocol based on various preliminary versions of the document. Their feedback has helped us make the document easier to read for an implementer and has improved the protocol.
著者は、プロトコルのさまざまな側面に関する貴重なフィードバックを提供してくれたOlov SchelenおよびKaustubh S. Phanseに感謝します。また、プロトコルの開発プロセスにおけるフィードバックについて、他のすべてのレビュー担当者とDTNRGの議長に感謝します。 Hello TLVメカニズムは、大まかにRFC 3292用に開発された隣接メッセージに基づいています。LukaBirsaとJeff Wilsonは、ドキュメントのさまざまな予備バージョンに基づいてプロトコルの実装を行うことからフィードバックを提供してくれました。彼らのフィードバックは、実装者がドキュメントを読みやすくするのに役立ち、プロトコルを改善しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007.
[RFC5050]スコット、KおよびS.バーレイ、「バンドルプロトコル仕様」、RFC 5050、2007年11月。
[CLAYER] Demmer, M., Ott, J., and S. Perreault, "Delay Tolerant Networking TCP Convergence Layer Protocol", Work in Progress, August 2012.
[CLAYER] Demmer、M.、Ott、J。、およびS. Perreault、「Delay Tolerant Networking TCP Convergence Layer Protocol」、Work in Progress、2012年8月。
[RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, June 1988.
[RFC1058] Hedrick、C。、「Routing Information Protocol」、RFC 1058、1988年6月。
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking Architecture", RFC 4838, April 2007.
[RFC4838] Cerf、V.、Burleigh、S.、Hooke、A.、Torgerson、L.、Durst、R.、Scott、K.、Fall、K。、およびH. Weiss、「Delay-Tolerant Networking Architecture」 、RFC 4838、2007年4月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell, "Bundle Security Protocol Specification", RFC 6257, May 2011.
[RFC6257] Symington、S.、Farrell、S.、Weiss、H。、およびP. Lovell、「Bundle Security Protocol Specification」、RFC 6257、2011年5月。
[bytewalla] Prasad, M., "Bytewalla 3: Network architecture and PRoPHET implementation", Bytewalla Project, KTH Royal Institute of Technology, Stockholm, Sweden, October 2010, <http://www.bytewalla.org/sites/bytewalla.org/files/ Bytewalla3_Network_architecture_and_PRoPHET_v1.0.pdf>.
[bytewalla] Prasad、M。、「Bytewalla 3：ネットワークアーキテクチャとPRoPHETの実装」、Bytewallaプロジェクト、KTH Royal Institute of Technology、ストックホルム、スウェーデン、2010年10月、<http://www.bytewalla.org/sites/bytewalla。 org / files / Bytewalla3_Network_architecture_and_PRoPHET_v1.0.pdf>。
[ccnc07] Lindgren, A. and A. Doria, "Experiences from Deploying a Real-life DTN System", Proceedings of the 4th Annual IEEE Consumer Communications and Networking Conference (CCNC 2007), Las Vegas, Nevada, USA, January 2007.
[ccnc07] Lindgren、A。およびA. Doria、「Experiences from Deploying a Real-life DTN System」、Proceedings of the 4 Annual IEEE Consumer Communications and Networking Conference（CCNC 2007）、Las Vegas、Nevada、USA、2007年1月。
[doria_02] Doria, A., Uden, M., and D. Pandey, "Providing connectivity to the Saami nomadic community", Proceedings of the 2nd International Conference on Open Collaborative Design for Sustainable Innovation (dyd 02), Bangalore, India, December 2002.
[doria_02] Doria、A.、Uden、M。、およびD. Pandey、「Saami遊牧コミュニティへの接続の提供」、第2回持続可能な国際イノベーションのためのオープンコラボレーションデザインに関する国際会議（dyd 02）、インド、バンガロール、 2002年12月。
[lindgren_06] Lindgren, A. and K. Phanse, "Evaluation of Queueing Policies and Forwarding Strategies for Routing in Intermittently Connected Networks", Proceedings of COMSWARE 2006, January 2006.
[lindgren_06] Lindgren、A。およびK. Phanse、「断続的に接続されたネットワークでのルーティングのためのキューイングポリシーおよび転送戦略の評価」、COMSWARE 2006の議事録、2006年1月。
[vahdat_00] Vahdat, A. and D. Becker, "Epidemic Routing for Partially Connected Ad Hoc Networks", Duke University Technical Report CS-200006, April 2000.
[vahdat_00] Vahdat、A。およびD. Becker、「部分的に接続されたアドホックネットワークの流行ルーティング」、デューク大学テクニカルレポートCS-200006、2000年4月。
[winsdr08] Lindgren, A., Doria, A., Lindblom, J., and M. Ek, "Networking in the Land of Northern Lights - Two Years of Experiences from DTN System Deployments", Proceedings of the ACM Wireless Networks and Systems for Developing Regions Workshop (WiNS-DR), San Francisco, California, USA, September 2008.
[winsdr08] Lindgren、A.、Doria、A.、Lindblom、J。、およびM. Ek、「オーロラの土地でのネットワーキング-DTNシステム導入からの2年間の経験」、ACMワイヤレスネットワークおよびシステムのプロシーディングス開発地域ワークショップ（WiNS-DR）、米国カリフォルニア州サンフランシスコ、2008年9月。
To help grasp the concepts of PRoPHET, an example is provided to give an understanding of the transitive property of the delivery predictability and the basic operation of PRoPHET. In Figure 13, we revisit the scenario where node A has a message it wants to send to node D. In the bottom right corner of subfigures a-c, the delivery predictability tables for the nodes are shown. Assume that nodes C and D encounter each other frequently (Figure 13a), making the delivery predictability values they have for each other high. Now assume that node C also frequently encounters node B (Figure 13b). Nodes B and C will get high delivery predictability values for each other, and the transitive property will also increase the value B has for D to a medium level. Finally, node B meets node A (Figure 13c), which has a message for node D. Figure 13d shows the message exchange between node A and node B. Summary vectors and delivery predictability information is exchanged, delivery predictabilities are updated, and node A then realizes that P_(b,d) > P_(a,d), and thus forwards the message for node D to node B.
PRoPHETの概念を理解するために、配信の予測可能性の推移的な特性とPRoPHETの基本操作を理解するための例が提供されています。図13では、ノードAがノードDに送信したいメッセージを持っているシナリオを再検討します。サブフィギュアa-cの右下隅に、ノードの配信予測テーブルが表示されます。ノードCとDが頻繁に遭遇し（図13a）、お互いの配信予測可能性の値が高くなっていると想定します。次に、ノードCもノードBに頻繁に遭遇するとします（図13b）。ノードBとCは、互いに高い配信予測可能性の値を取得し、推移的プロパティは、Dに対するBの値を中程度に増加させます。最後に、ノードBはノードA（図13c）に出会い、ノードDに対するメッセージが表示されます。図13dは、ノードAとノードBの間のメッセージ交換を示しています。要約ベクトルと配信予測可能性情報が交換され、配信予測可能性が更新され、ノードA次に、P_（b、d）> P_（a、d）であることを認識し、ノードDのメッセージをノードBに転送します。
+----------------------------+ +----------------------------+
| | | |
| C | | D |
| D | | |
| B | | B C |
| | | |
| | | |
| | | |
| | | |
| A* | | A* |
+-------------+--------------+ +-------------+--------------+
| A | B | C | D | | A | B | C | D |
|B:low |A:low |A:low |A:low | |B:low |A:low |A:low |A:low |
|C:low |C:low |B:low |B:low | |C:low |C:high|B:high |B:low |
|D:low |D:low |D:high |C:high| |D:low |D:med |D:high |C:high|
+-------------+--------------+ +-------------+--------------+
(a) (b)
+----------------------------+ A B
| | | |
| D | |Summary vector&delivery pred|
| | |--------------------------->|
| C | |Summary vector&delivery pred|
| | |<---------------------------|
| | | |
| B* | Update delivery predictabilities
| A | | |
| | Packet for D not in SV |
+-------------+--------------+ P(b,d)>P(a,d) |
| A | B | C | D | Thus, send |
|B:low |A:low |A:low |A:low | | |
|C:med |C:high|B:high |B:low | | Packet for D |
|D:low+|D:med |D:high |C:high| |--------------------------->|
+-------------+--------------+ | |
(c) (d)
Figure 13: PRoPHET example
図13：PRoPHETの例
This section outlines an example of a simple neighbor discovery protocol that can be run in-between PRoPHET and the underlying layer in case lower layers do not provide methods for neighbor discovery. It assumes that the underlying layer supports broadcast messages as would be the case if a wireless infrastructure was involved.
このセクションでは、下位層がネイバー探索の方法を提供しない場合に、PRoPHETとその下層の間で実行できる単純なネイバー探索プロトコルの例を概説します。ワイヤレスインフラストラクチャが関係する場合のように、基になるレイヤーがブロードキャストメッセージをサポートすることを前提としています。
Each node needs to maintain a list of its active neighbors. The operation of the protocol is as follows:
各ノードは、アクティブなネイバーのリストを維持する必要があります。プロトコルの操作は次のとおりです。
1. Every BEACON_INTERVAL milliseconds, the node does a local broadcast of a beacon that contains its identity and address, as well as the BEACON_INTERVAL value used by the node.
1. BEACON_INTERVALミリ秒ごとに、ノードはそのIDとアドレス、およびノードが使用するBEACON_INTERVAL値を含むビーコンのローカルブロードキャストを行います。
2. Upon reception of a beacon, the following can happen:
2. ビーコンを受信すると、次のことが起こります。
A. The sending node is already in the list of active neighbors. Update its entry in the list with the current time, and update the node's BEACON_INTERVAL if it has changed.
A.送信ノードはすでにアクティブネイバーのリストに含まれています。リストのエントリを現在の時刻で更新し、ノードのBEACON_INTERVALが変更されている場合は更新します。
B. The sending node is not in the list of active neighbors. Add the node to the list of active neighbors and record the current time and the node's BEACON_INTERVAL. Notify the PRoPHET agent that a new neighbor is available ("New Neighbor", as described in Section 2.4).
B.送信ノードはアクティブなネイバーのリストにありません。ノードをアクティブなネイバーのリストに追加し、現在の時刻とノードのBEACON_INTERVALを記録します。新しいネイバーが利用可能であることをPRoPHETエージェントに通知します（セクション2.4で説明されている「新しいネイバー」）。
3. If a beacon has not been received from a node in the list of active neighbors within a time period of NUM_ACCEPTED_LOSSES * BEACON_INTERVAL (for the BEACON_INTERVAL used by that node), it should be assumed that this node is no longer a neighbor. The entry for this node should be removed from the list of active neighbors, and the PRoPHET agent should be notified that a neighbor has left ("Neighbor Gone", as described in Section 2.4).
3. NUM_ACCEPTED_LOSSES * BEACON_INTERVAL（そのノードで使用されるBEACON_INTERVALの場合）の期間内にアクティブなネイバーのリスト内のノードからビーコンが受信されなかった場合、このノードはもはやネイバーではないと見なされます。このノードのエントリは、アクティブなネイバーのリストから削除する必要があり、PRoPHETエージェントには、ネイバーが去ったことを通知する必要があります（セクション2.4で説明されている「Neighbor Gone」）。
The evolution of the delivery predictabilities in a PRoPHET node is controlled by three main equations defined in Section 2.1.2. These equations use a number of parameters that need to be appropriately configured to ensure that the delivery predictabilities evolve in a way that mirrors the mobility model that applies in the PRoPHET zone where the node is operating.
PRoPHETノードの配信予測可能性の進化は、セクション2.1.2で定義された3つの主要な方程式によって制御されます。これらの方程式は、ノードが動作しているPRoPHETゾーンで適用されるモビリティモデルを反映する方法で配信の予測可能性が確実に進化するように適切に構成する必要があるいくつかのパラメーターを使用します。
When trying to describe the mobility model, it is more likely that the model will be couched in terms of statistical distribution of times between encounters and times to deliver a bundle in the zone. In this section, one possible way of deriving the PRoPHET parameters from a more usual description of the model is presented. It should be remembered that this may not be the only solution, and its appropriateness will depend both on the overall mobility model and the distribution of the times involved. There is an implicit assumption in this work that these distributions can be characterized by a normal-type distribution with a well-defined first moment (mean). The exact form of the distribution is not considered here, but more detailed models may wish to use more specific knowledge about the distributions to refine the derivation of the parameters.
モビリティモデルを記述しようとする場合、遭遇とゾーン内のバンドルを配信する時間との間の時間の統計的分布の観点から、モデルが推奨される可能性が高くなります。このセクションでは、モデルのより一般的な説明からPRoPHETパラメータを導出する1つの可能な方法を示します。これが唯一の解決策ではない可能性があること、およびその適切性は全体的なモビリティモデルと関係する時間の分布の両方に依存することに注意してください。この研究には、これらの分布が明確に定義された一次モーメント（平均）を持つ正規型分布によって特徴付けられるという暗黙の仮定があります。分布の正確な形式はここでは考慮されていませんが、より詳細なモデルでは、分布に関するより具体的な知識を使用してパラメーターの導出を調整することが必要な場合があります。
To characterize the model, we consider the following parameters:
モデルを特徴付けるために、以下のパラメーターを考慮します。
P1 The time resolution of the model.
P1モデルの時間分解能。
P2 The average time between encounters between nodes, I_typ, where the identity of the nodes is not taken into account.
P2ノード間の遭遇間の平均時間、I_typ。ノードのIDは考慮されません。
P3 The average number of encounters that a node has between meeting a particular node and meeting the same node again.
P3ノードが特定のノードに会ってから同じノードに再度会うまでの間に遭遇する平均の数。
P4 The average number of encounters needed to deliver a bundle in this zone.
P4このゾーンでバンドルを配信するために必要な遭遇の平均数。
P5 The multiple of the average number of encounters needed to deliver a bundle (P4) after which it can be assumed that a node is not going to encounter a particular node again in the foreseeable future so that the delivery predictability ought to be decayed below P_first_threshold.
P5バンドルの配信に必要な遭遇の平均数の倍数（P4）その後、ノードは予見可能な将来に特定のノードに再び遭遇することはないため、配信の予測可能性はP_first_thresholdを下回るはずです。 。
P6 The number of encounters between a particular pair of nodes that should result in the delivery predictability of the encountered node getting close to the maximum possible delivery predictability (1 - delta).
P6遭遇したノードの配信予測可能性が可能な最大の配信予測可能性（1-デルタ）に近づく結果となる特定のノードのペア間の遭遇の数。
We can use these parameters to derive appropriate values for gamma and P_encounter_max, which are the key parameters in the evolution of the delivery predictabilities. The values of the other parameters P_encounter_first (0.5), P_first_threshold (0.1), and delta (0.01), with the default values suggested in Figure 3, generally are not specific to the mobility model, although in special cases P_encounter_first may be different if extra information is available.
これらのパラメーターを使用して、配信の予測可能性の進化における重要なパラメーターであるgammaおよびP_encounter_maxの適切な値を導出できます。他のパラメーターP_encounter_first（0.5）、P_first_threshold（0.1）、およびdelta（0.01）の値は、図3で提案されているデフォルト値を使用して、一般にモビリティモデルに固有ではありませんが、特別なケースではP_encounter_firstが異なる場合がある情報が利用可能です。
To select a value for gamma:
After a single, unrepeated encounter, the delivery predictability of
the encountered node should decay from P_encounter_first to
P_first_threshold in the expected time for P4 * P5 encounters. Thus:
P_first_threshold = P_encounter_first * gamma ^ ((P2 * P4 * P5)/P1)
which can be rearranged as
これは次のように再配置できます
gamma = exp(ln(P_first_threshold/P_encounter_first) * P1 / (P2* P4 * P5)).
gamma = exp（ln（P_first_threshold / P_encounter_first）* P1 /（P2 * P4 * P5））。
Typical values of gamma will be less than 1, but very close to 1 (usually greater than 0.99). The value has to be stored to several decimal places of accuracy, but implementations can create a table of values for specific intervals to reduce the amount of on-the-fly calculation required.
ガンマの一般的な値は1未満ですが、1に非常に近くなります（通常は0.99より大きい）。値は小数点以下第2位までの精度で格納する必要がありますが、実装では、特定の間隔の値のテーブルを作成して、必要なオンザフライ計算の量を減らすことができます。
Selecting a value for P_encounter_max:
Once gamma has been determined, the decay factor for the average time
between encounters between a specific pair of nodes can be
calculated:
Decay_typ = gamma ^ ((P2 * P3)/P1)
Starting with P_encounter_first, using Decay_typ and applying Equation 1 from Section 2.1.2 (P6 - 1) times, we can calculate the typical delivery predictability for the encountered node after P6 encounters. The nature of Equation 1 is such that it is not easy to produce a closed form that generates a value of P_encounter_max from the parameter values, but using a spreadsheet to apply the equation repeatedly and tabulate the results will allow a suitable value of P_encounter_max to be chosen very simply. The evolution is not very sensitive to the value of P_encounter_max, and values in the range 0.4 to 0.8 will generally be appropriate. A value of 0.7 is recommended as a default.
P_encounter_firstから始め、Decay_typを使用し、セクション2.1.2（P6-1）の式1を適用すると、P6が検出された後の検出されたノードの一般的な配信予測可能性を計算できます。式1の性質により、パラメーター値からP_encounter_maxの値を生成する閉じたフォームを生成するのは容易ではありませんが、スプレッドシートを使用して式を繰り返し適用し、結果を表にすると、P_encounter_maxの適切な値を非常に簡単に選択しました。進化はP_encounter_maxの値にそれほど敏感ではなく、一般に0.4〜0.8の範囲の値が適切です。デフォルトとして0.7の値が推奨されます。
Once a PRoPHET zone has been in operation for some time, the logs of the actual encounters can and should be used to check that the selected parameters were appropriate and to tune them as necessary. In the longer term, it may prove possible to install a learning mode in nodes so that the parameters can be adjusted dynamically to maintain best congruence with the mobility model that may itself change over time.
PRoPHETゾーンがしばらく稼働していると、実際の遭遇のログを使用して、選択したパラメーターが適切であったことを確認し、必要に応じて調整することができます。長期的には、ノードに学習モードをインストールして、時間とともに変化する可能性のあるモビリティモデルとの最適な一致を維持するようにパラメータを動的に調整できるようになる可能性があります。
Authors' Addresses
著者のアドレス
Anders F. Lindgren Swedish Institute of Computer Science Box 1263 Kista SE-164 29 SE
Anders F. Lindgren Swedish Institute of Computer Science Box 1263 Kista SE-164 29 SE
Phone: +46707177269
EMail: andersl@sics.se
URI: http://www.sics.se/~andersl
Avri Doria Technicalities Providence RI US
あｖり どりあ てｃｈにかぃちえｓ Ｐろゔぃでんせ り うＳ
EMail: avri@acm.org
URI: http://psg.com/~avri
Elwyn Davies Folly Consulting Soham UK
Elwyn Davies Folly Consulting Soham UK
EMail: elwynd@folly.org.uk
Samo Grasic Lulea University of Technology Lulea SE-971 87 SE
サモグラシックルレオ工科大学ルレオSE-971 87 SE
EMail: samo.grasic@ltu.se