One document matched: draft-tuexen-rserpool-reqts-00.txt

Network Working Group                                          M. Tuexen
INTERNET DRAFT                                                Siemens AG
expires April 20, 2001                                  October 20, 2000


                Requirements for Reliable Server Pooling
                  <draft-tuexen-rserpool-reqts-00.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 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 requirements and architecture for management and
access to server pools, including requirements from a variety of
applications, building blocks and interfaces, different styles of
pooling, security requirements and performance requirements such as
failover times and coping with heterogeneous latencies.

Important requirements of this architecture are

     -    network fault tolerance,

     -    host fault tolerance,




Tuexen                                                          [Page 1]
Internet Draft  Requirements for Reliable Server Pooling   November 2000


     -    resistance against malicious attacks,

     -    and scalability.

1.  Introduction

1.1.  Overview

This document defines the requirements of the reliable server pooling
architecture and the protocol used.  Reliable server pools can be used
for providing high available services by using a set of servers in a
pool.

Therefore fault tolerance is very important. Real time applications must
also be supported which leads to requirements on the processing time
needed. Scalability is another important requirement.

Given that the server pool can be attacked by hackers, if one or more of
the servers are hijacked then the server pool is compromised.
Therefore, the security requirement is to catalog the threats to the
reliable server pool and identify appropriate responses to those
threats.

1.2.  Terminology

     Pool:
          A collection of clients or servers providing the same service.

     Pool Element:
          A client or server which belongs to a pool.

1.3.  Abbreviations

     SCTP: Stream Control Transmission Protocol

     TCP:  Transmission Control Protocol

2.  General Requirements

The general architecture should be based on a peer to peer basis.
However, the binding should be based on a client server model.

It should be possible to use the protocol stack in small devices, like
cellular phones. Therefore it should be possible to have lightweight
implementations that are able to operate with the servers.

Furthermore, it is expected that there is a transition phase with some
systems are supporting the rserpool architecture and some are not. To



Tuexen                                                          [Page 2]
Internet Draft  Requirements for Reliable Server Pooling   November 2000


make this transition as seamless as possible it should be possible for
hosts not supporting this architecture to use also the new pooling based
services via some mechanism.

There is also another transition process: it should be possible to adopt
existing services to the new architecture to make use of the better
services. The impact on existing protocols should be limited. Candidates
for these services may be the adaptation layers developed in the SIGTRAN
group and described in [RFC2719].

Another important requirement is that servers should be able to enter or
leave the pool transparently without an interruption in service.

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

Using this protocols it should be possible to implement an IP-based
service without a single point of failure. This includes network
failures and host failures. Especially, an IP-address is considered as a
single point of failure. Therefore namespaces have to be used.

3.  Namespaces and Pools

Services are provided to the clients through a pool of servers.  Clients
will access these servers by name.  Selection of a server in the pool
will be performed on behalf of the client.  The name resolution results
in access to one specific server out of a pool of servers.  The
selection of the server is transparent to the client and is governed by
server pool policy.

Servers are registered by name in a namespace to join a server pool.
There will be no globally unique namespace available, so multiple
independent namespaces must be supported.

Since it is necessary to support multiple namespaces, it should also be
possible for a host to refer to entities in namespaces the host does not
belong to.
     Editors note: Really? What about the proxies?
It must also be possible for a host to be registered in more than one
namespace or using multiple names in one namespace.

A namespace can consist of a great number of pools. This is important
since the system will be used for real time applications. So handling of
name resolution has to be fast.  Another consequence of the real time



Tuexen                                                          [Page 3]
Internet Draft  Requirements for Reliable Server Pooling   November 2000


requirement is the supervision on the pool entities. The name resolution
should not result in a pool element which is not able to provide the
required service.

The registration and deregistration process is a dynamic one.  It must
be possible for hosts to register in a pool without affecting the other
elements of a pool. This will be used for example, if a pool is under
high load and more servers are installed to provide the service of the
pool. It must also be possible to remove host from a pool without
affecting the rest.
     Editors Note: Make clear if we can use DNS or not!

4.  Server selection

Services are provided by a pool of servers. If a client wants to connect
to a server one of the servers of the pool has to be chosen. This
functionality is called server selection.  This selection is based on
the server pooling policy.

Server selection is driven by server pool policy.  Some examples of
selection policies are load balancing and round robin. The set of
supported policies should be extensible in the sense that new policies
can be added as required.

The server selection should not be based on internal features of the
underlying transport protocol. This means, for example, in the case of
SCTP that only the state of associations will be taken into account and
not the state of the paths of the associations.

For specific applications it can be important that a client use a server
of a pool, which was used before.  Therefore the clients must be able to
get handles of a server and to use this handle later in the server
selection to connect to the same server again, if it is still possible.

5.  Reliability aspects

Host failures are handled by the pool concept. If one pool element fails
and there are other pool elements which are able to provide the service
than the other pool elements will be used.

Transaction failover is not provided by reliable server pooling.  If a
host fails during processing of a transaction this transaction may be
lost. Some services may provide a way to handle the failure, but this is
not guaranteed.

Network failures have to be handled by the underlying transport
protocol. This means that the transport layer protocol must provide at
least a acknowledged error-free non-duplicated transfer data delivery



Tuexen                                                          [Page 4]
Internet Draft  Requirements for Reliable Server Pooling   November 2000


service. Furthermore for fulfilling realtime requirements it may be
necessary that the transport layer also provides network fault tolerance
like the usage of multihoming in SCTP.

6.  Security aspects

Security is a major point of this architecture. There are several
aspects which have to be considered:

-    The transport layer protocol used should support concepts for
     dealing with denial of service attacks.

-    It should not be possible for a host to register unauthorized in a
     pool.

-    It should not be possible for a host to deregister another host
     from a pool.

-    It should not be possible to attack the name resolution system.

-    The client-server relation should be based on an authentication.

-    It should be possible to encrypt the communication between the
     client and the host.
          Editors note: should the encryption be done at the application
          layer or at the transport layer.  I think it should not be
          done at the rserpool layer.

7.  Acknowledgements

The author would like to thank the members of the rserpool discussion
list, especially Maureen Stillman, for their valuable comments and
suggestions.

8.  References

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

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

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




Tuexen                                                          [Page 5]
Internet Draft  Requirements for Reliable Server Pooling   November 2000


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





              This Internet Draft expires April 20, 2001.






































Tuexen                                                          [Page 6]