draft-ietf-p2psip-service-discovery-09.txt   draft-ietf-p2psip-service-discovery-10.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: February 06, 2014 August 05, 2013 Expires: August 6, 2014 February 2, 2014
Service Discovery Usage for REsource LOcation And Discovery (RELOAD) Service Discovery Usage for REsource LOcation And Discovery (RELOAD)
draft-ietf-p2psip-service-discovery-09.txt draft-ietf-p2psip-service-discovery-10.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
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 February 06, 2014. This Internet-Draft will expire on August 6, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Introduction to ReDiR . . . . . . . . . . . . . . . . . . . . 4 3. Introduction to ReDiR . . . . . . . . . . . . . . . . . . . . 5
4. Using ReDiR in a RELOAD Overlay Instance . . . . . . . . . . 7 4. Using ReDiR in a RELOAD Overlay Instance . . . . . . . . . . 8
4.1. Data Structure . . . . . . . . . . . . . . . . . . . . . 7 4.1. Data Structure . . . . . . . . . . . . . . . . . . . . . 8
4.2. Selecting the Starting Level . . . . . . . . . . . . . . 8 4.2. Selecting the Starting Level . . . . . . . . . . . . . . 9
4.3. Service Provider Registration . . . . . . . . . . . . . . 8 4.3. Service Provider Registration . . . . . . . . . . . . . . 10
4.4. Refreshing Registrations . . . . . . . . . . . . . . . . 9 4.4. Refreshing Registrations . . . . . . . . . . . . . . . . 11
4.5. Service Lookups . . . . . . . . . . . . . . . . . . . . . 10 4.5. Service Lookups . . . . . . . . . . . . . . . . . . . . . 11
4.6. Removing Registrations . . . . . . . . . . . . . . . . . 11 4.6. Removing Registrations . . . . . . . . . . . . . . . . . 13
5. Access Control Rules . . . . . . . . . . . . . . . . . . . . 11 5. Access Control Rules . . . . . . . . . . . . . . . . . . . . 13
6. REDIR Kind Definition . . . . . . . . . . . . . . . . . . . . 12 6. REDIR Kind Definition . . . . . . . . . . . . . . . . . . . . 13
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Service Registration . . . . . . . . . . . . . . . . . . 13 7.1. Service Registration . . . . . . . . . . . . . . . . . . 14
7.2. Service Lookup . . . . . . . . . . . . . . . . . . . . . 14 7.2. Service Lookup . . . . . . . . . . . . . . . . . . . . . 16
8. Overlay Configuration Document Extension . . . . . . . . . . 15 8. Overlay Configuration Document Extension . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10.1. Access Control Policies . . . . . . . . . . . . . . . . 15 10.1. Access Control Policies . . . . . . . . . . . . . . . . 17
10.2. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 16 10.2. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 17
10.3. ReDiR Namespaces . . . . . . . . . . . . . . . . . . . . 16 10.3. ReDiR Namespaces . . . . . . . . . . . . . . . . . . . . 18
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
12.1. Normative References . . . . . . . . . . . . . . . . . . 17 12.1. Normative References . . . . . . . . . . . . . . . . . . 18
12.2. Informative References . . . . . . . . . . . . . . . . . 17 12.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
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 5, line 43 skipping to change at page 6, line 16
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 8, line 13
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 12, line 33 skipping to change at page 13, line 45
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 17, line 4 skipping to change at page 18, line 37
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.
Note to RFC Editor: please replace AAAA with the RFC number for this Note to RFC Editor: please replace AAAA with the RFC number for this
specification. specification.
11. Acknowledgments 11. Acknowledgments
The authors would like to thank Marc Petit-Huguenin and Joscha
Schneider for their comments on the draft. The authors would like to thank Marc Petit-Huguenin, Joscha
Schneider, and Carlos Bernardos for their comments on the document.
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-26 (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., Matthews, P., Shim, E., Willis, D., 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-05 (work in progress), July draft-ietf-p2psip-concepts-05 (work in progress), July
2013. 2013.
[Redir] Rhea, S., Godfrey, P., Karp, B., Kubiatowicz, J., [Redir] Rhea, S., Godfrey, P., Karp, B., Kubiatowicz, J.,
 End of changes. 24 change blocks. 
46 lines changed or deleted 68 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/