Internet Engineering Task Force (IETF) H. Song
Request for Comments: 7851 X. Jiang
Category: Standards Track R. Even
ISSN: 2070-1721 Huawei
D. Bryan
ethernot.org
Y. Sun
ICT
May 2016
Internet Engineering Task Force (IETF) H. Song
Request for Comments: 7851 X. Jiang
Category: Standards Track R. Even
ISSN: 2070-1721 Huawei
D. Bryan
ethernot.org
Y. Sun
ICT
May 2016
Peer-to-Peer (P2P) Overlay Diagnostics
对等（P2P）覆盖诊断
Abstract
摘要
This document describes mechanisms for Peer-to-Peer (P2P) overlay diagnostics. It defines extensions to the REsource LOcation And Discovery (RELOAD) base protocol to collect diagnostic information and details the protocol specifications for these extensions. Useful diagnostic information for connection and node status monitoring is also defined. The document also describes the usage scenarios and provides examples of how these methods are used to perform diagnostics.
本文档描述了对等（P2P）覆盖诊断机制。它定义了对资源位置和发现（重新加载）基本协议的扩展，以收集诊断信息并详细说明这些扩展的协议规范。还定义了用于连接和节点状态监视的有用诊断信息。本文档还描述了使用场景，并提供了如何使用这些方法执行诊断的示例。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见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/rfc7851.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7851.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Diagnostic Scenarios . . . . . . . . . . . . . . . . . . . . 5
4. Data Collection Mechanisms . . . . . . . . . . . . . . . . . 6
4.1. Overview of Operations . . . . . . . . . . . . . . . . . 6
4.2. "Ping-like" Behavior: Extending Ping . . . . . . . . . . 8
4.2.1. RELOAD Request Extension: Ping . . . . . . . . . . . 9
4.3. "Traceroute-like" Behavior: The PathTrack Method . . . . 9
4.3.1. New RELOAD Request: PathTrack . . . . . . . . . . . . 10
4.4. Error Code Extensions . . . . . . . . . . . . . . . . . . 12
5. Diagnostic Data Structures . . . . . . . . . . . . . . . . . 13
5.1. DiagnosticsRequest Data Structure . . . . . . . . . . . . 13
5.2. DiagnosticsResponse Data Structure . . . . . . . . . . . 15
5.3. dMFlags and Diagnostic Kind ID Types . . . . . . . . . . 16
6. Message Processing . . . . . . . . . . . . . . . . . . . . . 19
6.1. Message Creation and Transmission . . . . . . . . . . . . 19
6.2. Message Processing: Intermediate Peers . . . . . . . . . 20
6.3. Message Response Creation . . . . . . . . . . . . . . . . 21
6.4. Interpreting Results . . . . . . . . . . . . . . . . . . 22
7. Authorization through Overlay Configuration . . . . . . . . . 23
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9.1. Diagnostics Flag . . . . . . . . . . . . . . . . . . . . 24
9.2. Diagnostic Kind ID . . . . . . . . . . . . . . . . . . . 25
9.3. Message Codes . . . . . . . . . . . . . . . . . . . . . . 26
9.4. Error Code . . . . . . . . . . . . . . . . . . . . . . . 26
9.5. Message Extension . . . . . . . . . . . . . . . . . . . . 26
9.6. XML Name Space Registration . . . . . . . . . . . . . . . 27
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1. Normative References . . . . . . . . . . . . . . . . . . 27
10.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 29
A.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 29
A.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 29
A.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 29
Appendix B. Problems with Generating Multiple Responses on Path 29
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Diagnostic Scenarios . . . . . . . . . . . . . . . . . . . . 5
4. Data Collection Mechanisms . . . . . . . . . . . . . . . . . 6
4.1. Overview of Operations . . . . . . . . . . . . . . . . . 6
4.2. "Ping-like" Behavior: Extending Ping . . . . . . . . . . 8
4.2.1. RELOAD Request Extension: Ping . . . . . . . . . . . 9
4.3. "Traceroute-like" Behavior: The PathTrack Method . . . . 9
4.3.1. New RELOAD Request: PathTrack . . . . . . . . . . . . 10
4.4. Error Code Extensions . . . . . . . . . . . . . . . . . . 12
5. Diagnostic Data Structures . . . . . . . . . . . . . . . . . 13
5.1. DiagnosticsRequest Data Structure . . . . . . . . . . . . 13
5.2. DiagnosticsResponse Data Structure . . . . . . . . . . . 15
5.3. dMFlags and Diagnostic Kind ID Types . . . . . . . . . . 16
6. Message Processing . . . . . . . . . . . . . . . . . . . . . 19
6.1. Message Creation and Transmission . . . . . . . . . . . . 19
6.2. Message Processing: Intermediate Peers . . . . . . . . . 20
6.3. Message Response Creation . . . . . . . . . . . . . . . . 21
6.4. Interpreting Results . . . . . . . . . . . . . . . . . . 22
7. Authorization through Overlay Configuration . . . . . . . . . 23
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9.1. Diagnostics Flag . . . . . . . . . . . . . . . . . . . . 24
9.2. Diagnostic Kind ID . . . . . . . . . . . . . . . . . . . 25
9.3. Message Codes . . . . . . . . . . . . . . . . . . . . . . 26
9.4. Error Code . . . . . . . . . . . . . . . . . . . . . . . 26
9.5. Message Extension . . . . . . . . . . . . . . . . . . . . 26
9.6. XML Name Space Registration . . . . . . . . . . . . . . . 27
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1. Normative References . . . . . . . . . . . . . . . . . . 27
10.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 29
A.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 29
A.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 29
A.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 29
Appendix B. Problems with Generating Multiple Responses on Path 29
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
In the last few years, overlay networks have rapidly evolved and emerged as a promising platform for deployment of new applications and services in the Internet. One of the reasons overlay networks are seen as an excellent platform for large-scale distributed systems is their resilience in the presence of failures. This resilience has three aspects: data replication, routing recovery, and static resilience. Routing recovery algorithms are used to repopulate the routing table with live nodes when failures are detected. Static resilience measures the extent to which an overlay can route around failures even before the recovery algorithm repairs the routing table. Both routing recovery and static resilience rely on accurate and timely detection of failures.
在过去几年中，覆盖网络迅速发展，成为在互联网上部署新应用程序和服务的一个有前途的平台。覆盖网络被视为大型分布式系统的优秀平台的原因之一是其在出现故障时的恢复能力。这种弹性有三个方面：数据复制、路由恢复和静态弹性。路由恢复算法用于在检测到故障时用活动节点重新填充路由表。静态恢复能力度量即使在恢复算法修复路由表之前，覆盖也可以绕过故障进行路由的程度。路由恢复和静态恢复都依赖于对故障的准确及时检测。
There are a number of situations in which some nodes in a Peer-to-Peer (P2P) overlay may malfunction or behave badly. For example, these nodes may be disabled, congested, or may be misrouting messages. The impact of these malfunctions on the overlay network may be a degradation of quality of service provided collectively by the peers in the overlay network or an interruption of the overlay services. It is desirable to identify malfunctioning or badly behaving peers through diagnostic tools and exclude or reject them from the P2P system. Node failures may also be caused by failures of underlying layers. For example, recovery from an incorrect overlay topology may be slow when the speed at which IP routing recovers after link failures is very slow. Moreover, if a backbone link fails and the failover is slow, the network may be partitioned, leading to partitions of overlay topologies and inconsistent routing results between different partitioned components.
在许多情况下，点对点（P2P）覆盖中的某些节点可能会出现故障或表现不好。例如，这些节点可能被禁用、拥塞，或者可能是错误路由消息。这些故障对覆盖网络的影响可能是覆盖网络中的对等方集体提供的服务质量下降或覆盖服务中断。人们希望通过诊断工具识别出故障或行为不好的对等点，并将其从P2P系统中排除或拒绝。节点故障也可能由底层故障引起。例如，当链路故障后IP路由恢复的速度非常慢时，从错误的覆盖拓扑恢复可能会很慢。此外，如果主干链路出现故障且故障切换速度较慢，则网络可能会被分区，从而导致重叠拓扑的分区以及不同分区组件之间的路由结果不一致。
Some keep-alive algorithms based on periodic probe and acknowledge mechanisms enable accurate and timely detection of failures of one node's neighbors [Overlay-Failure-Detection], but these algorithms by themselves can only detect the disabled neighbors using the periodic method. This may not be sufficient for the service provider operating the overlay network.
一些基于周期探测和确认机制的保持活动算法能够准确、及时地检测一个节点邻居的故障[覆盖故障检测]，但这些算法本身只能使用周期方法检测禁用的邻居。这对于运营覆盖网络的服务提供商来说可能不够。
A P2P overlay diagnostic framework supporting periodic and on-demand methods for detecting node failures and network failures is desirable. This document describes a general P2P overlay diagnostic extension to the base protocol RELOAD [RFC6940] and is intended as a complement to keep-alive algorithms in the P2P overlay itself. Readers are advised to consult [P2PSIP-CONCEPTS] for further background on the problem domain.
P2P覆盖诊断框架支持定期和按需检测节点故障和网络故障。本文档描述了基本协议重新加载[RFC6940]的通用P2P覆盖诊断扩展，旨在补充P2P覆盖本身中的保持活动算法。建议读者参考[P2PSIP-CONCEPTS]，了解问题领域的更多背景知识。
This document uses the concepts defined in RELOAD [RFC6940]. In addition, the following terms are used in the document:
本文档使用重新加载[RFC6940]中定义的概念。此外，本文件中使用了以下术语：
overlay hop: One overlay hop is one portion of path between the initiator node and the destination peer in a RELOAD overlay. Each time packets are passed to the next node in the RELOAD overlay, one overlay hop occurs.
覆盖跃点：一个覆盖跃点是重新加载覆盖中发起方节点和目标对等方之间路径的一部分。每次将数据包传递到重新加载覆盖中的下一个节点时，都会发生一个覆盖跃点。
underlay hop: An underlay hop is one portion of the path between source and destination in the IP layer. Each time packets are passed to the next IP-layer device, an underlay hop occurs.
参考底图跃点：参考底图跃点是IP层中源和目标之间路径的一部分。每次数据包传递到下一个IP层设备时，都会发生参考底图跳变。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
P2P systems are self-organizing, and ideally the setup and configuration of individual P2P nodes requires no network management in the traditional sense. However, users of an overlay as well as P2P service providers may contemplate usage scenarios where some monitoring and diagnostics are required. We present a simple connectivity test and some useful diagnostic information that may be used in such diagnostics.
P2P系统是自组织的，理想情况下，单个P2P节点的设置和配置不需要传统意义上的网络管理。但是，覆盖层的用户以及P2P服务提供商可能会考虑需要进行一些监视和诊断的使用场景。我们提供了一个简单的连接测试和一些有用的诊断信息，可用于此类诊断。
The common usage scenarios for P2P diagnostics can be broadly categorized in three classes:
P2P诊断的常见使用场景大致可分为三类：
a. Automatic diagnostics built into the P2P overlay routing protocol. Nodes perform periodic checks of known neighbors and remove those nodes from the routing tables that fail to respond to connectivity checks [Handling_Churn_in_a_DHT]. Unresponsive nodes may only be temporarily disabled, for example, due to a local cryptographic processing overload, disk processing overload, or link overload. It is therefore useful to repeat the connectivity checks to see nodes have recovered and can be again placed in the routing tables. This process is known as 'failed node recovery' and can be optimized as described in the paper "Handling Churn in a DHT" [Handling_Churn_in_a_DHT].
a. 自动诊断内置于P2P覆盖路由协议中。节点对已知邻居执行定期检查，并从路由表中删除那些无法响应连接检查的节点[处理\u a\u DHT中的\u搅动\u]。例如，由于本地加密处理过载、磁盘处理过载或链路过载，可能只会暂时禁用无响应节点。因此，重复连接检查以查看节点是否已恢复并可以再次放置在路由表中非常有用。这个过程被称为“失败节点恢复”，可以按照“DHT中处理客户流失”[DHT中处理客户流失]一文中的描述进行优化。
b. Diagnostics used by a particular node to follow up on an individual user complaint or failure. For example, a technical support staff member may use a desktop sharing application (with the permission of the user) to remotely determine the health of, and possible problems with, the malfunctioning node. Part of the remote diagnostics may consist of simple connectivity tests with other nodes in the P2P overlay and retrieval of statistics from nodes in the overlay. The simple connectivity tests are not dependent on the type of P2P overlay. Note that other tests may be required as well, including checking the health and performance of the user's computer or mobile device and checking the bandwidth of the link connecting the user to the Internet.
b. 特定节点用于跟踪单个用户投诉或故障的诊断。例如，技术支持人员可以使用桌面共享应用程序（经用户许可）远程确定故障节点的运行状况和可能存在的问题。远程诊断的一部分可能包括与P2P覆盖中的其他节点进行简单的连接测试，以及从覆盖中的节点检索统计信息。简单的连接测试不依赖于P2P覆盖的类型。注意，也可能需要其他测试，包括检查用户计算机或移动设备的健康和性能，以及检查将用户连接到互联网的链路的带宽。
c. P2P system-wide diagnostics used to check the overall health of the P2P overlay network. These include checking the consumption of network bandwidth, checking for the presence of problem links, and checking for abusive or malicious nodes. This is not a trivial problem and has been studied in detail for content and streaming P2P overlays [Diagnostic_Framework] and has not been addressed in earlier documents. While this is a difficult problem, a great deal of information that can help in diagnosing these problems can be obtained by obtaining basic diagnostic information for peers and the network. This document provides a framework for obtaining this information.
c. P2P系统范围的诊断用于检查P2P覆盖网络的整体健康状况。这些包括检查网络带宽的消耗、检查问题链路的存在以及检查滥用或恶意节点。这不是一个微不足道的问题，已经针对内容和流式P2P覆盖[Diagnostic_Framework]进行了详细的研究，但在早期的文档中尚未解决。虽然这是一个困难的问题，但通过获取对等点和网络的基本诊断信息，可以获得大量有助于诊断这些问题的信息。本文件提供了获取这些信息的框架。
The diagnostic mechanisms described in this document are primarily intended to detect and locate failures or monitor performance in P2P overlay networks. It provides mechanisms to detect and locate malfunctioning or badly behaving nodes including disabled nodes, congested nodes, and misrouting peers. It provides a mechanism to detect direct connectivity or connectivity to a specified node, a mechanism to detect the availability of specified resource records, and a mechanism to discover P2P overlay topology and the underlay topology failures.
本文档中描述的诊断机制主要用于检测和定位P2P覆盖网络中的故障或监控性能。它提供了检测和定位故障或不良行为节点的机制，包括禁用节点、拥塞节点和路由错误的节点。它提供了一种检测到指定节点的直接连接或连接的机制，一种检测指定资源记录可用性的机制，以及一种发现P2P覆盖拓扑和底层拓扑故障的机制。
The RELOAD diagnostics extensions define two mechanisms to collect data. The first is an extension to the RELOAD Ping mechanism that allows diagnostic data to be queried from a node as well as to diagnose the path to that node. The second is a new method, PathTrack, for collecting diagnostic information iteratively. Payloads for these mechanisms allowing diagnostic data to be collected and represented are presented, and additional error codes are introduced. Essentially, this document reuses the RELOAD specification [RFC6940] and extends it to introduce the new
重新加载诊断扩展定义了两种收集数据的机制。第一个是重新加载Ping机制的扩展，它允许从节点查询诊断数据并诊断到该节点的路径。第二种方法是PathTrack，用于迭代收集诊断信息。介绍了这些机制的有效载荷，这些机制允许收集和表示诊断数据，并引入了额外的错误代码。本质上，本文档重用了重新加载规范[RFC6940]，并对其进行了扩展以引入新的
diagnostics methods. The extensions strictly follow how RELOAD specifies message routing, transport, NAT traversal, and other RELOAD protocol features.
诊断方法。这些扩展严格遵循重载如何指定消息路由、传输、NAT遍历和其他重载协议特性。
This document primarily describes how to detect and locate failures including disabled nodes, congested nodes, misrouting behaviors, and underlying network faults in P2P overlay networks through a simple and efficient mechanism. This mechanism is modeled after the ping/ traceroute paradigm: ping [RFC792] is used for connectivity checks, and traceroute is used for hop-by-hop fault localization as well as path tracing. This document specifies a "ping-like" mode (by extending the RELOAD Ping method to gather diagnostics) and a "traceroute-like" mode (by defining the new PathTrack method) for diagnosing P2P overlay networks.
本文档主要描述如何通过简单有效的机制检测和定位P2P覆盖网络中的故障，包括禁用节点、拥塞节点、错误路由行为和潜在网络故障。该机制是按照ping/traceroute范式建模的：ping[RFC792]用于连接检查，traceroute用于逐跳故障定位以及路径跟踪。本文档指定了用于诊断P2P覆盖网络的“ping-like”模式（通过扩展重载ping方法来收集诊断信息）和“traceroute-like”模式（通过定义新的PathTrack方法）。
One way these tools can be used is to detect the connectivity to the specified node or the availability of the specified resource record through the extended Ping operation. Once the overlay network receives some alarms about overlay service degradation or interruption, a Ping is sent. If the Ping fails, one can then send a PathTrack to determine where the fault lies.
使用这些工具的一种方法是通过扩展Ping操作检测到指定节点的连接或指定资源记录的可用性。一旦覆盖网络收到一些关于覆盖服务降级或中断的警报，就会发送Ping。如果Ping失败，则可以发送路径跟踪以确定故障所在。
The diagnostic information can only be provided to authorized nodes. Some diagnostic information can be provided to all the participants in the P2P overlay, and some other diagnostic information can only be provided to the nodes authorized by the local or overlay policy. The authorization depends on the type of the diagnostic information and the administrative considerations and is application specific.
诊断信息只能提供给授权节点。一些诊断信息可以提供给P2P覆盖中的所有参与者，而一些其他诊断信息只能提供给本地或覆盖策略授权的节点。授权取决于诊断信息的类型和管理注意事项，并且是特定于应用程序的。
This document considers the general administrative scenario based on diagnostic Kind, where a whole overlay can authorize a certain kind of diagnostic information to a small list of particular nodes (e.g., administrative nodes). That means if a node gets the authorization to access a diagnostic Kind, it can access that information from all nodes in the overlay network. It leaves the scenario where a particular node authorizes its diagnostic information to a particular list of nodes out of scope. This could be achieved by extension of this document if there is a requirement in the near future. The default policy or access rule for a type of diagnostic information is "deny" unless specified in the diagnostics extension document. As the RELOAD protocol already requires that each message carries the message signature of the sender, the receiver of the diagnostics requests can use the signature to identify the sender. It can then use the overlay configuration file with this signature to determine which types of diagnostic information that node is authorized for.
本文档考虑基于诊断类型的一般管理场景，其中整个覆盖可以将特定类型的诊断信息授权给特定节点（例如，管理节点）的小列表。这意味着，如果一个节点获得访问诊断类型的授权，它可以从覆盖网络中的所有节点访问该信息。它使特定节点将其诊断信息授权给特定节点列表的场景超出范围。如果近期有要求，可通过扩展本文件来实现。除非在诊断扩展文档中指定，否则一类诊断信息的默认策略或访问规则为“拒绝”。由于重新加载协议已经要求每条消息都带有发送方的消息签名，诊断请求的接收方可以使用该签名来识别发送方。然后，它可以使用带有此签名的覆盖配置文件来确定该节点被授权用于哪些类型的诊断信息。
In the remainder of this section we define mechanisms for collecting data, as well as the specific protocol extensions (message extensions, new methods, and error codes) required to collect this information. In Section 5 we discuss the format of the data collected, and in Section 6 we discuss detailed message processing.
在本节的其余部分中，我们将定义收集数据的机制，以及收集此信息所需的特定协议扩展（消息扩展、新方法和错误代码）。在第5节中，我们讨论所收集数据的格式，在第6节中，我们讨论详细的消息处理。
It is important to note that the mechanisms described in this document do not guarantee that the information collected is in fact related to the previous failures. However, using the information from previous traversed nodes, the user (or management system) may be able to infer the problem. Symmetric routing can be achieved by using the Via List [RFC6940] (or an alternate DHT routing algorithm), but the response path is not guaranteed to be the same.
需要注意的是，本文件中描述的机制并不保证所收集的信息实际上与以前的故障有关。然而，使用来自先前遍历的节点的信息，用户（或管理系统）可能能够推断问题。对称路由可以通过使用Via List[RFC6940]（或备用DHT路由算法）实现，但响应路径不能保证相同。
To provide "ping-like" behavior, the RELOAD Ping method is extended to collect diagnostic data along the path. The request message is forwarded by the intermediate peers along the path and then terminated by the responsible peer. After optional local diagnostics, the responsible peer returns a response message. If an error is found when routing, an error response is sent to the initiator node by the intermediate peer.
为了提供“类似ping”的行为，重新加载ping方法被扩展以沿路径收集诊断数据。请求消息由中间对等方沿路径转发，然后由负责对等方终止。在可选的本地诊断之后，负责的对等方返回响应消息。如果在路由时发现错误，则中间对等方将向启动器节点发送错误响应。
The message flow of a Ping message (with diagnostic extensions) is as follows:
Ping消息（带有诊断扩展）的消息流如下所示：
Peer A Peer B Peer C Peer D
| | | |
|(1). PingReq | | |
|------------------->|(2). PingReq | |
| |------------------->|(3). PingReq |
| | |------------------->|
| | | |
| | |<-------------------|
| |<-------------------|(4). PingAns |
|<-------------------|(5). PingAns | |
|(6). PingAns | | |
| | | |
Peer A Peer B Peer C Peer D
| | | |
|(1). PingReq | | |
|------------------->|(2). PingReq | |
| |------------------->|(3). PingReq |
| | |------------------->|
| | | |
| | |<-------------------|
| |<-------------------|(4). PingAns |
|<-------------------|(5). PingAns | |
|(6). PingAns | | |
| | | |
Figure 1: Ping Diagnostic Message Flow
图1：Ping诊断消息流
To extend the Ping request for use in diagnostics, a new extension of RELOAD is defined. The structure for a MessageExtension in RELOAD is defined as:
为了扩展Ping请求以用于诊断，定义了重新加载的新扩展。重新加载中MessageExtension的结构定义为：
struct {
MessageExtensionType type;
Boolean critical;
opaque extension_contents<0..2^32-1>;
} MessageExtension;
struct {
MessageExtensionType type;
Boolean critical;
opaque extension_contents<0..2^32-1>;
} MessageExtension;
For the Ping request extension, we define a new MessageExtensionType, extension 0x2 named "Diagnostic_Ping", as specified in Table 4. The extension contents consists of a DiagnosticsRequest structure, defined in Section 5.1. This extension MAY be used for new requests of the Ping method and MUST NOT be included in requests using any other method.
对于Ping请求扩展，我们定义了一个新的MessageExtensionType，扩展名为“Diagnostic_Ping”，如表4所示。扩展内容包括第5.1节中定义的DiagnosticsRequest结构。此扩展可用于Ping方法的新请求，并且不得包含在使用任何其他方法的请求中。
This extension is not critical. If a peer does not support the extension, they will simply ignore the diagnostic portion of the message and will treat the message as if it were a normal ping. Senders MUST accept a response that lacks diagnostic information and SHOULD NOT resend the message expecting a reply. Receivers who receive a method other than Ping including this extension MUST ignore the extension.
这种扩展并不重要。如果对等方不支持扩展，他们将忽略消息的诊断部分，并将消息视为正常的ping。发件人必须接受缺少诊断信息的响应，并且不应重新发送需要回复的邮件。接收除Ping以外的方法（包括此扩展）的接收器必须忽略该扩展。
We define a simple PathTrack method for retrieving diagnostic information iteratively.
我们定义了一个简单的PathTrack方法，用于迭代地检索诊断信息。
The operation of this request is shown below in Figure 2. The initiator node A asks its neighbor B which is the next hop peer to the destination ID, and B returns a message with the next hop peer C information, along with optional diagnostic information for B to the initiator node. Then the initiator node A asks the next hop peer C (direct response routing [RFC7263] or via symmetric routing) to return next hop peer D information and diagnostic information of C. Unless a failure prevents the message from being forwarded, this step can be repeated until the request reaches responsible peer D for the destination ID and retrieves the diagnostic information of peer D.
此请求的操作如下图2所示。发起方节点A询问其邻居B哪个是目标ID的下一跳对等方，并且B向发起方节点返回带有下一跳对等方C信息的消息以及B的可选诊断信息。然后，发起方节点A要求下一跳对等方C（直接响应路由[RFC7263]或通过对称路由）返回下一跳对等方D信息和C的诊断信息。除非故障阻止消息转发，可以重复此步骤，直到请求到达目标ID的负责对等方D并检索对等方D的诊断信息。
The message flow of a PathTrack message (with diagnostic extensions) is as follows:
PathTrack消息（带有诊断扩展名）的消息流如下所示：
Peer-A Peer-B Peer-C Peer-D
| | | |
|(1).PathTrackReq | | |
|------------------->| | |
|(2).PathTrackAns | | |
|<-------------------| | |
| |(3).PathTrackReq | |
|--------------------|------------------->| |
| |(4).PathTrackAns | |
|<-------------------|--------------------| |
| | |(5).PathTrackReq |
|--------------------|--------------------|------------------->|
| | |(6).PathTrackAns |
|<-------------------|--------------------|--------------------|
| | | |
Peer-A Peer-B Peer-C Peer-D
| | | |
|(1).PathTrackReq | | |
|------------------->| | |
|(2).PathTrackAns | | |
|<-------------------| | |
| |(3).PathTrackReq | |
|--------------------|------------------->| |
| |(4).PathTrackAns | |
|<-------------------|--------------------| |
| | |(5).PathTrackReq |
|--------------------|--------------------|------------------->|
| | |(6).PathTrackAns |
|<-------------------|--------------------|--------------------|
| | | |
Figure 2: PathTrack Diagnostic Message Flow
图2:PathTrack诊断消息流
There have been proposals that RouteQuery and a series of Fetch requests can be used to replace the PathTrack mechanism; however, in the presence of high rates of churn, such an operation would not, strictly speaking, provide identical results, as the path may change between RouteQuery and Fetch operations. While obviously the path could change between steps of PathTrack as well, with a single message rather than two messages for query and fetch, less inconsistency is likely, and thus the use of a single message is preferred.
有人建议使用RouteQuery和一系列获取请求来取代PathTrack机制；但是，在高流失率的情况下，严格来说，这样的操作不会提供相同的结果，因为路径可能在RouteQuery和Fetch操作之间发生变化。显然，路径也可以在PathTrack的各个步骤之间更改，使用一条消息而不是两条消息进行查询和获取，不一致性可能更小，因此最好使用一条消息。
Given that in a typical diagnostic scenario the peer sending the PathTrack request desires to obtain information about the current path to the destination, in the event that successive calls to PathTrack return different paths, the results should be discarded and the request resent, ensuring that the second request traverses the appropriate path.
鉴于在典型的诊断场景中，发送PathTrack请求的对等方希望获得有关到目标的当前路径的信息，如果对PathTrack的连续调用返回不同的路径，则应丢弃结果并重新发送请求，以确保第二个请求穿过适当的路径。
This document defines a new RELOAD method, PathTrack, to retrieve the diagnostic information from the intermediate peers along the routing path. At each step of the PathTrack request, the responsible peer responds to the initiator node with requested status information. Status information can include a peer's congestion state, processing power, available bandwidth, the number of entries in its neighbor table, uptime, identity, network address information, and next hop peer information.
本文档定义了一种新的重新加载方法PathTrack，用于从路由路径上的中间对等方检索诊断信息。在PathTrack请求的每个步骤中，负责的对等方使用请求的状态信息响应发起方节点。状态信息可以包括对等方的拥塞状态、处理能力、可用带宽、其邻居表中的条目数、正常运行时间、身份、网络地址信息和下一跳对等方信息。
A PathTrack request specifies which diagnostic information is requested using a DiagnosticsRequest data structure, which is defined and discussed in detail in Section 5.1. Base information is requested by setting the appropriate flags in the data structure in the request. If all flags are clear (no bits are set), then the PathTrack request is only used for requesting the next hop information. In this case, the iterative mode of PathTrack is degraded to a RouteQuery method that is only used for checking the liveness of the peers along the routing path. The PathTrack request can be routed using direct response routing or other routing methods chosen by the initiator node.
PathTrack请求指定使用DiagnosticsRequest数据结构请求哪些诊断信息，第5.1节对此进行了详细定义和讨论。通过在请求的数据结构中设置适当的标志来请求基本信息。如果清除了所有标志（未设置任何位），则PathTrack请求仅用于请求下一跳信息。在这种情况下，PathTrack的迭代模式被降级为RouteQuery方法，该方法仅用于检查沿路由路径的对等节点的活跃度。PathTrack请求可以使用直接响应路由或启动器节点选择的其他路由方法进行路由。
A response to a successful PathTrackReq is a PathTrackAns message. The PathTrackAns contains general diagnostic information in the payload, returned using a DiagnosticResponse data structure. This data structure is defined and discussed in detail in Section 5.2. The information returned is determined based on the information requested in the flags in the corresponding request.
对成功的PathTrackReq的响应是PathTrackAns消息。PathTrackAns在有效负载中包含常规诊断信息，使用DiagnosticResponse数据结构返回。第5.2节对该数据结构进行了详细定义和讨论。返回的信息是根据相应请求的标志中请求的信息确定的。
The structure of the PathTrack request is as follows:
PathTrack请求的结构如下所示：
struct{
Destination destination;
DiagnosticsRequest request;
}PathTrackReq;
struct{
Destination destination;
DiagnosticsRequest request;
}PathTrackReq;
The fields of the PathTrackReq are as follows:
PathTrackReq的字段如下所示：
destination: The destination that the initiator node is interested in. This may be any valid destination object, including a NodeID, opaque ids, or ResourceID. One example should be noted that, for debugging purposes, the initiator will use the destination ID as it was used when failure happened.
目的地：启动器节点感兴趣的目的地。这可以是任何有效的目标对象，包括NodeID、不透明ID或ResourceID。应注意的一个示例是，出于调试目的，启动器将使用发生故障时使用的目标ID。
request: A DiagnosticsRequest, as discussed in Section 5.1.
请求：诊断请求，如第5.1节所述。
The structure of the PathTrack response is as follows:
PathTrack响应的结构如下所示：
struct{
Destination next_hop;
DiagnosticsResponse response;
}PathTrackAns;
struct{
Destination next_hop;
DiagnosticsResponse response;
}PathTrackAns;
The fields of the PathTrackAns are as follows:
PathTrackAns的字段如下所示：
next_hop: The information of the next hop node from the responding intermediate peer to the destination. If the responding peer is the responsible peer for the destination ID, then the next_hop node ID equals the responding node ID, and after receiving a PathTrackAns where the next_hop node ID equals the responding node ID, the initiator MUST stop the iterative process.
下一跳：从响应的中间对等方到目的地的下一跳节点的信息。如果响应对等方是目标ID的负责对等方，则下一跳节点ID等于响应节点ID，并且在接收到下一跳节点ID等于响应节点ID的PathTrackAns后，发起方必须停止迭代过程。
response: A DiagnosticsResponse, as discussed in Section 5.2.
响应：诊断响应，如第5.2节所述。
This document extends the error response method defined in the RELOAD specification to support error cases resulting from diagnostic queries. When an error is encountered in RELOAD, the Message Code 0xffff is returned. The ErrorResponse structure includes an error code. We define new error codes to report possible error conditions detected while performing diagnostics:
本文档扩展了重新加载规范中定义的错误响应方法，以支持诊断查询导致的错误情况。重新加载时遇到错误时，将返回消息代码0xffff。ErrorResponse结构包含一个错误代码。我们定义了新的错误代码，以报告在执行诊断时检测到的可能错误情况：
Code Value Error Code Name 0x15 Error_Underlay_Destination_Unreachable 0x16 Error_Underlay_Time_Exceeded 0x17 Error_Message_Expired 0x18 Error_Upstream_Misrouting 0x19 Error_Loop_Detected 0x1a Error_TTL_Hops_Exceeded
代码值错误代码名称0x15错误\u参考底图\u目标\u无法访问0x16错误\u参考底图\u时间\u超过0x17错误\u消息\u过期0x18错误\u上游错误\u路由错误0x19错误\u循环\u检测到0x1a错误\u TTL\u超出跳数\u
The error code is returned by the upstream node before the failure node. The upstream node uses the normal ping to detect the failure type and return it to the initiator node, which will help the user (initiator node) to understand where the failure happened and what kind of error happened, as the failure may happen at the same location and for the same reason when sending the normal message and the diagnostics message.
错误代码由故障节点之前的上游节点返回。上游节点使用普通ping来检测故障类型并将其返回给发起方节点，这将帮助用户（发起方节点）了解故障发生的位置和发生的错误类型，因为在发送正常消息和诊断消息时，故障可能发生在同一位置，原因相同。
As defined in RELOAD, additional information may be stored (in an implementation-specific way) in the optional error_info byte string. While the specifics are obviously left to the implementation, as an example, in the case of 0x15, the error_field could be used to provide additional information as to why the underlay destination is unreachable (net unreachable, host unreachable, fragmentation needed, etc.).
按照RELOAD中的定义，附加信息可以（以特定于实现的方式）存储在可选的error_info字节字符串中。虽然细节显然由实现决定，例如，在0x15的情况下，error_字段可用于提供有关无法访问参考底图目标的原因（无法访问网络、无法访问主机、需要碎片等）的附加信息。
Both the extended Ping method and PathTrack method use the following common diagnostics data structures to collect data. Two common structures are defined: DiagnosticsRequest for requesting data and DiagnosticsResponse for returning the information.
扩展Ping方法和PathTrack方法都使用以下通用诊断数据结构来收集数据。定义了两种常见结构：用于请求数据的DiagnosticsRequest和用于返回信息的DiagnosticsResponse。
The DiagnosticsRequest data structure is used to request diagnostic information and has the following form:
DiagnosticsRequest数据结构用于请求诊断信息，具有以下形式：
enum{ (2^16-1) } DiagnosticKindId;
enum{ (2^16-1) } DiagnosticKindId;
struct{
DiagnosticKindId kind;
opaque diagnostic_extension_contents<0..2^32-1>;
}DiagnosticExtension;
struct{
DiagnosticKindId kind;
opaque diagnostic_extension_contents<0..2^32-1>;
}DiagnosticExtension;
struct{
uint64 expiration;
uint64 timestamp_initiated;
uint64 dMFlags;
uint32 ext_length;
DiagnosticExtension diagnostic_extensions_list<0..2^32-1>;
}DiagnosticsRequest;
struct{
uint64 expiration;
uint64 timestamp_initiated;
uint64 dMFlags;
uint32 ext_length;
DiagnosticExtension diagnostic_extensions_list<0..2^32-1>;
}DiagnosticsRequest;
The fields in the DiagnosticsRequest are as follows:
DiagnosticsRequest中的字段如下所示：
expiration: The time when the request will expire represented as the number of milliseconds elapsed since midnight Jan 1, 1970 UTC (not counting leap seconds). This will have the same values for seconds as standard UNIX time or POSIX time. More information can be found at "Unix time" in Wikipedia [UnixTime]. This value MUST have a value between 1 and 600 seconds in the future. This value is used to prevent replay attacks.
过期：请求将过期的时间，表示为自UTC 1970年1月1日午夜以来经过的毫秒数（不计算闰秒）。这将具有与标准UNIX时间或POSIX时间相同的秒值。更多信息可以在维基百科[UnixTime]的“Unix时间”中找到。该值将来必须在1到600秒之间。此值用于防止重播攻击。
timestamp_initiated: The time when the diagnostics request was initiated, represented as the number of milliseconds elapsed since midnight Jan 1, 1970 UTC (not counting leap seconds). This will have the same values for seconds as standard UNIX time or POSIX time.
timestamp_initiated：启动诊断请求的时间，表示为自UTC 1970年1月1日午夜以来经过的毫秒数（不计算闰秒）。这将具有与标准UNIX时间或POSIX时间相同的秒值。
dMFlags: A mandatory field that is an unsigned 64-bit integer indicating which base diagnostic information the request initiator node is interested in. The initiator sets different bits to retrieve different kinds of diagnostic information. If dMFlags is set to zero, then no base diagnostic information is conveyed in the PathTrack response. If dMFlags is set to all "1"s, then all base diagnostic information values are requested. A request may set any number of the flags to request the corresponding diagnostic information.
dMFlags：一个必填字段，它是一个无符号的64位整数，指示请求启动器节点感兴趣的基本诊断信息。启动器设置不同的位以检索不同类型的诊断信息。如果dMFlags设置为零，则PathTrack响应中不会传输任何基本诊断信息。如果dMFlags设置为所有“1”，则会请求所有基本诊断信息值。请求可以设置任意数量的标志来请求相应的诊断信息。
Note this memo specifies the initial set of flags; the flags can be extended. The dMflags indicate general diagnostic information. The mapping between the bits in the dMFlags and the diagnostic Kind ID presented is as described in Section 9.1.
注：本备忘录规定了标志的初始设置；这些标志可以扩展。dMflags表示一般诊断信息。dMFlags中的位与显示的诊断种类ID之间的映射如第9.1节所述。
ext_length: The length of the extended diagnostic request information in bytes. If the value is greater than or equal to 1, then some extended diagnostic information is being requested on the assumption this information will be included in the response if the recipient understands the extended request and is willing to provide it. The specific diagnostic information requested is defined in the diagnostic_extensions_list below. A value of zero indicates no extended diagnostic information is being requested. The value of ext_length MUST NOT be negative. Note that it is not the length of the entire DiagnosticsRequest data structure, but of the data making up the diagnostic_extensions_list.
ext_length：扩展诊断请求信息的长度（字节）。如果该值大于或等于1，则会请求一些扩展诊断信息，前提是如果接收者理解扩展请求并愿意提供，则该信息将包含在响应中。请求的特定诊断信息在下面的诊断扩展列表中定义。值为零表示未请求扩展诊断信息。ext_length的值不能为负。请注意，它不是整个DiagnosticsRequest数据结构的长度，而是组成Diagnostics_extensions_列表的数据的长度。
diagnostic_extensions_list: Consists of one or more DiagnosticExtension structures (see below) documenting additional diagnostic information being requested. Each DiagnosticExtension consists of the following fields:
诊断扩展列表：由一个或多个DiagnosticExtension结构（见下文）组成，记录请求的其他诊断信息。每个DiagnosticExtension由以下字段组成：
kind: A numerical code indicating the type of extension diagnostic information (see Section 9.2). Note that kinds 0xf000 - 0xfffe are reserved for overlay specific diagnostics and may be used without IANA registration for local diagnostic information. Kinds from 0x0000 to 0x003f MUST NOT be indicated in the diagnostic_extensions_list in the message request, as they may be represented using the dMFlags in a much simpler (and more space efficient) way.
种类：表示扩展诊断信息类型的数字代码（见第9.2节）。请注意，类型0xf000-0xfffe保留用于覆盖特定的诊断，可以在没有IANA注册的情况下使用，以获取本地诊断信息。消息请求中的诊断扩展列表中不得指示0x0000到0x003f之间的种类，因为它们可以使用dMFlags以更简单（更节省空间）的方式表示。
diagnostic_extension_contents: The opaque data containing the request for this particular extension. This data is extension dependent.
诊断扩展内容：包含此特定扩展请求的不透明数据。此数据依赖于扩展名。
The DiagnosticsResponse data structure is used to return the diagnostic information and has the following form:
DiagnosticsResponse数据结构用于返回诊断信息，其形式如下：
enum { (2^16-1) } DiagnosticKindId;
struct{
DiagnosticKindId kind;
opaque diagnostic_info_contents<0..2^16-1>;
}DiagnosticInfo;
enum { (2^16-1) } DiagnosticKindId;
struct{
DiagnosticKindId kind;
opaque diagnostic_info_contents<0..2^16-1>;
}DiagnosticInfo;
struct{
uint64 expiration;
uint64 timestamp_initiated;
uint64 timestamp_received;
uint8 hop_counter;
uint32 ext_length;
DiagnosticInfo diagnostic_info_list<0..2^32-1>;
}DiagnosticsResponse;
struct{
uint64 expiration;
uint64 timestamp_initiated;
uint64 timestamp_received;
uint8 hop_counter;
uint32 ext_length;
DiagnosticInfo diagnostic_info_list<0..2^32-1>;
}DiagnosticsResponse;
The fields in the DiagnosticsResponse are as follows:
DiagnosticsResponse中的字段如下所示：
expiration: The time when the response will expire represented as the number of milliseconds elapsed since midnight Jan 1, 1970 UTC (not counting leap seconds). This will have the same values for seconds as standard UNIX time or POSIX time. This value MUST have a value between 1 and 600 seconds in the future.
expiration：响应将过期的时间，表示为自UTC 1970年1月1日午夜以来经过的毫秒数（不计算闰秒）。这将具有与标准UNIX时间或POSIX时间相同的秒值。该值将来必须在1到600秒之间。
timestamp_initiated: This value is copied from the diagnostics request message. The benefit of containing such a value in the response message is that the initiator node does not have to maintain the state.
时间戳_initiated：此值从诊断请求消息复制。在响应消息中包含这样一个值的好处是发起方节点不必维护状态。
timestamp_received: The time when the diagnostic request was received represented as the number of milliseconds elapsed since midnight Jan 1, 1970 UTC (not counting leap seconds). This will have the same values for seconds as standard UNIX time or POSIX time.
timestamp_received：接收诊断请求的时间表示为自UTC 1970年1月1日午夜以来经过的毫秒数（不计算闰秒）。这将具有与标准UNIX时间或POSIX时间相同的秒值。
hop_counter: This field only appears in diagnostic responses. It MUST be exactly copied from the TTL field of the forwarding header in the received request. This information is sent back to the request initiator, allowing it to compute the number of hops that the message traversed in the overlay.
跃点计数器：此字段仅出现在诊断响应中。它必须完全从接收到的请求中转发头的TTL字段复制。该信息被发送回请求发起方，使其能够计算消息在覆盖中经过的跃点数。
ext_length: The length of the returned DiagnosticInfo information in bytes. If the value is greater than or equal to 1, then some extended diagnostic information (as specified in the DiagnosticsRequest) was available and is being returned. In that case, this value indicates the length of the returned information. A value of zero indicates no extended diagnostic information is included either because none was requested or the request could not be accommodated. The value of ext_length MUST NOT be negative. Note that it is not the length of the entire DiagnosticsRequest data structure but of the data making up the diagnostic_info_list.
ext_length：返回的DiagnosticInfo信息的长度（字节）。如果该值大于或等于1，则某些扩展诊断信息（如DiagnosticsRequest中所指定）可用并返回。在这种情况下，该值表示返回信息的长度。值为零表示未包含扩展诊断信息，原因可能是未请求扩展诊断信息或请求无法满足。ext_length的值不能为负。请注意，它不是整个DiagnosticsRequest数据结构的长度，而是构成诊断信息列表的数据的长度。
diagnostic_info_list: consists of one or more DiagnosticInfo structures containing the requested diagnostic_info_contents. The fields in the DiagnosticInfo structure are as follows:
诊断信息列表：由一个或多个包含请求的诊断信息内容的诊断信息结构组成。DiagnosticInfo结构中的字段如下所示：
kind: A numeric code indicating the type of information being returned. For base data requested using the dMFlags, this code corresponds to the dMFlag set and is described in Section 5.1. For diagnostic extensions, this code will be identical to the value of the DiagnosticKindId set in the "kind" field of the DiagnosticExtension of the request. See Section 9.2.
种类：指示返回信息类型的数字代码。对于使用dMFlags请求的基本数据，该代码对应于dMFlag集，并在第5.1节中进行了描述。对于诊断扩展，此代码将与请求的DiagnosticeExtension的“种类”字段中设置的DiagnosticKindId值相同。见第9.2节。
diagnostic_info_contents: Data containing the value for the diagnostic information being reported. Various kinds of diagnostic information can be retrieved. Please refer to Section 5.3 for details of the diagnostic Kind ID for the base diagnostic information that may be reported.
诊断信息内容：包含所报告诊断信息值的数据。可以检索各种类型的诊断信息。有关可能报告的基本诊断信息的诊断种类ID的详细信息，请参阅第5.3节。
The dMFlags field described above is a 64-bit field that allows initiator nodes to identify up to 62 items of base information to request in a request message (the first and last flags being reserved). The dMFlags also reserves all "0"s, which means nothing is requested, and all "1"s, which means everything is requested. But at the same time, the first and last bits cannot be used for other purposes, and they MUST be set to 0 when other particular diagnostic Kind IDs are requested. When the requested base information is returned in the response, the value of the diagnostic Kind ID will correspond to the numeric field marked in the dMFlags in the request. The values for the dMFlags are defined in Section 9.1 and the diagnostic Kind IDs are defined in Section 9.2. The information contained for each value is described in this section. Access to each kind of diagnostic information MUST NOT be allowed unless compliant to the rules defined in Section 7.
上面描述的dMFlags字段是一个64位字段，它允许启动器节点在请求消息中标识最多62项要请求的基本信息（保留第一个和最后一个标志）。dMFlags还保留所有“0”，表示未请求任何内容，保留所有“1”，表示请求所有内容。但同时，第一位和最后一位不能用于其他目的，当请求其他特定的诊断类型ID时，它们必须设置为0。当响应中返回请求的基本信息时，诊断种类ID的值将对应于请求中dMFlags中标记的数字字段。dMFlags的值在第9.1节中定义，诊断种类ID在第9.2节中定义。本节介绍了每个值包含的信息。除非符合第7节中定义的规则，否则不得访问各种诊断信息。
STATUS_INFO (8 bits): A single-value element containing an unsigned byte representing whether or not the node is in congestion status. An example usage of STATUS_INFO is for congestion-aware routing. In this scenario, each peer has to update its congestion status periodically. An intermediate peer in the Distributed Hash Table (DHT) network will choose its next hop according to both the DHT routing algorithm and the status information. This is done to avoid increasing load on congested peers. The rightmost 4 bits are used and other bits MUST be cleared to "0"s for future use.
STATUS_INFO（8位）：一个单值元素，包含一个无符号字节，表示节点是否处于拥塞状态。状态信息的一个示例用法是用于拥塞感知路由。在这种情况下，每个对等方必须定期更新其拥塞状态。分布式哈希表（DHT）网络中的中间节点将根据DHT路由算法和状态信息选择下一跳。这样做是为了避免在拥挤的对等机上增加负载。使用最右边的4位，其他位必须清除为“0”以备将来使用。
There are 16 levels of congestion status, with 0x00 representing zero load and 0x0f representing congestion. This document does not provide a specific method for congestion and leaves this decision to each overlay implementation. One possible option for an overlay implementation would be to take node's CPU/memory/ bandwidth usage percentage in the past 600 seconds and normalize the highest value to the range from 0x00 to 0x0f. An overlay implementation can also decide to not use all the 16 values from 0x00 to 0x0f. A future document may define an objective measure or specific algorithm for this.
拥塞状态有16个级别，0x00表示零负载，0x0f表示拥塞。本文档未提供拥塞的具体方法，并将此决定权留给每个覆盖实现。覆盖实现的一个可能选项是获取节点在过去600秒内的CPU/内存/带宽使用百分比，并将最高值标准化为0x00到0x0f的范围。覆盖实现还可以决定不使用从0x00到0x0f的所有16个值。未来的文档可能会为此定义一个客观度量或特定算法。
ROUTING_TABLE_SIZE (32 bits): A single-value element containing an unsigned 32-bit integer representing the number of peers in the peer's routing table. The administrator of the overlay may be interested in statistics of this value for reasons such as routing efficiency.
路由表大小（32位）：一个单值元素，包含一个无符号的32位整数，表示对等路由表中的对等数目。出于路由效率等原因，覆盖层管理员可能对该值的统计信息感兴趣。
PROCESS_POWER (64 bits): A single-value element containing an unsigned 64-bit integer specifying the processing power of the node with MIPS as the unit. Fractional values are rounded up.
PROCESS_POWER（64位）：一个单值元素，包含一个无符号的64位整数，指定以MIPS为单位的节点的处理能力。分数值向上舍入。
UPSTREAM_BANDWIDTH (64 bits): A single-value element containing an unsigned 64-bit integer specifying the upstream network bandwidth (provisioned or maximum, not available) of the node with units of kbit/s. Fractional values are rounded up. For multihomed hosts, this should be the link used to send the response.
上游带宽（64位）：一个单值元素，包含一个无符号的64位整数，指定节点的上游网络带宽（已配置或最大，不可用），单位为kbit/s。分数值向上舍入。对于多宿主主机，这应该是用于发送响应的链接。
DOWNSTREAM_BANDWIDTH (64 bits): A single-value element containing an unsigned 64-bit integer specifying the downstream network bandwidth (provisioned or maximum, not available) of the node with kbit/s as the unit. Fractional values are rounded up. For multihomed hosts, this should be the link the request was received from.
下游_带宽（64位）：一个单值元素，包含一个无符号的64位整数，指定以kbit/s为单位的节点的下游网络带宽（已配置或最大，不可用）。分数值向上舍入。对于多宿主主机，这应该是从中接收请求的链接。
SOFTWARE_VERSION: A single-value element containing a US-ASCII string that identifies the manufacture, model, operating system information, and the version of the software. Given that there are a very large number of peers in some networks, and no peer is likely to know all other peer's software, this information may be very useful to help determine if the cause of certain groups of misbehaving peers is related to specific software versions. While the format is peer defined, a suggested format is as follows: "ApplicationProductToken (Platform; OS-or-CPU) VendorProductToken (VendorComment)", for example, "MyReloadApp/1.0 (Unix; Linux x86_64) libreload-java/0.7.0 (Stonyfish Inc.)". The string is a C-style string and MUST be terminated by "\0"."\0" MUST NOT be included in the string itself to prevent confusion with the delimiter.
软件版本：一个单值元素，包含一个US-ASCII字符串，用于标识软件的制造商、型号、操作系统信息和版本。鉴于某些网络中存在大量的对等点，并且没有对等点可能知道所有其他对等点的软件，此信息可能非常有用，有助于确定某些行为不端的对等点组的原因是否与特定的软件版本有关。虽然该格式是对等定义的，但建议的格式如下：“ApplicationProductToken（平台；OS或CPU）VendorProductToken（VendorComment）”，例如，“MyReloadApp/1.0（Unix；Linux x86_64）libreload java/0.7.0（Stonyfish Inc.）”。该字符串是C样式的字符串，必须以“\0”结尾。“0”不能包含在字符串本身中，以防止与分隔符混淆。
MACHINE_UPTIME (64 bits): A single-value element containing an unsigned 64-bit integer specifying the time the node's underlying system has been up (in seconds).
MACHINE_UPTIME（64位）：一个单值元素，包含一个无符号的64位整数，指定节点的基础系统启动的时间（以秒为单位）。
APP_UPTIME (64 bits): A single-value element containing an unsigned 64-bit integer specifying the time the P2P application has been up (in seconds).
APP_UPTIME（64位）：一个单值元素，包含一个无符号的64位整数，指定P2P应用程序启动的时间（以秒为单位）。
MEMORY_FOOTPRINT (64 bits): A single-value element containing an unsigned 64-bit integer representing the memory footprint of the peer program in kilobytes (1024 bytes). Fractional values are rounded up.
内存占用（64位）：一个单值元素，包含一个无符号的64位整数，表示对等程序的内存占用，单位为千字节（1024字节）。分数值向上舍入。
DATASIZE_STORED (64 bits): An unsigned 64-bit integer representing the number of bytes of data being stored by this node.
DATASIZE_STORED（64位）：表示此节点存储的数据字节数的无符号64位整数。
INSTANCES_STORED: An array element containing the number of instances of each kind stored. The array is indexed by Kind-ID. Each entry is an unsigned 64-bit integer.
实例存储：一个数组元素，包含存储的每种实例的数量。数组按种类ID编制索引。每个条目都是一个无符号64位整数。
MESSAGES_SENT_RCVD: An array element containing the number of messages sent and received. The array is indexed by method code. Each entry in the array is a pair of unsigned 64-bit integers (packed end to end) representing sent and received.
MESSAGES\u SENT\u RCVD：包含发送和接收的消息数的数组元素。数组由方法代码索引。数组中的每个条目都是一对表示已发送和已接收的无符号64位整数（压缩端到端）。
EWMA_BYTES_SENT (32 bits): A single-value element containing an unsigned 32-bit integer representing an exponential weighted average of bytes sent per second by this peer:
EWMA_BYTES_SENT（32位）：一个单值元素，包含一个无符号32位整数，表示该对等方每秒发送的字节的指数加权平均数：
sent = alpha x sent_present + (1 - alpha) x sent_last
sent = alpha x sent_present + (1 - alpha) x sent_last
where sent_present represents the bytes sent per second since the last calculation and sent_last represents the last calculation of
其中，sent_present表示自上次计算以来每秒发送的字节数，sent_last表示上次计算的字节数
bytes sent per second. A suitable value for alpha is 0.8 (or another value as determined by the implementation). This value is calculated every five seconds (or another time period as determined by the implementation). The value for the very first time period should simply be the average of bytes sent in that time period.
每秒发送的字节数。alpha的合适值为0.8（或由实现确定的另一个值）。该值每五秒计算一次（或由实现确定的另一个时间段）。第一个时间段的值应该只是该时间段内发送的字节的平均值。
EWMA_BYTES_RCVD (32 bits): A single-value element containing an unsigned 32-bit integer representing an exponential weighted average of bytes received per second by this peer:
EWMA_BYTES_RCVD（32位）：一个单值元素，包含一个无符号32位整数，表示该对等方每秒接收的字节的指数加权平均数：
rcvd = alpha x rcvd_present + (1 - alpha) x rcvd_last
rcvd = alpha x rcvd_present + (1 - alpha) x rcvd_last
where rcvd_present represents the bytes received per second since the last calculation and rcvd_last represents the last calculation of bytes received per second. A suitable value for alpha is 0.8 (or another value as determined by the implementation). This value is calculated every five seconds (or another time period as determined by the implementation). The value for the very first time period should simply be the average of bytes received in that time period.
其中，rcvd_present表示自上次计算以来每秒接收的字节数，rcvd_last表示每秒接收的字节数的上次计算。alpha的合适值为0.8（或由实现确定的另一个值）。该值每五秒计算一次（或由实现确定的另一个时间段）。第一个时间段的值应该只是该时间段内接收的字节的平均值。
UNDERLAY_HOP (8 bits): Indicates the IP-layer hops from the intermediate peer, which receives the diagnostics message to the next-hop peer for this message. (Note: RELOAD does not require the intermediate peers to look into the message body. So, here we use PathTrack to gather underlay hops for diagnostics purpose).
UNDERLAY_-HOP（8位）：表示从中间对等方到下一个跃点对等方的IP层跃点，中间对等方接收该消息的诊断消息。（注意：重新加载不需要中间对等方查看消息正文。因此，这里我们使用PathTrack收集参考底图跃点以进行诊断）。
BATTERY_STATUS (8 bits): The leftmost bit is used to indicate whether this peer is using a battery or not. If this bit is clear (set to "0"), then the peer is using a battery for power. The other 7 bits are to be determined by specific applications.
电池状态（8位）：最左边的位用于指示该对等方是否正在使用电池。如果该位已清除（设置为“0”），则对等方正在使用电池供电。其他7位由具体应用确定。
When constructing either a Ping message with diagnostic extensions or a PathTrack message, the sender first creates and populates a DiagnosticsRequest data structure. The timestamp_initiated field is set to the current time, and the expiration field is constructed based on this time. The sender includes the dMFlags field in the structure, setting any number (including all) of the flags to request particular diagnostic information. The sender MAY leave all the bits unset, thereby requesting no particular diagnostic information.
当构造带有诊断扩展名的Ping消息或PathTrack消息时，发送方首先创建并填充DiagnosticsRequest数据结构。timestamp_initiated字段设置为当前时间，expiration字段基于此时间构建。发送方在结构中包括dMFlags字段，设置任意数量（包括所有）的标志以请求特定的诊断信息。发送方可能会保留所有未设置的位，因此不请求特定的诊断信息。
The sender MAY also include diagnostic extensions in the DiagnosticsRequest data structure to request additional information.
发送方还可以在DiagnosticsRequest数据结构中包括诊断扩展以请求附加信息。
If the sender includes any extensions, it MUST calculate the length of these extensions and set the ext_length field to this value. If no extensions are included, the sender MUST set ext_length to zero.
如果发送方包含任何扩展名，则必须计算这些扩展名的长度，并将ext_length字段设置为此值。如果未包含扩展名，发送方必须将ext_length设置为零。
The format of the DiagnosticRequest data structure and its fields MUST follow the restrictions defined in Section 5.1.
DiagnosticRequest数据结构及其字段的格式必须遵循第5.1节中定义的限制。
When constructing a Ping message with diagnostic extensions, the sender MUST create a MessageExtension structure as defined in RELOAD [RFC6940], setting the value of type to 0x2 and the value of critical to FALSE. The value of extension_contents MUST be a DiagnosticsRequest structure as defined above. The message MAY be directed to a particular NodeID or ResourceID but MUST NOT be sent to the broadcast NodeID.
当构造带有诊断扩展的Ping消息时，发送方必须创建一个MessageExtension结构，如RELOAD[RFC6940]中所定义，将type的值设置为0x2，critical的值设置为FALSE。扩展_内容的值必须是上面定义的DiagnosticsRequest结构。该消息可以被定向到特定的NodeID或ResourceID，但不得发送到广播NodeID。
When constructing a PathTrack message, the sender MUST set the message_code for the RELOAD MessageContents structure to path_track_req 0x27. The request field of the PathTrackReq MUST be set to the DiagnosticsRequest data structure defined above. The destination field MUST be set to the desired destination, which MAY be either a NodeID or ResourceID but SHOULD NOT be the broadcast NodeID.
构造PathTrack消息时，发送方必须将RELOAD MessageContents结构的消息代码设置为path_track_req 0x27。PathTrackReq的请求字段必须设置为上面定义的DiagnosticsRequest数据结构。“目的地”字段必须设置为所需的目的地，该目的地可以是NodeID或ResourceID，但不应是广播NodeID。
When a request arrives at a peer, if the peer's responsible ID space does not cover the destination ID of the request, then the peer MUST continue processing this request according to the overlay specified routing mode from RELOAD protocol.
当请求到达对等方时，如果对等方的责任ID空间没有覆盖请求的目标ID，则对等方必须根据重载协议中指定的覆盖路由模式继续处理该请求。
In P2P overlay, error responses to a message can be generated by either an intermediate peer or the responsible peer. When a request is received at a peer, the peer may find connectivity failures or malfunctioning peers through the predefined rules of the overlay network, e.g., by analyzing the Via List or underlay error messages. In this case, the intermediate peer returns an error response to the initiator node, reporting any malfunction node information available in the error message payload. All error responses generated MUST contain the appropriate error code.
在P2P覆盖中，对消息的错误响应可以由中间对等方或负责对等方生成。当在对等端接收到请求时，对等端可通过覆盖网络的预定义规则（例如，通过分析通孔列表或参考底图错误消息）查找连接故障或故障对等端。在这种情况下，中间对等向发起方节点返回错误响应，报告错误消息有效负载中可用的任何故障节点信息。生成的所有错误响应必须包含相应的错误代码。
Each intermediate peer receiving a Ping message with extensions (and that understands the extension) or receiving a PathTrack request / response MUST check the expiration value (Unix time format) to determine if the message is expired. If the message expired, the intermediate peer MUST generate a response with error code 0x17 "Error_Message_Expired", return the response to the initiator node, and discard the message.
接收带有扩展名的Ping消息（并且理解扩展名）或接收PathTrack请求/响应的每个中间对等方都必须检查过期值（Unix时间格式），以确定消息是否过期。如果消息过期，中间对等方必须生成一个错误代码为0x17“error\u message\u expired”的响应，将响应返回到发起方节点，并丢弃该消息。
The intermediate peer MUST return an error response with the error code 0x15 "Error_Underlay_Destination_Unreachable" when it receives an ICMP message with "Destination Unreachable" information after forwarding the received request to the destination peer.
在将接收到的请求转发到目标对等方后，当中间对等方接收到包含“目标不可访问”信息的ICMP消息时，必须返回错误响应，错误代码为0x15“error\u Underlay\u Destination\u Unreachable”。
The intermediate peer MUST return an error response with the error code 0x16 "Error_Underlay_Time_Exceeded" when it receives an ICMP message with "Time Exceeded" information after forwarding the received request.
转发接收到的请求后，中间对等方收到包含“超时”信息的ICMP消息时，必须返回错误代码为0x16“error\u Underlay\u Time\u extended”的错误响应。
The peer MUST return an error response with error code 0x18 "Error_Upstream_Misrouting" when it finds its upstream peer disobeys the routing rules defined in the overlay. The immediate upstream peer information MUST also be conveyed to the initiator node.
当发现其上游对等方违反覆盖中定义的路由规则时，对等方必须返回错误响应，错误代码为0x18“error_Upstream_Misrouting”。直接上游对等信息也必须传送到发起方节点。
The peer MUST return an error response with error code 0x19 "Error_Loop_Detected" when it finds a loop through the analysis of the Via List.
当对等方通过分析过孔列表找到循环时，必须返回错误代码为0x19“error\u Loop\u Detected”的错误响应。
The peer MUST return an error response with error code 0x1a "Error_TTL_Hops_Exceeded" when it finds that the TTL field value is no more than 0 when forwarding.
对等方在转发时发现TTL字段值不大于0时，必须返回错误代码为0x1a“error\u TTL\u Hops\u excelled”的错误响应。
When a diagnostic request message arrives at a peer, it is responsible for the destination ID specified in the forwarding header, and assuming it understands the extension (in the case of Ping) or the new request type PathTrack, it MUST follow the specifications defined in RELOAD to form the response header, and perform the following operations:
当诊断请求消息到达对等方时，它负责转发标头中指定的目标ID，并且假设它理解扩展（在Ping的情况下）或新的请求类型PathTrack，它必须遵循在RELOAD中定义的规范以形成响应标头，并执行以下操作：
o When constructing a PathTrack response, the sender MUST set the message_code for the RELOAD MessageContents structure to path_track_ans 0x28.
o 构造PathTrack响应时，发送方必须将RELOAD MessageContents结构的消息\u代码设置为path\u track\u ans 0x28。
o The receiver MUST check the expiration value (Unix time format) in the DiagnosticsRequest to determine if the message is expired. If the message is expired, the peer MUST generate a response with the error code 0x17 "Error_Message_Expired", return the response to the initiator node, and discard the message.
o 接收方必须检查DiagnosticsRequest中的过期值（Unix时间格式），以确定消息是否过期。如果消息过期，对等方必须生成一个错误代码为0x17“error\u message\u expired”的响应，将响应返回到发起方节点，并丢弃该消息。
o If the message is not expired, the receiver MUST construct a DiagnosticsResponse structure as follows: 1) the TTL value from the forwarding header is copied to the hop_counter field of the DiagnosticsResponse structure (note that the default value for TTL at the beginning represents 100 hops unless the overlay configuration has overridden the value), and 2) the receiver
o 如果消息未过期，则接收方必须按如下方式构造DiagnosticsResponse结构：1）转发头中的TTL值复制到DiagnosticsResponse结构的hop_计数器字段（请注意，除非覆盖配置已覆盖该值，否则TTL在开始时的默认值表示100跳），以及2）接收器
generates a Unix time format timestamp for the current time of day and places it in the timestamp_received field and constructs a new expiration time and places it in the expiration field of the DiagnosticsResponse.
为当前时间生成Unix时间格式的时间戳，并将其放置在timestamp_received字段中，构造新的过期时间并将其放置在DiagnosticsResponse的过期字段中。
o The destination peer MUST check if the initiator node has the authority to request specific types of diagnostic information, and if appropriate, append the diagnostic information requested in the dMFlags and diagnostic_extensions (if any) using the diagnostic_info_list field to the DiagnosticsResponse structure. If any information is returned, the receiver MUST calculate the length of the response and set ext_length appropriately. If no diagnostic information is returned, ext_length MUST be set to zero.
o 目标对等方必须检查发起方节点是否有权请求特定类型的诊断信息，并在适当的情况下，使用diagnostic_info_列表字段将dMFlags和diagnostic_extensions（如果有）中请求的诊断信息附加到DiagnosticsResponse结构中。如果返回任何信息，接收方必须计算响应的长度，并适当设置ext_长度。如果未返回任何诊断信息，则ext_length必须设置为零。
o The format of the DiagnosticResponse data structure and its fields MUST follow the restrictions defined in Section 5.2.
o DiagnosticResponse数据结构及其字段的格式必须遵循第5.2节中定义的限制。
o In the event of an error, an error response containing the error code followed by the description (if they exist) MUST be created and sent to the sender. If the initiator node asks for diagnostic information that they are not authorized to query, the receiving peer MUST return an error response with the error code 2 "Error_Forbidden".
o 发生错误时，必须创建包含错误代码和描述（如果存在）的错误响应，并将其发送给发件人。如果发起方节点请求未经授权查询的诊断信息，则接收对等方必须返回错误响应，错误代码为2“error_OPRIBLED”。
The initiator node, as well as the responding peer, may compute the overlay One-Way-Delay time through the value in timestamp_received and the timestamp_initiated field. However, for a single hop measurement, the traditional measurement methods (IP-layer ping) MUST be used instead of the overlay layer diagnostics methods.
发起方节点以及响应对等方可以通过接收到的timestamp_和timestamp_initiated字段中的值来计算覆盖单向延迟时间。但是，对于单跳测量，必须使用传统的测量方法（IP层ping），而不是覆盖层诊断方法。
The P2P overlay network using the diagnostics methods specified in this document MUST enforce time synchronization with a central time server. The Network Time Protocol [RFC5905] can usually maintain time to within tens of milliseconds over the public Internet and can achieve better than one millisecond accuracy in local area networks under ideal conditions. However, this document does not specify the choice for time resolution and synchronization, leaving it to the implementation.
使用本文档中指定的诊断方法的P2P覆盖网络必须与中央时间服务器进行时间同步。网络时间协议[RFC5905]通常可以在公共互联网上将时间保持在几十毫秒以内，并且在理想条件下可以在局域网中实现优于一毫秒的精度。但是，本文档没有指定时间解析和同步的选择，将其留给实现。
The initiator node receiving the Ping response may check the hop_counter field and compute the overlay hops to the destination peer for the statistics of connectivity quality from the perspective of overlay hops.
接收Ping响应的发起方节点可以检查hop_计数器字段，并计算到目的地对等方的覆盖跳跃，以从覆盖跳跃的角度统计连接质量。
Different level of access control can be made for different users/ nodes. For example, diagnostic information A can be accessed by nodes 1 and 2, but diagnostic information B can only be accessed by node 2.
可以针对不同的用户/节点进行不同级别的访问控制。例如，诊断信息A可由节点1和2访问，但诊断信息B只能由节点2访问。
The overlay configuration file MUST contain the following XML elements for authorizing a node to access the relative diagnostic Kinds.
覆盖配置文件必须包含以下XML元素，以授权节点访问相关诊断类型。
diagnostic-kind: This has the attribute "kind" with the hexadecimal number indicating the diagnostic Kind ID. This attribute has the same value with Section 9.2 and at least one subelement "access-node".
诊断种类：该属性为“种类”，十六进制数字表示诊断种类ID。该属性的值与第9.2节相同，至少有一个子元素“访问节点”。
access-node: This element contains one hexadecimal number indicating a NodeID, and the node with this NodeID is allowed to access the diagnostic "kind" under the same diagnostic-kind element.
访问节点：此元素包含一个十六进制数字，表示节点ID，具有此节点ID的节点可以访问同一诊断种类元素下的诊断“种类”。
The authorization for diagnostic information must be designed with care to prevent it becoming a method to retrieve information for both attacks. It should also be noted that attackers can use diagnostics to analyze overlay information to attack certain key peers. For example, diagnostic information might be used to fingerprint a peer where the peer will lose its anonymity characteristics, but anonymity might be very important for some P2P overlay networks, and defenses against such fingerprinting are probably very hard. As such, networks where anonymity is of very high importance may find implementation of diagnostics problematic or even undesirable, despite the many advantages it offers. As this document is a RELOAD extension, it follows RELOAD message header and routing specifications. The common security considerations described in the base document [RFC6940] are also applicable to this document. Overlays may define their own requirements on who can collect/share diagnostic information.
诊断信息的授权必须小心设计，以防止它成为检索两种攻击信息的方法。还应注意，攻击者可以使用诊断分析覆盖信息来攻击某些关键对等方。例如，诊断信息可用于对对等方进行指纹识别，而对等方将失去其匿名性特征，但匿名性对于某些P2P覆盖网络可能非常重要，并且对此类指纹识别的防御可能非常困难。因此，匿名性非常重要的网络可能会发现诊断的实现存在问题，甚至是不可取的，尽管它提供了许多优势。由于此文档是重新加载扩展，因此遵循重新加载消息头和路由规范。基本文档[RFC6940]中描述的常见安全注意事项也适用于本文档。覆盖层可定义其对谁可以收集/共享诊断信息的要求。
IANA has created a "RELOAD Diagnostics Flag" registry under protocol RELOAD. Entries in this registry are 1-bit flags contained in a 64-bit integer dMFlags denoting diagnostic information to be retrieved as described in Section 4.3.1. New entries SHALL be defined via Standards Action as per [RFC5226]. The initial contents of this registry are:
IANA已在协议重新加载下创建了“重新加载诊断标志”注册表。此注册表中的条目是包含在64位整数dMFlags中的1位标志，表示要检索的诊断信息，如第4.3.1节所述。应根据[RFC5226]通过标准行动定义新条目。此注册表的初始内容包括：
+-------------------------+----------------------------+----------+
| Diagnostic Information |Diagnostic Flag in dMFlags | Reference|
|-------------------------+----------------------------+----------|
|Reserved All 0s value | 0x 0000 0000 0000 0000 | RFC 7851 |
|Reserved First Bit | 0x 0000 0000 0000 0001 | RFC 7851 |
|STATUS_INFO | 0x 0000 0000 0000 0002 | RFC 7851 |
|ROUTING_TABLE_SIZE | 0x 0000 0000 0000 0004 | RFC 7851 |
|PROCESS_POWER | 0x 0000 0000 0000 0008 | RFC 7851 |
|UPSTREAM_BANDWIDTH | 0x 0000 0000 0000 0010 | RFC 7851 |
|DOWNSTREAM_ BANDWIDTH | 0x 0000 0000 0000 0020 | RFC 7851 |
|SOFTWARE_VERSION | 0x 0000 0000 0000 0040 | RFC 7851 |
|MACHINE_UPTIME | 0x 0000 0000 0000 0080 | RFC 7851 |
|APP_UPTIME | 0x 0000 0000 0000 0100 | RFC 7851 |
|MEMORY_FOOTPRINT | 0x 0000 0000 0000 0200 | RFC 7851 |
|DATASIZE_STORED | 0x 0000 0000 0000 0400 | RFC 7851 |
|INSTANCES_STORED | 0x 0000 0000 0000 0800 | RFC 7851 |
|MESSAGES_SENT_RCVD | 0x 0000 0000 0000 1000 | RFC 7851 |
|EWMA_BYTES_SENT | 0x 0000 0000 0000 2000 | RFC 7851 |
|EWMA_BYTES_RCVD | 0x 0000 0000 0000 4000 | RFC 7851 |
|UNDERLAY_HOP | 0x 0000 0000 0000 8000 | RFC 7851 |
|BATTERY_STATUS | 0x 0000 0000 0001 0000 | RFC 7851 |
|Reserved Last Bit | 0x 8000 0000 0000 0000 | RFC 7851 |
|Reserved All 1s value | 0x ffff ffff ffff ffff | RFC 7851 |
+-------------------------+----------------------------+----------+
+-------------------------+----------------------------+----------+
| Diagnostic Information |Diagnostic Flag in dMFlags | Reference|
|-------------------------+----------------------------+----------|
|Reserved All 0s value | 0x 0000 0000 0000 0000 | RFC 7851 |
|Reserved First Bit | 0x 0000 0000 0000 0001 | RFC 7851 |
|STATUS_INFO | 0x 0000 0000 0000 0002 | RFC 7851 |
|ROUTING_TABLE_SIZE | 0x 0000 0000 0000 0004 | RFC 7851 |
|PROCESS_POWER | 0x 0000 0000 0000 0008 | RFC 7851 |
|UPSTREAM_BANDWIDTH | 0x 0000 0000 0000 0010 | RFC 7851 |
|DOWNSTREAM_ BANDWIDTH | 0x 0000 0000 0000 0020 | RFC 7851 |
|SOFTWARE_VERSION | 0x 0000 0000 0000 0040 | RFC 7851 |
|MACHINE_UPTIME | 0x 0000 0000 0000 0080 | RFC 7851 |
|APP_UPTIME | 0x 0000 0000 0000 0100 | RFC 7851 |
|MEMORY_FOOTPRINT | 0x 0000 0000 0000 0200 | RFC 7851 |
|DATASIZE_STORED | 0x 0000 0000 0000 0400 | RFC 7851 |
|INSTANCES_STORED | 0x 0000 0000 0000 0800 | RFC 7851 |
|MESSAGES_SENT_RCVD | 0x 0000 0000 0000 1000 | RFC 7851 |
|EWMA_BYTES_SENT | 0x 0000 0000 0000 2000 | RFC 7851 |
|EWMA_BYTES_RCVD | 0x 0000 0000 0000 4000 | RFC 7851 |
|UNDERLAY_HOP | 0x 0000 0000 0000 8000 | RFC 7851 |
|BATTERY_STATUS | 0x 0000 0000 0001 0000 | RFC 7851 |
|Reserved Last Bit | 0x 8000 0000 0000 0000 | RFC 7851 |
|Reserved All 1s value | 0x ffff ffff ffff ffff | RFC 7851 |
+-------------------------+----------------------------+----------+
IANA has created a "RELOAD Diagnostic Kind ID" registry under protocol RELOAD. Entries in this registry are 16-bit integers denoting diagnostics extension data kinds carried in the diagnostic request and response messages, as described in Sections and 5.1 and 5.2. Code points from 0x0001 to 0x003e are asked to be assigned together with flags within the "RELOAD Diagnostics Flag" registry. The registration procedure for the "RELOAD Diagnostic Kind ID" registry is Standards Action as defined in RFC 5226.
IANA已在协议重新加载下创建了“重新加载诊断种类ID”注册表。此注册表中的条目是16位整数，表示诊断请求和响应消息中携带的诊断扩展数据类型，如第节和第5.1和5.2节所述。要求将0x0001到0x003e的代码点与“重新加载诊断标志”注册表中的标志一起分配。“重新加载诊断种类ID”注册表的注册程序是RFC 5226中定义的标准操作。
+----------------------+---------------+---------------+
| Diagnostic Kind | Code | Specification |
+----------------------+---------------+---------------+
| Reserved | 0x0000 | RFC 7851 |
| STATUS_INFO | 0x0001 | RFC 7851 |
| ROUTING_TABLE_SIZE | 0x0002 | RFC 7851 |
| PROCESS_POWER | 0x0003 | RFC 7851 |
| UPSTREAM_BANDWIDTH | 0x0004 | RFC 7851 |
| DOWNSTREAM_BANDWIDTH | 0x0005 | RFC 7851 |
| SOFTWARE_VERSION | 0x0006 | RFC 7851 |
| MACHINE_UPTIME | 0x0007 | RFC 7851 |
| APP_UPTIME | 0x0008 | RFC 7851 |
| MEMORY_FOOTPRINT | 0x0009 | RFC 7851 |
| DATASIZE_STORED | 0x000a | RFC 7851 |
| INSTANCES_STORED | 0x000b | RFC 7851 |
| MESSAGES_SENT_RCVD | 0x000c | RFC 7851 |
| EWMA_BYTES_SENT | 0x000d | RFC 7851 |
| EWMA_BYTES_RCVD | 0x000e | RFC 7851 |
| UNDERLAY_HOP | 0x000f | RFC 7851 |
| BATTERY_STATUS | 0x0010 | RFC 7851 |
| Unassigned | 0x0011-0x003e | RFC 7851 |
| local use (Reserved) | 0xf000-0xfffe | RFC 7851 |
| Reserved | 0xffff | RFC 7851 |
+----------------------+---------------+---------------+
+----------------------+---------------+---------------+
| Diagnostic Kind | Code | Specification |
+----------------------+---------------+---------------+
| Reserved | 0x0000 | RFC 7851 |
| STATUS_INFO | 0x0001 | RFC 7851 |
| ROUTING_TABLE_SIZE | 0x0002 | RFC 7851 |
| PROCESS_POWER | 0x0003 | RFC 7851 |
| UPSTREAM_BANDWIDTH | 0x0004 | RFC 7851 |
| DOWNSTREAM_BANDWIDTH | 0x0005 | RFC 7851 |
| SOFTWARE_VERSION | 0x0006 | RFC 7851 |
| MACHINE_UPTIME | 0x0007 | RFC 7851 |
| APP_UPTIME | 0x0008 | RFC 7851 |
| MEMORY_FOOTPRINT | 0x0009 | RFC 7851 |
| DATASIZE_STORED | 0x000a | RFC 7851 |
| INSTANCES_STORED | 0x000b | RFC 7851 |
| MESSAGES_SENT_RCVD | 0x000c | RFC 7851 |
| EWMA_BYTES_SENT | 0x000d | RFC 7851 |
| EWMA_BYTES_RCVD | 0x000e | RFC 7851 |
| UNDERLAY_HOP | 0x000f | RFC 7851 |
| BATTERY_STATUS | 0x0010 | RFC 7851 |
| Unassigned | 0x0011-0x003e | RFC 7851 |
| local use (Reserved) | 0xf000-0xfffe | RFC 7851 |
| Reserved | 0xffff | RFC 7851 |
+----------------------+---------------+---------------+
Table 1: Diagnostic Kind
表1：诊断类别
This document introduces two new types of messages and their responses, so the following additions have been made to the "RELOAD Message Codes" registry defined in RELOAD [RFC6940].
本文档介绍了两种新类型的消息及其响应，因此在RELOAD[RFC6940]中定义的“RELOAD Message Codes”注册表中添加了以下内容。
+-------------------+------------+----------+
| Message Code Name | Code Value | RFC |
+-------------------+------------+----------+
| path_track_req | 0x27 | RFC 7851 |
| path_track_ans | 0x28 | RFC 7851 |
+-------------------+------------+----------+
+-------------------+------------+----------+
| Message Code Name | Code Value | RFC |
+-------------------+------------+----------+
| path_track_req | 0x27 | RFC 7851 |
| path_track_ans | 0x28 | RFC 7851 |
+-------------------+------------+----------+
Table 2: Extensions to RELOAD Message Codes
表2：重新加载消息代码的扩展
This document introduces the following new error codes, which have been added to the "RELOAD Error Codes" registry.
本文档介绍了以下新的错误代码，这些代码已添加到“重新加载错误代码”注册表中。
+----------------------------------------+------------+-----------+
| Error Code Name | Code Value | Reference |
+----------------------------------------+------------+-----------+
| Error_Underlay_Destination_Unreachable | 0x15 | RFC 7851 |
| Error_Underlay_Time_Exceeded | 0x16 | RFC 7851 |
| Error_Message_Expired | 0x17 | RFC 7851 |
| Error_Upstream_Misrouting | 0x18 | RFC 7851 |
| Error_Loop_Detected | 0x19 | RFC 7851 |
| Error_TTL_Hops_Exceeded | 0x1A | RFC 7851 |
+----------------------------------------+------------+-----------+
+----------------------------------------+------------+-----------+
| Error Code Name | Code Value | Reference |
+----------------------------------------+------------+-----------+
| Error_Underlay_Destination_Unreachable | 0x15 | RFC 7851 |
| Error_Underlay_Time_Exceeded | 0x16 | RFC 7851 |
| Error_Message_Expired | 0x17 | RFC 7851 |
| Error_Upstream_Misrouting | 0x18 | RFC 7851 |
| Error_Loop_Detected | 0x19 | RFC 7851 |
| Error_TTL_Hops_Exceeded | 0x1A | RFC 7851 |
+----------------------------------------+------------+-----------+
Table 3: RELOAD Error Codes
表3：重新加载错误代码
This document introduces the following new RELOAD extension code:
本文档介绍了以下新的重新加载扩展代码：
+-----------------+------+-----------+
| Extension Name | Code | Reference |
+-----------------+------+-----------+
| Diagnostic_Ping | 0x2 | RFC 7851 |
+-----------------+------+-----------+
+-----------------+------+-----------+
| Extension Name | Code | Reference |
+-----------------+------+-----------+
| Diagnostic_Ping | 0x2 | RFC 7851 |
+-----------------+------+-----------+
Table 4: New RELOAD Extension Code
表4：新的重新加载扩展代码
This document registers a URI for the config-diagnostics XML namespace in the IETF XML registry defined in [RFC3688]. All the elements defined in this document belong to this namespace.
本文档在[RFC3688]中定义的IETF XML注册表中注册配置诊断XML命名空间的URI。此文档中定义的所有元素都属于此命名空间。
URI: urn:ietf:params:xml:ns:p2p:config-diagnostics
Registrant Contact: The IESG.
XML: N/A; the requested URIs are XML namespaces
URI: urn:ietf:params:xml:ns:p2p:config-diagnostics
Registrant Contact: The IESG.
XML: N/A; the requested URIs are XML namespaces
The overlay configuration file MUST contain the following XML language declaring P2P diagnostics as a mandatory extension to RELOAD.
覆盖配置文件必须包含以下XML语言，将P2P诊断声明为必须重新加载的扩展名。
<mandatory-extension>
urn:ietf:params:xml:ns:p2p:config-diagnostics
</mandatory-extension>
<mandatory-extension>
urn:ietf:params:xml:ns:p2p:config-diagnostics
</mandatory-extension>
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <http://www.rfc-editor.org/info/rfc792>.
[RFC792]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，DOI 10.17487/RFC0792，1981年9月<http://www.rfc-editor.org/info/rfc792>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <http://www.rfc-editor.org/info/rfc3688>.
[RFC3688]Mealling，M.，“IETF XML注册表”，BCP 81，RFC 3688，DOI 10.17487/RFC3688，2004年1月<http://www.rfc-editor.org/info/rfc3688>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <http://www.rfc-editor.org/info/rfc5905>.
[RFC5905]Mills，D.，Martin，J.，Ed.，Burbank，J.，和W.Kasch，“网络时间协议版本4：协议和算法规范”，RFC 5905，DOI 10.17487/RFC59052010年6月<http://www.rfc-editor.org/info/rfc5905>.
[RFC6940] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", RFC 6940, DOI 10.17487/RFC6940, January 2014, <http://www.rfc-editor.org/info/rfc6940>.
[RFC6940]Jennings，C.，Lowekamp，B.，Ed.，Rescorla，E.，Baset，S.，和H.Schulzrinne，“资源定位和发现（重新加载）基础协议”，RFC 6940，DOI 10.17487/RFC6940，2014年1月<http://www.rfc-editor.org/info/rfc6940>.
[RFC7263] Zong, N., Jiang, X., Even, R., and Y. Zhang, "An Extension to the REsource LOcation And Discovery (RELOAD) Protocol to Support Direct Response Routing", RFC 7263, DOI 10.17487/RFC7263, June 2014, <http://www.rfc-editor.org/info/rfc7263>.
[RFC7263]Zong，N.，Jiang，X.，Even，R.，和Y.Zhang，“支持直接响应路由的资源定位和发现（重新加载）协议的扩展”，RFC 7263，DOI 10.17487/RFC7263，2014年6月<http://www.rfc-editor.org/info/rfc7263>.
[UnixTime] Wikipedia, "Unix time", April 2016, <https://en.wikipedia.org/w/ index.php?title=Unix_time&oldid=715503178>.
[UnixTime]维基百科，“Unix时代”，2016年4月<https://en.wikipedia.org/w/ index.php？title=Unix\u time&oldid=715503178>。
[P2PSIP-CONCEPTS] Bryan, D., Matthews, P., Shim, E., Willis, D., and S. Dawkins, "Concepts and Terminology for Peer to Peer SIP", Work in Progress, draft-ietf-p2psip-concepts-09, April 2016.
[P2PSIP-CONCEPTS]Bryan，D.，Matthews，P.，Shim，E.，Willis，D.，和S.Dawkins，“对等SIP的概念和术语”，在建工程，草案-ietf-P2PSIP-CONCEPTS-092016年4月。
[Overlay-Failure-Detection] Zhuang, S., Geels, D., Stoica, I., and R. Katz, "On failure detection algorithms in overlay networks", In Proceedings of the IEEE INFOCOM 2005, pp. 2112-2123, DOI 10.1109/INFCOM.2005.1498487, March 2005.
[Overlay Failure Detection]Zhuang，S.，Geels，D.，Stoica，I.，和R.Katz，“关于重叠网络中的故障检测算法”，载于IEEE INFOCOM 2005年会议记录，第2112-2123页，DOI 10.1109/INFCOM.2005.1498487，2005年3月。
[Handling_Churn_in_a_DHT] Rhea, S., Geels, D., Roscoe, T., and J. Kubiatowicz, "Handling Churn in a DHT", In Proceedings of the USENIX Annual Technical Conference, June 2004.
[在DHT中处理搅动物]Rhea，S.，Geels，D.，Roscoe，T.，和J.Kubiatowicz，“在DHT中处理搅动物”，发表于《USENIX年度技术会议记录》，2004年6月。
[Diagnostic_Framework] Jin, X., Xiong, Y., Zhang, Q., and S. Chan, "A Diagnostic Framework for Peer-to-peer Streaming", IEEE ICME 2006, July 2006.
[Diagnostic_Framework]Jin，X.，Xong，Y.，Zhang，Q.，和S.Chan，“对等流的诊断框架”，IEEE ICME 2006，2006年7月。
Below, we sketch how these metrics can be used.
下面，我们简要介绍如何使用这些指标。
A peer may set EWMA_BYTES_SENT and EWMA_BYTES_RCVD flags in the PathTrackReq to its direct neighbors. A peer can use EWMA_BYTES_SENT and EWMA_BYTES_RCVD of another peer to infer whether it is acting as a media relay. It may then choose not to forward any requests for media relay to this peer. Similarly, among the various candidates for filling up a routing table, a peer may prefer a peer with a large UPTIME value, small RTT, and small LAST_CONTACT value.
对等方可以将PathTrackReq中的EWMA_字节发送和EWMA_字节RCVD标志设置为其直接邻居。对等方可以使用另一对等方的EWMA_字节数_发送和EWMA_字节数_RCVD来推断它是否充当媒体中继。然后，它可以选择不向该对等方转发任何媒体中继请求。类似地，在填充路由表的各种候选中，对等方可能更喜欢具有大正常运行时间值、小RTT和小最后联系值的对等方。
A peer may set the STATUS_INFO Flag in the PathTrackReq to a remote destination peer. The overlay has its own threshold definition for congestion. The peer can obtain knowledge of all the status information of the intermediate peers along the path, then it can choose other paths to that node for the subsequent requests.
对等方可以将PathTrackReq中的状态信息标志设置为远程目标对等方。覆盖有自己的拥塞阈值定义。对等方可以获得沿路径的中间对等方的所有状态信息的知识，然后可以为后续请求选择到该节点的其他路径。
A peer may use Ping to evaluate the average overlay hops to other peers by sending PingReq to a set of random resource or node IDs in the overlay. A peer may adjust its timeout value according to the change of average overlay hops.
对等方可以使用Ping通过向覆盖中的一组随机资源或节点id发送PingReq来评估到其他对等方的平均覆盖跳数。对等方可以根据平均覆盖跳数的变化调整其超时值。
An earlier draft version of this document considered an approach where a response was generated by each intermediate peer as the message traversed the overlay. This approach was discarded. One reason this approach was discarded was that it could provide a DoS mechanism, whereby an attacker could send an arbitrary message claiming to be from a spoofed "sender" the real sender wished to attack. As a result of sending this one message, many messages would be generated and sent back to the spoofed "sender" -- one from each intermediate peer on the message path. While authentication mechanisms could reduce some risk of this attack, it still resulted in a fundamental break from the request-response nature of the RELOAD protocol, as multiple responses are generated to a single request. Although one request with responses from all the peers in the route will be more efficient, it was determined to be too great a security risk and a deviation from the RELOAD architecture.
本文档的早期草案版本考虑了一种方法，即当消息穿过覆盖层时，每个中间对等方生成响应。这种方法被放弃了。放弃这种方法的一个原因是，它可以提供DoS机制，攻击者可以通过该机制发送任意消息，声称来自真实发件人希望攻击的伪造“发件人”。作为发送这一条消息的结果，许多消息将被生成并发送回伪造的“发送者”——消息路径上的每个中间对等方都会发送一条消息。虽然身份验证机制可以降低这种攻击的一些风险，但它仍然从根本上打破了重新加载协议的请求-响应特性，因为一个请求会生成多个响应。虽然一个请求和来自路由中所有对等方的响应将更有效，但它被确定为安全风险太大，并且偏离了重新加载架构。
Acknowledgments
致谢
We would like to thank Zheng Hewen for the contribution of the initial draft version of this document. We would also like to thank Bruce Lowekamp, Salman Baset, Henning Schulzrinne, Jiang Haifeng, and Marc Petit-Huguenin for the email discussion and their valued comments, and special thanks to Henry Sinnreich for contributing to the usage scenarios text. We would like to thank the authors of the RELOAD protocol for transferring text about diagnostics to this document.
我们要感谢郑和文对本文件初稿的贡献。我们还要感谢Bruce Lowekamp、Salman Baset、Henning Schulzrinne、Jiang Haifeng和Marc Petit Huguenin的电子邮件讨论和他们的宝贵意见，并特别感谢Henry Sinnreich对使用场景文本的贡献。我们要感谢重新加载协议的作者将有关诊断的文本传输到本文档中。
Authors' Addresses
作者地址
Haibin Song Huawei
宋海斌
Email: haibin.song@huawei.com
Email: haibin.song@huawei.com
Jiang Xingfeng Huawei
姜兴峰华为
Email: jiangxingfeng@huawei.com
Email: jiangxingfeng@huawei.com
Roni Even Huawei 14 David Hamelech Tel Aviv 64953 Israel
Roni甚至华为14 David Hamelech特拉维夫64953以色列
Email: ron.even.tlv@gmail.com
Email: ron.even.tlv@gmail.com
David A. Bryan ethernot.org Cedar Park, Texas United States
David A.Bryan ethernot.org美国德克萨斯州雪松公园
Email: dbryan@ethernot.org
Email: dbryan@ethernot.org
Yi Sun ICT
孙怡
Email: sunyi@ict.ac.cn
Email: sunyi@ict.ac.cn