2.8.16 Reliable Server Pooling (rserpool)

Last Modified: 2003-07-09

Lyndon Ong <lyong@ciena.com>
Maureen Stillman <maureen.stillman@nokia.com>
Transport Area Director(s):
Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>
Transport Area Advisor:
Jon Peterson <jon.peterson@neustar.biz>
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

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
  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.

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
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 RFC
Nov 03  Submit MIB to IESG for Proposed Standard RFC
  • - draft-ietf-rserpool-arch-06.txt
  • - draft-ietf-rserpool-comp-06.txt
  • - draft-ietf-rserpool-asap-07.txt
  • - draft-ietf-rserpool-enrp-06.txt
  • - draft-ietf-rserpool-common-param-04.txt
  • - draft-conrad-rserpool-service-03.txt
  • - draft-conrad-rserpool-tcpmapping-01.txt
  • - draft-ietf-rserpool-threats-01.txt
  • - draft-ietf-rserpool-applic-00.txt
  • - draft-ietf-rserpool-tcpmapping-00.txt
  • Request For Comments:
    Requirements for Reliable Server Pooling (RFC 3237) (16986 bytes)

    Current Meeting Report

    well.IETF #57
    Reliable Server Pooling WG (rserpool)
    Monday, July 16, 2003 9:00-11:30AM
    Lyndon Ong <lyong@ciena.com> 
    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
    John Loughney
    Rserpool architecture document
    Michael Tuexen
    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 
    business cards.  
    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 
    Rserpool services
    Peter Lei
    TCP mapping
    Peter Lei
    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
    Michael Tuexen
    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.
    Maureen Stillman
    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.
    Applicability Statement
    Lode Coene
    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 
    services draft. 


    Rserpool Applicability Statement
    Comparison of Protocols for Reliable Server Pooling
    Rserpool Security
    ASAP and ENRP
    RSerPool architecture