draft-ietf-p2psip-service-discovery-10.txt   draft-ietf-p2psip-service-discovery-11.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 6, 2014 February 2, 2014 Expires: November 11, 2014 May 10, 2014
Service Discovery Usage for REsource LOcation And Discovery (RELOAD) Service Discovery Usage for REsource LOcation And Discovery (RELOAD)
draft-ietf-p2psip-service-discovery-10.txt draft-ietf-p2psip-service-discovery-11.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 August 6, 2014. This Internet-Draft will expire on November 11, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
4.6. Removing Registrations . . . . . . . . . . . . . . . . . 13 4.6. Removing Registrations . . . . . . . . . . . . . . . . . 13
5. Access Control Rules . . . . . . . . . . . . . . . . . . . . 13 5. Access Control Rules . . . . . . . . . . . . . . . . . . . . 13
6. REDIR Kind Definition . . . . . . . . . . . . . . . . . . . . 13 6. REDIR Kind Definition . . . . . . . . . . . . . . . . . . . . 13
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Service Registration . . . . . . . . . . . . . . . . . . 14 7.1. Service Registration . . . . . . . . . . . . . . . . . . 14
7.2. Service Lookup . . . . . . . . . . . . . . . . . . . . . 16 7.2. Service Lookup . . . . . . . . . . . . . . . . . . . . . 16
8. Overlay Configuration Document Extension . . . . . . . . . . 17 8. Overlay Configuration Document Extension . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10.1. Access Control Policies . . . . . . . . . . . . . . . . 17 10.1. Access Control Policies . . . . . . . . . . . . . . . . 17
10.2. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 17 10.2. A New IETF XML Registry . . . . . . . . . . . . . . . . 17
10.3. ReDiR Namespaces . . . . . . . . . . . . . . . . . . . . 18 10.3. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 18
10.4. ReDiR Namespaces . . . . . . . . . . . . . . . . . . . . 18
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
12.1. Normative References . . . . . . . . . . . . . . . . . . 18 12.1. Normative References . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . 19 12.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
REsource LOcation And Discovery (RELOAD) [I-D.ietf-p2psip-base] is a REsource LOcation And Discovery (RELOAD) [RFC6940] is a peer-to-peer
peer-to-peer signaling protocol that can be used to maintain an signaling protocol that can be used to maintain an overlay network,
overlay network, and to store data in and retrieve data from the and to store data in and retrieve data from the overlay. Although
overlay. Although RELOAD defines a Traversal Using Relays around RELOAD defines a Traversal Using Relays around Network Address
Network Address Translation (TURN) specific service discovery Translation (TURN) specific service discovery mechanism, it does not
mechanism, it does not define a generic service discovery mechanism define a generic service discovery mechanism as a part of the base
as a part of the base protocol. This document defines how the protocol. This document defines how the Recursive Distributed
Recursive Distributed Rendezvous (ReDiR) service discovery mechanism Rendezvous (ReDiR) service discovery mechanism [Redir] used in
[Redir] used in OpenDHT can be applied to RELOAD overlays. OpenDHT can be applied to RELOAD overlays.
In a Peer-to-Peer (P2P) overlay network such as a RELOAD Overlay In a Peer-to-Peer (P2P) overlay network such as a RELOAD Overlay
Instance, the peers forming the overlay share their resources in Instance, the peers forming the overlay share their resources in
order to provide the service the system has been designed to provide. order to provide the service the system has been designed to provide.
The peers in the overlay both provide services to other peers and The peers in the overlay both provide services to other peers and
request services from other peers. Examples of possible services request services from other peers. Examples of possible services
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.
skipping to change at page 8, line 10 skipping to change at page 8, line 10
intervals. Level 2 contains 100 nodes and 1000 intervals, level 3 intervals. Level 2 contains 100 nodes and 1000 intervals, level 3
1000 nodes and 10000 intervals, etc. Further, the size of the 1000 nodes and 10000 intervals, etc. Further, the size of the
identifier space of a real RELOAD Overlay Instance is at the minimum identifier space of a real RELOAD Overlay Instance is at the minimum
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 [RFC6940]. The data stored is a RedirServiceProvider
RedirServiceProvider Resource Record: 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;
skipping to change at page 8, line 43 skipping to change at page 8, line 43
type 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 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 [RFC6940].
namespace namespace
An opaque UTF-8 encoded string containing the namespace. An opaque UTF-8 encoded string containing the namespace.
level level
The level in the ReDiR tree. The level in the ReDiR tree.
node node
skipping to change at page 13, line 11 skipping to change at page 13, line 11
that a service lookup operation fails due to the downward walk that a service lookup operation fails due to the downward walk
reaching a level that does not contain a successor, the cache is reaching a level that does not contain a successor, the cache is
searched for successors of the search key. If there are successors searched for successors of the search key. If there are successors
present in the cache, the closest one of them is selected as the present in the cache, the closest one of them is selected as the
service provider. service provider.
4.6. Removing Registrations 4.6. Removing Registrations
Before leaving the RELOAD Overlay Instance, a service provider MUST Before leaving the RELOAD Overlay Instance, a service provider MUST
remove the RedirServiceProvider records it has stored by storing remove the RedirServiceProvider records it has stored by storing
exists=False values in their place, as described in exists=False values in their place, as described in [RFC6940].
[I-D.ietf-p2psip-base].
5. Access Control Rules 5. Access Control Rules
As specified in RELOAD base [I-D.ietf-p2psip-base], every kind which As specified in RELOAD base [RFC6940], every kind which is storable
is storable in an overlay must be associated with an access control in an overlay must be associated with an access control policy. This
policy. This policy defines whether a request from a given node to policy defines whether a request from a given node to operate on a
operate on a given value should succeed or fail. Usages can define given value should succeed or fail. Usages can define any access
any access control rules they choose, including publicly writable control rules they choose, including publicly writable values.
values.
ReDiR requires an access control policy that allows multiple nodes in 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 read and write access to the ReDiR tree nodes stored in
the overlay. Therefore, none of the access control policies the overlay. Therefore, none of the access control policies
specified in RELOAD base [I-D.ietf-p2psip-base] is sufficient. specified in RELOAD base [RFC6940] is sufficient.
This document defines a new access control policy, called NODE-ID- This document defines a new access control policy, called NODE-ID-
MATCH. In this policy, a given value MUST be written and overwritten MATCH. In this policy, a given value MUST be written and overwritten
only if the the request is signed with a key associated with a only if the the request is signed with a key associated with a
certificate whose Node-ID is equal to the dictionary key. In certificate whose Node-ID is equal to the dictionary key. In
addition, provided that exists=TRUE, the Node-ID MUST belong to one addition, provided that exists=TRUE, the Node-ID MUST belong to one
of the intervals associated with the tree node (the number of of the intervals associated with the tree node (the number of
intervals each tree node has is determined by the branching-factor intervals each tree node has is determined by the branching-factor
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
skipping to change at page 17, line 14 skipping to change at page 17, line 14
8. Overlay Configuration Document Extension 8. Overlay Configuration Document Extension
This document extends the RELOAD overlay configuration document by This document extends the RELOAD overlay configuration document by
adding a new element "branching-factor" inside the new "REDIR" kind adding a new element "branching-factor" inside the new "REDIR" kind
element: element:
redir:branching-factor: The branching factor of the ReDir tree. The redir:branching-factor: The branching factor of the ReDir tree. The
default value is 10. default value is 10.
This new element is formally defined as follows: The Relax NG Grammar for this element is:
namespace redir = "urn:ietf:params:xml:ns:p2p:service-discovery" 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 The 'redir' namespace is added into the <mandatory-extension> element
in the overlay configuration file. in the overlay configuration file.
9. Security Considerations 9. Security Considerations
There are no new security considerations introduced in this document. There are no new security considerations introduced in this document.
The security considerations of RELOAD [I-D.ietf-p2psip-base] apply. The security considerations of RELOAD [RFC6940] apply.
10. IANA Considerations 10. IANA Considerations
10.1. Access Control Policies 10.1. Access Control Policies
This document introduces one additional access control policy to the This document introduces one additional access control policy to the
"RELOAD Access Control Policy" Registry: "RELOAD Access Control Policy" Registry:
NODE-ID-MATCH NODE-ID-MATCH
This access control policy was described in Section 5. This access control policy was described in Section 5.
10.2. Data Kind-ID 10.2. A New IETF XML Registry
This document registers one new URI for the redir namespace in the
IETF XML registry defined in [RFC3688].
URI: urn:ietf:params:xml:ns:p2p:redir
Registrant Contact: The IESG
XML: N/A, the requested URI is an XML namespace
10.3. Data Kind-ID
This document introduces one additional data Kind-ID to the "RELOAD This document introduces one additional data Kind-ID to the "RELOAD
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 Note to RFC Editor: please replace AAAA with the RFC number for this
specification. specification.
10.3. ReDiR Namespaces 10.4. 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 |
+----------------+----------+ +----------------+----------+
skipping to change at page 18, line 45 skipping to change at page 19, line 9
11. Acknowledgments 11. Acknowledgments
The authors would like to thank Marc Petit-Huguenin, Joscha The authors would like to thank Marc Petit-Huguenin, Joscha
Schneider, and Carlos Bernardos for their comments on the document. 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]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
Base Protocol", draft-ietf-p2psip-base-26 (work in
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.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC6940] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
Base Protocol", RFC 6940, January 2014.
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.,
Ratnasamy, S., Shenker, S., Stoica, I., and H. Yu, "Open Ratnasamy, S., Shenker, S., Stoica, I., and H. Yu, "Open
 End of changes. 19 change blocks. 
40 lines changed or deleted 50 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/