2.8.16 Reliable Server Pooling (rserpool)
Last Modified: 2003-07-09
Lyndon Ong <firstname.lastname@example.org>
Maureen Stillman <email@example.com>
Transport Area Director(s):
Allison Mankin <firstname.lastname@example.org>
Jon Peterson <email@example.com>
Transport Area Advisor:
Jon Peterson <firstname.lastname@example.org>
Ned Freed <email@example.com>
General Discussion: firstname.lastname@example.org
To Subscribe: email@example.com
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 03|| ||Submit Architecture draft to IESG for Informational RFC |
|Mar 03|| ||Submit Services document to IESG for Informational RFC |
|May 03|| ||Submit TCP mapping to IESG for Proposed Standard RFC |
|May 03|| ||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
|Nov 03|| ||Submit MIB to IESG for Proposed Standard RFC |
Request For Comments:
Requirements for Reliable Server Pooling (RFC 3237) (16986 bytes)
Current Meeting Report
Reliable Server Pooling WG (rserpool)
Monday, July 16, 2003 9:00-11:30AM
Lyndon Ong <firstname.lastname@example.org>
Maureen Stillman <Maureen.Stillman@nokia.com>
Approximately 20 people attend the meeting.
Summary: Some documents are now nearing completion, while most others have
been updated to be consistent.
Rserpool comparison document
Rserpool architecture document
The Rserpool comparison draft and architecture draft have been updated with
new information. The comparison draft now includes further
description of rserpool and its relationship with DNS and Layer 4-7
switches in response to questions from the Transport Directorate. The
architecture draft has been updated with clarification of the control vs.
data channel identification and usage and failover support using cookies and
The plan is to do a 1 week WG last call on the comparison document (which
was already approved in its previous version) and a 2 week LC on the
New versions of the services draft and TCP mapping draft will be
available soon. The mapping document has added a PPID which will be used to
multiplex like SCTP in the case where data and control channels are
present. The use of TSNs has been updated to clean up
ENRP and ASAP issues and updates
New versions of the ENRP and ASAP protocol are available. These update the
documents for consistency and also add the clarifications of control and
data channel made in the architecture. Among the updates is that a
control only channel is disallowed. The default has been changed to a data
only channel. A data channel is required; with the control channel being
optional. Documents have been updated to reflect that all PEs in a pool use
exactly one transport protocol.
The use of multicast in ENRP remains an open issue and was briefly
discussed. This will continue on the list.
The current design team consensus was that the network designer could
either use TLS or IPsec as mandatory to implement for ENRP-PE and
ENRP-ENRP communication. The PU authentication of the ENRP server using TLS
was previously decided to be mandatory to implement for reasons of
interoperability. Direction from the ADs and agreement in the meeting was
that one security mechanism should be made mandatory to implement for all.
It was agreed to use TLS as mandatory by those attending the meeting, but we
will take the final decision to the list.
Other clarifications included the restriction of pool elements within a
particular pool to provide the same level of security, for
simplicity. In addition, an ENRP server will either have all elements
secured or none, also for reasons of simplicity. A mixed security rating
for the elements stored in the ENRP database would complicate the client as
well as the ENRP server. The client would have to implement a security
policy which would review the entries returned by ENRP and select them
based on a security policy. It is also unclear what the impact of a mixed
database is on security as a whole. It was agreed to restrict the ENRP
database to secure registrations only and secure communications between
ENRP servers OR insecure registrations only by those attending the
meeting. The decision to restrict the ENRP database in this manner will be
further debated and validated over the list.
The applicability statement was reviewed. It has been updated with
several comments from the last WG meeting. This is still in an early
state and needs alignment with the other documents, especially the
Rserpool Applicability Statement
Comparison of Protocols for Reliable Server Pooling
ASAP and ENRP