Current Meeting Report
Slides


2.7.14 Reliable Server Pooling (rserpool)

NOTE: This charter is a snapshot of the 53rd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date. Last Modified: 11-Jan-02
Chair(s):
Lyndon Ong <lyong@ciena.com>
Maureen Stillman <maureen.stillman@nokia.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@isi.edu>
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.

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 RSPool Requirements And Architecture document
Done   Submit Reqts draft to IESG for consideration as an Informational RFC
Done   Initial draft of Binding Service document
Done   Initial draft of Client/server binding and Server Pool Management document
Nov 01   Submit Architecture draft to IESG for consideration as an Informational RFC
Jan 02   Submit drafts of Binding Service and Server Pool Management to IESG for consideration as Proposed Standard RFCs
Internet-Drafts:
Request For Comments:
RFCStatusTitle
RFC3237 Requirements for Reliable Server Pooling

Current Meeting Report

Rserpool: Reliable Server Pooling
Co-chairs: Lyndon Ong, lyong@ciena.com
Maureen Stillman, maureen.stillman@nokia.com
IETF 53 Monday March 18, 2002
13:00 - 15:00

Approximately 60 people attended this meeting.

Agenda:

1) Rserpool Architecture document
draft-ietf-rserpool-arch-01.txt
Michael Tuexen

2) Rserpool Comparison document
draft-ietf-comp-03.txt
John Loughney

3) Rserpool MIB document
draft-mulik-rserpool-mib-00.txt
Phillip Conrad

4) Threat document and Rserpool security
draft-stillman-rserpool-threats-02.txt
Maureen Stillman

5) Rserpool ASAP document
draft-ietf-rserpool-asap-02.txt
Randy Stewart

6) Rserpool ENRP document
draft-ietf-rserpool-enrp-02.txt
Qiaobing Xie

1) Rserpool Architecture document
The Rserpool architecture document was discussed. Several issues were raised: The use of multicast needs to be clarified. Where should we put the security work? In this document or some other document? Should we define APIs or psuedocode? A comment was made that the services offered by Rserpool are not defined. What do the Rserpool protocols offer to the application? A service model is necessary. It is not clear from the document if Rserpool is transparent to the application or not, for example.

It was determined that APIs or psuedocode are not appropriate for an architecture document. It was agreed by the group that more explanation of the services that Rserpool would offer to applications needs to be documented, and Loede Coene volunteered to draft an applicability statement that would provide such material. Further comments on the architecture document are welcome.

2) Rserpool Comparison document
The comparison document was discussed. Updated text on CORBA and SLP has been added. One attendee brought up possible relevance of the Sever Cache Synchronization Protocol (SCSP) RFC 2334 to Rserpool. It was requested that further information about SCSP and potential relationship to Rserpool be posted to the list. It may offer a complementary set of functions. It could potentially solve problems like state sharing. Further review of the comparison document was felt to be required before progressing it further.

3) Rserpool MIB document
A draft MIB has been completed for Rserpool by Phil Conrad and students and was submitted as an I-D. There may be an open source implementation available in September. SCTP bakeoffs might be a good venue. The AD asked that the MIB group work with experienced MIB writers for feedback and guidance. The MIB document was progressed to a Rserpool WG document by group consensus.

4) Threat document and Rserpool security
The security design team discussed Rserpool security for several months and reached a consensus. This consensus was discussed and problems with the end user security in exchanges with the ENRP server for name resolution were surfaced. It is possible for a malicious ENRP server to masquerade as a legitimate ENRP server. The user must be protected from this threat. Therefore, a security mechanism to authenticate the ENRP server to the end user will be added. The MIDCOM WG is dealing with similar security issues. We must think about where the credentials come from. Someone recommended that we look at Kerberos. We need to keep a watch on the IPSec WG for its revisions of the IKE protocol known as "son of IKE". It was recommended that we look at Eric Rescorla's document on how to write a security considerations section. The end user - ENRP server authentication problem is the next task that the security design team will tackle.

5,6) Rserpool ASAP and ENRP documents

ASAP was not revised much from previous IETF meeting. There are a number of open issues. One major issue is that Rserpool currently only supports SCTP as its transport for end user applications. This needs to be modified to include other transport protocols such as TCP and UDP. We cannot expect all applications to change their transport protocols. We need to clarify the use of multicast. Name space auditing and synchronization need to be addressed. Pluggable server selection policies were discussed in the past but not defined in detail. We need to determine the impact of NATs and address scoping of IP addresses in IPv6.

Closing Remarks:

There was consensus that the WG needs a working meeting on the ASAP, ENRP protocols and the architecture document. An interim meeting will be announced on the mailing list in accordance with IETF guidelines. Cisco offered to host the meeting.



Slides

The RSerPool architecture
Management Information Base using SMIv2
Endpoint Name Resolution Protocol
Comparison of Protocols for Reliable Server Pooling
Reliable Server Pooling Security Threats