Subject: [Rserpool] proposed draft-ietf-rserpool-arch-01.txt

From: Erik Guttman <[email-masked]>
Date: Tue, 4 Sep 2001 20:16:24 +0200 (MET DST)

Folks,

Please see the attached document.  This is a proposed
new version of the architecture document.  Unlike it,
there is no mention of specific protocols - rather of
the functions the framework provides, its interfaces
and properties.  Needless to say it is quite different
than the -00 version.  

There is still work to do on illustrating the scenarios
section and providing realistic worked-out examples of
how real applications would run over RSERPOOL.

Please send comments,

Erik

Network Working Group                                          M. Tuexen
INTERNET DRAFT                                                Siemens AG
                                                                  Q. Xie
                                                                Motorola
                                                              R. Stewart
                                                                M. Shore
                                                                   Cisco
                                                                  L. Ong
                                                    Point Reyes Networks
                                                             J. Loughney
                                                             M. Stillman
                                                                   Nokia
                                                            Erik Guttman
                                                        Sun Microsystems
4 Sep 2001
Expires in six months

                  Reliable Server Pooling Architecture
                   <draft-ietf-rserpool-arch-01.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of [RFC2026].

   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.

Abstract

   The RSERPOOL framework supports client application access to server
   pools, significantly enhancing application reliability as well as
   allowing for the simplification of application implementations. The
   framework session layer services, mediating communication between
   applications and the transport layer.  The RSERPOOL architecture
   defines the functions and protocol interactions which support the
   features of this framework.

Tuexen, et al.           Expires: 4 March 2002                  [Page 1]

Internet Draft           RSERPOOL Architecture            September 2001

1.  Introduction

   The Internet is always on. Many users expect services to be always
   available; many business depend upon connectivity 24 hours a day, 7
   days a week, 365 days a year.  Reliability and responsiveness are
   increasingly important; time-critical applications deployed over IP
   networks have to scale successfully to service ever more clients.

   In order to provide highly reliable access to servers various
   solutions have been introduced into the network (to mediate
   communication) and to client-server protocols themselves.

   The RSERPOOL framework provides session layer facilities which allow
   for end-to-end robustness features such as load balancing,
   application fail-over and recovery from communication and even
   application layer failures.

   The RSERPOOL architecture defines the features and interactions
   present in the framework functions.  The architecture will be
   discussed in abstract terms, then concretely applied to various
   classes of standards track Internet application protocols.  This will
   highlight the interactions between layers - as they are today and as
   they will be in a system employing the RSERPOOL framework.  Scenarios
   for application of RSERPOOL will serve to illustrate the architecture
   in an operational context.

1.1.  Where we are today

   Server mirroring and load balancing functions, for example, may be
   introduced transparently to client-server protocols.  Mechanisms
   within the network (manipulating DNS or routing state) can provide
   applications with access to available servers even in the case of
   application or network failure.

   Additionally, in order to achieve robustness in the face of possible
   server failure, application protocol implementations are tightly
   coupled to transport interfaces.  When a client determines that
   communication fails, the client attempts to recover.  Establishing,
   maintaining, determining error conditions and recovering from error
   conditions (either application or lower layer failures) complicates
   protocol implementations and duplicates these functions.

1.2.  The RSERPOOL Framework

   The RSERPOOL Framework constitutes a session layer, mediating the
   application layer and the transport layer.  The primary service it
   offers to application is reliable, timely delivery of messages.

   Unlike the similar sounding transport layer service, RSERPOOL may
   deliver the application message to any suitable server.  That is, the
   transport association between client and server is removed, or rather

Tuexen, et al.           Expires: 4 March 2002                  [Page 2]

Internet Draft           RSERPOOL Architecture            September 2001

   managed by the RSERPOOL framework.  This frees the application
   implementation from all transport layer communication management such
   as connection establishment and termination, timers and failure
   detection, receiving messages asynchronously, and most importantly -
   failure recovery.

   The RSERPOOL framework also eliminates the need for intermediaries in
   the network to provide 'transparent' load balancing, application and
   transport health monitoring and so on.  This empowers end-to-end
   policies and communication management to maintain robust and scalable
   operation.  This is simpler to deploy in the long run, since the
   network infrastructure can be oblivious to the details of higher
   layer protocols, for which it simply provides best effort delivery
   services.

1.3.  Session Layer Service

   A session layer mediates communication between higher layer and lower
   layers.  In the case of Internet protocols, it sits between the
   application and transport layers.

   Applications using TCP and UDP transport have typically done their
   own 'session management' by establishing an association between
   client and server on the basis of network address and transport port
   identifiers.

   The application implementation must first obtain the network address
   of the server (using a configuration file, DNS [RFC1034] or SLP
   [RFC2068], for example), to establish a transport layer connection or
   association, to monitor this for errors or unacceptable delays.  In
   the case of transport failure, the application must determine a new
   server location and reestablish communication.

   In the OSI Reference Model, the session layer [IS8326] provides a
   number of services.  These are largely irrelevant to most Internet
   application protocols.  To avoid ambiguity in the use of the term
   RSERPOOL framework.

   The only features which RSERPOOL offers (in the sense of ISO session
   layers) are 'Kernel Functional Unit' services:  establishing logical
   client-server connections (possibly distinct from transport layer
   connections), transferring data and orderly release of resources.

   [NOTE:  To facilitate support application state context transfer some
   support for 'Activity Management' services may be worth considering.
   See Appendix A for more discussion.]

   Other (notoriously complicated and obscure) functions of the OSI
   session layer have no bearing on RSERPOOL:  session capability
   negociation, half-duplex support, exception reporting and
   synchronization.  In particular, no control tokens are exchanged or

Tuexen, et al.           Expires: 4 March 2002                  [Page 3]

Internet Draft           RSERPOOL Architecture            September 2001

   managed.

1.4. Classification of Application Protocols

   The RSERPOOL framework provides applications with reliable and
   efficient access to servers, potentially by accessing different
   servers over time.

   Some application protocols can operate in a stateless fashion,
   insensitive to which server the client exchanges messages with. Most
   application protocols, however, establish 'session state,' tightly
   associated with a particular client-server pair and their active
   transport layer connection (or in the case of UDP, their
   association).

   The following distinctions provide terminology needed for subsequent
   discussion of RSERPOOL implications for higher layer protocols.

   A 'stateless transaction protocol' relates a single request with a
   single response.  A client for such a protocol can obtain service
   from any server, in any order.  Examples are UDP queries to DNS
   [RFC1034] or SLP [RFC2608].

   A 'stateful transaction protocol' associates state on the client and
   server with lower layer (generally transport) associations.
   Communication must occur sequentially, as each interaction occurs in
   the context of previously exchanged messages.  For example, TFTP
   [RFC1350] associates a sequence of data blocks on for transmission on
   the sender side, and an incrementally reconstructed file on the
   receiver side.

   An 'explicit state transaction protocol' includes enough information
   in each application layer message that a server can interpret the
   message to establish sufficient state to respond.  For example, HTTP
   1.1 [RFC2616] includes a chunking facility, so that interrupted file
   transfer can be resumed in the case of failure, even if requests are
   handled by distinct servers with no need for state concerning the
   preceding client-server dialog.

   Some application protocols include lower layer identifiers which the
   IP address, transport port number or host name of the communicating
   party, it is impossible to redirect communication from a client to
   different servers.  FTP [RFC959] passive mode, for example, includes
   the client transport port for subsequent interaction.

1.5 Terminology
       Operation 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

Tuexen, et al.           Expires: 4 March 2002                  [Page 4]

Internet Draft           RSERPOOL Architecture            September 2001

          same 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 a unique pool handle or "name".

       Pool element (PE):  An application layer server entity having
          registered to a pool.

       Pool user (PU):  An application layer client, a server pool user.

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

       Name space:  A mapping from pool handles to pool element handles
          and associated properties.

       Name and Discovery Function:  A set of entities responsible for
          making available and maintaining the name space within the
          RSerPool operation scope.

2.  Reliable Server Pooling Architecture

   The RSERPOOL framework consists of the set of functions required to
   provide applications with robust and efficient sessions with members
   of a server pool.  The RSERPOOL architecture describes how these
   functions work and interact.

                                    +-----------+
                                    |\ - - - - - \
                   +-----------+    |.+-----------+
                   |  client   |    |.|server app |
                   |   app     |<-->+.|  (Pool    |
                   |(Pool User)|    |\| Endpoint) |
  +-----------+    +-----------+    +.+-----------+    +-----------+
->| RSERPOOL  |<-->| RSERPOOL  |<-->|\|  RSERPOOL |<-->| RSERPOOL  |<-
  +-----------+    +-----------+    +.+-----------+    +-----------+
->| Transport |<-->| Transport |<-->|\| Transport |<-->| Transport |<-
  +-----------+    +-----------+    +.+-----------+    +-----------+
->|    IP     |<-->|    IP     |<--> \|    IP     |<-->|    IP     |<-
  +-----------+    +-----------+      +-----------+    +-----------+
    Naming &         Client           Server (1..N)      Naming &
    Discovery                                            Discovery
    Function                                             Function

                       Figure 1:  RSERPOOL Framework

   In Figure 1, a client system relies on RSERPOOL to deliver messages
   to the server pool.  These messages are delivered to an individual

Tuexen, et al.           Expires: 4 March 2002                  [Page 5]

Internet Draft           RSERPOOL Architecture            September 2001

   servers member of the pool reliably and efficiently.

   The RSERPOOL layer has several functions:
   [F1] Discovery of RSERPOOL Naming & Discovery Function

         The RSERPOOL layer supporting the PU and the PE use a discovery
         protocol to determine the location of the RSERPOOL function
         servers.

   [F2]  Discovery of Pool Handle

         Based on a description or a service or application layer
         identifier, the Pool Handle and associated properties of a pool
         can be retrieved.

   [F3]  Name Resolution of Pool Handle to obtain Pool Endpoints

         Based on a Pool Handle, the RSERPOOL layer can obtain
         associated Pool Endpoint Handles and other associated
         properties from the Naming & Discovery Function.

   [F4]  Registration of a Pool Endpoint associated with a Pool Handle

         A PE can register itself with the Naming & Discovery Function.
         This is a soft state registration, with an associated lifetime.
         The registration must be renewed before it expires.

   [F5]  Deregistration of a Pool Endpoint associated with a Pool Handle

         A PE can deregister itself with the Naming & Discovery
         Function.  This updates the Name space in a timely way.  If
         Deregistration fails to occur, the soft state registration will
         time out on its own, eventually.  In the worst case, the PU
         will determine that a PE is unreachable and recover
         automatically.

   [F6]  Maintain Session

         The RSERPOOL association between the PU and the PE is
         maintained irresepective of whether active exchange of
         application messages occurs.  This is done on a timely basis so
         that failures will be detected early.

         It is possible that the PU may maintain multiple transport
         layer connections, either to the same PE or different PEs.
         This will provide fault tolerance to lower layer failures.

   [F7]  Notify Endpoint Failure

         RSERPOOL session layers which fail to communicate with a
         corresponding session layer (due to lower layer failure) will

Tuexen, et al.           Expires: 4 March 2002                  [Page 6]

Internet Draft           RSERPOOL Architecture            September 2001

         inform the Naming & Discovery Function.  This will aid in
         providing timely information to PUs regarding the reachability
         of PEs.

   [F8]  Transfer data

         Messages are transferred as an atomic unit between RSERPOOL
         session layers.  If a message tranmission fails due to a lower
         layer failure, the session layer will attempt to deliver it to
         another functionally equivalent endpoint.  Data is sent and
         delivered asynchronously with respect to application clients
         and servers.  Note that this does not preclude a synchronous
         API between the application and session layer.

   [F9]  Application Notification of Errors and other Events

         Upon failure to obtain a Pool Handle, Pool Handle Endpoints, or
         to deliver a message, the RSERPOOL session layer will notify
         the PU or PE of an error.

   [F10] Synchronization of Name Space

         The Naming and Discovery Function is logically a consistent
         distribute database.  The Name space must be kept consistent
         among servers implementing this function. Events which alter
         the database state (such as registrations) must be distributed
         in a timely and robust fashion.  That is the purpose of the
         communication arcs on the extreme left and right of Figure 1.

   The detail of these functions and the interactions between the layers
   are discussed in the following subsections.

2.1.  Application interface with RSERPOOL Framework

   The Application interface must expose the features required by the
   client (PU) and server (PE) entities.  An important dimension to the
   interface is what it hides, that is, what RSERPOOL is doing
   transparently to the application.

2.1.1. The application layer interface to RSERPOOL

   From the perspective of a PU the following functions are required.
   Note that from the perspective of a PU, servers are dealt with via
   the pool handle, the PU itself has no notion of a pool element
   handle.

    - Discover pool handle given service name or description

      This is analogous to service discovery, though instead of
      discovering a service location, one discovers a pool handle
      associated with a set of service locations (PEs).  This request

Tuexen, et al.           Expires: 4 March 2002                  [Page 7]

Internet Draft           RSERPOOL Architecture            September 2001

      could be implemented asynchronously, in which case, an application
      could receive notification of pool handles as they become
      available.

    - Send application data to pool handle

      This is a reliable, asynchronous transmission request.  The
      application does not have to control or monitor the transport
      layer operations which will be associated with this request.

    - Receive application data from pool handle

      When asynchronously received data is received from the pool which
      the request, the application obtains it through this interface.

    - Receive error notification from RSERPOOL layer

      When an error occurs due to one of the previous requests, the PU
      is notified.

   From the point of view of a PE the following interfaces are needed.
   A PE listens for requests from a pool handle.  These requests are
   associated with a pool element handle - which is used for the Respond
   interface below.

    - Discover pool handle given service name or description

      This is important for a PE so that it can join an existing pool
      even if it does not have a priori knowledge of the associated pool
      handle.

    - Accept application data to pool handle

      The PE listens for requests sent to a server in the identified
      pool.  The request is associated with an opaque identifier
      representing the pool element handle of the requester.  The actual
      pool endpoint handle is managed by the RSERPOOL layer and not
      exposed to the PE.

    - Respond to application data to pool element handle

      The PE responds to the requester through the use of an opaque
      requester identifier.

    - Register with Naming and Discovery Function

      The PE must register its presense and auxilliary data (if any).
      The RSERPOOL session layer manages the pool element handle for the
      PE, reregistration and soft state automatically.

    - Deregister with Naming and Discovery Function

Tuexen, et al.           Expires: 4 March 2002                  [Page 8]

Internet Draft           RSERPOOL Architecture            September 2001

      Remove the association of the PE with the pool handle from the
      Naming and Discovery Function.

   Further requirements for application context transfer are discussed
   in Appendix A.

2.1.2. Implications of transport and server endpoint transparency

   A PU cannot assume that messages will be received by the same PE over
   time.

   The RSERPOOL framework can be used for stateless transaction
   protocols and explicit state transaction protocols transparently,
   that is, without higher layer protocol modification.

   Stateful transaction protocols constitute the majority of application
   protocols.

2.1.2.1. Stateful Session Handles

   To support these, the simplest approach would be for the client
   application to establish a session which binds subsequent
   communication to a single server - for example, via the following PU
   interfaces:

    - Create Session

      Obtain a special pool handle for sending and receiving messages
      which is bound to a single session instance.

    - Free Session

      Free the session state associated with a session pool handle.

   There would need be no corresponding PE interface.  An exception
   notification would be sent from RSERPOOL to the PU in case the
   session failed (that is the PE did not respond).  Note that this
   session need not directly associated with a particular transport
   connection provided that the PE's 'Accept application data' can
   associated a particular PU session id which the PE can use to
   demultiplex the incoming data and associate it protocol transaction
   state.

2.1.2.2. Stateful Application Context Transfer

   Ideally, it should not matter which PE is used, from the perspective
   of the PU.  The only way this can be achieved for stateful
   transaction application protocols is through automatic context
   transfer between PEs.

   There may be no general solution to this problem, suitable for all

Tuexen, et al.           Expires: 4 March 2002                  [Page 9]

Internet Draft           RSERPOOL Architecture            September 2001

   application layer protocols.  One possibility is to adopt session
   layer primitives to assist in application layer state
   synchronization, which is discussed in Appendix A.

2.2.  RSERPOOL session layer functions and interactions

   The RSERPOOL session layer must include several functions in order to
   support the upper layer interfaces described in Section 2.1.

    - Pool handle to pool end point mapping cache

      Maintain a local cache (for performance reasons) of mappings
      between pool handles and pool endpoint handles.  This cache has to
      maintain at least loose consistency with the state registered with
      the Naming and Discovery Function.

    - Message delivery and enqueuing

      Incoming and outgoing messages will have to be stored for
      asynchronous delivery.

      Some timing parameters should be available so that the application
      can get notified if the message fails to be delivered in an
      appropriate period of time.

           +----------+                   +----------+
           |  App (A) | o                 |  App (B) | ^
           +----------+ | A               +----------+ | C
           | RSERPOOL | v   o-----------> | RSERPOOL | o
           +----------+       B           +----------+
                            <-----------x
                              D
               Figure 2:  Application Message Delivery Sequence

      In Figure A, App A could get notified if the message failed to be
      delivered (Arc B) by the RSERPOOL session layer or the application
      failed to process the message (Arc C).  This has implications for
      the session layer protocol, as the RSERPOOL session layer
      supporting App B would have to know the maximum time to enqueue
      the asynchronous message from A before signalling the failure (Arc
      D).

    - Discovery of Naming and Discovery Function

    - Registration, reregistration and deregistration of applications
      associated with pool handles

    - Load balancing functions

      The RSERPOOL session layer must implement policy for load
      balancing which it has been configured to use - such as round

Tuexen, et al.           Expires: 4 March 2002                 [Page 10]

Internet Draft           RSERPOOL Architecture            September 2001

      robin or server with the lowest load attribute first, etc.  (A PE
      could inform the RSERPOOL framework via an API of its load
      information.  This attribute of the PE could be registered with
      the Naming and Discovery Function.)

    - Managing Transport Connections and Timely Failover

      The RSERPOOL session layer must open and close transport
      connections to enable communication between endpoints.  In the
      case of a failure to deliver messages (due to lower layer
      communication errors or timeout), the session layer will initiate
      (or use an existing open alternative) transport connection for
      message delivery.

      Failure of a transport connection will have implications for the
      local pool handle cache as well as notify the Naming and Discovery
      Function of the error (see Section 2, F7).

2.3.  RSERPOOL Framework interface to transport layer

   The RSERPOOL session layer needs to make user of transport layer
   facilities so as to detect failures in a timely way.  The session
   layer may have to queue incoming messages for asynchronous delivery
   to the application layer.

   Applications which assume that a transport layer acknowledgement is
   synonymous with successful application layer processing of a message
   may need to be modified to support the session layer. The session
   layer

3.  Scenarios

   There are three major scenarios for RSERPOOL.

   1. Proxied client access to RSERPOOL enhanced services

      A proxied client uses an external application protocol to
      communicate with a server, which functions as a application layer
      gateway.  This server then acts on the client's behalf as a PU.

      Depending on whether the proxied protocol is stateless (or
      equivalently, has exlicit state) or on the other hand is stateful,
      scenario 2 or 3 applies for communications between the proxy PU
      and the server pool.

      [Add a diagram showing proxy access to RSERPOOL.]

   2. Reliable client-server access to stateless application services
         or explicit state transaction application services

      These applications can benefit from the RSERPOOL framework with no

Tuexen, et al.           Expires: 4 March 2002                 [Page 11]

Internet Draft           RSERPOOL Architecture            September 2001

      modification to the higher level protocol.  In fact, the interface
      to the session layer could conceivably be the same as that to the
      transport layer; namely providing message delivery semantics,
      albeit more robustly.

      [Add a diagram showing transparent support for stateless
      application services.]

   3. Reliable client-server access to stateful application services

      These applications could benefit from the RSERPOOL framework, but
      require modification on either the client-side, server-side or
      both.

      Client-side modifications are discussed in Section 2.1.2.1.  These
      entail fixing a PU-PE session for the duration of the dialog or
      until there is a failure. The modified client has to be ready to
      restart its session (that is initiate all necessary application
      state) with a new server if this session fails.

      Server-side modifications are discussed in Section 2.1.2.2.  The
      modifications here require that all PEs in the pool maintain
      equivalent session state for PUs.  That way, if a PU switches in
      the midst of a stateful protocol dialog, to communicate with a
      different PE, communication can continue from where the previous
      PE left off.

      There are many ways in which application state context transfer
      can be accomplished:  On-demand, where context is pulled when
      needed, or Proactive, where context is replicated continuously.
      This is a trade off of latency and use of network resources.

      The server-side modifications may be profound:  Most applications
      are not implemented so that client session state can be exported
      and imported, let alone efficiently.  There may also have to be
      corresponding client-side modifications needed, so that a session
      identifier corresponding to replicated server-side state will
      accompany communications.

      The session layer itself could facilitate server side state
      context transfer.  This is discussed in Appendix A.

3.1.  DNS Example

   [Show how DNS (stateless transaction) can be easily supported with
   RSERPOOL]

3.2.  FTP Example

   [Show what you would have to do to support FTP (with server side
   state replication!) as an example of stateful transaction protocol

Tuexen, et al.           Expires: 4 March 2002                 [Page 12]

Internet Draft           RSERPOOL Architecture            September 2001

   support via RSERPOOL]

   [Not sure about the Gateway examples:  They were interesting as
   motivation and examples but add much to the architecture discussion.]

4.  Security Considerations

   RSERPOOL alters the common binding of an application to a transport
   connection, of a client to a single server for the duration of
   communication.  The security implications of this architecture are
   explored elsewhere [Where?]

   A brief summary of threats introduced by this approach follows.

    - Service discovery

      If the discovery of a Naming and Discovery Function server could
      be prevented, RSERPOOL naming service functions would fail.

      The discovery of a pool handle from a service name or description
      could be the target of an attack.

      If discovery were prevented, a PU could fail to discover the
      service it needs.  A PE could fail to register with the
      appropriate pool handle.

    - Pool handle to Pool endpoint handle name resolution

      If this name resolution could be thwarted, communication from PU
      to PE would be impossible.

      If this name resolution could be attacked, incorrect information
      could be returned (for instance an attacker's PE instead of a
      legitimate one) or legitimate PEs could be obscured (not
      returned).

    - Registration, Deregistration and Reregistration

      Unless these functions are authenticated, it would be possible for
      an attacker to register illegitimate pool handle to pool element
      handle mappings or additional pool element properties.  An
      attacker could also deregister or alter a legitimately registered
      pool element entry.

    - Transport oriented security associations fails

      Security closely associated with an individual transport
      association will be broken by RSERPOOL since the application
      session to transport association is not necessarily one to one.

      For example, LDAP over SASL [RFC2829] assumes that a transport

Tuexen, et al.           Expires: 4 March 2002                 [Page 13]

Internet Draft           RSERPOOL Architecture            September 2001

      connection is established through an initial exchange of
      authentication messages, then continues with LDAP application
      protocol [RFC2251] messages.

    - Pairwise network oriented security associations fail

      Pairwise network security associations between communicating
      endpoints could be incompatible with RSERPOOL as it can shift the
      endpoints involved in an exchange of messages dynamically.

5.  Acknowledgements

   The authors would like to thank Bernard Aboba, Matt Holdrege,
   Christopher Ross, Werner Vogels and many others for their invaluable
   comments and suggestions.

Appendix A:  Application layer context transfer

   The OSI session layer has application communication state
   synchronization features.  These do not themselves store and forward
   higher layer protocol state.  Rather, they facilitate state
   coordination between communicating end points through a set of
   signals and tokens managed at the session layer.  Most of this
   process is obscure and overly complex.  However, some ideas can be
   derived from the 'Activity Management' function which may be useful.

    - Message transmission 'interrupt', 'resume' and 'abort' support

      A large message transmission - say several megabytes, could be
      initiated and then interrupted.  If the session layer of the
      receiving side had the ability to enqueue this data, the data
      transmission could be resumed later, if not abandoned due to a
      timeout or the sender informing the receiver to 'abort' the
      message transfer.

    - Grouping messages before processing them for atomic operations

      It could simplify application layer protocols if it could be
      determined that a group of messages sent were all successfully
      delivered.

   These mechanisms, together with appropriate APIs to the application
   layer could facilitate application data context transfer:  As
   activity_start, activity_end, activity_interrupt, activity_resume,
   activity_discard and asynchronous activity_notification (of error or
   success).

   A PE, for example, could replicate client state among other PEs of
   the same pool.  The entire state could be either transferred in one
   blob, or as a set of incremental updates.  The session layer would
   make this easy - either ensuring the large transfer or group of

Tuexen, et al.           Expires: 4 March 2002                 [Page 14]

Internet Draft           RSERPOOL Architecture            September 2001

   incremental updates eventually completes or informing the PE if this
   is not the case.

References

   [RFC793] J. B. Postel, "Transmission Control Protocol", RFC 793,
           September 1981.

   [RFC959] J. B. Postel, J. Reynolds, "File Transfer Protocol (FTP)",
           RFC 959, October 1985.

   [RFC1034] P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND FACILITIES",
           RFC 1034, November 1987.

   [RFC1350] K. R. Sollins, "THE TFTP PROTOCOL (REVISION 2)", RFC 1350,
           July 1992.

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

   [RFC2251] M. Wahl, et al., "Lightweight Directory Access
            Protocol (v3)", RFC 2251, December 1997.

   [RFC2608] E. Guttman et al., "Service Location Protocol, Version 2",
           RFC 2608, June 1999.

   [RFC2616] R. Fielding et al., "Hypertext Transfer Protocol --
           HTTP/1.1", RFC 2616, June 1999.

   [RFC2719] L. Ong et al., "Framework Architecture for Signaling
           Transport", RFC 2719, October 1999.

   [RFC2829] M. Wahl, et al., "Authentication Methods for LDAP", RFC
           2829, May 2000.

   [RFC2960] R. R. Stewart et al., "Stream Control Transmission
           Protocol", RFC 2960, November 2000.

Authors' Addressse

Michael Tuexen                Tel.:   +49 89 722 47210
Siemens AG                    e-mail: [email-masked]
ICN WN CS SE 51
D-81359 Munich
Germany

Qiaobing Xie                  Tel.:   +1 847 632 3028
Motorola, Inc.                e-mail: [email-masked]
1501 W. Shure Drive, #2309
Arlington Heights, Il 60004

Tuexen, et al.           Expires: 4 March 2002                 [Page 15]

Internet Draft           RSERPOOL Architecture            September 2001

USA

Randall Stewart               Tel.:   +1 815 477 2127
Cisco Systems, Inc.           e-mail: [email-masked]
24 Burning Bush Trail
Crystal Lake, Il 60012
USA

Melinda Shore                 Tel.:   +1 607 272 7512
Cisco Systems, Inc.           e-mail: [email-masked]
809 Hayts Rd
Ithaca, NY 14850
USA

Lyndon Ong                    Tel.:   +1 408 321 8237
Point Reyes Networks          e-mail: [email-masked]
1991 Concourse Drive
San Jose, CA
USA

John Loughney                 Tel.:
Nokia Research Center         e-mail: [email-masked]
PO Box 407
FIN-00045 Nokia Group
Finland

Maureen Stillman              Tel.:   +1 607 273 0724 62
Nokia                         e-mail: [email-masked]
127 W. State Street
Ithaca, NY 14850
USA

Erik Guttman                  Tel.:   +49 6227 356 202
Sun Microsystems              e-mail: [email-masked]
Eichhoelzelstr. 7
D-74915 Waibstadt
Germany

Tuexen, et al.           Expires: 4 March 2002                 [Page 16]

---

From: [email-masked]
Date: Wed, 5 Sep 2001 16:25:31 +0300

Hi Erik,

> and properties.  Needless to say it is quite different

I'll review it & comment on it.
 
> how real applications would run over RSERPOOL.

Even if I haven't read it, I'd like to suggest that we
don't go to far down that road - I think an applicability
statement is a better place for that.  Of course, we should
have some general discusson on how an application might 
want to use this architecture ...

John

_______________________________________________
rserpool mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/rserpool

---

From: "Sengodan Senthil (NRC/Boston)" <[email-masked]>
Date: Thu, 6 Sep 2001 08:54:30 -0500

Erik,

One aspect that is not clear from the document is the detection of
failure of a PE when that PE is not involved in a session with a PU.
When there is a session ongoing, the PU detects the failure ([F6] in the
doc) and notifies the naming/discovery function [F7]. But, when the PE
dies when a session is not ongoing, there are some approaches to
handling this, which were not clearly documented: (1) an entity performs
heartbeat monitoring of the PEs (2) the PE performs periodic
registration, and failure of a PE eventually results in a timeout of its
soft registration (3) Failure of a PE before its soft registration
expiry, may be detected by a PU attempting to connect to the PE. It
seems that the current architecture document does not cover case (1),
but covers cases (2) and (3) in an implied fashion. Is that right?

- Senthil

> -----Original Message-----
> From: ext Erik Guttman [mailto:[email-masked]]
> Sent: Tuesday, September 04, 2001 2:16 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Rserpool] proposed draft-ietf-rserpool-arch-01.txt
> 
> 
> 
> Folks,
>