2.7.12 Reliable Server Pooling (rserpool)

NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-01-22

Lyndon Ong <lyong@ciena.com>
Maureen Stillman <maureen.stillman@nokia.com>
Transport Area Director(s):
Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>
Transport Area Advisor:
Jon Peterson <jon.peterson@neustar.biz>
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: ftp://ftp.ietf.org/ietf-mail-archive/rserpool/
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.


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
Mar 03  Submit Services document to IESG for Informational RFC
Done  Submit Architecture draft to IESG for Informational RFC
May 03  Submit TCP mapping to IESG for Proposed Standard RFC
Done  Submit Threat Analysis to IESG for Informational RFC
Aug 03  Submit Binding Service and Pool Management to IESG for Proposed Standard RFC
Aug 03  Submit Applicability Statement to IESG for Informational RFC
Nov 03  Submit MIB to IESG for Proposed Standard RFC
  • - draft-ietf-rserpool-arch-07.txt
  • - draft-ietf-rserpool-comp-07.txt
  • - draft-ietf-rserpool-asap-08.txt
  • - draft-ietf-rserpool-enrp-07.txt
  • - draft-ietf-rserpool-common-param-05.txt
  • - draft-ietf-rserpool-threats-02.txt
  • - draft-ietf-rserpool-applic-01.txt
  • - draft-ietf-rserpool-tcpmapping-01.txt
  • - draft-ietf-rserpool-service-00.txt
  • Request For Comments:
    RFC3237 I Requirements for Reliable Server Pooling

    Current Meeting Report

    Reliable Server Pooling
    Minutes from IETF #59
    Approximately 30 people attended the meeting at IETF #59.
    Lyndon Ong; lyong@ciena.com
    Maureen Stillman; maureen.stillman@nokia.com
    We discussed the services document 
    draft-ietf-rserpool-service-00.txt.  This document was recently updated and 
    posted to the list.  We request that people read the document and send 
    comments to the list.   
    Next we discussed the Rserpool architecture, 
    draft-ietf-rserpool-arch-07.txt which is in IESG review.  The IESG 
    requested some changes to this document which raised some issues.  
    Specifically questions were raised about whether the protocols should be 
    split into more pieces to aid in its understanding and possibly to aid in 
    implementation.  This topic needs to be investigated further.
    The comparison document 
    draft-ietf-rserpool-comparison-07.txt was added to the agenda because the 
    issues raised by the reserpool architecture review also had impact on the 
    comparison document.  Further issues were raised by the AD review 
    concerning evaluation of other IETF protocols such as Dynamic 
    Delegation Discovery System (DDDS) RFC 3401-6 and Extensible 
    Provisioning Protocol (EPP) draft-ietf-provreg-epp-09 in relation to 
    Rserpool.  We need to evaluate these protocols and reach a 
    determination about their applicability to Rserpool.  Also the issue of 
    using URN was raised.  Rserpool uses pool handle names in ASCII format 
    rather than URN.  This is due to issues such as hierarchy in the name 
    resolution process.  The Rserpool name space is not hierarchical.  The 
    comment was that this seems to be an architectural issue rather than a 
    comparison document issue.
    The Rserpool security threat document 
    draft-ietf-rserpool-threats-02.txt is also in AD review.  Comments were 
    also received from the AD and have been added to -03.  This draft will be 
    sent to be published after IETF 59.  A summary of the threats and 
    mitigations was presented.  This is the text added to the security 
    considerations section in response to AD review.  An issue was raised 
    about the security of cookies. Cookies are not part of the Rserpool 
    infrastructure, but it might make sense to provide security guidance on 
    this area.  The security design team will evaluate this issue and make a 
    recommendation.  This issue should also be discussed on the list.
    We will continue to work on documents that have been reviewed by our ADs.  
    Updated internet-drafts are being generated in response to 


    Services Provided by RSerPool
    Reliable Server Pooling Architecture
    Comparison of Protocols for Reliable Server Pooling
    Rserpool Security