Network Working Group                                          M. Tuexen
INTERNET DRAFT                                                Siemens AG
                                                                  Q. Xie
                                                                Motorola
                                                              R. Stewart
                                                                M. Shore
                                                                   Cisco
                                                                  L. Ong
                                                    Point Reyes Networks
                                                                   Ciena
                                                             J. Loughney
                                                             M. Stillman
                                                                   Nokia
Expires October 2, November 9, 2001                                    April 2,                                     May 9, 2001

                Requirements for Reliable Server Pooling
                   <draft-ietf-rserpool-reqts-02.txt>
                   <draft-ietf-rserpool-reqts-03.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 goal of Reliable Server Pooling (RSerPool) is to develop 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.

This document defines a basic set of requirements for reliable server
pooling.

1.  Introduction

1.1.  Overview

The Internet is always on. Many users expect services to be always
available; many business businesses depend upon connectivity 24 hours a day, 7
days a week, 365 days a year. In order to fulfill this, this level of
performance, many proprietary solutions and operating system dependent
solutions have been developed to provide highly reliable and highly
available servers.

This document defines requirements for reliable server pooling.

Highly available services also put the same an architecture and protocols
enabling pooling of servers to support high reliability
requirements upon the transport layer protocol beneath RSerPool - it
must provide strong survivability in the face and availability
for applications.

The range of network component
failures.

Supporting real time applications is another main focus of RSerPool
which leads to requirements on the processing time needed.

Scalability is another important requirement.

RSerPool introduces new security vulnerabilities into existing
applications, that can benefit from reliable server pooling
includes both in the pool formation and pool member selection
process mobile and in the failover process.  Therefore, during the protocol
development process it real-time applications. Reliable server pooling
mechanisms will be necessary designed to catalogue support functionality for flexible
pooling such as registration and deregistration, and load balancing of
traffic across the threats server pool. Mechanisms will need to
RSerPool balance the
needs of scalability, overhead traffic and identify appropriate responses response time to those threats. changes in
pool status, as discussed below.

1.2.  Terminology

This document uses the following terms:

     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 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:
          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 name of the pool and a one or more destination
          transport
          address of addresses for the pool element.

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

     Name server:
          Entity which the is responsible for managing and maintaining the
          name space within the RSerPool operation scope.

     RSerPool:
          The architecture and protocols for reliable server pooling.

1.3.  Abbreviations

     PE:   Pool element

     PU:   Pool user

     SCTP: Stream Control Transmission Protocol

     TCP:  Transmission Control Protocol

2.  Requirements

2.1.  Robustness

The solution must allow itself to be implemented and deployed in such a
way that there is no single point of failure in the system.

2.2.  Failover Support

The RSerPool architecture must be able to detect failure of pool
elements and name servers supporting the pool, and support failover to
available alternate resources.

2.3.  Communication Model

The general architecture should be based on a peer to peer model.
However, support flexibility of the binding should be based on communication
model between pool users and pool elements, especially allowing for a client server model.

2.2.
peer-to-peer relationship to support some applications.

2.4.  Processing Power

It should be possible to use the protocol stack in small devices, like
handheld wireless devices. The solution must scale to devices with a
differing range of processing power.

2.3.

2.5.  Transport Protocol

The protocols used for the pool handling should not cause network
congestion. This means that it should not generate heavy traffic, even
in case of failures, and has to use flow control and congestion
avoidance algorithms which are interoperable with currently deployed
techniques, especially the flow control of TCP [RFC793] and SCTP
[RFC2960].  Therefore, for large pools, only a subset of all possible
IP-addresses are returned by the name servers.

The architecture should not rely on multicast capabilities of the
underlying layer. Nevertheless, it can make use of it if multicast
capabilities are available.

Network failures have to be handled and concealed from the application
layer as much as possible by the transport protocol. This means that the
underlying transport protocol must provide a strong network failure
handling capability on top of an acknowledged error-free non-duplicated
data delivery service.  The failure of a network element must be handled
by the transport protocol in such a way that the timing requirements are
still fulfilled.

2.4.

2.6.  Support of RSerPool Unaware Clients

Furthermore,

The architecture should allow for ease of interaction between pools and
non-RSerPool-aware clients. However, it is expected assumed that there only RSerPool-
aware participants will be a transition phase with
some systems supporting the RSerPool architecture receive maximum timing and some are not. To
make this transition as seamless as possible it should be possible for
hosts not supporting this architecture to use also notification benefits
the new pooling
services via some mechanism.

2.5. architecture offers.

2.7.  Registering and Deregistering

Another important requirement is that servers should be able to register
to (become PEs) and deregister from a server pool transparently without
an interruption in service.  This means that after a PE has
deregistered, it will continue to serve PUs, PUs which started the their
connection before the deregistration of the PE.  No PE will establish a
new connection with the deregistered PE, because other PE of the server
pool  New connections will be used.
directed towards an alternative PE.

Servers should be able to register in multiple server pools which may
belong to different namespaces.

2.6.

2.8.  Naming

Server pools are identified by pool handles. These pool handles are only
valid inside the operation scope. Interoperability between different
namespaces has to be provided by other mechanisms.

2.9.  Name Resolution

The name resolution should not result in a pool element which is not
operational. This might be important for fulfilling the timing
requirements described below.

2.10.  Server Selection

The RSerPool mechanisms must be able to support different server
selection mechanisms. These are called server pool policies.

Examples of server pool policies are:

     -    Round Robin

     -    Least used

     -    Most used

The set of supported policies must be extensible in the sense that new
policies can be added as required. added as required. Non-stochastic and stochastic
policies can be supported.

There must be a way for the client to provide information operational status
feedback to the name server about the pool elements.

The name servers should server protocols must be extensible using a plug-in architecture.
These plug-ins would provide a to allow more refined
server selection by the name
servers using additional information provided by clients mechanisms to be implemented as hints. they are developed in
the future.

For some applications it is important that a client repeatedly connects
to the same server in a pool if it is possible, i. e., if that server is
still alive. This feature should be supported through the use of pool
element handles.

2.7.

2.11.  Timing Requirements

A server pool can consist of a large number (up to 500) of pool
elements.  This upper limit is important since the system will be used
for real time applications. So handling and Scaling

Handling of name resolution has to must be
fast.

Another consequence of the real time requirement is the supervision of fast to support real-time
applications. Moreover, the pool elements. The name resolution space should not result in a reflect pool
element which is membership
changes to the client application as rapidly as possible, i.e., not operational.

2.8.  Failover Support
waiting until the client application next reconnects.

The RSerPool architecture must be able should support control of timing parameters based on
specific needs, e.g., of an application or implementation.

In order to detect server failure quickly support more rapid and be able accurate response, the requirements
on scalability of the mechanism are limited to perform failover without service interruption.

2.9.  Robustness

The solution must allow itself server pools consisting
of a suitably large but not Internet-wide number of elements, as

necessary to be implemented and deployed support bounded delay in such a
way that handling real-time name
resolution.

Also, there is no single point requirement to support hierarchical organization of failure in
name servers for scalability. Instead, it is envisioned that the system.

2.10.  Naming

Server pools are identified by pool handles. These set of
name servers supporting a particular pool handles are only
valid inside is organized as a flat space
of equivalent servers. Accordingly, the operation scope. Interoperability between different
namespaces has impact of relatively frequent
updates to be provided by other mechanisms.

2.11. ensure accurate reflection of the status of pool elements is
limited to the set of name servers supporting a specific pool.

2.12.  Scalability

The RSerPool architecture should not require a limitation on the number
of server pools or on the number of pool users.

2.12. users, although the size of an
individual pool may be limited by timing requirements as defined above.

2.13.  Security Requirements

2.12.1.

2.13.1.  General

     -    The scaling characteristics of the security architecture
          should be compatible with those given previously.

     -    The security architecture should support hosts having a wide
          range of processing powers.

2.12.2.

2.13.2.  Name Space Services

     -    It must not be possible for an attacker to falsely register as
          a pool element with the name server either by masquerading as
          another pool element or by registering in violation of local
          authorization policy.

     -    It must not be possible for an attacker to deregister a server
          which has successfully registered with the name server.

     -    It must not be possible for an attacker to spoof the response
          to a query to the name server

     -    It must be possible to prohibit unauthorized queries to the
          name server.

     -    It must be possible to protect the privacy of queries to the
          name server and responses to those queries from the name
          server.

     -    Communication among name servers must be afforded the same
          protections as communication between clients and name servers.

2.12.3.

2.13.3.  Security State

The security context of an application is a subset of the overall
context, and context or state sharing is explicitly out-of-scope for
RSerPool. Because RSerPool does introduce new security vulnerabilities
to existing applications application designers employing RSerPool should
be aware of problems inherent in failing over secured connections.
Security services necessarily retain some state and this state may have
to be moved or re-established. Examples of this state include
authentication or retained ciphertext for ciphers operating in cipher
block chaining (CBC) or cipher feedback (CFB) mode. These problems must
be addressed by the application or by future work on RSerPool.

3.  Acknowledgements

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

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

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

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

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

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

5.  Authors' Addresses

Michael Tuexen                Tel.:   +49 89 722 47210
Siemens AG                    e-mail: Michael.Tuexen@icn.siemens.de
ICN WN CS SE 51
D-81359 Munich
Germany

Qiaobing Xie                  Tel.:   +1 847 632 3028
Motorola, Inc.                e-mail: qxie1@email.mot.com
1501 W. Shure Drive, #2309
Arlington Heights, Il 60004
USA

Randall Stewart               Tel.:   +1 815 477 2127
Cisco Systems, Inc.           e-mail: rrs@cisco.com
24 Burning Bush Trail
Crystal Lake, Il 60012
USA

Melinda Shore                 Tel.:   +1 607 272 7512
Cisco Systems, Inc.           e-mail: mshore@cisco.com
809 Hayts Rd
Ithaca, NY 14850
USA

Lyndon Ong                    Tel.:   +1 408 321 8237
Point Reyes Networks 366 3358
Ciena                         e-mail: long@pointreyesnet.com
1991 Concourse Drive
San Jose, lyong@ciena.com
10480 Ridgeview Court
Cupertino, CA 95014
USA

John Loughney                 Tel.:   +358 40 749 9122
Nokia Research Center         e-mail: john.loughney@nokia.com
PO Box 407
FIN-00045 Nokia Group
Finland

Maureen Stillman              Tel.:   +1 607 273 0724 62
Nokia                         e-mail: maureen.stillman@nokia.com
127 W. State Street
Ithaca, NY 14850
USA

             This Internet Draft expires October 2, November 9, 2001.