draft-ietf-rserpool-arch-09.txt   draft-ietf-rserpool-arch-10.txt 
Network Working Group M. Tuexen, Ed. Network Working Group M. Tuexen, Ed.
Internet-Draft Muenster Univ. of Applied Sciences Internet-Draft Muenster Univ. of Applied Sciences
Expires: August 24, 2005 Q. Xie Expires: January 8, 2006 Q. Xie
Motorola, Inc. Motorola, Inc.
R. Stewart R. Stewart
M. Shore M. Shore
Cisco Systems, Inc. Cisco Systems, Inc.
J. Loughney J. Loughney
Nokia Research Center Nokia Research Center
A. Silverton A. Silverton
Motorola Labs Motorola Labs
February 20, 2005 July 7, 2005
Architecture for Reliable Server Pooling Architecture for Reliable Server Pooling
draft-ietf-rserpool-arch-09.txt draft-ietf-rserpool-arch-10.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 24, 2005. This Internet-Draft will expire on January 8, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document describes an architecture and protocols for the This document describes an architecture and protocols for the
management and operation of server pools supporting highly reliable management and operation of server pools supporting highly reliable
applications, and for client access mechanisms to a server pool. applications, and for client access mechanisms to a server pool.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
2. Reliable Server Pooling Architecture . . . . . . . . . . . . . 4 2. Reliable Server Pooling Architecture . . . . . . . . . . . . . 5
2.1 RSerPool Functional Components . . . . . . . . . . . . . . 4 2.1 RSerPool Functional Components . . . . . . . . . . . . . . 5
2.1.1 Pool Elements . . . . . . . . . . . . . . . . . . . . 4 2.1.1 Pool Elements . . . . . . . . . . . . . . . . . . . . 5
2.1.2 ENRP Servers . . . . . . . . . . . . . . . . . . . . . 5 2.1.2 ENRP Servers . . . . . . . . . . . . . . . . . . . . . 5
2.1.3 Pool Users . . . . . . . . . . . . . . . . . . . . . . 5 2.1.3 Pool Users . . . . . . . . . . . . . . . . . . . . . . 6
2.2 RSerPool Protocol Overview . . . . . . . . . . . . . . . . 5 2.2 RSerPool Protocol Overview . . . . . . . . . . . . . . . . 6
2.2.1 Endpoint Handlespace Redundancy Protocol . . . . . . . 6 2.2.1 Endpoint Handlespace Redundancy Protocol . . . . . . . 6
2.2.2 Aggregate Server Access Protocol . . . . . . . . . . . 6 2.2.2 Aggregate Server Access Protocol . . . . . . . . . . . 7
2.2.3 PU <-> ENRP Server Communication . . . . . . . . . . . 7 2.2.3 PU <-> ENRP Server Communication . . . . . . . . . . . 7
2.2.4 PE <-> ENRP Server Communication . . . . . . . . . . . 8 2.2.4 PE <-> ENRP Server Communication . . . . . . . . . . . 8
2.2.5 PU <-> PE Communication . . . . . . . . . . . . . . . 8 2.2.5 PU <-> PE Communication . . . . . . . . . . . . . . . 8
2.2.6 ENRP Server <-> ENRP Server Communication . . . . . . 9 2.2.6 ENRP Server <-> ENRP Server Communication . . . . . . 9
2.2.7 PE <-> PE Communication . . . . . . . . . . . . . . . 10 2.2.7 PE <-> PE Communication . . . . . . . . . . . . . . . 10
2.3 Failover Support . . . . . . . . . . . . . . . . . . . . . 10 2.3 Failover Support . . . . . . . . . . . . . . . . . . . . . 10
2.3.1 Business Cards . . . . . . . . . . . . . . . . . . . . 10 2.3.1 Business Cards . . . . . . . . . . . . . . . . . . . . 10
2.3.2 Cookies . . . . . . . . . . . . . . . . . . . . . . . 12 2.3.2 Cookies . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 Typical Interactions between RSerPool Components . . . . . 12 2.4 Typical Interactions between RSerPool Components . . . . . 12
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1 Two File Transfer Examples . . . . . . . . . . . . . . . . 13 3.1 Two File Transfer Examples . . . . . . . . . . . . . . . . 14
3.1.1 The RSerPool Aware Client . . . . . . . . . . . . . . 14 3.1.1 The RSerPool Aware Client . . . . . . . . . . . . . . 15
3.1.2 The RSerPool Unaware Client . . . . . . . . . . . . . 15 3.1.2 The RSerPool Unaware Client . . . . . . . . . . . . . 16
3.2 Load Balancing Example . . . . . . . . . . . . . . . . . . 16 3.2 Load Balancing Example . . . . . . . . . . . . . . . . . . 17
3.3 Telephony Signaling Example . . . . . . . . . . . . . . . 17 3.3 Telephony Signaling Example . . . . . . . . . . . . . . . 18
3.3.1 Decomposed GWC and GK Scenario . . . . . . . . . . . . 18 3.3.1 Decomposed GWC and GK Scenario . . . . . . . . . . . . 19
3.3.2 Collocated GWC and GK Scenario . . . . . . . . . . . . 19 3.3.2 Collocated GWC and GK Scenario . . . . . . . . . . . . 20
4. Security Considerations . . . . . . . . . . . . . . . . . . . 20 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
6.1 Normative References . . . . . . . . . . . . . . . . . . . 21 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.2 Informative References . . . . . . . . . . . . . . . . . . 21 7.1 Normative References . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21 7.2 Informative References . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . 25
1. Introduction 1. Introduction
1.1 Overview 1.1 Overview
This document defines an architecture, for providing a highly A server pool is defined as a set of one or more servers providing
available reliable server function in support of a service or set of the same application functionality. These servers are called Pool
services. This is achieved by forming a pool of servers, each of Elements (PEs). PEs form the first class of entities in the RSerPool
which is capable of supporting the desired service(s), and providing architecture. Multiple PEs in a server pool can be used to provide
a name service that will resolve requests from a service user to the fault tolerance or load sharing, for example.
identity of a working server in the pool.
To access a server pool, the pool user consults an ENRP server. The Each server pool is identified by a unique identifier which is simply
name service itself can be provided by a pool of ENRP servers using a a byte string, called the pool handle. This allows binary
shared protocol to make the name resolution function fault-tolerant. identifiers to be used.
It is assumed that the handle space is kept flat and designed for a
limited scale in order to keep the protocols simple, robust and fast.
The server pool itself is supported by a shared protocol between These pool handles are not valid in the whole internet but only in
servers and the name service allowing servers to enter and exit the smaller domains, called the operational scope. Furthermore, the
pool. Several server selection mechanisms, called server pool handle-space is assumed to be flat, so that multiple levels of query
policies, are supported for flexibility. are not necessary to resolve a pool handle.
The second class of entities in the RSerPool architecture is the
class of Endpoint haNdlespace Redundancy Protocol (ENRP) servers.
ENRP servers are designed to provide a fully distributed fault-
tolerant real-time translation service that maps a pool handle to set
of transport addresses pointing to a specific group of networked
communication endpoints registered under that pool handle. To be
more precise, ENRP servers can resolve a pool handle to a list of
information which allows the Pool User (PU) to access a PE of the
server pool identified by the handle. This information includes:
o A list of IPv4 and/or IPv6 addresses.
o A protocol field specifying the transport layer protocol.
o A port number associated with the transport protocol, e.g. SCTP,
TCP or UDP.
Note that the RSerPool architecture supports both IPv4 and IPv6
addressing.
In each operational scope there must be at least one ENRP server.
All ENRP servers within the operational scope have knowledge of all
server pools within the operational scope.
RFC3237 [9] also requires that the ENRP servers should not resolve a
pool handle to a transport layer address of a PE which is not in
operation. Therefore each PE is supervised by one specific ENRP
server, called the home ENRP server of that PE. If it detects that
the PE is out of service all other ENRP servers are informed.
1.2 Terminology 1.2 Terminology
This document uses the following terms: This document uses the following terms:
Home ENRP Server: The ENRP server a Pool Element has registered with. Home ENRP Server: The ENRP server a Pool Element has registered with.
This ENRP server supervises the Pool Element. This ENRP server supervises the Pool Element.
Operational scope: The part of the network visible to pool users by a Operational scope: The part of the network visible to pool users by a
specific instance of the reliable server pooling protocols. specific instance of the reliable server pooling protocols.
skipping to change at page 5, line 49 skipping to change at page 6, line 29
the PE is out of service all other ENRP servers are informed. the PE is out of service all other ENRP servers are informed.
2.1.3 Pool Users 2.1.3 Pool Users
A third class of entities in the architecture is the Pool User (PU) A third class of entities in the architecture is the Pool User (PU)
class, consisting of the clients being served by the PEs of a server class, consisting of the clients being served by the PEs of a server
pool. pool.
2.2 RSerPool Protocol Overview 2.2 RSerPool Protocol Overview
Based on the requirements in RFC3237 [9], two new protocols: ENRP Based on the requirements in RFC3237 [9], the architecture of two new
(Endpoint haNdlespace Redundancy Protocol) and ASAP (Aggregate Server protocols is introduced in this document: ENRP (Endpoint haNdlespace
Access Protocol). These are used because no existing protocols are Redundancy Protocol) and ASAP (Aggregate Server Access Protocol).
suitable (see [3]). These are used because no existing protocols are suitable (see [3]).
2.2.1 Endpoint Handlespace Redundancy Protocol 2.2.1 Endpoint Handlespace Redundancy Protocol
The ENRP servers use a protocol called Endpoint haNdlespace The ENRP servers use a protocol called Endpoint haNdlespace
Redundancy Protocol (ENRP) for communication with each other to Redundancy Protocol (ENRP) for communication with each other to
exchange information and updates about the server pools. exchange information and updates about the server pools.
ENRP guarantees the integrity of the RSerPool handlespace by ENRP guarantees the integrity of the RSerPool handlespace by
providing the means for an ENRP server to providing the means for an ENRP server to
o update its peers regarding changes to the handlspace caused by the o update its peers regarding changes to the handlspace caused by the
addition of a PE or the status change of an existing PE, addition of a PE or the status change of an existing PE,
o monitor the health of its peers, and, if necessary, take over the o monitor the health of its peers, and, if necessary, take over the
responsibility of being the home ENRP server for a set of PEs when responsibility of being the home ENRP server for a set of PEs when
the ENRP server previously responsbile for those PEs has failed, the ENRP server previously responsible for those PEs has failed,
and and
o audit the handlespace for inconsistencies and synchronize the o audit the handlespace for inconsistencies and synchronize the
handlespace amongst its peers when inconsistencies have been handlespace amongst its peers when inconsistencies have been
found. found.
2.2.2 Aggregate Server Access Protocol 2.2.2 Aggregate Server Access Protocol
The PU wanting service from the pool uses the Aggregate Server Access The PU wanting service from the pool uses the Aggregate Server Access
Protocol (ASAP) to access members of the pool. Depending on the Protocol (ASAP) to access members of the pool. Depending on the
skipping to change at page 6, line 45 skipping to change at page 7, line 25
ASAP uses pool handles for addressing which isolates a logical ASAP uses pool handles for addressing which isolates a logical
communication endpoint from its IP address(es), thus effectively communication endpoint from its IP address(es), thus effectively
eliminating the binding between the communication endpoint and its eliminating the binding between the communication endpoint and its
physical IP address(es) which normally constitutes a single point of physical IP address(es) which normally constitutes a single point of
failure. failure.
In addition, ASAP provides some mechanisms to support loadsharing In addition, ASAP provides some mechanisms to support loadsharing
between PEs within the same pool and to support the upper layer in between PEs within the same pool and to support the upper layer in
case of a failover between PEs becomes necessary. case of a failover between PEs becomes necessary.
ASAP is also used by a PE to join or leave a server pool. It ASAP is also used by a PE to join or leave a server pool. The PE
registers or deregisters itself by communicating with a ENRP server, registers or deregisters itself by communicating with an ENRP server,
which will normally the home ENRP server. ASAP allows dynamic system which will normally be the home ENRP server. ASAP allows dynamic
scalability, allowing the pool membership to change at any time. system scalability, allowing the pool membership to change at any
time.
ASAP is used by a home ENRP server to supervise the PEs that have ASAP is used by a home ENRP server to supervise the PEs that have
registered with that ENRP server. If the home ENRP server detects registered with that ENRP server. If the home ENRP server detects
that a PE is out of service via ASAP, it notifies its peers using that a PE is out of service via ASAP, it notifies its peers using
ENRP as described previously. ENRP as described previously.
2.2.3 PU <-> ENRP Server Communication 2.2.3 PU <-> ENRP Server Communication
The PU <-> ENRP server communication is used for resolving pool The PU <-> ENRP server communication is used for resolving pool
handles and uses ASAP. The PU sends a pool handle to the ENRP server handles and uses ASAP. The PU sends a pool handle to the ENRP server
and gets back the information necessary for accessing a server in a and gets back the information necessary for accessing a server in a
server pool. server pool.
This communication can be based on SCTP or TCP if the PU does not This communication can be based on SCTP or TCP if the PU does not
support SCTP. The protocol stack for an SCTP capable PU is given in support SCTP. The protocol stack for a PU is shown in Figure 1.
Figure 1.
******** ********** ********** ************
* PU * * ENRP * * PU * * ENRP *
* * * server * * * * server *
******** ********** ********** ************
+------+ +------+ +--------+ +--------+
| ASAP | | ASAP | | ASAP | | ASAP |
+------+ +------+ +--------+ +--------+
| SCTP | | SCTP | |SCTP/TCP| |SCTP/TCP|
+------+ +------+ +--------+ +--------+
| IP | | IP | | IP | | IP |
+------+ +------+ +--------+ +--------+
Protocol stack between PU and ENRP server Protocol stack between PU and ENRP server
Figure 1 Figure 1
2.2.4 PE <-> ENRP Server Communication 2.2.4 PE <-> ENRP Server Communication
The PE <-> ENRP server communication is used for registration and The PE <-> ENRP server communication is used for registration and
deregistration of the PE in one or more pools and for the supervision deregistration of the PE in one or more pools and for the supervision
of the PE by the home ENRP server. This communication uses ASAP and of the PE by the home ENRP server. This communication uses ASAP and
skipping to change at page 13, line 33 skipping to change at page 13, line 33
(d) server pool <-> server pool: (ASAP) A PE in a server pool can (d) server pool <-> server pool: (ASAP) A PE in a server pool can
become a PU to another pool when the PE tries to initiate become a PU to another pool when the PE tries to initiate
communication with the other pool. In such a case, the communication with the other pool. In such a case, the
interactions described in (a) and (c) above will apply. interactions described in (a) and (c) above will apply.
(e) ENRP server <-> ENRP server: (ENRP) ENRP can be used to fulfill (e) ENRP server <-> ENRP server: (ENRP) ENRP can be used to fulfill
various handle space operation, administration, and maintenance various handle space operation, administration, and maintenance
(OAM) functions. (OAM) functions.
(f) Other Clients <-> Proxy/Gateway: standard protocols The (f) Other Clients <-> Proxy/Gateway: standard protocols The proxy/
proxy/gateway enables clients ("other clients"), which are not gateway enables clients ("other clients"), which are not RSerPool
RSerPool aware, to access services provided by an RSerPool based aware, to access services provided by an RSerPool based server
server pool. It should be noted that these proxies/gateways may pool. It should be noted that these proxies/gateways may become a
become a single point of failure. single point of failure.
3. Examples 3. Examples
In this section the basic concepts behind ENRP and ASAP are motivated
through examples. First, an RSerPool aware FTP server and Rserpool
aware clients are presented. Secondly, a scenario with an RSerPool
aware server with an Rserpool non-aware client shows how to
effectively use Rserpool with legacy clients or in a situation where
exposure to the PU of the list of addresses associated with the
handlespace is undesirable. This requirement has been expressed by
some telephony network operators who are concerned about potential
network address mapping. The last two examples illustrate load
balancing and telephony scenarios.
In this section the basic concepts of ENRP and ASAP will be In this section the basic concepts of ENRP and ASAP will be
described. First an RSerPool aware FTP server is considered. The described. First an RSerPool aware FTP server is considered. The
interaction with an RSerPool aware and an non-aware client is given. interaction with an RSerPool aware and an non-aware client is given.
Finally, a telephony example is considered. Finally, a telephony example is considered.
3.1 Two File Transfer Examples 3.1 Two File Transfer Examples
In this section we present two separate file transfer examples using In this section we present two file transfer examples using ENRP and
ENRP and ASAP. We present two separate examples demonstrating an ASAP. We present two separate examples demonstrating an RSerPool-
RSerPool-aware client and a client that is using a Proxy or Gateway aware client and an RSerPool-unaware client that is using a Proxy or
to perform the file transfer. In this example we will use a FTP Gateway to perform the file transfer. In these examples we will use
RFC959 [5] model with some modifications. The first example (the a FTP RFC959 [5] model with some modifications. In the first example
RSerPool aware one) will modify FTP concepts so that the file (client is RSerPool-aware) we will modify FTP concepts so that the
transfer takes place over SCTP. In the second example we will use file transfer takes place over SCTP. In the second example, we will
TCP between the unaware client and the Proxy. The Proxy itself will use TCP between the RSerPool-unaware client and the Proxy. The Proxy
use the modified FTP with RSerPool as illustrated in the first itself will use the modified FTP with RSerPool as illustrated in the
example. first example.
Please note that in the example we do NOT follow FTP RFC959 [5] Please note that in the example we do NOT follow FTP RFC959 [5]
precisely but use FTP-like concepts and attempt to adhere to the precisely but use FTP-like concepts and attempt to adhere to the
basic FTP model. These examples use FTP for illustrative purposes, basic FTP model. These examples use FTP for illustrative purposes.
FTP was chosen since many of the basic concept are well known and FTP was chosen since many of the basic concept are well known and
should be familiar to readers. should be familiar to readers.
3.1.1 The RSerPool Aware Client 3.1.1 The RSerPool Aware Client
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ operational scope ~ ~ operational scope ~
~ ......................... ~ ~ ......................... ~
~ . "file transfer pool" . ~ ~ . "file transfer pool" . ~
~ . +-------+ +-------+ . ~ ~ . +-------+ +-------+ . ~
skipping to change at page 14, line 51 skipping to change at page 15, line 39
~ +--------------+ ~ ~ +--------------+ ~
~ (a)-> ~ ~ (a)-> ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Architecture for RSerPool aware client. Architecture for RSerPool aware client.
Figure 6 Figure 6
To effect a file transfer the following steps would take place. To effect a file transfer the following steps would take place.
1. The application in PU(X) would send a login request. The PU(X)'s 1. The application in PU(X) sends a login request. The PU(X)'s ASAP
ASAP layer would send an ASAP request to its ENRP server to layer sends an ASAP request to an ENRP server to request the list
request the list of pool elements (using (a)). The pool handle of pool elements (using (a)). The pool handle to identify the
to identify the pool would be "File Transfer Pool". The ASAP pool is "File Transfer Pool". The ASAP layer queues the login
layer queues the login request. request.
2. The ENRP server would return a list of the three PEs PE(1,A), 2. The ENRP server returns a list of the three PEs PE(1,A), PE(1,B)
PE(1,B) and PE(1,C) to the ASAP layer in PU(X) (using (b)). and PE(1,C) to the ASAP layer in PU(X) (using (b)).
3. The ASAP layer selects one of the PEs, for example PE(1,B). It 3. The ASAP layer selects one of the PEs, for example PE(1,B). It
transmits the login request, the other FTP control data finally transmits the login request and the other FTP control data.
starts the transmission of the requested files (using (c)). For Finally, it starts the transmission of the requested files (using
this the multiple stream feature of SCTP could be used. (c)). Note that optionally, the multiple stream feature of SCTP
could be used.
4. If during the file transfer conversation, PE(1,B) fails, assuming 4. Suppose that during the file transfer transmission, PE(1,B)
the PE's were sharing state of file transfer, a fail-over to fails. If the PE's are sharing file transfer state, a fail-over
PE(1,A) could be initiated. PE(1,A) would continue the transfer to PE(1,A) could be initiated. PE(1,A) then continues the
until complete (see (d)). In parallel a request from PE(1,A) transfer until complete (see (d)). In parallel, a request from
would be made to the ENRP server to request a cache update for PE(1,A) is made to the ENRP server to request a cache update for
the server pool "File Transfer Pool" and a report would also be the server pool "File Transfer Pool". Furthermore, a report is
made that PE(1,B) is non-responsive (this would cause appropriate generated that PE(1,B) is non-responsive. This would trigger
audits that may remove PE(1,B) from the pool if the ENRP server appropriate audits that may remove PE(1,B) from the pool if the
had not already detected the failure) (using (a)). ENRP server had not already detected the failure) (using (a)).
3.1.2 The RSerPool Unaware Client 3.1.2 The RSerPool Unaware Client
In this example we investigate the use of a Proxy server assuming the In this example we investigate the use of a Proxy server assuming the
same set of scenario as illustrated above. same set of scenario as illustrated above.
In this example the steps will occur: In this example the steps will occur:
1. The FTP client and the Proxy/Gateway are using the TCP-based ftp 1. The FTP client and the Proxy/Gateway are using the TCP-based ftp
protocol. The client sends the login request to the proxy (using protocol. The client sends the login request to the proxy (using
skipping to change at page 15, line 48 skipping to change at page 16, line 36
2. The proxy behaves like a client and performs the actions 2. The proxy behaves like a client and performs the actions
described under (1), (2) and (3) of the above description (using described under (1), (2) and (3) of the above description (using
(a), (b) and (c)). (a), (b) and (c)).
3. The ftp communication continues and will be translated by the 3. The ftp communication continues and will be translated by the
proxy into the RSerPool aware dialect. This interworking uses proxy into the RSerPool aware dialect. This interworking uses
(f) and (c). (f) and (c).
Note that in this example high availability is maintained between the Note that in this example high availability is maintained between the
Proxy and the server pool but a single point of failure exists Proxy and the server pool but a single point of failure exists
between the FTP client and the Proxy, i.e. the command TCP between the FTP client and the Proxy, i.e. the command TCP connection
connection and its one IP address it is using for commands. and its one IP address it is using for commands.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ operational scope ~ ~ operational scope ~
~ ......................... ~ ~ ......................... ~
~ . "file transfer pool" . ~ ~ . "file transfer pool" . ~
~ . +-------+ +-------+ . ~ ~ . +-------+ +-------+ . ~
~ . |PE(1,A)| |PE(1,C)| . ~ ~ . |PE(1,A)| |PE(1,C)| . ~
~ . +-------+ +-------+ . ~ ~ . +-------+ +-------+ . ~
~ . ^ ^ . ~ ~ . ^ ^ . ~
~ . +----------+ | . ~ ~ . +----------+ | . ~
skipping to change at page 16, line 40 skipping to change at page 17, line 40
~ ::::::::::::::::: (e)-> ***************** ~ ~ ::::::::::::::::: (e)-> ***************** ~
~ : FTP client :<------------->* proxy/gateway * ~ ~ : FTP client :<------------->* proxy/gateway * ~
~ ::::::::::::::::: (f) ***************** ~ ~ ::::::::::::::::: (f) ***************** ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Architecture for RSerPool unaware client. Architecture for RSerPool unaware client.
Figure 7 Figure 7
3.2 Load Balancing Example 3.2 Load Balancing Example
This examples is similar to the one above describing an RSerPool This example is similar to the one above describing an RSerPool
unaware client. In both examples the clients do not need to support unaware client. In both examples the clients do not need to support
the RSerPool protocol suite. the RSerPool protocol suite.
There are several servers in a pool and the traffic from clients is There are several servers in a pool and the traffic from clients is
distributed among them by a load balancer. The load balancer can distributed among them by a load balancer. The load balancer can
make use of load information of the servers for optimal load make use of load information provided by the servers for optimal load
distribution. distribution.
One possibility of using RSerPool for this application is described One possibility of using RSerPool for this application is described
in the next figure. The servers become pool elements in one pool and in the next figure. The servers become pool elements in a pool and
register themselves at ENRP servers. They can also provide load register themselves with ENRP servers. They can also provide load
information. The load balancer acts as a pool user and gets the information. The load balancer acts as a pool user and gets the
addresses and possibly the load information via ASAP communication addresses and possibly the load information via ASAP communication
with ENRP servers. The communication between the clients and servers with ENRP servers. The communication between the clients and servers
is not affected. is not affected.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ operational scope ~ ~ operational scope ~
~ ......................... ~ ~ ......................... ~
~ . "server pool" . ~ ~ . "server pool" . ~
~ . +-------+ +-------+ . ~ ~ . +-------+ +-------+ . ~
skipping to change at page 18, line 44 skipping to change at page 19, line 44
| <-(a) | | <-(a) |
+-------------------+ +-------------------+
(b)-> (b)->
Deployment of Decomposed GWC and GK. Deployment of Decomposed GWC and GK.
Figure 9 Figure 9
As shown in the previous figure, the following sequence takes place: As shown in the previous figure, the following sequence takes place:
1. the Signaling Gateway (SG) receives an incoming signaling message 1. The Signaling Gateway (SG) receives an incoming signaling message
to be forwarded to the GWC. SG(X)'s ASAP layer would send an to be forwarded to the GWC. SG(X)'s ASAP layer sends an ASAP
ASAP request to its "local" ENRP server to request the list of request to its "local" ENRP server to request the list of pool
pool elements (PE's) of GWC (using (a)). The key used for this elements (PE's) of GWC (using (a)). The handle used for this
query is the pool handle of the GWC. The ASAP layer queues the query is the pool handle of the GWC. The ASAP layer queues the
data to be sent to the GWC in local buffers until the ENRP server data to be sent to the GWC in local buffers until the ENRP server
responds. responds.
2. the ENRP server would return a list of the three PE's A, B and C 2. The ENRP server returns a list of the three PE's A, B and C to
to the ASAP layer in SG(X) together with information to be used the ASAP layer in SG(X) together with information to be used for
for load-sharing traffic across the gateway controller pool load-sharing traffic across the gateway controller pool (using
(using (b)). (b)).
3. the ASAP layer in SG(X) will select one PE (e.g., PE(2,C)) and 3. The ASAP layer in SG(X) will select one PE (e.g., PE(2,C)) and
send the signaling message to it (using (c)). The selection is send the signaling message to it (using (c)). The selection is
based on the load sharing information of the gateway controller based on the load sharing information of the gateway controller
pool. pool.
4. to progress the call, PE(2,C) finds that it needs to talk to the 4. To progress the call, PE(2,C) finds that it needs to talk to the
Gatekeeper. Assuming it has already had gatekeeper pool's Gatekeeper. Assuming it has the gatekeeper pool's information in
information in its local cache (e.g., obtained and stored from its local cache (e.g., obtained and stored from a recent query to
recent query to ENRP server), PE(2,C) selects PE(1,B) and sends ENRP server), PE(2,C) selects PE(1,B) and sends the call control
the call control message to it (using (d)). message (using (d)).
5. We assume PE(1,B) responds back to PE(2,C) and authorizes the 5. We assume PE(1,B) responds to PE(2,C) and authorizes the call to
call to proceed. proceed.
6. PE(2,C) issues media control commands to the Media Gateway (using 6. PE(2,C) issues media control commands to the Media Gateway (using
(e)). (e)).
RSerPool will provide service robustness to the system if some RSerPool will provide service robustness to the system if some
failure would occur in the system. failure occurs in the system.
For instance, if PE(1, B) in the Gatekeeper Pool crashed after For example, if PE(1, B) in the Gatekeeper Pool crashed after
receiving the call control message from PE(2, C) in step (d) above, receiving the call control message from PE(2, C) in step (d) above.
what most likely will happen is that, due to the absence of a reply What most likely will happen is that, due to the absence of a reply
from the Gatekeeper, a timer expiration event will trigger the call from the Gatekeeper, a timer expiration event will trigger the call
state machine within PE(2, C) to resend the control message. The state machine within PE(2, C) to resend the control message. The
ASAP layer at PE(2, C) will then notice the failure of PE(1, B) ASAP layer at PE(2, C) will then notice the failure of PE(1, B)
through (likely) the endpoint unreachability detection by the through the endpoint unreachability detection by the transport
transport protocol beneath ASAP and automatically deliver the re-sent protocol beneath ASAP and automatically deliver the re-sent call
call control message to the alternate GK pool member PE(1, A). With control message to the alternate GK pool member PE(1, A). With
appropriate intra-pool call state sharing support, PE(1, A) will be appropriate intra-pool call state sharing support, PE(1, A) will
able to correctly handle the call and reply to PE(2, C) and hence correctly handle the call and reply to PE(2, C) and hence progress
progress the call. the call.
3.3.2 Collocated GWC and GK Scenario 3.3.2 Collocated GWC and GK Scenario
In this scenario, the GWC and GK services are collocated (e.g., they In this scenario, the GWC and GK services are collocated (e.g., they
are implemented as a single process). In such a case, one can form a are implemented as a single process). In this case, one can form a
pool that provides both GWC and GK services as shown in the figure pool that provides both GWC and GK services as shown in the figure
below. below.
The same sequence as described in 5.2.1 takes place, except that step The same sequence as described in 5.2.1 takes place, except that step
(4) now becomes internal to the PE(3,C) (again, we assume server C is (4) now becomes internal to the PE(3,C). Again, we assume server C
selected by SG). is selected by SG.
........................................ ........................................
. gateway controller/gatekeeper pool . . gateway controller/gatekeeper pool .
. +-------+ . . +-------+ .
. |PE(3,A)| . . |PE(3,A)| .
. +-------+ . . +-------+ .
. +-------+ . . +-------+ .
. |PE(3,C)|<---------------------------+ . |PE(3,C)|<---------------------------+
. +-------+ . | . +-------+ . |
. +-------+ ^ . | . +-------+ ^ . |
skipping to change at page 20, line 43 skipping to change at page 21, line 43
Figure 10 Figure 10
4. Security Considerations 4. Security Considerations
The RSerPool protocol must allow us to secure the RSerPool The RSerPool protocol must allow us to secure the RSerPool
infrastructure. There are security and privacy issues that relate to infrastructure. There are security and privacy issues that relate to
the handle space, pool element registration and user queries of the the handle space, pool element registration and user queries of the
handle space. In [2] a complete threat analysis of RSerPool handle space. In [2] a complete threat analysis of RSerPool
components is presented. components is presented.
5. Acknowledgements 5. IANA Considerations
There are no actions needed.
6. Acknowledgements
The authors would like to thank Bernard Aboba, Phillip Conrad, Harrie The authors would like to thank Bernard Aboba, Phillip Conrad, Harrie
Hazewinkel, Matt Holdrege, Lyndon Ong, Christopher Ross, Maureen Hazewinkel, Matt Holdrege, Lyndon Ong, Christopher Ross, Maureen
Stillman, Werner Vogels and many others for their invaluable comments Stillman, Werner Vogels and many others for their invaluable comments
and suggestions. and suggestions.
6. References 7. References
6.1 Normative References 7.1 Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", [1] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996. BCP 9, RFC 2026, October 1996.
[2] Stillman, M., "Threats Introduced by Rserpool and Requirements [2] Stillman, M., "Threats Introduced by Rserpool and Requirements
for Security in response to Threats", for Security in response to Threats",
Internet-Draft draft-ietf-rserpool-threats-04, January 2005. draft-ietf-rserpool-threats-04 (work in progress), January 2005.
[3] Loughney, J., "Comparison of Protocols for Reliable Server [3] Loughney, J., "Comparison of Protocols for Reliable Server
Pooling", Internet-Draft draft-ietf-rserpool-comp-08, July 2004. Pooling", draft-ietf-rserpool-comp-09 (work in progress),
February 2005.
6.2 Informative References 7.2 Informative References
[4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, [4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981. September 1981.
[5] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, [5] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9,
RFC 959, October 1985. RFC 959, October 1985.
[6] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service [6] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service
Location Protocol, Version 2", RFC 2608, June 1999. Location Protocol, Version 2", RFC 2608, June 1999.
[7] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L., [7] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L.,
Lin, H., Juhasz, I., Holdrege, M. and C. Sharp, "Framework Lin, H., Juhasz, I., Holdrege, M., and C. Sharp, "Framework
Architecture for Signaling Transport", RFC 2719, October 1999. Architecture for Signaling Transport", RFC 2719, October 1999.
[8] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, [8] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000. "Stream Control Transmission Protocol", RFC 2960, October 2000.
[9] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, [9] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney,
J. and M. Stillman, "Requirements for Reliable Server Pooling", J., and M. Stillman, "Requirements for Reliable Server Pooling",
RFC 3237, January 2002. RFC 3237, January 2002.
Authors' Addresses Authors' Addresses
Michael Tuexen (editor) Michael Tuexen (editor)
Muenster Univ. of Applied Sciences Muenster Univ. of Applied Sciences
Stegerwaldstr. 39 Stegerwaldstr. 39
48565 Steinfurt 48565 Steinfurt
Germany Germany
 End of changes. 

This html diff was produced by rfcdiff 1.24, available from http://www.levkowetz.com/ietf/tools/rfcdiff/