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
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.
本文件是耐延迟网络研究小组的产品，该小组已对其进行了审查。没有人反对将其作为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.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
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
本文档为互联网社区定义了一个实验协议。本文件是互联网研究工作组（IRTF）的产品。IRTF发布互联网相关研究和开发活动的结果。这些结果可能不适合部署。该RFC代表了互联网研究的延迟容忍网络研究小组的共识
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.
工作队。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.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
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
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
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）网络的最基本要求之一是，在通信会话期间，通信端点之间必须存在完全连接的路径，以便能够进行通信。然而，在许多情况下，连接是断断续续的，因此情况并非如此（从而使传统网络协议的端到端使用变得不可能），但仍然需要允许节点之间的通信。
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".
在这种情况下，实现通信的一种方法是允许消息在中间节点缓冲的时间比传统路由器队列中通常出现的时间长（参见延迟容忍网络[RFC4838]）。然后，就有可能利用节点子集的移动性，通过在它们相遇时将消息传输到其他节点，使消息更接近它们的目的地。图1显示了在这种情况下，如何使用节点的移动性最终将消息传递到其目的地。在该图中，四个子图（a）-（d）表示四个节点（a、B、C和d）在四个时间瞬间的物理位置，从（a）增加到（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基本上是一个带有严格修剪的流行病协议。流行病协议的工作原理是将其数据传输到它遇到的每个节点。当数据从一个节点传递到另一个节点时，它最终会传递到所有节点，包括目标节点。流行病协议的优点之一是，通过尝试每一条路径，可以保证尝试最佳路径。流行病协议的缺点之一是资源的广泛使用，每个节点都需要携带每个数据包以及相关的传输成本。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)
+----------------------------+ +----------------------------+
| ___ | | ___ |
| ___ / \ | | / \ |
| / \ ( 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
延迟容忍网络（DTN）体系结构[RFC4838]定义了一种在由于过度延迟、链路中断和其他极端条件而无法使用传统通信协议的环境中进行通信的体系结构。此处考虑的间歇性连接网络是DTN体系结构所涵盖网络的子集。DTN体系结构定义了基于“联系人”集合计算的路由，这些联系人指示拓扑图中链路的开始时间、持续时间、端点、转发容量和延迟。这些触点可以是确定性的，也可以是非确定性的
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.
根据估计得出。该体系结构定义了一些不同类型的间歇性触点。被称为“机会主义”和“预测”的是本协议所述的。
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预期适用的示例，但适用性并不限于包括人类在内的场景。
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协议期望节点能够建立本地TCP链路，以便交换PRoPHET协议所需的信息。协议信令通过该TCP链路在带外完成，不涉及捆绑协议代理[RFC5050]。但是，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在两个对等方之间提供可靠的双向通道，并保证传输数据的有序传递。在使用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提供了可靠的传输，因此当PRoPHET通过TCP传输或类似协议运行时，建议不要使用肯定确认功能。在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都希望使用双向链路进行信息交换；这使得信息交换可以在同一链路上的两个方向上进行，从而避免了为反向信息交换建立第二个链路的需要。
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
在大延迟和中断容忍网络（DTN）中，网络条件可能会有很大差异，在网络的不同部分，可能适用不同的路由协议。在本规范中，我们考虑在单个“先知区”中的路由，这是一组节点，其中消息使用先知路由。在许多情况下，PRoPHET区域不会跨越整个DTN，但网络的其他部分会具有运行其他路由协议的其他特性。要处理此问题，区域内可能有节点充当到其他节点的网关
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.
作为区域内生成的捆绑包的目标或将捆绑包插入区域的节点。因此，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中，该信息通过删除那些看起来不太可能提供有效路径以将数据传递到其预期目的地的路径来修剪流行路径树。这种差异的一个影响是[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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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的主要体系结构，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).
为了实现这一点，在每个已知目的地B的每个节点a处建立一个称为“交付可预测性”的度量，即0<=P_（a，B）<=1。计算该度量，以便对某个目的地具有较高值的节点被估计为向该目的地交付捆绑包的更好候选节点（即，如果P_（a，B）>P_（C，B），目的地B的捆绑包最好转发到A，而不是C）。稍后在做出转发决策时使用。由于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.
当两个PRoPHET节点有通信机会时，它们首先进入两部分信息交换阶段（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.
在遭遇战期间，交付可预测性更新的计算分为三个部分。
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
当两个节点相遇时，它们要做的第一件事是更新彼此的交付可预测性，以便经常遇到的节点具有较高的交付可预测性。如果节点B很长一段时间没有遇到节点A，或者从未遇到节点B，使得P_u（A，B）<P_first_阈值，那么P_u（A，B）应该设置为P_first_。因为PRoPHET通常不知道这是一次相对频繁的遭遇还是一次罕见的遭遇，所以P_遭遇_首先应该
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.
将设置为0.5，除非节点具有通过PRoPHET协议以外的其他方式获得的关于未来相遇可能性的额外信息。否则，P_（A，B）应按照方程式1所示进行计算，其中0<=P_遭遇<=1是一个比例因子，用于设置第一次遭遇后可预测性增加的速率，而δ是一个小的正数，有效地设置了P_（A，B）的上限。设置该限制是为了使不同节点之间的可预测性严格小于1。delta的值通常应非常小（例如，0.01），以便不会显著限制可用可预测性的范围，但在重要的情况下，可以选择delta使计算有效。
P_(A,B) =
P_(A,B)_old + ( 1 - delta - P_(A,B)_old ) * P_encounter (Eq. 1)
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 ad-hoc模式相互通信的移动节点可能会产生明显的多次相遇，其间间隔很短，但这通常是由于使用无线连接时底层物理网络的伪影造成的，传输问题或位置的微小变化可能导致重复重新连接。在这种情况下，将每次机会的交付可预测性增加相同的数量是不合适的，因为在正常流动模式下，当相遇间隔较长时，交付可预测性会增加。
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_遭遇是自上次遭遇导致交付可预测性更新以来的时间间隔的函数。函数的形式如图2所示。
P_encounter
^
|
P_encounter_max + - - .-------------------------------------
| /
| / .
| /
| / .
| /
| / .
|/
+-------+-------------------------------------> I
I_typ
P_encounter
^
|
P_encounter_max + - - .-------------------------------------
| /
| / .
| /
| / .
| /
| / .
|/
+-------+-------------------------------------> I
I_typ
Figure 2: P_encounter as function of time interval, I, between updates
图2：P_遭遇作为更新之间时间间隔I的函数
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_遭遇被设置为固定值P_遭遇最大值。断点反映了“正常”通信机会机制之间的转换（其中机会来自整体移动模式）以及由用于提供这些机会的无线技术的有效本地工件产生的紧密间隔的机会。
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_遭遇_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_遭遇依赖于间隔时间还可以避免在节点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
如果一对节点在某个时间间隔内没有相遇，它们就不太可能成为捆绑包的良好转发器，因此交付可预测性值必须老化，并在过程中降低。度量值更新的第二部分是等式2中所示老化方程的应用，其中0<=gamma<=1是老化常数，K是自上次度量老化以来经过的时间单位数。这个
time unit used can differ and should be defined based on the application and the expected delays in the targeted network.
使用的时间单位可能不同，应根据应用程序和目标网络中的预期延迟来定义。
P_(A,B) = P_(A,B)_old * gamma^K (Eq. 2)
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（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)
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和从遇到的节点B（例如，P_B（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节中描述的三个方程中使用的各种参数在每个节点中独立设置，因此，可能会在配置了不同参数值的节点之间发生碰撞。本节考虑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节所述。
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_和P_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δ）。然而，在某些特殊情况下，另一个节点的交付可预测性可能适合为1。例如，如果使用PRoPHET的DTN有多个网关连接到连续连接的Internet，则从PRoPHET在一个网关中看到的其他网关节点的交付可预测性可以被视为1，因为它们通过Internet永久连接。这将允许流量通过最有利的网关转发到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:
为了使交付的可预测性具有更平滑的变化率，节点可以应用以下方法之一：
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节方程式的输入。然后丢弃列表中最旧的值，并将新值写入列表的“最新”位置。当需要传递可预测性值时（用于发送到对等节点，或用于做出转发决策），将计算列表中值的平均值，然后使用该值。如果列表中输入的数值小于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）。EWMA随后用于做出转发决策并向对等节点报告，但根据第2.1.2节计算的值仍然用作新交付可预测性计算的输入。EWMA根据等式4计算，其中0<=α<=1是最新值的权重。
P_ewma = P_ewma_old * (1 - alpha) + P * alpha (Eq. 4)
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.
alpha的适当选择可能因应用场景情况而异。除非事先了解该场景，否则建议将alpha设置为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_阈值的交付可预测性，其中P_first_阈值是一个小数字，就好像它们是零一样，因此它们不需要存储或包括在信息交换阶段期间发送的列表中。如果使用此优化，则必须小心选择P_first_阈值，使其小于该节点作为转发器的目的地在网络中通常存在的交付可预测性值。有可能
P_first_threshold could be calculated based on delivery predictability ranges and the amount they change historically, but this has not been investigated yet.
P_first_阈值可以根据交付可预测性范围及其历史变化量来计算，但尚未对此进行调查。
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.
bundle，决定接受和/或放弃哪些bundle以保持良好的性能，在不同的场景中可能需要不同的策略。
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.
bundle协议[RFC5050]引入了“bundle协议代理”的概念，该代理管理应用程序和“汇聚层”之间的接口，后者在通信机会期间提供节点之间的bundle传输。本规范使用路由代理扩展捆绑协议代理，该路由代理在（机会主义）通信机会期间控制捆绑协议代理的操作。
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协议代理提供一个新的Bundle来存储。
Bundle Delivered Tells the bundle protocol agent that a bundle was delivered to its destination.
Bundle Delivered告诉Bundle协议代理一个Bundle已传递到其目标。
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.
Drop Bundle Advice建议Bundle协议代理将来不应提供指定的Bundle进行转发，如果合适，Bundle协议代理可能会删除该Bundle。
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区域中的网关节点可以使用路由导出来导出可达性信息（目的地EID和相应的交付可预测性），以供DTN其他部分中的路由协议使用。
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可以将从通信节点请求的捆绑包通知捆绑协议代理。然后，当相关包到达节点或交付到本地应用程序时，可以将Accept Bundle和Bundle Delivered函数实现为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之间存在转换功能，则应使用该功能设置交付可预测性。如果不存在此类翻译功能，则交付可预测性应设置为1。对于导出的路线，当前交付可预测性将与路线一起导出。
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节点需要知道其邻居的身份，以及新邻居出现和旧邻居消失的时间。一些无线网络技术可能已经包含了检测邻居和保持这种状态的机制。为了避免冗余和低效，PRoPHET中不包含邻居发现，但PRoPHET在较低的层中依赖这种机制。较低的层必须提供下面列出的两个功能。如果底层网络技术不支持此类服务，则可以在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 agent发出信号，表示新节点已成为邻居。邻居在这里被定义为当前在使用的无线网络技术的通信范围内的另一个节点。PRoPHET代理现在应该按照第5.2节所述启动Hello过程。
Neighbor Gone Signals to the PRoPHET agent that one of its neighbors has left.
邻居走了向先知特工发出信号，说它的一个邻居已经走了。
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协议包括两个主要阶段：
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.
当检测到新邻居时，协议开始通过Hello消息交换与该节点建立链接，如第5.2节所述。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_相遇的值取决于传递可预测性更新之间的间隔时间，但对于较长的间隔，P_相遇的值是一个常数。
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
为了利用这种时间依赖性，PRoPHET维护一个由端点标识符（EID）标识的最近遇到的节点列表，该节点用于标识通信会话，并包含与该节点的最后一次通信会话的开始时间。此列表的大小受到控制，因为
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.
不接触并且在当前连接之前超过一段时间才开始上一次连接的节点可以从列表中删除。它还保存了衰减函数（方程式2）最后应用于节点中交付可预测性的时间记录。
The Information Exchange Phase involves two parts:
信息交流阶段包括两个部分：
o establishing the Router Information Base (RIB Exchange Sub-Phase), and
o 建立路由器信息库（RIB交换子阶段），以及
o exchanging bundles using this information (Bundle Passing Sub-Phase).
o 使用此信息交换捆绑包（捆绑包通过子阶段）。
Four types of information are exchanged during this process:
在此过程中，交换了四种类型的信息：
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.
在通信机会期间，如本节其余部分所述，每种类型的信息的若干组可以在每个方向上传输。每一组都可以在一条或多条消息中传输。当（且仅当）使用本文档中设想的面向连接的可靠传输协议（如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
PRoPHET的规范还提供了子消息机制和重传，允许以较小的块传输较高级别指定的大型消息。该机制最初用于允许PRoPHET在不可靠的传输协议（如UDP）上运行，但也可用于可靠的传输协议
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.
如果高级软件不希望处理消息碎片，则传输。但是，如果传输协议已经提供了可靠的顺序传递，则顺序和长度会增加冗余的开销。
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（类型长度值消息组件）的消息。这组消息包含将在路由信息库（RIB）中列出的节点的端点标识符（EID）字典；有关本词典的更多信息，请参见第3.2.1节。在此之后，将发送一条或多条包含路由信息基TLV的消息。该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
做出此决定后，准备一个或多个Bundle Offer TLV，列出对等节点希望提供给发送RIB的接收方节点的所有Bundle的Bundle标识符及其目的地。如[RFC5050]所述，捆绑标识最多由五个组成部分组成。对于完整的捆绑包，标识符包括
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
此外，对于bundle片段，标识符还包含
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
如果任何捆绑包提供TLV列出的捆绑包的源或目标EID未包含在发送的前一组RIBD信息中，则接下来将发送一个或多个新的RIBD TLV，并对字典进行增量更新。当接收方节点有一个包含所有必要EID的字典时，Bundle Offer TLV将被发送到
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还包含PRoPHET Ack列表（见第3.5节）。如果接收方节点在Hello阶段请求，Bundle Offer TLV还将指定所有Bundle的有效负载长度，而不仅仅是片段的有效负载长度。接收节点可以使用此信息来帮助从提供的列表中选择要接受的捆绑包，尤其是在可用捆绑包存储容量有限的情况下。
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字典，将优先列表发送到一个或多个捆绑产品响应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.
当一个新包到达一个节点时，该节点可以检查其可用邻居的列表，如果其中一个邻居是转发该包的候选者，则可以向该节点发送一个新的包提供TLV。如果两个节点在较长时间内保持连接，信息交换阶段将定期重新启动，以允许通过网络传播新的交付可预测性信息，并进行新的捆绑交换。
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字典。本词典将可能相当长的可变长度EID（如[RFC4838]中所定义）映射为较短的数字标识符，编码为自定界数值（SDNV——见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
此字典是两个对等节点之间的共享资源。每个人都可以通过向其对等方发送RIB字典TLV来添加到字典中。为了允许任一节点随时添加到字典中，每个节点使用的标识符取自不相交的集合：由启动Hello过程的节点生成的标识符的最低有效位设置为0（即偶数），而由另一个对等节点生成的标识符的最低有效位设置为1（即是奇数）。这意味着字典
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.
可以由任一节点在信息交换阶段的任何点进行扩展，然后可以在后续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).
建立的字典仅在与节点的一次相遇中保持不变（即，当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:
当按照第2.1.2节所述，依次使用每个联系人传递的值更新交付可预测性时，当多个联系人正在进行时，一些特殊注意事项适用：
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.
SC1当根据方程式2对交付可预测性进行老化时，每组计算中使用的K值始终是自上次老化完成以来的时间量。例如，如果节点Z先与节点A联系，然后与节点B联系，则在节点Z中与节点B联系的交付可预测性老化时使用的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_遭遇值始终根据自上次与该节点遭遇以来的时间进行选择。因此，当节点Z和A的接触开始时（在刚刚给出的老化示例中），应用等式1来更新P_Z（Z，A），并且当节点Z和B的接触开始时更新P_Z（Z，B），将根据节点Z之前分别遇到节点A和节点B的时间，使用P_遭遇的适当值。
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的接触，则对于与节点Z（即，给定示例中的节点A）具有持续接触的所有节点“x”，等式1*也应*应用于P_Z（Z，x）。但是，使用的P_遭遇值将根据自上次更新交付可预测性以来的时间来选择，该可预测性是从任何其他节点收到的信息的结果。在这里给出的示例中，当从节点B接收到交付可预测性时，P_Z（A）也将应用等式1，但是所使用的P_遭遇的值将根据自节点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_遭遇值，而不管是哪个节点触发了以前的更新还是当前的更新。这意味着，在这里讨论的示例中，无论节点A还是节点B在三个节点保持连接的情况下发起更新，P_Z（Z，A）和P_Z（Z，B）都将使用相同的P_值进行更新。
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.
信息交换重新运行之间的间隔通常设置为成对节点独立相遇之间预期时间的一小部分。这确保了，例如，节点Z从节点A获得的交付可预测性信息将被传递到节点B，无论节点A和B是否可以在该遭遇期间直接通信。这避免了在这种情况下，由于无线电传播的特殊性而产生的问题，但是，根据交付可预测性的更新间隔时间对P_遭遇因子进行缩放意味着，与每次使用P_遭遇max值将每次信息交换视为单独遭遇时的情况一样，接触节点的可预测性不会过度增加。当多个节点相互接触时，由于P_遭遇的缩放以及使用“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
I_-typ I_-typ为PRoPHET场景中的移动模式提供了一个基本的时间尺度，在PRoPHET场景中，协议被应用。它表示正常移动过程中给定节点对之间相遇的典型或平均时间间隔。间隔应反映相遇之间的“逻辑”时间，且不应如第2.1.2节所述，对多个连接事件给予重大重视。此时间间隔通知许多其他参数的设置，但不一定直接用作参数。需要考虑更高的统计矩（例如，标准差）以及平均值（第一个）
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.
（矩）相遇间隔的分布和该分布的性质（例如，它与正态分布的接近程度）。本节后面部分和附录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_conference_max P_conference_max用作比例因子的上限，该比例因子可在遇到目标节点时增加目标的交付可预测性。P_conference_max的值越大，交付可预测性的提高速度越快，交付可预测性达到一定水平所需的遭遇次数越少。考虑到定义的转发机制关注的是相对而非绝对的交付可预测性值，只要为所有节点选择相同的值，该协议对不同的P_值非常鲁棒。选择该值时，应确保在方程式1中使用P_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_遭遇（intvl）如第2.1.2节所述，方程式1中使用的参数P_遭遇是时间间隔“intvl”的函数。该函数应近似于
P_encounter(intvl) =
P_encounter_max * (intvl / I_typ) for 0<= intvl <= I_typ
P_encounter_max for intvl > I_typ
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.
该功能可以量化和调整以适应移动模式并使实现更容易。总体效果应该是，如果在持续时间较长的沟通机会期间多次应用等式1，则交付可预测性的总体增加应与两次不同的会面间隔时间大致相同。第二种情况将导致使用P_max应用等式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
P_第一_阈值如第2.1.2节所述，目的地的交付可预测性随着时间的推移逐渐降低，除非由于直接接触或通过传递属性而增加。如果传递可预测性下降到值P_first_阈值以下，则节点可丢弃目的地的传递可预测性信息，并将后续遭遇视为之前从未遇到过该节点。这允许节点减少所需的存储空间
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_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_遭遇_首先，如第2.1.2节所述，PRoPHET默认情况下不会对遭遇节点在未来重复遭遇的可能性做出任何假设，或者，这是一次不太可能重复的一次性偶然遭遇。在遭遇节点没有遭遇目标节点的传递可预测性信息的遭遇期间，或者因为这是节点之间的第一次遭遇，或者因为上一次遭遇是很久以前的事，可预测性已经下降到P_first_阈值以下，因此被丢弃，相遇节点将目标节点的传递可预测性设置为P_conference_first。P_Conference_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.
阿尔法-阿尔法参数用于第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的可传递属性的权重，也就是说，应该在多大程度上考虑从遇到的节点接收到的有关目的地的信息。如果beta设置为零，PRoPHET的传递属性将不会激活，并且在计算交付可预测性时只使用直接遭遇。beta值越高，通过传递规则，相遇速度越快，可预测性就越高。
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值越低，分娩可预测性的老化速度越快。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参数将除节点本身之外的目的地的传递可预测性的最大值设置为（1-delta）（即，对于除P_（a，a）之外的所有情况，P_（a，B））。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.
为了设置适当的伽马值，应该考虑在使用协议的先知区中的“平均预期递送”时间，以及所使用的时间单位（递送可预测性被更新的分辨率）。I_aed时间间隔可以根据捆绑包必须通过的平均跳跃数和遭遇之间的平均间隔I_typ来估计。显然，如果捆绑包有一个生存时间（TTL），即在捆绑包中存储的到期时间出现之前的剩余时间小于i_aed，则它们不太可能在网络中生存下来，以交付给此区域中的节点。但是，不应仅在此基础上选择在该区域的节点中创建的捆绑包的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 ).
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_Conference_first、P_Conference_max、P_first_threshold、delta的设置，以及函数P_Conference（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之间的单次遭遇之后交付可预测性P_u（A，B）的演变，P_u（A，B）最初被设置为P_Conference_，然后将稳定地衰减，直到达到P_First_阈值。应设置P_遭遇_first和P_first_阈值之间的比率，以便在经过小倍数（例如，3到5）的I_aed后达到P_first_阈值，使得节点之间的任何后续遭遇可能在P_（a，B）衰减到P_first_阈值以下之前发生。如果已知两次相遇之间时间分布的统计数据，则可能使用分布标准偏差的小倍数，而不是使用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,
其次，如果a和B之间发生第二次相遇，P_相遇_max的设置应足够高，以逆转I_typ期间可能发生的衰减，并将P_（a，B）增加到P_相遇_的值之上。经过几次进一步的接触，
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.
P_（A，B）将达到其上限（1-delta）。与设置P_first_阈值一样，应设置P_Conference_max，以便在发生少量以I_typ隔开的遭遇后达到上限，但这通常应大于2或3。
Finally, beta can be chosen to give some smoothing of the influence of transitivity.
最后，可以选择beta来平滑传递性的影响。
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.
未进行特定网络测量时，建议的启动参数值如下。注意：没有“一刀切”的默认值，理想值根据网络特性而变化。并非所有节点上的参数值都必须相同，但建议在PRoPHET区域内的所有节点上使用类似值，如第2.1.2.1节所述。
+========================================+
| 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 |
+========================================+
+========================================+
| 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
在收到Bundle Offer TLV后，节点检查Bundle列表，并决定它愿意存储哪些Bundle以备将来转发，或者它能够将哪些Bundle交付到它们的目的地。这
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.
必须使用本地策略并考虑可用缓冲区空间等参数做出决策，如果节点请求捆绑长度，则考虑提供的捆绑长度。对于每个这样的可接受的捆绑包，节点向其对等节点发送捆绑包响应TLV，对等节点通过发送请求的捆绑包进行响应。如果一个节点希望在提供其他捆绑包之前先收到一些捆绑包（例如，它可以交付到最终目的地的捆绑包），它可能会按照该优先级顺序请求捆绑包。这通常是可取的，因为无法保证节点彼此保持足够长的接触时间以传输所有可接受的捆绑包。否则，节点应假定捆绑包按对等节点的转发策略确定的优先级顺序列出，并按该顺序请求捆绑包。
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时，也会列出已确认的捆绑包，并设置“PRoPHET 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时，它可以从其存储中删除该捆绑包，除非该节点持有该捆绑包的保管权。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，在这种情况下，可以避免向同一节点发送同一捆绑包的多个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和bundle Ack[RFC5050]是不同的东西。PRoPHET确认仅在网络的PRoPHET部分内有效，而捆绑包确认是可能超出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可在大量场景和环境中使用，而且可能使用的设备范围很广，因此无法确定该决策是否在所有情况下都基于相同的策略。因此，每个节点都必须运行一个_转发策略u来做出这个决定。节点可以定义自己的策略，但本节定义了一些节点可以使用的基本转发策略。注意：如果遇到的节点是所携带的任何捆绑包的目的地，则应将这些捆绑包提供给目的地，即使这会违反转发策略。这里列出的一些转发策略（以及一些排队策略）已经通过模拟进行了评估，关于这些策略的更多信息以及在不同情况下使用哪些策略的建议可以在[lindgren_06]中找到。如果由于部署场景的特点没有选择不同，节点应选择GRTR作为默认转发策略。
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（X，Y）表示存储在节点X处的目的地Y的交付可预测性，NF是节点A将包提供给其他某个节点的次数。
GRTR Forward the bundle only if P_(B,D) > P_(A,D).
GRTR仅当P_Ub（B，D）>P_Ub（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).
当两个节点相遇时，如果包的目的地在另一个节点的传递可预测性较高，则将包发送到另一个节点。只要有足够的可用缓冲区空间，第一个节点在发送包后不会删除包（因为它可能会遇到更好的节点，甚至将来会遇到包的最终目的地）。
GTMX Forward the bundle only if P_(B,D) > P_(A,D) && NF < NF_max.
GTMX仅当P_u2;（B，D）>P_2;（A，D）&&NF<NF_2;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.
此策略与前一个策略类似，但每个bundle最多只提供给目标之外的其他节点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_uB，D）>P_B（A，D）或P_B（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)
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.
仅当等式6成立时，GTMX+才向前推进捆绑。
P_(B,D) > P_(A,D) && P_(B,D) > P_max && NF < NF_max (Eq. 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_Ub（B，D）-P_Ub（A，D）值的降序选择束。仅当P_u（B，D）>P_u（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，但它不只是线性地遍历捆绑队列，而是查看两个节点之间每个捆绑的交付可预测性的差异，并首先转发差异最大的捆绑。由于带宽限制或中断的连接可能会导致并非所有需要交换的捆绑包都被交换，因此最好先发送能够大大提高交付可预测性的捆绑包。
GRTRMax Select bundles in descending order of P_(B,D). Forward the bundle only if P_(B,D) > P_(A,D).
GRTRMax按P_Ub（B，D）的降序选择束。仅当P_u（B，D）>P_u（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作为默认排队策略。
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.
先进先出-先进先出。第一次进入队列的捆绑包是要丢弃的第一个捆绑包。
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-首先驱逐大多数转发者。为了最大化捆绑包的传递速率，此策略要求路由代理跟踪每个捆绑包转发到其他节点的次数。转发次数最多的捆绑包是第一个被丢弃的捆绑包。
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-首先最有利地驱逐。为队列中的每个bundle保留一个变量FAV，初始化为零。每次转发捆绑包时，根据等式7更新FAV，其中P是捆绑包转发到的节点对其目的地的可预测性度量。
FAV_new = FAV_old + ( 1 - FAV_old ) * P (Eq. 7)
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-最有利地首先进行逐出；线性增加。为队列中的每个bundle保留一个变量FAV，初始化为零。每次转发捆绑包时，根据等式8更新FAV，其中P是捆绑包转发到的节点对其目的地的可预测性度量。
FAV_new = FAV_old + P (Eq. 8)
FAV_新=FAV_旧+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).
麻风-先驱逐最不可能的人。由于节点最不可能传递其传递可预测性较低的捆绑包，因此丢弃节点传递可预测性最低且至少转发了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.
一个有序集中可以组合多个排队策略，其中第一个策略主要使用，第二个策略仅在需要在主策略给予相同逐出优先级的捆绑包之间绑定中断时使用，依此类推。例如，可以选择队列策略为{MOFO；SHLI；FIFO}，这将从丢弃转发次数最多的包开始。如果转发了相同次数的多个捆绑包，则剩余生存期最短的捆绑包将被丢弃，如果剩余生存期相同，则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）。SDNVs的格式在[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节）和一个或多个类型长度值组件（TLV）序列组成，这些组件取自第4.2节中的规范。
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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仅指定使用TCP传输来传输PRoPHET数据包，因此协议编号仅用于标识DTN中的PRoPHET协议。在公共IP网络（如Internet）上直接将PRoPHET数据包作为IP协议传输通常不会很好地工作，因为中间盒（如防火墙和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.
标记保留的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传输或提供可靠顺序传递的类似协议运行，部署可能会选择在结果成功时不发送“成功”响应。为此，在所有请求消息中将结果字段设置为“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.
在响应消息中，结果字段可以有两个值：“成功”和“失败”。“成功”结果表示成功响应。属于同一成功响应的所有消息将具有相同的事务标识符。“Success”结果表示可能包含在单个消息中的成功响应，或跨多个消息的成功响应的最终消息。
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.
ReturnReceive是结果字段的值，用于指示消息需要确认。消息的默认值是控制器不会确认响应。在需要确认的情况下，它将在消息头中将结果字段设置为ReturnReceive。
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
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.
如果代码字段指示消息中包含错误TLV，则在错误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:
代码字段按网络位顺序编码为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.
子消息接收代码用于确认消息段的接收。通用成功代码用于确认收到完整消息并成功处理内容。
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-0xFE错误消息0xFF中的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阶段使用Hello SYN、Hello SYNACK和Hello ACK函数（在第5.2节中解释）发送消息的发件人实例，它是链接的发件人实例号。它用于检测链路在下降后何时恢复，或者链路另一端的实体标识何时更改。实例号是一个16位的数字，保证在最近一段时间内是唯一的，并且在链路或节点关闭后恢复时会发生变化。零不是有效的实例号。对于RSTACK函数（也在第5.2节中详细解释），发送方实例字段设置为导致生成RSTACK函数的传入消息中接收方实例字段的值。在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阶段使用Hello SYN、Hello SYNACK和Hello ACK函数的消息的接收方实例，发送方认为是链路的当前实例号，由链路远端的实体分配。如果消息的发送者不知道链接远端的当前实例号，则此字段必须设置为零。对于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.
用于将消息与其响应消息关联的事务标识符。这应该在请求消息中设置为发送主机在最近一段时间内唯一的值。回复消息包含它们响应的请求的事务标识符。事务标识符是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标志，并且此字段将包含子消息段的总计数。子消息编号按网络位顺序编码为15位无符号整数。子消息编号以零为基础，即，对于被划分为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.
此消息的长度（以八位字节为单位），包括消息头和消息正文。如果消息是分段的，则此字段包含此子消息的长度。长度编码为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节中规定的一个或多个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:
该协议还需要关于底层通信层必须提供的链路的额外信息。该信息用于第5.2节中更详细描述的Hello程序。由于此信息可从底层获得，因此无需在PRoPHET消息中携带它。以下值由底层提供：
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.
发送方本地地址底层通信层使用的地址，如第2.4节所述，用于标识当前消息的发送方地址。此地址在当前可以通信的节点中必须是唯一的，并且它仅与接收方本地地址、接收方实例和发送方实例结合使用，以标识通信的节点对。
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
第4.3节定义了特定于TLV类型的TLV。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传输，并在接收时忽略。
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用于设置和维护两个PRoPHET节点之间的链接。具有SYN功能的Hello消息作为信标或保持有效状态定期发送。Hello TLV是两个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.
一旦在两个PRoPHET节点之间建立了通信链路，Hello TLV将在间隔计时器中定义的每个间隔中发送一次。如果节点经历HELLO_DEAD HELLO interval失效，而没有在处于INFO_EXCH状态（如第5.1节中的状态机所定义）的连接上接收到HELLO 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=0x01 |L| Resv | HF | TLV Length (SDNV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timer (SDNV) |EID Length,SDNV| Sender EID (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
TLV标志TLV标志字段包含两个1位标志（S和L）和一个3位Hello函数（HF）编号，用于指定Hello TLV的四个函数之一。其余3位（Resv）未使用和保留：
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.
HF TLV标志位0、1和2被视为按网络位顺序编码的无符号3位整数。整数的值指定Hello TLV的Hello函数（HF）。为Hello TLV指定了四个函数。
The encoding of the Hello Function is:
Hello函数的编码为：
SYN: HF = 1
SYNACK: HF = 2
ACK: HF = 3
RSTACK: HF = 4
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，在接收时应忽略。
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函数值，该标志将被忽略。
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.
定时器定时器字段用于通知接收方发送方的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）已在具有当前发送方实例的消息中至少发送一次，则节点可以选择将此字段设置为零，从而从Hello TLV中忽略发送方EID。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.
发送方EID发送方EID字段指定发送方的DTN端点标识符（EID），用于更新路由信息和做出转发决策。如果一个节点有多个EID，则应选择一个EID进行路由。此字段的长度可变。
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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标志字段携带错误TLV类型的标识符，该标识符为按网络位顺序编码的8位无符号整数。除此处定义的值外，还有一系列值可供私人和实验使用。定义了以下错误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数据由导致冲突的字符串ID（编码为SDNV）和与以前安装的值冲突的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.
路由信息库字典包括用于做出路由决策的端点标识符列表。在链路上的会话期间，引用保持不变，实例号保持不变，路由信息基础消息和捆绑包提供/响应消息都可以使用引用。字典是一种共享资源（见第3.2.1节），它根据一个或多个此类传入TLV的内容以及用于创建此类传出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=0xA0 | TLV Flags | TLV Length (SDNV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RIBD Entry Count (SDNV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
~ Variable-Length Routing Address Strings ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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标识符。String ID zero预定义为通过发送Hello SYN消息来启动会话的节点，String ID one预定义为使用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).
为了确保由两个对等方发起的字符串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.
端点标识符表示端点标识符的文本字符串。请注意，它不是以null结尾的，因为条目包含标识符的长度。
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 |
+-+-+-+-+-+-+-+-+
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:更多肋骨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才能完全传输，“更多RIB TLV”标志设置为1。如果这是该肋骨的最终TLV，则该标志设置为0。
TLV Data
TLV数据
RIB String Count Number of routing entries in the TLV. Encoded as an SDNV.
RIB字符串计数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 String ID目标的端点标识符的字符串ID，该项为其指定字典TLV中预定义的传递可预测性。编码为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]的线性映射（例如，对于0.75的P值，映射将是0.75*65535=49151=0xBFFF；因此，P值将被编码为0xBFFF）。
RIB Flag The encoding of the 8-bit RIB Flag field is:
肋骨标志8位肋骨标志字段的编码为：
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
根据产品节点中存储的捆绑包，捆绑包产品TLV可能包含完整捆绑包和捆绑包片段的描述。为了正确识别捆绑包片段，需要
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).
捆绑包片段描述符必须包含捆绑包有效负载中有效负载片段的偏移量和有效负载片段的长度。如果接收节点在邻居感知阶段通过在SYN或SYNACK消息中设置L标志请求，则提供节点必须在描述符中包含完整捆绑的有效负载长度。必须在描述符的B_标志中设置适当的标志，以指示描述符是否包含有效负载长度字段（在所有情况下为碎片设置，如果设置了L标志，则为完整捆绑设置），以及描述符是否包含有效负载偏移字段（仅限碎片）。
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不再需要该包进行传输。尽管不再传输捆绑包，但它应该为已确认的捆绑包保留一个条目，以便能够进一步传播该消息。
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_标志。未被接受的捆包规范可以省略或保留，但不标记为已接受。对于响应消息中的完整捆绑包，可以忽略有效负载长度字段，即使它包含在要约消息中。必须正确设置B_标志有效负载长度标志，以指示是否包含长度字段。响应消息必须包括包片段的有效负载偏移量和有效负载长度字段，并且必须设置B_标志以指示两者都存在。
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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标志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之间划分，则“更多提供/响应TLV后续”标志必须全部设置为1，但序列中的最后一个TLV必须设置为0。
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.
捆绑产品报价计数捆绑产品报价/响应条目的数量。编码为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:未分配的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.
捆绑目标字符串ID字典TLV中预定义的捆绑目标EID的字符串ID。编码为SDNV。
Bundle Creation Timestamp Time Time component of the Bundle Creation Timestamp for the bundle. Encoded as an SDNV.
捆绑包创建时间戳捆绑包创建时间戳的时间组件。编码为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.
仅当Bundle B标志中设置了Bundle Length include位（值1）时，才包括Bundle Payload Length。指定的捆绑中有效负载的长度。如果捆绑包是完整捆绑包，则为总有效负载长度；如果捆绑包是片段，则为捆绑包片段有效负载长度。编码为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在不可靠的传输协议上运行，则需要肯定的确认来表示（sub）消息的成功传递。在本节中，短语“发送消息”应理解为“成功”发送消息，如果在不可靠的协议上运行，则通过接收适当的“成功”响应发出信号，但由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.
等待\n这是所有节点的启动状态。节点保持此状态，直到通知它们新邻居可用为止。此时，应使用新邻居启动Hello过程，节点将转换为Hello状态。节点应该能够并行处理多个邻居，为每个邻居维护单独的状态机。这可以通过在过渡到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状态（如第5.2节所述，当Hello程序进入ESTAB状态时发生；在此过程中，将使用ESTAB、SYNSENT和SYNRCVD状态，但这些状态是Hello程序的内部状态，此处未列出）。如果节点在建立链接之前被通知邻居已不在范围内，则它将返回到等待状态，如果合适，为处理邻居而创建的任何附加进程或线程都可能被销毁。
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
INFO_EXCH通过Hello过程建立链接后，节点将转换到完成信息交换阶段的INFO_EXCH状态。只要接收到信息交换阶段TLV（路由RIB、路由RIB字典、捆绑提供、捆绑响应），节点就会保持此状态。如果在交换所有信息和捆绑包之前，通知节点邻居已不在范围内，则任何关联的连接都将关闭，节点将被删除
returns to the WAIT_NB state to await new neighbors. The Timer(keep_alive) is used to ensure that the connection remains active.
返回等待状态以等待新邻居。计时器（保持_活动）用于确保连接保持活动状态。
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状态下，已建立链路两端的节点能够使用来自连接的对等方的数据更新其传递可预测性信息，然后提供对等方可能接受或不接受的交换包。为了管理这些流程，每个节点都充当信息交换阶段流程的启动器和侦听器，为这两个角色维护辅助状态机。发起方和侦听方术语指的是路由信息的发送：在捆绑传递部分，侦听方成为捆绑提供方，发起方成为捆绑接受方，这可能是违反直觉的。
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.
该协议的设计使得两个交换可以独立但并行地执行，消息在单个双向链路上多路复用（例如由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响应TLV（即，没有更多要发送的Bundle）时，节点启动计时器（下一次交换）。当该计时器过期时，假设邻居仍处于连接状态，启动器将重新运行信息交换阶段。如果此时仅连接了一个邻居，这将进一步增加邻居中该节点的传递可预测性，并由于传递属性（等式3）而改变传递可预测性。如果连接了多个邻居，或者自上一次信息交换以来发生了其他通信机会，则这些其他遭遇所导致的更改将传递给连接的邻居。信息交换再次完成后，将重新启动下一个交换计时器。
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.
如果此节点在等待计时器（下一次交换）过期时接收到一个或多个新捆绑包，并且交付可预测性表明将部分或全部捆绑包转发到连接的节点是合适的，则应立即将捆绑包提供给连接的邻居，并在接受的情况下进行传输。
State: WAIT_NB
州：等等
+==================================================================+
| Condition | Action | New State |
+==================+===================================+===========+
| New Neighbor | Start Hello procedure for neighbor| HELLO |
| | Keep waiting for more neighbors | 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 |
+==================================================================+
+==================================================================+
| 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 |
+==================================================================+
+==================================================================+
| 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函数）字段设置为指定值（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 “更新对等验证器”操作被定义为存储从链路远端的实体接收的Hello-SYN或Hello-SYNACK函数消息中的发送方实例和发送方本地地址字段的值。
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.
传入消息中的发送方实例与“更新对等验证器”操作从先前消息中存储的值相匹配。
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传入消息中的发送方实例和发送方本地地址字段与“更新对等验证程序”操作从先前消息中存储的值匹配。
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传入消息中的Receiver Instance和Receiver Local Address字段与传出Hello SYN、Hello SYNACK和Hello ACK消息中使用的Sender Instance和Sender Local Address的值匹配。
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.
确认已收到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消息需要一个计时器。计时器的值在计时器字段中宣布。为避免同步效应，应将+/-5%的均匀分布随机抖动添加到计时器实际使用的间隔中。
There are two independent events: the timer expires, and a packet arrives. The processing rules for these events are:
有两个独立的事件：计时器过期和数据包到达。这些事件的处理规则是：
Timer Expires: Reset Timer If state = SYNSENT Send SYN message If state = SYNRCVD Send SYNACK message If state = ESTAB Send ACK message
计时器过期：如果状态=SYNSED Send SYN message如果状态=SYNRCVD Send SYNACK message如果状态=ESTAB Send ACK message，则重置计时器
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消息：如果（A&&C&&！SYNSEMENT）重置链接，否则丢弃消息。如果传入消息是SYN、SYNACK或ACK消息：由以下状态表定义的响应。如果传入消息是任何其他PRoPHET TLV和状态！=ESTAB：丢弃传入消息。如果状态=SYNSED Send SYN message（注1）如果状态=SYNRCVD Send SYNACK message（注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消息不得超过两条。
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状态时，链路上的连接被视为已实现。在实现同步之前接收到的所有TLV（Hello 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 |
+==================================================================+
+==================================================================+
| 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
州：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 |
+==================================================================+
+==================================================================+
| 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 |
+==================================================================+
+==================================================================+
| 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消息不得超过两条。因此，每次计时器过期时必须发送一条ACK消息。此外，如果传入消息是SYN或SYNACK，则可以在计时器到期之间发送另一个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消息。
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
交换Hello消息后，节点处于ESTAB状态，信息交换阶段（包括肋骨交换和束传递子阶段）启动。本节介绍该过程并显示状态转换
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.
在这些子阶段中是必要的；以下各节详细描述了这些阶段中通过的各种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.
PRoPHET运行在第1.2节中记录的双向传输上，因此当一对节点（a和B）达到ESTAB状态时，它们能够在刚刚建立的链路上执行a到B和B到a方向的信息交换阶段过程。原则上，这两个过程相互独立，可以同时执行。但是，完全并发可能不是实现整个流程的最有效方式。如第3.2.1节所述，路由信息基础字典是一种共享资源，由每个节点上本地生成的信息和从对等节点传递的信息组合而成。通过字典生成和更新过程的顺序操作而不是并发操作，可以最小化此信息中的重叠，从而减少节点之间必须传递的信息量。通过检查从第一个要约人处收到的要约，也可以减少第二个要约人需要提供的捆绑数量——第二个要约人不需要提供已经存在于第一个要约人要约列表中的捆绑，因为它将不可避免地被拒绝。
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.
所有实现必须能够以完全并发的方式运行。每个实现都需要定义一个策略，该策略应该是可配置的，以确定它在信息交换阶段是以并发方式还是以顺序方式运行。如果要按顺序操作，则可以进一步选择是交错字典、提供和响应交换部分，还是在启动另一个方向之前在一个方向上完成所有部分。
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链路传输的数据量，尤其适用于半双工链路。但是，可能不希望将第二个方向上的信息交换推迟到包交换完成后再开始。如果节点之间的接触在交换所有可能的束之前结束，则在第二个方向延迟束交换的开始可能会导致束交换偏向于一个方向而不是另一个方向。最好通过重叠信息交换阶段并在可能的情况下同时运行实际的捆绑交换来共享方向之间的可用联系时间和带宽。此外，如果预计当前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.
一种可能的交织策略是在两个节点的发送之间交替。例如，如果Hello-SYN节点发送其初始词典条目，而Hello-SYNACK节点等待完成，那么Hello-SYNACK节点可以在发送之前修剪其建议的词典条目，以避免重复。对于Bundle Offers和response所需的第二批字典条目，以及Bundle Offers，可以重复这种方法，其中Hello-SYN节点提供的、已经存在于Hello-SYNACK节点中的任何Bundle都不需要提供给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.
为了管理信息传输，在每个节点中创建两个辅助状态机，以控制INFO_EXCH高级状态中肋骨交换子阶段和束传递子阶段过程的阶段，如图12所示。每个辅助状态机由两个基本上独立的组件组成，称为“启动器角色”和“侦听器角色”。其中一个组件在每个节点中实例化。启动器角色启动每个节点中的信息交换阶段，侦听器角色响应初始消息，但它不是被动侦听器，因为它还发起消息。从ESTAB状态的转换是“分叉”转换，因为它启动两个辅助状态机。只要邻居保持在范围内并保持连接，两个辅助状态机就会并行运行。
+ - - - - - - - - + + - - - - - - - - +
+ - - - - - - - - + + - - - - - - - - +
| 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 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 | +-------------+ |
| +-------------+ | 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中使用。通过TLV标志区分这两种情况，以确保在接收时在正确的角色上下文中处理它们。如果未提供此标志，则存在两个角色都可以接受RIB字典TLV的状态，因此无法确保正确的角色状态机接受RIB字典TLV。请注意，无论哪个角色处理TLV，都会对词典进行正确的更新，如果完全按顺序采用这些角色，也就是。，如果肋骨交换子阶段和相关的束通过子阶段在反向过程开始之前在一个方向上运行完成。
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上运行时，信息交换阶段的协议错误和重复超时应导致连接终止。
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:
每个节点中具有启动器角色的状态机组件在信息交换阶段开始从一个节点向其对等节点传输信息。从发起者的角度来看，流程执行以下操作：
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
o 发起人角色确定要发送到对等节点的交付可预测性集，并发送必要的RIB字典条目，以解释所需的RIB可预测性值集
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.
在字典更新后发送。在与同一对等方的单个会话期间第二次和后续执行此状态机时，可能没有要发送的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 发起者确定应接受哪些捆绑产品，并在必要时重新排列产品以适应其自身的优先级。使用一个或多个bundle响应将可能重新排序的已接受bundle列表发送到对等节点。
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 捆绑传输完成后，启动器启动计时器（下一次交换）。假设与邻居的连接保持打开状态，当计时器过期时，启动器将重新启动信息交换阶段。在此期间，Hello SYN消息将作为keep alives进行交换，以检查邻居是否仍然存在。keep-alive机制对于启动器和侦听器机器是通用的，并且在高级状态机中处理（参见第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对于发送Hello SYN消息的节点，从ESTAB状态到该状态的初始转换是即时的和自动的。对于对等（Hello SYNACK sender）节点，如果在节点策略中配置了顺序进程，则对于实现完全并发进程的节点，它可能会立即生效，或者可能会推迟到相应的侦听器达到指定状态。
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）。如果对等方通过包含错误TLV的Hello ACK消息报告字典冲突或坏字符串ID错误，则必须终止连接。
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状态，这表示新一轮信息交换和捆绑传递的开始。
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），以便在必要时重新启动进程。如果需要任何新的EID，则更新本地词典；格式化一个或多个RIB字典TLV和一个或多个RIB TLV，并将其发送给对等方。如果没有要发送的词典条目，则可以发送条目为零的TLV，或者可以省略TLV，但如果没有要发送的数据，则必须发送空的RIB TLV。此处生成的RIB字典TLV必须将Sent by Listener标志设置为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.
* 启动一个定时器（称为定时器（信息））并转换到发送状态。
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
请注意，当（且仅当）在传输协议（如TCP）上运行时，如果传输协议的已知约束要求或为了减小内存缓冲区的大小，RIB字典和RIB信息可能会分布在多个TLV和消息中。或者，可以使用单罗纹字典TLV和单罗纹TLV对信息进行格式化。这些TLV可能相当大，因此可能需要使用PRoPHET子消息功能或（如果传输协议具有适当的功能）使用这些固有功能对消息进行分段。关于分段的讨论适用于
the other states and the bundle offer and bundle response messages and will not be repeated.
其他状态和bundle提供和bundle响应消息，将不会重复。
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.
如果要使用多个肋骨TLV，则除最后一个之外，所有TLV标志中的“更多肋骨TLV”标志均设置为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.
* 如果计时器（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的响应消息，中止任何进行中的启动器或侦听器进程，并终止与对等方的连接。请注意，在某些情况下不需要字典更新，在这种状态下收到的第一条消息将携带Bundle Offer 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
* 如果收到带有捆绑提供TLV的消息，如果TLV中设置了“更多提供/响应TLV Following”标志，则重新启动计时器（info）；否则，停止计时器（info）。然后通过通知bundle protocol agent来处理TLV中的任何PRoPHET Ack，并将TLV中提供的bundle添加到提供的bundle集中。如果TLV中设置了“更多报价/响应TLV Following”标志，请等待进一步的捆绑报价TLV。如果收到的捆绑产品TLV的字符串ID不在
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.
使用字典，发送包含错误字符串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.
* 如果在收到的最后一个Bundle Offer TLV中清除了“More Offer/Response TLV Following”标志，请检查提供的Bundle集，以确定要使用配置的排队策略接受的Bundle集。记录接受的捆组，以便在捆通过子阶段检查接收情况。格式化一个或多个捆绑响应TLV，标记接受的报价，并将其发送给对等方。如果发送了多个捆绑响应TLV，则除最后一个外，所有捆绑响应TLV都应将“更多报价/响应TLV以下”标志设置为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.
* 如果对等方没有开始发送请求的包，请重新启动计时器（信息）计时器。
* Transition to state 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.
* 如果计时器（info）在等待捆绑包时过期，则格式化并发送一个或多个捆绑包响应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.
* 在收到每个捆绑包后重新启动计时器（信息）计时器，以防对等方不继续发送请求的捆绑包。
* 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).
* 收到所有请求的捆绑包后，格式化捆绑包响应TLV，将捆绑包提供计数设置为零，并将“更多提供/响应TLV跟随”标志清除为0，以向对等节点发出完成信号。另外，向该节点中的侦听器发送启动器已完成的信号。如果对等节点正在使用顺序策略，则侦听器可能仍处于初始状态，在这种情况下，它需要启动计时器以确保它检测到对等节点是否无法启动启动器状态机。此后，与同一节点中的侦听器状态机进行协调：当侦听器从对等节点接收到完成通知并且此启动器已发送其完成通知时，启动计时器（下一次交换）。
* If the Timer(next_exchange) expires, transition to state CREATE_DR to restart the Information Exchange Phase.
* 如果计时器（下一次交换）过期，请转换到状态CREATE\U 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.
请注意，如果计时器（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 从对等方接收肋骨字典更新和肋骨值。请注意，在某些情况下，不需要更新字典，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节），检查侦听器节点中当前存储的捆绑包集，以确定要提供给启动器的捆绑包集，并根据使用的转发策略对列表进行排序。Bundle Offer 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 发送一个或多个捆绑产品中的捆绑产品列表，如有必要，在列表前面添加一个或多个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，则侦听器进程将收到通知。然后将应用转发策略和当前交付可预测性来确定是否应将此信息发送给对等方。如果确定应转发一个或多个捆绑包和/或ACK，则向对等方发送一组新的捆绑包报价。如果对等方通过发送bundle响应来接受它们，那么bundle和/或ack将像前面一样进行传输。
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 TLV重新启动完整的信息交换，如果更新的RIB需要RIB字典条目，则可以选择在RIB TLV之前添加RIB字典条目。
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:
计时器用于确保如果没有及时从启动器接收到消息，侦听器不会锁定。如果未收到RIB，则侦听器将重新启动，并发送Hello ACK消息以强制启动器重新启动。如果未及时收到捆绑包响应消息，侦听器将重新发送捆绑包提供和相关字典更新。使用以下状态：
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.
WAIT_DICT监听器辅助状态机自动并立即从两个对等中的状态ESTAB转换到此状态。如果对等方中的计时器（下一次交换）过期，则将以相同的方式进入该状态，表示新一轮信息交换和捆绑传递的开始。这将导致对等节点的启动器向侦听器发送一个或多个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更新本地字典，启动或（如果它正在运行）重新启动计时器（对等）并转换到状态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可以组合成一条消息。肋骨TLV应在等待肋骨状态下进行处理。
WAIT_RIB In this state, the Listener expects to be receiving one or more RIB TLVs and possibly additional RIB Dictionary TLVs.
WAIT_RIB在此状态下，侦听器预期将接收一个或多个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.
* 每当收到新消息时，重新启动计时器（对等）计时器。
* 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.
* 当接收到RIB TLV且清除“更多RIB TLV”标志时，启动交付可预测性的重新计算并停止计时器（对等）。使用修改后的交付可预测性和配置的排队和转发策略创建要提供给对等节点的捆绑包列表。
* 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词典TLV消息中的RIB词典条目，以便在必要时更新对等词典。
* 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.
* 格式化并发送捆绑包提供TLV，该TLV携带要提供的捆绑包的标识符以及此节点接收或生成的任何PRoPHET Ack。如果发送了多个捆绑产品报价TLV，则除最后发送的捆绑产品报价TLV外，所有发送的捆绑产品报价TLV必须将“更多报价/响应TLV Following”标志设置为1。
* When all Bundle Offer TLVs have been sent, start the Timer(info) and transition to state OFFER.
* 发送完所有捆绑提供TLV后，启动计时器（info）并转换到状态提供。
* If the Timer(peer) expires, send a Hello ACK TLV to the peer, restart the timer, and transition to state WAIT_DICT.
* 如果计时器（对等机）过期，则向对等机发送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 Dictionary TLV和/或Bundle Offer 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.
提供在此状态下，侦听器期望接收一个或多个包响应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的报价顺序得到维护。重新启动计时器（info），除非收到的最后一个捆绑响应TLV的“更多提供/响应TLV以下”标志设置为0。如果收到的捆绑响应TLV的字符串ID不在字典中，请发送包含错误字符串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.
* 收到捆绑响应TLV后，将“更多提供/响应TLV跟随”标志设置为0，停止计时器（info）并转换到SND_捆绑状态。
* If the Timer(info) expires, send a Hello ACK TLV to the peer, restart the timer and transition to state WAIT_DICT.
* 如果计时器（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在此状态下，侦听器监视BUNDLE发送到发起方对等节点的过程。在传输中断的情况下，如果可能，发起方节点将重新发送已接受但尚未接收的捆绑包列表。必须将要发送的捆绑包列表的任何更新通知捆绑包协议代理（这可能涉及重新发送一个或多个捆绑包）。否则，侦听器在此状态下处于静止状态。
* 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
* 当收到捆绑包响应TLV时，捆绑包提供的数量为非零，提取接受的捆绑包列表并更新之前传递给捆绑包协议代理的列表，以便它可以（重新）开始传输到对等节点。确保尽可能维持TLV的报价顺序。重新启动计时器（info），除非收到的最后一个捆绑响应TLV的“更多提供/响应TLV以下”标志设置为0。如果收到的捆绑响应TLV的字符串ID不在字典中，则发送一条包含错误字符串ID指示符abort的错误TLV消息
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.
任何正在进行的启动器或侦听器进程，重新初始化本地字典，并重新启动信息交换阶段，就像刚刚达到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.
* 在接收到“更多报价/响应TLV后续”标志设置为0的捆绑响应TLV后，停止计时器（info）并等待捆绑发送完成。
* If the Timer(info) expires, send a Hello ACK TLV to the peer, restart the timer, and transition to state WAIT_DICT.
* 如果计时器（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时，捆绑包提供的数量为零，则捆绑包通过子阶段完成。通知发起者侦听器进程已完成，并转换到状态等待\u更多。
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
在此状态下，侦听器监视可能从多个源接收的新捆绑包的接收，包括
* 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.
* 永久连接，例如可能发生在Internet网关上的连接。
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
* 当捆绑协议代理通知侦听器已收到新的捆绑包和/或新的PRoPHET ACK时，侦听器将应用选定的转发策略和当前交付可预测性，以确定是否应向连接的对等方提供任何项目。如果是的话，它会带来
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.
执行与WAIT_RIB状态中描述的相同操作，以构建任何必要的RIB字典TLV和RIB TLV，并将其发送给对等方中的启动器。
* When all Bundle Offer TLVs have been sent, start the Timer(info) and transition to state OFFER.
* 发送完所有捆绑提供TLV后，启动计时器（info）并转换到状态提供。
* 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可以组合成一条消息。肋骨TLV应在等待肋骨状态下进行处理。
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.
定时器（info）和定时器（peer）都用于确保，如果对等节点由于网络中的消息丢失或对等节点的无响应而明显没有及时响应发送的消息，则状态机不会锁定到不适当的状态。适当的值在某种程度上取决于节点之间的网络连接速度和执行PRoPHET实现的节点的能力。应使用1到10秒范围内的值，默认值为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.
在节点处理器上的负载和希望及时转发从其他节点接收的捆绑包之间进行权衡。建议使用的计时器周期应在基准值的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.
发送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收到确认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.
接收到RIBnotlast RIB TLV，且“更多RIB TLV”标志设置为1。
RIBlast RIB TLV received with "More RIB TLVs" flag set to 0.
接收到最后一根肋骨TLV，且“更多肋骨TLV”标志设置为0。
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 Bundle响应TLV，标志设置为0后有更多报价/响应TLV。
RIBDi RIBD TLV received with Sent by Listener flag set to 0 (i.e., it was sent by Initiator role).
接收到RIBDi RIBD TLV时，侦听器发送标志设置为0（即，它是由启动器角色发送的）。
RIBDl RIBD TLV received with Sent by Listener flag set to 1 (i.e., it was sent by Listener role).
接收到RIBDl RIBD TLV时，侦听器发送标志设置为1（即，它是由侦听器角色发送的）。
Timeout(info) The Timer(info) has expired.
超时（信息）计时器（信息）已过期。
Timeout(peer) The Timer(peer) has 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 “发送字典更新”操作定义为：
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
1. 确定先前选定的RIB条目集中尚未在词典中的任何额外EID需要哪些词典更新，并使用这些EID更新本地词典。如果不需要额外的EID，则字典更新集可能为空。如果已执行顺序操作，则即使在第一次执行时，集合也可能为空
selected, this is the second node to start and the necessary EIDs were in the set previously sent by the first node to start.
选中时，这是要启动的第二个节点，并且所需的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. 为“Build RIB Entries”操作中标识的字典更新集格式化零个或多个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与先前存储在词典中的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 “中止交换”操作定义为中止任何正在进行的信息交换状态机并终止与对等机的连接。
o The "Start TI" operation is defined as (re)starting the Timer(info) timer.
o “启动TI”操作定义为（重新）启动计时器（信息）计时器。
o The "Start TP" operation is defined as (re)starting the Timer(peer) timer.
o “启动TP”操作定义为（重新）启动定时器（对等）定时器。
o The "Cancel TI" operation is defined as canceling the Timer(info) timer.
o “取消TI”操作定义为取消计时器（信息）计时器。
o The "Cancel TP" operation is defined as canceling the Timer(info) timer.
o “取消TP”操作定义为取消计时器（信息）计时器。
The rules and state tables for the Initiator role use the following operations:
启动器角色的规则和状态表使用以下操作：
o The "Build RIB Entries" operation is defined as:
o “构建肋骨条目的”操作定义为：
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集。如果这是在与连接的对等方的当前会话期间此节点中状态机的第二次或后续运行，则如果自上次运行状态机以来未发生任何更改，则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 “发送肋骨条目的”操作使用“构建肋骨条目的”操作中标识的肋骨条目的集合格式化一个或多个肋骨TLV，并将其发送给对等方。如果集合为空，则发送具有零条目的单个RIB TLV。如果发送了多个肋骨TLV，除最后一个外，所有其他肋骨TLV必须将“more RIB TLV”标志设置为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 “Notify ACKs”操作被定义为通知捆绑协议代理，已使用捆绑交付接口（见第2.2节）接收到捆绑产品报价TLV中一个或多个捆绑产品的PRoPHET Ack。
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 “发送请求”操作定义为格式化一个或多个非空捆绑响应TLV并将其发送到提供节点。如果发送了多个捆绑要约TLV，则除最后一个外，所有捆绑要约TLV都必须将“更多要约/响应TLV Following”标志设置为1；最后一个或唯一一个必须将标志设置为0。
o The "Record Bundle Received" operation deletes a successfully received bundle from the list of requests.
o “Record Bundle Received”操作从请求列表中删除成功接收的捆绑包。
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 “所有请求完成”操作定义为格式化并向提供节点发送空的捆绑包提供TLV，“更多提供/响应TLV 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 “检查接收”操作定义为如果当前正在从对等节点接收捆绑包，则与节点捆绑包协议代理进行检查。如果在等待bundle接收时发生超时，并且正在处理非常大的bundle，则需要执行此操作。
o The "Start NE" operation is defined as (re)starting the Timer(next_exchange).
o “启动NE”操作定义为（重新）启动计时器（下一次交换）。
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.
从不是Bundle Requests列表中唯一剩余Bundle的对等方接收的NotLastBndlRcvd Bundle。
OFRnotlast Bundle Offer TLV received with "More Offer/Response TLVs Following" flag set to 1.
接收到的最后一个捆绑包报价TLV，且“后续更多报价/响应TLV”标志设置为1。
OFRlast Bundle Offer TLV received with "More Offer/Response TLVs Following" flag set to 0
接收到最后一个捆绑包提供TLV，且“更多提供/响应TLV跟随”标志设置为0
Timeout(next_exch) The Timer(next_exchange) has expired
超时（下一次交换）计时器（下一次交换）已过期
State: 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 |
+==================================================================+
+==================================================================+
| 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 |
+==================================================================+
+==================================================================+
| 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 |
+==================================================================+
+==================================================================+
| 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 “清除提供的肋骨”操作定义为设置一个空容器以容纳对等节点提供的肋骨集。
o The "Record RIBs Supplied" operation is defined as:
o “提供的记录”操作定义为：
1. Taking the RIB entries from a received RIB TLV.
1. 从接收到的肋骨TLV中获取肋骨条目。
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可预测性”操作使用第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 “确定提供”操作确定要提供给对等方的捆绑包集。比较本地交付可预测性和对等方提供的交付可预测性，并根据配置的排队策略和转发策略对存储在此节点中的捆绑包进行优先选择，以提供给对等方。
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 “确定确认”操作定义为获取捆绑协议代理记录的需要转发给对等方的PRoPHET确认集。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 “Determine Offer Dict Updates”操作定义为确定字典中不存在的任何额外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 “发送要约”操作定义为格式化一个或多个非空捆绑要约TLV，合并先前确定的要约集和PRoPHET Ack，并将它们发送到对等节点。如果发送了多个捆绑要约TLV，则除最后一个外，所有捆绑要约TLV都必须将“更多要约/响应TLV Following”标志设置为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通知将发送到同一节点中的启动器角色。
The following events are specific to the Listener role state machine:
以下事件特定于侦听器角色状态机：
RIBnotlast RIB TLV received with "More RIB TLVs" flag set to 1.
接收到RIBnotlast RIB TLV，且“更多RIB TLV”标志设置为1。
RIBlast RIB TLV received with "More RIB TLVs" flag set to 0 and a non-zero count of RIB Entries.
接收RIBlast RIB TLV时，“更多RIB TLV”标志设置为0，RIB条目计数为非零。
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 Bundle Response 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 Bundle Response TLV收到，更多报价/响应TLV跟随标志设置为0，捆绑报价计数为零。
State: 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 |
+==================================================================+
+==================================================================+
| 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 |
+==================================================================+
+==================================================================+
| 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 |
+==================================================================+
+==================================================================+
| 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 |
+==================================================================+
+==================================================================+
| 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 |
+==================================================================+
+==================================================================+
| 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可能包含相同的先知信息。在这种情况下，状态将更改为WAIT_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:
PRoPHET的现有实现基于使用协议版本1的本规范草案版本。如本文件所述，版本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进行了约束，以确保如果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）现已弃用。对于每个bundle说明符，除了版本2的创建时间戳之外，还将传输源EID，以确保bundle具有唯一标识。当提供的捆绑包是捆绑包碎片时，版本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）中添加两个状态。对状态机描述的更改并没有改变连线上的协议。然而，后期操作阶段的规范有点模糊，不同的实现者可能会对其进行不同的解释。
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的节点可能会忽略与发送HELLO消息（指示其使用版本1）的节点的通信机会，或者可能会部分降级并响应消息，就像它是版本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.
建议版本2节点即使在与版本1节点通信时也使用本文档中定义的度量更新方程，因为这将部分抑制版本1中传递性方程的问题，并且版本2节点将任何大于（1-增量）的接收度量修改为（1-增量）为避免成为不发送到此节点的捆绑包的“接收器”。此外，版本1节点不能显式提供捆绑包片段，并且具有支持版本1的节点的exchange必须使用以前版本的捆绑包提供和响应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.
如果网络中的所有节点都可以信任并且正在朝着一个共同的目标努力，那么这里描述的攻击就没有问题。如果存在这样一组节点，但也存在恶意节点，则可以通过在两个节点相遇时引入身份验证机制（例如，使用公钥系统）来解决这些安全问题。因此，只允许已知为受信任节点组成员的节点参与路由。这当然会引入密钥分发的附加问题，但这里没有讨论这个问题。
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.
在适当的情况下，应使用捆绑安全协议[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. 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.
一次通信机会的终止。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. 上面列出的黑洞攻击的影响也适用于此攻击，但只有一个特定目的地的交付可预测性和捆绑包受到影响。这可以用来“窃取”应该发送到特定节点的数据。
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.
用户可以选择通过连接的网络（如运行另一个路由协议的Internet）连接两个稀疏连接的节点区域。对于这个网络，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.
根据“在RFCs中编写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 Codes for Success and Codes for Failure
* 预言家成功的准则和失败的准则
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 |
+--------------------------+-----------+---------------+
+--------------------------+-----------+---------------+
| 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 | |
+----------------------------+-----------+---------------+
+----------------------------+-----------+---------------+
| 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 | |
+------------+--------------+-----------+
+------------+--------------+-----------+
| 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 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 |
+--------------------------+-------------+---------------+
+--------------------------+-------------+---------------+
| 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 |
+--------------------------+-------------+---------------+
+--------------------------+-------------+---------------+
| 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 |
+----------------------------+-------------+---------------+
+----------------------------+-------------+---------------+
| 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 |
+------------------------------+-------------+---------------+
+------------------------------+-------------+---------------+
| 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 |
+----------------------------+---------------------+---------------+
+----------------------------+---------------------+---------------+
| 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 |
+--------------------------+------------------+---------------+
+--------------------------+------------------+---------------+
| 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标志适用于肋骨基础词典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 | |
+----------------------------+--------------+---------------+
+----------------------------+--------------+---------------+
| 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定义了以下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 | |
+----------------------------+--------------+---------------+
+----------------------------+--------------+---------------+
| 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 TLV中的单个条目定义了以下RIB标志（第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 | |
+------------+--------------+-----------+
+------------+--------------+-----------+
| 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):
为捆绑包报价和响应TLV定义了以下TLV标志（第4.3.5节）：
+------------------------------------+--------------+---------------+
| 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 | |
+------------------------------------+--------------+---------------+
+------------------------------------+--------------+---------------+
| 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):
捆绑产品报价和响应TLV（第4.3.5节）中为每个捆绑产品报价定义了以下B标志：
+------------------------------------+--------------+---------------+
| 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 |
+------------------------------------+--------------+---------------+
+------------------------------------+--------------+---------------+
| 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.
贝勒大学（Baylor University）已经编写了一个符合互联网草案（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
一个在C++中的协议的实现是由Lulea技术大学（LTU）的作者之一（Samo Grasic）开发的，作为SAMMI网络连接项目的一部分（见第9节），并继续跟踪协议的发展。这项工作正在进行中
part of the Networking for Communications Challenged Communities (N4C) project and is used in N4C testbeds.
作为通信挑战社区网络（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月的一周内，在瑞典山区（萨米网络连接项目[ccnc07][doria_02]的目标区域）进行了DTN系统的概念验证部署，使用LTU PRoPHET实现路由。部署了四个带有应用网关、一个互联网网关和七个移动中继的固定营地。部署表明PRoPHET能够路由不同应用程序（如电子邮件和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开发的邻接消息。Luka Birsa和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]Scott，K.和S.Burleigh，“捆绑协议规范”，RFC 50502007年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，“延迟容忍网络TCP聚合层协议”，正在进行的工作，2012年8月。
[RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, June 1988.
[RFC1058]Hedrick，C.，“路由信息协议”，RFC10581988年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，“延迟容忍网络架构”，RFC 48382007年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，“在RFCs中编写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，“捆绑包安全协议规范”，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皇家理工学院，斯德哥尔摩，瑞典，2010年10月<http://www.bytewalla.org/sites/bytewalla.org/files/ Bytewalla3_网络_架构_和先知_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，“部署真实DTN系统的经验”，第四届IEEE消费者通信和网络年会（CCNC 2007）会议记录，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，“为萨米游牧社区提供连接”，第二届可持续创新开放合作设计国际会议记录（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，“部分连接adhoc网络的流行病路由”，杜克大学技术报告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]林格伦，A，Doria. A，Lindblom，J和M. Ek，“网络在北极光的土地-从DTN系统部署两年的经验”，ACM无线网络和系统开发区域研讨会（WINDOWS 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将获得彼此的高交付可预测性值，可传递属性也将B对D的值增加到中等水平。最后，节点B遇到节点A（图13c），节点A有一条针对节点D的消息。图13d显示了节点A和节点B之间的消息交换。交换了摘要向量和交付可预测性信息，更新了交付可预测性，然后节点A实现了P_B（B，D）>P_B（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)
+----------------------------+ +----------------------------+
| | | |
| 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. 每个信标间隔毫秒，节点对信标进行本地广播，其中包含其标识和地址以及节点使用的信标间隔值。
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.发送节点已在活动邻居列表中。使用当前时间更新列表中的条目，如果节点的信标间隔已更改，则更新节点的信标间隔。
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.发送节点不在活动邻居列表中。将节点添加到活动邻居列表中，并记录当前时间和节点的信标间隔。通知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_loss*beacon_INTERVAL（对于该节点使用的信标_INTERVAL）的时间段内，未从活动邻居列表中的节点接收到信标，则应假定该节点不再是邻居。该节点的条目应从活动邻居列表中删除，并且应通知PRoPHET agent邻居已离开（“邻居已离开”，如第2.4节所述）。
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节中定义的三个主要方程控制。这些方程使用了大量需要适当配置的参数，以确保交付可预测性以反映适用于节点运行的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
当试图描述流动性模型时，更可能的是，该模型将根据遭遇之间的时间统计分布和在区域内交付包裹的时间来表述。在本节中，一种可能的推导PRoPHET参数的方法
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.
从一个更常见的描述模型被提出。应该记住，这可能不是唯一的解决方案，其适当性将取决于总体流动模式和所涉及时间的分布。在这项工作中有一个隐含的假设，即这些分布可以由一个具有明确定义的第一矩（平均值）的正态分布来表征。这里不考虑分布的确切形式，但更详细的模型可能希望使用有关分布的更具体的知识来改进参数的推导。
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节点之间相遇的平均时间，通常不考虑节点的身份。
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_阈值以下。
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__max得出适当的值，这是交付可预测性演变过程中的关键参数。其他参数P_遭遇_first（0.5）、P_first_threshold（0.1）和delta（0.01）的值，以及图3中建议的默认值，通常不特定于移动性模型，尽管在特殊情况下，P_遭遇_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:
要为gamma选择一个值：在一次未重复的遭遇之后，遭遇节点的交付可预测性应在P4*P5遭遇的预期时间内从P_Conference_first衰减到P_first_阈值。因此：
P_first_threshold = P_encounter_first * gamma ^ ((P2 * P4 * P5)/P1)
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_阈值/P_-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.
gamma的典型值将小于1，但非常接近1（通常大于0.99）。该值必须存储到小数点后几位，但实现可以创建特定间隔的值表，以减少所需的动态计算量。
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)
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_遭遇开始，使用衰变类型并应用第2.1.2节（P6-1）中的方程式1，我们可以计算P6遭遇后遭遇节点的典型交付可预测性。方程1的性质是，不容易产生一个封闭形式，从参数值生成P_遭遇_max值，但使用电子表格重复应用方程并将结果制成表格，将允许非常简单地选择合适的P_遭遇_max值。进化对P_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 zone运行一段时间后，可以而且应该使用实际遭遇的日志来检查所选参数是否合适，并根据需要对其进行调整。从长远来看，可以证明可以在节点中安装学习模式，以便可以动态地调整参数以保持与移动模型的最佳一致性，移动模型本身可能随时间变化。
Authors' Addresses
作者地址
Anders F. Lindgren Swedish Institute of Computer Science Box 1263 Kista SE-164 29 SE
Anders F.Lindgren瑞典计算机科学研究所信箱1263 Kista SE-164 29 SE
Phone: +46707177269
EMail: andersl@sics.se
URI: http://www.sics.se/~andersl
Phone: +46707177269
EMail: andersl@sics.se
URI: http://www.sics.se/~andersl
Avri Doria Technicalities Providence RI US
Avri Doria Providence RI US技术细节
EMail: avri@acm.org
URI: http://psg.com/~avri
EMail: avri@acm.org
URI: http://psg.com/~avri
Elwyn Davies Folly Consulting Soham UK
Elwyn Davies Folly咨询英国苏哈姆
EMail: elwynd@folly.org.uk
EMail: elwynd@folly.org.uk
Samo Grasic Lulea University of Technology Lulea SE-971 87 SE
拉莫亚技术大学LUEA SE-97 1 87 SE
EMail: samo.grasic@ltu.se
EMail: samo.grasic@ltu.se