--- 1/draft-ietf-rserpool-overview-03.txt 2008-02-08 04:12:17.000000000 +0100 +++ 2/draft-ietf-rserpool-overview-04.txt 2008-02-08 04:12:17.000000000 +0100 @@ -1,23 +1,23 @@ Network Working Group P. Lei Internet-Draft Cisco Systems, Inc. Intended status: Informational L. Ong -Expires: July 25, 2008 Ciena Corporation +Expires: August 6, 2008 Ciena Corporation M. Tuexen Muenster Univ. of Applied Sciences T. Dreibholz University of Duisburg-Essen - January 22, 2008 + February 3, 2008 An Overview of Reliable Server Pooling Protocols - draft-ietf-rserpool-overview-03.txt + draft-ietf-rserpool-overview-04.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,21 +28,21 @@ 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 July 25, 2008. + This Internet-Draft will expire on August 6, 2008. Copyright Notice Copyright (C) The IETF Trust (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 @@ -103,72 +103,77 @@ o facilitate different server selection policies o facilitate a set of application-independent failover capabilities o peer-to-peer structure The basic components of the RSerPool architecture are shown in Figure 1below: ....................... - ------ . +-------+ . - / ENRP \ . | | . - /---->| Server | . | PE 1 | . - | /--- \______/ . | | . - | | . +-------+ . - | | . . - | | . Server Pool . - | V . . + ______ ______ . +-------+ . + / ENRP \ / ENRP \ . | | . + |Server| <----> |Server|<----------.----->| PE 1 | . + \______/ ENRP \______/ ASAP(1) . | | . + ^ . +-------+ . + | . . + | ASAP(2) . Server Pool . + V . . +-------+ . +-------+ . | | . | | . - | PU 1 |-----------------.------| PE 2 | . - | | . | | . + | PU |<---------->. | PE 2 | . + | | PU to PE . | | . +-------+ . +-------+ . . . . +-------+ . . | | . . | PE 3 | . . | | . . +-------+ . ....................... 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 [2]. + 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 labeled 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 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. + a specific Pool Element 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 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 [3] to maintain synchronization - of data concerning the pool handle mapping space. + Element, 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. 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. + An ENRP 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 [3] to maintain synchronization of data concerning the pool + handle mapping space. + 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