Current Meeting Report
Jabber Logs

2.8.14 Reliable Server Pooling (rserpool)

NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 05/06/2002

Lyndon Ong <>
Maureen Stillman <>
Transport Area Director(s):
Scott Bradner <>
A. Mankin <>
Transport Area Advisor:
Scott Bradner <>
Technical Advisor(s):
Ned Freed <>
Mailing Lists:
General Discussion:
To Subscribe:
In Body: subscribe email_address
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 RSPool Requirements And Architecture document
Done  Submit Reqts draft to IESG for consideration as an Informational RFC
Done  Initial draft of Binding Service document
Done  Initial draft of Client/server binding and Server Pool Management document
NOV 01  Submit Architecture draft to IESG for consideration as an Informational RFC
JAN 02  Submit drafts of Binding Service and Server Pool Management to IESG for consideration as Proposed Standard RFCs
  • - draft-ietf-rserpool-arch-03.txt
  • - draft-ietf-rserpool-comp-04.txt
  • - draft-ietf-rserpool-asap-04.txt
  • - draft-ietf-rserpool-enrp-03.txt
  • - draft-ietf-rserpool-common-param-00.txt
  • - draft-ietf-rserpool-mib-00.txt
  • Request For Comments:
    RFC3237 I Requirements for Reliable Server Pooling

    Current Meeting Report

    Reliable Server Pooling WG (rserpool)
    Monday, November 18 at 1530-1730
    co-CHAIRs: Maureen Stillman 
    	   Lyndon Ong <> 
    Approximately 30 people attended this meeting.  
    We discussed the services document 
    draft-conrad-rserpool-service-02.  This describes the different 
    services that rserpool can offer to the application.  There are 
    currently eight services defined and some new services being worked on.  It 
    has been updated to allow TCP or SCTP for PU communication with the ENRP 
    server and any transport protocol for the application i.e. PU-PE 
    transport.  Service descriptions may need to be further refined on the 
    mailing list.  The services document was accepted as a Rserpool WG item.
    We discussed the TCP mapping document 
    draft-conrad-rserpool-tcpmapping-01.  The TCP mapping is a shim layer that 
    provides an SCTP-like encapsulation/framing header.  The TCP mapping 
    document was accepted as a Rserpool WG item.
    We discussed the Rserpool architecture 
    draft-ietf-rserpool-arch-03.txt.  Control channel and data channel need to be 
    clearly defined in terms of what messages are sent on each channel 
    associated with each service.  Further discussion will continue on the 
    We discussed issues concerning business cards and state sharing 
    information in connection with ASAP.  Work on the protocol is ongoing.
    We discussed issues concerning multicast and security in ENRP.  Three 
    alternatives can be considered -- use multicast at your own risk, make 
    multicast secure or abandon multicast.  Also, we need to investigate a 
    mixed network multicast and unicast.  Further discussion will follow on the 
    mailing list.
    The security threat document 
    draft-stillman-rserpool-threats-02 has been on hold for the last six 
    months while Rserpool experienced several significant protocol changes.  We 
    need to reexamine the document in light of recent changes to see if any 
    updates are required.  Also,  we need to revisit the security 
    architecture for Rserpool.  This task will be performed by the Rserpool 
    security design team.  The security threat document was accepted as a 
    Rserpool WG item.
    We had a discussion with the members of the IPFix (IP Flow 
    Information Export) WG concerning their possible use of Reliable Server 
    Pooling.  They are working on a standard to export router flow 
    information in a standard way.  The exporter sends information to one or 
    more collectors.  It is these collectors that could form a reliable 
    server pool.  We investigated the possibility of adding a new service to 
    Reliable Server Pooling in order to meet their requirements.  Further 
    discussions will follow.


    ASAP Changes
    Endpoint Name Resolution Protocol