draft-ietf-rserpool-overview-04.txt   draft-ietf-rserpool-overview-05.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: August 6, 2008 Ciena Corporation Expires: August 25, 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
February 3, 2008 February 22, 2008
An Overview of Reliable Server Pooling Protocols An Overview of Reliable Server Pooling Protocols
draft-ietf-rserpool-overview-04.txt draft-ietf-rserpool-overview-05.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 August 6, 2008. This Internet-Draft will expire on August 25, 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
document provides an overview of the protocols and mechanisms in the document provides an overview of the protocols and mechanisms in the
reliable server pooling suite. reliable server pooling suite.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Aggregate Server Access Protocol (ASAP) Overview . . . . . . . 5 2. Aggregate Server Access Protocol (ASAP) Overview . . . . . . . 6
2.1. Pool Initialization . . . . . . . . . . . . . . . . . . . 6 2.1. Pool Initialization . . . . . . . . . . . . . . . . . . . 6
2.2. Pool Entity Registration . . . . . . . . . . . . . . . . . 6 2.2. Pool Entity Registration . . . . . . . . . . . . . . . . . 6
2.3. Pool Entity Selection . . . . . . . . . . . . . . . . . . 6 2.3. Pool Entity Selection . . . . . . . . . . . . . . . . . . 7
2.4. Endpoint Keep-Alive . . . . . . . . . . . . . . . . . . . 6 2.4. Endpoint Keep-Alive . . . . . . . . . . . . . . . . . . . 7
2.5. Failover Services . . . . . . . . . . . . . . . . . . . . 7 2.5. Failover Services . . . . . . . . . . . . . . . . . . . . 7
2.5.1. Cookie Mechanism . . . . . . . . . . . . . . . . . . . 7 2.5.1. Cookie Mechanism . . . . . . . . . . . . . . . . . . . 7
2.5.2. Business Card Mechanism . . . . . . . . . . . . . . . 7 2.5.2. Business Card Mechanism . . . . . . . . . . . . . . . 7
3. Endpoint Handlespace Redundancy Protocol (ENRP) Overview . . . 7 3. Endpoint Handlespace Redundancy Protocol (ENRP) Overview . . . 8
3.1. Initialization . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Initialization . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Server Discovery and Home Server Selection . . . . . . . . 8 3.2. Server Discovery and Home Server Selection . . . . . . . . 8
3.3. Failure Detection, Handlespace Audit and 3.3. Failure Detection, Handlespace Audit and
Synchronization . . . . . . . . . . . . . . . . . . . . . 8 Synchronization . . . . . . . . . . . . . . . . . . . . . 9
3.4. Server Takeover . . . . . . . . . . . . . . . . . . . . . 8 3.4. Server Takeover . . . . . . . . . . . . . . . . . . . . . 9
4. Example Scenarios . . . . . . . . . . . . . . . . . . . . . . 9 4. Example Scenarios . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Example Scenario using RSerPool Resolution Service . . . . 9 4.1. Example Scenario using RSerPool Resolution Service . . . . 9
4.2. Example Scenario using RSerPool Session Services . . . . . 10 4.2. Example Scenario using RSerPool Session Services . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15
1. Introduction 1. Introduction
The Reliable Server Pooling (RSerPool) protocol suite is designed to The Reliable Server Pooling (RSerPool) protocol suite is designed to
provide client applications ("pool users") with the ability to select provide client applications ("pool users") with the ability to select
a server (a "pool element") from among a group of servers providing a server (a "pool element") from among a group of servers providing
equivalent service (a "pool"). equivalent service (a "pool").
The RSerPool architecture supports high-availability and load The RSerPool architecture supports high-availability and load
balancing by enabling a pool user to identify the most appropriate balancing by enabling a pool user to identify the most appropriate
server from the server pool at a given time. The architecture is server from the server pool at a given time. The architecture is
defined to support a set of basic goals: defined to support a set of basic goals:
o application-independent protocol mechanisms o application-independent protocol mechanisms
o separation of server naming from IP addressing o separation of server naming from IP addressing
o use of the end-to-end principle to avoid dependancies on o use of the end-to-end principle to avoid dependencies on
intermediate equipment intermediate equipment
o separation of session availability/failover functionality from o separation of session availability/failover functionality from
application itself application itself
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
skipping to change at page 4, line 35 skipping to change at page 4, line 35
....................... .......................
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 deregister out of the pool at an entity called the Endpoint and deregister out of the pool at an entity called the Endpoint
haNdlespace Redundancy Protocol (ENRP) server, using the Aggregate haNdlespace Redundancy Protocol (ENRP) server, using the Aggregate
Server Access Protocol ASAP [2] (this association is labeled ASAP(1) Server Access Protocol ASAP [2] (this association is labelled ASAP(1)
in the figure). 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 (both IPv4 and IPv6 a specific PE located by its IP address (both IPv4 and IPv6 PE
PE addresses are supported) and port number. The pool handle is what addresses are supported) and port number. The pool handle is what is
is specified by the Pool User (PU) when it attempts to access a specified by the Pool User (PU) when it attempts to access a server
server in the pool. 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
To resolve the pool handle to the address necessary to access a Pool association is labeled ASAP(2) in the figure). The protocols used
Element, the PU consults an ENRP server using ASAP (this association between PU and PE are application-specific.
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 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. This information is
exchanged between PE and PU directly, over the association labeled PU
to PE in the figure.
An ENRP server may be a standalone server supporting many PUs or a It is envisioned that ENRP servers provide a fully distributed and
part of the PU itself, however it is envisioned that ENRP servers fault-tolerant registry service. They use ENRP [3] to maintain
provide a fully distributed and fault-tolerant registry service using synchronization of data concerning the pool handle mapping space.
ENRP [3] to maintain synchronization of data concerning the pool For PUs and PEs, the ENRP servers are functionally equal. Due to the
handle mapping space. 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 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
skipping to change at page 5, line 39 skipping to change at page 6, line 13
This document provides an overview of the RSerPool protocol suite, This document provides an overview of the RSerPool protocol suite,
specifically the Aggregate Server Access Protocol ASAP [2] and the specifically the Aggregate Server Access Protocol ASAP [2] and the
Endpoint Handlespace Redundancy Protocol ENRP [3]. In addition to Endpoint Handlespace Redundancy Protocol ENRP [3]. In addition to
the protocol specifications, there is a common parameter format the protocol specifications, there is a common parameter format
specification COMMON [4] for both protocols, a definition of server specification COMMON [4] for both protocols, a definition of server
selection rules (pool policies) POLICIES [5], as well as a security selection rules (pool policies) POLICIES [5], as well as a security
threat analysis THREATS [6]. threat analysis THREATS [6].
2. Aggregate Server Access Protocol (ASAP) Overview 2. Aggregate Server Access Protocol (ASAP) Overview
ASAP defines a straigt-forward set of mechanisms necessary to support ASAP defines a straight-forward set of mechanisms necessary to
the creation and maintenance of pools of redundant servers. These support the creation and maintenance of pools of redundant servers.
mechanisms include: These mechanisms include:
o registration of a new server into a server pool o registration of a new server into a server pool
o deregistration of an existing server from a pool o deregistration of an existing server from a pool
o resolution of a pool handle to a server or list of servers o resolution of a pool handle to a server or list of servers
o liveness detection for servers in a pool o liveness detection for servers in a pool
o failover mechanisms for handling a server failure o failover mechanisms for handling a server failure
2.1. Pool Initialization 2.1. Pool Initialization
Pools come into existence when a PE registers the first instance of 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 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 deregisters. In other words, the starting of the first PE on some
machine causes the creation of the pool when the registration reaches machine causes the creation of the pool when the registration reaches
the ENRP server. the ENRP server.
skipping to change at page 10, line 22 skipping to change at page 10, line 46
remove itself from the server pool when shutting down. remove itself from the server pool when shutting down.
When using these RSerPool services, RSerPool provides benefits that When using these RSerPool services, RSerPool provides benefits that
are limited (as compared to utilizing all services), but nevertheless are limited (as compared to utilizing all services), but nevertheless
quite useful as compared to not using RSerPool at all. First, the 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, 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 rather than a list of servers. Second, the decision as to which
server is to be used can be determined dynamically by the server server is to be used can be determined dynamically by the server
selection mechanism (i.e. a "pool policy" performed by ASAP; see ASAP selection mechanism (i.e. a "pool policy" performed by ASAP; see ASAP
[2]). Finally, when failures occur, these are reported to the pool [2]). Finally, when failures occur, these are reported to the pool
via signaling present in ASAP [2] and ENRP [3], other clients will via signalling present in ASAP [2] and ENRP [3], other clients will
eventually know (once this failure is confirmed by other elements of eventually know (once this failure is confirmed by other elements of
the RSerPool architecture) that this server has failed. the RSerPool architecture) that this server has failed.
4.2. Example Scenario using RSerPool Session Services 4.2. Example Scenario using RSerPool Session Services
When the full suite of RSerPool services is used, all communication When the full suite of RSerPool services is used, all communication
between the pool user and the pool element is mediated by the between the pool user and the pool element is mediated by the
RSerPool framework, including session establishment and teardown, and RSerPool framework, including session establishment and teardown, and
the sending and receiving of data. Accordingly, it is necessary to the sending and receiving of data. Accordingly, it is necessary to
modify the application to use the service primitives (i.e. the API) modify the application to use the service primitives (i.e. the API)
skipping to change at page 12, line 40 skipping to change at page 13, line 21
November 2007. November 2007.
[6] Stillman, M., Gopal, R., Guttman, E., Holdrege, M., and S. [6] Stillman, M., Gopal, R., Guttman, E., Holdrege, M., and S.
Sengodan, "Threats Introduced by RSerPool and Requirements for Sengodan, "Threats Introduced by RSerPool and Requirements for
Security in Response to Threats", Security in Response to Threats",
draft-ietf-rserpool-threats-09 (work in progress), October 2007. draft-ietf-rserpool-threats-09 (work in progress), October 2007.
8.2. Informative References 8.2. Informative References
[7] Dreibholz, T., "Thomas Dreibholz's RSerPool Page", [7] Dreibholz, T., "Thomas Dreibholz's RSerPool Page",
URL: http://tdrwww.exp-math.uni-essen.de/dreibholz/rserpool/. URL: http://tdrwww.iem.uni-due.de/dreibholz/rserpool/.
[8] Dreibholz, T., "Reliable Server Pooling -- Evaluation, [8] Dreibholz, T., "Reliable Server Pooling -- Evaluation,
Optimization and Extension of a Novel IETF Architecture", Ph.D. Optimization and Extension of a Novel IETF Architecture", Ph.D.
Thesis University of Duisburg-Essen, Faculty of Economics, Thesis University of Duisburg-Essen, Faculty of Economics,
Institute for Computer Science and Business Information Systems, Institute for Computer Science and Business Information Systems,
URL: http://duepublico.uni-duisburg-essen.de/servlets/ URL: http://duepublico.uni-duisburg-essen.de/servlets/
DerivateServlet/Derivate-16326/Dre2006-final.pdf, March 2007. DerivateServlet/Derivate-16326/Dre2006-final.pdf, March 2007.
Authors' Addresses Authors' Addresses
skipping to change at page 13, line 40 skipping to change at page 14, line 20
Email: tuexen@fh-muenster.de Email: tuexen@fh-muenster.de
Thomas Dreibholz Thomas Dreibholz
University of Duisburg-Essen, Institute for Experimental Mathematics University of Duisburg-Essen, Institute for Experimental Mathematics
Ellernstrasse 29 Ellernstrasse 29
45326 Essen, Nordrhein-Westfalen 45326 Essen, Nordrhein-Westfalen
Germany Germany
Phone: +49 201 183-7637 Phone: +49 201 183-7637
Fax: +49 201 183-7673 Fax: +49 201 183-7673
Email: dreibh@exp-math.uni-essen.de Email: dreibh@iem.uni-due.de
URI: http://www.exp-math.uni-essen.de/~dreibh/ URI: http://www.iem.uni-due.de/~dreibh/
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
 End of changes. 21 change blocks. 
41 lines changed or deleted 62 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/