rfc3237.txt

RFC 的详细文档！

Network Working Group                                          M. Tuexen
Request for Comments: 3237                                    Siemens AG
Category: Informational                                           Q. Xie
                                                                Motorola
                                                              R. Stewart
                                                                M. Shore
                                                                   Cisco
                                                                  L. Ong
                                                                   Ciena
                                                             J. Loughney
                                                             M. Stillman
                                                                   Nokia
                                                            January 2002


                Requirements for Reliable Server Pooling

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

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

   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.

1.  Introduction

1.1.  Overview

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




Tuexen, et al.               Informational                      [Page 1]

RFC 3237        Requirements for Reliable Server Pooling    January 2002


   This document defines requirements for an architecture and protocols
   enabling pooling of servers to support high reliability and
   availability for applications.

   The range of applications that can benefit from reliable server
   pooling includes both mobile and real-time applications.  Reliable
   server pooling mechanisms will be designed to support functionality
   for flexible pooling such as registration and deregistration, and
   load balancing of traffic across the server pool.  Mechanisms will
   need to balance the needs of scalability, overhead traffic and
   response time to 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 one or more destination
         transport 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 is responsible for managing and maintaining the
         name space within the RSerPool operation scope.




Tuexen, et al.               Informational                      [Page 2]

RFC 3237        Requirements for Reliable Server Pooling    January 2002


      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 support flexibility of the
   communication model between pool users and pool elements, especially
   allowing for a 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.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] and must be compliant with [RFC2914].




Tuexen, et al.               Informational                      [Page 3]

RFC 3237        Requirements for Reliable Server Pooling    January 2002


   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.6.  Support of RSerPool Unaware Clients

   The architecture should allow for ease of interaction between pools
   and non-RSerPool-aware clients.  However, it is assumed that only
   RSerPool-aware participants will receive maximum timing and
   notification benefits the 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 which
   started their connection before the deregistration of the PE.  New
   connections will be directed towards an alternative PE.

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

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.




Tuexen, et al.               Informational                      [Page 4]

RFC 3237        Requirements for Reliable Server Pooling    January 2002


   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.  Non-stochastic and stochastic
   policies can be supported.

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

   The name server protocols must be extensible to allow more refined
   server selection mechanisms to be implemented as 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.11.  Timing Requirements and Scaling

   Handling of name resolution must be fast to support real-time
   applications.  Moreover, the name space should reflect pool
   membership changes to the client application as rapidly as possible,
   i.e., not waiting until the client application next reconnects.

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

   In order to support more rapid and accurate response, the
   requirements on scalability of the mechanism are limited to server
   pools consisting of a suitably large but not Internet-wide number of
   elements, as necessary to support bounded delay in handling real-time
   name resolution.

   Also, there is no requirement to support hierarchical organization of
   name servers for scalability.  Instead, it is envisioned that the set
   of name servers supporting a particular pool is organized as a flat
   space of equivalent servers.  Accordingly, the impact of relatively
   frequent updates to ensure accurate reflection of the status of pool
   elements is limited to the set of name servers supporting a specific
   pool.




Tuexen, et al.               Informational                      [Page 5]