draft-ietf-p2psip-service-discovery-08.txt   draft-ietf-p2psip-service-discovery-09.txt 
P2PSIP Working Group J. Maenpaa P2PSIP Working Group J. Maenpaa
Internet-Draft G. Camarillo Internet-Draft G. Camarillo
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: August 27, 2013 February 23, 2013 Expires: February 06, 2014 August 05, 2013
Service Discovery Usage for REsource LOcation And Discovery (RELOAD) Service Discovery Usage for REsource LOcation And Discovery (RELOAD)
draft-ietf-p2psip-service-discovery-08.txt draft-ietf-p2psip-service-discovery-09.txt
Abstract Abstract
REsource LOcation and Discovery (RELOAD) does not define a generic REsource LOcation and Discovery (RELOAD) does not define a generic
service discovery mechanism as a part of the base protocol. This service discovery mechanism as a part of the base protocol. This
document defines how the Recursive Distributed Rendezvous (ReDiR) document defines how the Recursive Distributed Rendezvous (ReDiR)
service discovery mechanism used in OpenDHT can be applied to RELOAD service discovery mechanism used in OpenDHT can be applied to RELOAD
overlays to provide a generic service discovery mechanism. overlays to provide a generic service discovery mechanism.
Status of this Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 27, 2013. This Internet-Draft will expire on February 06, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Introduction to ReDiR . . . . . . . . . . . . . . . . . . . . 4 3. Introduction to ReDiR . . . . . . . . . . . . . . . . . . . . 4
4. Using ReDiR in a RELOAD Overlay Instance . . . . . . . . . . . 7 4. Using ReDiR in a RELOAD Overlay Instance . . . . . . . . . . 7
4.1. Data Structure . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Data Structure . . . . . . . . . . . . . . . . . . . . . 7
4.2. Selecting the Starting Level . . . . . . . . . . . . . . . 8 4.2. Selecting the Starting Level . . . . . . . . . . . . . . 8
4.3. Service Provider Registration . . . . . . . . . . . . . . 9 4.3. Service Provider Registration . . . . . . . . . . . . . . 8
4.4. Refreshing Registrations . . . . . . . . . . . . . . . . . 9 4.4. Refreshing Registrations . . . . . . . . . . . . . . . . 9
4.5. Service Lookups . . . . . . . . . . . . . . . . . . . . . 10 4.5. Service Lookups . . . . . . . . . . . . . . . . . . . . . 10
4.6. Removing Registrations . . . . . . . . . . . . . . . . . . 11 4.6. Removing Registrations . . . . . . . . . . . . . . . . . 11
5. Access Control Rules . . . . . . . . . . . . . . . . . . . . . 12 5. Access Control Rules . . . . . . . . . . . . . . . . . . . . 11
6. REDIR Kind Definition . . . . . . . . . . . . . . . . . . . . 12 6. REDIR Kind Definition . . . . . . . . . . . . . . . . . . . . 12
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Service Registration . . . . . . . . . . . . . . . . . . . 13 7.1. Service Registration . . . . . . . . . . . . . . . . . . 13
7.2. Service Lookup . . . . . . . . . . . . . . . . . . . . . . 15 7.2. Service Lookup . . . . . . . . . . . . . . . . . . . . . 14
8. Overlay Configuration Document Extension . . . . . . . . . . . 15 8. Overlay Configuration Document Extension . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10.1. Access Control Policies . . . . . . . . . . . . . . . . . 16 10.1. Access Control Policies . . . . . . . . . . . . . . . . 15
10.2. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . . 16 10.2. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 16
10.3. ReDiR Namespaces . . . . . . . . . . . . . . . . . . . . . 16 10.3. ReDiR Namespaces . . . . . . . . . . . . . . . . . . . . 16
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . . 17 12.1. Normative References . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . . 17 12.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
REsource LOcation And Discovery (RELOAD) [I-D.ietf-p2psip-base] is a REsource LOcation And Discovery (RELOAD) [I-D.ietf-p2psip-base] is a
peer-to-peer signaling protocol that can be used to maintain an 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 network, and to store data in and retrieve data from the
overlay. Although RELOAD defines a Traversal Using Relays around overlay. Although RELOAD defines a Traversal Using Relays around
Network Address Translation (TURN) specific service discovery Network Address Translation (TURN) specific service discovery
mechanism, it does not define a generic service discovery mechanism mechanism, it does not define a generic service discovery mechanism
as a part of the base protocol. This document defines how the as a part of the base protocol. This document defines how the
skipping to change at page 3, line 32 skipping to change at page 3, line 12
peers in a RELOAD Overlay Instance can offer to each other include a peers in a RELOAD Overlay Instance can offer to each other include a
TURN relay service, a voice mail service, a gateway location service, TURN relay service, a voice mail service, a gateway location service,
and a transcoding service. Typically, only a small subset of the and a transcoding service. Typically, only a small subset of the
peers participating in the system are providers of a given service. peers participating in the system are providers of a given service.
A peer that wishes to use a particular service faces the problem of A peer that wishes to use a particular service faces the problem of
finding peers that are providing that service from the Overlay finding peers that are providing that service from the Overlay
Instance. Instance.
A naive way to perform service discovery is to store the Node-IDs of 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. all nodes providing a particular service under a well-known key k.
The limitation of this approach is that it scales linearly in the The limitation of this approach is that it scales linearly with the
number of nodes that provide the service. The problem is two-fold: 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 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 end up storing a large number of Node-IDs and most importantly, may
also become overloaded since all service lookup requests for service also become overloaded since all service lookup requests for service
s will need to be answered by node n. An efficient service discovery s will need to be answered by node n. An efficient service discovery
mechanism does not overload the nodes storing pointers to service mechanism does not overload the nodes storing pointers to service
providers. In addition, the mechanism must ensure that the load of providers. In addition, the mechanism must ensure that the load of
providing a given service is distributed evenly among the nodes providing a given service is distributed evenly among the nodes
providing the service. providing the service.
ReDiR implements service discovery by building a tree structure of ReDiR implements service discovery by building a tree structure of
the service providers that provide a particular service. The tree the service providers that provide a particular service. The tree
structure is stored into the RELOAD Overlay Instance using RELOAD structure is stored into the RELOAD Overlay Instance using RELOAD
Store and Fetch requests. Each service provided in the Overlay Store and Fetch requests. Each service provided in the Overlay
Instance has its own tree. The nodes in a ReDiR tree contain Instance has its own tree. The nodes in a ReDiR tree contain
skipping to change at page 4, line 19 skipping to change at page 3, line 47
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
This document uses the terminology and definitions from the Concepts This document uses the terminology and definitions from the Concepts
and Terminology for Peer to Peer SIP [I-D.ietf-p2psip-concepts] and Terminology for Peer to Peer SIP [I-D.ietf-p2psip-concepts]
draft. draft.
DHT: Distributed Hash Tables (DHTs) are a class of decentralized DHT: Distributed Hash Tables (DHTs) are a class of decentralized
distributed systems that provide a lookup service similar to a distributed systems that provide a lookup service similar to a
hash table. Given a key, any participating peer can retrieve the regular hash table. Given a key, any peer participating in the
value associated with that key. The responsibility for system can retrieve the value associated with that key. The
maintaining the mapping from keys to values is distributed among responsibility for maintaining the mapping from keys to values is
the peers. distributed among the peers.
H(x): Hash calculated over x. H(x): Refers to a hash function (e.g., SHA-1) calculated over the
value x.
I(l,k): An interval at level l in the ReDiR tree that encloses key I(lvl,k): An interval at level lvl in the ReDiR tree that encloses
k. 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.
n.id: Node-ID of node n. n.id: Refers to the RELOAD Node-ID of node n.
Namespace: An arbitrary identifier that identifies a service Namespace: An arbitrary identifier that identifies a service
provided in the RELOAD Overlay Instance. An example of a provided in the RELOAD Overlay Instance. Examples of potential
namespace is "voice-mail". The namespace is an UTF-8 text string. namespaces include "voice-mail" and "turn-relay". The namespace
is an UTF-8 text string.
numBitsInNodeId: Number of bits in a Node-ID. 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.
ReDiR tree: A tree structure of the nodes that provide a particular ReDiR tree: A tree structure of the nodes that provide a particular
service. The nodes embed the ReDiR tree into the RELOAD Overlay service. The nodes embed the ReDiR tree into the RELOAD Overlay
Instance using RELOAD Store and Fetch requests. 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.
Successor: The successor of identifier k in namespace ns is the node Successor: The successor of identifier k in namespace ns is the node
belonging to ns whose identifier most immediately follows k. belonging to the namespace ns whose identifier most immediately
follows the identifier k.
3. Introduction to ReDiR 3. Introduction to ReDiR
Recursive Distributed Rendezvous (ReDiR) [Redir] does not require new Recursive Distributed Rendezvous (ReDiR) [Redir] does not require new
functionality from the RELOAD base protocol. This is possible since functionality from the RELOAD base protocol. This is possible since
ReDiR interacts with the RELOAD Overlay Instance by simply storing ReDiR interacts with the RELOAD Overlay Instance by simply storing
and fetching data, that is, using RELOAD Store and Fetch requests. and fetching data, that is, using RELOAD Store and Fetch requests.
ReDiR creates a tree structure of the service providers of a ReDiR creates a tree structure of the service providers of a
particular service and stores it into the RELOAD Overlay Instance particular service and stores it into the RELOAD Overlay Instance
using the Store and Fetch requests. ReDiR service lookups require a using the Store and Fetch requests. ReDiR service lookups require a
skipping to change at page 5, line 51 skipping to change at page 5, line 43
left at level 2. left at level 2.
The ReDiR tree is stored into the RELOAD Overlay Instance tree node 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 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, 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 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- 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 mail",0,0). Each node (level,j) in the ReDiR tree contains b
intervals of the DHT's identifier space as follows: intervals of the DHT's identifier space as follows:
[2^numBitsInNodeID*b^(-level)*(j+(b'/b)), [2^numBitsInNodeID*b^(-level)*(j+(b'/b)),
2^numBitsInNodeID*b^(-level)*(j+((b'+1)/b))), for 0<=b'<b, 2^numBitsInNodeID*b^(-level)*(j+((b'+1)/b))), for 0<=b'<b,
where b is the branching-factor. where b is the branching-factor.
Figure 1 shows an example of a ReDiR tree whose branching factor is 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 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 16. Each tree node in the ReDiR tree is shown as two horizontal
lines separated by a vertical bar ('|') in the middle. The lines separated by a vertical bar ('|') in the middle. The
horizontal lines represent the two intervals each node is responsible horizontal lines represent the two intervals each node is responsible
for. At level 0, there is only one node, (0,0) responsible for two for. At level 0, there is only one node, (0,0) responsible for two
intervals that together cover the entire identifier space of the intervals that together cover the entire identifier space of the
skipping to change at page 7, line 32 skipping to change at page 7, line 32
2^128. 2^128.
4. Using ReDiR in a RELOAD Overlay Instance 4. Using ReDiR in a RELOAD Overlay Instance
4.1. Data Structure 4.1. Data Structure
ReDiR tree nodes are stored using the dictionary data model defined ReDiR tree nodes are stored using the dictionary data model defined
in RELOAD base [I-D.ietf-p2psip-base]. The data stored is a in RELOAD base [I-D.ietf-p2psip-base]. The data stored is a
RedirServiceProvider Resource Record: RedirServiceProvider Resource Record:
enum { none(0), (255) } enum { none(0), (255) }
RedirServiceProviderExtType; RedirServiceProviderExtType;
struct { struct {
RedirServiceProviderExtType type; RedirServiceProviderExtType type;
Destination destination_list<0..2^16-1>; Destination destination_list<0..2^16-1>;
opaque namespace<0..2^16-1>; opaque namespace<0..2^16-1>;
uint16 level; uint16 level;
uint16 node; uint16 node;
uint16 length; uint16 length;
select (type) { select (type) {
/* This type may be extended */ /* This type may be extended */
} extension; } extension;
} RedirServiceProvider; } RedirServiceProvider;
The contents of the RedirServiceProvider Resource Record are as The contents of the RedirServiceProvider Resource Record are as
follows: follows:
type
The type of an extension to the RedirServiceProvider Resource The type of an extension to the RedirServiceProvider Resource
Record. Unknown types are allowed. Record. Unknown types are allowed.
destination_list
A list of IDs through which a message is to be routed to reach the 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 service provider. The destination list consists of a sequence of
Destination values. The contents of the Destination structure are Destination values. The contents of the Destination structure are
as defined in RELOAD base [I-D.ietf-p2psip-base]. as defined in RELOAD base [I-D.ietf-p2psip-base].
namespace
An opaque UTF-8 encoded string containing the namespace. An opaque UTF-8 encoded string containing the namespace.
level
The level in the ReDiR tree. The level in the ReDiR tree.
node
The position of the node storing this RedirServiceProvider record The position of the node storing this RedirServiceProvider record
at the current level in the ReDiR tree. at the current level in the ReDiR tree.
length
The length of the rest of the Resource Record. The length of the rest of the Resource Record.
extension
An extension value. The RedirServiceProvider Resource Record can An extension value. The RedirServiceProvider Resource Record can
be extended to include for instance service or service provider be extended to include for instance service or service provider
specific information. specific information.
4.2. Selecting the Starting Level 4.2. Selecting the Starting Level
Before registering as a service provider or performing a service Before registering as a service provider or performing a service
lookup, a peer needs to determine the starting level Lstart for the lookup, a peer needs to determine the starting level Lstart for the
registration or lookup operation in the ReDiR tree. It is registration or lookup operation in the ReDiR tree. It is
RECOMMENDED that Lstart is set to 2. In subsequent registrations, RECOMMENDED that Lstart is set to 2. In subsequent registrations,
skipping to change at page 11, line 14 skipping to change at page 11, line 13
closest successor of n.id in the ReDiR tree. closest successor of n.id in the ReDiR tree.
Note that above, when we refer to 'the tree node responsible for 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 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 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. contrast, I(l,k) refers to a specific interval within a tree node.
Note also that there may be some cases in which no successor can be 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 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 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 than identifier k. In this case, the upward walk of the service
lookup will reach the root of the tree without encountering a lookup will reach the root of the tree without encountering a
successor. An appropriate strategy in this case is to pick one of successor. An appropriate strategy in this case is to pick one of
the RedirServiceProvider entries stored in the dictionary of the root the RedirServiceProvider entries stored in the dictionary of the root
node at random. node at random.
Since RedirServiceProvider records are expiring and registrations are Since RedirServiceProvider records are expiring and registrations are
being refreshed periodically, there can be certain rare situations in being refreshed periodically, there can be certain rare situations in
which a service lookup may fail even if there is a valid successor 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 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 tree node is fetched just after a RedirServiceProvider entry of the
skipping to change at page 12, line 36 skipping to change at page 12, line 33
parameter). Finally, provided that exists=TRUE, parameter). Finally, provided that exists=TRUE,
H(namespace,level,node), where namespace, level, and node are taken H(namespace,level,node), where namespace, level, and node are taken
from the RedirServiceProvider structure being stored, MUST be equal from the RedirServiceProvider structure being stored, MUST be equal
to the Resource-ID for the resource. The NODE-ID-MATCH policy may to the Resource-ID for the resource. The NODE-ID-MATCH policy may
only be used with dictionary types. only be used with dictionary types.
6. REDIR Kind Definition 6. REDIR Kind Definition
This section defines the REDIR kind. This section defines the REDIR kind.
Name
REDIR REDIR
Kind IDs
The Resource Name for the REDIR Kind-ID is created by The Resource Name for the REDIR Kind-ID is created by
concatenating three pieces of information: namespace, level, and concatenating three pieces of information: namespace, level, and
node number. Namespace is an opaque UTF-8 encoded string node number. Namespace is an opaque UTF-8 encoded string
identifying a service, such as "turn-server". Level is an integer identifying a service, such as "turn-server". Level is an integer
specifying a level in the ReDiR tree. Node number is an integer specifying a level in the ReDiR tree. Node number is an integer
identifying a ReDiR tree node at a specific level. The data identifying a ReDiR tree node at a specific level. The data
stored is a RedirServiceProvider structure that was defined in stored is a RedirServiceProvider structure that was defined in
Section 4.1. Section 4.1.
Data Model
The data model for the REDIR Kind-ID is dictionary. The The data model for the REDIR Kind-ID is dictionary. The
dictionary key is the Node-ID of the service provider. dictionary key is the Node-ID of the service provider.
Access Control
The access control policy for the REDIR kind is the NODE-ID-MATCH The access control policy for the REDIR kind is the NODE-ID-MATCH
policy that was defined in Section 5. policy that was defined in Section 5.
7. Examples 7. Examples
7.1. Service Registration 7.1. Service Registration
Figure 4 shows an example of a ReDiR tree containing information Figure 4 shows an example of a ReDiR tree containing information
about four different service providers whose Node-IDs are 2, 3, 4, about four different service providers whose Node-IDs are 2, 3, 4,
and 7. In the example, numBitsInNodeID=4. Initially, the ReDiR tree 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 is empty; Figure 4 shows the state of the tree at the point when all
the service providers have registered. the service providers have registered.
Level 0 ____2_3___4_____7_|__________________ Level 0 ____2_3___4_____7_|__________________
| | | |
skipping to change at page 13, line 41 skipping to change at page 13, line 30
Figure 4: Example of a ReDiR tree Figure 4: Example of a ReDiR tree
First, peer 2 whose Node-ID is 2 joins the namespace. Since this is 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 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 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 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 contents of the tree node associated with interval I(2,2) from
the RELOAD Overlay Instance. This tree node is the first tree node 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 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 interval of the first tree node. Peer 2 also stores its
RedirServiceProvider record in that tree node. Since peer 2's RedirServiceProvider record in that tree node. Since peer 2's Node-
Node-ID is the only Node-ID stored in the tree node (i.e., peer 2's ID is the only Node-ID stored in the tree node (i.e., peer 2's Node-
Node-ID fulfills the condition in Section 4.3 that it is the ID fulfills the condition in Section 4.3 that it is the numerically
numerically lowest or highest among the keys stored in the node), lowest or highest among the keys stored in the node), peer 2
peer 2 continues up the tree. In fact, peer 2 continues up in the continues up the tree. In fact, peer 2 continues up in the tree all
tree all the way to the root inserting its own Node-ID in all levels the way to the root inserting its own Node-ID in all levels since the
since the tree is empty (which means that peer 2's Node-ID always tree is empty (which means that peer 2's Node-ID always fulfills the
fulfills the condition that it is the numerically lowest or highest condition that it is the numerically lowest or highest Node-ID in the
Node-ID in the interval I(level, 2) during the upward walk). As interval I(level, 2) during the upward walk). As described in
described in Section 4.3, peer 2 also walks down the tree. The Section 4.3, peer 2 also walks down the tree. The downward walk peer
downward walk peer 2 does ends at level 2 since peer 2 is the only 2 does ends at level 2 since peer 2 is the only node in its interval
node in its interval at that level. at that level.
The next peer to join the namespace is peer 3, whose Node-ID is 3. 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 Peer 3 starts from level 2. At that level, peer 3 stores its
RedirServiceProvider entry in the same interval I(2,3) that already RedirServiceProvider entry in the same interval I(2,3) that already
contains the RedirServiceProvider entry of peer 2. Interval I(2,3), contains the RedirServiceProvider entry of peer 2. Interval I(2,3),
that is, the interval at Level 2 enclosing key 3, is associated with 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 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 has the numerically highest Node-ID in the tree node associated with
I(2,3), peer 3 continues up the tree. Peer 3 stores its I(2,3), peer 3 continues up the tree. Peer 3 stores its
RedirServiceProvider record also at levels 1 and 0 since its Node-ID RedirServiceProvider record also at levels 1 and 0 since its Node-ID
skipping to change at page 16, line 38 skipping to change at page 16, line 22
Data Kind-ID" Registry: Data Kind-ID" Registry:
+--------------+------------+----------+ +--------------+------------+----------+
| Kind | Kind-ID | RFC | | Kind | Kind-ID | RFC |
+--------------+------------+----------+ +--------------+------------+----------+
| REDIR | 104 | RFC-AAAA | | REDIR | 104 | RFC-AAAA |
+--------------+------------+----------+ +--------------+------------+----------+
This Kind-ID was defined in Section 6. This Kind-ID was defined in Section 6.
Note to RFC Editor: please replace AAAA with the RFC number for this
specification.
10.3. ReDiR Namespaces 10.3. ReDiR Namespaces
IANA SHALL create a "ReDiR Namespaces" Registry. Entries in this IANA SHALL create a "ReDiR Namespaces" Registry. Entries in this
registry are strings denoting ReDiR namespace values. The initial registry are strings denoting ReDiR namespace values. The initial
contents of this registry are: contents of this registry are:
+----------------+----------+ +----------------+----------+
| Namespace | RFC | | Namespace | RFC |
+----------------+----------+ +----------------+----------+
| turn-server | RFC-AAAA | | turn-server | RFC-AAAA |
+----------------+----------+ +----------------+----------+
The namespace 'turn-server' is used by nodes that wish to register as 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 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 that wish to discover providers of a TURN relay service from the
RELOAD overlay. RELOAD overlay.
11. Acknowledgments Note to RFC Editor: please replace AAAA with the RFC number for this
specification.
11. Acknowledgments
The authors would like to thank Marc Petit-Huguenin and Joscha The authors would like to thank Marc Petit-Huguenin and Joscha
Schneider for their comments on the draft. Schneider for their comments on the draft.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-p2psip-base] [I-D.ietf-p2psip-base]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
Base Protocol", draft-ietf-p2psip-base-25 (work in Base Protocol", draft-ietf-p2psip-base-26 (work in
progress), February 2013. progress), February 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels ", BCP 14, RFC 2119, March 1997.
12.2. Informative References 12.2. Informative References
[I-D.ietf-p2psip-concepts] [I-D.ietf-p2psip-concepts]
Bryan, D., Willis, D., Shim, E., Matthews, P., and S. Bryan, D., Matthews, P., Shim, E., Willis, D., and S.
Dawkins, "Concepts and Terminology for Peer to Peer SIP", Dawkins, "Concepts and Terminology for Peer to Peer SIP",
draft-ietf-p2psip-concepts-04 (work in progress), draft-ietf-p2psip-concepts-05 (work in progress), July
October 2011. 2013.
[Redir] Rhea, S., Godfrey, P., Karp, B., Kubiatowicz, J., [Redir] Rhea, S., Godfrey, P., Karp, B., Kubiatowicz, J.,
Ratnasamy, S., Shenker, S., Stoica, I., and H. Yu, "Open Ratnasamy, S., Shenker, S., Stoica, I., and H. Yu, "Open
DHT: A Public DHT Service and Its Uses". DHT: A Public DHT Service and Its Uses", October 2005.
Authors' Addresses Authors' Addresses
Jouni Maenpaa Jouni Maenpaa
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Jouni.Maenpaa@ericsson.com Email: Jouni.Maenpaa@ericsson.com
 End of changes. 43 change blocks. 
93 lines changed or deleted 101 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/