draft-ietf-rserpool-overview-00.txt		draft-ietf-rserpool-overview-01.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: April 18, 2007 Ciena Corporation		Expires: October 30, 2007 Ciena Corporation
	M. Tuexen		M. Tuexen
	Muenster Univ. of Applied Sciences		Muenster Univ. of Applied Sciences
	October 15, 2006		April 28, 2007
	An Overview of Reliable Server Pooling Protocols		An Overview of Reliable Server Pooling Protocols
	draft-ietf-rserpool-overview-00.txt		draft-ietf-rserpool-overview-01.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 37		skipping to change at page 1, line 37
	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 April 18, 2007.		This Internet-Draft will expire on October 30, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2007).
	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. ASAP Overview . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Aggregate Server Access Protocol (ASAP) Overview . . . . . . . 5
	2.1. Pool Initialization . . . . . . . . . . . . . . . . . . . 5		2.1. Pool Initialization . . . . . . . . . . . . . . . . . . . 5
	2.2. Pool Entity Registration . . . . . . . . . . . . . . . . . 5		2.2. Pool Entity Registration . . . . . . . . . . . . . . . . . 5
	2.3. Pool Entity Selection . . . . . . . . . . . . . . . . . . 5		2.3. Pool Entity Selection . . . . . . . . . . . . . . . . . . 6
	2.4. Endpoint Keepalive . . . . . . . . . . . . . . . . . . . . 6		2.4. Endpoint Keepalive . . . . . . . . . . . . . . . . . . . . 6
	2.5. Failover Services . . . . . . . . . . . . . . . . . . . . 6		2.5. Failover Services . . . . . . . . . . . . . . . . . . . . 6
	2.5.1. Cookie Mechanism . . . . . . . . . . . . . . . . . . . 6		2.5.1. Cookie Mechanism . . . . . . . . . . . . . . . . . . . 6
	2.5.2. Business Card Mechanism . . . . . . . . . . . . . . . 6		2.5.2. Business Card Mechanism . . . . . . . . . . . . . . . 7
	2.5.3. Failover Callback Mechanism . . . . . . . . . . . . . 7		3. Endpoint Nameserver Redundancy Protocol (ENRP) Overview . . . 7
	3. ENRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.1. Initialization . . . . . . . . . . . . . . . . . . . . . . 7		3.1. Initialization . . . . . . . . . . . . . . . . . . . . . . 7
	3.2. Server Discovery . . . . . . . . . . . . . . . . . . . . . 7		3.2. Server Discovery and Home Server Selection . . . . . . . . 7
	3.3. Server Pool Maintenance . . . . . . . . . . . . . . . . . 8		3.3. Server Pool Maintenance . . . . . . . . . . . . . . . . . 8
	4. Example Scenarios . . . . . . . . . . . . . . . . . . . . . . 8		4. Example Scenarios . . . . . . . . . . . . . . . . . . . . . . 8
	4.1. Example Scenario Using RSerPool Resolution Service . . . . 8		4.1. Example Scenario Using RSerPool Resolution Service . . . . 8
			4.1.1. Standalone Mode . . . . . . . . . . . . . . . . . . . 8
			4.1.2. Pool Mode . . . . . . . . . . . . . . . . . . . . . . 8
	4.2. Example Scenario Using RSerPool Session Services . . . . . 9		4.2. Example Scenario Using RSerPool Session Services . . . . . 9
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 10		5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
	8. Normative References . . . . . . . . . . . . . . . . . . . . . 11		8. Normative References . . . . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
	Intellectual Property and Copyright Statements . . . . . . . . . . 13		Intellectual Property and Copyright Statements . . . . . . . . . . 13
	1. Introduction		1. Introduction
	The requirements for the Reliable Server Pooling effort are defined		The Reliable Server Pooling (RSerPool) protocol suite is designed to
	in RFC3237 [2]. The central idea of this architecture is to provide		provide client applications ("pool users") with the ability to select
	client applications ("pool users") with the ability to select a		a server (a "pool element") from among a group of servers providing
	server (a "pool element") from among a group of servers providing		equivalent service (a "pool").
	equivalent service (a "pool"). The pool is accessed via an
	identifier called a "pool handle", which is a location-independent
	name separate from the IP address of any pool server.
	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 34		skipping to change at page 4, line 34
	. +-------+ .		. +-------+ .
	.......................		.......................
	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 deregisters out of the pool using the Aggregate Server Access		and deregisters out of the pool using the Aggregate Server Access
	Protocol ASAP [3].		Protocol ASAP [2].
	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. The pool handle allows a mapping from the pool to a		pool handle. The pool handle allows a mapping from the pool to a
	specific Pool Element located by its IP address and port. The pool		specific Pool Element located by its IP address and port. The pool
	handle is what is specified by the Pool User (PU) when it attempts to		handle is what is specified by the Pool User (PU) when it attempts to
	access a server in the pool, again using ASAP. Both IPv4 and IPv6 PE		access a server in the pool, again using ASAP. Both IPv4 and IPv6 PE
	addresses are supported.		addresses are supported.
	To resolve the pool handle to the address necessary to access a Pool		To resolve the pool handle to the address necessary to access a Pool
	Element, the PU consults an entity called the Endpoint haNdlespace		Element, the PU consults an entity called the Endpoint haNdlespace
	Redundancy Protocol (ENRP) server. This server may be a standalone		Redundancy Protocol (ENRP) server. This server may be a standalone
	server supporting many PUs or a part of the PU itself, however it is		server supporting many PUs or a part of the PU itself, however it is
	envisioned that ENRP servers provide a fully distributed and fault-		envisioned that ENRP servers provide a fully distributed and fault-
	tolerant registry service using ENRP [4] to maintain synchronization		tolerant registry service using ENRP [3] to maintain synchronization
	of data concerning the pool handle mapping space.		of data concerning the pool handle mapping space.
			Rserpool provides a number of tools to aid client migration between
			servers on server failure: it allows the client to identify
			alternative servers, either on initial discovery or in real time; it
			also allows the original server to provide a state cookie to the
			client that can be forwarded to an alternative server to provide
			application-specific state information.
			The requirements for the Reliable Server Pooling effort are defined
			in RFC3237 [1].
	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 [3] and the		specifically the Aggregate Server Access Protocol ASAP [2] and the
	Endpoint Nameserver Redundancy Protocol ENRP [4].		Endpoint Nameserver Redundancy Protocol ENRP [3].
	In addition to the protocol specifications, there is a common		In addition to the protocol specifications, there is a common
	parameter format specification COMMON [5] for both protocols, as well		parameter format specification COMMON [4] for both protocols, as well
	as a security threat analysis SEC [6].		as a security threat analysis SEC [5].
	2. ASAP Overview		2. Aggregate Server Access Protocol (ASAP) Overview
	ASAP is a straight-forward implementation of a set of mechanisms		ASAP is a straight-forward implementation of a set of mechanisms
	identified as necessary for support of the creation and maintenance		identified as necessary for support of the creation and maintenance
	of pools of redundant servers. These mechanisms include:		of pools of redundant servers. These mechanisms include:
	o registration of a new server for the server pool		o registration of a new server for the server pool
	o deregistration of an existing server in the pool		o deregistration of an existing server from the pool
	o resolution of a pool 'handle' to a server or list		o resolution of a pool 'handle' to a server or list of servers
	o liveness detection for servers in the pool		o liveness detection for servers in the pool
	o failover mechanisms for handling server failure		o failover mechanisms for handling 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. They disappear when the last PE deregisters. In		the pool name with an ENRP server. They disappear when the last PE
	other words, the starting of the first PE on some machine causes the		deregisters. In other words, the starting of the first PE on some
	creation of the pool when the registration reaches the ENRP server.		machine causes the creation of the pool when the registration reaches
			the ENRP server.
	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
	in ASAP indicating the 'handle' of the pool that it wishes to join, a		in ASAP to an ENRP server, indicating the 'handle' of the pool that
	pool identifier for itself (chosen randomly) information about it's		it wishes to join, a pool identifier for itself (chosen randomly)
	lifetime in the pool, and what transport protocols and selection		information about it's lifetime in the pool, and what transport
	policies it supports. The Registration message is sent to its Home		protocols and selection policies it supports. The ENRP server that
	ENRP server.		it first contacts is called its Home ENRP server, and maintains a
			list of subscriptions by the PE as well as performing periodic audits
			to confirm that the PE is still responsive.
	Similar procedures are applied to de-register itself from the server		Similar procedures are applied to de-register itself from the server
	pool (or alternatively the server may simply let its previously state		pool (or alternatively the server may simply let the lifetime that it
	lifetime expire and be gracefully removed from the pool.		previously registered with expire, after which it is gracefully
			removed from the pool.
	2.3. Pool Entity Selection		2.3. Pool Entity Selection
	When an endpoint wishes to be connected to a server in the pool, this		When an endpoint wishes to be connected to a server in the pool, it
	requires the resolution of a server 'handle' to the IP addresses of a		genereates a Handle Resolution message in ASAP and sends this to its
	server or list of servers in the pool. This process may involve a		home ENRP server. The ENRP server resolves the handle based on its
	number of policies for server selection, for which the RSerPool		knowledge of pool servers and returns a Handle Resolution Response in
	protocol suite supports a few simply defined policies and allows the		ASAP. The Resolution Response contains a list of the IP addresses of
	use of external server selection input for more complex policies.		one or more servers in the pool that can be contacted. The process
			by which the list of servers is created may involve a number of
	The endpoint generates a Handle Resolution message in ASAP and sends		policies for server selection. The RSerPool protocol suite supports
	this to its home ENRP server to start the resolution process. The		a few simply defined policies and allows the use of external server
	ENRP server resolves the handle based on its knowledge of pool		selection input for more complex policies.
	servers and returns a Handle Resolution Response in ASAP.
	2.4. Endpoint Keepalive		2.4. Endpoint Keepalive
	In order to maintain status information for members of the server		ENRP servers monitor the status of pool elements using the ASAP Keep
	pool, the ENRP server may audit the status of a particular pool		Alive message. A Pool Element responds to the ASAP Keep Alive
	element using an ASAP Keep Alive message. When received by the pool		message with an Ack response.
	element, it responds by verifying its membership in the pool in an
	Ack message.
	When a PE is found to be unreachable, for example, an endpoint		In addition, an endpoint can notify its home ENRP server that the PE
	conversing with the pool element finds that it can no longer be		the endpoint was using has become unresponsive by sending the ENRP
	reached by its transport connection, the endpoint can also inform its		server an Endpoint Unreachable message.
	home ENRP server by sending an Endpoint Unreachable message.
	2.5. Failover Services		2.5. Failover Services
	While maintaining application-independence, the RSerPool protocol		While maintaining application-independence, the RSerPool protocol
	suite provides some simple hooks for supporting failover of an		suite provides some simple hooks for supporting failover of an
	individual session with a pool element. Generally, mechanisms for		individual session with a pool element. Generally, mechanisms for
	failover that rely on application state or transaction status cannot		failover that rely on application state or transaction status cannot
	be supported without more specific knowledge of the application being		be defined without more specific knowledge of the application being
	supported. However, some simple mechanisms supported by RSerPool		supported. However, some simple mechanisms supported by RSerPool
	allow some level of failover that any application can use.		allow some level of failover that any application can use.
	2.5.1. Cookie Mechanism		2.5.1. Cookie Mechanism
	Cookies may optionally be generated by the ASAP layer and		Cookies may optionally be generated by the ASAP layer and
	periodically sent from the PE to the PU. The PU only stores the last		periodically sent from the PE to the PU. The PU only stores the last
	received cookie. In case of fail over the PU sends this last		received cookie. In case of fail over the PU sends this last
	received cookie to the new PE. This method provides a simple way of		received cookie to the new PE. This method provides a simple way of
	state sharing between the PEs. Please note that the old PE should		state sharing between the PEs. Please note that the old PE should
	skipping to change at page 7, line 9		skipping to change at page 7, line 19
	2.5.2. Business Card Mechanism		2.5.2. Business Card Mechanism
	A PE can send a business card to its peer (PE or PU) containing its		A PE can send a business card to its peer (PE or PU) containing its
	pool handle and guidance concerning which other PEs the peer should		pool handle and guidance concerning which other PEs the peer should
	use for failover. This gives a PE a means of telling a PU what it		use for failover. This gives a PE a means of telling a PU what it
	identifies as the "next best" PE to use in case of failure, which may		identifies as the "next best" PE to use in case of failure, which may
	be based on pool considerations, such as load balancing, or user		be based on pool considerations, such as load balancing, or user
	considerations, such as PEs that have the most up-to-date state		considerations, such as PEs that have the most up-to-date state
	information.		information.
	2.5.3. Failover Callback Mechanism		3. Endpoint Nameserver Redundancy Protocol (ENRP) Overview
	TBD
	3. ENRP
	ENRP is used between ENRP servers in order to maintain a distributed,		A server pool can be supported by one or more ENRP servers. If
	fault-tolerant real-time registry service. ENRP servers communicate		multiple ENRP servers are used to support a single pool then the ENRP
	with each other in order to exchange information such as pool		protocol is used between the ENRP servers in order to maintain a
	membership changes, handlespace data synchronization, etc.		distributed, fault-tolerant real-time registry service. ENRP servers
			communicate with each other in order to exchange information such as
			pool membership changes, handlespace data synchronization, etc.
	3.1. Initialization		3.1. Initialization
	Each ENRP server initially generates a 32-bit server ID that it uses		Each ENRP server initially generates a 32-bit server ID that it uses
	in subsequent messaging and remains unchanged over the lifetime of		in subsequent messaging and remains unchanged over the lifetime of
	the server. It then attempts to learn all of the other ENRP servers		the server. It then attempts to learn all of the other ENRP servers
	within the scope of the server pool, either using a pre-defined		within the scope of the server pool, either by using a pre-defined
	Mentor server or by sending out Presence messages on a well-known		Mentor server or by sending out Presence messages on a well-known
	multicast channel to determine other ENRP servers from the responses		multicast channel to determine other ENRP servers from the responses
	and select one as Mentor.		and select one as Mentor. A Mentor can be any peer ENRP server that
			it selects to provide current data about the pool.
	It then requests the most current data about the pool handlespace		It then requests the most current data about the pool handlespace
	from its Mentor server and unpacks received Handle Table Response		from its Mentor server and unpacks received Handle Table Response
	messages into its local database.		messages into its local database.
	It is then ready to provide ENRP services.		It is then ready to provide ENRP services.
	3.2. Server Discovery		3.2. Server Discovery and Home Server Selection
	PEs can now register their presence with the newly functioning ENRP		PEs can now register their presence with the newly functioning ENRP
	server by using ASAP messages. They discover the new ENRP server		server by using ASAP messages. They discover the new ENRP server
	after the server sends out an ASAP Server Announce message on the		after the server sends out an ASAP Server Announce message on the
	well-known ASAP multicast channel.		well-known ASAP multicast channel. PEs need only register with one
			ENRP server, as other ENRP servers supporting the pool will
			synchronize their knowledge about pool elements using the ENRP
			protocol.
	The PE may have a configured list of ENRP servers to talk to, in		The PE may have a configured list of ENRP servers to talk to, in the
	which case it will start to setup associations with some number of		form of a list of IP addresses, in which case it will start to setup
	them and assign the first one that responds to it as its Home ENRP		associations with some number of them and assign the first one that
	Server.		responds to it as its Home ENRP Server.
	Alternatively it can listen on the multicast channel for a set period		Alternatively it can listen on the multicast channel for a set period
	and when it hears an ENRP server, start an association. The first		and when it hears an ENRP server, start an association. The first
	server it gets up can then become its Home ENRP Server.		server it gets up can then become its Home ENRP Server.
	3.3. Server Pool Maintenance		3.3. Server Pool Maintenance
	PE failure detection, keepalive, etc. TBD		PE failure detection, keepalive, etc. TBD
	4. Example Scenarios		4. Example Scenarios
	4.1. Example Scenario Using RSerPool Resolution Service		4.1. Example Scenario Using RSerPool Resolution Service
			4.1.1. Standalone Mode
	RSerPool can be used in a 'standalone' manner, where the application		RSerPool can be used in a 'standalone' manner, where the application
	uses RSerPool to determine the address of a primary server in the		uses RSerPool to determine the address of a primary server in the
	pool, and then interacts directly with that server without further		pool, and then interacts directly with that server without further
	use of RSerPool services. If the initial server fails, the		use of RSerPool services. If the initial server fails, the
	application uses RSerPool again to find the next server in the pool.		application uses RSerPool again to find the next server in the pool.
			4.1.2. Pool Mode
	For pool user ("client") applications, if an ASAP implementation is		For pool user ("client") applications, if an ASAP implementation is
	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 gethostbyname()) to translate from a hostname to an IP		function gethostbyname()) to translate from a hostname to an IP
	skipping to change at page 9, line 25		skipping to change at page 9, line 43
	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
	[3]). Finally, when failures occur, these are reported to the pool		[2]). Finally, when failures occur, these are reported to the pool
	via signaling present in ASAP [3] and ENRP [4], other clients will		via signaling present in ASAP [2] and ENRP [3], other clients will
	eventually know (once this failure is confirmed by other elements of		eventually know (once this failure is confirmed by other elements of
	the RSerPool architecture) that this server has failed.		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 are used, all communication		When the full suite of RSerPool services are 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.
	As in the previous case, sessions (rather than connections or		As in the previous case, sessions (rather than connections or
	associations) are established, and the destination endpoint is		associations) are established, and the destination endpoint is
	specified as a pool handle rather than as a list of IP addresses with		specified as a pool handle rather than as a list of IP addresses with
	a port number. However, failover from one pool element to another is		a port number. However, failover from one pool element to another is
	fully automatic, and can be transparent to the application:		fully automatic, and can be transparent to the application (so long
			as the application has saved enough state in a state cookie):
	The RSerPool framework control channel provides maintainance		The RSerPool framework control channel provides maintenance
	functions to keep pool element lists, policies, etc. current.		functions to keep pool element lists, policies, etc. current.
	Since the application data (e.g. data channel) is managed by the		Since the application data (e.g. data channel) is managed by the
	RSerPool framework, unsent data (data not yet submitted by		RSerPool framework, unsent data (data not yet submitted by
	RSerPool to the underlying transport protocol) is automatically		RSerPool to the underlying transport protocol) is automatically
	redirected to the newly selected pool element upon failover. If		redirected to the newly selected pool element upon failover. If
	the underlying transport layer supports retrieval of unsent data		the underlying transport layer supports retrieval of unsent data
	(as in SCTP), retrieved unsent data can also be automatically re-		(as in SCTP), retrieved unsent data can also be automatically re-
	sent to the newly selected pool element.		sent to the newly selected pool element.
	skipping to change at page 11, line 8		skipping to change at page 11, line 24
	already documented in the ENRP and ASAP protocol specifications.		already documented in the ENRP and ASAP protocol specifications.
	6. IANA Considerations		6. 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		7. Acknowledgements
	The authors wish to thank Maureen Stillman, Qiaobing Xie, Randall		The authors wish to thank Maureen Stillman, Qiaobing Xie, Randall
	Stewart, and many others for their invaluable comments.		Stewart, Scott Bradner, and many others for their invaluable
			comments.
	8. Normative References		8. Normative References
	[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[1] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney,
	Levels", BCP 14, RFC 2119, March 1997.
	[2] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney,
	J., and M. Stillman, "Requirements for Reliable Server Pooling",		J., and M. Stillman, "Requirements for Reliable Server Pooling",
	RFC 3237, January 2002.		RFC 3237, January 2002.
	[3] Stewart, R., "Aggregate Server Access Protocol (ASAP)",		[2] Stewart, R., "Aggregate Server Access Protocol (ASAP)",
	draft-ietf-rserpool-asap-13 (work in progress), February 2006.		draft-ietf-rserpool-asap-15 (work in progress), January 2007.
	[4] Stewart, R., "Endpoint Handlespace Redundancy Protocol (ENRP)",		[3] Stewart, R., "Endpoint Handlespace Redundancy Protocol (ENRP)",
	draft-ietf-rserpool-enrp-13 (work in progress), February 2006.		draft-ietf-rserpool-enrp-15 (work in progress), January 2007.
	[5] Stewart, R., "Aggregate Server Access Protocol (ASAP) and		[4] Stewart, R., "Aggregate Server Access Protocol (ASAP) and
	Endpoint Handlespace Redundancy Protocol (ENRP) Parameters",		Endpoint Handlespace Redundancy Protocol (ENRP) Parameters",
	draft-ietf-rserpool-common-param-10 (work in progress),		draft-ietf-rserpool-common-param-11 (work in progress),
	February 2006.		October 2006.
	[6] Stillman, M., "Threats Introduced by Rserpool and Requirements		[5] Stillman, M., "Threats Introduced by Rserpool and Requirements
	for Security in response to Threats",		for Security in response to Threats",
	draft-ietf-rserpool-threats-05 (work in progress), July 2005.		draft-ietf-rserpool-threats-06 (work in progress),
			November 2006.
	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 13, line 7		skipping to change at page 13, line 7
	Michael Tuexen		Michael Tuexen
	Muenster Univ. of Applied Sciences		Muenster Univ. of Applied Sciences
	Stegerwaldstr. 39		Stegerwaldstr. 39
	48565 Steinfurt		48565 Steinfurt
	Germany		Germany
	Email: tuexen@fh-muenster.de		Email: tuexen@fh-muenster.de
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2007).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Intellectual Property		Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
End of changes. 50 change blocks.
	101 lines changed or deleted		115 lines changed or added
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/