draft-ietf-p2psip-service-discovery-00.txt		draft-ietf-p2psip-service-discovery-01.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 23, 2010 January 19, 2010		Expires: January 13, 2011 July 12, 2010
	Service Discovery Usage for REsource LOcation And Discovery (RELOAD)		Service Discovery Usage for REsource LOcation And Discovery (RELOAD)
	draft-ietf-p2psip-service-discovery-00.txt		draft-ietf-p2psip-service-discovery-01.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
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF). Note that other groups may also distribute
	other groups may also distribute working documents as Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts.		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."
	The list of current Internet-Drafts can be accessed at		This Internet-Draft will expire on January 13, 2011.
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on July 23, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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
	described in the BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Introduction to ReDiR . . . . . . . . . . . . . . . . . . . . 4		3. Introduction to ReDiR . . . . . . . . . . . . . . . . . . . . 4
	4. Using ReDiR in a RELOAD Overlay Instance . . . . . . . . . . . 6		4. Using ReDiR in a RELOAD Overlay Instance . . . . . . . . . . . 6
	4.1. Data Structure . . . . . . . . . . . . . . . . . . . . . . 6		4.1. Data Structure . . . . . . . . . . . . . . . . . . . . . . 6
	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 . . . . . . . . . . . . . . . . . . . . 9		6. REDIR Kind Definition . . . . . . . . . . . . . . . . . . . . 10
	7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 10		7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	8. Overlay Configuration Document Extension . . . . . . . . . . . 11		8. Overlay Configuration Document Extension . . . . . . . . . . . 12
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 12		9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	10.1. Access Control Policies . . . . . . . . . . . . . . . . . 12		10.1. Access Control Policies . . . . . . . . . . . . . . . . . 12
	10.2. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . . 12		10.2. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . . 12
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 12		11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
	11.2. Informative References . . . . . . . . . . . . . . . . . . 13		11.2. Informative References . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
	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
	skipping to change at page 5, line 44		skipping to change at page 5, line 44
	where b is the redirBranchingFactor.		where b is the redirBranchingFactor.
	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 leavel 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
	eight nodes each of which is responsible for one eight of the		eight nodes each of which is responsible for one eight of the
	identifier space.		identifier space.
	Level 0 __________________|__________________		Level 0 __________________|__________________
	| |		| |
	Level 1 ________|________ ________|________		Level 1 ________|________ ________|________
	| | | |		| | | |
	Level 2 ___|___ ___|___ ___|___ ___|___		Level 2 ___|___ ___|___ ___|___ ___|___
	| | | | | | | |		| | | | | | | |
	skipping to change at page 7, line 41		skipping to change at page 7, line 41
	the last 16 service lookups completed and take Lstart to be the mode		the last 16 service lookups completed and take Lstart to be the mode
	of those depths.		of those depths.
	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). First, node n MUST		details on selecting the starting level). Therefore, node n sets
	send a RELOAD Store request to add its RedirServiceProvider entry		level=Lstart.
	to the dictionary stored in the tree node associated with		2. Node n MUST send a RELOAD Fetch request to fetch the contents of
	I(Lstart,n.id). An interval I(l,k) is defined as the unique		the tree node associated with I(level,n.id). An interval I(l,k)
	interval at level l in the ReDiR tree that encloses key k		is defined as the unique interval at level l in the ReDiR tree
	2. Node n MUST send a RELOAD Fetch request to obtain the contents of		that encloses key k. The fetch MUST be a wildcard fetch.
	the tree node associated with I(Lstart,n.id). The fetch MUST be		3. Node n MUST send a RELOAD Store request to add its
	a wildcard fetch.		RedirServiceProvider entry to the dictionary stored in the tree
	3. If node n's Node-ID is the numerically lowest or highest among		node associated with I(level,n.id)
	the Node-IDs stored in the tree node, node n MUST continue up the
	tree towards the root (level 0), repeating steps 1 and 2. Node n		4. If node n's Node-ID is the numerically lowest or highest among
	MUST continue this until it reaches either the root or a level at		the Node-IDs stored in the tree node associated with
	which n.id is not the lowest or highest Node-ID in the interval.		I(Lstart,n.id), node n MUST continue up the tree towards the root
	4. Node n MUST also walk down the tree through tree nodes associated		(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
			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
	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
			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,
			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 redirRefreshPeriod 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. redirRefreshPeriod is a
	new element in the RELOAD overlay configuration document (see		new element in the RELOAD overlay configuration document (see
	Section 8). Every service provider MUST repeat the entire		Section 8). Every service provider MUST repeat the entire
	registration process periodically until it leaves the RELOAD Overlay		registration process periodically until it leaves the RELOAD Overlay
	Instance.		Instance.
	skipping to change at page 8, line 38		skipping to change at page 8, line 48
	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
	follows identifier k.		follows identifier k.
	A service lookup is similar to the registration operation. The		A service lookup is similar to the registration operation. The
	service lookup starts from some level level=Lstart (see Section 4.2		service lookup starts from some level level=Lstart (see Section 4.2
	for the details on selecting the starting level). At each step, the		for the details on selecting the starting level). At each step, the
	node n wishing to discover a service provider MUST fetch the current		node n wishing to discover a service provider MUST fetch the tree
	interval I(level,n.id) using a RELOAD Fetch request and MUST		node associated with the current interval I(level,n.id) using a
	determine where to look next as follows:		RELOAD Fetch request and MUST determine where to look next as
			follows:
	1. If the successor of node n is not present in the tree node		1. If the successor of node n is not present in the tree node
	associated with I(level,n.id), then its successor must occur in a		associated with I(level,n.id), then its successor must occur in a
	larger range of the keyspace. Node n MUST set level=level-1 and		larger range of the keyspace. Node n MUST set level=level-1 and
	try again.		try again.
	2. If n.id is sandwiched between two Node-IDs in I(level,n.id), the		2. If n.id is sandwiched between two Node-IDs in I(level,n.id), the
	successor must lie somewhere in I(level,n.id). Node n MUST set		successor must lie somewhere in I(level,n.id). Node n MUST set
	level=level+1 and repeat.		level=level+1 and repeat.
	3. Otherwise, there is a Node-ID s stored in the node associated		3. Otherwise, there is a Node-ID s stored in the node associated
	with I(level,n.id) whose identifier succeeds n.id, and there are		with I(level,n.id) whose identifier succeeds n.id, and there are
	no Node-IDs between n.id and s. Thus, s must be the closest		no Node-IDs between n.id and s. Thus, s must be the closest
	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
			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,
			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		"nonexistent" 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
	skipping to change at page 10, line 26		skipping to change at page 10, line 36
	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. Initially, the ReDiR tree is empty.
	Level 0 ____2_3_________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 4|_ _|_ _|_ _|_ _|_ _|_		Level 3 _|_ _|3 _|_ _|_ _|_ _|_ _|_ _|_
	Figure 2: Example of a ReDiR tree		Figure 2: Example of a ReDiR tree
	First, peer 2 whose Node-ID is 2 joins the namespace. Since this is		First, peer 2 whose Node-ID is 2 joins the namespace. Since this is
	the first registration peer 2 performs, peer 2 sets the starting		the first registration peer 2 performs, peer 2 sets the starting
	level Lstart to 2, as was described in Section 4.2. Also all other		level Lstart to 2, as was described in Section 4.2. Also all other
	peers in this example will start from level 2. Peer 2 stores a		peers in this example will start from level 2. First, peer 2 fetches
	RedirServiceProvider record containing its Node-ID in the tree node		the contents of the tree node associated with interval I(2,2) from
	associated with interval I(2,2). Peer 2 also fetches the contents of		the overlay. Peer 2 also stores its RedirServiceProvider record in
	that tree node from the overlay. Since peer 2's Node-ID is the only		that tree node. Since peer 2's Node-ID is the only Node-ID stored in
	Node-ID stored in the interval, peer 2 continues up the tree. In		the tree node (i.e., peer 2's Node-ID fulfills the condition that it
	fact, peer 2 continues up in the tree all the way to the root		is the numerically lowest or highest among the keys stored in the
	inserting its own Node-ID in all levels since the tree is empty. As		node), peer 2 continues up the tree. In fact, peer 2 continues up in
	described in Section 4.3, peer 2 also walks down the tree. The		the tree all the way to the root inserting its own Node-ID in all
			levels since the tree is empty (which means that peer 2's Node-ID
			always fulfills the condition that it is the numerically lowest or
			highest Node-ID in the interval I(level, 2) during the upward walk).
			As described in Section 4.3, peer 2 also walks down the tree. The
	downward walk peer 2 does ends at level 2 since peer 2 is the only		downward walk peer 2 does ends at level 2 since peer 2 is the only
	node in its interval at that level.		node in its interval at that level.
	The next peer to join the namespace is peer 3, whose Node-ID is 3.		The next peer to join the namespace is peer 3, whose Node-ID is 3.
	Peer 3 starts from level 2. At that level, peer 3 stores its Node-ID		Peer 3 starts from level 2. At that level, peer 3 stores its
	in the same interval I(2,3) that already contains the Node-ID of peer		RedirServiceProvider record in the same interval I(2,3) that already
	2. Since peer 3 has the numerically highest Node-ID in the interval,		contains the Node-ID of peer 2. Since peer 3 has the numerically
	it continues up the tree. Peer 3 stores its node-ID also at levels 1		highest Node-ID in the tree node associated with I(2,3), peer 3
	and 0 since its Node-ID is numerically highest among the Node-IDs		continues up the tree. Peer 3 stores its RedirServiceProvider record
	stored in the tree nodes it fetches. Peer 3 also does a downward		also at levels 1 and 0 since its Node-ID is numerically highest among
	walk which starts from level 2 (i.e., the starting level). Since		the Node-IDs stored in the intervals to which its own Node-ID
	peer 3 is not the only node in interval I(2,3), it continues down the		belongs. Peer 3 also does a downward walk which starts from level 2
	tree to level 3. The downward walk ends at this level since peer 3		(i.e., the starting level). Since peer 3 is not the only node in
	is the only entry in the interval I(3,3).		interval I(2,3), it continues down the tree to level 3. The downward
			walk ends at this level since peer 3 is the only service provider in
			the interval I(3,3).
	The third peer to join the namespace is peer 7, whose Node-ID is 7.		The third peer to join the namespace is peer 7, whose Node-ID is 7.
	Like the two earlier peers, also peer 7 starts from level 2 because		Like the two earlier peers, also peer 7 starts from level 2 because
	this is the first registration it performs. Peer 7 stores its		this is the first registration it performs. Peer 7 stores its
	RedirServiceProvider record at level 2. At level 1, peer 7 has the		RedirServiceProvider record at level 2. At level 1, peer 7 has the
	numerically highest Node-ID (because it is the only node in interval		numerically highest (and lowest) Node-ID in its interval I(1,7)
	I(1,7); peers 2 and 3 are stored in the same tree node but in a		(because it is the only node in interval I(1,7); peers 2 and 3 are
	different interval) and therefore it stores its Node-ID in the tree		stored in the same tree node but in a different interval) and
	node associated with interval I(1,7). Peer 7 also has the		therefore it stores its Node-ID in the tree node associated with that
	numerically highest Node-ID in the interval I(0,7) associated with		interval. Peer 7 also has the numerically highest Node-ID in the
	its Node-ID at level 0. Peer 7 also does a downward walk, which ends		interval I(0,7) associated with its Node-ID at level 0. Finally,
	at level 2 because peer 7 is the only node in its interval at that		peer 7 performs a downward walk, which ends at level 2 because peer 7
	level.		is the only node in its interval at that level.
	The final peer to join the ReDiR tree is peer 4, whose Node-ID is 4.		The final peer to join the ReDiR tree is peer 4, whose Node-ID is 4.
	Peer 4 starts by storing its RedirServiceProvider record at level 2.		Peer 4 starts by storing its RedirServiceProvider record at level 2.
	Since it is the only peer associated with interval I(2,4), it		Since it has the numerically lowest Node-ID in the tree node
	continues up in the tree to level 1. At level 1, peer 4 stores its		associated with interval I(2,4), it continues up in the tree to level
	record in the tree node associated with interval I(1,4) because it		1. At level 1, peer 4 stores its record in the tree node associated
	has the numerically lowest Node-ID in that interval. Next, peer 4		with interval I(1,4) because it has the numerically lowest Node-ID in
	continues to the root level. At the root level, there are other		that interval. Next, peer 4 continues to the root level, at which it
	peers having higher and lower Node-IDs than peer 4 in interval		stores its RedirServiceProvider record and finishes the upward walk
	I(0,4). Therefore, peer 4 does not store a RedirServiceProvider		since the root level was reached. Peer 4 also does a downward walk
	record at the tree node associated with the interval I(0,4). Peer 4		starting from level 2. The downward walk stops at level 2 because
	also does a downward walk starting from level 2. The downward walk		peer 4 is the only peer in the interval I(2,4).
	stops at level 3 because peer 4 is the only peer in the interval
	I(3,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 each "configuration" element.
	redirBranchingFactor: The branching factor of the ReDir tree. The		redirBranchingFactor: 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		redirRefreshPeriod: The interval at which a service provider needs
	skipping to change at page 13, line 5		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-06 (work in		Base Protocol", draft-ietf-p2psip-base-08 (work in
	progress), November 2009.		progress), March 2010.
	[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-02 (work in progress),		draft-ietf-p2psip-concepts-02 (work in progress),
End of changes. 20 change blocks.
	76 lines changed or deleted		88 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/