2.8.12 Reliable Server Pooling (rserpool)

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-10-22

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

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-07.txt
  • - draft-ietf-rserpool-comp-07.txt
  • - draft-ietf-rserpool-asap-08.txt
  • - draft-ietf-rserpool-enrp-07.txt
  • - draft-ietf-rserpool-common-param-05.txt
  • - draft-ietf-rserpool-threats-02.txt
  • - draft-ietf-rserpool-applic-01.txt
  • - draft-ietf-rserpool-tcpmapping-00.txt
    • Request For Comments:
    RFCStatusTitle
    RFC3237 I Requirements for Reliable Server Pooling

    Current Meeting Report

     
    check.Reliable Server Pooling WG (rserpool)
 
Monday, November 10, 2003
=================================
 
 CHAIRs:
 Lyndon Ong <lyong@ciena.com>
 Maureen Stillman <Maureen.Stillman@nokia.com>




http://www.ietf.org/internet-drafts/draf
t-conrad-rserpool-service-02.txt


The Rserpool services draft is still under construction.     Two modes are 
defined: basic and enhanced.  Basic just performs server selection, that is, 
it uses a pool handle to get an IP address and ports of servers.  Then the 
application must take care of all failure detection etc.  Enhanced mode 
uses TCP+shim or SCTP. Data is transported through RSERPOOL service.  The 
next draft needs to be reviewed as there have been a number of changes 
since the -02 draft.


There have been a number of requests for a socket layer defined to make 
Rserpool more easily accessible to implementers.  A high 
availability socket layer would be a useful addition.  Some 
volunteers for a draft were identified.
 

http://www.ietf.org/internet-drafts/draf
t-rserpool-tcpmapping-00.txt
There have been no changes to the TCP Mapping document.  The 
references in it need to be updated.  This document is considered stable at 
this point.



http://www.ietf.org/internet-drafts/draf
t-ietf-rserpool-arch-07.txt


Rserpool architecture document has been submitted to the IESG for 
review.  It was updated to point to the security threat document in the 
security considerations section.  Comments received during last call were 
incorporated into the document before it was sent to the IESG for 
review.



http://www.ietf.org/internet-drafts/draf
t-ietf-rserpool-common-param-04.txt

http://www.ietf.org/internet-drafts/draf
t-ietf-rserpool-asap-07.txt

http://www.ietf.org/internet-drafts/draf
t-ietf-rserpool-enrp-06.txt


ENRP and ASAP issues and updates were addressed.  Security 
considerations section was added to both ASAP and ENRP based on the work of 
the security design team over the last year.  The decision to use TLS as the 
security mechanism for Rserpool was documented.  A namespace 
consistency audit was added to ENRP.  It was pointed out that the 
databases will not be 100% consistent with each other.  A checksum is used to 
determine if the databases are in synch.  If the checksums do not match, 
then a resynch is required.  The use of multicast is still an open issue due 
to security concerns.  Everyone should read the drafts carefully and send 
any comments.



http://www.ietf.org/internet-drafts/draf
t-ietf-rserpool-threats-02.txt


The security design team has completed its work after meeting for over a 
year.  The threat document has been submitted to the IESG for review and 
comment.  Several comments were incorporated during last call.  
Information regarding security of the ENRP namespace needs to be added to 
the ENRP document security considerations section.  One outstanding issue is 
the TLS cipher suite. A MUST implement cipher suite needs to be 
implemented.  This was brought up on the list.  We agreed on AES as MUST 
implement at the meeting. The security design team declares victory and has 
meet all of its objectives.
 



http://www.ietf.org/internet-drafts/draf
t-rserpool-applic-01.txt


Applicability Statement draft is waiting on a new revision of the 
rserpool services document.  These documents need to be in 
synchronization.  The draft will be updated to reflect the changes in 
services.




http://www.ietf.org/internet-drafts/draf
t-xie-rserpool-redundancy-model-00.txt


Rserpool redundancy model support is not sufficient to support some 
commonly deployed high availability systems.
This draft defines an extension to the load sharing policy to support an 
advanced N+M or N-way redundancy model.  There was a request to 
incorporate this draft into ASAP/ENRP.  There is potential IPR on this 
draft.  Motorola will clarify the IPR issue.  Decision will be made after 
Motorola provides more information on its IPR

    Slides

    Rserpool Applicability Statement
    Rserpool Security
    Advanced Redundant Model Policy Support
    ENRP and ASAP Updates and Issues
    RSerPool Architecture