draft-ietf-rserpool-overview-03.txt   draft-ietf-rserpool-overview-04.txt 
Network Working Group P. Lei Network Working Group P. Lei
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Informational L. Ong Intended status: Informational L. Ong
Expires: July 25, 2008 Ciena Corporation Expires: August 6, 2008 Ciena Corporation
M. Tuexen M. Tuexen
Muenster Univ. of Applied Sciences Muenster Univ. of Applied Sciences
T. Dreibholz T. Dreibholz
University of Duisburg-Essen University of Duisburg-Essen
January 22, 2008 February 3, 2008
An Overview of Reliable Server Pooling Protocols An Overview of Reliable Server Pooling Protocols
draft-ietf-rserpool-overview-03.txt draft-ietf-rserpool-overview-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. 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 Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
The Reliable Server Pooling effort (abbreviated "RSerPool"), provides The Reliable Server Pooling effort (abbreviated "RSerPool"), provides
an application-independent set of services and protocols for building an application-independent set of services and protocols for building
fault tolerant and highly available client/server applications. This fault tolerant and highly available client/server applications. This
skipping to change at page 4, line 6 skipping to change at page 4, line 6
o facilitate different server selection policies o facilitate different server selection policies
o facilitate a set of application-independent failover capabilities o facilitate a set of application-independent failover capabilities
o peer-to-peer structure o peer-to-peer structure
The basic components of the RSerPool architecture are shown in The basic components of the RSerPool architecture are shown in
Figure 1below: Figure 1below:
....................... .......................
------ . +-------+ . ______ ______ . +-------+ .
/ ENRP \ . | | . / ENRP \ / ENRP \ . | | .
/---->| Server | . | PE 1 | . |Server| <----> |Server|<----------.----->| PE 1 | .
| /--- \______/ . | | . \______/ ENRP \______/ ASAP(1) . | | .
| | . +-------+ . ^ . +-------+ .
| | . . | . .
| | . Server Pool . | ASAP(2) . Server Pool .
| V . . V . .
+-------+ . +-------+ . +-------+ . +-------+ .
| | . | | . | | . | | .
| PU 1 |-----------------.------| PE 2 | . | PU |<---------->. | PE 2 | .
| | . | | . | | PU to PE . | | .
+-------+ . +-------+ . +-------+ . +-------+ .
. . . .
. +-------+ . . +-------+ .
. | | . . | | .
. | PE 3 | . . | PE 3 | .
. | | . . | | .
. +-------+ . . +-------+ .
....................... .......................
Figure 1 Figure 1
A server pool is defined as a set of one or more servers providing A server pool is defined as a set of one or more servers providing
the same application functionality. The servers are called Pool the same application functionality. The servers are called Pool
Elements (PEs). Multiple PEs in a server pool can be used to provide Elements (PEs). Multiple PEs in a server pool can be used to provide
fault tolerance or load sharing, for example. The PEs register into fault tolerance or load sharing, for example. The PEs register into
and deregisters out of the pool using the Aggregate Server Access and deregister out of the pool at an entity called the Endpoint
Protocol ASAP [2]. 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 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 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 a specific Pool Element located by its IP address (both IPv4 and IPv6
handle is what is specified by the Pool User (PU) when it attempts to PE addresses are supported) and port number. The pool handle is what
access a server in the pool, again using ASAP. Both IPv4 and IPv6 PE is specified by the Pool User (PU) when it attempts to access a
addresses are supported. server in the pool.
To resolve the pool handle to the address necessary to access a Pool To resolve the pool handle to the address necessary to access a Pool
Element, the PU consults an entity called the Endpoint haNdlespace Element, the PU consults an ENRP server using ASAP (this association
Redundancy Protocol (ENRP) server. This server may be a standalone is labeled ASAP(2) in the figure). The protocols used between PU and
server supporting many PUs or a part of the PU itself, however it is PE are application-specific.
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.
RSerPool provides a number of tools to aid client migration between RSerPool provides a number of tools to aid client migration between
servers on server failure: it allows the client to identify servers on server failure: it allows the client to identify
alternative servers, either on initial discovery or in real time; it alternative servers, either on initial discovery or in real time; it
also allows the original server to provide a state cookie to the also allows the original server to provide a state cookie to the
client that can be forwarded to an alternative server to provide client that can be forwarded to an alternative server to provide
application-specific state information. 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 The requirements for the Reliable Server Pooling framework are
defined in RFC3237 [1]. It is worth noting that the requirements on defined in RFC3237 [1]. It is worth noting that the requirements on
RSerPool in the area of load balancing partially overlap with GRID RSerPool in the area of load balancing partially overlap with GRID
computing/high performance computing. However, the scope of both computing/high performance computing. However, the scope of both
areas is completely different: GRID and high performance computing areas is completely different: GRID and high performance computing
also cover topics like managing different administrative domains, also cover topics like managing different administrative domains,
data locking and synchronization, inter-session communication and data locking and synchronization, inter-session communication and
resource accounting for powerful computation services, but the resource accounting for powerful computation services, but the
intention of RSerPool is simply a lightweight realization of load intention of RSerPool is simply a lightweight realization of load
distribution and session management. In particular, these distribution and session management. In particular, these
 End of changes. 10 change blocks. 
26 lines changed or deleted 31 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/