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
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
对资源位置和发现（重新加载）协议的扩展，以支持中继对等路由
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.
本文档定义了资源位置和发现（重新加载）协议的可选扩展，以支持中继对等路由模式。RELOAD建议对路由消息使用对称递归路由。新的可选扩展为响应提供了较短的路由，从而减少了中间节点的开销。本文档还描述了可以使用此扩展的潜在情况。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/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.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
1. Introduction ....................................................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
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
资源位置和发现（RELOAD）协议[RFC6940]为路由消息推荐对称递归路由（SRR），并描述了支持其他路由算法所需的扩展。除了SRR，在[RFC6940]的附录A中还讨论了另外两种路由选择——直接响应路由（DRR）和中继对等路由（RPR）。正如我们在第3节中所展示的，RPR在某些场景中优于SRR，因为RPR可以减少中间对等点上的负载（CPU和链路带宽）。RPR在提前提供中继对等点的网络中工作得更好，因此
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.
在P2P系统中，中继节点是可公开访问的。在其他场景中，与单独使用SRR相比，将RPR和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模式及其重新加载以生成独立解决方案的扩展。有关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节讨论问题陈述。第4节介绍了如何将RPR和SRR结合起来。第5节定义了重新加载以支持RPR的扩展。第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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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.
我们在本文档中广泛使用基本重新加载规范[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.
可公开访问：如果对等方可以从同一覆盖中的任何其他对等方接收未经请求的消息，则该对等方是可公开访问的。注：“公开”并不意味着对等方必须在公共互联网上，因为重载协议可以在封闭网络中使用。
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.
对称递归路由（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.
重新加载预计将在大量应用程序场景下工作。要部署重新加载的情况差别很大。例如，一些部署是全球性的，例如旨在提供公共服务的类似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].
重载是一种简单的请求-响应协议。发送请求后，对等方等待目标对等方的响应。目标对等方有几种方法将响应发送回源对等方。在本节中，我们将提供有关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后面，并且知道一个或多个中继对等方之前与之有过连接，则对等方A可以尝试RPR。假设对等方A与中继对等方R关联。发送请求时，对等方A在请求中包含描述对等方R传输地址的信息。当peer X接收到请求时，peer X将响应发送给peer R，后者直接将其转发给现有连接上的peer A。图1说明了RPR。注意，与SRR相比，RPR还允许更短的响应路径；这意味着减少了中间节点的开销。建立到具有传输层安全性（TLS）的继电器的连接需要多次往返。有关SRR和RPR之间的成本比较，请参阅附录B。
A B C D X R
| Request | | | | |
|----------->| | | | |
| | Request | | | |
| |----------->| | | |
| | | Request | | |
| | |----------->| | |
| | | | Request | |
| | | |----------->| |
| | | | | Response |
| | | | |---------->|
| | | | Response | |
|<-----------+------------+------------+------------+-----------|
| | | | | |
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.
另一种用法是在受管网络边界上安装中继对等点，允许外部对等点向受管网络内的对等点发送响应。
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.
在重新加载体系结构中，引导节点通常是可公开访问的。因此，一种可能的方案是将引导节点用作中继对等点，以便与RPR一起使用。中继对等机应可公开访问，并与其客户端保持直接连接。因此，引导节点非常适合扮演中继节点的角色。
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的对等方必须与其中继对等方保持连接。这可以通过与使用附加方法[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
RPR并不打算取代SRR。最好将这两种模式结合使用，以适应每个对等方的具体情况。请注意，关于如何在SRR和RPR之间转换的信息性建议与DRR相同。更多详情请参考[RFC7263]第4.2节。如果中继对等方由服务提供商提供，则对等方应首选RPR而不是SRR。但是，RPR不应在开放互联网中使用，或者如果管理员使用RPR
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.
我觉得他没有足够的关于覆盖网络拓扑的信息。第6节定义了一个新的覆盖配置元素，用于指定RPR的使用。
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的支持需要对当前重新加载协议进行扩展。在本节中，我们定义了所需的扩展，包括对消息结构和消息处理的扩展。
All peers MUST be able to process requests for routing in SRR and MAY support RPR routing requests.
所有对等方必须能够处理SRR中的路由请求，并且可能支持RPR路由请求。
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路由选项。需要状态保持标志[RFC7263]来支持RPR模式。
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;
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.
OverlayLink类型：指用于将响应从目标对等方传递到中继对等方的传输类型。
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，则目的地包含两项：中继对等方的节点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时，发送对等方必须在转发头中设置IGNORE-STATE-KEEPING标志。此外，对等方必须在转发头中构造并包含转发选项结构。构造ForwardingOption结构时，必须按如下方式设置字段：
1) The type MUST be set to extensive_routing_mode.
1) 该类型必须设置为扩展路由模式。
2) The ExtensiveRoutingModeOption structure MUST be used for the option field within the ForwardingOption structure. The fields MUST be defined as follows:
2) ExtensionVeroutingModeOption结构必须用于ForwardingOption结构中的选项字段。这些字段必须定义如下：
2.1) routemode set to 0x02 (RPR).
2.1）路由模式设置为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）目标结构必须包含两个值。第一个必须定义为“节点”类型，并使用中继对等节点的值进行设置。第二个必须定义为类型“node”，并使用发送对等方自己的值进行设置。
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的附加过程。请参考[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.
当目标对等方收到请求时，它将检查转发头中的选项。如果目标对等方无法理解请求中的扩展路由模式选项，则必须尝试使用SRR向发送对等方返回“错误未知扩展”响应（定义见[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]中定义的两个条目。第一个条目必须根据请求中的选项设置为中继对等方的节点ID，第二个条目必须根据请求中的选项设置为发送对等方的节点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且不存在两个目的地，目的地对等方必须尝试使用SRR向发送对等方发送“错误未知扩展”响应（定义见[RFC6940]第6.3.3.1和14.9节）。
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.
对等方构造响应的目的地列表后，会将响应发送到传输地址，该地址在使用ForwardingOption中特定传输模式的选项的ipaddressport字段中指示。如果目标对等方在其现在尝试响应的消息上接收到具有SRR首选项的重传，则响应对等方应中止RPR响应并使用SRR。
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重新发送消息。
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.
中继对等点旨在将响应转发给无法公开访问的对等点。对于响应的路由，此文档仍然使用目的地列表。与SRR的唯一区别在于，目的地_列表与via_列表不同。相反，它是根据转发选项构建的，如下所述。
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]中的规则。它接收响应，验证消息，重新调整目标_列表，并根据连接表将响应转发到目标_列表中的下一个跃点。对中继对等机没有额外的要求。
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节中定义的每个“配置”元素内使用新的重新加载覆盖配置元素“路由模式”。路由模式必须为“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]中定义的“重新加载转发选项注册表”中添加了新的重新加载转发选项类型。
Code: 2 Forwarding Option: extensive_routing_mode
代码：2转发选项：扩展路由模式
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，“资源定位和发现（重新加载）基本协议”，RFC 69402014年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，“支持直接响应路由的资源定位和发现（重新加载）协议的扩展”，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，“网络地址转换中单边自地址固定（UNSAF）的IAB考虑”，RFC 34242002年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 57802010年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]指定回退计划，解决了单边自地址修复（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正常运行的两个主要因素。有许多技术可以让对等方在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
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可以退回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)
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
宁宗华为技术有限公司
EMail: zongning@huawei.com
EMail: zongning@huawei.com
Xingfeng Jiang Huawei Technologies
兴丰江华为技术有限公司
EMail: jiang.x.f@huawei.com
EMail: jiang.x.f@huawei.com
Roni Even Huawei Technologies
Roni甚至华为技术
EMail: roni.even@mail01.huawei.com
EMail: roni.even@mail01.huawei.com
Yunfei Zhang CoolPad / China Mobile
张云飞酷派/中国移动
EMail: hishigh@gmail.com
EMail: hishigh@gmail.com