Reliable Server Pooling (rserpool)

Last Modified: 2008-07-31

Additional information is available at tools.ietf.org/wg/rserpool

Chair(s):

  • Maureen Stillman <maureen.stillman@nokia.com>

  • Lyndon Ong <lyong@ciena.com>

    Transport Area Director(s):

  • Magnus Westerlund <magnus.westerlund@ericsson.com>
  • Lars Eggert <lars.eggert@nokia.com>

    Transport Area Advisor:

  • Magnus Westerlund <magnus.westerlund@ericsson.com>

    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
    Done  Submit Architecture draft to IESG for Informational RFC
    Done  Submit Threat Analysis to IESG for Informational RFC
    Done  Initial draft of RSERPOOL Overview document
    Done  Revised versions of protocol specification drafts
    Done  Finished review cycle with at least 2 external reviewers
    Done  Threats Analysis updated to align with specification
    Done  Updated drafts submitted based on review comments
    Done  WG discussion on any outstanding issues.
    Done  WG last call on protocol specifications, Threats Analysis and Overview document
    Done  Overview, Threat Analysis and Protocol specifications submitted to IESG for Informational, Informational and Experimental respectively.

    No Current Internet-Drafts

    Request For Comments:

    Requirements for Reliable Server Pooling (RFC 3237) (16986 bytes)
    An Overview of Reliable Server Pooling Protocols (RFC 5351) (33062 bytes)
    Aggregate Server Access Protocol (ASAP) (RFC 5352) (118712 bytes)
    Endpoint Handlespace Redundancy Protocol (ENRP) (RFC 5353) (83657 bytes)
    Threats Introduced by RSerPool and Requirements for Security in Response to Threats (RFC 5355) (38042 bytes)
    Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters (RFC 5354) (50217 bytes)
    Reliable Server Pooling Policies (RFC 5356) (33394 bytes)
    Reliable Server Pooling MIB Module Definition (RFC 5525) (85897 bytes)
    IETF Secretariat - Please send questions, comments, and/or suggestions to ietf-web@ietf.org.

    Return to working group directory.

    Return to IETF home page.