draft-ietf-p2psip-service-discovery-03.txt		draft-ietf-p2psip-service-discovery-04.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: January 6, 2012 July 5, 2011		Expires: July 9, 2012 January 6, 2012
	Service Discovery Usage for REsource LOcation And Discovery (RELOAD)		Service Discovery Usage for REsource LOcation And Discovery (RELOAD)
	draft-ietf-p2psip-service-discovery-03.txt		draft-ietf-p2psip-service-discovery-04.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 January 6, 2012.		This Internet-Draft will expire on July 9, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2012 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
	skipping to change at page 2, line 22		skipping to change at page 2, line 22
	4.2. Selecting the Starting Level . . . . . . . . . . . . . . . 7		4.2. Selecting the Starting Level . . . . . . . . . . . . . . . 7
	4.3. Service Provider Registration . . . . . . . . . . . . . . 7		4.3. Service Provider Registration . . . . . . . . . . . . . . 7
	4.4. Refreshing Registrations . . . . . . . . . . . . . . . . . 8		4.4. Refreshing Registrations . . . . . . . . . . . . . . . . . 8
	4.5. Service Lookups . . . . . . . . . . . . . . . . . . . . . 8		4.5. Service Lookups . . . . . . . . . . . . . . . . . . . . . 8
	4.6. Removing Registrations . . . . . . . . . . . . . . . . . . 9		4.6. Removing Registrations . . . . . . . . . . . . . . . . . . 9
	5. Access Control Rules . . . . . . . . . . . . . . . . . . . . . 9		5. Access Control Rules . . . . . . . . . . . . . . . . . . . . . 9
	6. REDIR Kind Definition . . . . . . . . . . . . . . . . . . . . 10		6. REDIR Kind Definition . . . . . . . . . . . . . . . . . . . . 10
	7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 10		7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	8. Overlay Configuration Document Extension . . . . . . . . . . . 12		8. Overlay Configuration Document Extension . . . . . . . . . . . 12
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 12		9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	10.1. Access Control Policies . . . . . . . . . . . . . . . . . 12		10.1. Access Control Policies . . . . . . . . . . . . . . . . . 13
	10.2. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . . 12		10.2. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . . 13
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		10.3. ReDiR Namespaces . . . . . . . . . . . . . . . . . . . . . 13
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 13		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
	11.2. Informative References . . . . . . . . . . . . . . . . . . 13		12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13		12.1. Normative References . . . . . . . . . . . . . . . . . . . 14
			12.2. Informative References . . . . . . . . . . . . . . . . . . 14
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
	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 part of the base protocol. This document defines how the		as part of the base protocol. This document defines how the
	skipping to change at page 3, line 52		skipping to change at page 3, line 52
	ReDiR implements service discovery by building a tree structure of		ReDiR implements service discovery by building a tree structure of
	the nodes that provide a particular service and embedding it into the		the nodes that provide a particular service and embedding it into the
	RELOAD Overlay Instance using RELOAD Store and Fetch requests. Each		RELOAD Overlay Instance using RELOAD Store and Fetch requests. Each
	service provided in the Overlay Instance has its own tree. The nodes		service provided in the Overlay Instance has its own tree. The nodes
	in a ReDiR tree contain pointers to service providers. During		in a ReDiR tree contain pointers to service providers. During
	service discovery, a peer wishing to use a given service fetches		service discovery, a peer wishing to use a given service fetches
	ReDiR tree nodes one-by-one from the RELOAD Overlay Instance until it		ReDiR tree nodes one-by-one from the RELOAD Overlay Instance until it
	finds a service provider responsible for its Node-ID. It has been		finds a service provider responsible for its Node-ID. It has been
	proved that ReDiR can find a service provider using only a constant		proved that ReDiR can find a service provider using only a constant
	number of fetch operations [Redir].		number of Fetch operations [Redir].
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	This document uses the terminology and definitions from the Concepts		This document uses the terminology and definitions from the Concepts
	and Terminology for Peer to Peer SIP [I-D.ietf-p2psip-concepts]		and Terminology for Peer to Peer SIP [I-D.ietf-p2psip-concepts]
	draft.		draft.
	skipping to change at page 4, line 31		skipping to change at page 4, line 31
	H(x): Hash calculated over x.		H(x): Hash calculated over x.
	I(l,k): The unique interval at level l in the ReDiR tree that		I(l,k): The unique interval at level l in the ReDiR tree that
	encloses key k.		encloses key k.
	n.id: Node-ID of node n.		n.id: Node-ID of node n.
	Namespace: An arbitrary identifier that identifies a service		Namespace: An arbitrary identifier that identifies a service
	provided in the RELOAD Overlay Instance. An example of a		provided in the RELOAD Overlay Instance. An example of a
	namespace is "voice-mail".		namespace is "voice-mail". The namespace is an UTF-8 text string.
	numBitsInNodeId: Number of bits in a Node-ID.		numBitsInNodeId: Number of bits in a Node-ID.
	ReDiR tree: A tree structure of the nodes that provide a particular		ReDiR tree: A tree structure of the nodes that provide a particular
	service. The nodes embed the ReDiR tree into the RELOAD Overlay		service. The nodes embed the ReDiR tree into the RELOAD Overlay
	Instance using RELOAD Store and Fetch requests.		Instance using RELOAD Store and Fetch requests.
	Successor: The successor of identifier k in namespace ns is the node		Successor: The successor of identifier k in namespace ns is the node
	that has joined ns whose identifier most immediately follows k.		that has joined ns whose identifier most immediately follows k.
	skipping to change at page 5, line 7		skipping to change at page 5, line 7
	Recursive Distributed Rendezvous (ReDiR) [Redir] does not require new		Recursive Distributed Rendezvous (ReDiR) [Redir] does not require new
	functionality from the RELOAD base protocol. This is possible since		functionality from the RELOAD base protocol. This is possible since
	ReDiR interacts with the RELOAD overlay through a put/get API using		ReDiR interacts with the RELOAD overlay through a put/get API using
	RELOAD Store and Fetch requests. ReDiR builds a tree structure of		RELOAD Store and Fetch requests. ReDiR builds a tree structure of
	the nodes that provide a particular service and embeds it into the		the nodes that provide a particular service and embeds it into the
	RELOAD Overlay Instance using the Store and Fetch requests. ReDiR		RELOAD Overlay Instance using the Store and Fetch requests. ReDiR
	performs lookup in a logarithmic number of Fetch operations with high		performs lookup in a logarithmic number of Fetch operations with high
	probability. Further, if the tree's height is estimated based on		probability. Further, if the tree's height is estimated based on
	past lookups, the average lookup can be reduced to a constant number		past lookups, the average lookup can be reduced to a constant number
	of fetch operations assuming that Node-IDs are distributed uniformly		of Fetch operations assuming that Node-IDs are distributed uniformly
	at random.		at random.
	In ReDiR, each service provided in the overlay is identified by an		In ReDiR, each service provided in the overlay is identified by an
	arbitrary identifier, called its namespace. All service providers		arbitrary identifier, called its namespace. All service providers
	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
	skipping to change at page 5, line 33		skipping to change at page 5, line 33
	the tree, there are at most branching-factor^i nodes. The nodes at		the tree, there are at most branching-factor^i nodes. The nodes at
	any level are labeled from left to right, such that a pair (i,j)		any level are labeled from left to right, such that a pair (i,j)
	uniquely identifies the jth node from the left at level i. This tree		uniquely identifies the jth node from the left at level i. This tree
	is embedded into the RELOAD Overlay Instance node by node, by storing		is embedded into the RELOAD Overlay Instance node by node, by storing
	the values of node (i,j) at key H(namespace,i,j). As an example, the		the values of node (i,j) at key H(namespace,i,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 (i,j) in the tree is associated with		mail",0,0). Each node (i,j) in the tree is associated with
	branching-factor 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 branching-factor.		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
	skipping to change at page 6, line 21		skipping to change at page 6, line 21
	Level 3 _|_ _|_ _|_ _|_ _|_ _|_ _|_ _|_		Level 3 _|_ _|_ _|_ _|_ _|_ _|_ _|_ _|_
	Figure 1: ReDiR tree		Figure 1: ReDiR tree
	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 structure:		RedirServiceProvider Resource Record:
	struct {
	NodeId serviceProvider;
	opaque namespace<0..2^16-1>;
	uint16 level;
	uint16 node;
	/* This type can be extended */
	} RedirServiceProviderData;		enum { none(0), (255) }
			RedirServiceProviderExtType;
	struct {		struct {
	uint16 length;		RedirServiceProviderExtType type;
	RedirServiceProviderData data;		NodeId serviceProvider;
	} RedirServiceProvider;		opaque namespace<0..2^16-1>;
			uint16 level;
	The contents of the RedirServiceProvider structure are as follows:		uint16 node;
			uint16 length;
	length		select (type) {
	The length of the rest of the structure.		/* This type may be extended */
			} extension;
	data		} RedirServiceProvider;
	The service provider data.
	The contents of the RedirServiceProviderData structure are as		The contents of the RedirServiceProvider Resource Record are as
	follows:		follows:
			type
			The type of an extension to the RedirServiceProvider Resource
			Record. Unknown types are allowed.
	serviceProvider		serviceProvider
	The Node-ID of a service provider.		The Node-ID of a service provider.
	namespace		namespace
	An opaque string containing the namespace.		An opaque string containing the namespace.
	level		level
	The level in the ReDiR tree.		The level in the ReDiR tree.
	node		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.
	The RedirServiceProviderData structure can be extended to include for		length
	instance service or service provider specific information.		The length of the rest of the Resource Record.
			extension
			An extension value. The RedirServiceProvider Resource Record can
			be extended to include for instance service or service provider
			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 initially set to 2. In subsequent		RECOMMENDED that Lstart is initially set to 2. In subsequent
	registrations, Lstart MUST be set to the lowest level at which		registrations, Lstart MUST be set to the lowest level at which
	registration last completed.		registration last completed.
	skipping to change at page 7, line 43		skipping to change at page 8, line 4
	4.3. Service Provider Registration		4.3. Service Provider Registration
	A node MUST use the following procedure to register as a service		A node MUST use the following procedure to register as a service
	provider in the RELOAD Overlay Instance:		provider in the RELOAD Overlay Instance:
	1. A node n with Node-ID n.id wishing to register as a service		1. A node n with Node-ID n.id wishing to register as a service
	provider starts from level Lstart (see Section 4.2 for the		provider starts from level Lstart (see Section 4.2 for the
	details on selecting the starting level). Therefore, node n sets		details on selecting the starting level). Therefore, node n sets
	level=Lstart.		level=Lstart.
	2. Node n MUST send a RELOAD Fetch request to fetch the contents of		2. Node n MUST send a RELOAD Fetch request to fetch the contents of
	the tree node associated with I(level,n.id). An interval I(l,k)		the tree node associated with I(level,n.id). An interval I(l,k)
	is defined as the unique interval at level l in the ReDiR tree		is defined as the unique interval at level l in the ReDiR tree
	that encloses key k. The fetch MUST be a wildcard fetch.		that encloses key k. The fetch MUST be a wildcard fetch.
	3. Node n MUST send a RELOAD Store request to add its		3. Node n MUST send a RELOAD Store request to add its
	RedirServiceProvider entry to the dictionary stored in the tree		RedirServiceProvider entry to the dictionary stored in the tree
	node associated with I(level,n.id)		node associated with I(level,n.id)
	4. If node n's Node-ID is the numerically lowest or highest among		4. If node n's Node-ID is the numerically lowest or highest among
	the Node-IDs stored in the tree node associated with		the Node-IDs stored in the tree node associated with
	I(Lstart,n.id), node n MUST continue up the tree towards the root		I(Lstart,n.id), node n MUST continue up the tree towards the root
	(level 0), repeating steps 2 and 3. Node n MUST continue this		(level 0), repeating steps 2 and 3. Node n MUST continue this
	until it reaches either the root or a level at which n.id is not		until it reaches either the root or a level at which n.id is not
	the lowest or highest Node-ID in the interval I(level,n.id).		the lowest or highest Node-ID in the interval I(level,n.id).
	5. Node n MUST also walk down the tree through tree nodes associated		5. Node n MUST also walk down the tree through tree nodes associated
	with the intervals I(Lstart,n.id),I(Lstart+1,n.id),..., at each		with the intervals I(Lstart,n.id),I(Lstart+1,n.id),..., at each
	step fetching the current contents of the tree node, and storing		step fetching the current contents of the tree node, and storing
	its redirServiceProvider record if n.id is the lowest or highest		its RedirServiceProvider record if n.id is the lowest or highest
	Node-ID in the interval. Node n MUST end this downward walk when		Node-ID in the interval. Node n MUST end this downward walk when
	it reaches a level at which it is the only service provider in		it reaches a level at which it is the only service provider in
	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. Therefore, a service provider
	refreshed for refresh-period seconds, it MUST be dropped from the		needs to periodically repeat the registration process to refresh its
	dictionary by the peer storing the tree node. refresh-period is a new		RedirServiceProvider Resource Record. If a record expires, it MUST
	element in the RELOAD overlay configuration document (see Section 8).		be dropped from the dictionary by the peer storing the tree node.
	Every service provider MUST repeat the entire registration process		Deciding an appropriate lifetime for the RedirServiceProvider
	periodically until it leaves the RELOAD Overlay Instance.		Resource Records is up to each service provider. Every service
			provider MUST repeat the entire registration process periodically
			until it leaves the RELOAD Overlay 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 25		skipping to change at page 9, line 33
	successor of n.id, and the lookup is done.		successor of n.id, and the lookup is done.
	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.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
	"nonexistent" values in their place, as described in		exists=False values in their place, as described in
	[I-D.ietf-p2psip-base].		[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 [I-D.ietf-p2psip-base], every kind which
	is storable in an overlay must be associated with an access control		is storable in an overlay must be associated with an access control
	policy. This policy defines whether a request from a given node to		policy. This policy defines whether a request from a given node to
	operate on a given value should succeed or fail. Usages can define		operate on a given value should succeed or fail. Usages can define
	any access control rules they choose, including publicly writable		any access 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 [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 intervals associated		addition, provided that exists=TRUE, the Node-ID MUST belong to one
	with the tree node (the number of intervals each tree node has is		of the intervals associated with the tree node (the number of
	determined by the branching-factor parameter). Finally,		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		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		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
	concatenating three pieces of information: service name, level,		concatenating three pieces of information: namespace, level, and
	and node number. Service name is a string identifying a service,		node number. Namespace is a string identifying a service, such as
	such as "voice-mail". Level is an integer specifying a level in		"voice-mail". Level is an integer specifying a level in the ReDiR
	the ReDiR tree. Node number is an integer identifying a ReDiR		tree. Node number is an integer identifying a ReDiR tree node at
	tree node at a specific level. The data stored is a		a specific level. The data stored is a RedirServiceProvider
	RedirServiceProvider structure that was defined in Section 4.1.		structure that was defined in Section 4.1.
	Data Model		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		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. Example		7. Example
	Figure 2 shows an example of a ReDiR tree containing information		Figure 2 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. Initially, the ReDiR tree is empty.		and 7. In the example, numBitsInNodeID=4. Initially, the ReDiR tree
			is empty.
	Level 0 ____2_3___4_____7_|__________________		Level 0 ____2_3___4_____7_|__________________
	| |		| |
	Level 1 ____2_3_|_4_____7 ________|________		Level 1 ____2_3_|_4_____7 ________|________
	| | | |		| | | |
	Level 2 ___|2_3 4__|__7 ___|___ ___|___		Level 2 ___|2_3 4__|__7 ___|___ ___|___
	| | | | | | | |		| | | | | | | |
	Level 3 _|_ _|3 _|_ _|_ _|_ _|_ _|_ _|_		Level 3 _|_ _|3 _|_ _|_ _|_ _|_ _|_ _|_
	Figure 2: Example of a ReDiR tree		Figure 2: Example of a ReDiR tree
	skipping to change at page 12, line 15		skipping to change at page 12, line 27
	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 the new "REDIR" kind element.		adding a new element "branching-factor" inside the new "REDIR" kind
			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.
	redir:refresh-period: The interval at which a service provider needs		This new element is formally defined as follows:
	to repeat the ReDiR registration process.
			namespace redir = "urn:ietf:params:xml:ns:p2p:service-discovery"
			parameter &= element redir:branching-factor { xsd:unsignedInt }
			The 'redir' namespace is added into the <mandatory-extension> element
			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 [I-D.ietf-p2psip-base] 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. 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.
	11. References		10.3. ReDiR Namespaces
	11.1. Normative References		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 |
			+----------------+----------+
			| voice-mail | RFC-AAAA |
			+----------------+----------+
			11. Acknowledgments
			The authors would like to thank Marc Petit-Huguenin for his comments
			on the draft.
			12. 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-15 (work in		Base Protocol", draft-ietf-p2psip-base-19 (work in
	progress), May 2011.		progress), October 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		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-03 (work in progress),		draft-ietf-p2psip-concepts-04 (work in progress),
	October 2010.		October 2011.
	[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
	DHT: A Public DHT Service and Its Uses".		DHT: A Public DHT Service and Its Uses".
	Authors' Addresses		Authors' Addresses
	Jouni Maenpaa		Jouni Maenpaa
	Ericsson		Ericsson
	Hirsalantie 11		Hirsalantie 11
End of changes. 34 change blocks.
	69 lines changed or deleted		104 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/