[要約] RFC 7851は、P2Pオーバーレイ診断のためのガイドラインを提供するものであり、P2Pネットワークのトラブルシューティングとパフォーマンスの向上を目的としています。
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）オーバーレイ診断のメカニズムについて説明します。 REsource LOcation And Discovery（RELOAD）ベースプロトコルの拡張機能を定義して、診断情報を収集し、これらの拡張機能のプロトコル仕様を詳しく説明します。接続とノードステータスの監視に役立つ診断情報も定義されています。このドキュメントでは、使用シナリオについても説明し、これらのメソッドを使用して診断を実行する方法の例を示します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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.
ここ数年で、オーバーレイネットワークは急速に進化し、新しいアプリケーションとサービスをインターネットに展開するための有望なプラットフォームとして登場しました。オーバーレイネットワークが大規模分散システムの優れたプラットフォームと見なされる理由の1つは、障害が発生した場合の回復力です。この回復力には、データ複製、ルーティングの回復、静的回復力の3つの側面があります。ルーティングリカバリアルゴリズムは、障害が検出されたときに、ライブテーブルをルーティングテーブルに再配置するために使用されます。静的復元力は、復旧アルゴリズムがルーティングテーブルを修復する前でも、オーバーレイが障害を迂回できる程度を測定します。ルーティングの回復と静的な復元力はどちらも、障害を正確かつタイムリーに検出することに依存しています。
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.
定期的なプローブと確認メカニズムに基づく一部のキープアライブアルゴリズムは、1つのノードのネイバーの障害を正確かつタイムリーに検出できるようにします[Overlay-Failure-Detection]。これは、オーバーレイネットワークを運用しているサービスプロバイダーにとって十分ではない場合があります。
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オーバーレイ診断フレームワークが望ましい。このドキュメントでは、基本プロトコルRELOAD [RFC6940]に対する一般的なP2Pオーバーレイ診断拡張機能について説明し、P2Pオーバーレイ自体のキープアライブアルゴリズムを補足することを目的としています。読者は、問題のあるドメインの背景について、[P2PSIP-CONCEPTS]を参照することをお勧めします。
This document uses the concepts defined in RELOAD [RFC6940]. In addition, the following terms are used in the document:
このドキュメントでは、RELOAD [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.
オーバーレイホップ：1つのオーバーレイホップは、RELOADオーバーレイのイニシエーターノードと宛先ピア間のパスの一部です。パケットがRELOADオーバーレイの次のノードに渡されるたびに、1つのオーバーレイホップが発生します。
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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診断の一般的な使用シナリオは、大きく3つのクラスに分類できます。
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オーバーレイルーティングプロトコルに組み込まれた自動診断。ノードは既知のネイバーの定期的なチェックを実行し、接続チェックに応答しないルーティングテーブルからそれらのノードを削除します[Handling_Churn_in_a_DHT]。たとえば、ローカルの暗号処理の過負荷、ディスク処理の過負荷、リンクの過負荷などが原因で、応答しないノードが一時的にのみ無効になる場合があります。したがって、接続性チェックを繰り返してノードが回復し、ルーティングテーブルに再度配置できることを確認すると便利です。このプロセスは「障害が発生したノードの回復」と呼ばれ、「DHTでのチャーンの処理」[Handling_Churn_in_a_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 diagnostics methods. The extensions strictly follow how RELOAD specifies message routing, transport, NAT traversal, and other RELOAD protocol features.
RELOAD診断拡張機能は、データを収集する2つのメカニズムを定義します。 1つはRELOAD Pingメカニズムの拡張機能であり、ノードからの診断データの照会や、そのノードへのパスの診断を可能にします。 2つ目は、診断情報を繰り返し収集するための新しいメソッドPathTrackです。診断データの収集と表現を可能にするこれらのメカニズムのペイロードが提示され、追加のエラーコードが導入されます。基本的に、このドキュメントはRELOAD仕様[RFC6940]を再利用し、それを拡張して新しい診断方法を紹介します。拡張機能は、RELOADがメッセージのルーティング、トランスポート、NATトラバーサル、およびその他のRELOADプロトコル機能を指定する方法に厳密に従います。
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のような」モード（RELOAD Pingメソッドを拡張して診断を収集する）と「tracerouteのような」モード（新しい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.
これらのツールを使用できる1つの方法は、指定されたノードへの接続、または拡張Ping操作による指定されたリソースレコードの可用性を検出することです。オーバーレイネットワークがオーバーレイサービスの低下または中断に関するいくつかのアラームを受信すると、Pingが送信されます。 Pingが失敗した場合は、PathTrackを送信して、障害の場所を特定できます。
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.
このドキュメントでは、診断の種類に基づいて一般的な管理シナリオを検討します。ここでは、オーバーレイ全体が特定の種類の診断情報を特定のノード（管理ノードなど）の小さなリストに許可できます。つまり、ノードが診断の種類にアクセスするための承認を得た場合、オーバーレイネットワーク内のすべてのノードからその情報にアクセスできます。特定のノードが範囲外のノードの特定のリストにその診断情報を承認するというシナリオを残します。これは、近い将来に要件がある場合、このドキュメントを拡張することで実現できます。診断拡張機能ドキュメントで指定されていない限り、診断情報のタイプのデフォルトポリシーまたはアクセスルールは「拒否」です。 RELOADプロトコルでは、各メッセージに送信者のメッセージ署名が含まれている必要があるため、診断要求の受信者は署名を使用して送信者を識別できます。次に、このシグニチャーを含むオーバーレイ構成ファイルを使用して、ノードが許可されている診断情報のタイプを判別できます。
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リスト[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のような」動作を提供するために、RELOAD 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 | | |
| | | |
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要求を拡張するために、RELOADの新しい拡張が定義されています。 RELOADの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リクエスト拡張については、表4に示すように、「Diagnostic_Ping」という名前の新しいMessageExtensionType、拡張0x2を定義します。拡張コンテンツは、セクション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であるかのように扱います。送信者は、診断情報のない応答を受け入れなければならず、応答を期待しているメッセージを再送してはなりません（SHOULD NOT）。この拡張子を含む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は、宛先IDへのネクストホップピアであるネイバーBに問い合わせ、BはネクストホップピアC情報とオプションの診断情報を含むメッセージを返します。イニシエータノードへのB。次に、イニシエーターノードAはネクストホップピアC（直接応答ルーティング[RFC7263]または対称ルーティング経由）にネクストホップピアD情報とCの診断情報を返すように要求します。障害がメッセージの転送を妨げない限り、この手順は要求が宛先のピア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 |
|<-------------------|--------------------|--------------------|
| | | |
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および一連のFetchリクエストを使用して、PathTrackメカニズムを置き換えることができるという提案がありました。ただし、チャーンの発生率が高い場合、RouteQuery操作とFetch操作の間でパスが変わる可能性があるため、厳密に言えば、このような操作では同じ結果は得られません。当然、PathTrackのステップ間でもパスが変化する可能性がありますが、クエリとフェッチに2つのメッセージではなく単一のメッセージを使用することで、矛盾が少なくなる可能性が高いため、単一のメッセージの使用が推奨されます。
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への連続した呼び出しが異なるパスを返す場合、結果を破棄して要求を再送信し、 2番目の要求は適切なパスを通過します。
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.
このドキュメントでは、新しいRELOADメソッドPathTrackを定義して、ルーティングパスに沿って中間ピアから診断情報を取得します。 PathTrackリクエストの各ステップで、責任のあるピアは、リクエストされたステータス情報でイニシエータノードに応答します。ステータス情報には、ピアの輻輳状態、処理能力、使用可能な帯域幅、ネイバーテーブルのエントリ数、アップタイム、ID、ネットワークアドレス情報、ネクストホップピア情報を含めることができます。
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;
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.
destination：イニシエーターノードが対象とする宛先。これは、NodeID、不透明なID、ResourceIDなど、有効な宛先オブジェクトです。デバッグの目的で、イニシエーターは、障害が発生したときに使用された宛先IDを使用することに注意してください。
request: A DiagnosticsRequest, as discussed in Section 5.1.
request：セクション5.1で説明したDiagnosticsRequest。
The structure of the PathTrack response is as follows:
PathTrack応答の構造は次のとおりです。
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.
next_hop：応答する中間ピアから宛先へのネクストホップノードの情報。応答するピアが宛先IDの責任ピアである場合、next_hopノードIDは応答するノードIDと等しく、next_hopノードIDが応答するノードIDと等しいPathTrackAnsを受信した後、イニシエーターは反復プロセスを停止する必要があります。
response: A DiagnosticsResponse, as discussed in Section 5.2.
応答：5.2項で説明したように、DiagnosticsResponse。
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:
このドキュメントは、RELOAD仕様で定義されたエラー応答メソッドを拡張して、診断クエリから発生するエラーケースをサポートします。 RELOADでエラーが発生すると、メッセージコード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 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
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_fieldを使用して、アンダーレイの宛先に到達できない理由（ネットに到達できない、ホストに到達できない、断片化が必要など）に関する追加情報を提供できます。 。
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メソッドはどちらも、次の一般的な診断データ構造を使用してデータを収集します。 2つの一般的な構造が定義されています。データを要求するためのDiagnosticsRequestと、情報を返すためのDiagnosticsResponseです。
The DiagnosticsRequest data structure is used to request diagnostic information and has the following form:
DiagnosticsRequestデータ構造は、診断情報を要求するために使用され、次の形式になります。
enum{ (2^16-1) } DiagnosticKindId;
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;
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.
expire：1970年1月1日UTC（うるう秒は数えない）の午前0時から経過したミリ秒数として表される、リクエストの有効期限。秒の値は、標準のUNIX時間またはPOSIX時間と同じです。詳細については、Wikipedia [UnixTime]の「Unix time」を参照してください。この値は、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：診断要求が開始された時刻。UTC1970年1月1日の午前0時から経過したミリ秒数として表されます（うるう秒はカウントされません）。秒の値は、標準の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のビットと提示された診断Kind 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以上の場合、受信者が拡張要求を理解し、提供する意思がある場合、この情報が応答に含まれると想定して、拡張診断情報が要求されます。要求された特定の診断情報は、以下のdiagnostic_extensions_listで定義されています。ゼロの値は、拡張診断情報が要求されていないことを示します。 ext_lengthの値は負であってはなりません。 DiagnosticsRequestデータ構造全体の長さではなく、diagnostic_extensions_listを構成するデータの長さに注意してください。
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:
diagnostic_extensions_list：1つ以上の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.
kind：拡張診断情報のタイプを示す数値コード（セクション9.2を参照）。種類0xf000-0xfffeはオーバーレイ固有の診断用に予約されており、ローカル診断情報のIANA登録なしで使用できることに注意してください。 0x0000から0x003fまでの種類は、メッセージリクエストのdiagnostic_extensions_listで指定してはなりません。これは、dMFlagsを使用して、はるかに単純な（スペース効率が高い）方法で表される場合があるためです。
diagnostic_extension_contents: The opaque data containing the request for this particular extension. This data is extension dependent.
diagnostic_extension_contents：この特定の拡張機能のリクエストを含む不透明なデータ。このデータは拡張子に依存します。
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;
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.
有効期限：応答が期限切れになる時間は、1970年1月1日UTC（うるう秒は含まない）の午前0時から経過したミリ秒数として表されます。秒の値は、標準の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.
timestamp_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日の午前0時から経過したミリ秒数として表されます（うるう秒はカウントされません）。秒の値は、標準の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.
hop_counter：このフィールドは診断応答にのみ表示されます。受信したリクエストの転送ヘッダーの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で指定された）拡張診断情報が利用可能であり、返されています。その場合、この値は返される情報の長さを示します。値0は、何も要求されなかったか、要求に対応できなかったために、拡張診断情報が含まれていないことを示します。 ext_lengthの値は負であってはなりません。 DiagnosticsRequestデータ構造全体の長さではなく、diagnostic_info_listを構成するデータの長さに注意してください。
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:
diagnostic_info_list：要求されたdiagnostic_info_contentsを含む1つ以上のDiagnosticInfo構造で構成されます。 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.
kind：返される情報のタイプを示す数値コード。 dMFlagsを使用して要求された基本データの場合、このコードはdMFlagセットに対応し、セクション5.1で説明されています。診断拡張機能の場合、このコードは、リクエストのDiagnosticExtensionの「kind」フィールドに設定された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.
diagnostic_info_contents：レポートされる診断情報の値を含むデータ。さまざまな種類の診断情報を取得できます。報告される可能性のある基本診断情報の診断Kind 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」はすべて要求されることを意味します。ただし、同時に、最初と最後のビットを他の目的に使用することはできず、他の特定の診断Kind 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ビット）：ノードが輻輳状態かどうかを表す符号なしバイトを含む単一値要素。 STATUS_INFOの使用例は、輻輳認識ルーティング用です。このシナリオでは、各ピアは輻輳ステータスを定期的に更新する必要があります。分散ハッシュテーブル（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は輻輳を表します。このドキュメントでは、輻輳の特定の方法を提供せず、この決定は各オーバーレイの実装に任せています。オーバーレイ実装の1つの可能なオプションは、過去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.
ROUTING_TABLE_SIZE（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ビット）：MIPSを単位とするノードの処理能力を指定する符号なし64ビット整数を含む単一値の要素。小数値は切り上げられます。
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.
UPSTREAM_BANDWIDTH（64ビット）：ノードの上流ネットワーク帯域幅（プロビジョニングまたは最大、使用不可）をkbit / sの単位で指定する符号なし64ビット整数を含む単一値の要素。小数値は切り上げられます。マルチホームホストの場合、これは応答の送信に使用されるリンクである必要があります。
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.
DOWNSTREAM_BANDWIDTH（64ビット）：単位がkbit / sのノードのダウンストリームネットワーク帯域幅（プロビジョニングまたは最大、使用不可）を指定する符号なし64ビット整数を含む単一値の要素。小数値は切り上げられます。マルチホームホストの場合、これはリクエストの受信元のリンクである必要があります。
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.
SOFTWARE_VERSION：製造、モデル、オペレーティングシステム情報、およびソフトウェアのバージョンを識別するUS-ASCII文字列を含む単一値の要素。一部のネットワークには非常に多数のピアがあり、ピアが他のすべてのピアのソフトウェアを認識している可能性は低いため、この情報は、特定のグループの動作不良ピアの原因が特定のソフトウェアバージョンに関連しているかどうかを判断するのに非常に役立ちます。 。形式はピア定義ですが、推奨される形式は次のとおりです：「ApplicationProductToken（プラットフォーム; OSまたはCPU）VendorProductToken（VendorComment）」、たとえば、「MyReloadApp / 1.0（Unix; Linux x86_64）libreload-java / 0.7。 0（ストーニーフィッシュ株式会社）」。文字列は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ビット）：P2Pアプリケーションが起動した時間（秒単位）を指定する符号なし64ビット整数を含む単一値の要素。
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.
MEMORY_FOOTPRINT（64ビット）：ピアプログラムのメモリフットプリントをキロバイト（1024バイト）で表す符号なし64ビット整数を含む単一値の要素。小数値は切り上げられます。
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.
INSTANCES_STORED：格納されている各種類のインスタンスの数を含む配列要素。配列には、Kind-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_SENT_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ビット）：このピアによって1秒あたりに送信されたバイトの指数加重平均を表す符号なし32ビット整数を含む単一値要素：
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 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.
ここで、sent_presentは最後の計算以降に送信された1秒あたりのバイト数を表し、sent_lastは1秒あたりに送信されたバイト数の最後の計算を表します。 alphaの適切な値は0.8（または実装によって決定される別の値）です。この値は5秒ごと（または実装によって決定される別の期間）ごとに計算されます。最初の期間の値は、単にその期間に送信されたバイトの平均である必要があります。
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ビット）：このピアが受信した1秒あたりのバイトの指数加重平均を表す符号なし32ビット整数を含む単一値の要素：
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は最後の計算以降に受信された1秒あたりのバイト数を表し、rcvd_lastは1秒あたりに受信されたバイト数の最後の計算を表します。 alphaの適切な値は0.8（または実装によって決定される別の値）です。この値は5秒ごと（または実装によって決定される別の期間）ごとに計算されます。最初の期間の値は、単にその期間に受信されたバイトの平均である必要があります。
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層ホップを示します。中間ピアは、このメッセージの次ホップピアへの診断メッセージを受信します。 （注：RELOADでは、中間ピアがメッセージ本文を調べる必要はありません。したがって、ここでは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.
BATTERY_STATUS（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データ構造に追加の情報を要求する診断拡張機能を含めることもできます（MAY）。
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メッセージを作成する場合、送信者はRELOAD [RFC6940]で定義されているようにMessageExtension構造を作成し、typeの値を0x2に、criticalの値をFALSEに設定する必要があります。 extension_contentsの値は、上記で定義されたDiagnosticsRequest構造である必要があります。メッセージは特定のNodeIDまたはResourceIDに送信される場合がありますが、ブロードキャストNodeIDに送信してはなりません（MUST NOT）。
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構造のmessage_codeを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をカバーしていない場合、ピアはRELOADプロトコルからのオーバーレイ指定ルーティングモードに従ってこのリクエストの処理を継続する必要があります。
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_Message_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.
中間ピアは、受信した要求を宛先ピアに転送した後に「Destination Unreachable」情報を含むICMPメッセージを受信すると、エラーコード0x15 "Error_Underlay_Destination_Unreachable"のエラー応答を返さなければなりません（MUST）。
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.
中間ピアは、受信した要求を転送した後、 "Time Exceeded"情報を含むICMPメッセージを受信すると、エラーコード0x16 "Error_Underlay_Time_Exceeded"のエラー応答を返さなければなりません（MUST）。
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"のエラー応答を返さなければなりません（MUST）。すぐ上流のピア情報もイニシエータノードに伝達する必要があります。
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.
ピアは、Viaリストの分析を通じてループを見つけたときに、エラーコード0x19 "Error_Loop_Detected"のエラー応答を返さなければなりません（MUST）。
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_TTL_Hops_Exceeded"のエラー応答を返さなければなりません（MUST）。
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構造のmessage_codeをpath_track_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_Message_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 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.
oメッセージの有効期限が切れていない場合、受信者は次のようにDiagnosticsResponse構造を構築する必要があります。1）転送ヘッダーのTTL値がDiagnosticsResponse構造のhop_counterフィールドにコピーされます（最初のTTLのデフォルト値は100であることに注意してください）オーバーレイ構成が値をオーバーライドしない限りホップします）、および2）レシーバーは現在の時刻の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 宛先ピアは、イニシエーターノードが特定のタイプの診断情報を要求する権限を持っているかどうかを確認し、適切な場合は、DiagnosticsResponse構造にdiagnostic_info_listフィールドを使用して、dMFlagsおよびdiagnostic_extensions（存在する場合）で要求された診断情報を追加します。何らかの情報が返された場合、受信者は応答の長さを計算し、ext_lengthを適切に設定する必要があります。診断情報が返されない場合は、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_Forbidden"のエラー応答を返さなければなりません（MUST）。
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_receivedと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]は通常、パブリックインターネット経由で数十ミリ秒以内の時間を維持でき、理想的な条件下のローカルエリアネットワークで1ミリ秒よりも高い精度を実現できます。ただし、このドキュメントでは、時間解決と同期の選択については明記しておらず、実装に委ねています。
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_counterフィールドをチェックし、オーバーレイホップの観点からの接続品質の統計情報について、宛先ピアへのオーバーレイホップを計算します。
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".
diagnostic-kind：これには、診断の種類IDを示す16進数の属性「kind」があります。この属性の値は、セクション9.2と同じで、少なくとも1つのサブ要素「access-node」があります。
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.
access-node：このエレメントには、NodeIDを示す1つの16進数が含まれており、このNodeIDを持つノードは、同じdiagnostic-kindエレメントの下の診断「kind」にアクセスできます。
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オーバーレイネットワークでは匿名性が非常に重要であり、そのようなフィンガープリントに対する防御はおそらく非常に困難です。このように、匿名性が非常に重要なネットワークでは、多くの利点があるにもかかわらず、診断の実装に問題がある、または望ましくない場合さえあります。このドキュメントはRELOAD拡張であるため、RELOADメッセージヘッダーとルーティング仕様に従います。ベースドキュメント[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は、プロトコルRELOADの下に「RELOAD診断フラグ」レジストリを作成しました。このレジストリのエントリは、セクション4.3.1で説明されているように、取得する診断情報を示す64ビット整数のdMFlagsに含まれる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 |
+-------------------------+----------------------------+----------+
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は、プロトコルRELOADの下に「RELOAD Diagnostic Kind ID」レジストリを作成しました。このレジストリのエントリは、セクションと5.1および5.2で説明されているように、診断要求および応答メッセージで伝送される診断拡張データの種類を示す16ビット整数です。 0x0001から0x003eまでのコードポイントは、「RELOAD Diagnostics Flag」レジストリ内のフラグと一緒に割り当てるように求められます。 「RELOAD Diagnostic Kind 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 |
+----------------------+---------------+---------------+
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].
このドキュメントでは、2つの新しいタイプのメッセージとその応答を紹介しているため、RELOAD [RFC6940]で定義されている "RELOAD Message Codes"レジストリに次の追加が行われています。
+-------------------+------------+----------+
| 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：RELOADメッセージコードの拡張
This document introduces the following new error codes, which have been added to the "RELOAD Error Codes" registry.
このドキュメントでは、「RELOAD Error Codes」レジストリに追加された次の新しいエラーコードを紹介します。
+----------------------------------------+------------+-----------+
| 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：RELOADエラーコード
This document introduces the following new RELOAD extension code:
このドキュメントでは、次の新しいRELOAD拡張コードを紹介します。
+-----------------+------+-----------+
| Extension Name | Code | Reference |
+-----------------+------+-----------+
| Diagnostic_Ping | 0x2 | RFC 7851 |
+-----------------+------+-----------+
Table 4: New RELOAD Extension Code
表4：新しいRELOAD拡張コード
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レジストリにconfig-diagnostics XML名前空間のURIを登録します。このドキュメントで定義されているすべての要素は、この名前空間に属しています。
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.
オーバーレイ構成ファイルには、P2P診断をRELOADの必須の拡張として宣言する次のXML言語を含める必要があります。
<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。、「The IETF XML Registry」、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、「RFCで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、「Network Time Protocol Version 4：Protocol and Algorithms Specification」、RFC 5905、DOI 10.17487 / RFC5905、2010年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、「REsource LOcation And Discovery（RELOAD）Base Protocol」、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、「直接応答ルーティングをサポートするためのリソース再配置および検出（RELOAD）プロトコルの拡張」、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_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]ブライアン、D。、マシューズ、P。、シム、E。、ウィリス、D。、およびS.ドーキンス、「ピアツーピアSIPの概念と用語」、作業中、draft-ietf-p2psip -コンセプト-09、2016年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.
[オーバーレイ障害検出] 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.
[Handling_Churn_in_a_DHT] Rhea、S.、Geels、D.、Roscoe、T.、J。Kubiatowicz、「Handling Churn in DHT」、USENIX Annual Technical Conference、Proceedings、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.、Xiong、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_BYTES_SENTフラグとEWMA_BYTES_RCVDフラグを直接のネイバーに設定できます。ピアは、別のピアのEWMA_BYTES_SENTおよびEWMA_BYTES_RCVDを使用して、メディアリレーとして機能しているかどうかを推測できます。次に、メディアリレーの要求をこのピアに転送しないことを選択できます。同様に、ルーティングテーブルを埋めるためのさまざまな候補の中で、ピアは、UPTIME値が大きく、RTTが小さく、LAST_CONTACT値が小さいピアを優先する場合があります。
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のSTATUS_INFOフラグをリモートの宛先ピアに設定できます。オーバーレイには、輻輳の独自のしきい値定義があります。ピアは、パスに沿った中間ピアのすべてのステータス情報の情報を取得できます。その後、後続のリクエストのために、そのノードへの他のパスを選択できます。
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.
このドキュメントの以前のドラフトバージョンでは、メッセージがオーバーレイを通過するときに各中間ピアによって応答が生成されるアプローチが検討されていました。このアプローチは破棄されました。このアプローチが破棄された理由の1つは、DoSメカニズムが提供され、攻撃者が実際の送信者が攻撃したい偽装した「送信者」からのものであると主張する任意のメッセージを送信できることでした。この1つのメッセージを送信すると、多くのメッセージが生成され、なりすましの「送信者」に送信されます。メッセージパス上の各中間ピアから1つ送信されます。認証メカニズムはこの攻撃のリスクを軽減できますが、単一の要求に対して複数の応答が生成されるため、RELOADプロトコルの要求と応答の性質が根本的に破られました。ルート内のすべてのピアからの応答を持つ1つの要求の方が効率的ですが、セキュリティリスクが大きすぎ、RELOADアーキテクチャからの逸脱であると判断されました。
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.
このドキュメントの最初のドラフトバージョンを提供してくれたZheng Hewenに感謝します。また、電子メールのディスカッションとその貴重なコメントを提供してくれたBruce Lowekamp、Salman Baset、Henning Schulzrinne、Jiang Haifeng、Marc Petit-Hugueninに感謝します。使用シナリオのテキストに貢献してくれたHenry Sinnreichに特に感謝します。診断に関するテキストをこのドキュメントに転送してくれたRELOADプロトコルの作者に感謝します。
Authors' Addresses
著者のアドレス
Haibin Song Huawei
H AI bin Songhuaは
Email: haibin.song@huawei.com
Jiang Xingfeng Huawei
江興風胡Aは
Email: jiangxingfeng@huawei.com
Roni Even Huawei 14 David Hamelech Tel Aviv 64953 Israel
Roni Even Huawei 14 David Hamelech Tel Aviv 64953 Israel
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
Yi Sun ICT
李舜ICT
Email: sunyi@ict.ac.cn