draft-ietf-rserpool-reqts-03.txt   rfc3237.txt 
Network Working Group M. Tuexen Network Working Group M. Tuexen
INTERNET DRAFT Siemens AG Request for Comments: 3237 Siemens AG
Q. Xie Category: Informational Q. Xie
Motorola Motorola
R. Stewart R. Stewart
M. Shore M. Shore
Cisco Cisco
L. Ong L. Ong
Ciena Ciena
J. Loughney J. Loughney
M. Stillman M. Stillman
Nokia Nokia
Expires November 9, 2001 May 9, 2001 January 2002
Requirements for Reliable Server Pooling Requirements for Reliable Server Pooling
<draft-ietf-rserpool-reqts-03.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This memo provides information for the Internet community. It does
provisions of Section 10 of [RFC2026]. not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
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 Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2002). All Rights Reserved.
http://www.ietf.org/shadow.html.
Abstract Abstract
The goal of Reliable Server Pooling (RSerPool) is to develop an This document defines a basic set of requirements for reliable server
architecture and protocols for the management and operation of server pooling.
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 The goal of Reliable Server Pooling (RSerPool) is to develop an
pooling. 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. Introduction
1.1. Overview 1.1. Overview
The Internet is always on. Many users expect services to be always The Internet is always on. Many users expect services to be always
available; many businesses depend upon connectivity 24 hours a day, 7 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 days a week, 365 days a year. In order to fulfill this level of
performance, many proprietary solutions and operating system dependent performance, many proprietary solutions and operating system
solutions have been developed to provide highly reliable and highly dependent solutions have been developed to provide highly reliable
available servers. and highly available servers.
This document defines requirements for an architecture and protocols This document defines requirements for an architecture and protocols
enabling pooling of servers to support high reliability and availability enabling pooling of servers to support high reliability and
for applications. availability for applications.
The range of applications that can benefit from reliable server pooling The range of applications that can benefit from reliable server
includes both mobile and real-time applications. Reliable server pooling pooling includes both mobile and real-time applications. Reliable
mechanisms will be designed to support functionality for flexible server pooling mechanisms will be designed to support functionality
pooling such as registration and deregistration, and load balancing of for flexible pooling such as registration and deregistration, and
traffic across the server pool. Mechanisms will need to balance the load balancing of traffic across the server pool. Mechanisms will
needs of scalability, overhead traffic and response time to changes in need to balance the needs of scalability, overhead traffic and
pool status, as discussed below. response time to changes in pool status, as discussed below.
1.2. Terminology 1.2. Terminology
This document uses the following terms: This document uses the following terms:
Operation scope: Operation scope:
The part of the network visible to pool users by a specific The part of the network visible to pool users by a specific
instance of the reliable server pooling protocols. instance of the reliable server pooling protocols.
Pool (or server pool): Pool (or server pool):
A collection of servers providing the same application A collection of servers providing the same application
functionality. functionality.
Pool handle (or pool name): Pool handle (or pool name):
A logical pointer to a pool. Each server pool will be A logical pointer to a pool. Each server pool will be
identifiable in the operation scope of the system by a unique identifiable in the operation scope of the system by a unique
pool handle or "name". pool handle or "name".
Pool element: Pool element:
A server entity having registered to a pool. A server entity having registered to a pool.
Pool user: Pool user:
A server pool user. A server pool user.
Pool element handle (or endpoint handle): Pool element handle (or endpoint handle):
A logical pointer to a particular pool element in a pool, A logical pointer to a particular pool element in a pool,
consisting of the name of the pool and one or more destination consisting of the name of the pool and one or more destination
transport addresses for the pool element. transport addresses for the pool element.
Name space: Name space:
A cohesive structure of pool names and relations that may be A cohesive structure of pool names and relations that may be
queried by an internal or external agent. queried by an internal or external agent.
Name server: Name server:
Entity which is responsible for managing and maintaining the Entity which is responsible for managing and maintaining the
name space within the RSerPool operation scope. name space within the RSerPool operation scope.
RSerPool: RSerPool:
The architecture and protocols for reliable server pooling. The architecture and protocols for reliable server pooling.
1.3. Abbreviations 1.3. Abbreviations
PE: Pool element PE: Pool element
PU: Pool user PU: Pool user
SCTP: Stream Control Transmission Protocol SCTP: Stream Control Transmission Protocol
TCP: Transmission Control Protocol TCP: Transmission Control Protocol
2. Requirements 2. Requirements
2.1. Robustness 2.1. Robustness
The solution must allow itself to be implemented and deployed in such a The solution must allow itself to be implemented and deployed in such
way that there is no single point of failure in the system. a way that there is no single point of failure in the system.
2.2. Failover Support 2.2. Failover Support
The RSerPool architecture must be able to detect failure of pool The RSerPool architecture must be able to detect failure of pool
elements and name servers supporting the pool, and support failover to elements and name servers supporting the pool, and support failover
available alternate resources. to available alternate resources.
2.3. Communication Model 2.3. Communication Model
The general architecture should support flexibility of the communication The general architecture should support flexibility of the
model between pool users and pool elements, especially allowing for a communication model between pool users and pool elements, especially
peer-to-peer relationship to support some applications. allowing for a peer-to-peer relationship to support some
applications.
2.4. Processing Power 2.4. Processing Power
It should be possible to use the protocol stack in small devices, like It should be possible to use the protocol stack in small devices,
handheld wireless devices. The solution must scale to devices with a like handheld wireless devices. The solution must scale to devices
differing range of processing power. with a differing range of processing power.
2.5. Transport Protocol 2.5. Transport Protocol
The protocols used for the pool handling should not cause network The protocols used for the pool handling should not cause network
congestion. This means that it should not generate heavy traffic, even congestion. This means that it should not generate heavy traffic,
in case of failures, and has to use flow control and congestion even in case of failures, and has to use flow control and congestion
avoidance algorithms which are interoperable with currently deployed avoidance algorithms which are interoperable with currently deployed
techniques, especially the flow control of TCP [RFC793] and SCTP techniques, especially the flow control of TCP [RFC793] and SCTP
[RFC2960]. [RFC2960] and must be compliant with [RFC2914].
The architecture should not rely on multicast capabilities of the The architecture should not rely on multicast capabilities of the
underlying layer. Nevertheless, it can make use of it if multicast underlying layer. Nevertheless, it can make use of it if multicast
capabilities are available. capabilities are available.
Network failures have to be handled and concealed from the application Network failures have to be handled and concealed from the
layer as much as possible by the transport protocol. This means that the application layer as much as possible by the transport protocol.
underlying transport protocol must provide a strong network failure This means that the underlying transport protocol must provide a
handling capability on top of an acknowledged error-free non-duplicated strong network failure handling capability on top of an acknowledged
data delivery service. The failure of a network element must be handled error-free non-duplicated data delivery service. The failure of a
by the transport protocol in such a way that the timing requirements are network element must be handled by the transport protocol in such a
still fulfilled. way that the timing requirements are still fulfilled.
2.6. Support of RSerPool Unaware Clients 2.6. Support of RSerPool Unaware Clients
The architecture should allow for ease of interaction between pools and The architecture should allow for ease of interaction between pools
non-RSerPool-aware clients. However, it is assumed that only RSerPool- and non-RSerPool-aware clients. However, it is assumed that only
aware participants will receive maximum timing and notification benefits RSerPool-aware participants will receive maximum timing and
the architecture offers. notification benefits the architecture offers.
2.7. Registering and Deregistering 2.7. Registering and Deregistering
Another important requirement is that servers should be able to register Another important requirement is that servers should be able to
to (become PEs) and deregister from a server pool transparently without register to (become PEs) and deregister from a server pool
an interruption in service. This means that after a PE has transparently without an interruption in service. This means that
deregistered, it will continue to serve PUs which started their after a PE has deregistered, it will continue to serve PUs which
connection before the deregistration of the PE. New connections will be started their connection before the deregistration of the PE. New
directed towards an alternative PE. connections will be directed towards an alternative PE.
Servers should be able to register in multiple server pools which may Servers should be able to register in multiple server pools which may
belong to different namespaces. belong to different namespaces.
2.8. Naming 2.8. Naming
Server pools are identified by pool handles. These pool handles are only Server pools are identified by pool handles. These pool handles are
valid inside the operation scope. Interoperability between different only valid inside the operation scope. Interoperability between
namespaces has to be provided by other mechanisms. different namespaces has to be provided by other mechanisms.
2.9. Name Resolution 2.9. Name Resolution
The name resolution should not result in a pool element which is not The name resolution should not result in a pool element which is not
operational. This might be important for fulfilling the timing operational. This might be important for fulfilling the timing
requirements described below. requirements described below.
2.10. Server Selection 2.10. Server Selection
The RSerPool mechanisms must be able to support different server The RSerPool mechanisms must be able to support different server
selection mechanisms. These are called server pool policies. selection mechanisms. These are called server pool policies.
Examples of server pool policies are: Examples of server pool policies are:
- Round Robin - Round Robin
- Least used - Least used
- Most used - Most used
The set of supported policies must be extensible in the sense that new The set of supported policies must be extensible in the sense that
policies can be added as required. Non-stochastic and stochastic new policies can be added as required. Non-stochastic and stochastic
policies can be supported. policies can be supported.
There must be a way for the client to provide operational status There must be a way for the client to provide operational status
feedback to the name server about the pool elements. feedback to the name server about the pool elements.
The name server protocols must be extensible to allow more refined The name server protocols must be extensible to allow more refined
server selection mechanisms to be implemented as they are developed in server selection mechanisms to be implemented as they are developed
the future. in the future.
For some applications it is important that a client repeatedly connects For some applications it is important that a client repeatedly
to the same server in a pool if it is possible, i. e., if that server is connects to the same server in a pool if it is possible, i.e., if
still alive. This feature should be supported through the use of pool that server is still alive. This feature should be supported through
element handles. the use of pool element handles.
2.11. Timing Requirements and Scaling 2.11. Timing Requirements and Scaling
Handling of name resolution must be fast to support real-time Handling of name resolution must be fast to support real-time
applications. Moreover, the name space should reflect pool membership applications. Moreover, the name space should reflect pool
changes to the client application as rapidly as possible, i.e., not membership changes to the client application as rapidly as possible,
waiting until the client application next reconnects. i.e., not waiting until the client application next reconnects.
The architecture should support control of timing parameters based on The architecture should support control of timing parameters based on
specific needs, e.g., of an application or implementation. specific needs, e.g., of an application or implementation.
In order to support more rapid and accurate response, the requirements In order to support more rapid and accurate response, the
on scalability of the mechanism are limited to server pools consisting requirements on scalability of the mechanism are limited to server
of a suitably large but not Internet-wide number of elements, as pools consisting of a suitably large but not Internet-wide number of
necessary to support bounded delay in handling real-time name elements, as necessary to support bounded delay in handling real-time
resolution. name resolution.
Also, there is no requirement to support hierarchical organization of Also, there is no requirement to support hierarchical organization of
name servers for scalability. Instead, it is envisioned that the set of name servers for scalability. Instead, it is envisioned that the set
name servers supporting a particular pool is organized as a flat space of name servers supporting a particular pool is organized as a flat
of equivalent servers. Accordingly, the impact of relatively frequent space of equivalent servers. Accordingly, the impact of relatively
updates to ensure accurate reflection of the status of pool elements is frequent updates to ensure accurate reflection of the status of pool
limited to the set of name servers supporting a specific pool. elements is limited to the set of name servers supporting a specific
pool.
2.12. Scalability 2.12. Scalability
The RSerPool architecture should not require a limitation on the number The RSerPool architecture should not require a limitation on the
of server pools or on the number of pool users, although the size of an number of server pools or on the number of pool users, although the
individual pool may be limited by timing requirements as defined above. size of an individual pool may be limited by timing requirements as
defined above.
2.13. Security Requirements 2.13. Security Requirements
2.13.1. General 2.13.1. General
- The scaling characteristics of the security architecture - The scaling characteristics of the security architecture should be
should be compatible with those given previously. compatible with those given previously.
- The security architecture should support hosts having a wide - The security architecture should support hosts having a wide range
range of processing powers. of processing powers.
2.13.2. Name Space Services 2.13.2. Name Space Services
- It must not be possible for an attacker to falsely register as - It must not be possible for an attacker to falsely register as a
a pool element with the name server either by masquerading as pool element with the name server either by masquerading as
another pool element or by registering in violation of local another pool element or by registering in violation of local
authorization policy. authorization policy.
- It must not be possible for an attacker to deregister a server - It must not be possible for an attacker to deregister a server
which has successfully registered with the name server. which has successfully registered with the name server.
- It must not be possible for an attacker to spoof the response - It must not be possible for an attacker to spoof the response to a
to a query to the name server query to the name server
- It must be possible to protect the privacy of queries to the - It must be possible to protect the privacy of queries to the name
name server and responses to those queries from the name server and responses to those queries from the name server.
server.
- Communication among name servers must be afforded the same - Communication among name servers must be afforded the same
protections as communication between clients and name servers. protections as communication between clients and name servers.
2.13.3. Security State 2.13.3. Security State
The security context of an application is a subset of the overall The security context of an application is a subset of the overall
context, and context or state sharing is explicitly out-of-scope for context, and context or state sharing is explicitly out-of-scope for
RSerPool. Because RSerPool does introduce new security vulnerabilities RSerPool. Because RSerPool does introduce new security
to existing applications application designers employing RSerPool should vulnerabilities to existing applications application designers
be aware of problems inherent in failing over secured connections. employing RSerPool should be aware of problems inherent in failing
Security services necessarily retain some state and this state may have over secured connections. Security services necessarily retain some
to be moved or re-established. Examples of this state include state and this state may have to be moved or re-established.
authentication or retained ciphertext for ciphers operating in cipher Examples of this state include authentication or retained ciphertext
block chaining (CBC) or cipher feedback (CFB) mode. These problems must for ciphers operating in cipher block chaining (CBC) or cipher
be addressed by the application or by future work on RSerPool. feedback (CFB) mode. These problems must be addressed by the
application or by future work on RSerPool.
3. Acknowledgements 3. Security Considerations
The authors would like to thank Bernard Aboba, Matt Holdrege, Eliot Security issues are discussed in section 2.13.
Lear, Christopher Ross, Werner Vogels and many others for their
invaluable comments and suggestions.
4. References 4. Acknowledgements
[RFC793] J. B. Postel, "Transmission Control Protocol", RFC 793, The authors would like to thank Bernard Aboba, Matt Holdrege, Eliot
September 1981. Lear, Christopher Ross, Werner Vogels and many others for their
invaluable comments and suggestions.
[RFC959] J. B. Postel, J. Reynolds, "File Transfer Protocol (FTP)", 5. References
RFC 959, October 1985.
[RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
RFC 2026, October 1996. 793, September 1981.
[RFC2608] E. Guttman et al., "Service Location Protocol, Version 2", [RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)",
RFC 2608, June 1999. STD 9, RFC 959, October 1985.
[RFC2719] L. Ong et al., "Framework Architecture for Signaling [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
Transport", RFC 2719, October 1999. 3", BCP 9, RFC 2026, October 1996.
[RFC2960] R. R. Stewart et al., "Stream Control Transmission [RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
Protocol", RFC 2960, November 2000. Location Protocol, Version 2", RFC 2608, June 1999.
5. Authors' Addresses [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.
Michael Tuexen Tel.: +49 89 722 47210 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC
Siemens AG e-mail: Michael.Tuexen@icn.siemens.de 2914, September 2000.
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 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Cisco Systems, Inc. e-mail: rrs@cisco.com Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang,
24 Burning Bush Trail L. and V. Paxson, "Stream Control Transmission Protocol",
Crystal Lake, Il 60012 RFC 2960, November 2000.
USA
Melinda Shore Tel.: +1 607 272 7512 6. Authors' Addresses
Cisco Systems, Inc. e-mail: mshore@cisco.com
809 Hayts Rd
Ithaca, NY 14850
USA
Lyndon Ong Tel.: +1 408 366 3358 Michael Tuexen
Ciena e-mail: lyong@ciena.com Siemens AG
10480 Ridgeview Court ICN WN CS SE 51
Cupertino, CA 95014 D-81359 Munich
USA Germany
John Loughney Tel.: +358 40 749 9122 Phone: +49 89 722 47210
Nokia Research Center e-mail: john.loughney@nokia.com EMail: Michael.Tuexen@icn.siemens.de
PO Box 407
FIN-00045 Nokia Group
Finland
Maureen Stillman Tel.: +1 607 273 0724 62 Qiaobing Xie
Nokia e-mail: maureen.stillman@nokia.com Motorola, Inc.
127 W. State Street 1501 W. Shure Drive, #2309
Ithaca, NY 14850 Arlington Heights, Il 60004
USA USA
This Internet Draft expires November 9, 2001. 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
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
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.
 End of changes. 76 change blocks. 
235 lines changed or deleted 212 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/