[要約] RFC 7264は、RELOADプロトコルを拡張し、リレーピアルーティングをサポートするためのものです。目的は、ネットワーク内のリソースの位置と発見を効率的に行うことです。
Internet Engineering Task Force (IETF) N. Zong
Request for Comments: 7264 X. Jiang
Category: Standards Track R. Even
ISSN: 2070-1721 Huawei Technologies
Y. Zhang
CoolPad / China Mobile
June 2014
An Extension to the REsource LOcation And Discovery (RELOAD) Protocol to Support Relay Peer Routing
リレーピアルーティングをサポートするためのREsource LOcation and Discovery（RELOAD）プロトコルの拡張
Abstract
概要
This document defines an optional extension to the REsource LOcation And Discovery (RELOAD) protocol to support the relay peer routing mode. RELOAD recommends symmetric recursive routing for routing messages. The new optional extension provides a shorter route for responses, thereby reducing overhead on intermediate peers. This document also describes potential cases where this extension can be used.
このドキュメントでは、リレーピアルーティングモードをサポートするために、REsource LOcation And Discovery（RELOAD）プロトコルのオプションの拡張機能を定義します。 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/rfc7264.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7264で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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 ....................................................3
2. Terminology .....................................................4
3. Overview ........................................................5
3.1. RPR ........................................................5
3.2. Scenarios Where RPR Can Be Used ............................6
3.2.1. Managed or Closed P2P Systems .......................6
3.2.2. Using Bootstrap Nodes as Relay Peers ................7
3.2.3. Wireless Scenarios ..................................7
4. Relationship between SRR and RPR ................................7
4.1. How RPR Works ..............................................7
4.2. How SRR and RPR Work Together ..............................7
5. RPR Extensions to RELOAD ........................................8
5.1. Basic Requirements .........................................8
5.2. Modification to RELOAD Message Structure ...................8
5.2.1. Extensive Routing Mode ..............................8
5.3. Creating a Request .........................................9
5.3.1. Creating a Request for RPR ..........................9
5.4. Request and Response Processing ............................9
5.4.1. Destination Peer: Receiving a Request and
Sending a Response ..................................9
5.4.2. Sending Peer: Receiving a Response .................10
5.4.3. Relay Peer Processing ..............................10
6. Overlay Configuration Extension ................................10
7. Discovery of Relay Peers .......................................11
8. Security Considerations ........................................11
9. IANA Considerations ............................................11
9.1. A New RELOAD Forwarding Option ............................11
10. Acknowledgments ...............................................11
11. References ....................................................12
11.1. Normative References .....................................12
11.2. Informative References ...................................12
Appendix A. Optional Methods to Investigate Peer Connectivity .....13
Appendix B. Comparison of Cost of SRR and RPR .....................14
B.1. Closed or Managed Networks .................................14
B.2. Open Networks ..............................................15
The REsource LOcation And Discovery (RELOAD) protocol [RFC6940] recommends symmetric recursive routing (SRR) for routing messages and describes the extensions that would be required to support additional routing algorithms. In addition to SRR, two other routing options -- direct response routing (DRR) and relay peer routing (RPR) -- are also discussed in Appendix A of [RFC6940]. As we show in Section 3, RPR is advantageous over SRR in some scenarios in that RPR can reduce load (CPU and link bandwidth) on intermediate peers. RPR works better in a network where relay peers are provisioned in advance so that relay peers are publicly reachable in the P2P system. In other scenarios, using a combination of RPR and SRR together is more likely to provide benefits than if SRR is used alone.
REsource LOcation And Discovery（RELOAD）プロトコル[RFC6940]は、メッセージのルーティングに対称再帰ルーティング（SRR）を推奨し、追加のルーティングアルゴリズムをサポートするために必要な拡張機能について説明しています。 SRRに加えて、ダイレクトレスポンスルーティング（DRR）とリレーピアルーティング（RPR）の2つのルーティングオプションについても、[RFC6940]の付録Aで説明しています。セクション3で示すように、RPRは中間ピアの負荷（CPUとリンク帯域幅）を削減できるという点で、一部のシナリオではSRRよりもRPRの方が有利です。 RPRは、リレーピアが事前にプロビジョニングされているネットワークでより効果的に機能するため、P2Pシステムでリレーピアにパブリックに到達できます。他のシナリオでは、RPRとSRRを組み合わせて使用すると、SRRを単独で使用する場合よりもメリットが得られる可能性が高くなります。
Note that in this document we focus on the RPR mode and its extensions to RELOAD to produce a standalone solution. Please refer to [RFC7263] for details on the DRR mode.
このドキュメントでは、RPRモードとスタンドアロンソリューションを作成するためのRELOADの拡張に焦点を当てていることに注意してください。 DRRモードの詳細については、[RFC7263]を参照してください。
We first discuss the problem statement in Section 3. How to combine RPR and SRR is presented in Section 4. An extension to RELOAD to support RPR is defined in Section 5. Discovery of relay peers is introduced in Section 7. Some optional methods to check peer connectivity are introduced in Appendix A. In Appendix B, we give a comparison of the cost of SRR and RPR in both managed and open networks.
最初にセクション3で問題ステートメントについて説明します。RPRとSRRを組み合わせる方法はセクション4で説明されています。RPRをサポートするRELOADの拡張はセクション5で定義されています。リレーピアの検出はセクション7で導入されています。ピア接続は付録Aで紹介されています。付録Bでは、管理対象ネットワークとオープンネットワークの両方でのSRRとRPRのコストを比較しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
We use terminology and definitions from the base RELOAD specification [RFC6940] extensively in this document. We also use terms defined in the NAT behavior discovery document [RFC5780]. Other terms used in this document are defined inline when used and are also defined below for reference.
このドキュメントでは、基本的なRELOAD仕様[RFC6940]の用語と定義を広く使用しています。また、NAT動作検出ドキュメント[RFC5780]で定義されている用語も使用します。このドキュメントで使用されている他の用語は、使用時にインラインで定義され、参照用に以下でも定義されています。
Publicly Reachable: A peer is publicly reachable if it can receive unsolicited messages from any other peer in the same overlay. Note: "Publicly" does not mean that the peers must be on the public Internet, because the RELOAD protocol may be used in a closed network.
パブリックに到達可能：ピアは、同じオーバーレイ内の他のピアからの一方的なメッセージを受信できる場合、パブリックに到達可能です。注：「公的に」とは、RELOADプロトコルが閉じたネットワークで使用される場合があるため、ピアが公衆インターネット上にある必要があることを意味しません。
Relay Peer: A relay peer is a type of publicly reachable peer that can receive unsolicited messages from all other peers in the overlay and forward the responses from destination peers towards the sender of the request.
リレーピア：リレーピアは、オーバーレイで他のすべてのピアから非送信請求メッセージを受信し、宛先ピアからの応答を要求の送信者に転送できる一種の公的に到達可能なピアです。
Relay Peer Routing (RPR): "RPR" refers to a routing mode in which responses to Peer-to-Peer SIP (P2PSIP) requests are sent by the destination peer to a relay peer transport address that will forward the responses towards the sending peer. For simplicity, the abbreviation "RPR" is used in the rest of this document.
リレーピアルーティング（RPR）：「RPR」は、ピアツーピアSIP（P2PSIP）要求への応答が、送信側ピアに向けて応答を転送するリレーピアトランスポートアドレスに宛先ピアから送信されるルーティングモードを指します。 。簡単にするために、このドキュメントでは以降、略語「RPR」を使用します。
Symmetric Recursive Routing (SRR): "SRR" refers to a routing mode in which responses follow the reverse path of the request to get to the sending peer. For simplicity, the abbreviation "SRR" is used in the rest of this document.
Symmetric Recursive Routing（SRR）： "SRR"は、応答が送信ピアに到達するために要求の逆のパスをたどるルーティングモードを指します。簡単にするために、このドキュメントの残りの部分では略語「SRR」を使用しています。
Direct Response Routing (DRR): "DRR" refers to a routing mode in which responses to P2PSIP requests are returned to the sending peer directly from the destination peer based on the sending peer's own local transport address(es). For simplicity, the abbreviation "DRR" is used in the rest of this document.
ダイレクトレスポンスルーティング（DRR）：「DRR」は、P2PSIP要求への応答が送信ピアの独自のローカルトランスポートアドレスに基づいて宛先ピアから直接送信ピアに返されるルーティングモードを指します。簡単にするために、この文書の残りでは略語「DRR」が使用されています。
RELOAD is expected to work under a great number of application scenarios. The situations where RELOAD is to be deployed differ greatly. For instance, some deployments are global, such as a Skype-like system intended to provide public service, while others run in small-scale closed networks. SRR works in any situation, but RPR may work better in some specific scenarios.
RELOADは、多数のアプリケーションシナリオで機能することが期待されています。 RELOADがデプロイされる状況は大きく異なります。たとえば、パブリックサービスの提供を目的としたSkypeのようなシステムなど、グローバルな展開もあれば、小規模なクローズドネットワークで実行される展開もあります。 SRRはどのような状況でも機能しますが、RPRは特定のシナリオでより適切に機能する場合があります。
RELOAD is a simple request-response protocol. After sending a request, a peer waits for a response from a destination peer. There are several ways for the destination peer to send a response back to the source peer. In this section, we will provide detailed information on RPR. Note that the same types of illustrative settings can be found in Appendix B.1 of [RFC7263].
RELOADは、単純な要求/応答プロトコルです。要求を送信した後、ピアは宛先ピアからの応答を待ちます。宛先ピアが応答をソースピアに返信する方法はいくつかあります。このセクションでは、RPRの詳細情報を提供します。 [RFC7263]の付録B.1にも、同じタイプの例示的な設定があります。
If peer A knows it is behind a NAT or NATs and knows one or more relay peers with whom they have had prior connections, peer A can try RPR. Assume that peer A is associated with relay peer R. When sending the request, peer A includes information describing peer R's transport address in the request. When peer X receives the request, peer X sends the response to peer R, which forwards it directly to peer A on the existing connection. Figure 1 illustrates RPR. Note that RPR also allows a shorter route for responses compared to SRR; this means less overhead on intermediate peers. Establishing a connection to the relay with Transport Layer Security (TLS) requires multiple round trips. Please refer to Appendix B for a cost comparison between SRR and RPR.
ピアAがNATの背後にあること、および以前に接続していた1つ以上のリレーピアを知っている場合、ピアAはRPRを試すことができます。ピアAがリレーピアRに関連付けられていると仮定します。要求を送信するとき、ピアAはピアRのトランスポートアドレスを説明する情報を要求に含めます。ピアXが要求を受信すると、ピアXは応答をピアRに送信し、ピアRはそれを既存の接続のピアAに直接転送します。図1にRPRを示します。 RPRは、SRRと比較して応答のルートを短くすることもできます。これは、中間ピアでのオーバーヘッドが少ないことを意味します。 Transport Layer Security（TLS）を使用してリレーへの接続を確立するには、複数のラウンドトリップが必要です。 SRRとRPRのコスト比較については、付録Bを参照してください。
A B C D X R
| Request | | | | |
|----------->| | | | |
| | Request | | | |
| |----------->| | | |
| | | Request | | |
| | |----------->| | |
| | | | Request | |
| | | |----------->| |
| | | | | Response |
| | | | |---------->|
| | | | Response | |
|<-----------+------------+------------+------------+-----------|
| | | | | |
Figure 1: RPR Mode
図1：RPRモード
This technique relies on the relative population of peers such as peer A that require relay peers, and peers such as peer R that are capable of serving as relay peers. It also requires a mechanism to enable peers to know which peers can be used as their relays. This mechanism may be based on configuration -- for example, as part of the overlay configuration, an initial list of relay peers can be supplied. Another option is a response message in which the responding peer can announce that it can serve as a relay peer.
この手法は、リレーピアを必要とするピアAなどのピアと、リレーピアとして機能するピアRなどのピアの相対的な数に依存しています。また、ピアがリレーとして使用できるピアを知ることができるメカニズムも必要です。このメカニズムは、構成に基づいている場合があります。たとえば、オーバーレイ構成の一部として、リレーピアの初期リストを提供できます。別のオプションは、応答ピアがリレーピアとして機能できることを通知できる応答メッセージです。
In this section, we will list several scenarios where using RPR would improve performance.
このセクションでは、RPRを使用するとパフォーマンスが向上するいくつかのシナリオを示します。
As described in Section 3.2.1 of [RFC7263], many P2P systems run in a closed or managed environment so that network administrators can better manage their system. For example, the network administrator can deploy several relay peers that are publicly reachable in the system and indicate their presence in the configuration file. After learning where these relay peers are, peers behind NATs can use RPR with help from these relay peers. Peers MUST also support SRR in case RPR fails.
[RFC7263]のセクション3.2.1で説明されているように、多くのP2Pシステムは閉じた環境または管理された環境で実行されるため、ネットワーク管理者はシステムをより適切に管理できます。たとえば、ネットワーク管理者は、システム内でパブリックに到達可能ないくつかのリレーピアを展開し、構成ファイルでその存在を示すことができます。これらのリレーピアの場所を学習した後、NATの背後にあるピアは、これらのリレーピアの助けを借りてRPRを使用できます。ピアは、RPRが失敗した場合のSRRもサポートする必要があります。
Another usage is to install relay peers on the managed network boundary, allowing external peers to send responses to peers inside the managed network.
もう1つの使用法は、管理対象ネットワーク境界にリレーピアをインストールして、外部ピアが管理対象ネットワーク内のピアに応答を送信できるようにすることです。
Bootstrap nodes are typically publicly reachable in a RELOAD architecture. As a result, one possible scenario would be to use the bootstrap nodes as relay peers for use with RPR. A relay peer SHOULD be publicly accessible and maintain a direct connection with its client. As such, bootstrap nodes are well suited to play the role of relay peers.
ブートストラップノードは、通常RELOADアーキテクチャでパブリックに到達可能です。その結果、1つの可能なシナリオは、RPRで使用するリレーピアとしてブートストラップノードを使用することです。リレーピアは、パブリックにアクセス可能であり、クライアントとの直接接続を維持する必要があります（SHOULD）。したがって、ブートストラップノードは、リレーピアの役割を果たすのに適しています。
In some mobile deployments, using RPR may help reduce radio battery usage and bandwidth by the intermediate peers. The service provider may recommend using RPR based on his knowledge of the topology.
一部のモバイル展開では、RPRを使用すると、中間ピアによる無線バッテリーの使用量と帯域幅を削減できる場合があります。サービスプロバイダーは、トポロジに関する知識に基づいてRPRの使用を推奨する場合があります。
Peers using RPR MUST maintain a connection with their relay peer(s). This can be done in the same way as establishing a neighbor connection between peers using the Attach method [RFC6940].
RPRを使用するピアは、リレーピアとの接続を維持する必要があります。これは、Attachメソッド[RFC6940]を使用してピア間のネイバー接続を確立するのと同じ方法で実行できます。
A requirement for RPR is that the source peer convey its relay peer's (or peers') transport address(es) in the request so the destination peer knows where the relay peers are and will send the response to a relay peer first. The request MUST also include the requesting peer's Node-ID or IP address, which enables the relay peer to route the response back to the right peer.
RPRの要件は、送信元ピアが要求でリレーピア（またはピア）のトランスポートアドレスを伝達することです。これにより、宛先ピアはリレーピアの場所を認識し、最初にリレーピアに応答を送信します。要求には、要求側のピアのノードIDまたはIPアドレスも含める必要があります。これにより、リレーピアが応答を正しいピアにルーティングできるようになります。
Note that being a relay peer does not require that the relay peer have more functionality than an ordinary peer. Relay peers comply with the same procedure as an ordinary peer to forward messages. The only difference is that there may be a larger traffic burden on relay peers. Relay peers can decide whether to accept a new connection based on their current burden.
リレーピアであるために、リレーピアが通常のピアよりも多くの機能を持っている必要はありません。リレーピアは、通常のピアと同じ手順に従ってメッセージを転送します。唯一の違いは、リレーピアのトラフィック負荷が大きくなる可能性があることです。リレーピアは、現在の負担に基づいて、新しい接続を受け入れるかどうかを決定できます。
RPR is not intended to replace SRR. It is better to use these two modes together to adapt to each peer's specific situation. Note that the informative suggestions for how to transition between SRR and RPR are the same as those for DRR. Please refer to Section 4.2 of [RFC7263] for more details. If a relay peer is provided by the service provider, peers SHOULD prefer RPR over SRR. However, RPR SHOULD NOT be used in the open Internet or if the administrator does not feel he has enough information about the overlay network topology. A new overlay configuration element specifying the usage of RPR is defined in Section 6.
RPRはSRRを置き換えるものではありません。これら2つのモードを一緒に使用して、各ピアの特定の状況に適応することをお勧めします。 SRRとRPRの間の移行方法に関する有益な提案は、DRRの場合と同じであることに注意してください。詳細については、[RFC7263]のセクション4.2を参照してください。リレーピアがサービスプロバイダーによって提供される場合、ピアはSRRよりもRPRを優先する必要があります。ただし、オープンインターネットではRPRを使用しないでください。または、管理者がオーバーレイネットワークトポロジに関する十分な情報を持っていると管理者が感じていない場合は使用しないでください。 RPRの使用法を指定する新しいオーバーレイ構成要素は、セクション6で定義されています。
Adding support for RPR requires extensions to the current RELOAD protocol. In this section, we define the required extensions, including extensions to message structure and message processing.
RPRのサポートを追加するには、現在のRELOADプロトコルを拡張する必要があります。このセクションでは、メッセージ構造やメッセージ処理への拡張など、必要な拡張を定義します。
All peers MUST be able to process requests for routing in SRR and MAY support RPR routing requests.
すべてのピアは、SRRでルーティングの要求を処理できなければならず、RPRルーティング要求をサポートしてもよい（MAY）。
RELOAD provides an extensible framework to accommodate future extensions. In this section, we define an RPR routing option for the extensive routing mode specified in [RFC7263]. The state-keeping flag [RFC7263] is needed to support the RPR mode.
RELOADは、将来の拡張に対応するための拡張可能なフレームワークを提供します。このセクションでは、[RFC7263]で指定されている拡張ルーティングモードのRPRルーティングオプションを定義します。 RPRモードをサポートするには、状態維持フラグ[RFC7263]が必要です。
The new RouteMode value for RPR is defined below for the ExtensiveRoutingModeOption structure:
RPRの新しいRouteMode値は、ExtensiveRoutingModeOption構造体に対して以下で定義されています。
enum {(0),DRR(1),RPR(2),(255)} RouteMode;
struct {
RouteMode routemode;
OverlayLinkType transport;
IpAddressPort ipaddressport;
Destination destinations<1..2^8-1>;
} ExtensiveRoutingModeOption;
Note that the DRR value in RouteMode is defined in [RFC7263].
RouteModeのDRR値は[RFC7263]で定義されていることに注意してください。
RouteMode: refers to which type of routing mode is indicated to the destination peer.
RouteMode：宛先ピアに示されているルーティングモードのタイプを参照します。
OverlayLinkType: refers to the transport type that is used to deliver responses from the destination peer to the relay peer.
OverlayLinkType：宛先ピアからリレーピアに応答を配信するために使用されるトランスポートタイプを指します。
IpAddressPort: refers to the transport address that the destination peer should use for sending responses. This will be a relay peer address for RPR.
IpAddressPort：宛先ピアが応答の送信に使用する必要があるトランスポートアドレスを参照します。これはRPRのリレーピアアドレスになります。
Destination: refers to the relay peer itself. If the routing mode is RPR, then the destination contains two items: the relay peer's Node-ID and the sending peer's Node-ID.
宛先：リレーピア自体を指します。ルーティングモードがRPRの場合、宛先には2つの項目が含まれます。リレーピアのノードIDと送信ピアのノードIDです。
When using RPR for a transaction, the sending peer MUST set the IGNORE-STATE-KEEPING flag in the ForwardingHeader. Additionally, the peer MUST construct and include a ForwardingOption structure in the ForwardingHeader. When constructing the ForwardingOption structure, the fields MUST be set as follows:
トランザクションにRPRを使用する場合、送信ピアはForwardingHeaderにIGNORE-STATE-KEEPINGフラグを設定する必要があります。さらに、ピアはForwardingHeaderにForwardingOption構造を構築して含める必要があります。 ForwardingOption構造を構築する場合、フィールドは次のように設定する必要があります。
1) The type MUST be set to extensive_routing_mode.
1）タイプはexpanded_routing_modeに設定する必要があります。
2) The ExtensiveRoutingModeOption structure MUST be used for the option field within the ForwardingOption structure. The fields MUST be defined as follows:
2）ExtensiveRoutingModeOption構造体は、ForwardingOption構造体内のオプションフィールドに使用する必要があります。フィールドは次のように定義する必要があります。
2.1) routemode set to 0x02 (RPR).
2.1）routemodeが0x02（RPR）に設定されています。
2.2) transport set as appropriate for the relay peer.
2.2）中継ピアに適切なトランスポートセット。
2.3) ipaddressport set to the transport address of the relay peer through which the sender wishes the message relayed.
2.3）ipaddressportは、送信者がメッセージのリレーを希望するリレーピアのトランスポートアドレスに設定されます。
2.4) The destination structure MUST contain two values. The first MUST be defined as type "node" and set with the values for the relay peer. The second MUST be defined as type "node" and set with the sending peer's own values.
2.4）宛先構造には2つの値が含まれている必要があります。最初はタイプ「ノード」として定義され、リレーピアの値を設定する必要があります。 2番目はタイプ「ノード」として定義されなければならず、送信ピア自身の値で設定されなければなりません。
This section gives normative text for message processing after RPR is introduced. Here, we only describe the additional procedures for supporting RPR. Please refer to [RFC6940] for RELOAD base procedures.
このセクションでは、RPRが導入された後のメッセージ処理の規範的なテキストを示します。ここでは、RPRをサポートするための追加手順についてのみ説明します。 RELOADの基本手順については、[RFC6940]を参照してください。
When the destination peer receives a request, it will check the options in the forwarding header. If the destination peer cannot understand the extensive_routing_mode option in the request, it MUST attempt to use SRR to return an "Error_Unknown_Extension" response (defined in Sections 6.3.3.1 and 14.9 of [RFC6940]) to the sending peer.
宛先ピアがリクエストを受信すると、転送ヘッダーのオプションをチェックします。宛先ピアがリクエストのexpanded_routing_modeオプションを理解できない場合、SRRを使用して "Error_Unknown_Extension"応答（[RFC6940]のセクション6.3.3.1および14.9で定義）を送信ピアに返す必要があります。
If the routing mode is RPR, the destination peer MUST construct a destination_list for the response with two entries as defined in [RFC6940]. The first entry MUST be set to the relay peer's Node-ID from the option in the request, and the second entry MUST be the sending peer's Node-ID from the option in the request.
ルーティングモードがRPRの場合、宛先ピアは、[RFC6940]で定義されている2つのエントリを持つ応答のdestination_listを構築する必要があります。最初のエントリは、リクエストのオプションからのリレーピアのノードIDに設定する必要があり、2番目のエントリは、リクエストのオプションからの送信ピアのノードIDである必要があります。
In the event that the routing mode is set to RPR and there are not exactly two destinations, the destination peer MUST try to send an "Error_Unknown_Extension" response (defined in Sections 6.3.3.1 and 14.9 of [RFC6940]) to the sending peer using SRR.
ルーティングモードがRPRに設定されていて、宛先が2つではない場合、宛先ピアは、「Error_Unknown_Extension」応答（[RFC6940]のセクション6.3.3.1および14.9で定義）を使用して、送信ピアに送信を試行する必要があります。 SRR。
After the peer constructs the destination_list for the response, it sends the response to the transport address, which is indicated in the ipaddressport field in the option using the specific transport mode in the ForwardingOption. If the destination peer receives a retransmit with SRR preference on the message it is trying to respond to now, the responding peer SHOULD abort the RPR response and use SRR.
ピアは、応答のdestination_listを作成した後、ForwardingOptionの特定のトランスポートモードを使用して、オプションのipaddressportフィールドに示されているトランスポートアドレスに応答を送信します。宛先ピアが、現在応答しようとしているメッセージでSRR優先度付きの再送信を受信した場合、応答ピアはRPR応答を中止し、SRRを使用する必要があります（SHOULD）。
Upon receiving a response, the peer follows the rules in [RFC6940]. If the sender used RPR and did not get a response until the timeout, it MAY resend the message using either RPR (but with a different relay peer, if available) or SRR.
応答を受信すると、ピアは[RFC6940]のルールに従います。送信者がRPRを使用し、タイムアウトになるまで応答が得られなかった場合、RPR（使用可能な場合は別のリレーピアを使用）またはSRRのいずれかを使用してメッセージを再送信できます（MAY）。
Relay peers are designed to forward responses to peers who are not publicly reachable. For the routing of the response, this document still uses the destination_list. The only difference from SRR is that the destination_list is not the reverse of the via_list. Instead, it is constructed from the forwarding option as described below.
リレーピアは、パブリックに到達できないピアに応答を転送するように設計されています。応答のルーティングのために、このドキュメントはまだdestination_listを使用しています。 SRRとの唯一の違いは、destination_listがvia_listの逆ではないことです。代わりに、以下で説明するように、転送オプションから構築されます。
When a relay peer receives a response, it MUST follow the rules in [RFC6940]. It receives the response, validates the message, readjusts the destination_list, and forwards the response to the next hop in the destination_list based on the connection table. There is no added requirement for the relay peer.
リレーピアが応答を受信するとき、それは[RFC6940]のルールに従う必要があります。応答を受信し、メッセージを検証して、destination_listを再調整し、接続テーブルに基づいて、destination_listの次のホップに応答を転送します。リレーピアの追加要件はありません。
This document uses the new RELOAD overlay configuration element, "route-mode", inside each "configuration" element, as defined in Section 6 of [RFC7263]. The route mode MUST be "RPR".
このドキュメントでは、[RFC7263]のセクション6で定義されているように、各「構成」要素内で新しいRELOADオーバーレイ構成要素「route-mode」を使用します。ルートモードは「RPR」である必要があります。
There are several ways to distribute information about relay peers throughout the overlay. P2P network providers can deploy some relay peers and advertise them in the configuration file. With the configuration file at hand, peers can get relay peers to try RPR. Another way is to consider the relay peer as a service; some service advertisement and discovery mechanism can then also be used for discovering relay peers -- for example, using the same mechanism as that used in Traversal Using Relays around NAT (TURN) server discovery as discussed in [RFC6940]. Another option is to let a peer advertise its capability to be a relay in the response to an Attach or Join [RFC6940].
オーバーレイ全体にリレーピアに関する情報を配信する方法はいくつかあります。 P2Pネットワークプロバイダーは、いくつかのリレーピアを展開し、構成ファイルでそれらをアドバタイズできます。手元の構成ファイルを使用して、ピアはリレーピアを取得してRPRを試すことができます。別の方法は、リレーピアをサービスと見なすことです。 [RFC6940]で説明されているように、NAT（TURN）サーバーディスカバリを使用したリレーのトラバーサルで使用されているものと同じメカニズムを使用するなど、一部のサービスアドバタイズメントと検出メカニズムもリレーピアの検出に使用できます。別のオプションは、接続または結合への応答でリレーになる機能をピアに通知することです[RFC6940]。
The normative security recommendations of Section 13 of [RFC6940] are applicable to this document. As a routing alternative, the security part of RPR conforms to Section 13.6 of [RFC6940], which describes routing security. RPR behaves like a DRR requesting node towards the destination node. The RPR relay peer is not necessarily an arbitrary node -- for example, a managed network, a bootstrap node, or a configured relay peer; it should be a trusted node, because a trusted node will be less of a risk, as outlined in Section 13 of [RFC6940].
[RFC6940]のセクション13の規範的なセキュリティ推奨事項がこのドキュメントに適用されます。ルーティングの代替手段として、RPRのセキュリティ部分は、ルーティングのセキュリティについて説明する[RFC6940]のセクション13.6に準拠しています。 RPRは、宛先ノードに対してDRR要求ノードのように動作します。 RPRリレーピアは必ずしも任意のノードではありません。たとえば、管理対象ネットワーク、ブートストラップノード、または構成済みのリレーピアなどです。 [RFC6940]のセクション13で概説されているように、信頼されたノードはリスクが少ないため、信頼されたノードである必要があります。
In order to address possible DoS attacks, the relay peer SHOULD also limit the number of maximum connections; this is required in order to also reduce load on the relay peer, as explained in Section 4.1.
可能なDoS攻撃に対処するために、リレーピアは最大接続数も制限する必要があります。これは、セクション4.1で説明されているように、リレーピアの負荷を軽減するためにも必要です。
A new RELOAD Forwarding Option type has been added to the "RELOAD Forwarding Option Registry" defined in [RFC6940].
[RFC6940]で定義されている「RELOAD転送オプションレジストリ」に、新しいRELOAD転送オプションタイプが追加されました。
Code: 2 Forwarding Option: extensive_routing_mode
コード：2転送オプション：expanded_routing_mode
David Bryan helped extensively with this document and helped provide some of the text, analysis, and ideas contained here. The authors would like to thank Ted Hardie, Narayanan Vidya, Dondeti Lakshminath, Bruce Lowekamp, Stephane Bryant, Marc Petit-Huguenin, and Carlos Jesus Bernardos Cano for their constructive comments.
David Bryanは、このドキュメントを広範囲にわたって支援し、ここに含まれるテキスト、分析、およびアイデアの一部を提供するのを支援しました。著者は、彼らの建設的なコメントをしてくれたテッド・ハーディ、ナラヤナン・ビディア、ドンデティ・ラクシュミナート、ブルース・ローエカンプ、ステファン・ブライアント、マーク・プチ・フゲニン、カルロス・イエス・ベルナルドス・カノに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC6940] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", RFC 6940, January 2014.
[RFC6940] Jennings、C.、Lowekamp、B.、Rescorla、E.、Baset、S。、およびH. Schulzrinne、「REsource LOcation And Discovery（RELOAD）Base Protocol」、RFC 6940、2014年1月。
[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, June 2014.
[RFC7263] Zong、N.、Jiang、X.、Even、R。、およびY. Zhang、「直接応答ルーティングをサポートするためのリソース再配置および検出（RELOAD）プロトコルの拡張」、RFC 7263、2014年6月。
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[RFC3424] Daigle、L。およびIAB、「ネットワークアドレス変換を介したUNilateral Self-Address Fixing（UNSAF）に関するIABの考慮事項」、RFC 3424、2002年11月。
[RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)", RFC 5780, May 2010.
[RFC5780] MacDonald、D。およびB. Lowekamp、「NAT用のセッショントラバーサルユーティリティを使用したNAT動作検出（STUN）」、RFC 5780、2010年5月。
This section is for informational purposes only and provides some mechanisms that can be used when the configuration information does not specify if RPR can be used. It summarizes some methods that can be used by a peer to determine its own network location compared with NAT. These methods may help a peer to decide which routing mode it may wish to try. Note that there is no foolproof way to determine whether a peer is publicly reachable, other than via out-of-band mechanisms. This document addresses UNilateral Self-Address Fixing (UNSAF) [RFC3424] considerations by specifying a fallback plan to SRR [RFC6940]. SRR is not an UNSAF mechanism. This document does not define any new UNSAF mechanisms.
このセクションは情報提供のみを目的としており、RPRを使用できるかどうか構成情報で指定されていない場合に使用できるいくつかのメカニズムを提供します。 NATと比較して、ピアが独自のネットワークロケーションを決定するために使用できるいくつかの方法を要約しています。これらのメソッドは、ピアがどのルーティングモードを試行するかを決定するのに役立ちます。アウトオブバンドメカニズムを介して以外に、ピアがパブリックに到達可能かどうかを判断するための確実な方法はないことに注意してください。このドキュメントは、SRR [RFC6940]へのフォールバック計画を指定することにより、UNilateral Self-Address Fixing（UNSAF）[RFC3424]の考慮事項に対処します。 SRRはUNSAFメカニズムではありません。このドキュメントでは、新しいUNSAFメカニズムを定義していません。
For RPR to function correctly, a peer may attempt to determine whether it is publicly reachable. If it is not, RPR may be chosen to route the response with help from relay peers, or the peers should fall back to SRR. NATs and firewalls are two major contributors to preventing RPR from functioning properly. There are a number of techniques by which a peer can get its reflexive address on the public side of the NAT. After obtaining the reflexive address, a peer can perform further tests to learn whether the reflexive address is publicly reachable. If the address appears to be publicly reachable, the peer to which the address belongs can be a candidate to serve as a relay peer. Peers that are not publicly reachable may still use RPR to shorten the response path, with help from relay peers.
RPRが正しく機能するために、ピアはパブリックに到達可能かどうかを判断しようとする場合があります。そうでない場合は、RPRを選択して、リレーピアの助けを借りて応答をルーティングするか、ピアをSRRにフォールバックする必要があります。 NATとファイアウォールは、RPRが適切に機能しない原因の2つです。ピアがNATのパブリック側でその再帰アドレスを取得できるようにするいくつかの手法があります。再帰アドレスを取得した後、ピアはさらにテストを実行して、再帰アドレスがパブリックに到達可能かどうかを確認できます。アドレスがパブリックに到達可能であると思われる場合、そのアドレスが属するピアは、リレーピアとして機能する候補になります。パブリックに到達できないピアでも、RPRを使用して、リレーピアの助けを得て応答パスを短縮できます。
Some conditions that are unique in P2PSIP architecture could be leveraged to facilitate the tests. In a P2P overlay network, each peer has only a partial view of the whole network and knows of a few peers in the overlay. P2P routing algorithms can easily deliver a request from a sending peer to a peer with whom the sending peer has no direct connection. This makes it easy for a peer to ask other peers to send unsolicited messages back to the requester.
P2PSIPアーキテクチャーに固有のいくつかの条件を利用して、テストを容易にすることができます。 P2Pオーバーレイネットワークでは、各ピアはネットワーク全体の一部のみを表示し、オーバーレイ内のいくつかのピアを認識しています。 P2Pルーティングアルゴリズムは、送信ピアからの直接接続を持たないピアに、送信ピアからの要求を簡単に配信できます。これにより、ピアが他のピアに要求していないメッセージをリクエスタに送信するように依頼することが簡単になります。
The approaches for a peer to get the addresses needed for further tests, as well as the test for learning whether a peer may be publicly reachable, are the same as those for DRR. Please refer to Appendix A of [RFC7263] for more details.
ピアが以降のテストに必要なアドレスを取得するためのアプローチ、およびピアがパブリックに到達可能かどうかを学習するためのテストは、DRRのアプローチと同じです。詳細については、[RFC7263]の付録Aを参照してください。
The major advantage of using RPR is that it reduces the number of intermediate peers traversed by the response. This reduces the load, such as processing and communication bandwidth, on those peers' resources.
RPRを使用する主な利点は、応答が通過する中間ピアの数が減ることです。これにより、それらのピアのリソースに対する処理や通信帯域幅などの負荷が軽減されます。
As described in Section 3, many P2P systems run in a closed or managed environment (e.g., carrier networks), so network administrators would know that they could safely use RPR.
セクション3で説明したように、多くのP2Pシステムは閉じた環境または管理された環境（キャリアネットワークなど）で実行されるため、ネットワーク管理者はRPRを安全に使用できることを知っています。
The number of hops for a response in SRR and in RPR are listed in the following table. Note that the same types of illustrative settings can be found in Appendix B.1 of [RFC7263].
SRRおよびRPRの応答のホップ数を次の表に示します。 [RFC7263]の付録B.1にも、同じタイプの例示的な設定があります。
Mode | Success | No. of Hops | No. of Msgs
------------------------------------------------
SRR | Yes | log(N) | log(N)
RPR | Yes | 2 | 2
RPR (DTLS) | Yes | 2 | 7+2
Table 1: Comparison of SRR and RPR in Closed Networks
表1：閉じたネットワークでのSRRとRPRの比較
From the above comparison, it is clear that:
上記の比較から、次のことが明らかです。
1) In most cases when the number of peers (N) > 4 (2^2), RPR uses fewer hops than SRR. Using a shorter route means less overhead and resource usage on intermediate peers, which is an important consideration for adopting RPR in the cases where such resources as CPU and bandwidth are limited, e.g., the case of mobile, wireless networks.
1）ピアの数（N）> 4（2 ^ 2）のほとんどの場合、RPRはSRRよりも少ないホップを使用します。短いルートを使用すると、中間ピアでのオーバーヘッドとリソース使用量が少なくなります。これは、CPUや帯域幅などのリソースが制限されている場合（モバイルワイヤレスネットワークなど）にRPRを採用する場合の重要な考慮事項です。
2) In the cases when N > 512 (2^9), RPR also uses fewer messages than SRR.
2）N> 512（2 ^ 9）の場合、RPRはSRRよりも少ないメッセージを使用します。
3) In the cases when N < 512, RPR uses more messages than SRR (but still uses fewer hops than SRR), so the consideration of whether to use RPR or SRR depends on other factors such as using less resources (bandwidth and processing) from the intermediate peers. Section 4 provides use cases where RPR has a better chance of working or where the considerations of intermediary resources are important.
3）N <512の場合、RPRはSRRよりも多くのメッセージを使用します（ただし、SRRよりも少ないホップを使用します）。したがって、RPRまたはSRRを使用するかどうかの検討は、より少ないリソース（帯域幅と処理）の使用などの他の要因に依存します。中間ピアから。セクション4では、RPRが機能する可能性が高い場合、または中間リソースの考慮が重要な場合の使用例を示します。
In open networks (e.g., the Internet) where RPR is not guaranteed to work, RPR can fall back to SRR if it fails after trial, as described in Section 4.2. Based on the same settings as those listed in Appendix B.1, the number of hops, as well as the number of messages for a response in SRR and RPR, are listed in the following table:
RPRの動作が保証されていないオープンネットワーク（インターネットなど）では、セクション4.2で説明されているように、RPRが試行後に失敗した場合、RPRはSRRにフォールバックできます。付録B.1に記載されているものと同じ設定に基づいて、ホップ数、およびSRRとRPRの応答のメッセージ数を次の表に示します。
Mode | Success | No. of Hops | No. of Msgs
----------------------------------------------------------------
SRR | Yes | log(N) | log(N)
RPR | Yes | 2 | 2
| Fail & fall back to SRR | 2+log(N) | 2+log(N)
RPR (DTLS) | Yes | 2 | 7+2
| Fail & fall back to SRR | 2+log(N) | 9+log(N)
Table 2: Comparison of SRR and RPR in Open Networks
表2：オープンネットワークにおけるSRRとRPRの比較
From the above comparison, it can be observed that trying to first use RPR could still provide an overall number of hops lower than directly using SRR. The detailed analysis is the same as that for DRR and can be found in [RFC7263].
上記の比較から、RPRを最初に使用しようとしても、SRRを直接使用するよりも全体的なホップ数が少ない可能性があることがわかります。詳細な分析はDRRの分析と同じであり、[RFC7263]で見つけることができます。
Authors' Addresses
著者のアドレス
Ning Zong Huawei Technologies
NIはGH UA上のZがテクノロジーであること
EMail: zongning@huawei.com
Xingfeng Jiang Huawei Technologies
興風江胡Aは技術です
EMail: jiang.x.f@huawei.com
Roni Even Huawei Technologies
逆Aもhu Aはテクノロジーです
EMail: roni.even@mail01.huawei.com
Yunfei Zhang CoolPad / China Mobile
Y UN非張クールパッド/チャイナモバイル
EMail: hishigh@gmail.com