Internet Engineering Task Force (IETF) N. Zong
Request for Comments: 7263 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: 7263 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 Direct Response Routing
对资源位置和发现（重新加载）协议的扩展，以支持直接响应路由
Abstract
摘要
This document defines an optional extension to the REsource LOcation And Discovery (RELOAD) protocol to support the direct response 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/rfc7263.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7263.
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 ....................................................4
2. Terminology .....................................................4
3. Overview ........................................................5
3.1. SRR and DRR ................................................5
3.1.1. Symmetric Recursive Routing (SRR) ...................6
3.1.2. Direct Response Routing (DRR) .......................6
3.2. Scenarios Where DRR Can Be Used ............................7
3.2.1. Managed or Closed P2P Systems .......................7
3.2.2. Wireless Scenarios ..................................8
4. Relationship between SRR and DRR ................................8
4.1. How DRR Works ..............................................8
4.2. How SRR and DRR Work Together ..............................8
5. DRR Extensions to RELOAD ........................................9
5.1. Basic Requirements .........................................9
5.2. Modification to RELOAD Message Structure ...................9
5.2.1. State-Keeping Flag ..................................9
5.2.2. Extensive Routing Mode .............................10
5.3. Creating a Request ........................................11
5.3.1. Creating a Request for DRR .........................11
5.4. Request and Response Processing ...........................11
5.4.1. Destination Peer: Receiving a Request and
Sending a Response .................................11
5.4.2. Sending Peer: Receiving a Response .................12
6. Overlay Configuration Extension ................................12
7. Security Considerations ........................................12
8. IANA Considerations ............................................13
8.1. A New RELOAD Forwarding Option ............................13
8.2. A New IETF XML Registry ...................................13
9. Acknowledgments ................................................13
10. References ....................................................13
10.1. Normative References .....................................13
10.2. Informative References ...................................14
Appendix A. Optional Methods to Investigate Peer Connectivity .....15
A.1. Getting Addresses to Be Used as Candidates for DRR .........15
A.2. Public Reachability Test ...................................16
Appendix B. Comparison of Cost of SRR and DRR .....................17
B.1. Closed or Managed Networks .................................17
B.2. Open Networks ..............................................19
1. Introduction ....................................................4
2. Terminology .....................................................4
3. Overview ........................................................5
3.1. SRR and DRR ................................................5
3.1.1. Symmetric Recursive Routing (SRR) ...................6
3.1.2. Direct Response Routing (DRR) .......................6
3.2. Scenarios Where DRR Can Be Used ............................7
3.2.1. Managed or Closed P2P Systems .......................7
3.2.2. Wireless Scenarios ..................................8
4. Relationship between SRR and DRR ................................8
4.1. How DRR Works ..............................................8
4.2. How SRR and DRR Work Together ..............................8
5. DRR Extensions to RELOAD ........................................9
5.1. Basic Requirements .........................................9
5.2. Modification to RELOAD Message Structure ...................9
5.2.1. State-Keeping Flag ..................................9
5.2.2. Extensive Routing Mode .............................10
5.3. Creating a Request ........................................11
5.3.1. Creating a Request for DRR .........................11
5.4. Request and Response Processing ...........................11
5.4.1. Destination Peer: Receiving a Request and
Sending a Response .................................11
5.4.2. Sending Peer: Receiving a Response .................12
6. Overlay Configuration Extension ................................12
7. Security Considerations ........................................12
8. IANA Considerations ............................................13
8.1. A New RELOAD Forwarding Option ............................13
8.2. A New IETF XML Registry ...................................13
9. Acknowledgments ................................................13
10. References ....................................................13
10.1. Normative References .....................................13
10.2. Informative References ...................................14
Appendix A. Optional Methods to Investigate Peer Connectivity .....15
A.1. Getting Addresses to Be Used as Candidates for DRR .........15
A.2. Public Reachability Test ...................................16
Appendix B. Comparison of Cost of SRR and DRR .....................17
B.1. Closed or Managed Networks .................................17
B.2. Open Networks ..............................................19
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, DRR is advantageous over SRR in some scenarios in that DRR can reduce load (CPU and link bandwidth) on intermediate peers. For example, in a closed network where every peer is in the same address realm, DRR performs better than SRR. In other scenarios, using a combination of DRR and SRR together is more likely to provide benefits than if SRR is used alone.
资源位置和发现（RELOAD）协议[RFC6940]为路由消息推荐对称递归路由（SRR），并描述了支持其他路由算法所需的扩展。除了SRR，在[RFC6940]的附录A中还讨论了另外两种路由选择——直接响应路由（DRR）和中继对等路由（RPR）。如第3节所示，DRR在某些情况下优于SRR，因为DRR可以减少中间对等点上的负载（CPU和链路带宽）。例如，在每个对等方都位于同一地址域的封闭网络中，DRR的性能优于SRR。在其他场景中，将DRR和SRR结合使用比单独使用SRR更有可能带来好处。
Note that in this document we focus on the DRR mode and its extensions to RELOAD to produce a standalone solution. Please refer to [RFC7264] for details on the RPR mode.
请注意，在本文档中，我们将重点介绍DRR模式及其扩展，以便重新加载以生成独立的解决方案。有关RPR模式的详细信息，请参阅[RFC7264]。
We first discuss the problem statement in Section 3. How to combine DRR and SRR is presented in Section 4. An extension to RELOAD to support DRR is defined in Section 5. 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 DRR in both managed and open networks.
我们首先在第3节讨论问题陈述。第4节介绍了如何结合DRR和SRR。第5节定义了重新加载以支持DRR的扩展。附录A中介绍了一些检查对等连接的可选方法。在附录B中，我们比较了管理网络和开放网络中SRR和DRR的成本。
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.
可公开访问：如果对等方可以从同一覆盖中的任何其他对等方接收未经请求的消息，则该对等方是可公开访问的。注：“公开”并不意味着对等方必须在公共互联网上，因为重载协议可以在封闭网络中使用。
Direct Response Routing (DRR): "DRR" refers to a routing mode in which responses to Peer-to-Peer SIP (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”指的是一种路由模式，在这种模式下，对等SIP（P2PSIP）请求的响应将根据发送对等方自己的本地传输地址直接从目标对等方返回给发送对等方。为简单起见，本文件其余部分使用缩写“DRR”。
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”。
Relay Peer Routing (RPR): "RPR" refers to a routing mode in which responses to P2PSIP requests are sent by the destination peer to the transport address of a relay peer that will forward the responses towards the sending peer. For simplicity, the abbreviation "RPR" is used in the rest of this document.
中继对等路由（RPR）：“RPR”指的是一种路由模式，在这种模式下，目标对等方将对P2PSIP请求的响应发送到中继对等方的传输地址，中继对等方将向发送对等方转发响应。为简单起见，本文件其余部分使用缩写“RPR”。
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 DRR may work better in some specific scenarios.
重新加载预计将在大量应用程序场景下工作。要部署重新加载的情况差别很大。例如，一些部署是全球性的，例如旨在提供公共服务的类似Skype的系统，而其他部署则在小型封闭网络中运行。SRR在任何情况下都可以工作，但DRR在某些特定场景下可能工作得更好。
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 two routing modes: SRR and DRR.
重载是一种简单的请求-响应协议。发送请求后，对等方等待目标对等方的响应。目标对等方有几种方法将响应发送回源对等方。在本节中，我们将提供有关两种路由模式的详细信息：SRR和DRR。
Some assumptions are made in the illustrations that follow:
下图中给出了一些假设：
1) Peer A sends a request destined to a peer who is the responsible peer for a Resource-ID k.
1) 对等方A向作为资源ID k的负责对等方的对等方发送目的地为的请求。
2) Peer X is the root peer responsible for Resource-ID k.
2) 对等方X是负责资源ID k的根对等方。
3) The intermediate peers for the path from A to X are peers B, C, and D.
3) 从A到X的路径的中间对等点是对等点B、C和D。
For SRR, when the request sent by peer A is received by an intermediate peer B, C, or D, each intermediate peer will insert information on the peer from whom they got the request in the Via List, as described in RELOAD [RFC6940]. As a result, the destination peer X will know the exact path that the request has traversed. Peer X will then send back the response in the reverse path by constructing a Destination List based on the Via List in the request. Figure 1 illustrates SRR.
对于SRR，当中间对等方B、C或D接收到对等方A发送的请求时，每个中间对等方将在Via列表中插入从其获得请求的对等方的信息，如RELOAD[RFC6940]中所述。因此，目标对等方X将知道请求所经过的确切路径。然后，Peer X将通过基于请求中的Via列表构建目的地列表，以反向路径发回响应。图1说明了SRR。
A B C D X
| Request | | | |
|----------->| | | |
| | Request | | |
| |----------->| | |
| | | Request | |
| | |----------->| |
| | | | Request |
| | | |----------->|
| | | | |
| | | | Response |
| | | |<-----------|
| | | Response | |
| | |<-----------| |
| | Response | | |
| |<-----------| | |
| Response | | | |
|<-----------| | | |
| | | | |
A B C D X
| Request | | | |
|----------->| | | |
| | Request | | |
| |----------->| | |
| | | Request | |
| | |----------->| |
| | | | Request |
| | | |----------->|
| | | | |
| | | | Response |
| | | |<-----------|
| | | Response | |
| | |<-----------| |
| | Response | | |
| |<-----------| | |
| Response | | | |
|<-----------| | | |
| | | | |
Figure 1: SRR Mode
图1:SRR模式
SRR works in any situation, especially when there are NATs or firewalls. A downside of this solution is that the message takes several hops to return to the peer, increasing the bandwidth usage and CPU/battery load of multiple peers.
SRR可以在任何情况下工作，尤其是在存在NAT或防火墙的情况下。此解决方案的一个缺点是消息需要几跳才能返回到对等方，从而增加了多个对等方的带宽使用率和CPU/电池负载。
In DRR, peer X receives the request sent by peer A through intermediate peers B, C, and D, as in SRR. However, peer X sends the response back directly to peer A based on peer A's local transport address. In this case, the response is not routed through intermediate peers. Figure 2 illustrates DRR. Using a shorter route means less overhead on intermediate peers, especially in the case of wireless networks where the CPU and uplink bandwidth are limited. For example, in the absence of NATs, or if the NAT implements
在DRR中，对等方X接收对等方A通过中间对等方B、C和D发送的请求，如SRR中所示。但是，对等X根据对等A的本地传输地址直接将响应发送回对等A。在这种情况下，响应不会通过中间对等方路由。图2说明了DRR。使用较短的路由意味着中间节点上的开销较少，特别是在CPU和上行链路带宽有限的无线网络中。例如，在没有NAT的情况下，或者如果NAT实现
endpoint-independent filtering, this is the optimal routing technique. Note that establishing a secure connection requires multiple round trips. Please refer to Appendix B for a cost comparison between SRR and DRR.
端点独立过滤，这是最佳路由技术。请注意，建立安全连接需要多次往返。关于SRR和DRR之间的成本比较，请参考附录B。
A B C D X
| Request | | | |
|----------->| | | |
| | Request | | |
| |----------->| | |
| | | Request | |
| | |----------->| |
| | | | Request |
| | | |----------->|
| | | | |
| | | | Response |
|<-----------+------------+------------+------------|
| | | | |
A B C D X
| Request | | | |
|----------->| | | |
| | Request | | |
| |----------->| | |
| | | Request | |
| | |----------->| |
| | | | Request |
| | | |----------->|
| | | | |
| | | | Response |
|<-----------+------------+------------+------------|
| | | | |
Figure 2: DRR Mode
图2:DRR模式
This section lists several scenarios where using DRR would work and identifies when the increased efficiency would be advantageous.
本节列出了使用DRR的几种情况，并确定了提高效率的有利时机。
The properties that make P2P technology attractive, such as the lack of need for centralized servers, self-organization, etc., are attractive for managed systems as well as unmanaged systems. Many of these systems are deployed on private networks where peers are in the same address realm and/or can directly route to each other. In such a scenario, the network administrator can indicate preference for DRR in the peer's configuration file. Peers in such a system would always try DRR first, but peers MUST also support SRR in case DRR fails. During the process of establishing a direct connection with the sending peer, if the responding peer receives a request with SRR as the preferred routing mode (or it fails to establish the direct connection), the responding peer SHOULD NOT use DRR but instead switch to SRR. The simple policy is to try DRR and, if this fails, switch to SRR for all connections. In a finer-grained policy, a peer would keep a list of unreachable peers based on trying DRR and then would use only SRR for those peers. The advantage of using DRR is network stability, since it puts less overhead on the intermediate peers that will not route the responses. The intermediate peers will need to route fewer messages and will save CPU resources as well as link bandwidth usage.
使P2P技术具有吸引力的特性，例如不需要集中式服务器、自组织等，对托管系统和非托管系统都具有吸引力。这些系统中的许多部署在私有网络上，其中对等点位于同一地址域和/或可以直接路由到彼此。在这种情况下，网络管理员可以在对等方的配置文件中指示DRR的首选项。这种系统中的对等方总是首先尝试DRR，但对等方还必须在DRR失败的情况下支持SRR。在与发送对等方建立直接连接的过程中，如果响应对等方接收到以SRR作为首选路由模式的请求（或无法建立直接连接），则响应对等方不应使用DRR，而应切换到SRR。简单的策略是尝试DRR，如果失败，则为所有连接切换到SRR。在细粒度策略中，对等方将根据尝试的DRR保留一个无法访问的对等方列表，然后仅对这些对等方使用SRR。使用DRR的优点是网络稳定性，因为它减少了不会路由响应的中间对等方的开销。中间对等点将需要路由更少的消息，并将节省CPU资源和链路带宽使用。
In some mobile deployments, using DRR may help reduce radio battery usage and bandwidth by the intermediate peers. The service provider may recommend using DRR based on his knowledge of the topology.
在某些移动部署中，使用DRR可能有助于减少中间节点的无线电池使用量和带宽。服务提供商可根据其对拓扑的了解，建议使用DRR。
DRR is very simple. The only requirement is for the source peers to provide their potential (publicly reachable) transport address to the destination peers, so that the destination peer knows where to send the response. Responses are sent directly to the requesting peer.
DRR非常简单。唯一的要求是源对等方向目标对等方提供其潜在的（可公开访问的）传输地址，以便目标对等方知道在哪里发送响应。响应直接发送到请求的对等方。
DRR is not intended to replace SRR. It is better to use these two modes together to adapt to each peer's specific situation. In this section, we give some informative suggestions for how to transition between the routing modes in RELOAD.
DRR并不打算取代SRR。最好将这两种模式结合使用，以适应每个对等方的具体情况。在本节中，我们将提供一些关于如何在重新加载时在路由模式之间转换的信息性建议。
According to [RFC6940], SRR MUST be supported. An overlay MAY be configured to use alternative routing algorithms, and alternative routing algorithms MAY be selected on a per-message basis. That is, a node in an overlay that supports SRR and some other routing algorithm -- for example, DRR -- might use SRR some of the time and DRR some of the time. A node joining the overlay should get the preferred routing mode from the configuration file. If an overlay runs within a private network and all peers in the system can reach each other directly, peers MAY send most of the transactions with DRR. However, DRR 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 DRR is defined in Section 6.
根据[RFC6940]，必须支持SRR。覆盖可被配置为使用替代路由算法，并且可基于每条消息选择替代路由算法。也就是说，覆盖中支持SRR和其他一些路由算法（例如DRR）的节点可能在某些时候使用SRR，在某些时候使用DRR。加入覆盖的节点应从配置文件中获取首选路由模式。如果覆盖在专用网络内运行，并且系统中的所有对等方都可以直接彼此联系，则对等方可以使用DRR发送大部分事务。但是，DRR不应在开放Internet中使用，或者如果管理员认为他没有足够的关于覆盖网络拓扑的信息。第6节定义了一个新的覆盖配置元素，用于指定DRR的使用。
Alternatively, a peer can collect statistical data on the success of the different routing modes based on previous transactions and keep a list of non-reachable addresses. Based on this data, the peer will have a clearer view of the success rate of different routing modes. In addition to data on the success rate, the peer can also get data of finer granularity -- for example, the number of retransmissions the peer needs to achieve a desirable success rate.
或者，对等方可以根据以前的事务收集不同路由模式成功的统计数据，并保留不可到达地址的列表。基于此数据，对等方将更清楚地了解不同路由模式的成功率。除了关于成功率的数据外，对等方还可以获得粒度更细的数据——例如，对等方实现理想成功率所需的重传次数。
A typical strategy for the peer is as follows. A peer chooses to start with DRR based on the configuration. Based on the success rate as indicated by statistics on lost messages or by responses that used DRR, the peer can either continue to offer DRR first or switch to
对等方的典型策略如下所示。对等方根据配置选择从DRR开始。根据丢失消息的统计数据或使用DRR的响应所指示的成功率，对等方可以首先继续提供DRR或切换到DRR
SRR. Note that a peer should use the DRR success statistics to decide whether to continue using DRR or fall back to SRR. Making such a decision per specific connection is not recommended; this should be an application decision.
SRR。请注意，对等方应使用DRR成功统计信息来决定是继续使用DRR还是退回SRR。不建议针对特定连接做出此类决定；这应该是一个申请决定。
Adding support for DRR requires extensions to the current RELOAD protocol. In this section, we define the required extensions, including extensions to message structure and message processing.
添加对DRR的支持需要对当前重新加载协议进行扩展。在本节中，我们定义了所需的扩展，包括对消息结构和消息处理的扩展。
All peers MUST be able to process requests for routing in SRR and MAY support DRR routing requests.
所有对等方必须能够处理SRR中的路由请求，并且可能支持DRR路由请求。
RELOAD provides an extensible framework to accommodate future extensions. In this section, we define a ForwardingOption structure to support DRR mode. Additionally, we present a state-keeping flag to inform intermediate peers if they are allowed to not maintain state for a transaction.
RELOAD提供了一个可扩展的框架，以适应未来的扩展。在本节中，我们定义了一个ForwardingOption结构来支持DRR模式。此外，如果允许中间对等方不维护事务的状态，我们将提供一个状态保持标志来通知中间对等方。
RELOAD allows intermediate peers to maintain state in order to implement SRR -- for example, for implementing hop-by-hop retransmission. If DRR is used, the response will not follow the reverse path, and the state in the intermediate peers will not be cleared until such state expires. In order to address this issue, we define a new flag, state-keeping flag, in the ForwardingOption structure to indicate whether the state-keeping is required in the intermediate peers.
重载允许中间对等方维护状态以实现SRR——例如，实现逐跳重传。如果使用DRR，响应将不会遵循反向路径，并且在该状态到期之前，中间对等方中的状态不会被清除。为了解决这个问题，我们在ForwardingOption结构中定义了一个新的标志——状态保持标志，以指示中间对等点中是否需要状态保持。
Flag: 0x08 IGNORE-STATE-KEEPING
标志：0x08忽略状态保持
If IGNORE-STATE-KEEPING is set, any peer receiving this message but who is not the destination of the message SHOULD forward the message with the full Via List and SHOULD NOT maintain any internal state.
如果设置了IGNORE-STATE-KEEPING，则接收此消息但不是消息目的地的任何对等方都应使用完整的Via列表转发消息，并且不应保持任何内部状态。
This document introduces a new forwarding option for an extensive routing mode. This option conforms to the description in Section 6.3.2.3 of [RFC6940].
本文档为扩展路由模式引入了一个新的转发选项。该选项符合[RFC6940]第6.3.2.3节中的说明。
We first define a new type to define the new option, extensive_routing_mode:
我们首先定义一个新类型来定义新选项，扩展路由模式：
The option value that defines the ExtensiveRoutingModeOption structure is illustrated below:
定义ExtensionVeroutingModeOption结构的选项值如下所示：
enum {(0),DRR(1),(255)} RouteMode;
struct {
RouteMode routemode;
OverlayLinkType transport;
IpAddressPort ipaddressport;
Destination destinations<1..2^8-1>;
} ExtensiveRoutingModeOption;
enum {(0),DRR(1),(255)} RouteMode;
struct {
RouteMode routemode;
OverlayLinkType transport;
IpAddressPort ipaddressport;
Destination destinations<1..2^8-1>;
} ExtensiveRoutingModeOption;
The above structure reuses the OverlayLinkType, Destination, and IpAddressPort structures as defined in Sections 6.5.1.1, 6.3.2.2, and 6.3.1.1 of [RFC6940], respectively.
上述结构分别重用[RFC6940]第6.5.1.1、6.3.2.2和6.3.1.1节中定义的OverlayLinkType、Destination和IpAddressPort结构。
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 sending peer.
OverlyLink类型：指用于将响应从目标对等方传递到发送对等方的传输类型。
IpAddressPort: refers to the transport address that the destination peer will use for sending responses. This will be a sending peer address for DRR.
IpAddressPort：指目标对等方将用于发送响应的传输地址。这将是DRR的发送对等地址。
Destination: refers to the sending peer itself. If the routing mode is DRR, then the destination only contains the sending peer's Node-ID.
目的地：指发送对等方本身。如果路由模式为DRR，则目的地仅包含发送对等方的节点ID。
When using DRR 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:
当对事务使用DRR时，发送对等方必须在转发器中设置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 0x01 (DRR).
2.1）路由模式设置为0x01（DRR）。
2.2) transport set as appropriate for the sender.
2.2）根据发送者的需要设置运输装置。
2.3) ipaddressport set to the peer's associated transport address.
2.3）ipaddressport设置为对等方的关联传输地址。
2.4) The destination structure MUST contain one value, defined as type "node" and set with the sending peer's own values.
2.4）目标结构必须包含一个值，定义为“节点”类型，并使用发送对等方自己的值进行设置。
This section gives normative text for message processing after DRR is introduced. Here, we only describe the additional procedures for supporting DRR. Please refer to [RFC6940] for RELOAD base procedures.
本节给出了引入DRR后消息处理的标准文本。这里，我们只描述支持DRR的附加程序。请参考[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 DRR, the destination peer MUST construct the Destination List for the response with only one entry, using the requesting peer's Node-ID from the Via List in the request as the value.
如果路由模式为DRR，则目标对等方必须使用请求中Via列表中请求对等方的节点ID作为值，仅使用一个条目为响应构建目标列表。
In the event that the routing mode is set to DRR and there is not exactly one destination, the destination peer MUST try to return an "Error_Unknown_Extension" response (defined in Sections 6.3.3.1 and 14.9 of [RFC6940]) to the sending peer using SRR.
如果路由模式设置为DRR且不存在一个目的地，目的地对等方必须尝试使用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 DRR response and use SRR.
对等方构造响应的目标列表后，会将响应发送到传输地址，该地址在使用ForwardingOption中的特定传输模式的选项的ipaddressport字段中指示。如果目标对等方在其现在尝试响应的消息上接收到具有SRR首选项的重传，则响应对等方应中止DRR响应并使用SRR。
Upon receiving a response, the peer follows the rules in [RFC6940]. The peer SHOULD note if DRR worked, in order to decide whether to offer DRR again. If the peer does not receive a response until the timeout, it SHOULD resend the request using SRR.
收到响应后，对等方遵循[RFC6940]中的规则。对等方应注意DRR是否有效，以便决定是否再次提供DRR。如果对等方在超时之前没有收到响应，则应使用SRR重新发送请求。
This document extends the RELOAD overlay configuration (see Section 11.1 of [RFC6940]) by adding one new element, "route-mode", inside each "configuration" element.
本文件通过在每个“配置”元素内添加一个新元素“路由模式”，扩展了重新加载覆盖配置（见[RFC6940]第11.1节）。
The Compact Regular Language for XML Next Generation (RELAX NG) grammar for this element is:
此元素的XML下一代压缩正则语言（RELAX NG）语法为：
namespace route-mode = "urn:ietf:params:xml:ns:p2p:route-mode"
namespace route-mode = "urn:ietf:params:xml:ns:p2p:route-mode"
parameter &= element route-mode:mode { xsd:string }?
parameter &= element route-mode:mode { xsd:string }?
This namespace is added into the <mandatory-extension> element in the overlay configuration file. The defined routing modes include DRR and RPR.
该名称空间被添加到覆盖配置文件中的<mandatory extension>元素中。定义的路由模式包括DRR和RPR。
The mode can be DRR or RPR and, if specified in the configuration, should be the preferred routing mode used by the application.
该模式可以是DRR或RPR，如果在配置中指定，则应为应用程序使用的首选路由模式。
The normative security recommendations of Section 13 of [RFC6940] are applicable to this document. As a routing alternative, the security part of DRR conforms to Section 13.6 of [RFC6940], which describes routing security. For example, the DRR routing option provides information about the route back to the source. According to
[RFC6940]第13节的规范性安全建议适用于本文件。作为一种路由选择，DRR的安全部分符合[RFC6940]第13.6节，该节描述了路由安全性。例如，DRR路由选项提供有关返回源的路由的信息。根据
Section 13.6 of [RFC6940], the entire DRR routing message MUST be digitally signed and sent over via a protected channel to protect the DRR routing information.
[RFC6940]第13.6节规定，必须对整个DRR路由消息进行数字签名，并通过受保护通道发送，以保护DRR路由信息。
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转发选项：扩展路由模式
IANA has registered the following URN in the "XML Namespaces" class of the "IETF XML Registry" in accordance with [RFC3688].
IANA已根据[RFC3688]在“IETF XML注册表”的“XML名称空间”类中注册了以下URN。
URI: urn:ietf:params:xml:ns:p2p:route-mode
URI: urn:ietf:params:xml:ns:p2p:route-mode
Registrant Contact: The IESG
注册联系人：IESG
XML: This specification
XML：这个规范
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月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688]Mealling，M.“IETF XML注册表”，BCP 81，RFC 3688，2004年1月。
[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月。
[Chord] Stoica, I., Morris, R., Liben-Nowell, D., Karger, D., Kaashoek, M., Dabek, F., and H. Balakrishnan, "Chord: A Scalable Peer-to-Peer Lookup Protocol for Internet Applications", IEEE/ACM Transactions on Networking Volume 11, Issue 1, 17-32, February 2003.
[Chord]Stoica，I.，Morris，R.，Liben Nowell，D.，Karger，D.，Kaashoek，M.，Dabek，F.，和H.Balakrishnan，“Chord：互联网应用的可扩展对等查找协议”，IEEE/ACM网络交易卷11，第1期，第17-32期，2003年2月。
[DTLS] Modadugu, N. and E. Rescorla, "The Design and Implementation of Datagram TLS", Proc. 11th Network and Distributed System Security Symposium (NDSS), February 2004.
[DTLS]Modadugu，N.和E.Rescorla，“数据报TLS的设计和实现”，Proc。第11届网络和分布式系统安全研讨会（NDSS），2004年2月。
[IGD2] UPnP Forum, "WANIPConnection:2 Service", September 2010, <http://upnp.org/specs/gw/ UPnP-gw-WANIPConnection-v2-Service.pdf>.
[IGD2]UPnP论坛，“WANIConnect:2服务”，2010年9月<http://upnp.org/specs/gw/ UPnP-gw-WANIPConnection-v2-Service.pdf>。
[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月。
[RFC6886] Cheshire, S. and M. Krochmal, "NAT Port Mapping Protocol (NAT-PMP)", RFC 6886, April 2013.
[RFC6886]Cheshire，S.和M.Krochmal，“NAT端口映射协议（NAT-PMP）”，RFC 68862013年4月。
[RFC7264] Zong, N., Jiang, X., Even, R., and Y. Zhang, "An Extension to the REsource LOcation And Discovery (RELOAD) Protocol to Support Relay Peer Routing", RFC 7264, June 2014.
[RFC7264]Zong，N.，Jiang，X.，Even，R.，和Y.Zhang，“支持中继对等路由的资源定位和发现（重新加载）协议的扩展”，RFC 7264，2014年6月。
[wikiChord] Wikipedia, "Chord (peer-to-peer)", 2013, <http://en.wikipedia.org/w/ index.php?title=Chord_%28peer-to-peer%29&oldid=549516287>.
[维基和弦]维基百科，“和弦（点对点）”，2013年<http://en.wikipedia.org/w/ index.php？title=Chord_u%28对等%29&oldid=549516287>。
This section is for informational purposes only and provides some mechanisms that can be used when the configuration information does not specify if DRR 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.
本节仅供参考，并提供了一些在配置信息未指定是否可以使用DRR时可以使用的机制。它总结了与NAT相比，对等方可以使用的一些方法来确定自己的网络位置。这些方法可以帮助对等方决定它希望尝试哪种路由模式。请注意，除了通过带外机制之外，没有简单易行的方法来确定对等点是否可公开访问。本文档通过向SRR[RFC6940]指定回退计划，解决了单边自地址修复（UNSAF）[RFC3424]的注意事项。SRR不是UNSAF机制。本文件未定义任何新的UNSAF机制。
For DRR to function correctly, a peer may attempt to determine whether it is publicly reachable. If it is not, the peer should fall back to SRR. If the peer believes it is publicly reachable, DRR may be attempted. NATs and firewalls are two major contributors to preventing DRR 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 use DRR for responses.
为了使DRR正常工作，对等方可以尝试确定它是否可公开访问。如果不是这样，对等方应该退回到SRR。如果对等方认为它可以公开访问，则可以尝试DRR。NAT和防火墙是阻止DRR正常运行的两个主要因素。有许多技术可以让对等方在NAT的公共端获得其反射地址。获得自反地址后，对等方可以执行进一步的测试，以了解自反地址是否可公开访问。如果该地址似乎可以公开访问，则该地址所属的对等方可以使用DRR进行响应。
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路由算法可以很容易地将请求从发送节点传递到发送节点没有直接连接的节点。这使得对等方很容易要求其他对等方将未经请求的消息发送回请求方。
In the following sections, we first introduce several ways for a peer to get the addresses needed for further tests. Then, a test for learning whether a peer may be publicly reachable is proposed.
在下面的部分中，我们首先介绍对等方获取进一步测试所需地址的几种方法。然后，提出了一个测试来了解对等点是否可以公开访问。
In order to test whether a peer may be publicly reachable, the peer should first get one or more addresses that will be used by other peers to send him messages directly. This address is either a local address of a peer or a translated address that is assigned by a NAT to the peer.
为了测试一个对等方是否可以公开访问，该对等方应该首先获得一个或多个地址，其他对等方将使用这些地址直接向他发送消息。该地址可以是对等方的本地地址，也可以是NAT分配给对等方的翻译地址。
Session Traversal Utilities for NAT (STUN) is used to get a reflexive address on the public side of a NAT with the help of STUN servers. NAT behavior discovery using STUN is specified in [RFC5780]. Under the RELOAD architecture, a few infrastructure servers can be leveraged for discovering NAT behavior, such as enrollment servers, diagnostic servers, bootstrap servers, etc.
NAT会话遍历实用程序（STUN）在STUN服务器的帮助下，用于在NAT的公共端获取自反地址。[RFC5780]中规定了使用STUN进行NAT行为发现。在重新加载体系结构下，可以利用一些基础结构服务器来发现NAT行为，例如注册服务器、诊断服务器、引导服务器等。
The peer can use a STUN Binding request to one of the STUN servers to trigger a STUN Binding response, which returns the reflexive address from the server's perspective. If the reflexive transport address is the same as the source address of the Binding request, the peer can determine that there is likely no NAT between it and the chosen infrastructure server. (Certainly, in some rare cases, the allocated address happens to be the same as the source address. Further tests will detect this case and rule it out in the end.) Usually, these infrastructure servers are publicly reachable in the overlay, so the peer can be considered publicly reachable. On the other hand, using the techniques in [RFC5780], a peer can also decide whether it is behind a NAT with endpoint-independent mapping behavior. If the peer is behind a NAT with endpoint-independent mapping behavior, the reflexive address should also be a candidate for further tests.
对等方可以使用对其中一个STUN服务器的STUN绑定请求来触发STUN绑定响应，该响应从服务器的角度返回自反地址。如果自反传输地址与绑定请求的源地址相同，则对等方可以确定它与所选基础结构服务器之间可能没有NAT。（当然，在一些罕见的情况下，分配的地址恰好与源地址相同。进一步的测试将检测到这种情况并最终排除它。）通常，这些基础结构服务器在覆盖中是可公开访问的，因此可以认为对等方是可公开访问的。另一方面，使用[RFC5780]中的技术，对等方还可以通过端点无关的映射行为确定它是否位于NAT后面。如果对等方位于具有端点无关映射行为的NAT后面，则自反地址也应该是进一步测试的候选地址。
The Universal Plug and Play Internet Gateway Device (UPnP-IGD) [IGD2] is a mechanism that a peer can use to get the assigned address from its residential gateway, and after obtaining this address to communicate it with other peers, the peer can receive unsolicited messages from outside, even though it is behind a NAT. So, the address obtained through the UPnP mechanism should also be used for further tests.
通用即插即用互联网网关设备（UPnP IGD）[IGD2]是一种对等方可用于从其住宅网关获取分配地址的机制，并且在获取该地址以与其他对等方通信后，对等方可接收来自外部的未经请求的消息，即使其位于NAT后面。因此，通过UPnP机制获得的地址也应用于进一步的测试。
Another way that a peer behind NAT can learn its assigned address by NAT is via the NAT Port Mapping Protocol (NAT-PMP) [RFC6886]. As with UPnP-IGD, the address obtained using this mechanism should also be tested further.
NAT后面的对等方通过NAT学习其分配地址的另一种方式是通过NAT端口映射协议（NAT-PMP）[RFC6886]。与UPnP IGD一样，使用此机制获得的地址也应进一步测试。
The above techniques are not exhaustive. These techniques can be used to get candidate transport addresses for further tests.
上述技术并非详尽无遗。这些技术可用于获取用于进一步测试的候选传输地址。
Using the transport addresses obtained by the above techniques, a peer can start a test to learn whether the candidate transport address is publicly reachable. The basic idea of the test is that a peer sends a request and expects another peer in the overlay to send back a response. If the response is successfully received by the sending peer and the peer giving the response has no direct
使用通过上述技术获得的传输地址，对等方可以开始测试，以了解候选传输地址是否可公开访问。测试的基本思想是，一个对等方发送一个请求，并期望覆盖层中的另一个对等方发送回响应。如果发送对等方成功接收到响应，并且发出响应的对等方没有直接
connection with the sending peer, the sending peer can determine that the address is probably publicly reachable and hence the peer may be publicly reachable at the tested transport address.
通过与发送对等方的连接，发送对等方可以确定该地址可能是可公开访问的，因此该对等方可以在测试的传输地址处公开访问。
In a P2P overlay, a request is routed through the overlay and finally a destination peer will terminate the request and give the response. In a large system, there is a high probability that the destination peer has no direct connection with the sending peer. Every peer maintains a connection table, particularly in the RELOAD architecture, so it is easier for a peer to see whether it has direct connection with another peer.
在P2P覆盖中，请求通过覆盖路由，最终目标对等方将终止请求并给出响应。在大型系统中，目标对等方很可能与发送对等方没有直接连接。每个对等机都维护一个连接表，特别是在重新加载体系结构中，因此对等机更容易查看它是否与另一个对等机有直接连接。
If a peer wants to test whether its transport address is publicly reachable, it can send a request to the overlay. The routing for the test message would be different from other kinds of requests because it is not for storing or fetching something to or from the overlay, or for locating a specific peer; instead, it is to get a peer who can deliver to the sending peer an unsolicited response and who has no direct connection with him. Each intermediate peer receiving the request first checks to see whether it has a direct connection with the sending peer. If there is a direct connection, the request is routed to the next peer. If there is no direct connection, the intermediate peer terminates the request and sends the response back directly to the sending peer with the transport address under test.
如果对等方希望测试其传输地址是否可公开访问，则可以向覆盖发送请求。测试消息的路由将不同于其他类型的请求，因为它不是用于存储或从覆盖层获取内容，或者用于定位特定的对等方；取而代之的是让一个能够主动向发送的对等方提供响应并且与他没有直接联系的对等方。接收请求的每个中间对等方首先检查它是否与发送对等方有直接连接。如果存在直接连接，则将请求路由到下一个对等方。如果没有直接连接，中间对等方将终止请求，并将响应直接发送回发送对等方，发送对等方具有测试中的传输地址。
After performing the test, if the peer determines that it may be publicly reachable, it can try DRR in subsequent transactions.
执行测试后，如果对等方确定它可以公开访问，则可以在后续事务中尝试DRR。
The major advantage of using DRR 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.
使用DRR的主要优点是减少了响应所经过的中间对等点的数量。这降低了这些对等方资源上的负载，例如处理和通信带宽。
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 DRR.
如第3节所述，许多P2P系统在封闭或管理的环境中运行（例如，运营商网络），因此网络管理员知道他们可以安全地使用DRR。
SRR uses more routing hops than DRR. Assuming that there are N peers in the P2P system and Chord [Chord] [wikiChord] is applied for routing, the number of hops for a response in SRR and in DRR are listed in the following table. Establishing a secure connection between the sending peer and the responding peer with Transport Layer Security (TLS) or Datagram TLS (DTLS) requires multiple messages. Note that establishing (D)TLS secure connections for a P2P overlay is
SRR比DRR使用更多的路由跃点。假设P2P系统中有N个对等点，并且Chord[Chord][wikiChord]应用于路由，下表列出了SRR和DRR中响应的跃点数。使用传输层安全性（TLS）或数据报TLS（DTLS）在发送端和响应端之间建立安全连接需要多条消息。请注意，为P2P覆盖建立（D）TLS安全连接是非常困难的
not optimal in some cases, e.g., DRR where (D)TLS is heavy for temporary connections. Therefore, in the following table we show the cases of 1) no (D)TLS in DRR and 2) still using DTLS in DRR as sub-optimal. As the worst-cost case, seven (7) messages are used during DTLS handshaking [DTLS]. (The TLS handshake is a negotiation protocol that requires two (2) round trips, while the DTLS handshake is a negotiation protocol that requires three (3) round trips.)
在某些情况下不是最优的，例如，DRR，其中（D）TLS对于临时连接来说很重。因此，在下表中，我们显示了以下情况：1）DRR中没有（D）个TLS，2）DRR中仍然使用DTL作为次优。作为最坏的成本情况，在DTLS握手[DTLS]期间使用七（7）条消息。（TLS握手是一种需要两（2）次往返的协商协议，而DTLS握手是一种需要三（3）次往返的协商协议。）
Mode | Success | No. of Hops | No. of Msgs
------------------------------------------------
SRR | Yes | log(N) | log(N)
DRR | Yes | 1 | 1
DRR (DTLS) | Yes | 1 | 7+1
Mode | Success | No. of Hops | No. of Msgs
------------------------------------------------
SRR | Yes | log(N) | log(N)
DRR | Yes | 1 | 1
DRR (DTLS) | Yes | 1 | 7+1
Table 1: Comparison of SRR and DRR in Closed Networks
表1：封闭网络中SRR和DRR的比较
From the above comparison, it is clear that:
从上述比较中可以明显看出：
1) In most cases when the number of peers (N) > 2 (2^1), DRR 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 DRR in the cases where such resources as CPU and bandwidth are limited, e.g., the case of mobile, wireless networks.
1) 在大多数情况下，当对等节点数（N）>2（2^1）时，DRR使用的跳数比SRR少。使用较短的路由意味着中间对等点上的开销和资源使用更少，这是在CPU和带宽等资源有限的情况下采用DRR的一个重要考虑因素，例如，在移动无线网络的情况下。
2) In the cases when N > 256 (2^8), DRR also uses fewer messages than SRR.
2) 在N>256（2^8）的情况下，DRR使用的消息也比SRR少。
3) In the cases when N < 256, DRR uses more messages than SRR (but still uses fewer hops than SRR), so the consideration of whether to use DRR or SRR depends on other factors such as using less resources (bandwidth and processing) from the intermediate peers. Section 4 provides use cases where DRR has a better chance of working or where the considerations of intermediary resources are important.
3) 在N<256的情况下，DRR比SRR使用更多的消息（但仍然比SRR使用更少的跳数），因此是否使用DRR或SRR取决于其他因素，例如使用来自中间对等方的更少资源（带宽和处理）。第4节提供了DRR有更好的工作机会或中间资源的考虑很重要的用例。
In open networks (e.g., the Internet) where DRR is not guaranteed to work, DRR can fall back to SRR if it fails after trial, as described in Section 4. 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 DRR, are listed in the following table:
在开放网络（如互联网）中，DRR不能保证正常工作，如第4节所述，如果试验失败，DRR可以退回SRR。基于与附录B.1中列出的设置相同的设置，下表列出了SRR和DRR中的跃点数以及响应的消息数：
Mode | Success | No. of Hops | No. of Msgs
----------------------------------------------------------------
SRR | Yes | log(N) | log(N)
DRR | Yes | 1 | 1
| Fail & fall back to SRR | 1+log(N) | 1+log(N)
DRR (DTLS) | Yes | 1 | 7+1
| Fail & fall back to SRR | 1+log(N) | 8+log(N)
Mode | Success | No. of Hops | No. of Msgs
----------------------------------------------------------------
SRR | Yes | log(N) | log(N)
DRR | Yes | 1 | 1
| Fail & fall back to SRR | 1+log(N) | 1+log(N)
DRR (DTLS) | Yes | 1 | 7+1
| Fail & fall back to SRR | 1+log(N) | 8+log(N)
Table 2: Comparison of SRR and DRR in Open Networks
表2：开放网络中SRR和DRR的比较
From the above comparison, it can be observed that trying to first use DRR could still provide an overall number of hops lower than directly using SRR. Suppose that P peers are publicly reachable; the number of hops in DRR and SRR is P*1+(N-P)*(1+logN) and N*logN, respectively. The condition for fewer hops in DRR is P*1+(N-P)*(1+logN) < N*logN, which is P/N > 1/logN. This means that when the number of peers (N) grows, the required ratio of publicly reachable peers P/N for fewer hops in DRR decreases. Therefore, the chance of trying DRR with fewer hops than SRR improves as the scale of the network increases.
从上面的比较中可以看出，尝试首先使用DRR仍然可以提供比直接使用SRR更低的总跳数。假设P个对等点是可公开访问的；DRR和SRR中的跳数分别为P*1+（N-P）*（1+logN）和N*logN。DRR中跳数较少的条件是P*1+（N-P）*（1+logN）<N*logN，即P/N>1/logN。这意味着，当对等点（N）的数量增加时，DRR中跳数越少，所需的公共可访问对等点P/N比率越低。因此，随着网络规模的增加，使用比SRR更少的跳数尝试DRR的机会会提高。
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