Last Modified: 2004-06-15
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.
|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|
|RFC3237||I||Requirements for Reliable Server Pooling|
Rserpool minutes from IETF #60
Approximately 30 people attended the WG meeting held on 8/5/2004.
A policies draft was presented (draft-tuexen-rserpool-policies-00.txt). This draft presents new policies for reliable server pooling. The proposal was to take the pool policies currently included in the ASAP draft and separate them into a separate policies draft. This allows the stable base ASAP protocol specification to be separated from the pool policies which are subject to further investigation and more substantial changes. Consensus was reached in the meeting to make this change. We will take the proposal to the mailing list.
The SASP Server Application State protocol was presented (draft-bivens-sasp-00.txt). SASP is focused on a specific application which is load balancing among a group of servers. The architecture of SASP was presented and it was compared to Rserpool. This protocol has some overlap with Rserpool and many of the same goals and requirements. The meeting participants reached consensus to work with the author of SASP on a collaborative effort as SASP brings an important application's set of requirements, namely load balancers, into the protocol development process. An offline discussion followed the agreement.
A brief update was presented on the following documents with minor changes since the last draft:
These documents are currently in AD review.
These documents are under construction:
The group was encouraged to read the latest drafts and send comments to the mailing list.
The ASAP and ENRP protocols are fairly stable at this time. Rserpool implementations are being discussed on the mailing list since IETF #59 and changes have been suggested to the protocols as a result. These changes were made to the latest drafts. A presentation on the current status of the implementations gave details of how to get open source and tools such as Ethereal which has been updated to dissect ENRP and ASAP packets.
We feel that the WG is moving ahead and making good progress.