--- 1/draft-ietf-rserpool-overview-05.txt 2008-05-06 04:12:21.000000000 +0200 +++ 2/draft-ietf-rserpool-overview-06.txt 2008-05-06 04:12:21.000000000 +0200 @@ -1,23 +1,23 @@ Network Working Group P. Lei Internet-Draft Cisco Systems, Inc. Intended status: Informational L. Ong -Expires: August 25, 2008 Ciena Corporation +Expires: November 7, 2008 Ciena Corporation M. Tuexen Muenster Univ. of Applied Sciences T. Dreibholz University of Duisburg-Essen - February 22, 2008 + May 06, 2008 An Overview of Reliable Server Pooling Protocols - draft-ietf-rserpool-overview-05.txt + draft-ietf-rserpool-overview-06.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -28,69 +28,67 @@ 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. - This Internet-Draft will expire on August 25, 2008. - -Copyright Notice - - Copyright (C) The IETF Trust (2008). + This Internet-Draft will expire on November 7, 2008. Abstract The Reliable Server Pooling effort (abbreviated "RSerPool"), provides an application-independent set of services and protocols for building fault tolerant and highly available client/server applications. This document provides an overview of the protocols and mechanisms in the reliable server pooling suite. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Aggregate Server Access Protocol (ASAP) Overview . . . . . . . 6 2.1. Pool Initialization . . . . . . . . . . . . . . . . . . . 6 - 2.2. Pool Entity Registration . . . . . . . . . . . . . . . . . 6 + 2.2. Pool Entity Registration . . . . . . . . . . . . . . . . . 7 2.3. Pool Entity Selection . . . . . . . . . . . . . . . . . . 7 2.4. Endpoint Keep-Alive . . . . . . . . . . . . . . . . . . . 7 2.5. Failover Services . . . . . . . . . . . . . . . . . . . . 7 - 2.5.1. Cookie Mechanism . . . . . . . . . . . . . . . . . . . 7 - 2.5.2. Business Card Mechanism . . . . . . . . . . . . . . . 7 + 2.5.1. Cookie Mechanism . . . . . . . . . . . . . . . . . . . 8 + 2.5.2. Business Card Mechanism . . . . . . . . . . . . . . . 8 3. Endpoint Handlespace Redundancy Protocol (ENRP) Overview . . . 8 3.1. Initialization . . . . . . . . . . . . . . . . . . . . . . 8 - 3.2. Server Discovery and Home Server Selection . . . . . . . . 8 + 3.2. Server Discovery and Home Server Selection . . . . . . . . 9 3.3. Failure Detection, Handlespace Audit and Synchronization . . . . . . . . . . . . . . . . . . . . . 9 3.4. Server Takeover . . . . . . . . . . . . . . . . . . . . . 9 4. Example Scenarios . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Example Scenario using RSerPool Resolution Service . . . . 9 4.2. Example Scenario using RSerPool Session Services . . . . . 11 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 - Intellectual Property and Copyright Statements . . . . . . . . . . 15 + 5. Reference Implementation . . . . . . . . . . . . . . . . . . . 12 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 + Intellectual Property and Copyright Statements . . . . . . . . . . 16 1. Introduction The Reliable Server Pooling (RSerPool) protocol suite is designed to provide client applications ("pool users") with the ability to select a server (a "pool element") from among a group of servers providing - equivalent service (a "pool"). + equivalent service (a "pool"). The protocols are currently targeted + for Experimental Track. The RSerPool architecture supports high-availability and load balancing by enabling a pool user to identify the most appropriate server from the server pool at a given time. The architecture is defined to support a set of basic goals: o application-independent protocol mechanisms o separation of server naming from IP addressing @@ -132,90 +130,100 @@ ....................... Figure 1 A server pool is defined as a set of one or more servers providing the same application functionality. The servers are called Pool Elements (PEs). Multiple PEs in a server pool can be used to provide fault tolerance or load sharing, for example. The PEs register into and deregister out of the pool at an entity called the Endpoint haNdlespace Redundancy Protocol (ENRP) server, using the Aggregate - Server Access Protocol ASAP [2] (this association is labelled ASAP(1) - in the figure). + Server Access Protocol ASAP [I-D.ietf-rserpool-asap] (this + association is labelled ASAP(1) in the figure). Each server pool is identified by a unique byte string called the pool handle (PH). The pool handle allows a mapping from the pool to a specific PE located by its IP address (both IPv4 and IPv6 PE addresses are supported) and port number. The pool handle is what is specified by the Pool User (PU) when it attempts to access a server in the pool. To resolve the pool handle to the address necessary to access a PE, the PU consults an ENRP server using ASAP (this - association is labeled ASAP(2) in the figure). The protocols used - between PU and PE are application-specific. + association is labeled ASAP(2) in the figure). The space of pool + handles is assumed to be a flat space with limited operational scope + (see RFC3237 [RFC3237]). Administration of pool handles is not + addressed by the RSerPool protocol drafts at this time. The + protocols used between PU and PE are application-specific. It is + assumed that the PU and PE are configured to support a common set of + protocols for application layer communication, independent of the + RSerPool mechanisms. RSerPool provides a number of tools to aid client migration between servers on server failure: it allows the client to identify alternative servers, either on initial discovery or in real time; it also allows the original server to provide a state cookie to the client that can be forwarded to an alternative server to provide application-specific state information. This information is exchanged between PE and PU directly, over the association labeled PU to PE in the figure. It is envisioned that ENRP servers provide a fully distributed and - fault-tolerant registry service. They use ENRP [3] to maintain - synchronization of data concerning the pool handle mapping space. - For PUs and PEs, the ENRP servers are functionally equal. Due to the - synchronization provided by ENRP, they can contact an arbitrary one - for registration/deregistration (PE) or PH resolution (PU). An - illustration containing 3 ENRP servers is provided in Figure 2 below: + fault-tolerant registry service. They use ENRP + [I-D.ietf-rserpool-enrp] to maintain synchronization of data + concerning the pool handle mapping space. For PUs and PEs, the ENRP + servers are functionally equal. Due to the synchronization provided + by ENRP, they can contact an arbitrary one for registration/ + deregistration (PE) or PH resolution (PU). An illustration + containing 3 ENRP servers is provided in Figure 2 below: ______ _____ ... / ENRP \ / ENRP \ ... PEs/PUs <---->|Server| <----> |Server|<----> PEs/PUs ... ASAP \______/ ENRP \______/ ASAP ... ^ ^ | | | / ENRP \ | +---->|Server|<----+ ENRP \______/ ENRP ^ | ASAP v ... PEs/PUs ... Figure 2 The requirements for the Reliable Server Pooling framework are - defined in RFC3237 [1]. It is worth noting that the requirements on - RSerPool in the area of load balancing partially overlap with GRID - computing/high performance computing. However, the scope of both - areas is completely different: GRID and high performance computing - also cover topics like managing different administrative domains, - data locking and synchronization, inter-session communication and - resource accounting for powerful computation services, but the - intention of RSerPool is simply a lightweight realization of load - distribution and session management. In particular, these - functionalities are intended to be used on systems with small memory - and CPU resources only. Any further functionality is not in the - scope of RSerPool and can -- if necessary -- provided by the - application itself. + defined in RFC3237 [RFC3237]. It is worth noting that the + requirements on RSerPool in the area of load balancing partially + overlap with GRID computing/high performance computing. However, the + scope of both areas is completely different: GRID and high + performance computing also cover topics like managing different + administrative domains, data locking and synchronization, inter- + session communication and resource accounting for powerful + computation services, but the intention of RSerPool is simply a + lightweight realization of load distribution and session management. + + In particular, these functionalities are intended to be used on + systems with small memory and CPU resources only. Any further + functionality is not in the scope of RSerPool and can -- if necessary + -- provided by the application itself. This document provides an overview of the RSerPool protocol suite, - specifically the Aggregate Server Access Protocol ASAP [2] and the - Endpoint Handlespace Redundancy Protocol ENRP [3]. In addition to - the protocol specifications, there is a common parameter format - specification COMMON [4] for both protocols, a definition of server - selection rules (pool policies) POLICIES [5], as well as a security - threat analysis THREATS [6]. + specifically the Aggregate Server Access Protocol ASAP + [I-D.ietf-rserpool-asap] and the Endpoint Handlespace Redundancy + Protocol ENRP [I-D.ietf-rserpool-enrp]. In addition to the protocol + specifications, there is a common parameter format specification + COMMON [I-D.ietf-rserpool-common-param] for both protocols, a + definition of server selection rules (pool policies) POLICIES + [I-D.ietf-rserpool-policies], as well as a security threat analysis + THREATS [I-D.ietf-rserpool-threats]. 2. Aggregate Server Access Protocol (ASAP) Overview ASAP defines a straight-forward set of mechanisms necessary to support the creation and maintenance of pools of redundant servers. These mechanisms include: o registration of a new server into a server pool o deregistration of an existing server from a pool @@ -227,20 +235,25 @@ o failover mechanisms for handling a server failure 2.1. Pool Initialization Pools come into existence when a PE registers the first instance of the pool name with an ENRP server. They disappear when the last PE deregisters. In other words, the starting of the first PE on some machine causes the creation of the pool when the registration reaches the ENRP server. + It is assumed that information needed for RSerPool, such as the + address of an ENRP server to contact, is configured into the PE + beforehand. Methods of automating this configuration process are not + addressed at this time. + 2.2. Pool Entity Registration A new server joins an existing pool by sending a Registration message via ASAP to an ENRP server, indicating the pool handle of the pool that it wishes to join, a PE identifier for itself (chosen randomly), information about its lifetime in the pool, and what transport protocols and selection policy it supports. The ENRP server that it first contacts is called its Home ENRP server, and maintains a list of subscriptions by the PE as well as performs periodic audits to confirm that the PE is still responsive. @@ -383,67 +396,72 @@ available on the client system, there are typically only three modifications required to the application source code: 1. Instead of specifying the hostnames of primary, secondary, tertiary servers, etc., the application user specifies a pool handle. 2. Instead of using a DNS based service (e.g. the Unix library function getaddrinfo()) to translate from a hostname to an IP address, the application will invoke an RSerPool service - primitive GETPRIMARYSERVER that takes as input a pool handle, and - returns the IP address of the primary server. The application - then uses that IP address just as it would have used the IP - address returned by the DNS in the previous scenario. + primitive provisionally named GETPRIMARYSERVER that takes a pool + handle as input, and returns the IP address of the primary + server. The application then uses that IP address just as it + would have used the IP address returned by the DNS in the + previous scenario. 3. Without the use of additional RSerPool services, failure detection and failover procedures must be designed into each application. However, when failure is detected on the primary server, instead of invoking DNS translation again on the hostname - of a secondary server, the application invokes the service - primitive GETNEXTSERVER, which performs two functions in a single - operation. + of a secondary server, the application invokes a service + primitive provisionally named GETNEXTSERVER, which performs two + functions in a single operation. - 1. First it indicates to the RSerPool layer the failure of the + 1. First, it indicates to the RSerPool layer the failure of the server returned by a previous GETPRIMARYSERVER or GETNEXTSERVER call. 2. Second, it provides the IP address of the next server that should be contacted, according to the best information available to the RSerPool layer at the present time (e.g. set of available pool elements, pool element policy in effect for the pool, etc.). + Note: at the time of this document, a full API for use with RSerPool + Protocols has not yet been defined. + For pool element ("server") applications where an ASAP implementation is available, two changes are required to the application source code: 1. The server should invoke the REGISTER service primitive upon startup to add itself into the server pool using an appropriate pool handle. This also includes the address(es) protocol or mapping id, port (if required by the mapping), and pooling policy(s). 2. The server should invoke the DEREGISTER service primitive to remove itself from the server pool when shutting down. When using these RSerPool services, RSerPool provides benefits that are limited (as compared to utilizing all services), but nevertheless quite useful as compared to not using RSerPool at all. First, the client user need only supply a single string, i.e. the pool handle, rather than a list of servers. Second, the decision as to which server is to be used can be determined dynamically by the server selection mechanism (i.e. a "pool policy" performed by ASAP; see ASAP - [2]). Finally, when failures occur, these are reported to the pool - via signalling present in ASAP [2] and ENRP [3], other clients will - eventually know (once this failure is confirmed by other elements of - the RSerPool architecture) that this server has failed. + [I-D.ietf-rserpool-asap]). Finally, when failures occur, these are + reported to the pool via signalling present in ASAP + [I-D.ietf-rserpool-asap] and ENRP [I-D.ietf-rserpool-enrp], other + clients will eventually know (once this failure is confirmed by other + elements of the RSerPool architecture) that this server has failed. 4.2. Example Scenario using RSerPool Session Services When the full suite of RSerPool services is used, all communication between the pool user and the pool element is mediated by the RSerPool framework, including session establishment and teardown, and the sending and receiving of data. Accordingly, it is necessary to modify the application to use the service primitives (i.e. the API) provided by RSerPool, rather than the transport layer primitives provided by TCP, SCTP, or whatever transport protocol is being used. @@ -489,79 +507,95 @@ failure in the communication link between A and B, PE B can use the information in the business card to contact an equivalent PE to PU A from pool X. Additionally, if the application at PU A is aware of some particular PEs of pool X that would be preferred for B to contact in the event that A becomes unreachable from B, PU A can provide that list to the ASAP layer, and it will be included in A's business card (see Section 2.5.2). -5. Security Considerations +5. Reference Implementation + + The reference implementation of RSerPool is available at + [RSerPoolPage] and described in [Dre2006]. + +6. Security Considerations This document does not identify security requirements beyond those already documented in the ENRP and ASAP protocol specifications. A - security threat analysis of RSerPool is provided in THREATS [6]. + security threat analysis of RSerPool is provided in THREATS + [I-D.ietf-rserpool-threats]. -6. IANA Considerations +7. IANA Considerations This document does not require additional IANA actions beyond those already identified in the ENRP and ASAP protocol specifications. -7. Acknowledgements +8. Acknowledgements The authors wish to thank Maureen Stillman, Qiaobing Xie, Randall Stewart, Scott Bradner, and many others for their invaluable comments. -8. References +9. References -8.1. Normative References +9.1. Normative References - [1] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, - J., and M. Stillman, "Requirements for Reliable Server Pooling", - RFC 3237, January 2002. + [RFC3237] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., + Loughney, J., and M. Stillman, "Requirements for Reliable + Server Pooling", RFC 3237, January 2002. - [2] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate - Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-18 - (work in progress), November 2007. + [I-D.ietf-rserpool-asap] + Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, + "Aggregate Server Access Protocol (ASAP)", + draft-ietf-rserpool-asap-19 (work in progress), + March 2008. - [3] Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. - Silverton, "Endpoint Handlespace Redundancy Protocol (ENRP)", - draft-ietf-rserpool-enrp-18 (work in progress), November 2007. + [I-D.ietf-rserpool-enrp] + Kim, D., Stewart, R., Stillman, M., Tuexen, M., and A. + Silverton, "Endpoint Handlespace Redundancy Protocol + (ENRP)", draft-ietf-rserpool-enrp-19 (work in progress), + March 2008. - [4] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate - Server Access Protocol (ASAP) and Endpoint Handlespace - Redundancy Protocol (ENRP) Parameters", - draft-ietf-rserpool-common-param-15 (work in progress), - December 2007. + [I-D.ietf-rserpool-common-param] + Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, + "Aggregate Server Access Protocol (ASAP) and Endpoint + Handlespace Redundancy Protocol (ENRP) Parameters", + draft-ietf-rserpool-common-param-16 (work in progress), + March 2008. - [5] Tuexen, M. and T. Dreibholz, "Reliable Server Pooling Policies", - draft-ietf-rserpool-policies-07 (work in progress), - November 2007. + [I-D.ietf-rserpool-policies] + Tuexen, M. and T. Dreibholz, "Reliable Server Pooling + Policies", draft-ietf-rserpool-policies-08 (work in + progress), March 2008. - [6] Stillman, M., Gopal, R., Guttman, E., Holdrege, M., and S. - Sengodan, "Threats Introduced by RSerPool and Requirements for - Security in Response to Threats", - draft-ietf-rserpool-threats-09 (work in progress), October 2007. + [I-D.ietf-rserpool-threats] + Stillman, M., Gopal, R., Guttman, E., Holdrege, M., and S. + Sengodan, "Threats Introduced by RSerPool and Requirements + for Security in Response to Threats", + draft-ietf-rserpool-threats-11 (work in progress), + April 2008. -8.2. Informative References +9.2. Informative References - [7] Dreibholz, T., "Thomas Dreibholz's RSerPool Page", + [RSerPoolPage] + Dreibholz, T., "Thomas Dreibholz's RSerPool Page", URL: http://tdrwww.iem.uni-due.de/dreibholz/rserpool/. - [8] Dreibholz, T., "Reliable Server Pooling -- Evaluation, - Optimization and Extension of a Novel IETF Architecture", Ph.D. - Thesis University of Duisburg-Essen, Faculty of Economics, - Institute for Computer Science and Business Information Systems, - URL: http://duepublico.uni-duisburg-essen.de/servlets/ - DerivateServlet/Derivate-16326/Dre2006-final.pdf, March 2007. + [Dre2006] Dreibholz, T., "Reliable Server Pooling -- Evaluation, + Optimization and Extension of a Novel IETF Architecture", + Ph.D. Thesis University of Duisburg-Essen, Faculty of + Economics, Institute for Computer Science and Business + Information Systems, URL: http:// + duepublico.uni-duisburg-essen.de/servlets/DerivateServlet/ + Derivate-16326/Dre2006-final.pdf, March 2007. Authors' Addresses Peter Lei Cisco Systems, Inc. 955 Happfield Dr. Arlington Heights, IL 60004 US Phone: +1 773 695-8201 @@ -625,15 +659,10 @@ attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. - -Acknowledgment - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA).