draft-ietf-rserpool-arch-08.txt   draft-ietf-rserpool-arch-09.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: April 24, 2005 Q. Xie Expires: August 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 24, 2004 A. Silverton
Motorola Labs
February 20, 2005
Architecture for Reliable Server Pooling Architecture for Reliable Server Pooling
draft-ietf-rserpool-arch-08.txt draft-ietf-rserpool-arch-09.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. 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-Drafts. Internet-Drafts.
skipping to change at page 1, line 42 skipping to change at page 1, line 44
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 April 24, 2005. This Internet-Draft will expire on August 24, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). 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 . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
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.1.1 Pool Elements . . . . . . . . . . . . . . . . . . . . 4
2.1.2 ENRP Servers . . . . . . . . . . . . . . . . . . . . . 5
2.1.3 Pool Users . . . . . . . . . . . . . . . . . . . . . . 5
2.2 RSerPool Protocol Overview . . . . . . . . . . . . . . . . 5 2.2 RSerPool Protocol Overview . . . . . . . . . . . . . . . . 5
2.2.1 Endpoint Name Resolution Protocol . . . . . . . . . . 5 2.2.1 Endpoint Handlespace Redundancy Protocol . . . . . . . 6
2.2.2 Aggregate Server Access Protocol . . . . . . . . . . . 5 2.2.2 Aggregate Server Access Protocol . . . . . . . . . . . 6
2.2.3 PU <-> NS Communication . . . . . . . . . . . . . . . 6 2.2.3 PU <-> ENRP Server Communication . . . . . . . . . . . 7
2.2.4 PE <-> NS Communication . . . . . . . . . . . . . . . 7 2.2.4 PE <-> ENRP Server Communication . . . . . . . . . . . 8
2.2.5 PU <-> PE Communication . . . . . . . . . . . . . . . 7 2.2.5 PU <-> PE Communication . . . . . . . . . . . . . . . 8
2.2.6 NS <-> NS Communication . . . . . . . . . . . . . . . 8 2.2.6 ENRP Server <-> ENRP Server Communication . . . . . . 9
2.2.7 PE <-> PE Communication . . . . . . . . . . . . . . . 9 2.2.7 PE <-> PE Communication . . . . . . . . . . . . . . . 10
2.3 Failover Support . . . . . . . . . . . . . . . . . . . . . 9 2.3 Failover Support . . . . . . . . . . . . . . . . . . . . . 10
2.3.1 Business Cards . . . . . . . . . . . . . . . . . . . . 9 2.3.1 Business Cards . . . . . . . . . . . . . . . . . . . . 10
2.3.2 Cookies . . . . . . . . . . . . . . . . . . . . . . . 10 2.3.2 Cookies . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 Typical Interactions between RSerPool Components . . . . . 11 2.4 Typical Interactions between RSerPool Components . . . . . 12
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1 Two File Transfer Examples . . . . . . . . . . . . . . . . 12 3.1 Two File Transfer Examples . . . . . . . . . . . . . . . . 13
3.1.1 The RSerPool Aware Client . . . . . . . . . . . . . . 13 3.1.1 The RSerPool Aware Client . . . . . . . . . . . . . . 14
3.1.2 The RSerPool Unaware Client . . . . . . . . . . . . . 14 3.1.2 The RSerPool Unaware Client . . . . . . . . . . . . . 15
3.2 Telephony Signaling Example . . . . . . . . . . . . . . . 15 3.2 Load Balancing Example . . . . . . . . . . . . . . . . . . 16
3.2.1 Decomposed GWC and GK Scenario . . . . . . . . . . . . 15 3.3 Telephony Signaling Example . . . . . . . . . . . . . . . 17
3.2.2 Collocated GWC and GK Scenario . . . . . . . . . . . . 17 3.3.1 Decomposed GWC and GK Scenario . . . . . . . . . . . . 18
4. Security Considerations . . . . . . . . . . . . . . . . . . . 18 3.3.2 Collocated GWC and GK Scenario . . . . . . . . . . . . 19
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 4. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
6.1 Normative References . . . . . . . . . . . . . . . . . . . . 19 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.2 Informative References . . . . . . . . . . . . . . . . . . . 19 6.1 Normative References . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 6.2 Informative References . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . 24
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 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 an ENRP 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 ENRP 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 handle 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.
The server pool itself is supported by a shared protocol between The server pool itself is supported by a shared protocol between
servers and the name service allowing servers to enter and exit the servers and the name service allowing servers to enter and exit the
pool. Several server selection mechanisms, called server pool pool. Several server selection mechanisms, called server pool
policies, are supported for flexibility. policies, are supported for flexibility.
1.2 Terminology 1.2 Terminology
This document uses the following terms: This document uses the following terms:
Home Name Server: The Name Server a Pool Element has registered with.
This Name Server supervises the Pool Element. Home ENRP Server: The ENRP server a Pool Element has registered with.
Operation scope: The part of the network visible to pool users by a This ENRP server supervises the Pool Element.
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.
Pool (or server pool): A collection of servers providing the same Pool (or server pool): A collection of servers providing the same
application functionality. application functionality.
Pool handle (or pool name): A logical pointer to a pool. Each server
pool will be identifiable in the operation scope of the system by Pool handle: A logical pointer to a pool. Each server pool will be
a unique pool handle or "name". identifiable in the operational scope of the system by a unique
pool handle.
Pool element: A server entity having registered to a pool. Pool element: A server entity having registered to a pool.
Pool user: A server pool user. Pool user: A server pool user.
Pool element handle (or endpoint handle): A logical pointer to a Pool element handle (or endpoint handle): A logical pointer to a
particular pool element in a pool, consisting of the name of the particular pool element in a pool, consisting of the pool handle
pool and a destination transport address of the pool element. and a destination transport address of the pool element.
Name space: A cohesive structure of pool names and relations that may
be queried by an internal or external agent. Handle space: A cohesive structure of pool handles and relations that
Name server: Entity which is responsible for managing and maintaining may be queried by an internal or external agent.
the name space within the RSerPool operation scope.
ENRP server: Entity which is responsible for managing and maintaining
the handle space within the RSerPool operational scope.
1.3 Abbreviations 1.3 Abbreviations
ASAP: Aggregate Server Access Protocol ASAP: Aggregate Server Access Protocol
ENRP: Endpoint Name Resolution Protocol
Home NS: Home Name Server ENRP: Endpoint haNdlespace Redundancy Protocol
NS: Name Server
PE: Pool element PE: Pool element
PU: Pool user PU: Pool user
SCTP: Stream Control Transmission Protocol SCTP: Stream Control Transmission Protocol
TCP: Transmission Control Protocol TCP: Transmission Control Protocol
2. Reliable Server Pooling Architecture 2. Reliable Server Pooling Architecture
In this section, we define a reliable server pool architecture. In this section, we define a reliable server pool architecture.
2.1 RSerPool Functional Components 2.1 RSerPool Functional Components
There are three classes of entities in the RSerPool architecture: There are three classes of entities in the RSerPool architecture:
o Pool Elements (PEs). o Pool Elements (PEs).
o Name Servers (NSs).
o ENRP Servers.
o Pool Users (PUs). o Pool Users (PUs).
2.1.1 Pool Elements
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. These servers are called Pool the same application functionality. These servers are called Pool
Elements (PEs). PEs form the first class of entities in the RSerPool Elements (PEs). PEs form the first class of entities in the RSerPool
architecture. Multiple PEs in a server pool can be used to provide architecture. Multiple PEs in a server pool can be used to provide
fault tolerance or load sharing, for example. fault tolerance or load sharing, for example.
Each server pool is identified by a unique name which is simply a Each server pool is identified by a unique identifier which is simply
byte string, called the pool handle. This allows binary names to be a byte string, called the pool handle. This allows binary
used. identifiers to be used.
These names are not valid in the whole internet but only in smaller These pool handles are not valid in the whole internet but only in
domains, called the operational scope. Furthermore, the namespace is smaller domains, called the operational scope. Furthermore, the
assumed to be flat, so that multiple levels of query are not handle-space is assumed to be flat, so that multiple levels of query
necessary to resolve a name request. are not necessary to resolve a pool handle.
2.1.2 ENRP Servers
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 ENRP servers. ENRP servers are designed to provide a fully
handle to a list of information which allows the PU to access a PE of distributed fault-tolerant real-time translation service that maps a
the server pool identified by the handle. This information includes: 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 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 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. In each operational scope there must be at least one ENRP server.
All ENRP 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.
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.
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], two new protocols: ENRP
(Endpoint Name Resolution Protocol) and ASAP (Aggregate Server Access (Endpoint haNdlespace Redundancy Protocol) and ASAP (Aggregate Server
Protocol). These are used because no existing protocols are suitable Access Protocol). These are used because no existing protocols are
(see [3]). suitable (see [3]).
2.2.1 Endpoint Name Resolution Protocol 2.2.1 Endpoint Handlespace Redundancy Protocol
The name servers use a protocol called Endpoint Name Resolution The ENRP servers use a protocol called Endpoint haNdlespace
Protocol (ENRP) for communication with each other to exchange Redundancy Protocol (ENRP) for communication with each other to
information and updates about the server pools. exchange information and updates about the server pools.
ENRP is designed to provide a fully distributed fault-tolerant ENRP guarantees the integrity of the RSerPool handlespace by
real-time translation service that maps a name to a set of transport providing the means for an ENRP server to
addresses pointing to a specific group of networked communication
endpoints registered under that name.
RFC3237 [9] also requires that the name servers should not resolve a o update its peers regarding changes to the handlspace caused by the
pool handle to a transport layer address of a PE which is not in addition of a PE or the status change of an existing PE,
operation. Therefore each PE is supervised by one specific name
server, called the home NS of that PE by using ASAP. If it detects o monitor the health of its peers, and, if necessary, take over the
that the PE is out of service all other name servers are informed by responsibility of being the home ENRP server for a set of PEs when
using ENRP. the ENRP server previously responsbile for those PEs has failed,
and
o audit the handlespace for inconsistencies and synchronize the
handlespace amongst its peers when inconsistencies have been
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
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.
ASAP uses a name-based addressing model 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. It
registers or deregisters itself by communicating with a name server, registers or deregisters itself by communicating with a ENRP server,
which will normally the home NS. ASAP allows dynamic system which will normally the home ENRP server. 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 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
that a PE is out of service via ASAP, it notifies its peers using
ENRP as described previously.
The PU <-> NS communication is used for performing name queries and 2.2.3 PU <-> ENRP Server Communication
uses ASAP. The PU sends a pool handle to the NS and gets back the
information necessary for accessing a server in a server 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
and gets back the 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 * * ENRP *
******** ******** * * * server *
******** **********
+------+ +------+ +------+ +------+
| ASAP | | ASAP | | ASAP | | ASAP |
+------+ +------+ +------+ +------+
| SCTP | | SCTP | | SCTP | | SCTP |
+------+ +------+ +------+ +------+
| IP | | IP | | IP | | IP |
+------+ +------+ +------+ +------+
Protocol stack between PU and NS Protocol stack between PU and ENRP server
Figure 1 Figure 1
2.2.4 PE <-> NS Communication 2.2.4 PE <-> ENRP Server Communication
The PE <-> NS 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 NS. This communication is based on SCTP, the of the PE by the home ENRP server. This communication uses ASAP and
protocol stack is shown in the following figure. is based on SCTP, the protocol stack is shown in the following
figure.
******** ******** ******** **********
* PE * * NS * * PE * * ENRP *
******** ******** * * * server *
******** **********
+------+ +------+ +------+ +------+
| ASAP | | ASAP | | ASAP | | ASAP |
+------+ +------+ +------+ +------+
| SCTP | | SCTP | | SCTP | | SCTP |
+------+ +------+ +------+ +------+
| IP | | IP | | IP | | IP |
+------+ +------+ +------+ +------+
Protocol stack between PE and NS Protocol stack between PE and ENRP server
Figure 2 Figure 2
2.2.5 PU <-> PE Communication 2.2.5 PU <-> PE Communication
The PU <-> PE communication can be divided into two parts: The PU <-> PE communication can be divided into two parts:
o control channel o control channel
o data channel o data channel
The data channel is used for the transmission of the upper layer The data channel is used for the transmission of the upper layer
data, the control channel is used to exchange RSerPool information. data, the control channel is used to exchange RSerPool information.
There are two supported scenarios: There are two supported scenarios:
o Multiplexed data and control channel. Both channels are o Multiplexed data and control channel. Both channels are
transported over one transport connection. This can either be an transported over one transport connection. This can either be an
SCTP association, with data and control channel are separated by SCTP association, with data and control channel are separated by
the PPID, or an TCP connection, with data and control channel the PPID, or an TCP connection, with data and control channel
being handled by a TCP mapping layer. being handled by a TCP mapping layer.
o Data channel and no control channel. There is no restriction on o Data channel and no control channel. There is no restriction on
the transport protocol in this case. Note that certain enhanced the transport protocol in this case. Note that certain enhanced
failover services (e.g. business cards, state cookies, message failover services (e.g. business cards, state cookies, message
failover) are not available when this method is used. failover) are not available when this method is used.
For a given pool, all PUs and PEs should make the same choice for the For a given pool, all PUs and PEs should make the same choice for the
style of interaction between each other: that is, for a given pool, style of interaction between each other: that is, for a given pool,
either all PEs and PUs in that pool use a multiplexed control/data either all PEs and PUs in that pool use a multiplexed control/data
channel for PU-PE communication, or all PEs and PUs in that pool use channel for PU-PE communication, or all PEs and PUs in that pool use
a data channel only for PU-PE communication. a data channel only for PU-PE communication.
skipping to change at page 8, line 24 skipping to change at page 9, line 30
failover) are not available when this method is used. failover) are not available when this method is used.
For a given pool, all PUs and PEs should make the same choice for the For a given pool, all PUs and PEs should make the same choice for the
style of interaction between each other: that is, for a given pool, style of interaction between each other: that is, for a given pool,
either all PEs and PUs in that pool use a multiplexed control/data either all PEs and PUs in that pool use a multiplexed control/data
channel for PU-PE communication, or all PEs and PUs in that pool use channel for PU-PE communication, or all PEs and PUs in that pool use
a data channel only for PU-PE communication. a data channel only for PU-PE communication.
When the multiplexed data and control channel is used, enhanced When the multiplexed data and control channel is used, enhanced
failover services may be provided, including: failover services may be provided, including:
o The PE can send a business card to the PU for providing o The PE can send a business card to the PU for providing
information to which other PE the PU should failover in case of a information to which other PE the PU should failover in case of a
failover. failover.
o The PE can send cookies to the PU. The PE would store only the o The PE can send cookies to the PU. The PE would store only the
last cookie and send it to the new PE in case of a failover. last cookie and send it to the new PE in case of a failover.
See Section 2.3 for further details. See Section 2.3 for further details.
2.2.6 NS <-> NS Communication 2.2.6 ENRP Server <-> ENRP Server Communication
The communication between name servers is used to share the knowledge The communication between ENRP servers is used to share the knowledge
about all server pools between all name servers in an operational about all server pools between all ENRP servers in an operational
scope. scope.
For this communication ENRP over SCTP is used and the protocol stack For this communication ENRP over SCTP is used and the protocol stack
is shown in Figure 3. is shown in Figure 3.
******** ******** ********** **********
* NS * * NS * * ENRP * * ENRP *
******** ******** * server * * server *
********** **********
+------+ +------+ +------+ +------+
| ENRP | | ENRP | | ENRP | | ENRP |
+------+ +------+ +------+ +------+
| SCTP | | SCTP | | SCTP | | SCTP |
+------+ +------+ +------+ +------+
| IP | | IP | | IP | | IP |
+------+ +------+ +------+ +------+
Protocol stack between NS and NS Protocol stack between ENRP servers
Figure 3 Figure 3
When a name initializes a UDP multicast message may be transmitted When a ENRP server initializes a UDP multicast message may be
for initial detection of other name servers in the operational scope. transmitted for initial detection of other ENRP servers in the
The other name servers send a response using a unicast UDP message. operational scope. The other ENRP 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, this means that one PE is
acting like a PU during the communication setup.
There is one additional point here: The PE acting as a PU can send The difference between a pure PU <-> PE communication is that the PE
the PE the information that it is actually a PE of a pool. This acting as a PU can send the PE the information that it is actually a
means that the pool handle is transferred via the control channel. PE of a pool. This means that the pool handle is transferred via the
See Section 2.3 for further details. control channel. 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 16 skipping to change at page 11, line 19
very important. Consider the scenario presented in the following very important. Consider the scenario presented in the following
figure. figure.
....................... .......................
. +-------+ . . +-------+ .
. | | . . | | .
. | PE 1 | . . | PE 1 | .
. | | . . | | .
. +-------+ . . +-------+ .
. . . .
. Server Pool . . server pool .
. . . .
. . . .
+-------+ . +-------+ . +-------+ +-------+ . +-------+ . +-------+
| | . | | . | | | | . | | . | |
| PU 1 |------.------| PE 2 |------.-------| PU 2 | | PU 1 |------.------| PE 2 |------.-------| PU 2 |
| | . | | . | | | | . | | . | |
+-------+ . +-------+ . +-------+ +-------+ . +-------+ . +-------+
. . . .
. . . .
. . . .
skipping to change at page 11, line 16 skipping to change at page 12, line 21
old 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 signature. For the PU, the cookie has no structure and is only
stored 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 ~ ~ operational scope ~
~ ......................... ......................... ~ ~ ......................... ......................... ~
~ . Server Pool 1 . . Server Pool 2 . ~ ~ . server pool 1 . . server pool 2 . ~
~ . +-------+ +-------+ . (d) . +-------+ +-------+ . ~ ~ . +-------+ +-------+ . (d) . +-------+ +-------+ . ~
~ . |PE(1,A)| |PE(1,C)|<-------------->|PE(2,B)| |PE(2,A)|<---+ ~ ~ . |PE(1,A)| |PE(1,C)|<-------------->|PE(2,B)| |PE(2,A)|<---+ ~
~ . +-------+ +-------+ . . +-------+ +-------+ . | ~ ~ . +-------+ +-------+ . . +-------+ +-------+ . | ~
~ . ^ ^ . . ^ ^ . | ~ ~ . ^ ^ . . ^ ^ . | ~
~ . | (a) | . . | | . | ~ ~ . | (a) | . . | | . | ~
~ . +----------+ | . . | | . | ~ ~ . +----------+ | . . | | . | ~
~ . +-------+ | | . . | | . | ~ ~ . +-------+ | | . . | | . | ~
~ . |PE(1,B)|<---+ | | . . | | . | ~ ~ . |PE(1,B)|<---+ | | . . | | . | ~
~ . +-------+ | | | . . | | . | ~ ~ . +-------+ | | | . . | | . | ~
~ . ^ | | | . . | | . | ~ ~ . ^ | | | . . | | . | ~
~ .......|........|.|.|.... .......|.........|....... | ~ ~ .......|........|.|.|.... .......|.........|....... | ~
~ | | | | | | | ~ ~ | | | | | | | ~
~ (c)| (a)| | |(a) (a)| (a)| (c)| ~ ~ (c)| (a)| | |(a) (a)| (a)| (c)| ~
~ | | | | | | | ~ ~ | | | | | | | ~
~ | v v v v v | ~ ~ | v v v v v | ~
~ | +++++++++++++++ (e) +++++++++++++++ | ~ ~ | +++++++++++++++ (e) +++++++++++++++ | ~
~ | + NS +<---------->+ NS + | ~ ~ | + ENRP server +<---------->+ ENRP server + | ~
~ | +++++++++++++++ +++++++++++++++ | ~ ~ | +++++++++++++++ +++++++++++++++ | ~
~ v ^ ^ | ~ ~ v ^ ^ | ~
~ ********* | | | ~ ~ ********* | | | ~
~ * PU(A) *<-------+ (b)| | ~ ~ * PU(A) *<-------+ (b)| | ~
~ ********* (b) | | ~ ~ ********* (b) | | ~
~ v | ~ ~ v | ~
~ ::::::::::::::::: (f) ***************** | ~ ~ ::::::::::::::::: (f) ***************** | ~
~ : Other Clients :<------------->* Proxy/Gateway * <---+ ~ ~ : other clients :<------------->* proxy/gateway * <---+ ~
~ ::::::::::::::::: ***************** ~ ~ ::::::::::::::::: ***************** ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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 <-> ENRP server: (ASAP) Each PE in a pool
to register or de-register itself as well as to exchange other uses ASAP to register or de-register itself as well as to exchange
auxiliary information with the NS. The NS also uses ASAP to other auxiliary information with the ENRP server. The ENRP server
monitor the operational status of each PE in a pool. also uses ASAP to monitor the operational status of each PE in a
(b) PU <-> NS: (ASAP) A PU normally uses ASAP to request the NS for a pool.
name-to-address translation service before the PU can send user
messages addressed to a server pool by the pool's name. (b) PU <-> ENRP server: (ASAP) A PU normally uses ASAP to request the
ENRP server for a pool handle to address translation service
before the PU can send user messages addressed to a server pool by
the pool's handle.
(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
operation, administration, and maintenance (OAM) functions. (e) ENRP server <-> ENRP server: (ENRP) ENRP can be used to fulfill
various handle space operation, administration, and maintenance
(OAM) functions.
(f) Other Clients <-> Proxy/Gateway: standard protocols The (f) Other Clients <-> Proxy/Gateway: standard protocols The
proxy/gateway enables clients ("other clients"), which are not proxy/gateway enables clients ("other clients"), which are not
RSerPool aware, to access services provided by an RSerPool based RSerPool aware, to access services provided by an RSerPool based
server pool. It should be noted that these proxies/gateways may server pool. It should be noted that these proxies/gateways may
become a single point of failure. become a 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 RSerPool-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 [5] 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 transfer takes place over SCTP. In the second example we will use
TCP between the unaware client and the Proxy. The Proxy itself will TCP between the unaware client and the Proxy. The Proxy itself will
use the modified FTP with RSerPool as illustrated in the first use the modified FTP with RSerPool as illustrated in the first
example. 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ operation scope ~ ~ operational scope ~
~ ......................... ~ ~ ......................... ~
~ . "File Transfer Pool" . ~ ~ . "file transfer pool" . ~
~ . +-------+ +-------+ . ~ ~ . +-------+ +-------+ . ~
~ +-> |PE(1,A)| |PE(1,C)| . ~ ~ +-> |PE(1,A)| |PE(1,C)| . ~
~ |. +-------+ +-------+ . ~ ~ |. +-------+ +-------+ . ~
~ |. ^ ^ . ~ ~ |. ^ ^ . ~
~ |. +----------+ | . ~ ~ |. +----------+ | . ~
~ |. +-------+ | | . ~ ~ |. +-------+ | | . ~
~ |. |PE(1,B)|<---+ | | . ~ ~ |. |PE(1,B)|<---+ | | . ~
~ |. +-------+ | | | . ~ ~ |. +-------+ | | | . ~
~ |. ^ | | | . ~ ~ |. ^ | | | . ~
~ |.......|........|.|.|.... ~ ~ |.......|........|.|.|.... ~
~ | ASAP | ASAP| | |ASAP ~ ~ | ASAP | ASAP| | |ASAP ~
~ |(d) |(c) | | | ~ ~ |(d) |(c) | | | ~
~ | v v v v ~ ~ | v v v v ~
~ | ********* +++++++++++++++ ~ ~ | ********* +++++++++++++++ ~
~ + ->* PU(X) * + NS + ~ ~ + ->* PU(X) * + ENRP server + ~
~ ********* +++++++++++++++ ~ ~ ********* +++++++++++++++ ~
~ ^ ASAP ^ ~ ~ ^ ASAP ^ ~
~ | <-(b) | ~ ~ | <-(b) | ~
~ +--------------+ ~ ~ +--------------+ ~
~ (a)-> ~ ~ (a)-> ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Architecture for RSerPool aware client. Architecture for RSerPool aware client.
Figure 6 Figure 6
skipping to change at page 13, line 38 skipping to change at page 14, line 50
~ | <-(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 ENRP server to
list of pool elements (using (a)). The pool handle to identify request the list of pool elements (using (a)). The pool handle
the pool would be "File Transfer Pool". The ASAP layer queues to identify the pool would be "File Transfer Pool". The ASAP
the login request. layer queues the login request.
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)). 2. The ENRP server 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)).
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 the NS to request a cache update for the server would be made to the ENRP server to request a cache update for
pool "File Transfer Pool" and a report would also be made that the server pool "File Transfer Pool" and a report would also be
PE(1,B) is non-responsive (this would cause appropriate audits made that PE(1,B) is non-responsive (this would cause appropriate
that may remove PE(1,B) from the pool if the NS had not already audits that may remove PE(1,B) from the pool if the ENRP server
detected the failure) (using (a)). 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
(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 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 and its one IP address it is using for commands. connection and its one IP address it is using for commands.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
skipping to change at page 15, line 6 skipping to change at page 16, line 6
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 and its one IP address it is using for commands. connection and its one IP address it is using for commands.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ operation scope ~ ~ operational scope ~
~ ......................... ~ ~ ......................... ~
~ . "File Transfer Pool" . ~ ~ . "file transfer pool" . ~
~ . +-------+ +-------+ . ~ ~ . +-------+ +-------+ . ~
~ . |PE(1,A)| |PE(1,C)| . ~ ~ . |PE(1,A)| |PE(1,C)| . ~
~ . +-------+ +-------+ . ~ ~ . +-------+ +-------+ . ~
~ . ^ ^ . ~ ~ . ^ ^ . ~
~ . +----------+ | . ~ ~ . +----------+ | . ~
~ . +-------+ | | . ~ ~ . +-------+ | | . ~
~ . |PE(1,B)|<---+ | | . ~ ~ . |PE(1,B)|<---+ | | . ~
~ . +-------+ | | | . ~ ~ . +-------+ | | | . ~
~ .......^........|.|.|.... ~ ~ .......^........|.|.|.... ~
~ | | | | ~ ~ | | | | ~
~ | ASAP| | |ASAP ~ ~ | ASAP| | |ASAP ~
~ | | | | ~ ~ | | | | ~
~ | v v v ~ ~ | v v v ~
~ | +++++++++++++++ +++++++++++++++ ~ ~ | +++++++++++++++ +++++++++++++++ ~
~ | + NS +<--ENRP-->+ NS + ~ ~ | + ENRP server +<--ENRP-->+ ENRP server + ~
~ | +++++++++++++++ +++++++++++++++ ~ ~ | +++++++++++++++ +++++++++++++++ ~
~ | ASAP ^ ~ ~ | ASAP ^ ~
~ | ASAP (c) (b) | ^ ~ ~ | ASAP (c) (b) | ^ ~
~ +---------------------------------+ | | | ~ ~ +---------------------------------+ | | | ~
~ | v | (a) ~ ~ | v | (a) ~
~ v v ~ ~ v v ~
~ ::::::::::::::::: (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 Telephony Signaling Example 3.2 Load Balancing Example
This examples is similar to the one above describing an RSerPool
unaware client. In both examples the clients do not need to support
the RSerPool protocol suite.
There are several servers in a pool and the traffic from clients is
distributed among them by a load balancer. The load balancer can
make use of load information of the servers for optimal load
distribution.
One possibility of using RSerPool for this application is described
in the next figure. The servers become pool elements in one pool and
register themselves at ENRP servers. They can also provide load
information. The load balancer acts as a pool user and gets the
addresses and possibly the load information via ASAP communication
with ENRP servers. The communication between the clients and servers
is not affected.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ operational scope ~
~ ......................... ~
~ . "server pool" . ~
~ . +-------+ +-------+ . ~
~ . |PE(1,A)| |PE(1,C)| . ~
~ . +-------+ +-------+ . ~
~ . ^ ^ . ~
~ . +----------+ | . ~
~ . +-------+ | | . ~
~ . |PE(1,B)|<---+ | | . ~
~ . +-------+ | | | . ~
~ .......^........|.|.|.... ~
~ | | | | ~
~ | ASAP| | |ASAP ~
~ | | | | ~
~ | v v v ~
~ | +++++++++++++++ +++++++++++++++ ~
~ | + ENRP server +<--ENRP-->+ ENRP server + ~
~ | +++++++++++++++ +++++++++++++++ ~
~ | ^ ~
~ | (c) | ~
~ +---------------------------------+ | ASAP ~
~ | | (a) ~
~ v v ~
~ ::::::::::::::::: (b) ********************** ~
~ : client :<----------->* load balancer (PU) * ~
~ ::::::::::::::::: ********************** ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Architecture for an RSerPool based load balancer.
Figure 8
3.3 Telephony Signaling Example
This example shows the use of ASAP/RSerPool to support server pooling This example shows the use of ASAP/RSerPool to support server pooling
for high availability of a telephony application such as a Voice over for high availability of a telephony application such as a Voice over
IP Gateway Controller (GWC) and Gatekeeper services (GK). IP Gateway Controller (GWC) and Gatekeeper services (GK).
In this example, we show two different scenarios of deploying these In this example, we show two different scenarios of deploying these
services using RSerPool in order to illustrate the flexibility of the services using RSerPool in order to illustrate the flexibility of the
RSerPool architecture. RSerPool architecture.
3.2.1 Decomposed GWC and GK Scenario 3.3.1 Decomposed GWC and GK Scenario
In this scenario, both GWC and GK services are deployed as separate In this scenario, both GWC and GK services are deployed as separate
pools with some number of PEs, as shown in the following diagram. pools with some number of PEs, as shown in the following diagram.
Each of the pools will register their unique pool handle with the
Each of the pools will register their unique pool handle (i.e. name) ENRP server. We also assume that there are a Signaling Gateway (SG)
with the NS. We also assume that there are a Signaling Gateway (SG)
and a Media Gateway (MG) present and both are RSerPool aware. and a Media Gateway (MG) present and both are RSerPool aware.
................... ...................
. Gateway . . gateway .
. Controller Pool . . controller pool .
................. . +-------+ . ................. . +-------+ .
. Gatekeeper . . |PE(2,A)| . . gatekeeper . . |PE(2,A)| .
. Pool . . +-------+ . . pool . . +-------+ .
. +-------+ . . +-------+ . . +-------+ . . +-------+ .
. |PE(1,A)| . . |PE(2,B)| . . |PE(1,A)| . . |PE(2,B)| .
. +-------+ . . +-------+ . . +-------+ . . +-------+ .
. +-------+ . (d) . +-------+ . . +-------+ . (d) . +-------+ .
. |PE(1,B)|<------------>|PE(2,C)|<-------------+ . |PE(1,B)|<------------>|PE(2,C)|<-------------+
. +-------+ . . +-------+ . | . +-------+ . . +-------+ . |
................. ........^.......... | ................. ........^.......... |
| | | |
(c)| (e)| (c)| (e)|
| v | v
+++++++++++++++ ********* ***************** +++++++++++++++ ********* *****************
+ NS + * SG(X) * * Media Gateway * + ENRP server + * SG(X) * * media gateway *
+++++++++++++++ ********* ***************** +++++++++++++++ ********* *****************
^ ^ ^ ^
| | | |
| <-(a) | | <-(a) |
+-------------------+ +-------------------+
(b)-> (b)->
Deployment of Decomposed GWC and GK. Deployment of Decomposed GWC and GK.
Figure 8 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 would send an
ASAP request to its "local" NS to request the list of pool ASAP request to its "local" ENRP server to request the list of
elements (PE's) of GWC (using (a)). The key used for this query pool elements (PE's) of GWC (using (a)). The key used for this
is the pool handle of the GWC. The ASAP layer queues the data to query is the pool handle of the GWC. The ASAP layer queues the
be sent to the GWC in local buffers until the NS responds. data to be sent to the GWC in local buffers until the ENRP server
2. the NS would return a list of the three PE's A, B and C to the responds.
ASAP layer in SG(X) together with information to be used for
load-sharing traffic across the gateway controller pool (using 2. the ENRP server would return a list of the three PE's A, B and C
(b)). to the ASAP layer in SG(X) together with information to be used
for load-sharing traffic across the gateway controller pool
(using (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 ENRP server), PE(2,C) selects PE(1,B) and sends
control message to it (using (d)). the call control message to it (using (d)).
5. We assume PE(1,B) responds back to PE(2,C) and authorizes the 5. We assume PE(1,B) responds back to PE(2,C) and authorizes the
call to proceed. call to 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 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
skipping to change at page 17, line 31 skipping to change at page 19, line 41
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 (likely) the endpoint unreachability detection by the
transport protocol beneath ASAP and automatically deliver the re-sent transport protocol beneath ASAP and automatically deliver the re-sent
call 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.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 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.
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 is
selected by SG). selected by SG).
........................................ ........................................
. Gateway Controller/Gatekeeper Pool . . gateway controller/gatekeeper pool .
. +-------+ . . +-------+ .
. |PE(3,A)| . . |PE(3,A)| .
. +-------+ . . +-------+ .
. +-------+ . . +-------+ .
. |PE(3,C)|<---------------------------+ . |PE(3,C)|<---------------------------+
. +-------+ . | . +-------+ . |
. +-------+ ^ . | . +-------+ ^ . |
. |PE(3,B)| | . | . |PE(3,B)| | . |
. +-------+ | . | . +-------+ | . |
................|....................... | ................|....................... |
| | | |
+-------------+ | +-------------+ |
| | | |
(c)| (e)| (c)| (e)|
v v v v
+++++++++++++++ ********* ***************** +++++++++++++++ ********* *****************
+ NS + * SG(X) * * Media Gateway * + ENRP server + * SG(X) * * media gateway *
+++++++++++++++ ********* ***************** +++++++++++++++ ********* *****************
^ ^ ^ ^
| | | |
| <-(a) | | <-(a) |
+-------------------+ +-------------------+
(b)-> (b)->
Deployment of Collocated GWC and GK. Deployment of Collocated GWC and GK.
Figure 9 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 namespace, pool element registration and user queries of the the handle space, pool element registration and user queries of the
namespace. In [2] a complete threat analysis of RSerPool components handle space. In [2] a complete threat analysis of RSerPool
is presented. components 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, 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 6. References
6.1 Normative References 6.1 Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP [1] Bradner, S., "The Internet Standards Process -- Revision 3",
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",
draft-ietf-rserpool-threats-03 (work in progress), July 2004. Internet-Draft draft-ietf-rserpool-threats-04, January 2005.
[3] Loughney, J., "Comparison of Protocols for Reliable Server [3] Loughney, J., "Comparison of Protocols for Reliable Server
Pooling", draft-ietf-rserpool-comp-08 (work in progress), July Pooling", Internet-Draft draft-ietf-rserpool-comp-08, July 2004.
2004.
6.2 Informative References 6.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, RFC [5] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9,
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,
skipping to change at page 19, line 51 skipping to change at page 21, line 50
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
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
Phone: +1-847-632-3028 Phone: +1-847-632-3028
EMail: qxie1@email.mot.com Email: qxie1@email.mot.com
Randall R. Stewart Randall R. Stewart
Cisco Systems, Inc. Cisco Systems, Inc.
8725 West Higgins Road 8725 West Higgins Road
Suite 300 Suite 300
Chicago, IL 60631 Chicago, IL 60631
USA USA
Phone: +1-815-477-2127 Phone: +1-815-477-2127
EMail: rrs@cisco.com Email: rrs@cisco.com
Melinda Shore Melinda Shore
Cisco Systems, Inc. Cisco Systems, Inc.
809 Hayts Rd 809 Hayts Rd
Ithaca, NY 14850 Ithaca, NY 14850
USA USA
Phone: +1 607 272 7512 Phone: +1 607 272 7512
EMail: mshore@cisco.com Email: mshore@cisco.com
John Loughney John Loughney
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
Aron J. Silverton
Motorola Labs
1301 E. Algonquin Road
Room 2246
Schaumburg, IL 60196
US
Phone: +1 847-576-8747
Email: aron.j.silverton@motorola.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 Rights 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; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 21, line 41 skipping to change at page 24, line 41
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
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
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/