--- 1/draft-ietf-rserpool-overview-00.txt 2007-04-30 22:12:10.000000000 +0200 +++ 2/draft-ietf-rserpool-overview-01.txt 2007-04-30 22:12:10.000000000 +0200 @@ -1,21 +1,21 @@ Network Working Group P. Lei Internet-Draft Cisco Systems, Inc. Intended status: Informational L. Ong -Expires: April 18, 2007 Ciena Corporation +Expires: October 30, 2007 Ciena Corporation M. Tuexen Muenster Univ. of Applied Sciences - October 15, 2006 + April 28, 2007 An Overview of Reliable Server Pooling Protocols - draft-ietf-rserpool-overview-00.txt + draft-ietf-rserpool-overview-01.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 @@ -26,69 +26,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 April 18, 2007. + This Internet-Draft will expire on October 30, 2007. Copyright Notice - Copyright (C) The Internet Society (2006). + Copyright (C) The IETF Trust (2007). 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. ASAP Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2. Aggregate Server Access Protocol (ASAP) Overview . . . . . . . 5 2.1. Pool Initialization . . . . . . . . . . . . . . . . . . . 5 2.2. Pool Entity Registration . . . . . . . . . . . . . . . . . 5 - 2.3. Pool Entity Selection . . . . . . . . . . . . . . . . . . 5 + 2.3. Pool Entity Selection . . . . . . . . . . . . . . . . . . 6 2.4. Endpoint Keepalive . . . . . . . . . . . . . . . . . . . . 6 2.5. Failover Services . . . . . . . . . . . . . . . . . . . . 6 2.5.1. Cookie Mechanism . . . . . . . . . . . . . . . . . . . 6 - 2.5.2. Business Card Mechanism . . . . . . . . . . . . . . . 6 - 2.5.3. Failover Callback Mechanism . . . . . . . . . . . . . 7 - 3. ENRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.5.2. Business Card Mechanism . . . . . . . . . . . . . . . 7 + 3. Endpoint Nameserver Redundancy Protocol (ENRP) Overview . . . 7 3.1. Initialization . . . . . . . . . . . . . . . . . . . . . . 7 - 3.2. Server Discovery . . . . . . . . . . . . . . . . . . . . . 7 + 3.2. Server Discovery and Home Server Selection . . . . . . . . 7 3.3. Server Pool Maintenance . . . . . . . . . . . . . . . . . 8 4. Example Scenarios . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Example Scenario Using RSerPool Resolution Service . . . . 8 + 4.1.1. Standalone Mode . . . . . . . . . . . . . . . . . . . 8 + 4.1.2. Pool Mode . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Example Scenario Using RSerPool Session Services . . . . . 9 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 8. Normative References . . . . . . . . . . . . . . . . . . . . . 11 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 1. Introduction - The requirements for the Reliable Server Pooling effort are defined - in RFC3237 [2]. The central idea of this architecture is 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"). The pool is accessed via an - identifier called a "pool handle", which is a location-independent - name separate from the IP address of any pool server. + 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"). 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 @@ -129,115 +127,125 @@ . +-------+ . ....................... 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 deregisters out of the pool using the Aggregate Server Access - Protocol ASAP [3]. + Protocol ASAP [2]. Each server pool is identified by a unique byte string called the pool handle. The pool handle allows a mapping from the pool to a specific Pool Element located by its IP address and port. The pool handle is what is specified by the Pool User (PU) when it attempts to access a server in the pool, again using ASAP. Both IPv4 and IPv6 PE addresses are supported. To resolve the pool handle to the address necessary to access a Pool Element, the PU consults an entity called the Endpoint haNdlespace Redundancy Protocol (ENRP) server. This server may be a standalone server supporting many PUs or a part of the PU itself, however it is envisioned that ENRP servers provide a fully distributed and fault- - tolerant registry service using ENRP [4] to maintain synchronization + tolerant registry service using ENRP [3] to maintain synchronization of data concerning the pool handle mapping space. + 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. + + The requirements for the Reliable Server Pooling effort are defined + in RFC3237 [1]. + This document provides an overview of the RSerPool protocol suite, - specifically the Aggregate Server Access Protocol ASAP [3] and the - Endpoint Nameserver Redundancy Protocol ENRP [4]. + specifically the Aggregate Server Access Protocol ASAP [2] and the + Endpoint Nameserver Redundancy Protocol ENRP [3]. In addition to the protocol specifications, there is a common - parameter format specification COMMON [5] for both protocols, as well - as a security threat analysis SEC [6]. + parameter format specification COMMON [4] for both protocols, as well + as a security threat analysis SEC [5]. -2. ASAP Overview +2. Aggregate Server Access Protocol (ASAP) Overview ASAP is a straight-forward implementation of a set of mechanisms identified as necessary for support of the creation and maintenance of pools of redundant servers. These mechanisms include: o registration of a new server for the server pool - o deregistration of an existing server in the pool + o deregistration of an existing server from the pool - o resolution of a pool 'handle' to a server or list + o resolution of a pool 'handle' to a server or list of servers o liveness detection for servers in the pool o failover mechanisms for handling server failure 2.1. Pool Initialization Pools come into existence when a PE registers the first instance of - the pool name. 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. + 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. 2.2. Pool Entity Registration A new server joins an existing pool by sending a Registration message - in ASAP indicating the 'handle' of the pool that it wishes to join, a - pool identifier for itself (chosen randomly) information about it's - lifetime in the pool, and what transport protocols and selection - policies it supports. The Registration message is sent to its Home - ENRP server. + in ASAP to an ENRP server, indicating the 'handle' of the pool that + it wishes to join, a pool identifier for itself (chosen randomly) + information about it's lifetime in the pool, and what transport + protocols and selection policies 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 performing periodic audits + to confirm that the PE is still responsive. Similar procedures are applied to de-register itself from the server - pool (or alternatively the server may simply let its previously state - lifetime expire and be gracefully removed from the pool. + pool (or alternatively the server may simply let the lifetime that it + previously registered with expire, after which it is gracefully + removed from the pool. 2.3. Pool Entity Selection - When an endpoint wishes to be connected to a server in the pool, this - requires the resolution of a server 'handle' to the IP addresses of a - server or list of servers in the pool. This process may involve a - number of policies for server selection, for which the RSerPool - protocol suite supports a few simply defined policies and allows the - use of external server selection input for more complex policies. - - The endpoint generates a Handle Resolution message in ASAP and sends - this to its home ENRP server to start the resolution process. The - ENRP server resolves the handle based on its knowledge of pool - servers and returns a Handle Resolution Response in ASAP. + When an endpoint wishes to be connected to a server in the pool, it + genereates a Handle Resolution message in ASAP and sends this to its + home ENRP server. The ENRP server resolves the handle based on its + knowledge of pool servers and returns a Handle Resolution Response in + ASAP. The Resolution Response contains a list of the IP addresses of + one or more servers in the pool that can be contacted. The process + by which the list of servers is created may involve a number of + policies for server selection. The RSerPool protocol suite supports + a few simply defined policies and allows the use of external server + selection input for more complex policies. 2.4. Endpoint Keepalive - In order to maintain status information for members of the server - pool, the ENRP server may audit the status of a particular pool - element using an ASAP Keep Alive message. When received by the pool - element, it responds by verifying its membership in the pool in an - Ack message. + ENRP servers monitor the status of pool elements using the ASAP Keep + Alive message. A Pool Element responds to the ASAP Keep Alive + message with an Ack response. - When a PE is found to be unreachable, for example, an endpoint - conversing with the pool element finds that it can no longer be - reached by its transport connection, the endpoint can also inform its - home ENRP server by sending an Endpoint Unreachable message. + In addition, an endpoint can notify its home ENRP server that the PE + the endpoint was using has become unresponsive by sending the ENRP + server an Endpoint Unreachable message. 2.5. Failover Services While maintaining application-independence, the RSerPool protocol suite provides some simple hooks for supporting failover of an individual session with a pool element. Generally, mechanisms for failover that rely on application state or transaction status cannot - be supported without more specific knowledge of the application being + be defined without more specific knowledge of the application being supported. However, some simple mechanisms supported by RSerPool allow some level of failover that any application can use. 2.5.1. Cookie Mechanism Cookies may optionally be generated by the ASAP layer and periodically sent from the PE to the PU. The PU only stores the last received cookie. In case of fail over the PU sends this last received cookie to the new PE. This method provides a simple way of state sharing between the PEs. Please note that the old PE should @@ -248,77 +256,83 @@ 2.5.2. Business Card Mechanism A PE can send a business card to its peer (PE or PU) containing its pool handle and guidance concerning which other PEs the peer should use for failover. This gives a PE a means of telling a PU what it identifies as the "next best" PE to use in case of failure, which may be based on pool considerations, such as load balancing, or user considerations, such as PEs that have the most up-to-date state information. -2.5.3. Failover Callback Mechanism - - TBD - -3. ENRP +3. Endpoint Nameserver Redundancy Protocol (ENRP) Overview - ENRP is used between ENRP servers in order to maintain a distributed, - fault-tolerant real-time registry service. ENRP servers communicate - with each other in order to exchange information such as pool - membership changes, handlespace data synchronization, etc. + A server pool can be supported by one or more ENRP servers. If + multiple ENRP servers are used to support a single pool then the ENRP + protocol is used between the ENRP servers in order to maintain a + distributed, fault-tolerant real-time registry service. ENRP servers + communicate with each other in order to exchange information such as + pool membership changes, handlespace data synchronization, etc. 3.1. Initialization Each ENRP server initially generates a 32-bit server ID that it uses in subsequent messaging and remains unchanged over the lifetime of the server. It then attempts to learn all of the other ENRP servers - within the scope of the server pool, either using a pre-defined + within the scope of the server pool, either by using a pre-defined Mentor server or by sending out Presence messages on a well-known multicast channel to determine other ENRP servers from the responses - and select one as Mentor. + and select one as Mentor. A Mentor can be any peer ENRP server that + it selects to provide current data about the pool. It then requests the most current data about the pool handlespace from its Mentor server and unpacks received Handle Table Response messages into its local database. It is then ready to provide ENRP services. -3.2. Server Discovery +3.2. Server Discovery and Home Server Selection PEs can now register their presence with the newly functioning ENRP server by using ASAP messages. They discover the new ENRP server after the server sends out an ASAP Server Announce message on the - well-known ASAP multicast channel. + well-known ASAP multicast channel. PEs need only register with one + ENRP server, as other ENRP servers supporting the pool will + synchronize their knowledge about pool elements using the ENRP + protocol. - The PE may have a configured list of ENRP servers to talk to, in - which case it will start to setup associations with some number of - them and assign the first one that responds to it as its Home ENRP - Server. + The PE may have a configured list of ENRP servers to talk to, in the + form of a list of IP addresses, in which case it will start to setup + associations with some number of them and assign the first one that + responds to it as its Home ENRP Server. Alternatively it can listen on the multicast channel for a set period and when it hears an ENRP server, start an association. The first server it gets up can then become its Home ENRP Server. 3.3. Server Pool Maintenance PE failure detection, keepalive, etc. TBD 4. Example Scenarios 4.1. Example Scenario Using RSerPool Resolution Service +4.1.1. Standalone Mode + RSerPool can be used in a 'standalone' manner, where the application uses RSerPool to determine the address of a primary server in the pool, and then interacts directly with that server without further use of RSerPool services. If the initial server fails, the application uses RSerPool again to find the next server in the pool. +4.1.2. Pool Mode + For pool user ("client") applications, if an ASAP implementation is 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 gethostbyname()) to translate from a hostname to an IP @@ -359,42 +373,43 @@ 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 - [3]). Finally, when failures occur, these are reported to the pool - via signaling present in ASAP [3] and ENRP [4], other clients will + [2]). Finally, when failures occur, these are reported to the pool + via signaling 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. 4.2. Example Scenario Using RSerPool Session Services When the full suite of RSerPool services are 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. As in the previous case, sessions (rather than connections or associations) are established, and the destination endpoint is specified as a pool handle rather than as a list of IP addresses with a port number. However, failover from one pool element to another is - fully automatic, and can be transparent to the application: + fully automatic, and can be transparent to the application (so long + as the application has saved enough state in a state cookie): - The RSerPool framework control channel provides maintainance + The RSerPool framework control channel provides maintenance functions to keep pool element lists, policies, etc. current. Since the application data (e.g. data channel) is managed by the RSerPool framework, unsent data (data not yet submitted by RSerPool to the underlying transport protocol) is automatically redirected to the newly selected pool element upon failover. If the underlying transport layer supports retrieval of unsent data (as in SCTP), retrieved unsent data can also be automatically re- sent to the newly selected pool element. @@ -434,45 +449,44 @@ already documented in the ENRP and ASAP protocol specifications. 6. IANA Considerations This document does not require additional IANA actions beyond those already identified in the ENRP and ASAP protocol specifications. 7. Acknowledgements The authors wish to thank Maureen Stillman, Qiaobing Xie, Randall - Stewart, and many others for their invaluable comments. + Stewart, Scott Bradner, and many others for their invaluable + comments. 8. Normative References - [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [2] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, + [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. - [3] Stewart, R., "Aggregate Server Access Protocol (ASAP)", - draft-ietf-rserpool-asap-13 (work in progress), February 2006. + [2] Stewart, R., "Aggregate Server Access Protocol (ASAP)", + draft-ietf-rserpool-asap-15 (work in progress), January 2007. - [4] Stewart, R., "Endpoint Handlespace Redundancy Protocol (ENRP)", - draft-ietf-rserpool-enrp-13 (work in progress), February 2006. + [3] Stewart, R., "Endpoint Handlespace Redundancy Protocol (ENRP)", + draft-ietf-rserpool-enrp-15 (work in progress), January 2007. - [5] Stewart, R., "Aggregate Server Access Protocol (ASAP) and + [4] Stewart, R., "Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters", - draft-ietf-rserpool-common-param-10 (work in progress), - February 2006. + draft-ietf-rserpool-common-param-11 (work in progress), + October 2006. - [6] Stillman, M., "Threats Introduced by Rserpool and Requirements + [5] Stillman, M., "Threats Introduced by Rserpool and Requirements for Security in response to Threats", - draft-ietf-rserpool-threats-05 (work in progress), July 2005. + draft-ietf-rserpool-threats-06 (work in progress), + November 2006. Authors' Addresses Peter Lei Cisco Systems, Inc. 955 Happfield Dr. Arlington Heights, IL 60004 US Phone: +1 773 695-8201 @@ -488,32 +503,32 @@ Michael Tuexen Muenster Univ. of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt Germany Email: tuexen@fh-muenster.de Full Copyright Statement - Copyright (C) The Internet Society (2006). + Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information