2.8.13 Reliable Server Pooling (rserpool)
NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.
Last Modified: 2005-10-03
Lyndon Ong <email@example.com>
Maureen Stillman <firstname.lastname@example.org>
Transport Area Director(s):
Allison Mankin <email@example.com>
Jon Peterson <firstname.lastname@example.org>
Transport Area Advisor:
Jon Peterson <email@example.com>
Ned Freed <firstname.lastname@example.org>
General Discussion: email@example.com
To Subscribe: firstname.lastname@example.org
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
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,
1) An access mechanism that allows geographically dispersed servers in
2) A client-server binding mechanism that allows dynamic assignment of
client to servers based on load balancing or application specific
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
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.
2) A scalable protocol for performing node failure detection,
reconfiguration and failover, and otherwise managing the server pool
(supporting caching, membership, query, authentication,
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 2003|| ||Submit Services document to IESG for Informational RFC |
|Done|| ||Submit Architecture draft to IESG for Informational RFC |
|May 2003|| ||Submit TCP mapping to IESG for Proposed Standard RFC |
|Done|| ||Submit Threat Analysis to IESG for Informational RFC |
|Aug 2003|| ||Submit Binding Service and Pool Management to IESG for Proposed
Standard RFC |
|Aug 2003|| ||Submit Applicability Statement to IESG for Informational RFC |
|Nov 2003|| ||Submit MIB to IESG for Proposed Standard RFC |
Request For Comments:
|RFC3237|| I ||Requirements for Reliable Server Pooling |
Current Meeting Report
Minutes for Rserpool from IETF-64
Summary of Rserpool Meeting at IETF #64
Approximately 30 people attended this meeting.
The group initially discussed the Rserpool API draft and debated whether
this is the right set of APIs to help application developers.
Implementation experience is ongoing to determine this. There is an
available library that can be used by developers, and a URL was provided
by the author.
The group then reviewed load balancing work. No presentation was
available as documentation was not completed in time for the meeting
cutoff date. The Chairs noted that there was a meeting between the
A-Ds, the WG Chairs and the authors of the SASP draft where it was
decided that this would be treated as an individual submission to the
RFC editors documenting an existing implementation, and will continue on
a separate track from work in Rserpool.
There was a report on Reserpool implementations. Multiple
implementations are available or in progress, and interoperability
testing has been done on ASAP. Further interoperability testing is
planned for next year, including testing of ENRP interoperability.
There was a discussion on next steps for Rserpool. We had submitted 3
drafts to the IESG: the architecture, comparison and security threat
analysis. The General Area reviewer commented that the drafts were not
clear and were incomplete without the protocols documents. We explored
several options on how to handle this. It was decided that the documents
would be revised and improved, soliciting outside review of the updated
drafts to ensure readability. In the meantime, work will continue
towards completing the protocol documents, which are stable but continue
to be updated with the results of implementation testing.
Rserpool Draft Status
Reliable Server Pooling Implementations
Reliable Server Pooling Sockets API Extensions