Current Meeting Report
Slides


2.7.15 Reliable Server Pooling (rserpool)

NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It may now be out-of-date. Last Modified: 28-Sep-01
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:
No Request For Comments

Current Meeting Report

Report on Reliable Server Pooling - Rserpool WG IETF 52
Co-Chairs: Lyndon Ong (lyong@ciena.com)
Maureen Stillman (maureen.stillman@nokia.com)

Approximately thirty people attended the WG meeting of Rserpool on Tuesday, December 11 at 9AM.

Agenda

1) Rserpool Requirements document
draft-ietf-rserpool-reqts-03.txt
Michael Tuexen

2) Rserpool Comparison document
draft-ietf-comp-02.txt
John Loughney
Erik Guttman
Randy Stewart

3) Rserpool ASAP document
draft-ietf-rserpool-asap-01.txt
Randy Stewart

4) Rserpool ENRP document
draft-ietf-rserpool-enrp-01.txt
Qiaobing Xie

5) Threat document
draft-stillman-rserpool-threats-00.txt
Maureen Stillman

It was noted by the chair that a MIB I-D draft-mulik-rserpool-mib-00.txt has been submitted, but the authors were not able to attend the SLC meeting.
They may be available to present it at IETF 53.

1) Rserpool Requirements document

The requirements document has been approved as an informational RFC.
The IESG had minor comments, which were added to draft-ietf-rserpool-reqts-03.txt.

The Rserpool architecture document was discussed. A request for it to be more neutral regarding solutions and more generic in its use of terminology was proposed. It was agreed that this approach should be supported. In addition, an e-mail to the mailing list by Erik Guttman with an example of TFTP will be included in the architecture document. Many people felt that the example was very valuable in bringing out important issues. Erik also suggested considering some work from OSI regarding session state sharing between servers using session state tokens. This work is documented in a book by Marshall Rose entitled "The Open Book".

2) Rserpool Comparison document

John Loughney presented open issues with the comparison document draft-ietf-comp-02.txt. The draft had been updated with information on SLP. A table summarizes and compares the protocols. The table needs corrections and updates. It will be updated with recent comments. John welcomed further comments on the list.

We discussed the addition of SLP into the ASAP/ENRP protocol. A design team worked on this merger with no consensus reached, but improvements were made to both ENRP and mesh SLP as a result of the discussion. We continued the debate of SLP and ENRP.

Erik Guttman clarified that mesh SLP (mSLP) was needed for rapid distribution and that SLP currently supports less reliable state propagation than ENRP. His belief is that Rserpool would benefit from taking SLP as a whole, given that (1) SLP is further along in specification and implementation and (2) a method such as SLP is needed for discovery of session handles in addition to ENRP.

Randy Stewart and Qiaobing Xie argued that SLP by itself was not reliable and was not sufficiently robust. Randy argued that architecturally Rserpool provided session layer functions whereas SLP was application layer, and that the two should not be tightly coupled.

Henning Schulzrinne commented from the floor that he preferred to see the group borrow rather than create new protocols, and that SLP would be better tested because of implementations. It was noted that SLP folks plan to continue enhancing SLP to include the modifications necessary for server pooling independently of the work in this group, so that working on ENRP in this group would not rule out the possibility of using SLP in this context. It was decided to continue work on ENRP but to document work done on applicability of SLP for Rserpool functions in an Rserpool Applicability Statement (for which the comparisons document is probably a good start).

3) Rserpool ASAP document
4) Rserpool ENRP document

We have two working group documents that are drafts for the Rserpool protocol. At this WG meeting, several new ideas for protocol changes to the WG documents Aggregate Access Protocol (ASAP) draft-ietf-rserpool-asap-01.txt and Endpoint Name Resolution Protocol (ENRP) draft-ietf-rserpool-enrp-01.txt were discussed.

Randy Stewart presented an update on ASAP. The records have been changed to TLV format. The wording in the document has been improved. We need to work on security (see 5 below). The next step for ASAP/ENRP is to work on a reference implementation.

Qiaobing presented an update on ENRP. It has been simplified to remove the takeover mechanism as a result of discussion on SLP, which indicated that there was little gain in this compared to the added complexity. Use of TLV formats and support for Ipv6 were also added. Future modifications will include addition of TCP and UDP transport, discussion of bootstrapping, use of non-multicast environments and security. Continued debate and enhancement of the protocol will continue on the list.

5) Threat document

The security threat document draft-stillman-rserpool-threats-00.txt was debated and valuable comments on it were made. Erik Guttman pointed out that there was no statement on issues related to application security included in the document. Specifically, that fail over of a secure connection will require transfer of security context and state sharing in order for the fail over to provide adequate security. The requirements document mentions this issue but defers work on state sharing. This is out of the scope of the Rserpool charter. Context transfer may be addressed by the WG at a later time.

These comments will be added to the threat draft. Upon the completion of the threat document, we need to determine its status in the WG. The area directors will be asked about including it in the list of deliverables as an Informational RFC. The next step is to determine the security mechanisms to mitigate the threats. A design team to discuss security solutions will be formed. The group will formulate potential security solutions and present this to the list for comment.

Slides

Reliable Server Pooling Security Threats
Endpoint Name Resolution Protocol
Endpoint Name Resolution using SLP
Comparison of Protocols for Reliable Server Pooling