2.8.18 Reliable Server Pooling (rserpool)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-09-07

Chair(s):

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: http://www.ietf.org/mail-archive/web/rserpool/index.html

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.

Scope:

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

Internet-Drafts:

  • draft-ietf-rserpool-arch-08.txt
  • draft-ietf-rserpool-comp-08.txt
  • draft-ietf-rserpool-asap-10.txt
  • draft-ietf-rserpool-enrp-10.txt
  • draft-ietf-rserpool-common-param-07.txt
  • draft-ietf-rserpool-threats-03.txt
  • draft-ietf-rserpool-applic-02.txt
  • draft-ietf-rserpool-tcpmapping-02.txt
  • draft-ietf-rserpool-service-01.txt
  • draft-ietf-rserpool-policies-00.txt

    Request For Comments:

    RFCStatusTitle
    RFC3237 I Requirements for Reliable Server Pooling

    Current Meeting Report

    Reliable Server Pooling (Rserpool) minutes IETF #61

    This meeting was attended by approximately 35 people.

    The Rserpool architecture document was discussed. Changes in terminology will be added to the document. These changes are to clarify the architecture and make it easier for the reader to understand Rserpool.

    The document contains several examples of applications of Rserpool. We are interested in adding a load balancing example due to the recent work of the design team in load balancing. Due to these changes we will reissue the document and perform another last call.

    The Rserpool policy document was recently made a WG item. It describes a collection of optional pool policies. One recent change to the document is that it allows two modes of operation. Either the ENRP server can determine the next address or the PU can be given a list of IP addresses from which it selects an address. This change was debated and will be brought to the list.

    The ASAP and ENRP protocols have been stable for a long time. Currently, changes have been suggested on the mailing list from people who are implementing Rserpool. Several changes have been incorporated into both protocols. The authors will update the terminology in the protocol documents to match the architecture document. We solicit and encourage more implementation feedback.

    The load balancing design team has been meeting for two months and has made good progress. We are working with load balancing vendors to understand their requirements. Based on requirements, our goal is to identify changes to the Rserpool protocol and examine the advantages and disadvantages of several approaches. The design team is working on an internet draft to reflect load balancing requirements. This will be released after IETF #61 for review and comment. The design team will continue to meet.

    An internet draft on high availability and Rserpool was discussed. The IPR on this work needs to be clarified before the WG can make a determination about making it a WG item.

    The final talk was a discussion of Rserpool socket APIs. There is a draft not yet released with several authors. An overview of the functions was presented. The goal would be for this document to become an informational RFC. The draft will be sent to the list for review before deciding on its WG status.

    -- Maureen

    Slides

    RSerPool Architecture
    ASAP Protocol Draft
    Reliable Server Pooling Sockets API
    Reliable Server Pooling Load Balancing Analysis
    ENRP Changes from v09
    Advanced Redundant Model Policy Support