draft-ietf-rserpool-arch-07.txt   draft-ietf-rserpool-arch-08.txt 
Network Working Group M. Tuexen, Ed. Network Working Group M. Tuexen, Ed.
Internet-Draft Univ. of Applied Sciences Muenster Internet-Draft Muenster Univ. of Applied Sciences
Expires: April 11, 2004 Q. Xie Expires: April 24, 2005 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
October 12, 2003 October 24, 2004
Architecture for Reliable Server Pooling Architecture for Reliable Server Pooling
draft-ietf-rserpool-arch-07.txt draft-ietf-rserpool-arch-08.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is subject to all provisions
all provisions of Section 10 of RFC2026. of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she 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 other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
Internet-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 http:// The list of current Internet-Drafts can be accessed at
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 April 11, 2004. This Internet-Draft will expire on April 24, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004).
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 . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
2. Reliable Server Pooling Architecture . . . . . . . . . . . . 4 2. Reliable Server Pooling Architecture . . . . . . . . . . . . . 4
2.1 RSerPool Functional Components . . . . . . . . . . . . . . . 4 2.1 RSerPool Functional Components . . . . . . . . . . . . . . 4
2.2 RSerPool Protocol Overview . . . . . . . . . . . . . . . . . 5 2.2 RSerPool Protocol Overview . . . . . . . . . . . . . . . . 5
2.2.1 Endpoint Name Resolution Protocol . . . . . . . . . . . . . 5 2.2.1 Endpoint Name Resolution Protocol . . . . . . . . . . 5
2.2.2 Aggregate Server Access Protocol . . . . . . . . . . . . . . 6 2.2.2 Aggregate Server Access Protocol . . . . . . . . . . . 5
2.2.3 PU <-> NS Communication . . . . . . . . . . . . . . . . . . 6 2.2.3 PU <-> NS Communication . . . . . . . . . . . . . . . 6
2.2.4 PE <-> NS Communication . . . . . . . . . . . . . . . . . . 7 2.2.4 PE <-> NS Communication . . . . . . . . . . . . . . . 7
2.2.5 PU <-> PE Communication . . . . . . . . . . . . . . . . . . 7 2.2.5 PU <-> PE Communication . . . . . . . . . . . . . . . 7
2.2.6 NS <-> NS Communication . . . . . . . . . . . . . . . . . . 8 2.2.6 NS <-> NS Communication . . . . . . . . . . . . . . . 8
2.2.7 PE <-> PE Communication . . . . . . . . . . . . . . . . . . 9 2.2.7 PE <-> PE Communication . . . . . . . . . . . . . . . 9
2.3 Failover Support . . . . . . . . . . . . . . . . . . . . . . 9 2.3 Failover Support . . . . . . . . . . . . . . . . . . . . . 9
2.3.1 Business Cards . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.1 Business Cards . . . . . . . . . . . . . . . . . . . . 9
2.3.2 Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3.2 Cookies . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 Typical Interactions between RSerPool Components . . . . . . 11 2.4 Typical Interactions between RSerPool Components . . . . . 11
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1 Two File Transfer Examples . . . . . . . . . . . . . . . . . 12 3.1 Two File Transfer Examples . . . . . . . . . . . . . . . . 12
3.1.1 The RSerPool Aware Client . . . . . . . . . . . . . . . . . 13 3.1.1 The RSerPool Aware Client . . . . . . . . . . . . . . 13
3.1.2 The RSerPool Unaware Client . . . . . . . . . . . . . . . . 14 3.1.2 The RSerPool Unaware Client . . . . . . . . . . . . . 14
3.2 Telephony Signaling Example . . . . . . . . . . . . . . . . 15 3.2 Telephony Signaling Example . . . . . . . . . . . . . . . 15
3.2.1 Decomposed GWC and GK Scenario . . . . . . . . . . . . . . . 15 3.2.1 Decomposed GWC and GK Scenario . . . . . . . . . . . . 15
3.2.2 Collocated GWC and GK Scenario . . . . . . . . . . . . . . . 17 3.2.2 Collocated GWC and GK Scenario . . . . . . . . . . . . 17
4. Security Considerations . . . . . . . . . . . . . . . . . . 18 4. Security Considerations . . . . . . . . . . . . . . . . . . . 18
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
Normative References . . . . . . . . . . . . . . . . . . . . 18 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Informative References . . . . . . . . . . . . . . . . . . . 19 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19 6.2 Informative References . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . 21
1. Introduction 1. Introduction
1.1 Overview 1.1 Overview
This document defines an architecture, for providing a highly This document defines an architecture, for providing a highly
available reliable server function in support of a service or set of available reliable server function in support of a service or set of
services. This is achieved is by forming a pool of servers, each of services. This is achieved by forming a pool of servers, each of
which is capable of supporting the desired service(s), and providing which is capable of supporting the desired service(s), and providing
a name service that will resolve requests from a service user to the a name service that will resolve requests from a service user to the
identity of a working server in the pool. identity of a working server in the pool.
To access a server pool, the pool user consults a name server. The To access a server pool, the pool user consults a name server. The
name service itself can be provided by a pool of name servers using a name service itself can be provided by a pool of name servers using a
shared protocol to make the name resolution function fault-tolerant. shared protocol to make the name resolution function fault-tolerant.
It is assumed that the name space is kept flat and designed for a It is assumed that the name space is kept flat and designed for a
limited scale in order to keep the protocols simple, robust and fast. limited scale in order to keep the protocols simple, robust and fast.
skipping to change at page 5, line 15 skipping to change at page 4, line 43
These names are not valid in the whole internet but only in smaller These names are not valid in the whole internet but only in smaller
domains, called the operational scope. Furthermore, the namespace is domains, called the operational scope. Furthermore, the namespace is
assumed to be flat, so that multiple levels of query are not assumed to be flat, so that multiple levels of query are not
necessary to resolve a name request. necessary to resolve a name request.
The second class of entities in the RSerPool architecture is the The second class of entities in the RSerPool architecture is the
class of name servers (NSs). These name servers can resolve a pool class of name servers (NSs). These name servers can resolve a pool
handle to a list of information which allows the PU to access a PE of handle to a list of information which allows the PU to access a PE of
the server pool identified by the handle. This information includes: the server pool identified by the handle. This information includes:
o A list of IPv4 and/or IPv6 addresses. o A list of IPv4 and/or IPv6 addresses.
o A protocol field specifying the transport layer protocol. o A protocol field specifying the transport layer protocol.
o A port number associated with the transport protocol, e.g. SCTP, o A port number associated with the transport protocol, e.g. SCTP,
TCP or UDP. TCP or UDP.
Note that the RSerPool architecture supports both IPv4 and IPv6 Note that the RSerPool architecture supports both IPv4 and IPv6
addressing. addressing.
In each operational scope there must be at least one name server. All In each operational scope there must be at least one name server.
name servers within the operational scope have knowledge of all
All name servers within the operational scope have knowledge of all
server pools within the operational scope. server pools within the operational scope.
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
The RSerPool requested features can be obtained with the help of the Based on the requirements in RFC3237 [9], two new protocols: ENRP
combination of two protocols: ENRP (Endpoint Name Resolution (Endpoint Name Resolution Protocol) and ASAP (Aggregate Server Access
Protocol) and ASAP (Aggregate Server Access Protocol). Protocol). These are used because no existing protocols are suitable
(see [3]).
2.2.1 Endpoint Name Resolution Protocol 2.2.1 Endpoint Name Resolution Protocol
The name servers use a protocol called Endpoint Name Resolution The name servers use a protocol called Endpoint Name Resolution
Protocol (ENRP) for communication with each other to exchange Protocol (ENRP) for communication with each other to exchange
information and updates about the server pools. information and updates about the server pools.
ENRP is designed to provide a fully distributed fault-tolerant ENRP is designed to provide a fully distributed fault-tolerant
real-time translation service that maps a name to a set of transport real-time translation service that maps a name to a set of transport
addresses pointing to a specific group of networked communication addresses pointing to a specific group of networked communication
endpoints registered under that name. ENRP employs a client-server endpoints registered under that name.
model in which a name server will respond to the name translation
service requests from endpoint clients.
RFC3237 [8] also requires that the name servers should not resolve a RFC3237 [9] also requires that the name servers should not resolve a
pool handle to a transport layer address of a PE which is not in pool handle to a transport layer address of a PE which is not in
operation. Therefore each PE is supervised by one specific name operation. Therefore each PE is supervised by one specific name
server, called the home NS of that PE. If it detects that the PE is server, called the home NS of that PE by using ASAP. If it detects
out of service all other name servers are informed by using ENRP. that the PE is out of service all other name servers are informed by
using ENRP.
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
level of support desired by the application, use of ASAP may be level of support desired by the application, use of ASAP may be
limited to an initial query for an active PE, or ASAP may be used to limited to an initial query for an active PE, or ASAP may be used to
mediate all communication between the PU and PE, so that automatic mediate all communication between the PU and PE, so that automatic
failover from a failed PE to an alternate PE can be supported. failover from a failed PE to an alternate PE can be supported.
skipping to change at page 6, line 37 skipping to change at page 6, line 14
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. It
registers or deregisters itself by communicating with a name server, registers or deregisters itself by communicating with a name server,
which will normally the home NS. ASAP allows dynamic system which will normally the home NS. ASAP allows dynamic system
scalability, allowing the pool membership to change at any time. scalability, allowing the pool membership to change at any time.
2.2.3 PU <-> NS Communication 2.2.3 PU <-> NS Communication
The PU <-> NS communication is used for performing name queries. The The PU <-> NS communication is used for performing name queries and
PU sends a pool handle to the NS and gets back the information uses ASAP. The PU sends a pool handle to the NS and gets back the
necessary for accessing a server in a server pool. information necessary for accessing a server in a 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 an SCTP capable PU is given in
Figure 1. Figure 1.
******** ******** ******** ********
* PU * * NS * * PU * * NS *
******** ******** ******** ********
+------+ +------+ +------+ +------+
skipping to change at page 9, line 30 skipping to change at page 9, line 30
When a name initializes a UDP multicast message may be transmitted When a name initializes a UDP multicast message may be transmitted
for initial detection of other name servers in the operational scope. for initial detection of other name servers in the operational scope.
The other name servers send a response using a unicast UDP message. The other name servers send a response using a unicast UDP message.
2.2.7 PE <-> PE Communication 2.2.7 PE <-> PE Communication
This is a special case of the PU <-> PE communication. In this case This is a special case of the PU <-> PE communication. In this case
the PU is also a PE in a server pool. the PU is also a PE in a server pool.
There is one additional point here: The PE acting as a PU can send There is one additional point here: The PE acting as a PU can send
the PE the information that it is actually a PE of a pool. This means the PE the information that it is actually a PE of a pool. This
that the pool handle is transferred via the control channel. See means that the pool handle is transferred via the control channel.
Section 2.3 for further details. See Section 2.3 for further details.
2.3 Failover Support 2.3 Failover Support
If the PU detects the failure of a PE it may fail over to a different If the PU detects the failure of a PE it may fail over to a different
PE. The selection to a new PE should be made such that most likely PE. The selection to a new PE should be made such that most likely
the new PE is not affected by the failed one. the new PE is not affected by the failed one.
There are some mechanisms provided by RSerPool to support the There are some mechanisms provided by RSerPool to support the
failover to a new PE. failover to a new PE.
skipping to change at page 10, line 39 skipping to change at page 10, line 39
. | | . . | | .
. | PE 3 | . . | PE 3 | .
. | | . . | | .
. +-------+ . . +-------+ .
....................... .......................
Two PUs accessing the same PE Two PUs accessing the same PE
Figure 4 Figure 4
PU 1 is using PE 2 of the server pool. Assume that PE 1 and PE 2 PU 1 is using PE 2 of the server pool. Assume that PE 1 and PE 2
share state but not PE 2 and PE 3. Using the business card of PE 2 it share state but not PE 2 and PE 3. Using the business card of PE 2
is possible for PE 2 to inform PU 1 that it should fail over to PE 1 it is possible for PE 2 to inform PU 1 that it should fail over to PE
in case of a failure. 1 in case of a failure.
A slightly more complicated situation is if two pool users, PU 1 and A slightly more complicated situation is if two pool users, PU 1 and
PU 2, use PE 2 but both, PU 1 and PU 2, need to use the same PE. Then PU 2, use PE 2 but both, PU 1 and PU 2, need to use the same PE.
it is important that PU 1 and PU 2 fail over to the same PE. This can Then it is important that PU 1 and PU 2 fail over to the same PE.
be handled in a way such that PE 2 gives the same business card to PU This can be handled in a way such that PE 2 gives the same business
1 and PU 2. card to PU 1 and PU 2.
2.3.2 Cookies 2.3.2 Cookies
Cookies may optionally be sent from the PE to the PU. The PU only Cookies may optionally be sent from the PE to the PU. The PU only
stores the last received cookie. In case of fail over the PU sends stores the last received cookie. In case of fail over the PU sends
this last received cookie to the new PE. This method provides a this last received cookie to the new PE. This method provides a
simple way of state sharing between the PEs. Please note that the old simple way of state sharing between the PEs. Please note that the
PE should sign the cookie and the receiving PE should verify the old PE should sign the cookie and the receiving PE should verify the
signature. For the PU, the cookie has no structure and is only stored signature. For the PU, the cookie has no structure and is only
and transmitted to the new PE. stored and transmitted to the new PE.
2.4 Typical Interactions between RSerPool Components 2.4 Typical Interactions between RSerPool Components
The following drawing shows the typical RSerPool components and their The following drawing shows the typical RSerPool components and their
possible interactions with each other: possible interactions with each other:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ operation scope ~ ~ operation scope ~
~ ......................... ......................... ~ ~ ......................... ......................... ~
~ . Server Pool 1 . . Server Pool 2 . ~ ~ . Server Pool 1 . . Server Pool 2 . ~
skipping to change at page 12, line 9 skipping to change at page 12, line 9
RSerPool components and their possible interactions. RSerPool components and their possible interactions.
Figure 5 Figure 5
In this figure we can identify the following possible interactions: In this figure we can identify the following possible interactions:
(a) Server Pool Elements <-> NS: (ASAP) Each PE in a pool uses ASAP (a) Server Pool Elements <-> NS: (ASAP) Each PE in a pool uses ASAP
to register or de-register itself as well as to exchange other to register or de-register itself as well as to exchange other
auxiliary information with the NS. The NS also uses ASAP to auxiliary information with the NS. The NS also uses ASAP to
monitor the operational status of each PE in a pool. monitor the operational status of each PE in a pool.
(b) PU <-> NS: (ASAP) A PU normally uses ASAP to request the NS for a (b) PU <-> NS: (ASAP) A PU normally uses ASAP to request the NS for a
name-to-address translation service before the PU can send user name-to-address translation service before the PU can send user
messages addressed to a server pool by the pool's name. messages addressed to a server pool by the pool's name.
(c) PU <-> PE: (ASAP) ASAP can be used to exchange some auxiliary (c) PU <-> PE: (ASAP) ASAP can be used to exchange some auxiliary
information of the two parties before they engage in user data information of the two parties before they engage in user data
transfer. transfer.
(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) NS <-> NS: (ENRP) ENRP can be used to fulfill various Name Space (e) NS <-> NS: (ENRP) ENRP can be used to fulfill various Name Space
operation, administration, and maintenance (OAM) functions. operation, administration, and maintenance (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 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 separate file transfer examples using
ENRP and ASAP. We present two separate examples demonstrating an ENRP and ASAP. We present two separate examples demonstrating an
ENRP/ASAP aware client and a client that is using a Proxy or Gateway ENRP/ASAP aware client and a client that is using a Proxy or Gateway
to perform the file transfer. In this example we will use a FTP to perform the file transfer. In this example we will use a FTP
RFC959 [4] model with some modifications. The first example (the RFC959 [5] model with some modifications. The first example (the
RSerPool aware one) will modify FTP concepts so that the file RSerPool aware one) will modify FTP concepts so that the file
transfer takes place over SCTP. In the second example we will use TCP transfer takes place over SCTP. In the second example we will use
between the unaware client and the Proxy. The Proxy itself will use TCP between the unaware client and the Proxy. The Proxy itself will
the modified FTP with RSerPool as illustrated in the first example. use the modified FTP with RSerPool as illustrated in the first
example.
Please note that in the example we do NOT follow FTP RFC959 [4] 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ operation scope ~ ~ operation scope ~
~ ......................... ~ ~ ......................... ~
skipping to change at page 13, line 42 skipping to change at page 13, line 38
~ | <-(b) | ~ ~ | <-(b) | ~
~ +--------------+ ~ ~ +--------------+ ~
~ (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) would send a login request. The PU(X)'s
ASAP layer would send an ASAP request to its NS to request the ASAP layer would send an ASAP request to its NS to request the
list of pool elements (using (a)). The pool handle to identify list of pool elements (using (a)). The pool handle to identify
the pool would be "File Transfer Pool". The ASAP layer queues the the pool would be "File Transfer Pool". The ASAP layer queues
login request. the login request.
2. The NS would return a list of the three PEs PE(1,A), PE(1,B) and 2. The NS would return a list of the three PEs PE(1,A), PE(1,B) and
PE(1,C) to the ASAP layer in PU(X) (using (b)). 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, the other FTP control data finally
starts the transmission of the requested files (using (c)). For starts the transmission of the requested files (using (c)). For
this the multiple stream feature of SCTP could be used. this the multiple stream feature of SCTP could be used.
4. If during the file transfer conversation, PE(1,B) fails, assuming 4. If during the file transfer conversation, PE(1,B) fails, assuming
the PE's were sharing state of file transfer, a fail-over to the PE's were sharing state of file transfer, a fail-over to
PE(1,A) could be initiated. PE(1,A) would continue the transfer PE(1,A) could be initiated. PE(1,A) would continue the transfer
until complete (see (d)). In parallel a request from PE(1,A) until complete (see (d)). In parallel a request from PE(1,A)
would be made to ENRP to request a cache update for the server would be made to the NS to request a cache update for the server
pool "File Transfer Pool" and a report would also be made that pool "File Transfer Pool" and a report would also be made that
PE(1,B) is non-responsive (this would cause appropriate audits PE(1,B) is non-responsive (this would cause appropriate audits
that may remove PE(1,B) from the pool if the NS had not already that may remove PE(1,B) from the pool if the NS had not already
detected the failure) (using (a)). 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.
skipping to change at page 14, line 26 skipping to change at page 14, line 16
PE(1,B) is non-responsive (this would cause appropriate audits PE(1,B) is non-responsive (this would cause appropriate audits
that may remove PE(1,B) from the pool if the NS had not already that may remove PE(1,B) from the pool if the NS had not already
detected the failure) (using (a)). 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
(e)). (e)).
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 (f) proxy into the RSerPool aware dialect. This interworking uses
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 connection between the FTP client and the Proxy, i.e. the command TCP
and its one IP address it is using for commands. connection and its one IP address it is using for commands.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ operation scope ~ ~ operation 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 39 skipping to change at page 16, line 39
| | | |
| <-(a) | | <-(a) |
+-------------------+ +-------------------+
(b)-> (b)->
Deployment of Decomposed GWC and GK. Deployment of Decomposed GWC and GK.
Figure 8 Figure 8
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 ASAP to be forwarded to the GWC. SG(X)'s ASAP layer would send an
request to its "local" NS to request the list of pool elements ASAP request to its "local" NS to request the list of pool
(PE's) of GWC (using (a)). The key used for this query is the elements (PE's) of GWC (using (a)). The key used for this query
pool handle of the GWC. The ASAP layer queues the data to be sent is the pool handle of the GWC. The ASAP layer queues the data to
to the GWC in local buffers until the NS responds. be sent to the GWC in local buffers until the NS responds.
2. the NS would return a list of the three PE's A, B and C to the 2. the NS would return a list of the three PE's A, B and C to the
ASAP layer in SG(X) together with information to be used for ASAP layer in SG(X) together with information to be used for
load-sharing traffic across the gateway controller pool (using load-sharing traffic across the gateway controller pool (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 already had gatekeeper pool's
information in its local cache (e.g., obtained and stored from information in its local cache (e.g., obtained and stored from
recent query to NS), PE(2,C) selects PE(1,B) and sends the call recent query to NS), PE(2,C) selects PE(1,B) and sends the call
control message to it (using (d)). control message to it (using (d)).
skipping to change at page 17, line 27 skipping to change at page 17, line 22
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 would occur in the system.
For instance, if PE(1, B) in the Gatekeeper Pool crashed after For instance, 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 ASAP state machine within PE(2, C) to resend the control message. The
layer at PE(2, C) will then notice the failure of PE(1, B) through ASAP layer at PE(2, C) will then notice the failure of PE(1, B)
(likely) the endpoint unreachability detection by the transport through (likely) the endpoint unreachability detection by the
protocol beneath ASAP and automatically deliver the re-sent call transport protocol beneath ASAP and automatically deliver the re-sent
control message to the alternate GK pool member PE(1, A). With call 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 be
able to correctly handle the call and reply to PE(2, C) and hence able to correctly handle the call and reply to PE(2, C) and hence
progress the call. progress the call.
3.2.2 Collocated GWC and GK Scenario 3.2.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 such a 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.
skipping to change at page 18, line 46 skipping to change at page 18, line 46
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 namespace, pool element registration and user queries of the the namespace, pool element registration and user queries of the
namespace. In [2] a complete threat analysis of RSerPool components namespace. In [2] a complete threat analysis of RSerPool components
is presented. is presented.
5. Acknowledgements 5. 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, Christopher Ross, Werner Vogels and many Hazewinkel, Matt Holdrege, Lyndon Ong, Christopher Ross, Maureen
others for their invaluable comments and suggestions. Stillman, Werner Vogels and many others for their invaluable comments
and suggestions.
Normative References 6. References
6.1 Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996. 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",
draft-ietf-rserpool-threats-02 (work in progress), October 2003. draft-ietf-rserpool-threats-03 (work in progress), July 2004.
Informative References [3] Loughney, J., "Comparison of Protocols for Reliable Server
Pooling", draft-ietf-rserpool-comp-08 (work in progress), July
2004.
[3] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 6.2 Informative References
[4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981. September 1981.
[4] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC [5] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC
959, October 1985. 959, October 1985.
[5] 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.
[6] 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.
[7] 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.
[8] 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)
Univ. of Applied Sciences Muenster 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
Qiaobing Xie Qiaobing Xie
Motorola, Inc. Motorola, Inc.
1501 W. Shure Drive, #2309 1501 W. Shure Drive, #2309
Arlington Heights, IL 60004 Arlington Heights, IL 60004
USA USA
skipping to change at page 21, line 8 skipping to change at page 21, line 8
Nokia Research Center Nokia Research Center
PO Box 407 PO Box 407
FIN-00045 Nokia Group FIN-00045 FIN-00045 Nokia Group FIN-00045
Finland Finland
EMail: john.loughney@nokia.com EMail: john.loughney@nokia.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Disclaimer of Validity
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Copyright Statement
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an Copyright (C) The Internet Society (2004). This document is subject
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING to the rights, licenses and restrictions contained in BCP 78, and
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING except as set forth therein, the authors retain all their rights.
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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