draft-ietf-p2psip-service-discovery-02.txt   draft-ietf-p2psip-service-discovery-03.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: July 11, 2011 January 7, 2011 Expires: January 6, 2012 July 5, 2011
Service Discovery Usage for REsource LOcation And Discovery (RELOAD) Service Discovery Usage for REsource LOcation And Discovery (RELOAD)
draft-ietf-p2psip-service-discovery-02.txt draft-ietf-p2psip-service-discovery-03.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 part of the base protocol. This service discovery mechanism as 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 July 11, 2011. This Internet-Draft will expire on January 6, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 5, line 22 skipping to change at page 5, line 22
join a namespace and peers wishing to use a service perform lookups join a namespace and peers wishing to use a service perform lookups
within the namespace of the service. A ReDiR lookup for identifier k within the namespace of the service. A ReDiR lookup for identifier k
in namespace ns returns a node that has joined ns whose identifier is in namespace ns returns a node that has joined ns whose identifier is
the closest successor of k. the closest successor of k.
Each tree node in the ReDiR tree contains a list of Node-IDs of peers Each tree node in the ReDiR tree contains a list of Node-IDs of peers
providing a particular service. Each node in the tree has a level. providing a particular service. Each node in the tree has a level.
The root is at level 0, the immediate children of the root are at The root is at level 0, the immediate children of the root are at
level 1, and so forth. The ReDiR tree has a branching factor, whose level 1, and so forth. The ReDiR tree has a branching factor, whose
value is determined by a new element in the RELOAD overlay value is determined by a new element in the RELOAD overlay
configuration document, called redirBranchingFactor. At every level configuration document, called branching-factor. At every level i in
i in the tree, there are at most redirBranchingFactor^i nodes. The the tree, there are at most branching-factor^i nodes. The nodes at
nodes at any level are labeled from left to right, such that a pair any level are labeled from left to right, such that a pair (i,j)
(i,j) uniquely identifies the jth node from the left at level i. uniquely identifies the jth node from the left at level i. This tree
This tree is embedded into the RELOAD Overlay Instance node by node, is embedded into the RELOAD Overlay Instance node by node, by storing
by storing the values of node (i,j) at key H(namespace,i,j). As an the values of node (i,j) at key H(namespace,i,j). As an example, the
example, the root of the tree for a voice mail service is stored at root of the tree for a voice mail service is stored at H("voice-
H("voice-mail",0,0). Each node (i,j) in the tree is associated with mail",0,0). Each node (i,j) in the tree is associated with
redirBranchingFactor intervals of the DHT keyspace as follows: branching-factor intervals of the DHT keyspace as follows:
[2^numBitsInNodeID*b^(-i)*(j+(b'/b)), [2^numBitsInNodeID*b^(-i)*(j+(b'/b)),
2^numBitsInNodeID*b^(-i)*(j+((b'+1)/b))], for 0<=b'<b, 2^numBitsInNodeID*b^(-i)*(j+((b'+1)/b))], for 0<=b'<b,
where b is the redirBranchingFactor. where b is the branching-factor.
Figure 1 shows an example of a ReDiR tree with a branching factor of Figure 1 shows an example of a ReDiR tree with a branching factor of
2. Each node is shown as two horizontal lines separated by a 2. Each node is shown as two horizontal lines separated by a
vertical bar. The lines represent the two intervals each node is vertical bar. The lines represent the two intervals each node is
responsible for. At level 0, there is only one node, (0,0) responsible for. At level 0, there is only one node, (0,0)
responsible for two intervals that together cover the entire responsible for two intervals that together cover the entire
identifier space of the RELOAD Overlay Instance. At level 1, there 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 are two nodes, (1,0) and (1,1), each of which is responsible for half
of the identifier space. At level 2, there are four nodes. Each of of the identifier space. At level 2, there are four nodes. Each of
them owns one fourth of the identifier space. At level 3, there are them owns one fourth of the identifier space. At level 3, there are
skipping to change at page 8, line 27 skipping to change at page 8, line 27
the interval. the interval.
Note that above, when we refer to 'the tree node associated with Note that above, when we refer to 'the tree node associated with
I(l,k)', we mean the entire tree node (that is, all the intervals 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, 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) refers to a specific interval within a tree node.
4.4. Refreshing Registrations 4.4. Refreshing Registrations
All state in the ReDiR tree is soft. If an entry (Node-ID) is not All state in the ReDiR tree is soft. If an entry (Node-ID) is not
refreshed for redirRefreshPeriod seconds, it MUST be dropped from the refreshed for refresh-period seconds, it MUST be dropped from the
dictionary by the peer storing the tree node. redirRefreshPeriod is a dictionary by the peer storing the tree node. refresh-period is a new
new element in the RELOAD overlay configuration document (see element in the RELOAD overlay configuration document (see Section 8).
Section 8). Every service provider MUST repeat the entire Every service provider MUST repeat the entire registration process
registration process periodically until it leaves the RELOAD Overlay periodically until it leaves the RELOAD Overlay Instance.
Instance.
Note that no new mechanisms are needed to keep track of the remaining Note that no new mechanisms are needed to keep track of the remaining
lifetime of RedirServiceProvider records. The 'storage_time' and lifetime of RedirServiceProvider records. The 'storage_time' and
'lifetime' fields of RELOAD's StoredData structure can be used for 'lifetime' fields of RELOAD's StoredData structure can be used for
this purpose in the usual way. this purpose in the usual way.
4.5. Service Lookups 4.5. Service Lookups
The purpose of a service lookup on identifier k in namespace ns is to The purpose of a service lookup on identifier k in namespace ns is to
find the node that has joined ns whose identifier most immediately find the node that has joined ns whose identifier most immediately
skipping to change at page 9, line 47 skipping to change at page 9, line 47
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 [I-D.ietf-p2psip-base] 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, the Node-ID MUST belong to one of the two intervals addition, the Node-ID MUST belong to one of the intervals associated
associated with the tree node. Finally, H(namespace,level,node), with the tree node (the number of intervals each tree node has is
where namespace, level, and node are taken from the determined by the branching-factor parameter). Finally,
RedirServiceProvider structure being stored, MUST be equal to the H(namespace,level,node), where namespace, level, and node are taken
Resource-ID for the resource. The NODE-ID-MATCH policy may only be from the RedirServiceProvider structure being stored, MUST be equal
used with dictionary types. to the Resource-ID for the resource. The NODE-ID-MATCH policy may
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 Name
REDIR REDIR
Kind IDs Kind IDs
The Resource Name for the REDIR Kind-ID is created by The Resource Name for the REDIR Kind-ID is created by
skipping to change at page 12, line 14 skipping to change at page 12, line 15
with interval I(1,4) because it has the numerically lowest Node-ID in 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 that interval. Next, peer 4 continues to the root level, at which it
stores its RedirServiceProvider record and finishes the upward walk stores its RedirServiceProvider record and finishes the upward walk
since the root level was reached. Peer 4 also does a downward 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 starting from level 2. The downward walk stops at level 2 because
peer 4 is the only peer in the interval I(2,4). peer 4 is the only peer in the interval I(2,4).
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 two new elements inside each "configuration" element. adding two new elements inside the new "REDIR" kind element.
redirBranchingFactor: 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.
redirRefreshPeriod: The interval at which a service provider needs redir:refresh-period: The interval at which a service provider needs
to repeat the ReDiR registration process. to repeat the ReDiR registration process.
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 [I-D.ietf-p2psip-base] apply.
10. IANA Considerations 10. IANA Considerations
10.1. Access Control Policies 10.1. Access Control Policies
skipping to change at page 13, line 20 skipping to change at page 13, line 20
This kind-ID was defined in Section 6. This kind-ID was defined in Section 6.
11. References 11. References
11.1. Normative References 11.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-12 (work in Base Protocol", draft-ietf-p2psip-base-15 (work in
progress), November 2010. progress), May 2011.
[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.
11.2. Informative References 11.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-03 (work in progress), draft-ietf-p2psip-concepts-03 (work in progress),
 End of changes. 11 change blocks. 
30 lines changed or deleted 30 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/