Network Working Group M. Tuexen Request for Comments: 3237 Siemens AG Category: Informational Q. Xie Motorola R. Stewart M. Shore Cisco L. Ong Ciena J. Loughney M. Stillman Nokia January 2002 Requirements for Reliable Server Pooling Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved.
AbstractThis document defines a basic set of requirements for reliable server pooling. The goal of Reliable Server Pooling (RSerPool) 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.
This document defines requirements for an architecture and protocols enabling pooling of servers to support high reliability and availability for applications. The range of applications that can benefit from reliable server pooling includes both mobile and real-time applications. Reliable server pooling mechanisms will be designed to support functionality for flexible pooling such as registration and deregistration, and load balancing of traffic across the server pool. Mechanisms will need to balance the needs of scalability, overhead traffic and response time to changes in pool status, as discussed below.
The architecture should not rely on multicast capabilities of the underlying layer. Nevertheless, it can make use of it if multicast capabilities are available. Network failures have to be handled and concealed from the application layer as much as possible by the transport protocol. This means that the underlying transport protocol must provide a strong network failure handling capability on top of an acknowledged error-free non-duplicated data delivery service. The failure of a network element must be handled by the transport protocol in such a way that the timing requirements are still fulfilled.
Examples of server pool policies are: - Round Robin - Least used - Most used The set of supported policies must be extensible in the sense that new policies can be added as required. Non-stochastic and stochastic policies can be supported. There must be a way for the client to provide operational status feedback to the name server about the pool elements. The name server protocols must be extensible to allow more refined server selection mechanisms to be implemented as they are developed in the future. For some applications it is important that a client repeatedly connects to the same server in a pool if it is possible, i.e., if that server is still alive. This feature should be supported through the use of pool element handles.
for ciphers operating in cipher block chaining (CBC) or cipher feedback (CFB) mode. These problems must be addressed by the application or by future work on RSerPool. section 2.13. [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, October 1985. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999. [RFC2719] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L., Lin, H., Juhasz, I., Holdrege, M. and C. Sharp, "Framework Architecture for Signaling Transport", RFC 2719, October 1999. [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000. [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, November 2000.
Lyndon Ong Ciena 10480 Ridgeview Court Cupertino, CA 95014 USA Phone: +1 408 366 3358 EMail: firstname.lastname@example.org John Loughney Nokia Research Center PO Box 407 FIN-00045 Nokia Group Finland Phone: +358 50 483 6242 EMail: email@example.com Maureen Stillman Nokia 127 W. State Street Ithaca, NY 14850 USA Phone: +1 607 273 0724 62 EMail: firstname.lastname@example.org
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.