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/