GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3237

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:
  1. Round Robin
  1. Least used
  1. 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] RFC 3237 Requirements for Reliable Server Pooling January 2002

2.12. Scalability

 The RSerPool architecture should not require a limitation on the
 number of server pools or on the number of pool users, although the
 size of an individual pool may be limited by timing requirements as
 defined above.

2.13. Security Requirements

2.13.1. General

  1. The scaling characteristics of the security architecture should be

compatible with those given previously.

  1. The security architecture should support hosts having a wide range

of processing powers.

2.13.2. Name Space Services

  1. 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.
  1. It must not be possible for an attacker to deregister a server

which has successfully registered with the name server.

  1. It must not be possible for an attacker to spoof the response to a

query to the name server

  1. It must be possible to protect the privacy of queries to the name

server and responses to those queries from the name server.

  1. Communication among name servers must be afforded the same

protections as communication between clients and name servers.

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

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

 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. Security Considerations

 Security issues are discussed in section 2.13.

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

5. References

 [RFC793]  Postel, J., "Transmission Control Protocol", STD 7, RFC
           793, September 1981.
 [RFC959]  Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)",
           STD 9, RFC 959, October 1985.
 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
           3", BCP 9, RFC 2026, October 1996.
 [RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
           Location Protocol, Version 2", RFC 2608, June 1999.
 [RFC2719] 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.
 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC
           2914, September 2000.
 [RFC2960] 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, November 2000.

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

6. Authors' Addresses

 Michael Tuexen
 Siemens AG
 ICN WN CS SE 51
 D-81359 Munich
 Germany
 Phone:   +49 89 722 47210
 EMail: Michael.Tuexen@icn.siemens.de
 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 Stewart
 Cisco Systems, Inc.
 24 Burning Bush Trail
 Crystal Lake, Il 60012
 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

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

 Lyndon Ong
 Ciena
 10480 Ridgeview Court
 Cupertino, CA 95014
 USA
 Phone: +1 408 366 3358
 EMail: lyong@ciena.com
 John Loughney
 Nokia Research Center
 PO Box 407
 FIN-00045 Nokia Group
 Finland
 Phone: +358 50 483 6242
 EMail: john.loughney@nokia.com
 Maureen Stillman
 Nokia
 127 W. State Street
 Ithaca, NY 14850
 USA
 Phone: +1 607 273 0724 62
 EMail: maureen.stillman@nokia.com

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

7. Full Copyright Statement

 Copyright (C) The Internet Society (2002).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS 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.

Acknowledgement

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

Tuexen, et al. Informational [Page 10]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3237.txt · Last modified: 2002/01/22 23:05 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki