Internet Engineering Task Force (IETF) J. Maenpaa
Request for Comments: 7374 G. Camarillo
Category: Standards Track Ericsson
ISSN: 2070-1721 October 2014
Internet Engineering Task Force (IETF) J. Maenpaa
Request for Comments: 7374 G. Camarillo
Category: Standards Track Ericsson
ISSN: 2070-1721 October 2014
Service Discovery Usage for REsource LOcation And Discovery (RELOAD)
资源位置和发现的服务发现使用情况（重新加载）
Abstract
摘要
REsource LOcation And Discovery (RELOAD) does not define a generic service discovery mechanism as a part of the base protocol (RFC 6940). This document defines how the Recursive Distributed Rendezvous (ReDiR) service discovery mechanism can be applied to RELOAD overlays to provide a generic service discovery mechanism.
资源位置和发现（重新加载）未将通用服务发现机制定义为基本协议（RFC 6940）的一部分。本文档定义了如何将递归分布式集合（ReDiR）服务发现机制应用于重新加载覆盖以提供通用服务发现机制。
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/rfc7374.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7374.
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. Introduction to ReDiR ...........................................5
4. Using ReDiR in a RELOAD Overlay Instance ........................8
4.1. Data Structure .............................................8
4.2. Selecting the Starting Level ...............................9
4.3. Service Provider Registration ..............................9
4.4. Refreshing Registrations ..................................10
4.5. Service Lookups ...........................................11
4.6. Removing Registrations ....................................13
5. Access Control Rules ...........................................13
6. REDIR Kind Definition ..........................................13
7. Examples .......................................................14
7.1. Service Registration ......................................14
7.2. Service Lookup ............................................16
8. Overlay Configuration Document Extension .......................16
9. Security Considerations ........................................17
10. IANA Considerations ...........................................17
10.1. Access Control Policies ..................................17
10.2. A New IETF XML Registry ..................................17
10.3. Data Kind-ID .............................................18
10.4. RELOAD Services Registry .................................18
11. References ....................................................19
11.1. Normative References .....................................19
11.2. Informative Reference ....................................19
Acknowledgments ...................................................19
Authors' Addresses ................................................20
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Introduction to ReDiR ...........................................5
4. Using ReDiR in a RELOAD Overlay Instance ........................8
4.1. Data Structure .............................................8
4.2. Selecting the Starting Level ...............................9
4.3. Service Provider Registration ..............................9
4.4. Refreshing Registrations ..................................10
4.5. Service Lookups ...........................................11
4.6. Removing Registrations ....................................13
5. Access Control Rules ...........................................13
6. REDIR Kind Definition ..........................................13
7. Examples .......................................................14
7.1. Service Registration ......................................14
7.2. Service Lookup ............................................16
8. Overlay Configuration Document Extension .......................16
9. Security Considerations ........................................17
10. IANA Considerations ...........................................17
10.1. Access Control Policies ..................................17
10.2. A New IETF XML Registry ..................................17
10.3. Data Kind-ID .............................................18
10.4. RELOAD Services Registry .................................18
11. References ....................................................19
11.1. Normative References .....................................19
11.2. Informative Reference ....................................19
Acknowledgments ...................................................19
Authors' Addresses ................................................20
REsource LOcation And Discovery (RELOAD) [RFC6940] is a peer-to-peer signaling protocol that can be used to maintain an overlay network and to store data in and retrieve data from the overlay. Although RELOAD defines a service discovery mechanism specific to Traversal Using Relays around Network Address Translation (TURN), it does not define a generic service discovery mechanism as a part of the base protocol. This document defines how the Recursive Distributed Rendezvous (ReDiR) service discovery mechanism specified in [Redir] can be applied to RELOAD overlays.
资源定位和发现（RELOAD）[RFC6940]是一种对等信令协议，可用于维护覆盖网络，并在覆盖中存储数据和从覆盖中检索数据。尽管RELOAD定义了一种特定于使用网络地址转换（TURN）中继进行遍历的服务发现机制，但它没有将通用服务发现机制定义为基本协议的一部分。本文档定义了如何将[ReDiR]中指定的递归分布式会合（ReDiR）服务发现机制应用于重新加载覆盖。
In a peer-to-peer (P2P) overlay network such as a RELOAD Overlay Instance, the peers forming the overlay share their resources in order to provide the service the system has been designed to provide. The peers in the overlay both provide services to other peers and request services from other peers. Examples of possible services peers in a RELOAD Overlay Instance can offer to each other include a TURN relay service, a voice mail service, a gateway location service, and a transcoding service. Typically, only a small subset of the peers participating in the system are providers of a given service. A peer that wishes to use a particular service faces the problem of finding peers that are providing that service from the Overlay Instance.
在对等（P2P）覆盖网络（如重新加载覆盖实例）中，形成覆盖的对等方共享其资源，以便提供系统设计用于提供的服务。覆盖层中的节点既向其他节点提供服务，也向其他节点请求服务。重载覆盖实例中的对等方可以彼此提供的可能服务的示例包括转向中继服务、语音邮件服务、网关位置服务和转码服务。通常，只有一小部分参与系统的对等方是给定服务的提供者。希望使用特定服务的对等方面临从覆盖实例查找提供该服务的对等方的问题。
A naive way to perform service discovery is to store the Node-IDs of all nodes providing a particular service under a well-known key k. The limitation of this approach is that it scales linearly with the number of nodes that provide the service. The problem is two-fold: the node n that is responsible for service s identified by key k may end up storing a large number of Node-IDs and, most importantly, may also become overloaded since all service lookup requests for service s will need to be answered by node n. An efficient service discovery mechanism does not overload the nodes storing pointers to service providers. In addition, the mechanism must ensure that the load associated with providing a given service is distributed evenly among the nodes providing the service.
执行服务发现的一种简单方法是将提供特定服务的所有节点的节点ID存储在已知密钥k下。这种方法的局限性在于，它与提供服务的节点数成线性关系。问题有两个方面：负责密钥k标识的服务s的节点n可能最终存储大量节点id，最重要的是，也可能过载，因为所有服务s的服务查找请求都需要节点n响应。高效的服务发现机制不会使存储指向服务提供者的指针的节点过载。此外，该机制必须确保与提供给定服务相关联的负载在提供服务的节点之间均匀分布。
It should be noted that a simple service discovery mechanism such as the one mentioned in the previous paragraph might be an appropriate solution in a very small overlay network consisting of perhaps tens of nodes. The ReDiR-based service discovery mechanism described in this document is suitable for use even in overlay networks where the number of end users that may make service discovery requests can be very high (e.g., tens of thousands of nodes or even higher) and where a large fraction of the peers (e.g., on the order of one out of ten or more) can offer the service.
应该注意的是，在可能由数十个节点组成的非常小的覆盖网络中，一个简单的服务发现机制（如前一段中提到的机制）可能是一个合适的解决方案。本文档中描述的基于ReDiR的服务发现机制甚至适用于覆盖网络中，在覆盖网络中，可能提出服务发现请求的最终用户数量可能非常高（例如，数万个节点或甚至更高），并且大部分对等方（例如，十个或更多个节点中的一个）我可以提供服务。
ReDiR implements service discovery by building a tree structure of the service providers that provide a particular service. The tree structure is stored into the RELOAD Overlay Instance using RELOAD Store and Fetch requests. Each service provided in the Overlay Instance has its own tree. The nodes in a ReDiR tree contain pointers to service providers. During service discovery, a peer wishing to use a given service fetches ReDiR tree nodes one-by-one from the RELOAD Overlay Instance until it finds a service provider responsible for its Node-ID. It has been proved that ReDiR can find a service provider using only a constant number of Fetch operations [Redir].
ReDiR通过构建提供特定服务的服务提供者的树结构来实现服务发现。使用重载存储和获取请求将树结构存储到重载覆盖实例中。覆盖实例中提供的每个服务都有自己的树。ReDiR树中的节点包含指向服务提供者的指针。在服务发现过程中，希望使用给定服务的对等方从重新加载覆盖实例中逐个获取ReDiR树节点，直到找到负责其节点ID的服务提供商。事实证明，ReDiR可以仅使用固定数量的获取操作[ReDiR]来查找服务提供商。
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]中所述进行解释。
DHT: Distributed Hash Tables (DHTs) are a class of decentralized distributed systems that provide a lookup service similar to a regular hash table. Given a key, any peer participating in the system can retrieve the value associated with that key. The responsibility for maintaining the mapping from keys to values is distributed among the peers.
DHT：分布式哈希表（Distributed Hash Tables，DHT）是一类分散的分布式系统，提供类似于常规哈希表的查找服务。给定一个密钥，参与系统的任何对等方都可以检索与该密钥关联的值。维护从键到值的映射的责任在对等点之间分配。
H(x): Refers to a hash function (e.g., SHA-1 [RFC3174]) calculated over the value x.
H（x）：指通过值x计算的散列函数（例如，SHA-1[RFC3174]）。
H(x,y,z): Refers to a hash function calculated over a concatenated string consisting of x, y, and z, where x, y, and z can be both strings and integers. The network byte order is used.
H（x，y，z）：指在由x，y和z组成的串联字符串上计算的哈希函数，其中x，y和z可以是字符串和整数。使用网络字节顺序。
I(lvl,k): An interval at level lvl in the ReDiR tree that encloses key k. As an example, I(5,10) refers to an interval at level 5 in the ReDiR tree within whose range key 10 falls.
I（lvl，k）：包含键k的ReDiR树中的lvl级别的间隔。例如，I（5,10）表示重拨树中级别5处的间隔，其范围键10落在该间隔内。
n.id: Refers to the RELOAD Node-ID of node n.
n、 id：节点n的重新加载节点id。
Namespace: An arbitrary identifier that identifies a service provided in the RELOAD Overlay Instance. Examples of potential namespaces include 'voice-mail' and 'turn-server'. The namespace is a UTF-8-encoded [RFC3629] text string.
名称空间：标识重载覆盖实例中提供的服务的任意标识符。潜在名称空间的示例包括“语音邮件”和“turn server”。名称空间是UTF-8编码的[RFC3629]文本字符串。
numBitsInNodeId: Refers to the number of bits in a RELOAD Node-ID. This value is used in the equations for calculating the ranges of intervals that ReDiR tree nodes are responsible for.
NumbitsinodeId：指重新加载节点ID中的位数。该值用于计算ReDiR树节点负责的间隔范围的方程式中。
ReDiR tree: A tree structure of the nodes that provide a particular service. The nodes embed the ReDiR tree into the RELOAD Overlay Instance using RELOAD Store and Fetch requests. Each tree node in the ReDiR tree belongs to some level in the tree. The root node of the ReDiR tree is located at level 0 of the ReDiR tree. The child nodes of the root node are located at level 1. The children of the tree nodes at level 1 are located at level 2, and so forth. The ReDiR tree has a branching factor b. At every level lvl in the ReDiR tree, there is room for a maximum of b^lvl tree nodes. Each tree node in the ReDiR tree is uniquely identified by a pair (lvl,j), where lvl is a level in the ReDiR tree and j is the position of the tree node (from the left) at that level.
ReDiR树：提供特定服务的节点的树结构。节点使用重新加载存储和获取请求将重读树嵌入到重新加载覆盖实例中。ReDiR树中的每个树节点都属于树中的某个级别。重拨树的根节点位于重拨树的级别0。根节点的子节点位于级别1。级别1的树节点的子节点位于级别2，依此类推。ReDiR树有一个分支因子b。在ReDiR树中的每一级lvl上，最多有b^lvl树节点的空间。ReDiR树中的每个树节点都由一对（lvl，j）唯一标识，其中lvl是ReDiR树中的一个级别，j是树节点（从左侧）在该级别的位置。
Successor: The successor of identifier k in namespace ns is the node belonging to the namespace ns whose identifier most immediately follows the identifier k.
继任者：命名空间ns中标识符k的继任者是属于命名空间ns的节点，其标识符紧跟在标识符k之后。
Recursive Distributed Rendezvous (ReDiR) [Redir] does not require new functionality from the RELOAD base protocol [RFC6940]. This is possible since ReDiR interacts with the RELOAD Overlay Instance by simply storing and fetching data, that is, using RELOAD Store and Fetch requests. ReDiR creates a tree structure of the service providers of a particular service and stores it into the RELOAD Overlay Instance using the Store and Fetch requests. ReDiR service lookups require a logarithmic number of Fetch operations. Further, if information from past service lookups is used to determine the optimal level in the ReDiR tree from which to start new service lookups, an average service lookup can typically finish after a constant number of Fetch operations, assuming that Node-IDs are distributed uniformly at random.
递归分布式会合（ReDiR）[ReDiR]不需要重新加载基本协议[RFC6940]的新功能。这是可能的，因为ReDiR通过简单地存储和获取数据（即使用RELOAD Store和Fetch请求）与RELOAD Overlay实例交互。ReDiR创建特定服务的服务提供者的树结构，并使用存储和获取请求将其存储到重新加载覆盖实例中。ReDiR服务查找需要对数数量的提取操作。此外，如果使用来自过去服务查找的信息来确定ReDiR树中启动新服务查找的最佳级别，则假设节点ID均匀随机分布，则平均服务查找通常可以在恒定数量的提取操作之后完成。
In ReDiR, each service provided in the overlay is identified by an identifier, called the namespace. All service providers of a given service store their information under the namespace of that service. Peers wishing to use a service perform lookups within the namespace of the service. The result of a ReDiR lookup for an identifier k in namespace ns is a RedirServiceProvider structure (see Section 4.1) of a service provider that belongs to ns and whose Node-ID is the closest successor of identifier k in the namespace.
在ReDiR中，覆盖中提供的每个服务都由一个称为名称空间的标识符标识。给定服务的所有服务提供者都将其信息存储在该服务的命名空间下。希望使用服务的对等方在服务的命名空间内执行查找。对命名空间ns中的标识符k进行ReDiR查找的结果是属于ns且其节点ID是命名空间中标识符k的最近继承者的服务提供程序的RedirServiceProvider结构（请参见第4.1节）。
Each tree node in the ReDiR tree contains a dictionary of RedirServiceProvider entries of peers providing a particular service. Each tree node in the ReDiR tree also belongs to some level in the tree. The root node of the ReDiR tree is located at level 0. The child nodes of the root node are located at level 1 of the ReDiR tree. The children of the tree nodes at level 1 are located at
ReDiR树中的每个树节点都包含提供特定服务的对等方的RedirServiceProvider条目字典。ReDiR树中的每个树节点也属于树中的某个级别。重拨树的根节点位于级别0。根节点的子节点位于ReDiR树的级别1。级别1的树节点的子节点位于
level 2, and so forth. The ReDiR tree has a branching factor, whose value is determined by a new element in the RELOAD overlay configuration document, called branching-factor. The RELOAD overlay configuration document is defined in the RELOAD base protocol [RFC6940]. At every level lvl in the ReDiR tree, there is room for a maximum of branching-factor^lvl tree nodes. As an example, in a tree whose branching-factor is 2, the second level can contain up to four tree nodes (note that a given level may contain less than the maximum number of tree nodes since empty tree nodes are not stored). Each tree node in the ReDiR tree is uniquely identified by a pair (lvl,j), where lvl is a level in the ReDiR tree and j is the position of the tree node (from the left) at that level. As an example, the pair (2,3) identifies the third tree node from the left at level 2.
第二级，等等。ReDiR树有一个分支因子，其值由重载覆盖配置文档中的新元素（称为分支因子）确定。重新加载覆盖配置文档在重新加载基本协议[RFC6940]中定义。在ReDiR树中的每一级lvl上，都有空间容纳最多的分支因子^lvl树节点。例如，在分支因子为2的树中，第二个级别最多可以包含四个树节点（请注意，由于未存储空树节点，因此给定级别可能包含的树节点数小于最大树节点数）。ReDiR树中的每个树节点都由一对（lvl，j）唯一标识，其中lvl是ReDiR树中的一个级别，j是树节点（从左侧）在该级别的位置。例如，该对（2,3）在级别2处标识左侧的第三个树节点。
The ReDiR tree is stored into the RELOAD Overlay Instance tree node by tree node, by storing the values of tree node (level,j) under a key created by taking a hash over the concatenation of the namespace, level, and j, that is, as H(namespace,level,j). As an example, the root of the tree for a voice mail service is stored at H("voice-mail",0,0). Each node (level,j) in the ReDiR tree contains b intervals of the DHT's identifier space as follows:
通过将树节点（level，j）的值存储在通过对名称空间、level和j的串联进行散列而创建的键下，即作为H（名称空间、level，j），将ReDiR树逐树节点存储到重新加载覆盖实例树中。例如，语音邮件服务的树的根存储在H（“语音邮件”，0,0）。ReDiR树中的每个节点（级别j）包含DHT标识符空间的b个间隔，如下所示：
[2^numBitsInNodeId*b^(-level)*(j+(b'/b)), 2^numBitsInNodeId*b^(-level)*(j+((b'+1)/b))), for 0<=b'<b,
[2^Numbitsinodeid*b^（-level）*（j+（b'/b）），2^Numbitsinodeid*b^（-level）*（j+（（b'+1）/b）），用于0<=b'<b，
where b is the branching-factor and b' refers to the number of an interval within the ReDiR tree node j.
其中，b是分支因子，b'是指ReDiR树节点j内的间隔数。
Figure 1 shows an example of a ReDiR tree whose branching factor is 2. In the figure, the size of the identifier space of the overlay is 16. Each tree node in the ReDiR tree is shown as two horizontal lines separated by a vertical bar ('|') in the middle. The horizontal lines represent the two intervals each node is responsible for. At level 0, there is only one node, (0,0), responsible for two intervals that together cover the entire identifier space of the RELOAD Overlay Instance. At level 1, there are two nodes, (1,0) and (1,1), each of which is responsible for half of the identifier space of the RELOAD Overlay Instance. At level 2, there are four nodes. Each of them owns one fourth of the identifier space. At level 3, there are eight nodes, each of which is responsible for one eighth of the identifier space.
图1显示了一个分支因子为2的ReDiR树的示例。在图中，覆盖的标识符空间的大小为16。ReDR树中的每个树节点都显示为两条水平线，中间线由中间的垂直条（′′）分隔。水平线表示每个节点负责的两个间隔。在级别0，只有一个节点（0,0），负责两个时间间隔，这两个时间间隔共同覆盖重载覆盖实例的整个标识符空间。在级别1，有两个节点（1,0）和（1,1），每个节点负责重载覆盖实例的一半标识符空间。在级别2，有四个节点。它们每个都拥有四分之一的标识符空间。在级别3，有八个节点，每个节点负责八分之一的标识符空间。
Level 0 __________________|__________________
| |
Level 1 ________|________ ________|________
| | | |
Level 2 ___|___ ___|___ ___|___ ___|___
| | | | | | | |
Level 3 _|_ _|_ _|_ _|_ _|_ _|_ _|_ _|_
Level 0 __________________|__________________
| |
Level 1 ________|________ ________|________
| | | |
Level 2 ___|___ ___|___ ___|___ ___|___
| | | | | | | |
Level 3 _|_ _|_ _|_ _|_ _|_ _|_ _|_ _|_
Figure 1: ReDiR Tree
图1:ReDiR树
Figure 2 illustrates how tree nodes are numbered in the ReDiR tree at levels 0-2.
图2说明了如何在0-2级的ReDiR树中对树节点进行编号。
Level 0 ________________(0,0)________________
| |
Level 1 ______(1,0)______ ______(1,1)______
| | | |
Level 2 _(2,0)_ _(2,1)_ _(2,2)_ _(2,3)_
| | | | | | | |
Level 3 _|_ _|_ _|_ _|_ _|_ _|_ _|_ _|_
Level 0 ________________(0,0)________________
| |
Level 1 ______(1,0)______ ______(1,1)______
| | | |
Level 2 _(2,0)_ _(2,1)_ _(2,2)_ _(2,3)_
| | | | | | | |
Level 3 _|_ _|_ _|_ _|_ _|_ _|_ _|_ _|_
Figure 2: ReDiR Tree Nodes
图2:ReDiR树节点
Figure 3 illustrates how intervals are assigned to tree nodes in the ReDiR tree at levels 0 and 1. As an example, the single tree node (0,0) at level 0 is divided into two intervals, each of which covers half of the identifier space of the overlay. These two intervals are [0,7] and [8,15].
图3说明了如何将间隔分配给ReDiR树中级别为0和1的树节点。例如，级别0的单个树节点（0,0）被划分为两个间隔，每个间隔覆盖覆盖的标识符空间的一半。这两个区间分别为[0,7]和[8,15]。
Level 0 ______[0,7]_______|_______[8,15]_____
| |
Level 1 _[0,3]__|__[4,7]_ _[8,11]_|_[12,15]
| | | |
Level 2 ___|___ ___|___ ___|___ ___|___
| | | | | | | |
Level 3 _|_ _|_ _|_ _|_ _|_ _|_ _|_ _|_
Level 0 ______[0,7]_______|_______[8,15]_____
| |
Level 1 _[0,3]__|__[4,7]_ _[8,11]_|_[12,15]
| | | |
Level 2 ___|___ ___|___ ___|___ ___|___
| | | | | | | |
Level 3 _|_ _|_ _|_ _|_ _|_ _|_ _|_ _|_
Figure 3: Intervals in ReDiR Tree
图3：ReDiR树中的间隔
Note that all of the examples above are simplified. In a real ReDiR tree, the default ReDiR branching factor is 10, meaning that each tree node is split into 10 intervals and that each tree node has 10 children. In such a tree, level 1 contains 10 nodes and 100 intervals. Level 2 contains 100 nodes and 1000 intervals, level 3 1000 nodes and 10000 intervals, etc. Further, the size of the identifier space of a real RELOAD Overlay Instance is at the minimum 2^128.
请注意，上面的所有示例都已简化。在真实的ReDiR树中，默认的ReDiR分支因子为10，这意味着每个树节点被拆分为10个间隔，并且每个树节点有10个子节点。在这样的树中，级别1包含10个节点和100个间隔。级别2包含100个节点和1000个间隔，级别3包含1000个节点和10000个间隔，等等。此外，实际重载覆盖实例的标识符空间的大小至少为2^128。
ReDiR tree nodes are stored using the dictionary data model defined in the RELOAD base protocol [RFC6940]. The data stored is a RedirServiceProvider Resource Record:
ReDiR树节点使用RELOAD base协议[RFC6940]中定义的字典数据模型存储。存储的数据是RederserviceProvider资源记录：
enum { none(0), (255) }
RedirServiceProviderExtType;
enum { none(0), (255) }
RedirServiceProviderExtType;
struct {
RedirServiceProviderExtType type;
Destination destination_list<0..2^16-1>;
opaque namespace<0..2^16-1>;
uint16 level;
uint16 node;
uint16 length;
struct {
RedirServiceProviderExtType type;
Destination destination_list<0..2^16-1>;
opaque namespace<0..2^16-1>;
uint16 level;
uint16 node;
uint16 length;
select (type) {
/* This type may be extended */
} extension;
select (type) {
/* This type may be extended */
} extension;
} RedirServiceProvider;
}无线电服务提供商；
The contents of the RedirServiceProvider Resource Record are as follows:
RederserviceProvider资源记录的内容如下：
type
类型
The type of an extension to the RedirServiceProvider Resource Record. Unknown types are allowed.
RedirServiceProvider资源记录的扩展的类型。允许使用未知类型。
destination_list
目的地列表
A list of IDs through which a message is to be routed to reach the service provider. The destination list consists of a sequence of Destination values. The contents of the Destination structure are as defined in the RELOAD base protocol [RFC6940].
将消息路由到服务提供商的ID列表。目标列表由一系列目标值组成。目标结构的内容如重新加载基本协议[RFC6940]中所定义。
namespace
名称空间
An opaque UTF-8-encoded string containing the namespace.
包含命名空间的不透明UTF-8编码字符串。
level
数量
The level in the ReDiR tree.
重读树中的级别。
node
节点
The position of the node storing this RedirServiceProvider record at the current level in the ReDiR tree.
在ReDiR树的当前级别上存储此RedirServiceProvider记录的节点的位置。
length
长
The length of the rest of the Resource Record.
资源记录其余部分的长度。
extension
扩大
An extension value. The RedirServiceProvider Resource Record can be extended to include, for instance, information specific to the service or service provider.
扩展值。例如，可以扩展RederserviceProvider资源记录，以包括特定于服务或服务提供商的信息。
Before registering as a service provider or performing a service lookup, a peer needs to determine the starting level Lstart for the registration or lookup operation in the ReDiR tree. It is RECOMMENDED that Lstart is set to 2. This recommendation is based on the findings in [Redir], which indicate that this starting level results in good performance. In subsequent registrations, Lstart MAY, as an optimization, be set to the lowest level at which a registration operation has last completed.
在注册为服务提供商或执行服务查找之前，对等方需要确定ReDiR树中注册或查找操作的起始级别Lstart。建议将Lstart设置为2。本建议基于[Redir]中的调查结果，该调查结果表明，该起始水平会产生良好的绩效。在随后的注册中，作为优化，可以将Lstart设置为上次完成注册操作的最低级别。
In the case of subsequent service lookups, nodes MAY, as an optimization, record the levels at which the last 16 service lookups completed and take Lstart to be the mode of those depths (mode, in statistics, is the value that appears most often in a set of data).
在后续服务查找的情况下，作为优化，节点可以记录最后16个服务查找完成的级别，并将Lstart作为这些深度的模式（统计中，模式是一组数据中最常出现的值）。
A node MUST use the following procedure to register as a service provider in the RELOAD Overlay Instance:
节点必须使用以下过程在重新加载覆盖实例中注册为服务提供商：
1. A node n with Node-ID n.id wishing to register as a service provider starts from a starting level Lstart (see Section 4.2 for the details on selecting the starting level). Therefore, node n sets the current level to level=Lstart.
1. 节点ID为n.ID的节点n希望注册为服务提供商，从起始级别Lstart开始（有关选择起始级别的详细信息，请参阅第4.2节）。因此，节点n将当前级别设置为level=Lstart。
2. Node n MUST send a RELOAD Fetch request to fetch the contents of the tree node responsible for I(level,n.id). An interval I(l,k) is the interval at level l in the ReDiR tree that includes key k. The fetch MUST be a wildcard fetch.
2. 节点n必须发送重新加载获取请求，以获取负责I（级别，n.id）的树节点的内容。间隔I（l，k）是包含键k的ReDiR树中级别l的间隔。提取必须是通配符提取。
3. Node n MUST send a RELOAD Store request to add its RedirServiceProvider entry to the dictionary stored in the tree node responsible for I(level,n.id). Note that node n always stores its RedirServiceProvider entry, regardless of the contents of the dictionary.
3. 节点n必须发送重新加载存储请求，以将其RederserviceProvider条目添加到负责I（级别，n.id）的树节点中存储的字典中。请注意，节点n始终存储其RederserviceProvider条目，而不管字典的内容如何。
4. If node n's Node-ID (n.id) is the lowest or highest Node-ID stored in the tree node responsible for I(Lstart,n.id), node n MUST reduce the current level by one (i.e., set level=level-1) and continue up the ReDiR tree towards the root level (level 0), repeating steps 2 and 3 above. Node n MUST continue in this way until it reaches either the root of the tree or a level at which n.id is not the lowest or highest Node-ID in the interval I(level,n.id).
4. 如果节点n的节点ID（n.ID）是负责I的树节点（Lstart，n.ID）中存储的最低或最高节点ID，则节点n必须将当前级别降低一（即，设置级别=级别-1），并继续向根级别（级别0）的ReDiR树上移动，重复上述步骤2和3。节点n必须以这种方式继续，直到它到达树的根或n.id不是间隔I（级别，n.id）中的最低或最高节点id的级别。
5. Node n MUST also perform a downward walk in the ReDiR tree, during which it goes through the tree nodes responsible for intervals I(Lstart,n.id), I(Lstart+1,n.id), I(Lstart+2,n.id), etc. At each step, node n MUST fetch the responsible tree node and store its RedirServiceProvider record in that tree node if n.id is the lowest or highest Node-ID in its interval. Node n MUST end this downward walk as soon as it reaches a level l at which it is the only service provider in its interval I(l,n.id).
5. 节点n还必须在ReDiR树中执行向下行走，在此期间，它在每个步骤中穿过负责间隔I（Lstart，n.id）、I（Lstart+1，n.id）、I（Lstart+2，n.id）等的树节点，如果n.id是其间隔中的最低或最高节点id，则节点n必须获取负责的树节点，并将其RedirServiceProvider记录存储在该树节点中。节点n必须在达到其间隔I（l，n.id）中的唯一服务提供者的级别l时结束此向下行走。
Note that above, when we refer to 'the tree node responsible for I(l,k)', we mean the entire tree node (that is, all the intervals within the tree node) responsible for interval I(l,k). In contrast, I(l,k) refers to a specific interval within a tree node.
请注意，上面提到的“负责I（l，k）的树节点”是指负责间隔I（l，k）的整个树节点（即树节点内的所有间隔）。相反，I（l，k）表示树节点内的特定间隔。
All state in the ReDiR tree is soft. Therefore, a service provider needs to periodically repeat the registration process to refresh its RedirServiceProvider Resource Record. If a record expires, it MUST be dropped from the dictionary by the peer storing the tree node. Deciding an appropriate lifetime for the RedirServiceProvider Resource Records is up to each service provider. However, a default value of 10 minutes is RECOMMENDED as this is a good trade-off between keeping the amount of ReDiR traffic in the overlay at a reasonable level and ensuring that stale information is removed quickly enough. Every service provider MUST repeat the entire registration process periodically until it leaves the RELOAD Overlay Instance. The service provider SHOULD initiate each refresh process slightly earlier (e.g., when 90% of the refresh interval has passed) than the expiry time of the Resource Record.
ReDiR树中的所有状态都是软状态。因此，服务提供商需要定期重复注册过程以刷新其RederserviceProvider资源记录。如果记录过期，则存储树节点的对等方必须将其从字典中删除。由每个服务提供商决定RedirServiceProvider资源记录的适当生存期。但是，建议使用默认值10分钟，因为这是将覆盖中的重拨通信量保持在合理水平和确保足够快地删除过时信息之间的一个很好的权衡。每个服务提供商必须定期重复整个注册过程，直到它离开重新加载覆盖实例。服务提供商应在资源记录到期时间之前（例如，当90%的刷新间隔已过）启动每个刷新过程。
Note that no new mechanisms are needed to keep track of the remaining lifetime of RedirServiceProvider records. The 'storage_time' and 'lifetime' fields of RELOAD's StoredData structure can be used for this purpose in the usual way.
请注意，不需要新的机制来跟踪RederserviceProvider记录的剩余生存期。RELOAD的StoredData结构的“存储时间”和“生存期”字段可按常规方式用于此目的。
The purpose of a service lookup for identifier k in namespace ns is to find the node that is a part of ns and whose identifier most immediately follows (i.e., is the closest successor of) the identifier k.
命名空间ns中标识符k的服务查找的目的是查找属于ns的一部分且其标识符紧跟在标识符k之后（即，是标识符k最接近的后续者）的节点。
A service lookup operation resembles the service registration operation described in Section 4.3. Service lookups start from a given starting level level=Lstart in the ReDiR tree (see Section 4.2 for the details on selecting the starting level). At each step, a node n wishing to discover a service provider MUST fetch the tree node responsible for the interval I(level,n.id) that encloses the search key n.id at the current level using a RELOAD Fetch request. Having fetched the tree node, node n MUST determine the next action to carry out as follows:
服务查找操作类似于第4.3节中描述的服务注册操作。服务查找从ReDiR树中给定的起始级别开始=L起始（有关选择起始级别的详细信息，请参阅第4.2节）。在每个步骤中，希望发现服务提供者的节点n必须使用重新加载获取请求获取负责间隔I（级别，n.id）的树节点，该间隔I包含当前级别的搜索键n.id。获取树节点后，节点n必须确定要执行的下一个操作，如下所示：
Condition 1
条件1
If there is no successor of node n present in the just-fetched ReDiR tree node (note: within the entire tree node and not only within the current interval) responsible for I(level,n.id), then the successor of node n must be present in a larger segment of the identifier space (i.e., further up in the ReDiR tree where each interval and tree node covers a larger range of the identifier space). Therefore, node n MUST reduce the current level by one to level=level-1 and carry out a new Fetch operation for the tree node responsible for n.id at that level. The fetched tree node is then analyzed and the next action determined by checking Conditions 1-3.
如果在刚刚获取的ReDiR树节点（注意：在整个树节点内，而不仅仅是在当前间隔内）中没有负责I（级别，n.id）的节点n的后续节点，则节点n的后续节点必须存在于标识符空间的较大段中（即，在ReDiR树的更上层，其中每个间隔和树节点覆盖更大范围的标识符空间）。因此，节点n必须将当前级别降低一到级别=级别1，并对负责该级别n.id的树节点执行新的提取操作。然后分析提取的树节点，并通过检查条件1-3确定下一个操作。
Condition 2
条件2
If n.id is neither the lowest nor the highest Node-ID within the interval (note: within the interval, not within the entire tree node) I(level,n.id), n MUST next check the tree node responsible for n.id at the next level down the tree. Thus, node n MUST increase the level by one to level=level+1 and carry out a new Fetch operation at that level. The fetched tree node is then analyzed and the next action determined by checking the conditions listed here, starting at Condition 1.
如果n.id既不是间隔（注意：在间隔内，而不是整个树节点）I（级别，n.id）内的最低节点id，也不是最高节点id，则n必须在树的下一级别检查负责n.id的树节点。因此，节点n必须将级别增加1到level=level+1，并在该级别执行新的获取操作。然后，通过检查此处列出的条件（从条件1开始），分析获取的树节点并确定下一个操作。
Condition 3
条件3
If neither of the conditions above holds, meaning that there is a successor s of n.id present in the just-fetched ReDiR tree node and n.id is the highest or lowest Node-ID in its interval, the service lookup has finished successfully, and s must be the closest successor of n.id in the ReDiR tree.
如果上述两个条件均不成立，即在刚获取的ReDiR树节点中存在n.id的后续节点s，且n.id是其间隔内的最高或最低节点id，则服务查找已成功完成，且s必须是ReDiR树中n.id的最近后续节点。
Note that above, when we refer to 'the tree node responsible for interval I(l,k)', we mean the entire tree node (that is, all the intervals within the tree node) responsible for interval I(l,k). In contrast, I(l,k) refers to a specific interval within a tree node.
请注意，上面提到的“负责区间I（l，k）的树节点”是指负责区间I（l，k）的整个树节点（即树节点内的所有区间）。相反，I（l，k）表示树节点内的特定间隔。
Note also that there may be some cases in which no successor can be found from the ReDiR tree. An example is a situation in which all of the service providers stored in the ReDiR tree have a Node-ID smaller than identifier k. In this case, the upward walk of the service lookup will reach the root of the tree without encountering a successor. An appropriate strategy in this case is to pick one of the RedirServiceProvider entries stored in the dictionary of the root node at random.
还请注意，在某些情况下，可能无法从ReDiR树中找到后续项。一个示例是这样一种情况，其中存储在ReDiR树中的所有服务提供商的节点ID都小于标识符k。在这种情况下，服务查找的向上移动将到达树的根，而不会遇到后续路径。在这种情况下，适当的策略是随机选取根节点字典中存储的一个RederserviceProvider条目。
Since RedirServiceProvider records are expiring and registrations are being refreshed periodically, there can be certain rare situations in which a service lookup may fail even if there is a valid successor present in the ReDiR tree. An example is a case in which a ReDiR tree node is fetched just after a RedirServiceProvider entry of the only successor of k present in the tree node has expired and just before a Store request that has been sent to refresh the entry reaches the peer storing the tree node. In this rather unlikely scenario, the successor that should have been present in the tree node is temporarily missing. Thus, the service lookup will fail and needs to be carried out again.
由于RedirServiceProvider记录将过期，并且注册将定期刷新，因此可能会出现某些罕见的情况，即即使ReDiR树中存在有效的后续记录，服务查找也可能失败。一个示例是这样一种情况，即在树节点中存在的k的唯一后继项的RedirServiceProvider条目过期之后，并且在发送刷新条目的存储请求到达存储树节点的对等方之前，提取ReDiR树节点。在这种不太可能的情况下，本应存在于树节点中的后续节点将暂时丢失。因此，服务查找将失败，需要再次执行。
To recover from the kinds of situations described above, a ReDiR implementation MAY choose to use the optimization described next. The ReDiR implementation MAY implement a local temporary cache that is maintained for the duration of a service lookup operation in a RELOAD node. The temporary cache is used to store all RedirServiceProvider entries that have been fetched during the upward and downward walks of a service lookup operation. Should it happen that a service lookup operation fails due to the downward walk reaching a level that does not contain a successor, the cache is searched for successors of the search key. If there are successors present in the cache, the closest one of them is selected as the service provider.
要从上述各种情况中恢复，ReDiR实现可以选择使用下面描述的优化。ReDiR实现可以实现在重新加载节点中的服务查找操作期间维护的本地临时缓存。临时缓存用于存储在服务查找操作的向上和向下移动过程中获取的所有RederserviceProvider条目。如果服务查找操作因向下移动达到不包含后续项的级别而失败，则将在缓存中搜索搜索搜索键的后续项。如果缓存中存在后续服务器，则选择其中最近的一个作为服务提供程序。
Before leaving the RELOAD Overlay Instance, a service provider SHOULD remove the RedirServiceProvider records it has stored by storing exists=False values in their place, as described in [RFC6940].
在离开RELOAD Overlay实例之前，服务提供商应通过将exists=False值存储在RedirServiceProvider记录的位置来删除它存储的RedirServiceProvider记录，如[RFC6940]中所述。
As specified in the RELOAD base protocol [RFC6940], every Kind that is storable in an overlay must be associated with an access control policy. This policy defines whether a request from a given node to operate on a given value should succeed or fail. Usages can define any access control rules they choose, including publicly writable values.
正如重新加载基本协议[RFC6940]中所规定的那样，覆盖中可存储的每种类型都必须与访问控制策略相关联。此策略定义来自给定节点的对给定值进行操作的请求是成功还是失败。用法可以定义他们选择的任何访问控制规则，包括可公开写入的值。
ReDiR requires an access control policy that allows multiple nodes in the overlay read and write access to the ReDiR tree nodes stored in the overlay. Therefore, none of the access control policies specified in the RELOAD base protocol [RFC6940] is sufficient.
ReDiR需要访问控制策略，该策略允许覆盖中的多个节点对存储在覆盖中的ReDiR树节点进行读写访问。因此，在重新加载基本协议[RFC6940]中指定的访问控制策略都不够。
This document defines a new access control policy, called NODE-ID-MATCH. In this policy, a given value MUST be written and overwritten only if the request is signed with a key associated with a certificate whose Node-ID is equal to the dictionary key. In addition, provided that exists=True, the Node-ID MUST belong to one of the intervals associated with the tree node (the number of intervals each tree node has is determined by the branching-factor parameter). Finally, provided that exists=True, H(namespace,level,node), where namespace, level, and node are taken from the RedirServiceProvider structure being stored, MUST be equal to the Resource-ID for the resource. The NODE-ID-MATCH policy may only be used with dictionary types.
本文档定义了一个新的访问控制策略，称为NODE-ID-MATCH。在此策略中，只有当请求使用与节点ID等于字典密钥的证书相关联的密钥签名时，才能写入和覆盖给定值。此外，如果exists=True，则节点ID必须属于与树节点关联的间隔之一（每个树节点的间隔数由分支因子参数确定）。最后，如果exists=True，则从存储的RedirServiceProvider结构中获取名称空间、级别和节点的H（名称空间、级别、节点）必须等于资源的资源ID。NODE-ID-MATCH策略只能与字典类型一起使用。
This section defines the REDIR Kind.
本节定义了重读类型。
Name
名称
REDIR
重读
Kind-ID
种类ID
The Resource Name for the REDIR Kind-ID is created by concatenating three pieces of information: namespace, level, and node number. Namespace is an opaque UTF-8-encoded string identifying a service, such as 'turn-server'. Level is an integer specifying a level in the ReDiR tree. Node number is an integer
REDIR种类ID的资源名称是通过连接三条信息创建的：名称空间、级别和节点号。名称空间是一个不透明的UTF-8编码字符串，用于标识服务，例如“turn server”。级别是一个整数，用于指定重读树中的级别。节点号是一个整数
identifying a ReDiR tree node at a specific level. The data stored is a RedirServiceProvider structure, as defined in Section 4.1.
标识特定级别上的ReDiR树节点。存储的数据是第4.1节中定义的RederserviceProvider结构。
Data Model
数据模型
The data model for the REDIR Kind-ID is dictionary. The dictionary key is the Node-ID of the service provider.
REDIR种类ID的数据模型为dictionary。字典键是服务提供者的节点ID。
Access Control
访问控制
The access control policy for the REDIR Kind is the NODE-ID-MATCH policy that was defined in Section 5.
REDIR类型的访问控制策略是第5节中定义的NODE-ID-MATCH策略。
Figure 4 shows an example of a ReDiR tree containing information about four different service providers whose Node-IDs are 2, 3, 4, and 7. In the example, numBitsInNodeId=4. Initially, the ReDiR tree is empty; Figure 4 shows the state of the tree at the point when all the service providers have registered.
图4显示了一个ReDiR树的示例，其中包含关于四个不同服务提供商的信息，这些提供商的节点ID分别为2、3、4和7。在本例中，numBitsInNodeId=4。最初，ReDiR树是空的；图4显示了所有服务提供者注册时树的状态。
Level 0 ____2_3___4_____7_|__________________
| |
Level 1 ____2_3_|_4_____7 ________|________
| | | |
Level 2 ___|2_3 4__|__7 ___|___ ___|___
| | | | | | | |
Level 3 _|_ _|3 _|_ _|_ _|_ _|_ _|_ _|_
Level 0 ____2_3___4_____7_|__________________
| |
Level 1 ____2_3_|_4_____7 ________|________
| | | |
Level 2 ___|2_3 4__|__7 ___|___ ___|___
| | | | | | | |
Level 3 _|_ _|3 _|_ _|_ _|_ _|_ _|_ _|_
Figure 4: Example of a ReDiR Tree
图4：ReDiR树的示例
First, peer 2 whose Node-ID is 2 joins the namespace. Since this is the first registration peer 2 performs, peer 2 sets the starting level Lstart to 2, as was described in Section 4.2. Also, all other peers in this example will start from level 2. First, peer 2 fetches the contents of the tree node associated with interval I(2,2) from the RELOAD Overlay Instance. This tree node is the first tree node from the left at level 2 since key 2 is associated with the second interval of the first tree node. Peer 2 also stores its RedirServiceProvider record in that tree node. Since peer 2's Node-ID is the only Node-ID stored in the tree node (i.e., peer 2's Node-ID fulfills the condition in Section 4.3 that it be the numerically lowest or highest among the keys stored in the node), peer 2 continues up the tree. In fact, peer 2 continues up in the tree all the way to the root inserting its own Node-ID in all levels since the
首先，节点ID为2的对等方2加入命名空间。由于这是对等机2执行的第一次注册，对等机2将起始级别Lstart设置为2，如第4.2节所述。此外，本例中的所有其他对等方将从级别2开始。首先，对等节点2从重载覆盖实例获取与间隔I（2,2）关联的树节点的内容。此树节点是级别2左侧的第一个树节点，因为键2与第一个树节点的第二个间隔相关联。对等方2还将其RederserviceProvider记录存储在该树节点中。由于对等方2的节点ID是存储在树节点中的唯一节点ID（即，对等方2的节点ID满足第4.3节中的条件，即它是存储在节点中的密钥中数值最低或最高的），因此对等方2继续在树上运行。事实上，对等节点2在树中一直向上延伸到根节点，在自
tree is empty (which means that peer 2's Node-ID always fulfills the condition that it be the numerically lowest or highest Node-ID in the interval I(level, 2) during the upward walk). As described in Section 4.3, peer 2 also walks down the tree. The downward walk peer 2 does ends at level 2 since peer 2 is the only node in its interval at that level.
树为空（这意味着对等节点2的节点ID始终满足以下条件：在向上行走期间，它是间隔I（级别2）中数值最低或最高的节点ID）。如第4.3节所述，同伴2也会沿着树走下去。向下行走的对等点2在级别2结束，因为对等点2是该级别间隔中的唯一节点。
The next peer to join the namespace is peer 3, whose Node-ID is 3. Peer 3 starts from level 2. At that level, peer 3 stores its RedirServiceProvider entry in the same interval I(2,3) that already contains the RedirServiceProvider entry of peer 2. Interval I(2,3), that is, the interval at level 2 enclosing key 3, is associated with the right-hand-side interval of the first tree node. Since peer 3 has the numerically highest Node-ID in the tree node associated with I(2,3), peer 3 continues up the tree. Peer 3 also stores its RedirServiceProvider record at levels 1 and 0 since its Node-ID is numerically highest among the Node-IDs stored in the intervals to which its own Node-ID belongs. Peer 3 also does a downward walk that starts from level 2 (i.e., the starting level). Since peer 3 is not the only node in interval I(2,3), it continues down the tree to level 3. The downward walk ends at this level since peer 3 is the only service provider in the interval I(3,3).
加入命名空间的下一个对等方是对等方3，其节点ID为3。同伴3从2级开始。在该级别，对等方3将其RedirServiceProvider条目存储在已包含对等方2的RedirServiceProvider条目的相同间隔I（2,3）中。区间I（2,3），即包含键3的级别2的区间，与第一个树节点的右侧区间相关联。由于对等方3在与I（2,3）关联的树节点中具有数字上最高的节点ID，因此对等方3继续向树上移动。对等方3还将其RedirServiceProvider记录存储在级别1和0，因为其节点ID在其自身节点ID所属的时间间隔内存储的节点ID中数值最高。同伴3也从第2层（即起始层）开始向下行走。由于对等节点3不是间隔I（2,3）中的唯一节点，因此它继续沿着树向下到第3级。由于对等方3是间隔I（3,3）中唯一的服务提供商，因此向下行走在此级别结束。
The third peer to join the namespace is peer 7, whose Node-ID is 7. Like the two earlier peers, peer 7 also starts from level 2 because this is the first registration it performs. Peer 7 stores its RedirServiceProvider record at level 2. At level 1, peer 7 has the numerically highest (and lowest) Node-ID in its interval I(1,7) (because it is the only node in interval I(1,7); peers 2 and 3 are stored in the same tree node but in a different interval), and therefore, it stores its Node-ID in the tree node associated with that interval. Peer 7 also has the numerically highest Node-ID in the interval I(0,7) associated with its Node-ID at level 0. Finally, peer 7 performs a downward walk, which ends at level 2 because peer 7 is the only node in its interval at that level.
加入命名空间的第三个对等方是对等方7，其节点ID为7。与前面的两个对等点一样，对等点7也从级别2开始，因为这是它执行的第一次注册。对等方7将其RederserviceProvider记录存储在级别2。在级别1，对等方7在其间隔I（1,7）中具有数字上最高（和最低）的节点ID（因为它是间隔I（1,7）中的唯一节点；对等方2和3存储在同一树节点中，但在不同的间隔中），因此，它将其节点ID存储在与该间隔关联的树节点中。对等方7在与其级别0处的节点ID相关联的间隔I（0,7）中也具有数字上最高的节点ID。最后，对等点7执行向下行走，该行走在级别2结束，因为对等点7是该级别间隔中的唯一节点。
The final peer to join the ReDiR tree is peer 4, whose Node-ID is 4. Peer 4 starts by storing its RedirServiceProvider record at level 2. Since it has the numerically lowest Node-ID in the tree node associated with interval I(2,4), it continues up in the tree to level 1. At level 1, peer 4 stores its record in the tree node associated with interval I(1,4) because it has the numerically lowest Node-ID in that interval. Next, peer 4 continues to the root level, at which it stores its RedirServiceProvider record and finishes the upward walk since the root level was reached. Peer 4 also does a downward walk starting from level 2. The downward walk stops at level 2 because peer 4 is the only peer in the interval I(2,4).
加入ReDiR树的最后一个对等方是对等方4，其节点ID为4。对等方4首先将其RederserviceProvider记录存储在级别2。由于它在与间隔I（2,4）相关联的树节点中具有数值最低的节点ID，因此它在树中继续向上到级别1。在级别1，对等方4将其记录存储在与间隔I（1,4）相关联的树节点中，因为它在该间隔中具有数值最低的节点ID。接下来，对等方4继续到根级别，在该级别存储其RederserviceProvider记录，并完成自到达根级别以来的向上行走。同伴4也从第2层开始向下行走。向下行走在第2层停止，因为对等点4是间隔I（2,4）中唯一的对等点。
This subsection gives an example of peer 5 whose Node-ID is 5 performing a service lookup operation in the ReDiR tree shown in Figure 4. This is the first service lookup peer 5 carries out, and thus, the service lookup starts from the default starting level 2. As the first action, peer 5 fetches the tree node corresponding to the interval I(2,5) from the starting level. This interval maps to the second tree node from the left at level 2 since that tree node is responsible for the interval (third interval from left) to which Node-ID 5 falls at level 2. Having fetched the tree node, peer 5 checks its contents. First, there is a successor, peer 7, present in the tree node. Therefore, Condition 1 of Section 4.5 is false, and there is no need to perform an upward walk. Second, Node-ID 5 is the highest Node-ID in its interval, so Condition 2 of Section 4.5 is also false, and there is no need to perform a downward walk. Thus, the service lookup finishes at level 2 since Node-ID 7 is the closest successor of peer 5.
本小节给出了节点ID为5的对等方5在图4所示的ReDiR树中执行服务查找操作的示例。这是对等方5执行的第一次服务查找，因此，服务查找从默认的起始级别2开始。作为第一个操作，对等方5从起始级别获取与间隔I（2,5）对应的树节点。此间隔映射到级别2左侧的第二个树节点，因为该树节点负责节点ID 5位于级别2的间隔（左侧的第三个间隔）。获取树节点后，对等节点5检查其内容。首先，树节点中存在一个后继节点，对等节点7。因此，第4.5节的条件1为假，无需执行向上行走。其次，节点ID 5是其间隔内的最高节点ID，因此第4.5节的条件2也是错误的，并且不需要执行向下行走。因此，服务查找在级别2完成，因为节点ID 7是对等节点5的最接近的后续节点。
Note that the service lookup procedure would be slightly different if peer 5 used level 3 as the starting level. Peer 5 might use this starting level, for instance, if it has already carried out service lookups in the past and follows the heuristic in Section 4.2 to select the starting level. In this case, peer 5's first action is to fetch the tree node at level 3 that is responsible for I(3,5). Thus, peer 5 fetches the third tree node from the left. Since this tree node is empty, peer 5 decreases the current level by one to 2 and thus continues up in the tree. The next action peer 5 performs is identical to the single action in the previous example of fetching the node associated with I(2,5) from level 2. Thus, the service lookup finishes at level 2.
请注意，如果对等方5使用级别3作为起始级别，则服务查找过程将略有不同。例如，如果对等方5在过去已经执行了服务查找，并且遵循第4.2节中的启发式选择起始级别，则对等方5可能会使用此起始级别。在这种情况下，对等方5的第一个操作是获取负责I（3,5）的3级树节点。因此，对等节点5从左侧获取第三个树节点。由于该树节点为空，对等节点5将当前级别降低1到2，从而在树中继续向上。对等方5执行的下一个操作与前一个示例中从级别2获取与I（2,5）关联的节点的单个操作相同。因此，服务查找在第2级完成。
This document extends the RELOAD overlay configuration document defined in the RELOAD base protocol specification [RFC6940] by adding a new element, "branching-factor", inside the new "REDIR" kind element:
本文档扩展了重新加载基本协议规范[RFC6940]中定义的重新加载覆盖配置文档，在新的“REDIR”类元素中添加了一个新元素“分支因子”：
redir:branching-factor: The branching factor of the ReDiR tree. The default value is 10.
redir：分支因子：redir树的分支因子。默认值为10。
The RELAX NG grammar for this element is:
此元素的RELAX NG语法为：
namespace redir = "urn:ietf:params:xml:ns:p2p:redir"
namespace redir = "urn:ietf:params:xml:ns:p2p:redir"
parameter &= element redir:branching-factor { xsd:unsignedInt }?
parameter &= element redir:branching-factor { xsd:unsignedInt }?
The 'redir' namespace is added into the <mandatory-extension> element in the overlay configuration file.
“redir”命名空间被添加到覆盖配置文件中的<mandatory extension>元素中。
This document defines a new access control policy called NODE-ID-MATCH (see Section 5) whose purpose is to control which nodes in the overlay are allowed read and write access to the ReDiR tree nodes. The NODE-ID-MATCH access control policy ensures that the only node in the overlay that can store a pointer to a specific service provider in the ReDiR tree is the service provider itself. This prevents attacks where a malicious node inserts pointers to other nodes in the ReDiR tree. Further, the NODE-ID-MATCH access control policy ensures that a node can only store information in locations in the ReDiR tree where it is entitled to do so. In other words, a node can only store one RedirServiceProvider record at any given level in the ReDiR tree. This prevents an attack where a malicious node is trying to insert a high number of pointers to the ReDiR tree.
本文档定义了一个名为NODE-ID-MATCH（参见第5节）的新访问控制策略，其目的是控制覆盖中的哪些节点允许对ReDiR树节点进行读写访问。NODE-ID-MATCH访问控制策略确保覆盖中唯一可以在ReDiR树中存储指向特定服务提供商的指针的节点是服务提供商本身。这可以防止恶意节点插入指向ReDiR树中其他节点的指针的攻击。此外，NODE-ID-MATCH访问控制策略确保节点只能在其有权这样做的ReDiR树中的位置存储信息。换句话说，节点只能在ReDiR树中的任何给定级别存储一条RedirServiceProvider记录。这可以防止恶意节点试图向ReDiR树插入大量指针的攻击。
When it comes to attacks such as a malicious node refusing to store a value or denying knowledge of a value it has previously accepted, such security concerns are already discussed in the RELOAD base specification [RFC6940].
当涉及到诸如恶意节点拒绝存储值或拒绝知道其先前接受的值等攻击时，此类安全问题已在重新加载基础规范[RFC6940]中讨论过。
This document adds a new access control policy to the "RELOAD Access Control Policies" registry:
本文档向“重新加载访问控制策略”注册表添加了一个新的访问控制策略：
NODE-ID-MATCH
节点ID匹配
This access control policy was described in Section 5.
第5节描述了该访问控制策略。
This document registers one new URI for the 'redir' namespace in the "IETF XML Registry" defined in [RFC3688].
本文档在[RFC3688]中定义的“IETF XML注册表”中为“redir”命名空间注册了一个新URI。
URI: urn:ietf:params:xml:ns:p2p:redir
URI: urn:ietf:params:xml:ns:p2p:redir
Registrant Contact: The IESG
注册联系人：IESG
XML: N/A, the requested URI is an XML namespace
XML:N/A，请求的URI是一个XML名称空间
This document adds one new data Kind-ID to the "RELOAD Data Kind-ID" registry:
本文档向“重新加载数据种类ID”注册表添加一个新的数据种类ID：
+--------------+------------+-----------+
| Kind | Kind-ID | RFC |
+--------------+------------+-----------+
| REDIR | 0x104 | [RFC7374] |
+--------------+------------+-----------+
+--------------+------------+-----------+
| Kind | Kind-ID | RFC |
+--------------+------------+-----------+
| REDIR | 0x104 | [RFC7374] |
+--------------+------------+-----------+
This Kind-ID was defined in Section 6.
第6节定义了此类ID。
IANA has created a new registry for ReDiR namespaces:
IANA已为ReDiR命名空间创建了一个新的注册表：
Registry Name: RELOAD Services Registry
注册表名称：重新加载服务注册表
Reference: [RFC7374]
参考文献：[RFC7374]
Registration Procedure: Specification Required
注册程序：需要说明
Entries in this registry are strings denoting ReDiR namespace values. The initial contents of this registry are:
此注册表中的项是表示ReDiR命名空间值的字符串。此注册表的初始内容包括：
+----------------+-----------+
| Namespace | RFC |
+----------------+-----------+
| turn-server | [RFC7374] |
+----------------+-----------+
| voice-mail | [RFC7374] |
+----------------+-----------+
+----------------+-----------+
| Namespace | RFC |
+----------------+-----------+
| turn-server | [RFC7374] |
+----------------+-----------+
| voice-mail | [RFC7374] |
+----------------+-----------+
The namespace 'turn-server' is used by nodes that wish to register as providers of a TURN relay service in the RELOAD overlay and by nodes that wish to discover providers of a TURN relay service from the RELOAD overlay. In the TURN server discovery use case, the ReDiR-based service discovery and registration mechanism specified in this document can be used as an alternative to the TURN server discovery mechanism specified in the RELOAD base specification [RFC6940]. The namespace 'voice-mail' is intended for a voice mail service implemented on top of a RELOAD overlay.
命名空间“turn server”由希望在重新加载覆盖中注册为turn中继服务提供者的节点使用，也由希望从重新加载覆盖中发现turn中继服务提供者的节点使用。在TURN server discovery用例中，本文档中指定的基于ReDiR的服务发现和注册机制可以用作RELOAD base规范[RFC6940]中指定的TURN server discovery机制的替代方案。名称空间“语音邮件”用于在重新加载覆盖上实现的语音邮件服务。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001, <http://www.rfc-editor.org/info/rfc3174>.
[RFC3174]Eastlake，D.和P.Jones，“美国安全哈希算法1（SHA1）”，RFC 31742001年9月<http://www.rfc-editor.org/info/rfc3174>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月<http://www.rfc-editor.org/info/rfc3629>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004, <http://www.rfc-editor.org/info/rfc3688>.
[RFC3688]Mealling，M.“IETF XML注册表”，BCP 81，RFC 3688，2004年1月<http://www.rfc-editor.org/info/rfc3688>.
[RFC6940] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", RFC 6940, January 2014, <http://www.rfc-editor.org/info/rfc6940>.
[RFC6940]Jennings，C.，Lowekamp，B.，Rescorla，E.，Baset，S.，和H.Schulzrinne，“资源定位和发现（重新加载）基本协议”，RFC 69402014年1月<http://www.rfc-editor.org/info/rfc6940>.
[Redir] Rhea, S., Godfrey, B., Karp, B., Kubiatowicz, J., Ratnasamy, S., Shenker, S., Stoica, I., and H. Yu, "OpenDHT: A Public DHT Service and Its Uses", October 2005.
[Redir]Rhea，S.，Godfrey，B.，Karp，B.，Kubiatowicz，J.，Ratnasamy，S.，Shenker，S.，Stoica，I.，和H.Yu，“OpenDHT：公共DHT服务及其使用”，2005年10月。
Acknowledgments
致谢
The authors would like to thank Marc Petit-Huguenin, Joscha Schneider, Carlos Bernardos, Spencer Dawkins, Barry Leiba, Adrian Farrel, Alexey Melnikov, Ted Lemon, and Stephen Farrell for their comments on the document.
作者感谢Marc Petit Hugunin、Joscha Schneider、Carlos Bernardos、Spencer Dawkins、Barry Leiba、Adrian Farrel、Alexey Melnikov、Ted Lemon和Stephen Farrell对该文件的评论。
Authors' Addresses
作者地址
Jouni Maenpaa Ericsson Hirsalantie 11 Jorvas 02420 Finland
Jouni Maenpaa Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: Jouni.Maenpaa@ericsson.com
EMail: Jouni.Maenpaa@ericsson.com
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: Gonzalo.Camarillo@ericsson.com
EMail: Gonzalo.Camarillo@ericsson.com