--- 1/draft-ietf-p2psip-service-discovery-10.txt 2014-05-10 03:14:19.546121951 -0700 +++ 2/draft-ietf-p2psip-service-discovery-11.txt 2014-05-10 03:14:19.582122827 -0700 @@ -1,18 +1,18 @@ P2PSIP Working Group J. Maenpaa Internet-Draft G. Camarillo 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) - draft-ietf-p2psip-service-discovery-10.txt + draft-ietf-p2psip-service-discovery-11.txt Abstract REsource LOcation and Discovery (RELOAD) 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 used in OpenDHT can be applied to RELOAD overlays to provide a generic service discovery mechanism. Status of This Memo @@ -23,21 +23,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. 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 @@ -61,39 +61,40 @@ 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 . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 10.1. Access Control Policies . . . . . . . . . . . . . . . . 17 - 10.2. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 17 - 10.3. ReDiR Namespaces . . . . . . . . . . . . . . . . . . . . 18 + 10.2. A New IETF XML Registry . . . . . . . . . . . . . . . . 17 + 10.3. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 18 + 10.4. ReDiR Namespaces . . . . . . . . . . . . . . . . . . . . 18 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 18 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 19 12.2. Informative References . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction - REsource LOcation And Discovery (RELOAD) [I-D.ietf-p2psip-base] 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 Traversal Using Relays around - Network Address Translation (TURN) specific service discovery - mechanism, 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 - [Redir] used in OpenDHT can be applied to RELOAD overlays. + 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 Traversal Using Relays around Network Address + Translation (TURN) specific service discovery mechanism, 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 [Redir] used in + OpenDHT can be applied to RELOAD overlays. 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. @@ -296,22 +297,22 @@ 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. 4. Using ReDiR in a RELOAD Overlay Instance 4.1. Data Structure ReDiR tree nodes are stored using the dictionary data model defined - in RELOAD base [I-D.ietf-p2psip-base]. The data stored is a - RedirServiceProvider Resource Record: + in RELOAD base [RFC6940]. The data stored is a RedirServiceProvider + Resource Record: 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; @@ -329,21 +330,21 @@ type The type of an extension to the RedirServiceProvider Resource Record. Unknown types are allowed. 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 RELOAD base [I-D.ietf-p2psip-base]. + as defined in RELOAD base [RFC6940]. namespace An opaque UTF-8 encoded string containing the namespace. level The level in the ReDiR tree. node @@ -513,36 +514,34 @@ 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. 4.6. Removing Registrations Before leaving the RELOAD Overlay Instance, a service provider MUST remove the RedirServiceProvider records it has stored by storing - exists=False values in their place, as described in - [I-D.ietf-p2psip-base]. + exists=False values in their place, as described in [RFC6940]. 5. Access Control Rules - As specified in RELOAD base [I-D.ietf-p2psip-base], every kind which - 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. + As specified in RELOAD base [RFC6940], every kind which 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. 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 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- 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 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 @@ -694,62 +693,72 @@ 8. Overlay Configuration Document Extension This document extends the RELOAD overlay configuration document by adding a new element "branching-factor" inside the new "REDIR" kind element: redir:branching-factor: The branching factor of the ReDir tree. The 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 element in the overlay configuration file. 9. Security Considerations 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.1. Access Control Policies This document introduces one additional access control policy to the "RELOAD Access Control Policy" Registry: NODE-ID-MATCH 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 Data Kind-ID" Registry: +--------------+------------+----------+ | Kind | Kind-ID | RFC | +--------------+------------+----------+ | REDIR | 104 | RFC-AAAA | +--------------+------------+----------+ 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.4. ReDiR Namespaces IANA SHALL create a "ReDiR Namespaces" Registry. Entries in this registry are strings denoting ReDiR namespace values. The initial contents of this registry are: +----------------+----------+ | Namespace | RFC | +----------------+----------+ | turn-server | RFC-AAAA | +----------------+----------+ @@ -764,29 +773,30 @@ 11. Acknowledgments The authors would like to thank Marc Petit-Huguenin, Joscha Schneider, and Carlos Bernardos for their comments on the document. 12. 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 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 [I-D.ietf-p2psip-concepts] Bryan, D., Matthews, P., Shim, E., Willis, D., and S. Dawkins, "Concepts and Terminology for Peer to Peer SIP", draft-ietf-p2psip-concepts-05 (work in progress), July 2013. [Redir] Rhea, S., Godfrey, P., Karp, B., Kubiatowicz, J., Ratnasamy, S., Shenker, S., Stoica, I., and H. Yu, "Open