2.8.14 Reliable Server Pooling (rserpool)

NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-01-21

Lyndon Ong <lyong@ciena.com>
Maureen Stillman <maureen.stillman@nokia.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@psg.com>
Transport Area Advisor:
Scott Bradner <sob@harvard.edu>
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
NOV 02  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 RFC
NOV 03  Submit MIB to IESG for Proposed Standard RFC
  • - draft-ietf-rserpool-arch-05.txt
  • - draft-ietf-rserpool-comp-05.txt
  • - draft-ietf-rserpool-asap-06.txt
  • - draft-ietf-rserpool-enrp-05.txt
  • - draft-ietf-rserpool-common-param-03.txt
  • - draft-conrad-rserpool-service-03.txt
  • - draft-ietf-rserpool-mib-00.txt
  • - draft-conrad-rserpool-tcpmapping-01.txt
  • - draft-ietf-rserpool-threats-00.txt
  • Request For Comments:
    RFC3237 I Requirements for Reliable Server Pooling

    Current Meeting Report

    IETF #56
    Reliable Server Pooling WG (rserpool)
    Monday, March 17, 2003 15:30-17:30
    Lyndon Ong <lyong@ciena.com> 
    	Maureen Stillman <Maureen.Stillman@nokia.com>
    Approximately 35 people attend the meeting.
    We discussed the services document 
    draft-conrad-rserpool-service-03.txt.  This draft describes the 
    different services that rserpool can offer to the application.   Recent 
    discussions have resulted in some changes.    An updated draft will be 
    released shortly after IETF #56.  The WG was asked to carefully review this 
    document for any services that need to be added or changed.  Service 
    descriptions may need to be further refined on the mailing list.
    Outstanding issues with the tcpmapping document 
    draft-conrad-rserpool-tcpmapping-01.txt were presented.  Under 
    discussion was the initial TSN (0 explicitly?) and message retrieval.  Due to 
    some changes agreed to in the services document, a better alignment with 
    services draft will be included in the next draft.  
    We discussed an open issue in the ASAP protocol 
    draft-ietf-rserpool-asap-06.txt, specifically the configuration of the 
    control and data channels.  The concern is that if we allow different 
    transport protocols for the control and data channels, the result is too 
    complex.  The consensus was to require data and control to use the same 
    transport protocol and in addition, to use of separate pools for 
    different protocols.   Otherwise registration is complex and we prefer to 
    keep it simple. 
    Recent changes and issues concerning ENRP protocol 
    draft-ietf-rserpool-enrp-04.txt were raised.  We have added a 
    Server_Announce message to allow name servers to broadcast so that PU or PE 
    can find the home server.  There was a question on the traffic impacts on 
    wireless devices as it may create too much traffic.  A possible 
    solution is to limit multicast to wire, unicast over the air.  The 
    heartbeat mechanism must not be multicast, as multicast is not 
    transparently supported across domains.  Discussion of this issue will 
    continue on the mailing list.
    The security design team has meet and discussed the security sections in 
    both ASAP and ENRP.  In addition, the design team reviewed the threat 
    draft-ietf-rserpool-threats-00.txt.  The open issue discussed is a 
    requirement to ensure that if security is requested between the PU and ENRP 
    server, then the PU is guaranteed not only to talk to an 
    authenticated ENRP server, but also is guaranteed integrity and 
    authentication of the PE registration data.  These threats are 
    documented in the threat document. 
    Secondly, securing the control channel is an open issue.  Given the 
    consensus to require data and control channel to use the same 
    transport solutions to the problem will be simpler.  This will be 
    further discussed on the list.  The design team will continue working and 
    report its findings to the list.   The chair reopened the membership to any 
    interested person.
    The applicability statement 
    draft-coene-rserpool-applic-01.txt presents several examples or models of 
    how Rserpool could be deployed.  The group discussed that it needs to be 
    aligned or merged with services document.  The minimalist model was based on 
    an IPFIX WG request.  
    We discussed three current implementations of Rserpool from 
    Siemens/University of Essen, Motorola and Temple University.
    Siemens/Essen: Linux, FreeBSD, DarwinOS For more information about this 
    implementation, see:
    http://tdrwww.exp-math.uni-essen.de/dreibholz/rserpool/ and 
    http://www.sctp.de/rserpool.html. An introduction to design and 
    implementation of our rsplib prototype is given in the paper at:
    Motorola has an internal implementation; uses open source SCTP from 
    sctp.org; Linux/Solaris> 
    Temple has Kame SCTP; planning stages; FreeBSD.  
    At this time the documents are becoming more stable with the exception of 
    resolving security issues.  The security design team will continue to meet 
    with the expectation of resolving the above issues by IETF #57.


    Services Provided by RSerPool
    Rserpool Applicability Statement
    Rserpool Security
    Reliable Server Pooling Implementations