draft-ietf-rserpool-overview-01.txt   draft-ietf-rserpool-overview-02.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: October 30, 2007 Ciena Corporation Expires: January 7, 2008 Ciena Corporation
M. Tuexen M. Tuexen
Muenster Univ. of Applied Sciences Muenster Univ. of Applied Sciences
April 28, 2007 T. Dreibholz
University of Duisburg-Essen
July 6, 2007
An Overview of Reliable Server Pooling Protocols An Overview of Reliable Server Pooling Protocols
draft-ietf-rserpool-overview-01.txt draft-ietf-rserpool-overview-02.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 37 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 October 30, 2007. This Internet-Draft will expire on January 7, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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 . . . . . . . 5
2.1. Pool Initialization . . . . . . . . . . . . . . . . . . . 5 2.1. Pool Initialization . . . . . . . . . . . . . . . . . . . 6
2.2. Pool Entity Registration . . . . . . . . . . . . . . . . . 5 2.2. Pool Entity Registration . . . . . . . . . . . . . . . . . 6
2.3. Pool Entity Selection . . . . . . . . . . . . . . . . . . 6 2.3. Pool Entity Selection . . . . . . . . . . . . . . . . . . 6
2.4. Endpoint Keepalive . . . . . . . . . . . . . . . . . . . . 6 2.4. Endpoint Keep-Alive . . . . . . . . . . . . . . . . . . . 6
2.5. Failover Services . . . . . . . . . . . . . . . . . . . . 6 2.5. Failover Services . . . . . . . . . . . . . . . . . . . . 7
2.5.1. Cookie Mechanism . . . . . . . . . . . . . . . . . . . 6 2.5.1. Cookie Mechanism . . . . . . . . . . . . . . . . . . . 7
2.5.2. Business Card Mechanism . . . . . . . . . . . . . . . 7 2.5.2. Business Card Mechanism . . . . . . . . . . . . . . . 7
3. Endpoint Nameserver Redundancy Protocol (ENRP) Overview . . . 7 3. Endpoint Handlespace Redundancy Protocol (ENRP) Overview . . . 7
3.1. Initialization . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Initialization . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Server Discovery and Home Server Selection . . . . . . . . 7 3.2. Server Discovery and Home Server Selection . . . . . . . . 8
3.3. Server Pool Maintenance . . . . . . . . . . . . . . . . . 8 3.3. Failure Detection, Handlespace Audit and
4. Example Scenarios . . . . . . . . . . . . . . . . . . . . . . 8 Synchronization . . . . . . . . . . . . . . . . . . . . . 8
4.1. Example Scenario Using RSerPool Resolution Service . . . . 8 3.4. Server Takeover . . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Standalone Mode . . . . . . . . . . . . . . . . . . . 8 4. Example Scenarios . . . . . . . . . . . . . . . . . . . . . . 9
4.1.2. Pool Mode . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Example Scenario using RSerPool Resolution Service . . . . 9
4.2. Example Scenario Using RSerPool Session Services . . . . . 9 4.2. Example Scenario using RSerPool Session Services . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
8. Normative References . . . . . . . . . . . . . . . . . . . . . 11 8. Normative References . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14
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
skipping to change at page 3, line 33 skipping to change at page 3, line 33
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
The basic components of the Rserpool architecture are shown in The basic components of the RSerPool architecture are shown in
Figure 1 below: Figure 1 below:
....................... .......................
------ . +-------+ . ------ . +-------+ .
/ ENRP \ . | | . / ENRP \ . | | .
/---->| Server | . | PE 1 | . /---->| Server | . | PE 1 | .
| /--- \______/ . | | . | /--- \______/ . | | .
| | . +-------+ . | | . +-------+ .
| | . . | | . .
| | . server pool . | | . Server Pool .
| V . . | V . .
+-------+ . +-------+ . +-------+ . +-------+ .
| | . | | . | | . | | .
| PU 1 |-----------------.------| PE 2 | . | PU 1 |-----------------.------| PE 2 | .
| | . | | . | | . | | .
+-------+ . +-------+ . +-------+ . +-------+ .
. . . .
. +-------+ . . +-------+ .
. | | . . | | .
. | PE 3 | . . | PE 3 | .
skipping to change at page 4, line 37 skipping to change at page 4, line 37
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 deregisters out of the pool using the Aggregate Server Access
Protocol ASAP [2]. Protocol ASAP [2].
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. The pool handle allows a mapping from the pool to a pool handle (PH). The pool handle allows a mapping from the pool to
specific Pool Element located by its IP address and port. The pool 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 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 access a server in the pool, again using ASAP. Both IPv4 and IPv6 PE
addresses are supported. addresses are supported.
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 entity called the Endpoint haNdlespace
Redundancy Protocol (ENRP) server. This server may be a standalone Redundancy Protocol (ENRP) server. This server may be a standalone
server supporting many PUs or a part of the PU itself, however it is server supporting many PUs or a part of the PU itself, however it is
envisioned that ENRP servers provide a fully distributed and fault- envisioned that ENRP servers provide a fully distributed and fault-
tolerant registry service using ENRP [3] to maintain synchronization tolerant registry service using ENRP [3] to maintain synchronization
of data concerning the pool handle mapping space. 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.
The requirements for the Reliable Server Pooling effort are defined The requirements for the Reliable Server Pooling framework are
in RFC3237 [1]. 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.
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 Nameserver Redundancy Protocol ENRP [3]. Endpoint Handlespace Redundancy Protocol ENRP [3]. In addition to
the protocol specifications, there is a common parameter format
In addition to the protocol specifications, there is a common specification COMMON [4] for both protocols, a definition of server
parameter format specification COMMON [4] for both protocols, as well selection rules (pool policies) POLICIES [5], as well as a security
as a security threat analysis SEC [5]. threat analysis THREATS [6].
2. Aggregate Server Access Protocol (ASAP) Overview 2. Aggregate Server Access Protocol (ASAP) Overview
ASAP is a straight-forward implementation of a set of mechanisms ASAP defines a straigt-forward set of mechanisms necessary to support
identified as necessary for support of the creation and maintenance the creation and maintenance of pools of redundant servers. These
of pools of redundant servers. These mechanisms include: mechanisms include:
o registration of a new server for the server pool o registration of a new server into a server pool
o deregistration of an existing server from the 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 the pool o liveness detection for servers in a pool
o failover mechanisms for handling 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.
2.2. Pool Entity Registration 2.2. Pool Entity Registration
A new server joins an existing pool by sending a Registration message A new server joins an existing pool by sending a Registration message
in ASAP to an ENRP server, indicating the 'handle' of the pool that via ASAP to an ENRP server, indicating the pool handle of the pool
it wishes to join, a pool identifier for itself (chosen randomly) that it wishes to join, a PE identifier for itself (chosen randomly),
information about it's lifetime in the pool, and what transport information about its lifetime in the pool, and what transport
protocols and selection policies it supports. The ENRP server that protocols and selection policy it supports. The ENRP server that it
it first contacts is called its Home ENRP server, and maintains a first contacts is called its Home ENRP server, and maintains a list
list of subscriptions by the PE as well as performing periodic audits of subscriptions by the PE as well as performs periodic audits to
to confirm that the PE is still responsive. confirm that the PE is still responsive.
Similar procedures are applied to de-register itself from the server Similar procedures are applied to de-register itself from the server
pool (or alternatively the server may simply let the lifetime that it pool (or alternatively the server may simply let the lifetime that it
previously registered with expire, after which it is gracefully previously registered with expire, after which it is gracefully
removed from the pool. removed from the pool.
2.3. Pool Entity Selection 2.3. Pool Entity Selection
When an endpoint wishes to be connected to a server in the pool, it 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 generates an ASAP Handle Resolution message and sends this to its
home ENRP server. The ENRP server resolves the handle based on its home ENRP server. The ENRP server resolves the handle based on its
knowledge of pool servers and returns a Handle Resolution Response in knowledge of pool servers and returns a Handle Resolution Response
ASAP. The Resolution Response contains a list of the IP addresses of via ASAP. The response contains a list of the IP addresses of one or
one or more servers in the pool that can be contacted. The process more servers in the pool that can be contacted. The process by which
by which the list of servers is created may involve a number of the list of servers is created may involve a number of policies for
policies for server selection. The RSerPool protocol suite supports server selection. The RSerPool protocol suite defines a few basic
a few simply defined policies and allows the use of external server policies and allows the use of external server selection input for
selection input for more complex policies. more complex policies.
2.4. Endpoint Keepalive 2.4. Endpoint Keep-Alive
ENRP servers monitor the status of pool elements using the ASAP Keep ENRP servers monitor the status of pool elements using the ASAP
Alive message. A Pool Element responds to the ASAP Keep Alive Endpoint Keep-Alive message. A PE responds to the ASAP Keep-Alive
message with an Ack response. message with an Endpoint Keep-Alive Ack response.
In addition, an endpoint can notify its home ENRP server that the PE In addition, a PU can notify its home ENRP server that the PE it used
the endpoint was using has become unresponsive by sending the ENRP has become unresponsive by sending an ASAP Endpoint Unreachable
server an Endpoint Unreachable message. message to the ENRP server.
2.5. Failover Services 2.5. Failover Services
While maintaining application-independence, the RSerPool protocol While maintaining application-independence, the RSerPool protocol
suite provides some simple hooks for supporting failover of an suite provides some simple hooks for supporting failover of an
individual session with a pool element. Generally, mechanisms for individual session with a pool element. Generally, mechanisms for
failover that rely on application state or transaction status cannot failover that rely on application state or transaction status cannot
be defined 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 supported. However, some simple mechanisms supported by RSerPool
allow some level of failover that any application can use. allow some level of failover that any application can use.
2.5.1. Cookie Mechanism 2.5.1. Cookie Mechanism
Cookies may optionally be generated by the ASAP layer and Cookies may optionally be generated by the ASAP layer and
periodically sent from the PE to the PU. The PU only stores the last 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. In case of failover the PU sends this last received
received cookie to the new PE. This method provides a simple way of cookie to the new PE. This method provides a simple way of state
state sharing between the PEs. Please note that the old PE should sharing between the PEs. Please note that the old PE should sign the
sign the cookie and the receiving PE should verify the signature. cookie and the receiving PE should verify that signature. For the
For the PU, the cookie has no structure and is only stored and PU, the cookie has no structure and is only stored and transmitted to
transmitted to the new PE. the new PE.
2.5.2. Business Card Mechanism 2.5.2. Business Card Mechanism
A PE can send a business card to its peer (PE or PU) containing its 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 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 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 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 be based on pool considerations, such as load balancing, or user
considerations, such as PEs that have the most up-to-date state considerations, such as PEs that have the most up-to-date state
information. information.
3. Endpoint Nameserver Redundancy Protocol (ENRP) Overview 3. Endpoint Handlespace Redundancy Protocol (ENRP) Overview
A server pool can be supported by one or more ENRP servers. If A set of server pools, which is denoted as a handlespace, is managed
multiple ENRP servers are used to support a single pool then the ENRP by ENRP servers. Pools are not valid in the whole Internet but only
protocol is used between the ENRP servers in order to maintain a in smaller domains, called the operational scope. The ENRP servers
distributed, fault-tolerant real-time registry service. ENRP servers use the ENRP protocol in order to maintain a distributed, fault-
communicate with each other in order to exchange information such as tolerant, real-time registry service. ENRP servers communicate with
pool membership changes, handlespace data synchronization, etc. each other for information exchange, such as pool membership changes,
handlespace data synchronization, etc..
3.1. Initialization 3.1. Initialization
Each ENRP server initially generates a 32-bit server ID that it uses Each ENRP server initially generates a 32-bit server ID that it uses
in subsequent messaging and remains unchanged over the lifetime of in subsequent messaging and remains unchanged over the lifetime of
the server. It then attempts to learn all of the other ENRP servers the server. It then attempts to learn all of the other ENRP servers
within the scope of the server pool, either by 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 Mentor server or by sending out Presence messages on a well-known
multicast channel to determine other ENRP servers from the responses multicast channel in order to determine other ENRP servers from the
and select one as Mentor. A Mentor can be any peer ENRP server that responses and select one as Mentor. A Mentor can be any peer ENRP
it selects to provide current data about the pool. server. The most current handlespace data is requested by Handle
Table Requests from the Mentor. The received answer in form of
It then requests the most current data about the pool handlespace Handle Table Response messages is unpacked into the local database.
from its Mentor server and unpacks received Handle Table Response After that, the ENRP server is ready to provide ENRP services.
messages into its local database.
It is then ready to provide ENRP services.
3.2. Server Discovery and Home Server Selection 3.2. Server Discovery and Home Server Selection
PEs can now register their presence with the newly functioning ENRP PEs can now register their presence with the newly functioning ENRP
server by using ASAP messages. They discover the new ENRP server server by using ASAP messages. They discover the new ENRP server
after the server sends out an ASAP Server Announce message on the after the server sends out an ASAP Server Announce message on the
well-known ASAP multicast channel. PEs need only register with one well-known ASAP multicast channel. PEs only have to register with
ENRP server, as other ENRP servers supporting the pool will one ENRP server, as other ENRP servers supporting the pool will
synchronize their knowledge about pool elements using the ENRP synchronize their knowledge about pool elements using the ENRP
protocol. protocol.
The PE may have a configured list of ENRP servers to talk to, in the 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 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 associations with some number of them and assign the first one that
responds to it as its Home ENRP Server. responds to it as its Home ENRP Server.
Alternatively it can listen on the multicast channel for a set period Alternatively it can listen on the multicast channel for a set period
and when it hears an ENRP server, start an association. The first and when it hears an ENRP server, start an association. The first
server it gets up can then become its Home ENRP Server. server it gets up can then become its Home ENRP Server.
3.3. Server Pool Maintenance 3.3. Failure Detection, Handlespace Audit and Synchronization
PE failure detection, keepalive, etc. TBD ENRP servers send ENRP Presence messages to all of their peers in
order to show their liveness. These Presence messages also include a
checksum computed over all PE identities for which the ENRP server is
in the role of a Home ENRP server. Each ENRP server maintains an up-
to-date list of its peers and can also compute the checksum expected
from a certain peer, according to its local handlespace database. By
comparing the expected sum and the sum reported by a peer (denoted as
handlespace audit), an inconsistency can be detected. In such a
case, the handlespace -- restricted to the PEs owned by that peer --
can be requested for synchronization, analogously to Section 3.2.
4. Example Scenarios 3.4. Server Takeover
4.1. Example Scenario Using RSerPool Resolution Service If the unresponsiveness of an ENRP server is detected, the remaining
ENRP servers negotiate which other server takes over the Home ENRP
role for the PEs of the failed peer. After reaching a consensus on
the takeover, the ENRP server taking over these PEs sends a
notification to its peers (via ENRP) as well as to the PEs taken over
(via ASAP).
4.1.1. Standalone Mode 4. Example Scenarios
4.1. Example Scenario using RSerPool Resolution Service
RSerPool can be used in a 'standalone' manner, where the application RSerPool can be used in a 'standalone' manner, where the application
uses RSerPool to determine the address of a primary server in the uses RSerPool to determine the address of a primary server in the
pool, and then interacts directly with that server without further pool, and then interacts directly with that server without further
use of RSerPool services. If the initial server fails, the use of RSerPool services. If the initial server fails, the
application uses RSerPool again to find the next server in the pool. 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 For pool user ("client") applications, if an ASAP implementation is
available on the client system, there are typically only three available on the client system, there are typically only three
modifications required to the application source code: modifications required to the application source code:
1. Instead of specifying the hostnames of primary, secondary, 1. Instead of specifying the hostnames of primary, secondary,
tertiary servers, etc., the application user specifies a pool tertiary servers, etc., the application user specifies a pool
handle. handle.
2. Instead of using a DNS based service (e.g. the Unix library 2. Instead of using a DNS based service (e.g. the Unix library
function gethostbyname()) to translate from a hostname to an IP function getaddrinfo()) to translate from a hostname to an IP
address, the application will invoke an RSerPool service address, the application will invoke an RSerPool service
primitive GETPRIMARYSERVER that takes as input a pool handle, and primitive GETPRIMARYSERVER that takes as input a pool handle, and
returns the IP address of the primary server. The application returns the IP address of the primary server. The application
then uses that IP address just as it would have used the IP then uses that IP address just as it would have used the IP
address returned by the DNS in the previous scenario. address returned by the DNS in the previous scenario.
3. Without the use of additional RSerPool services, failure 3. Without the use of additional RSerPool services, failure
detection and failover procedures must be designed into each detection and failover procedures must be designed into each
application. However, when failure is detected on the primary application. However, when failure is detected on the primary
server, instead of invoking DNS translation again on the hostname server, instead of invoking DNS translation again on the hostname
skipping to change at page 9, line 48 skipping to change at page 10, line 26
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 signaling 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 are 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)
provided by RSerPool, rather than the transport layer primitives provided by RSerPool, rather than the transport layer primitives
provided by TCP, SCTP, or whatever transport protocol is being used. provided by TCP, SCTP, or whatever transport protocol is being used.
As in the previous case, sessions (rather than connections or As in the previous case, sessions (rather than connections or
associations) are established, and the destination endpoint is associations) are established, and the destination endpoint is
specified as a pool handle rather than as a list of IP addresses with specified as a pool handle rather than as a list of IP addresses with
skipping to change at page 10, line 37 skipping to change at page 11, line 15
An application server (pool element) can provide a state cookie An application server (pool element) can provide a state cookie
(described in Section 2.5.1) that is automatically passed on to (described in Section 2.5.1) that is automatically passed on to
another pool element (by the ASAP layer at the pool user) in the another pool element (by the ASAP layer at the pool user) in the
event of a failover. This state cookie can be used to assist the event of a failover. This state cookie can be used to assist the
application at the new pool element in recreating whatever state application at the new pool element in recreating whatever state
is needed to continue a session or transaction that was is needed to continue a session or transaction that was
interrupted by a failure in the communication between a pool user interrupted by a failure in the communication between a pool user
and the original pool element. and the original pool element.
The application client (pool user) can provide a callback function The application client (pool user) can provide a callback function
(described in Section 2.5.2) that is invoked on the pool user side that is invoked on the pool user side in the case of a failover.
in the case of a failover. This callback function can execute any This callback function can execute any application specific
application specific failover code, such as generating a special failover code, such as generating a special message (or sequence
message (or sequence of messages) that helps the new pool element of messages) that helps the new pool element construct any state
construct any state needed to continue an in-process session. needed to continue an in-process session.
Suppose in a particular peer-to-peer application, PU A is Suppose in a particular peer-to-peer application, PU A is
communicating with PE B, and it so happens that PU A is also a PE communicating with PE B, and it so happens that PU A is also a PE
in pool X. PU A can pass a "business card" to PE B identifying it in pool X. PU A can pass a "business card" to PE B identifying it
as a member of pool X. In the event of a failure at A, or a as a member of pool X. In the event of a failure at A, or a
failure in the communication link between A and B, PE B can use failure in the communication link between A and B, PE B can use
the information in the business card to contact an equivalent PE the information in the business card to contact an equivalent PE
to PU A from pool X. to PU A from pool X.
Additionally, if the application at PU A is aware of some Additionally, if the application at PU A is aware of some
particular PEs of pool X that would be preferred for B to contact 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 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 that list to the ASAP layer, and it will be included in A's
business card. (See Section 2.5.2). business card (see Section 2.5.2).
5. Security Considerations 5. Security Considerations
This document does not identify security requirements beyond those This document does not identify security requirements beyond those
already documented in the ENRP and ASAP protocol specifications. already documented in the ENRP and ASAP protocol specifications. A
security threat analysis of RSerPool is provided in THREATS [6].
6. IANA Considerations 6. IANA Considerations
This document does not require additional IANA actions beyond those This document does not require additional IANA actions beyond those
already identified in the ENRP and ASAP protocol specifications. already identified in the ENRP and ASAP protocol specifications.
7. Acknowledgements 7. Acknowledgements
The authors wish to thank Maureen Stillman, Qiaobing Xie, Randall The authors wish to thank Maureen Stillman, Qiaobing Xie, Randall
Stewart, Scott Bradner, and many others for their invaluable Stewart, Scott Bradner, and many others for their invaluable
skipping to change at page 11, line 44 skipping to change at page 12, line 23
draft-ietf-rserpool-asap-15 (work in progress), January 2007. draft-ietf-rserpool-asap-15 (work in progress), January 2007.
[3] Stewart, R., "Endpoint Handlespace Redundancy Protocol (ENRP)", [3] Stewart, R., "Endpoint Handlespace Redundancy Protocol (ENRP)",
draft-ietf-rserpool-enrp-15 (work in progress), January 2007. draft-ietf-rserpool-enrp-15 (work in progress), January 2007.
[4] Stewart, R., "Aggregate Server Access Protocol (ASAP) and [4] Stewart, R., "Aggregate Server Access Protocol (ASAP) and
Endpoint Handlespace Redundancy Protocol (ENRP) Parameters", Endpoint Handlespace Redundancy Protocol (ENRP) Parameters",
draft-ietf-rserpool-common-param-11 (work in progress), draft-ietf-rserpool-common-param-11 (work in progress),
October 2006. October 2006.
[5] Stillman, M., "Threats Introduced by Rserpool and Requirements [5] Tuexen, M. and T. Dreibholz, "Reliable Server Pooling Policies",
draft-ietf-rserpool-policies-04 (work in progress), March 2007.
[6] Stillman, M., "Threats Introduced by Rserpool and Requirements
for Security in response to Threats", for Security in response to Threats",
draft-ietf-rserpool-threats-06 (work in progress), draft-ietf-rserpool-threats-06 (work in progress),
November 2006. November 2006.
Authors' Addresses Authors' Addresses
Peter Lei Peter Lei
Cisco Systems, Inc. Cisco Systems, Inc.
955 Happfield Dr. 955 Happfield Dr.
Arlington Heights, IL 60004 Arlington Heights, IL 60004
skipping to change at page 13, line 5 skipping to change at page 13, line 20
Email: Lyong@Ciena.com Email: Lyong@Ciena.com
Michael Tuexen Michael Tuexen
Muenster Univ. of Applied Sciences Muenster Univ. of Applied Sciences
Stegerwaldstr. 39 Stegerwaldstr. 39
48565 Steinfurt 48565 Steinfurt
Germany Germany
Email: tuexen@fh-muenster.de Email: tuexen@fh-muenster.de
Thomas Dreibholz
University of Duisburg-Essen, Institute for Experimental Mathematics
Ellernstrasse 29
45326 Essen, Nordrhein-Westfalen
Germany
Phone: +49 201 183-7637
Fax: +49 201 183-7673
Email: dreibh@exp-math.uni-essen.de
URI: http://www.exp-math.uni-essen.de/~dreibh/
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 End of changes. 48 change blocks. 
104 lines changed or deleted 145 lines changed or added

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