draft-ietf-rserpool-overview-05.txt		draft-ietf-rserpool-overview-06.txt
	Network Working Group P. Lei		Network Working Group P. Lei
	Internet-Draft Cisco Systems, Inc.		Internet-Draft Cisco Systems, Inc.
	Intended status: Informational L. Ong		Intended status: Informational L. Ong
	Expires: August 25, 2008 Ciena Corporation		Expires: November 7, 2008 Ciena Corporation
	M. Tuexen		M. Tuexen
	Muenster Univ. of Applied Sciences		Muenster Univ. of Applied Sciences
	T. Dreibholz		T. Dreibholz
	University of Duisburg-Essen		University of Duisburg-Essen
	February 22, 2008		May 06, 2008
	An Overview of Reliable Server Pooling Protocols		An Overview of Reliable Server Pooling Protocols
	draft-ietf-rserpool-overview-05.txt		draft-ietf-rserpool-overview-06.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of 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), its areas, and its working groups. Note that
	skipping to change at page 1, line 39		skipping to change at page 1, line 39
	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		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on August 25, 2008.		This Internet-Draft will expire on November 7, 2008.
	Copyright Notice
	Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	The Reliable Server Pooling effort (abbreviated "RSerPool"), provides		The Reliable Server Pooling effort (abbreviated "RSerPool"), provides
	an application-independent set of services and protocols for building		an application-independent set of services and protocols for building
	fault tolerant and highly available client/server applications. This		fault tolerant and highly available client/server applications. This
	document provides an overview of the protocols and mechanisms in the		document provides an overview of the protocols and mechanisms in the
	reliable server pooling suite.		reliable server pooling suite.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Aggregate Server Access Protocol (ASAP) Overview . . . . . . . 6		2. Aggregate Server Access Protocol (ASAP) Overview . . . . . . . 6
	2.1. Pool Initialization . . . . . . . . . . . . . . . . . . . 6		2.1. Pool Initialization . . . . . . . . . . . . . . . . . . . 6
	2.2. Pool Entity Registration . . . . . . . . . . . . . . . . . 6		2.2. Pool Entity Registration . . . . . . . . . . . . . . . . . 7
	2.3. Pool Entity Selection . . . . . . . . . . . . . . . . . . 7		2.3. Pool Entity Selection . . . . . . . . . . . . . . . . . . 7
	2.4. Endpoint Keep-Alive . . . . . . . . . . . . . . . . . . . 7		2.4. Endpoint Keep-Alive . . . . . . . . . . . . . . . . . . . 7
	2.5. Failover Services . . . . . . . . . . . . . . . . . . . . 7		2.5. Failover Services . . . . . . . . . . . . . . . . . . . . 7
	2.5.1. Cookie Mechanism . . . . . . . . . . . . . . . . . . . 7		2.5.1. Cookie Mechanism . . . . . . . . . . . . . . . . . . . 8
	2.5.2. Business Card Mechanism . . . . . . . . . . . . . . . 7		2.5.2. Business Card Mechanism . . . . . . . . . . . . . . . 8
	3. Endpoint Handlespace Redundancy Protocol (ENRP) Overview . . . 8		3. Endpoint Handlespace Redundancy Protocol (ENRP) Overview . . . 8
	3.1. Initialization . . . . . . . . . . . . . . . . . . . . . . 8		3.1. Initialization . . . . . . . . . . . . . . . . . . . . . . 8
	3.2. Server Discovery and Home Server Selection . . . . . . . . 8		3.2. Server Discovery and Home Server Selection . . . . . . . . 9
	3.3. Failure Detection, Handlespace Audit and		3.3. Failure Detection, Handlespace Audit and
	Synchronization . . . . . . . . . . . . . . . . . . . . . 9		Synchronization . . . . . . . . . . . . . . . . . . . . . 9
	3.4. Server Takeover . . . . . . . . . . . . . . . . . . . . . 9		3.4. Server Takeover . . . . . . . . . . . . . . . . . . . . . 9
	4. Example Scenarios . . . . . . . . . . . . . . . . . . . . . . 9		4. Example Scenarios . . . . . . . . . . . . . . . . . . . . . . 9
	4.1. Example Scenario using RSerPool Resolution Service . . . . 9		4.1. Example Scenario using RSerPool Resolution Service . . . . 9
	4.2. Example Scenario using RSerPool Session Services . . . . . 11		4.2. Example Scenario using RSerPool Session Services . . . . . 11
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 12		5. Reference Implementation . . . . . . . . . . . . . . . . . . . 12
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 12		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	8.2. Informative References . . . . . . . . . . . . . . . . . . 13		9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13		9.2. Informative References . . . . . . . . . . . . . . . . . . 14
	Intellectual Property and Copyright Statements . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
			Intellectual Property and Copyright Statements . . . . . . . . . . 16
	1. Introduction		1. Introduction
	The Reliable Server Pooling (RSerPool) protocol suite is designed to		The Reliable Server Pooling (RSerPool) protocol suite is designed to
	provide client applications ("pool users") with the ability to select		provide client applications ("pool users") with the ability to select
	a server (a "pool element") from among a group of servers providing		a server (a "pool element") from among a group of servers providing
	equivalent service (a "pool").		equivalent service (a "pool"). The protocols are currently targeted
			for Experimental Track.
	The RSerPool architecture supports high-availability and load		The RSerPool architecture supports high-availability and load
	balancing by enabling a pool user to identify the most appropriate		balancing by enabling a pool user to identify the most appropriate
	server from the server pool at a given time. The architecture is		server from the server pool at a given time. The architecture is
	defined to support a set of basic goals:		defined to support a set of basic goals:
	o application-independent protocol mechanisms		o application-independent protocol mechanisms
	o separation of server naming from IP addressing		o separation of server naming from IP addressing
	skipping to change at page 4, line 35		skipping to change at page 4, line 35
	.......................		.......................
	Figure 1		Figure 1
	A server pool is defined as a set of one or more servers providing		A server pool is defined as a set of one or more servers providing
	the same application functionality. The servers are called Pool		the same application functionality. The servers are called Pool
	Elements (PEs). Multiple PEs in a server pool can be used to provide		Elements (PEs). Multiple PEs in a server pool can be used to provide
	fault tolerance or load sharing, for example. The PEs register into		fault tolerance or load sharing, for example. The PEs register into
	and deregister out of the pool at an entity called the Endpoint		and deregister out of the pool at an entity called the Endpoint
	haNdlespace Redundancy Protocol (ENRP) server, using the Aggregate		haNdlespace Redundancy Protocol (ENRP) server, using the Aggregate
	Server Access Protocol ASAP [2] (this association is labelled ASAP(1)		Server Access Protocol ASAP [I-D.ietf-rserpool-asap] (this
	in the figure).		association is labelled ASAP(1) in the figure).
	Each server pool is identified by a unique byte string called the		Each server pool is identified by a unique byte string called the
	pool handle (PH). The pool handle allows a mapping from the pool to		pool handle (PH). The pool handle allows a mapping from the pool to
	a specific PE located by its IP address (both IPv4 and IPv6 PE		a specific PE located by its IP address (both IPv4 and IPv6 PE
	addresses are supported) and port number. The pool handle is what is		addresses are supported) and port number. The pool handle is what is
	specified by the Pool User (PU) when it attempts to access a server		specified by the Pool User (PU) when it attempts to access a server
	in the pool. To resolve the pool handle to the address necessary to		in the pool. To resolve the pool handle to the address necessary to
	access a PE, the PU consults an ENRP server using ASAP (this		access a PE, the PU consults an ENRP server using ASAP (this
	association is labeled ASAP(2) in the figure). The protocols used		association is labeled ASAP(2) in the figure). The space of pool
	between PU and PE are application-specific.		handles is assumed to be a flat space with limited operational scope
			(see RFC3237 [RFC3237]). Administration of pool handles is not
			addressed by the RSerPool protocol drafts at this time. The
			protocols used between PU and PE are application-specific. It is
			assumed that the PU and PE are configured to support a common set of
			protocols for application layer communication, independent of the
			RSerPool mechanisms.
	RSerPool provides a number of tools to aid client migration between		RSerPool provides a number of tools to aid client migration between
	servers on server failure: it allows the client to identify		servers on server failure: it allows the client to identify
	alternative servers, either on initial discovery or in real time; it		alternative servers, either on initial discovery or in real time; it
	also allows the original server to provide a state cookie to the		also allows the original server to provide a state cookie to the
	client that can be forwarded to an alternative server to provide		client that can be forwarded to an alternative server to provide
	application-specific state information. This information is		application-specific state information. This information is
	exchanged between PE and PU directly, over the association labeled PU		exchanged between PE and PU directly, over the association labeled PU
	to PE in the figure.		to PE in the figure.
	It is envisioned that ENRP servers provide a fully distributed and		It is envisioned that ENRP servers provide a fully distributed and
	fault-tolerant registry service. They use ENRP [3] to maintain		fault-tolerant registry service. They use ENRP
	synchronization of data concerning the pool handle mapping space.		[I-D.ietf-rserpool-enrp] to maintain synchronization of data
	For PUs and PEs, the ENRP servers are functionally equal. Due to the		concerning the pool handle mapping space. For PUs and PEs, the ENRP
	synchronization provided by ENRP, they can contact an arbitrary one		servers are functionally equal. Due to the synchronization provided
	for registration/deregistration (PE) or PH resolution (PU). An		by ENRP, they can contact an arbitrary one for registration/
	illustration containing 3 ENRP servers is provided in Figure 2 below:		deregistration (PE) or PH resolution (PU). An illustration
			containing 3 ENRP servers is provided in Figure 2 below:
	______ _____		______ _____
	... / ENRP \ / ENRP \ ...		... / ENRP \ / ENRP \ ...
	PEs/PUs <---->|Server| <----> |Server|<----> PEs/PUs		PEs/PUs <---->|Server| <----> |Server|<----> PEs/PUs
	... ASAP \______/ ENRP \______/ ASAP ...		... ASAP \______/ ENRP \______/ ASAP ...
	^ ^		^ ^
	| |		| |
	| / ENRP \ |		| / ENRP \ |
	+---->|Server|<----+		+---->|Server|<----+
	ENRP \______/ ENRP		ENRP \______/ ENRP
	^		^
	| ASAP		| ASAP
	v		v
	...		...
	PEs/PUs		PEs/PUs
	...		...
	Figure 2		Figure 2
	The requirements for the Reliable Server Pooling framework are		The requirements for the Reliable Server Pooling framework are
	defined in RFC3237 [1]. It is worth noting that the requirements on		defined in RFC3237 [RFC3237]. It is worth noting that the
	RSerPool in the area of load balancing partially overlap with GRID		requirements on RSerPool in the area of load balancing partially
	computing/high performance computing. However, the scope of both		overlap with GRID computing/high performance computing. However, the
	areas is completely different: GRID and high performance computing		scope of both areas is completely different: GRID and high
	also cover topics like managing different administrative domains,		performance computing also cover topics like managing different
	data locking and synchronization, inter-session communication and		administrative domains, data locking and synchronization, inter-
	resource accounting for powerful computation services, but the		session communication and resource accounting for powerful
	intention of RSerPool is simply a lightweight realization of load		computation services, but the intention of RSerPool is simply a
	distribution and session management. In particular, these		lightweight realization of load distribution and session management.
	functionalities are intended to be used on systems with small memory
	and CPU resources only. Any further functionality is not in the		In particular, these functionalities are intended to be used on
	scope of RSerPool and can -- if necessary -- provided by the		systems with small memory and CPU resources only. Any further
	application itself.		functionality is not in the scope of RSerPool and can -- if necessary
			-- provided by the application itself.
	This document provides an overview of the RSerPool protocol suite,		This document provides an overview of the RSerPool protocol suite,
	specifically the Aggregate Server Access Protocol ASAP [2] and the		specifically the Aggregate Server Access Protocol ASAP
	Endpoint Handlespace Redundancy Protocol ENRP [3]. In addition to		[I-D.ietf-rserpool-asap] and the Endpoint Handlespace Redundancy
	the protocol specifications, there is a common parameter format		Protocol ENRP [I-D.ietf-rserpool-enrp]. In addition to the protocol
	specification COMMON [4] for both protocols, a definition of server		specifications, there is a common parameter format specification
	selection rules (pool policies) POLICIES [5], as well as a security		COMMON [I-D.ietf-rserpool-common-param] for both protocols, a
	threat analysis THREATS [6].		definition of server selection rules (pool policies) POLICIES
			[I-D.ietf-rserpool-policies], as well as a security threat analysis
			THREATS [I-D.ietf-rserpool-threats].
	2. Aggregate Server Access Protocol (ASAP) Overview		2. Aggregate Server Access Protocol (ASAP) Overview
	ASAP defines a straight-forward set of mechanisms necessary to		ASAP defines a straight-forward set of mechanisms necessary to
	support the creation and maintenance of pools of redundant servers.		support the creation and maintenance of pools of redundant servers.
	These mechanisms include:		These mechanisms include:
	o registration of a new server into a server pool		o registration of a new server into a server pool
	o deregistration of an existing server from a pool		o deregistration of an existing server from a pool
	skipping to change at page 6, line 35		skipping to change at page 6, line 44
	o failover mechanisms for handling a server failure		o failover mechanisms for handling a server failure
	2.1. Pool Initialization		2.1. Pool Initialization
	Pools come into existence when a PE registers the first instance of		Pools come into existence when a PE registers the first instance of
	the pool name with an ENRP server. They disappear when the last PE		the pool name with an ENRP server. They disappear when the last PE
	deregisters. In other words, the starting of the first PE on some		deregisters. In other words, the starting of the first PE on some
	machine causes the creation of the pool when the registration reaches		machine causes the creation of the pool when the registration reaches
	the ENRP server.		the ENRP server.
			It is assumed that information needed for RSerPool, such as the
			address of an ENRP server to contact, is configured into the PE
			beforehand. Methods of automating this configuration process are not
			addressed at this time.
	2.2. Pool Entity Registration		2.2. Pool Entity Registration
	A new server joins an existing pool by sending a Registration message		A new server joins an existing pool by sending a Registration message
	via ASAP to an ENRP server, indicating the pool handle of the pool		via ASAP to an ENRP server, indicating the pool handle of the pool
	that it wishes to join, a PE identifier for itself (chosen randomly),		that it wishes to join, a PE identifier for itself (chosen randomly),
	information about its lifetime in the pool, and what transport		information about its lifetime in the pool, and what transport
	protocols and selection policy it supports. The ENRP server that it		protocols and selection policy it supports. The ENRP server that it
	first contacts is called its Home ENRP server, and maintains a list		first contacts is called its Home ENRP server, and maintains a list
	of subscriptions by the PE as well as performs periodic audits to		of subscriptions by the PE as well as performs periodic audits to
	confirm that the PE is still responsive.		confirm that the PE is still responsive.
	skipping to change at page 9, line 49		skipping to change at page 10, line 19
	available on the client system, there are typically only three		available on the client system, there are typically only three
	modifications required to the application source code:		modifications required to the application source code:
	1. Instead of specifying the hostnames of primary, secondary,		1. Instead of specifying the hostnames of primary, secondary,
	tertiary servers, etc., the application user specifies a pool		tertiary servers, etc., the application user specifies a pool
	handle.		handle.
	2. Instead of using a DNS based service (e.g. the Unix library		2. Instead of using a DNS based service (e.g. the Unix library
	function getaddrinfo()) to translate from a hostname to an IP		function getaddrinfo()) to translate from a hostname to an IP
	address, the application will invoke an RSerPool service		address, the application will invoke an RSerPool service
	primitive GETPRIMARYSERVER that takes as input a pool handle, and		primitive provisionally named GETPRIMARYSERVER that takes a pool
	returns the IP address of the primary server. The application		handle as input, and returns the IP address of the primary
	then uses that IP address just as it would have used the IP		server. The application then uses that IP address just as it
	address returned by the DNS in the previous scenario.		would have used the IP address returned by the DNS in the
			previous scenario.
	3. Without the use of additional RSerPool services, failure		3. Without the use of additional RSerPool services, failure
	detection and failover procedures must be designed into each		detection and failover procedures must be designed into each
	application. However, when failure is detected on the primary		application. However, when failure is detected on the primary
	server, instead of invoking DNS translation again on the hostname		server, instead of invoking DNS translation again on the hostname
	of a secondary server, the application invokes the service		of a secondary server, the application invokes a service
	primitive GETNEXTSERVER, which performs two functions in a single		primitive provisionally named GETNEXTSERVER, which performs two
	operation.		functions in a single operation.
	1. First it indicates to the RSerPool layer the failure of the		1. First, it indicates to the RSerPool layer the failure of the
	server returned by a previous GETPRIMARYSERVER or		server returned by a previous GETPRIMARYSERVER or
	GETNEXTSERVER call.		GETNEXTSERVER call.
	2. Second, it provides the IP address of the next server that		2. Second, it provides the IP address of the next server that
	should be contacted, according to the best information		should be contacted, according to the best information
	available to the RSerPool layer at the present time (e.g. set		available to the RSerPool layer at the present time (e.g. set
	of available pool elements, pool element policy in effect for		of available pool elements, pool element policy in effect for
	the pool, etc.).		the pool, etc.).
			Note: at the time of this document, a full API for use with RSerPool
			Protocols has not yet been defined.
	For pool element ("server") applications where an ASAP implementation		For pool element ("server") applications where an ASAP implementation
	is available, two changes are required to the application source		is available, two changes are required to the application source
	code:		code:
	1. The server should invoke the REGISTER service primitive upon		1. The server should invoke the REGISTER service primitive upon
	startup to add itself into the server pool using an appropriate		startup to add itself into the server pool using an appropriate
	pool handle. This also includes the address(es) protocol or		pool handle. This also includes the address(es) protocol or
	mapping id, port (if required by the mapping), and pooling		mapping id, port (if required by the mapping), and pooling
	policy(s).		policy(s).
	2. The server should invoke the DEREGISTER service primitive to		2. The server should invoke the DEREGISTER service primitive to
	remove itself from the server pool when shutting down.		remove itself from the server pool when shutting down.
	When using these RSerPool services, RSerPool provides benefits that		When using these RSerPool services, RSerPool provides benefits that
	are limited (as compared to utilizing all services), but nevertheless		are limited (as compared to utilizing all services), but nevertheless
	quite useful as compared to not using RSerPool at all. First, the		quite useful as compared to not using RSerPool at all. First, the
	client user need only supply a single string, i.e. the pool handle,		client user need only supply a single string, i.e. the pool handle,
	rather than a list of servers. Second, the decision as to which		rather than a list of servers. Second, the decision as to which
	server is to be used can be determined dynamically by the server		server is to be used can be determined dynamically by the server
	selection mechanism (i.e. a "pool policy" performed by ASAP; see ASAP		selection mechanism (i.e. a "pool policy" performed by ASAP; see ASAP
	[2]). Finally, when failures occur, these are reported to the pool		[I-D.ietf-rserpool-asap]). Finally, when failures occur, these are
	via signalling present in ASAP [2] and ENRP [3], other clients will		reported to the pool via signalling present in ASAP
	eventually know (once this failure is confirmed by other elements of		[I-D.ietf-rserpool-asap] and ENRP [I-D.ietf-rserpool-enrp], other
	the RSerPool architecture) that this server has failed.		clients will eventually know (once this failure is confirmed by other
			elements of the RSerPool architecture) that this server has failed.
	4.2. Example Scenario using RSerPool Session Services		4.2. Example Scenario using RSerPool Session Services
	When the full suite of RSerPool services is used, all communication		When the full suite of RSerPool services is used, all communication
	between the pool user and the pool element is mediated by the		between the pool user and the pool element is mediated by the
	RSerPool framework, including session establishment and teardown, and		RSerPool framework, including session establishment and teardown, and
	the sending and receiving of data. Accordingly, it is necessary to		the sending and receiving of data. Accordingly, it is necessary to
	modify the application to use the service primitives (i.e. the API)		modify the application to use the service primitives (i.e. the API)
	provided by RSerPool, rather than the transport layer primitives		provided by RSerPool, rather than the transport layer primitives
	provided by TCP, SCTP, or whatever transport protocol is being used.		provided by TCP, SCTP, or whatever transport protocol is being used.
	skipping to change at page 12, line 14		skipping to change at page 12, line 35
	failure in the communication link between A and B, PE B can use		failure in the communication link between A and B, PE B can use
	the information in the business card to contact an equivalent PE		the information in the business card to contact an equivalent PE
	to PU A from pool X.		to PU A from pool X.
	Additionally, if the application at PU A is aware of some		Additionally, if the application at PU A is aware of some
	particular PEs of pool X that would be preferred for B to contact		particular PEs of pool X that would be preferred for B to contact
	in the event that A becomes unreachable from B, PU A can provide		in the event that A becomes unreachable from B, PU A can provide
	that list to the ASAP layer, and it will be included in A's		that list to the ASAP layer, and it will be included in A's
	business card (see Section 2.5.2).		business card (see Section 2.5.2).
	5. Security Considerations		5. Reference Implementation
			The reference implementation of RSerPool is available at
			[RSerPoolPage] and described in [Dre2006].
			6. Security Considerations
	This document does not identify security requirements beyond those		This document does not identify security requirements beyond those
	already documented in the ENRP and ASAP protocol specifications. A		already documented in the ENRP and ASAP protocol specifications. A
	security threat analysis of RSerPool is provided in THREATS [6].		security threat analysis of RSerPool is provided in THREATS
			[I-D.ietf-rserpool-threats].
	6. IANA Considerations		7. IANA Considerations
	This document does not require additional IANA actions beyond those		This document does not require additional IANA actions beyond those
	already identified in the ENRP and ASAP protocol specifications.		already identified in the ENRP and ASAP protocol specifications.
	7. Acknowledgements		8. Acknowledgements
	The authors wish to thank Maureen Stillman, Qiaobing Xie, Randall		The authors wish to thank Maureen Stillman, Qiaobing Xie, Randall
	Stewart, Scott Bradner, and many others for their invaluable		Stewart, Scott Bradner, and many others for their invaluable
	comments.		comments.
	8. References		9. References
	8.1. Normative References		9.1. Normative References
	[1] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney,		[RFC3237] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L.,
	J., and M. Stillman, "Requirements for Reliable Server Pooling",		Loughney, J., and M. Stillman, "Requirements for Reliable
	RFC 3237, January 2002.		Server Pooling", RFC 3237, January 2002.
	[2] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate		[I-D.ietf-rserpool-asap]
	Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-18		Stewart, R., Xie, Q., Stillman, M., and M. Tuexen,
	(work in progress), November 2007.		"Aggregate Server Access Protocol (ASAP)",
			draft-ietf-rserpool-asap-19 (work in progress),
			March 2008.
	[3] Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A.		[I-D.ietf-rserpool-enrp]
	Silverton, "Endpoint Handlespace Redundancy Protocol (ENRP)",		Kim, D., Stewart, R., Stillman, M., Tuexen, M., and A.
	draft-ietf-rserpool-enrp-18 (work in progress), November 2007.		Silverton, "Endpoint Handlespace Redundancy Protocol
			(ENRP)", draft-ietf-rserpool-enrp-19 (work in progress),
			March 2008.
	[4] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate		[I-D.ietf-rserpool-common-param]
	Server Access Protocol (ASAP) and Endpoint Handlespace		Stewart, R., Xie, Q., Stillman, M., and M. Tuexen,
	Redundancy Protocol (ENRP) Parameters",		"Aggregate Server Access Protocol (ASAP) and Endpoint
	draft-ietf-rserpool-common-param-15 (work in progress),		Handlespace Redundancy Protocol (ENRP) Parameters",
	December 2007.		draft-ietf-rserpool-common-param-16 (work in progress),
			March 2008.
	[5] Tuexen, M. and T. Dreibholz, "Reliable Server Pooling Policies",		[I-D.ietf-rserpool-policies]
	draft-ietf-rserpool-policies-07 (work in progress),		Tuexen, M. and T. Dreibholz, "Reliable Server Pooling
	November 2007.		Policies", draft-ietf-rserpool-policies-08 (work in
			progress), March 2008.
	[6] Stillman, M., Gopal, R., Guttman, E., Holdrege, M., and S.		[I-D.ietf-rserpool-threats]
	Sengodan, "Threats Introduced by RSerPool and Requirements for		Stillman, M., Gopal, R., Guttman, E., Holdrege, M., and S.
	Security in Response to Threats",		Sengodan, "Threats Introduced by RSerPool and Requirements
	draft-ietf-rserpool-threats-09 (work in progress), October 2007.		for Security in Response to Threats",
			draft-ietf-rserpool-threats-11 (work in progress),
			April 2008.
	8.2. Informative References		9.2. Informative References
	[7] Dreibholz, T., "Thomas Dreibholz's RSerPool Page",		[RSerPoolPage]
			Dreibholz, T., "Thomas Dreibholz's RSerPool Page",
	URL: http://tdrwww.iem.uni-due.de/dreibholz/rserpool/.		URL: http://tdrwww.iem.uni-due.de/dreibholz/rserpool/.
	[8] Dreibholz, T., "Reliable Server Pooling -- Evaluation,		[Dre2006] Dreibholz, T., "Reliable Server Pooling -- Evaluation,
	Optimization and Extension of a Novel IETF Architecture", Ph.D.		Optimization and Extension of a Novel IETF Architecture",
	Thesis University of Duisburg-Essen, Faculty of Economics,		Ph.D. Thesis University of Duisburg-Essen, Faculty of
	Institute for Computer Science and Business Information Systems,		Economics, Institute for Computer Science and Business
	URL: http://duepublico.uni-duisburg-essen.de/servlets/		Information Systems, URL: http://
	DerivateServlet/Derivate-16326/Dre2006-final.pdf, March 2007.		duepublico.uni-duisburg-essen.de/servlets/DerivateServlet/
			Derivate-16326/Dre2006-final.pdf, March 2007.
	Authors' Addresses		Authors' Addresses
	Peter Lei		Peter Lei
	Cisco Systems, Inc.		Cisco Systems, Inc.
	955 Happfield Dr.		955 Happfield Dr.
	Arlington Heights, IL 60004		Arlington Heights, IL 60004
	US		US
	Phone: +1 773 695-8201		Phone: +1 773 695-8201
	skipping to change at page 15, line 44		skipping to change at line 669
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Acknowledgment
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).
End of changes. 36 change blocks.
	97 lines changed or deleted		131 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/