Reliable Server Pooling (rserpool)
----------------------------------

 Charter
 Last Modified: 2006-11-08

 Current Status: Active Working Group

 Chair(s):
     Lyndon Ong  <lyong@ciena.com>
     Maureen Stillman  <maureen.stillman@nokia.com>

 Transport Area Director(s):
     Magnus Westerlund  <magnus.westerlund@ericsson.com>
     Lars Eggert  <lars.eggert@netlab.nec.de>

 Transport Area Advisor:
     Magnus Westerlund  <magnus.westerlund@ericsson.com>

 Technical Advisor(s):
     Ned Freed  <ned.freed@mrochek.com>

 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 

   Nov 2006       Initial draft of RSERPOOL Overview document 

   Dec 2006       Revised versions of protocol specification drafts 

   Jan 2007       Finished review cycle with at least 2 external reviewers 

   Jan 2007       Threats Analysis updated to align with specification 

   Feb 2007       Updated drafts submitted based on review comments 

   Mar 2007       WG discussion on any outstanding issues. 

   Apr 2007       WG last call on protocol specifications, Threats Analysis and 
                Overview document 

   May 2007       Overview, Threat Analysis and Protocol specifications submitted 
                to IESG for Informational, Informational and Experimental 
                respectively. 


 Internet-Drafts:

Posted Revised         I-D Title   <Filename>
------ ------- --------------------------------------------
Apr 2001 Nov 2006   <draft-ietf-rserpool-arch-12.txt>
                Architecture for Reliable Server Pooling 

Jun 2001 Oct 2006   <draft-ietf-rserpool-asap-14.txt>
                Aggregate Server Access Protocol (ASAP) 

Jun 2001 Nov 2006   <draft-ietf-rserpool-enrp-14.txt>
                Endpoint Handlespace Redundancy Protocol (ENRP) 

May 2002 Oct 2006   <draft-ietf-rserpool-common-param-11.txt>
                Aggregate Server Access Protocol (ASAP) and Endpoint 
                Handlespace Redundancy Protocol (ENRP) Parameters 

May 2002 Aug 2006   <draft-ietf-rserpool-mib-03.txt>
                Reliable Server Pooling: Management Information Base using 
                SMIv2 

Oct 2004 Sep 2006   <draft-ietf-rserpool-policies-03.txt>
                Reliable Server Pooling Policies 

Oct 2006 Oct 2006   <draft-ietf-rserpool-overview-00.txt>
                An Overview of Reliable Server Pooling Protocols 

 Request For Comments:

  RFC   Stat Published     Title
------- -- ----------- ------------------------------------
RFC3237 I    Jan 2002    Requirements for Reliable Server Pooling