Network Working Group M. Tuexen INTERNET DRAFT Siemens AG Q. Xie Motorola R. Stewart M. Shore Cisco L. Ong
Point Reyes NetworksCiena J. Loughney M. Stillman Nokia Expires October 2,November 9, 2001 April 2,May 9, 2001 Requirements for Reliable Server Pooling <draft-ietf-rserpool-reqts-02.txt><draft-ietf-rserpool-reqts-03.txt> Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract 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 a basic set of requirements for reliable server pooling. 1. Introduction 1.1. Overview The Internet is always on. Many users expect services to be always available; many businessbusinesses depend upon connectivity 24 hours a day, 7 days a week, 365 days a year. In order to fulfill this,this level of performance, many proprietary solutions and operating system dependent solutions have been developed to provide highly reliable and highly available servers. This document defines requirements for reliable server pooling. Highly available services also put the samean architecture and protocols enabling pooling of servers to support high reliability requirements upon the transport layer protocol beneath RSerPool - it must provide strong survivability in the faceand availability for applications. The range of network component failures. Supporting real timeapplications is another main focus of RSerPool which leads to requirements on the processing time needed. Scalability is another important requirement. RSerPool introduces new security vulnerabilities into existing applications,that can benefit from reliable server pooling includes both in the pool formation and pool member selection processmobile and in the failover process. Therefore, during the protocol development process itreal-time applications. Reliable server pooling mechanisms will be necessarydesigned to cataloguesupport functionality for flexible pooling such as registration and deregistration, and load balancing of traffic across the threatsserver pool. Mechanisms will need to RSerPoolbalance the needs of scalability, overhead traffic and identify appropriate responsesresponse time to those threats.changes in pool status, as discussed below. 1.2. Terminology This document uses the following terms: Operation scope: The part of the network visible to pool users by a specific instance of the reliable server pooling protocols. Pool (or server pool): A collection of servers providing the same application functionality. Pool handle (or pool name): A logical pointer to a pool. Each server pool will be identifiable in the operation scope of the system by a unique pool handle or "name". Pool element: A server entity having registered to a pool. Pool user: A server pool user. Pool element handle (or endpoint handle): A logical pointer to a particular pool element in a pool, consisting of the name of the pool and aone or more destination transport address ofaddresses for the pool element. Name space: A cohesive structure of pool names and relations that may be queried by an internal or external agent. Name server: Entity which theis responsible for managing and maintaining the name space within the RSerPool operation scope. RSerPool: The architecture and protocols for reliable server pooling. 1.3. Abbreviations PE: Pool element PU: Pool user SCTP: Stream Control Transmission Protocol TCP: Transmission Control Protocol 2. Requirements 2.1. Robustness The solution must allow itself to be implemented and deployed in such a way that there is no single point of failure in the system. 2.2. Failover Support The RSerPool architecture must be able to detect failure of pool elements and name servers supporting the pool, and support failover to available alternate resources. 2.3. Communication Model The general architecture should be based on a peer to peer model. However,support flexibility of the binding should be based oncommunication model between pool users and pool elements, especially allowing for a client server model. 2.2.peer-to-peer relationship to support some applications. 2.4. Processing Power It should be possible to use the protocol stack in small devices, like handheld wireless devices. The solution must scale to devices with a differing range of processing power. 188.8.131.52. Transport Protocol The protocols used for the pool handling should not cause network congestion. This means that it should not generate heavy traffic, even in case of failures, and has to use flow control and congestion avoidance algorithms which are interoperable with currently deployed techniques, especially the flow control of TCP [RFC793] and SCTP [RFC2960]. Therefore, for large pools, only a subset of all possible IP-addresses are returned by the name servers.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. 184.108.40.206. Support of RSerPool Unaware Clients Furthermore,The architecture should allow for ease of interaction between pools and non-RSerPool-aware clients. However, it is expectedassumed that thereonly RSerPool- aware participants will be a transition phase with some systems supporting the RSerPool architecturereceive maximum timing and some are not. To make this transition as seamless as possible it should be possible for hosts not supporting this architecture to use alsonotification benefits the new pooling services via some mechanism. 2.5.architecture offers. 2.7. Registering and Deregistering Another important requirement is that servers should be able to register to (become PEs) and deregister from a server pool transparently without an interruption in service. This means that after a PE has deregistered, it will continue to serve PUs,PUs which started thetheir connection before the deregistration of the PE. No PE will establish a new connection with the deregistered PE, because other PE of the server poolNew connections will be used.directed towards an alternative PE. Servers should be able to register in multiple server pools which may belong to different namespaces. 220.127.116.11. Naming Server pools are identified by pool handles. These pool handles are only valid inside the operation scope. Interoperability between different namespaces has to be provided by other mechanisms. 2.9. Name Resolution The name resolution should not result in a pool element which is not operational. This might be important for fulfilling the timing requirements described below. 2.10. Server Selection The RSerPool mechanisms must be able to support different server selection mechanisms. These are called server pool policies. 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.added as required. Non-stochastic and stochastic policies can be supported. There must be a way for the client to provide informationoperational status feedback to the name server about the pool elements. The name servers shouldserver protocols must be extensible using a plug-in architecture. These plug-ins would provide ato allow more refined server selection by the name servers using additional information provided by clientsmechanisms to be implemented as hints.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. 18.104.22.168. Timing Requirements A server pool can consist of a large number (up to 500) of pool elements. This upper limit is important since the system will be used for real time applications. So handlingand Scaling Handling of name resolution has tomust be fast. Another consequence of the real time requirement is the supervision offast to support real-time applications. Moreover, the pool elements. Thename resolutionspace should not result in areflect pool element which ismembership changes to the client application as rapidly as possible, i.e., not operational. 2.8. Failover Supportwaiting until the client application next reconnects. The RSerPoolarchitecture must be ableshould support control of timing parameters based on specific needs, e.g., of an application or implementation. In order to detect server failure quicklysupport more rapid and be ableaccurate response, the requirements on scalability of the mechanism are limited to perform failover without service interruption. 2.9. Robustness The solution must allow itselfserver pools consisting of a suitably large but not Internet-wide number of elements, as necessary to be implemented and deployedsupport bounded delay in such a way thathandling real-time name resolution. Also, there is no single pointrequirement to support hierarchical organization of failure inname servers for scalability. Instead, it is envisioned that the system. 2.10. Naming Server pools are identified by pool handles. Theseset of name servers supporting a particular pool handles are only valid insideis organized as a flat space of equivalent servers. Accordingly, the operation scope. Interoperability between different namespaces hasimpact of relatively frequent updates to be provided by other mechanisms. 2.11.ensure accurate reflection of the status of pool elements is limited to the set of name servers supporting a specific pool. 2.12. Scalability The RSerPool architecture should not require a limitation on the number of server pools or on the number of pool users. 2.12.users, although the size of an individual pool may be limited by timing requirements as defined above. 2.13. Security Requirements 22.214.171.124.13.1. General - The scaling characteristics of the security architecture should be compatible with those given previously. - The security architecture should support hosts having a wide range of processing powers. 126.96.36.199.13.2. Name Space Services - It must not be possible for an attacker to falsely register as a pool element with the name server either by masquerading as another pool element or by registering in violation of local authorization policy. - It must not be possible for an attacker to deregister a server which has successfully registered with the name server. - It must not be possible for an attacker to spoof the response to a query to the name server - It must be possible to prohibit unauthorized queries to the name server. - It must be possible toprotect the privacy of queries to the name server and responses to those queries from the name server. - Communication among name servers must be afforded the same protections as communication between clients and name servers. 188.8.131.52.13.3. Security State The security context of an application is a subset of the overall context, and context or state sharing is explicitly out-of-scope for RSerPool. Because RSerPool does introduce new security vulnerabilities to existing applications application designers employing RSerPool should be aware of problems inherent in failing over secured connections. Security services necessarily retain some state and this state may have to be moved or re-established. Examples of this state include authentication or retained ciphertext 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. 3. Acknowledgements The authors would like to thank Bernard Aboba, Matt Holdrege, Eliot Lear, Christopher Ross, Werner Vogels and many others for their invaluable comments and suggestions. 4. References [RFC793] J. B. Postel, "Transmission Control Protocol", RFC 793, September 1981. [RFC959] J. B. Postel, J. Reynolds, "File Transfer Protocol (FTP)", RFC 959, October 1985. [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. [RFC2608] E. Guttman et al., "Service Location Protocol, Version 2", RFC 2608, June 1999. [RFC2719] L. Ong et al., "Framework Architecture for Signaling Transport", RFC 2719, October 1999. [RFC2960] R. R. Stewart et al., "Stream Control Transmission Protocol", RFC 2960, November 2000. 5. Authors' Addresses Michael Tuexen Tel.: +49 89 722 47210 Siemens AG e-mail: Michael.Tuexen@icn.siemens.de ICN WN CS SE 51 D-81359 Munich Germany Qiaobing Xie Tel.: +1 847 632 3028 Motorola, Inc. e-mail: email@example.com 1501 W. Shure Drive, #2309 Arlington Heights, Il 60004 USA Randall Stewart Tel.: +1 815 477 2127 Cisco Systems, Inc. e-mail: firstname.lastname@example.org 24 Burning Bush Trail Crystal Lake, Il 60012 USA Melinda Shore Tel.: +1 607 272 7512 Cisco Systems, Inc. e-mail: email@example.com 809 Hayts Rd Ithaca, NY 14850 USA Lyndon Ong Tel.: +1 408 321 8237 Point Reyes Networks366 3358 Ciena e-mail: firstname.lastname@example.org 1991 Concourse Drive San Jose,email@example.com 10480 Ridgeview Court Cupertino, CA 95014 USA John Loughney Tel.: +358 40 749 9122 Nokia Research Center e-mail: firstname.lastname@example.org PO Box 407 FIN-00045 Nokia Group Finland Maureen Stillman Tel.: +1 607 273 0724 62 Nokia e-mail: email@example.com 127 W. State Street Ithaca, NY 14850 USA This Internet Draft expires October 2,November 9, 2001.