[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12

Network Working Group                                     M. Tuexen, Ed.
Internet-Draft                        Muenster Univ. of Applied Sciences
Expires: August 24, 2005                                          Q. Xie
                                                          Motorola, Inc.
                                                              R. Stewart
                                                                M. Shore
                                                     Cisco Systems, Inc.
                                                             J. Loughney
                                                   Nokia Research Center
                                                            A. Silverton
                                                           Motorola Labs
                                                       February 20, 2005


                Architecture for Reliable Server Pooling
                    draft-ietf-rserpool-arch-09.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   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
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 24, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).




Tuexen, et al.           Expires August 24, 2005                [Page 1]


Internet-Draft    Architecture for Reliable Server Pooling February 2005


Abstract

   This document describes an architecture and protocols for the
   management and operation of server pools supporting highly reliable
   applications, and for client access mechanisms to a server pool.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1   Overview . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2   Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
     1.3   Abbreviations  . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Reliable Server Pooling Architecture . . . . . . . . . . . . .  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.1   Endpoint Handlespace Redundancy Protocol . . . . . . .  6
       2.2.2   Aggregate Server Access Protocol . . . . . . . . . . .  6
       2.2.3   PU <-> ENRP Server Communication . . . . . . . . . . .  7
       2.2.4   PE <-> ENRP Server Communication . . . . . . . . . . .  8
       2.2.5   PU <-> PE Communication  . . . . . . . . . . . . . . .  8
       2.2.6   ENRP Server <-> ENRP Server Communication  . . . . . .  9
       2.2.7   PE <-> PE Communication  . . . . . . . . . . . . . . . 10
     2.3   Failover Support . . . . . . . . . . . . . . . . . . . . . 10
       2.3.1   Business Cards . . . . . . . . . . . . . . . . . . . . 10
       2.3.2   Cookies  . . . . . . . . . . . . . . . . . . . . . . . 12
     2.4   Typical Interactions between RSerPool Components . . . . . 12
   3.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     3.1   Two File Transfer Examples . . . . . . . . . . . . . . . . 13
       3.1.1   The RSerPool Aware Client  . . . . . . . . . . . . . . 14
       3.1.2   The RSerPool Unaware Client  . . . . . . . . . . . . . 15
     3.2   Load Balancing Example . . . . . . . . . . . . . . . . . . 16
     3.3   Telephony Signaling Example  . . . . . . . . . . . . . . . 17
       3.3.1   Decomposed GWC and GK Scenario . . . . . . . . . . . . 18
       3.3.2   Collocated GWC and GK Scenario . . . . . . . . . . . . 19
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     6.1   Normative References . . . . . . . . . . . . . . . . . . . 21
     6.2   Informative References . . . . . . . . . . . . . . . . . . 21
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
       Intellectual Property and Copyright Statements . . . . . . . . 24







Tuexen, et al.           Expires August 24, 2005                [Page 2]


Internet-Draft    Architecture for Reliable Server Pooling February 2005


1.  Introduction

1.1  Overview

   This document defines an architecture, for providing a highly
   available reliable server function in support of a service or set of
   services.  This is achieved by forming a pool of servers, each of
   which is capable of supporting the desired service(s), and providing
   a name service that will resolve requests from a service user to the
   identity of a working server in the pool.

   To access a server pool, the pool user consults an ENRP server.  The
   name service itself can be provided by a pool of ENRP servers using a
   shared protocol to make the name resolution function fault-tolerant.
   It is assumed that the handle space is kept flat and designed for a
   limited scale in order to keep the protocols simple, robust and fast.

   The server pool itself is supported by a shared protocol between
   servers and the name service allowing servers to enter and exit the
   pool.  Several server selection mechanisms, called server pool
   policies, are supported for flexibility.

1.2  Terminology

   This document uses the following terms:

   Home ENRP Server: The ENRP server a Pool Element has registered with.
      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.

   Pool (or server pool): A collection of servers providing the same
      application functionality.

   Pool handle: A logical pointer to a pool.  Each server pool will be
      identifiable in the operational scope of the system by a unique
      pool handle.

   Pool element: A server entity having registered to a pool.

   Pool user: A server pool user.

   Pool element handle (or endpoint handle): A logical pointer to a
      particular pool element in a pool, consisting of the pool handle
      and a destination transport address of the pool element.





Tuexen, et al.           Expires August 24, 2005                [Page 3]


Internet-Draft    Architecture for Reliable Server Pooling February 2005


   Handle space: A cohesive structure of pool handles and relations that
      may be queried by an internal or external agent.

   ENRP server: Entity which is responsible for managing and maintaining
      the handle space within the RSerPool operational scope.


1.3  Abbreviations

   ASAP: Aggregate Server Access Protocol

   ENRP: Endpoint haNdlespace Redundancy Protocol

   PE: Pool element

   PU: Pool user

   SCTP: Stream Control Transmission Protocol

   TCP: Transmission Control Protocol


2.  Reliable Server Pooling Architecture

   In this section, we define a reliable server pool architecture.

2.1  RSerPool Functional Components

   There are three classes of entities in the RSerPool architecture:

   o  Pool Elements (PEs).

   o  ENRP Servers.

   o  Pool Users (PUs).


2.1.1  Pool Elements

   A server pool is defined as a set of one or more servers providing
   the same application functionality.  These servers are called Pool
   Elements (PEs).  PEs form the first class of entities in the RSerPool
   architecture.  Multiple PEs in a server pool can be used to provide
   fault tolerance or load sharing, for example.

   Each server pool is identified by a unique identifier which is simply
   a byte string, called the pool handle.  This allows binary
   identifiers to be used.



Tuexen, et al.           Expires August 24, 2005                [Page 4]


Internet-Draft    Architecture for Reliable Server Pooling February 2005


   These pool handles are not valid in the whole internet but only in
   smaller domains, called the operational scope.  Furthermore, the
   handle-space is assumed to be flat, so that multiple levels of query
   are not necessary to resolve a pool handle.

2.1.2  ENRP Servers

   The second class of entities in the RSerPool architecture is the
   class of ENRP servers.  ENRP servers are designed to provide a fully
   distributed fault-tolerant real-time translation service that maps a
   pool handle to set of transport addresses pointing to a specific
   group of networked communication endpoints registered under that pool
   handle.  To be more precise, ENRP servers can resolve a pool handle
   to a list of information which allows the PU to access a PE of the
   server pool identified by the handle.  This information includes:

   o  A list of IPv4 and/or IPv6 addresses.

   o  A protocol field specifying the transport layer protocol.

   o  A port number associated with the transport protocol, e.g.  SCTP,
      TCP or UDP.

   Note that the RSerPool architecture supports both IPv4 and IPv6
   addressing.

   In each operational scope there must be at least one ENRP server.
   All ENRP servers within the operational scope have knowledge of all
   server pools within the operational scope.

   RFC3237 [9] also requires that the ENRP servers should not resolve a
   pool handle to a transport layer address of a PE which is not in
   operation.  Therefore each PE is supervised by one specific ENRP
   server, called the home ENRP server of that PE.  If it detects that
   the PE is out of service all other ENRP servers are informed.

2.1.3  Pool Users

   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
   pool.

2.2  RSerPool Protocol Overview

   Based on the requirements in RFC3237 [9], two new protocols: ENRP
   (Endpoint haNdlespace Redundancy Protocol) and ASAP (Aggregate Server
   Access Protocol).  These are used because no existing protocols are
   suitable (see [3]).



Tuexen, et al.           Expires August 24, 2005                [Page 5]


Internet-Draft    Architecture for Reliable Server Pooling February 2005


2.2.1  Endpoint Handlespace Redundancy Protocol

   The ENRP servers use a protocol called Endpoint haNdlespace
   Redundancy Protocol (ENRP) for communication with each other to
   exchange information and updates about the server pools.

   ENRP guarantees the integrity of the RSerPool handlespace by
   providing the means for an ENRP server to

   o  update its peers regarding changes to the handlspace caused by the
      addition of a PE or the status change of an existing PE,

   o  monitor the health of its peers, and, if necessary, take over the
      responsibility of being the home ENRP server for a set of PEs when
      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

   The PU wanting service from the pool uses the Aggregate Server Access
   Protocol (ASAP) to access members of the pool.  Depending on the
   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
   mediate all communication between the PU and PE, so that automatic
   failover from a failed PE to an alternate PE can be supported.

   ASAP uses pool handles for addressing which isolates a logical
   communication endpoint from its IP address(es), thus effectively
   eliminating the binding between the communication endpoint and its
   physical IP address(es) which normally constitutes a single point of
   failure.

   In addition, ASAP provides some mechanisms to support loadsharing
   between PEs within the same pool and to support the upper layer in
   case of a failover between PEs becomes necessary.

   ASAP is also used by a PE to join or leave a server pool.  It
   registers or deregisters itself by communicating with a ENRP server,
   which will normally the home ENRP server.  ASAP allows dynamic system
   scalability, allowing the pool membership to change at any time.

   ASAP is used by a home ENRP server to supervise the PEs that have
   registered with that ENRP server.  If the home ENRP server detects



Tuexen, et al.           Expires August 24, 2005                [Page 6]


Internet-Draft    Architecture for Reliable Server Pooling February 2005


   that a PE is out of service via ASAP, it notifies its peers using
   ENRP as described previously.

2.2.3  PU <-> ENRP Server Communication

   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
   support SCTP.  The protocol stack for an SCTP capable PU is given in
   Figure 1.






































Tuexen, et al.           Expires August 24, 2005                [Page 7]


Internet-Draft    Architecture for Reliable Server Pooling February 2005


                       ********        **********
                       *  PU  *        *  ENRP  *
                       *      *        * server *
                       ********        **********

                       +------+         +------+
                       | ASAP |         | ASAP |
                       +------+         +------+
                       | SCTP |         | SCTP |
                       +------+         +------+
                       |  IP  |         |  IP  |
                       +------+         +------+

                Protocol stack between PU and ENRP server

                                Figure 1


2.2.4  PE <-> ENRP Server Communication

   The PE <-> ENRP server communication is used for registration and
   deregistration of the PE in one or more pools and for the supervision
   of the PE by the home ENRP server.  This communication uses ASAP and
   is based on SCTP, the protocol stack is shown in the following
   figure.

                       ********        **********
                       *  PE  *        *  ENRP  *
                       *      *        * server *
                       ********        **********

                       +------+         +------+
                       | ASAP |         | ASAP |
                       +------+         +------+
                       | SCTP |         | SCTP |
                       +------+         +------+
                       |  IP  |         |  IP  |
                       +------+         +------+
               Protocol stack between PE and ENRP server

                                Figure 2


2.2.5  PU <-> PE Communication

   The PU <-> PE communication can be divided into two parts:

   o  control channel



Tuexen, et al.           Expires August 24, 2005                [Page 8]


Internet-Draft    Architecture for Reliable Server Pooling February 2005


   o  data channel

   The data channel is used for the transmission of the upper layer
   data, the control channel is used to exchange RSerPool information.

   There are two supported scenarios:

   o  Multiplexed data and control channel.  Both channels are
      transported over one transport connection.  This can either be an
      SCTP association, with data and control channel are separated by
      the PPID, or an TCP connection, with data and control channel
      being handled by a TCP mapping layer.

   o  Data channel and no control channel.  There is no restriction on
      the transport protocol in this case.  Note that certain enhanced
      failover services (e.g.  business cards, state cookies, message
      failover) are not available when this method is used.

   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,
   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
   a data channel only for PU-PE communication.

   When the multiplexed data and control channel is used, enhanced
   failover services may be provided, including:

   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
      failover.

   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.

   See Section 2.3 for further details.

2.2.6  ENRP Server <-> ENRP Server Communication

   The communication between ENRP servers is used to share the knowledge
   about all server pools between all ENRP servers in an operational
   scope.

   For this communication ENRP over SCTP is used and the protocol stack
   is shown in Figure 3.







Tuexen, et al.           Expires August 24, 2005                [Page 9]


Internet-Draft    Architecture for Reliable Server Pooling February 2005


                      **********      **********
                      *  ENRP  *      *  ENRP  *
                      * server *      * server *
                      **********      **********

                       +------+        +------+
                       | ENRP |        | ENRP |
                       +------+        +------+
                       | SCTP |        | SCTP |
                       +------+        +------+
                       |  IP  |        |  IP  |
                       +------+        +------+
                  Protocol stack between ENRP servers

                                Figure 3

   When a ENRP server initializes a UDP multicast message may be
   transmitted for initial detection of other ENRP servers in the
   operational scope.  The other ENRP servers send a response using a
   unicast UDP message.

2.2.7  PE <-> PE Communication

   This is a special case of the PU <-> PE communication.  In this case
   the PU is also a PE in a server pool, this means that one PE is
   acting like a PU during the communication setup.

   The difference between a pure PU <-> PE communication is that the PE
   acting as a PU can send the PE the information that it is actually a
   PE of a pool.  This means that the pool handle is transferred via the
   control channel.  See Section 2.3 for further details.

2.3  Failover Support

   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
   the new PE is not affected by the failed one.

   There are some mechanisms provided by RSerPool to support the
   failover to a new PE.

2.3.1  Business Cards

   A PE can send a business card to its peer containing its pool handle
   and optionally information to which other PEs the peer should
   failover.

   Presenting the pool handle is important in case of PE <-> PE



Tuexen, et al.           Expires August 24, 2005               [Page 10]


Internet-Draft    Architecture for Reliable Server Pooling February 2005


   communication in which one of the PEs acts as a PU for establishing
   the communication.  The pool handle of the PE which initiated the
   communication may not be known by the peer.

   Providing information to which PE the PU should failover can also be
   very important.  Consider the scenario presented in the following
   figure.

                   .......................
                   .      +-------+      .
                   .      |       |      .
                   .      |  PE 1 |      .
                   .      |       |      .
                   .      +-------+      .
                   .                     .
                   .     server pool     .
                   .                     .
                   .                     .
    +-------+      .      +-------+      .       +-------+
    |       |      .      |       |      .       |       |
    |  PU 1 |------.------|  PE 2 |------.-------|  PU 2 |
    |       |      .      |       |      .       |       |
    +-------+      .      +-------+      .       +-------+
                   .                     .
                   .                     .
                   .                     .
                   .                     .
                   .      +-------+      .
                   .      |       |      .
                   .      |  PE 3 |      .
                   .      |       |      .
                   .      +-------+      .
                   .......................
                 Two PUs accessing the same PE

                                Figure 4

   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 is possible for PE 2 to inform PU 1 that it should fail over to PE
   1 in case of a failure.

   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 it is important that PU 1 and PU 2 fail over to the same PE.
   This can be handled in a way such that PE 2 gives the same business
   card to PU 1 and PU 2.




Tuexen, et al.           Expires August 24, 2005               [Page 11]


Internet-Draft    Architecture for Reliable Server Pooling February 2005


2.3.2  Cookies

   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
   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 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 and transmitted to the new PE.

2.4  Typical Interactions between RSerPool Components

   The following drawing shows the typical RSerPool components and their
   possible interactions with each other:

     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     ~                                                operational scope ~
     ~  .........................          .........................    ~
     ~  .        server pool 1  .          .        server pool 2  .    ~
     ~  .  +-------+ +-------+  .    (d)   .  +-------+ +-------+  .    ~
     ~  .  |PE(1,A)| |PE(1,C)|<-------------->|PE(2,B)| |PE(2,A)|<---+  ~
     ~  .  +-------+ +-------+  .          .  +-------+ +-------+  . |  ~
     ~  .      ^            ^   .          .      ^         ^      . |  ~
     ~  .      |      (a)   |   .          .      |         |      . |  ~
     ~  .      +----------+ |   .          .      |         |      . |  ~
     ~  .  +-------+      | |   .          .      |         |      . |  ~
     ~  .  |PE(1,B)|<---+ | |   .          .      |         |      . |  ~
     ~  .  +-------+    | | |   .          .      |         |      . |  ~
     ~  .      ^        | | |   .          .      |         |      . |  ~
     ~  .......|........|.|.|....          .......|.........|....... |  ~
     ~         |        | | |                     |         |        |  ~
     ~      (c)|     (a)| | |(a)               (a)|      (a)|     (c)|  ~
     ~         |        | | |                     |         |        |  ~
     ~         |        v v v                     v         v        |  ~
     ~         |     +++++++++++++++    (e)     +++++++++++++++      |  ~
     ~         |     + ENRP server +<---------->+ ENRP server +      |  ~
     ~         |     +++++++++++++++            +++++++++++++++      |  ~
     ~         v            ^                          ^             |  ~
     ~     *********        |                          |             |  ~
     ~     * PU(A) *<-------+                       (b)|             |  ~
     ~     *********   (b)                             |             |  ~
     ~                                                 v             |  ~
     ~         :::::::::::::::::      (f)      *****************     |  ~
     ~         : other clients :<------------->* proxy/gateway * <---+  ~
     ~         :::::::::::::::::               *****************        ~
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            RSerPool components and their possible interactions.




Tuexen, et al.           Expires August 24, 2005               [Page 12]


Internet-Draft    Architecture for Reliable Server Pooling February 2005


                                Figure 5

   In this figure  we can identify the following possible interactions:

   (a) server pool elements <-> ENRP server: (ASAP) Each PE in a pool
      uses ASAP to register or de-register itself as well as to exchange
      other auxiliary information with the ENRP server.  The ENRP server
      also uses ASAP to monitor the operational status of each PE in a
      pool.

   (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
      information of the two parties before they engage in user data
      transfer.

   (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
      communication with the other pool.  In such a case, the
      interactions described in (a) and (c) above will apply.

   (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
      proxy/gateway enables clients ("other clients"), which are not
      RSerPool aware, to access services provided by an RSerPool based
      server pool.  It should be noted that these proxies/gateways may
      become a single point of failure.


3.  Examples

   In this section the basic concepts of ENRP and ASAP will be
   described.  First an RSerPool aware FTP server is considered.  The
   interaction with an RSerPool aware and an non-aware client is given.
   Finally, a telephony example is considered.

3.1  Two File Transfer Examples

   In this section we present two separate file transfer examples using
   ENRP and ASAP.  We present two separate examples demonstrating an
   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



Tuexen, et al.           Expires August 24, 2005               [Page 13]


Internet-Draft    Architecture for Reliable Server Pooling February 2005


   RFC959 [5] model with some modifications.  The first example (the
   RSerPool aware one) will modify FTP concepts so that the file
   transfer takes place over SCTP.  In the second example we will use
   TCP between the unaware client and the Proxy.  The Proxy itself will
   use the modified FTP with RSerPool as illustrated in the first
   example.

   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
   basic FTP model.  These examples use FTP for illustrative purposes,
   FTP was chosen since many of the basic concept are well known and
   should be familiar to readers.

3.1.1  The RSerPool Aware Client

   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   ~                                                operational scope ~
   ~  .........................                                       ~
   ~  . "file transfer pool"  .                                       ~
   ~  .  +-------+ +-------+  .                                       ~
   ~ +-> |PE(1,A)| |PE(1,C)|  .                                       ~
   ~ |.  +-------+ +-------+  .                                       ~
   ~ |.      ^            ^   .                                       ~
   ~ |.      +----------+ |   .                                       ~
   ~ |.  +-------+      | |   .                                       ~
   ~ |.  |PE(1,B)|<---+ | |   .                                       ~
   ~ |.  +-------+    | | |   .                                       ~
   ~ |.      ^        | | |   .                                       ~
   ~ |.......|........|.|.|....                                       ~
   ~ |  ASAP |    ASAP| | |ASAP                                       ~
   ~ |(d)    |(c)     | | |                                           ~
   ~ |       v        v v v                                           ~
   ~ |   *********   +++++++++++++++                                  ~
   ~ + ->* PU(X) *   + ENRP server +                                  ~
   ~     *********   +++++++++++++++                                  ~
   ~         ^     ASAP     ^                                         ~
   ~         |     <-(b)    |                                         ~
   ~         +--------------+                                         ~
   ~               (a)->                                              ~
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

               Architecture for RSerPool aware client.

                                Figure 6

   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



Tuexen, et al.           Expires August 24, 2005               [Page 14]


Internet-Draft    Architecture for Reliable Server Pooling February 2005


       ASAP layer would send an ASAP request to its ENRP server to
       request the list of pool elements (using (a)).  The pool handle
       to identify the pool would be "File Transfer Pool".  The ASAP
       layer queues the login request.

   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
       transmits the login request, the other FTP control data finally
       starts the transmission of the requested files (using (c)).  For
       this the multiple stream feature of SCTP could be used.

   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
       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)
       would be made to the ENRP server to request a cache update for
       the server pool "File Transfer Pool" and a report would also be
       made that PE(1,B) is non-responsive (this would cause appropriate
       audits that may remove PE(1,B) from the pool if the ENRP server
       had not already detected the failure) (using (a)).


3.1.2  The RSerPool Unaware Client

   In this example we investigate the use of a Proxy server assuming the
   same set of scenario as illustrated above.

   In this example the steps will occur:

   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
       (e)).

   2.  The proxy behaves like a client and performs the actions
       described under (1), (2) and (3) of the above description (using
       (a), (b) and (c)).

   3.  The ftp communication continues and will be translated by the
       proxy into the RSerPool aware dialect.  This interworking uses
       (f) and (c).

   Note that in this example high availability is maintained between the
   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 and its one IP address it is using for commands.




Tuexen, et al.           Expires August 24, 2005               [Page 15]


Internet-Draft    Architecture for Reliable Server Pooling February 2005


   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   ~                                                operational scope ~
   ~  .........................                                       ~
   ~  . "file transfer pool"  .                                       ~
   ~  .  +-------+ +-------+  .                                       ~
   ~  .  |PE(1,A)| |PE(1,C)|  .                                       ~
   ~  .  +-------+ +-------+  .                                       ~
   ~  .      ^            ^   .                                       ~
   ~  .      +----------+ |   .                                       ~
   ~  .  +-------+      | |   .                                       ~
   ~  .  |PE(1,B)|<---+ | |   .                                       ~
   ~  .  +-------+    | | |   .                                       ~
   ~  .......^........|.|.|....                                       ~
   ~         |        | | |                                           ~
   ~         |    ASAP| | |ASAP                                       ~
   ~         |        | | |                                           ~
   ~         |        v v v                                           ~
   ~         |       +++++++++++++++          +++++++++++++++         ~
   ~         |       + ENRP server +<--ENRP-->+ ENRP server +         ~
   ~         |       +++++++++++++++          +++++++++++++++         ~
   ~         |                                ASAP   ^                ~
   ~         |     ASAP       (c)                (b) |  ^             ~
   ~         +---------------------------------+  |  |  |             ~
   ~                                           |  v  | (a)            ~
   ~                                           v     v                ~
   ~         :::::::::::::::::     (e)->     *****************        ~
   ~         :   FTP client  :<------------->* proxy/gateway *        ~
   ~         :::::::::::::::::     (f)       *****************        ~
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                Architecture for RSerPool unaware client.

                                Figure 7


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



Tuexen, et al.           Expires August 24, 2005               [Page 16]


Internet-Draft    Architecture for Reliable Server Pooling February 2005


   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
   for high availability of a telephony application such as a Voice over
   IP Gateway Controller (GWC) and Gatekeeper services (GK).

   In this example, we show two different scenarios of deploying these
   services using RSerPool in order to illustrate the flexibility of the
   RSerPool architecture.



Tuexen, et al.           Expires August 24, 2005               [Page 17]


Internet-Draft    Architecture for Reliable Server Pooling February 2005


3.3.1  Decomposed GWC and GK Scenario

   In this scenario, both GWC and GK services are deployed as separate
   pools with some number of PEs, as shown in the following diagram.
   Each of the pools will register their unique pool handle with the
   ENRP server.  We also assume that there are a Signaling Gateway (SG)
   and a Media Gateway (MG) present and both are RSerPool aware.

                              ...................
                              .    gateway      .
                              . controller pool .
       .................      .   +-------+     .
       .   gatekeeper  .      .   |PE(2,A)|     .
       .     pool      .      .   +-------+     .
       .   +-------+   .      .   +-------+     .
       .   |PE(1,A)|   .      .   |PE(2,B)|     .
       .   +-------+   .      .   +-------+     .
       .   +-------+   . (d)  .   +-------+     .
       .   |PE(1,B)|<------------>|PE(2,C)|<-------------+
       .   +-------+   .      .   +-------+     .        |
       .................      ........^..........        |
                                      |                  |
                                   (c)|               (e)|
                                      |                  v
           +++++++++++++++        *********       *****************
           + ENRP server +        * SG(X) *       * media gateway *
           +++++++++++++++        *********       *****************
                  ^                   ^
                  |                   |
                  |     <-(a)         |
                  +-------------------+
                         (b)->

               Deployment of Decomposed GWC and GK.

                                Figure 9

   As shown in the previous figure, the following sequence takes place:

   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 request to its "local" ENRP server to request the list of
       pool elements (PE's) of GWC (using (a)).  The key used for this
       query is the pool handle of the GWC.  The ASAP layer queues the
       data to be sent to the GWC in local buffers until the ENRP server
       responds.

   2.  the ENRP server would return a list of the three PE's A, B and C



Tuexen, et al.           Expires August 24, 2005               [Page 18]


Internet-Draft    Architecture for Reliable Server Pooling February 2005


       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
       send the signaling message to it (using (c)).  The selection is
       based on the load sharing information of the gateway controller
       pool.

   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
       information in its local cache (e.g., obtained and stored from
       recent query to ENRP server), PE(2,C) selects PE(1,B) and sends
       the call control message to it (using (d)).

   5.  We assume PE(1,B) responds back to PE(2,C) and authorizes the
       call to proceed.

   6.  PE(2,C) issues media control commands to the Media Gateway (using
       (e)).

   RSerPool will provide service robustness to the system if some
   failure would occur in the system.

   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,
   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
   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)
   through (likely) the endpoint unreachability detection by the
   transport protocol beneath ASAP and automatically deliver the re-sent
   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
   able to correctly handle the call and reply to PE(2, C) and hence
   progress the call.

3.3.2  Collocated GWC and GK Scenario

   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
   pool that provides both GWC and GK services as shown in the figure
   below.

   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
   selected by SG).




Tuexen, et al.           Expires August 24, 2005               [Page 19]


Internet-Draft    Architecture for Reliable Server Pooling February 2005


        ........................................
        .  gateway controller/gatekeeper pool  .
        .                  +-------+           .
        .                  |PE(3,A)|           .
        .                  +-------+           .
        .           +-------+                  .
        .           |PE(3,C)|<---------------------------+
        .           +-------+                  .         |
        .    +-------+  ^                      .         |
        .    |PE(3,B)|  |                      .         |
        .    +-------+  |                      .         |
        ................|.......................         |
                        |                                |
                        +-------------+                  |
                                      |                  |
                                   (c)|               (e)|
                                      v                  v
           +++++++++++++++        *********       *****************
           + ENRP server +        * SG(X) *       * media gateway *
           +++++++++++++++        *********       *****************
                  ^                   ^
                  |                   |
                  |     <-(a)         |
                  +-------------------+
                         (b)->

               Deployment of Collocated GWC and GK.

                               Figure 10


4.  Security Considerations

   The RSerPool protocol must allow us to secure the RSerPool
   infrastructure.  There are security and privacy issues that relate to
   the handle space, pool element registration and user queries of the
   handle space.  In [2] a complete threat analysis of RSerPool
   components is presented.

5.  Acknowledgements

   The authors would like to thank Bernard Aboba, Phillip Conrad, Harrie
   Hazewinkel, Matt Holdrege, Lyndon Ong, Christopher Ross, Maureen
   Stillman, Werner Vogels and many others for their invaluable comments
   and suggestions.






Tuexen, et al.           Expires August 24, 2005               [Page 20]


Internet-Draft    Architecture for Reliable Server Pooling February 2005


6.  References

6.1  Normative References

   [1]  Bradner, S., "The Internet Standards Process -- Revision 3",
        BCP 9, RFC 2026, October 1996.

   [2]  Stillman, M., "Threats Introduced by Rserpool and Requirements
        for Security in response to  Threats",
        Internet-Draft draft-ietf-rserpool-threats-04, January 2005.

   [3]  Loughney, J., "Comparison of Protocols for Reliable Server
        Pooling", Internet-Draft draft-ietf-rserpool-comp-08, July 2004.

6.2  Informative References

   [4]  Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
        September 1981.

   [5]  Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9,
        RFC 959, October 1985.

   [6]  Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
        Location Protocol, Version 2", RFC 2608, June 1999.

   [7]  Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L.,
        Lin, H., Juhasz, I., Holdrege, M. and C. Sharp, "Framework
        Architecture for Signaling Transport", RFC 2719, October 1999.

   [8]  Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
        H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
        "Stream Control Transmission Protocol", RFC 2960, October 2000.

   [9]  Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney,
        J. and M. Stillman, "Requirements for Reliable Server Pooling",
        RFC 3237, January 2002.


Authors' Addresses

   Michael Tuexen (editor)
   Muenster Univ. of Applied Sciences
   Stegerwaldstr. 39
   48565 Steinfurt
   Germany

   Email: tuexen@fh-muenster.de




Tuexen, et al.           Expires August 24, 2005               [Page 21]


Internet-Draft    Architecture for Reliable Server Pooling February 2005


   Qiaobing Xie
   Motorola, Inc.
   1501 W. Shure Drive, #2309
   Arlington Heights, IL  60004
   USA

   Phone: +1-847-632-3028
   Email: qxie1@email.mot.com


   Randall R. Stewart
   Cisco Systems, Inc.
   8725 West Higgins Road
   Suite 300
   Chicago, IL  60631
   USA

   Phone: +1-815-477-2127
   Email: rrs@cisco.com


   Melinda Shore
   Cisco Systems, Inc.
   809 Hayts Rd
   Ithaca, NY  14850
   USA

   Phone: +1 607 272 7512
   Email: mshore@cisco.com


   John Loughney
   Nokia Research Center
   PO Box 407
   FIN-00045 Nokia Group  FIN-00045
   Finland

   Email: john.loughney@nokia.com













Tuexen, et al.           Expires August 24, 2005               [Page 22]


Internet-Draft    Architecture for Reliable Server Pooling February 2005


   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










































Tuexen, et al.           Expires August 24, 2005               [Page 23]


Internet-Draft    Architecture for Reliable Server Pooling February 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   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
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   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
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING 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.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Tuexen, et al.           Expires August 24, 2005               [Page 24]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/