Reliable Server Pooling (rserpool) ---------------------------------- Charter Last Modified: 2008-07-31 Current Status: Active Working Group Chair(s): Maureen Stillman Lyndon Ong Transport Area Director(s): Magnus Westerlund Lars Eggert Transport Area Advisor: Magnus Westerlund Technical Advisor(s): Ned Freed Mailing Lists: General Discussion:rserpool@ietf.org To Subscribe: rserpool-request@ietf.org In Body: subscribe email_address Archive: http://www.ietf.org/mail-archive/web/rserpool/index.html Description of Working Group: The purpose of the WG is to develop an architecture and protocols for the management and operation of server pools supporting highly reliable applications, and for client access mechanisms to a server pool. The WG will define architecture and requirements for management and access to server pools, including requirements from a variety of applications, building blocks and interfaces, different styles of pooling, security requirements and performance requirements, such as failover times and coping with heterogeneous latencies. This will be documented in an Informational RFC. Scope: The working group will focus on supporting high availability and scalability of applications through the use of pools of servers. This requires both a way to keep track of what servers are in the pool and are able to receive requests and a way for the client to bind to a desired server. The Working Group will NOT address: 1) reliable multicast protocols - the use of multicast for reliable server pooling is optional. Reliable multicast protocols will be developed by the RMT WG. 2) synchronization/consistency of data between server pool elements, e.g. shared memory 3) mechanisms for sharing state information between server pool elements 4) Transaction failover. If a server fails during processing of a transaction this transaction may be lost. Some services may provide a way to handle the failure, but this is not guaranteed. The WG will address client access mechanisms for server pools, specifically: 1) An access mechanism that allows geographically dispersed servers in the pool 2) A client-server binding mechanism that allows dynamic assignment of client to servers based on load balancing or application specific assignment policies. 3) Support of automatic reconfiguration of the client/server binding in case of server failure or administrative changes. To the extent that new protocols are necessary to support the requirements for server pooling, these will be documented in a Standards Track RFC on client access to a binding service (i.e. name space) protocol. The WG will also address use of proxying to interwork existing client access mechanisms to any new binding service. The WG will address server pool management and a distributed service to support client/server binding, including: 1) A scalable mechanism for tracking server pool membership (incl. registration) 2) A scalable protocol for performing node failure detection, reconfiguration and failover, and otherwise managing the server pool (supporting caching, membership, query, authentication, and security) 3) A distributed service to support binding of clients to servers, based on information specific to the server pool. Given that this service is essential to access the server pool, a high degree of availability is necessary. 4) A means for allowing flexible load assignment and balancing policies The protocols and procedures for server pool management will be documented in a Standards Track RFC. The WG will address: - transport protocol(s) that would be supported (eg. UDP, SCTP, TCP) - any new congestion management issues - relationship to existing work such as URI resolution mechanisms Rserpool will consult with other IETF working groups such as Reliable multicast, DNS extensions, AAA, URN, WREC and Sigtran as appropriate and will not duplicate any of these efforts. Goals and Milestones: Done Initial draft of Protocol Comparison Done Initial draft of Threat Analysis Done Initial draft of MIB Done Initial draft of Rserpool Services document Done Initial draft of Pool Management document Done Initial draft of Rserpool Architecture document Done Initial draft of Binding Service document Done Submit Requirements document to IESG for Informational RFC Done Submit Comparison document to IESG for Informational RFC Done Initial draft of Resrpool Requirements document Done Initial draft of TCP Mapping document Done Initial draft of Applicability Statement Done Submit Architecture draft to IESG for Informational RFC Done Submit Threat Analysis to IESG for Informational RFC Done Initial draft of RSERPOOL Overview document Done Revised versions of protocol specification drafts Done Finished review cycle with at least 2 external reviewers Done Threats Analysis updated to align with specification Done Updated drafts submitted based on review comments Done WG discussion on any outstanding issues. Done WG last call on protocol specifications, Threats Analysis and Overview document Done Overview, Threat Analysis and Protocol specifications submitted to IESG for Informational, Informational and Experimental respectively. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- May 2002 Feb 2009 Reliable Server Pooling MIB Module Definition Request For Comments: RFC Stat Published Title ------- -- ----------- ------------------------------------ RFC3237 I Jan 2002 Requirements for Reliable Server Pooling RFC5351 I Sep 2008 An Overview of Reliable Server Pooling Protocols RFC5352 E Sep 2008 Aggregate Server Access Protocol (ASAP) RFC5353 E Sep 2008 Endpoint Handlespace Redundancy Protocol (ENRP) RFC5355 I Sep 2008 Threats Introduced by RSerPool and Requirements for Security in Response to Threats RFC5354 E Sep 2008 Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters RFC5356 E Sep 2008 Reliable Server Pooling Policies