draft-ietf-rserpool-reqts-02.txt   draft-ietf-rserpool-reqts-03.txt 
Network Working Group M. Tuexen Network Working Group M. Tuexen
INTERNET DRAFT Siemens AG INTERNET DRAFT Siemens AG
Q. Xie Q. Xie
Motorola Motorola
R. Stewart R. Stewart
M. Shore M. Shore
Cisco Cisco
L. Ong L. Ong
Point Reyes Networks Ciena
J. Loughney J. Loughney
M. Stillman M. Stillman
Nokia Nokia
Expires October 2, 2001 April 2, 2001 Expires November 9, 2001 May 9, 2001
Requirements for Reliable Server Pooling Requirements for Reliable Server Pooling
<draft-ietf-rserpool-reqts-02.txt> <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 document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of [RFC2026]. provisions of Section 10 of [RFC2026].
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
or to cite them other than as "work in progress." or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
The goal is to develop an architecture and protocols for the management The goal of Reliable Server Pooling (RSerPool) is to develop an
and operation of server pools supporting highly reliable applications, architecture and protocols for the management and operation of server
and for client access mechanisms to a server pool. pools supporting highly reliable applications, and for client access
mechanisms to a server pool.
This document defines a basic set requirements for reliable server This document defines a basic set of requirements for reliable server
pooling. pooling.
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 business depend upon connectivity 24 hours a day, 7 days available; many businesses depend upon connectivity 24 hours a day, 7
a week, 365 days a year. In order to fulfill this, many proprietary days a week, 365 days a year. In order to fulfill this level of
solutions and operating system dependent solutions have been developed performance, many proprietary solutions and operating system dependent
to provide highly reliable and highly available servers. 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 high reliability
requirements upon the transport layer protocol beneath RSerPool - it
must provide strong survivability in the face 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. This document defines requirements for an architecture and protocols
enabling pooling of servers to support high reliability and availability
for applications.
RSerPool introduces new security vulnerabilities into existing The range of applications that can benefit from reliable server pooling
applications, both in the pool formation and pool member selection includes both mobile and real-time applications. Reliable server pooling
process and in the failover process. Therefore, during the protocol mechanisms will be designed to support functionality for flexible
development process it will be necessary to catalogue the threats to pooling such as registration and deregistration, and load balancing of
RSerPool and identify appropriate responses to those threats. 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 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):
skipping to change at page 3, line 10 skipping to change at page 3, line 4
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 a destination transport consisting of the name of the pool and one or more destination
address of 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 the 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:
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. Communication Model 2.1. Robustness
The general architecture should be based on a peer to peer model. The solution must allow itself to be implemented and deployed in such a
However, the binding should be based on a client server model. way that there is no single point of failure in the system.
2.2. Processing Power 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 It should be possible to use the protocol stack in small devices, like
handheld wireless devices. The solution must scale to devices with a handheld wireless devices. The solution must scale to devices with a
differing range of processing power. differing range of processing power.
2.3. 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, even
in case of failures, and has to use flow control and congestion 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]. Therefore, for large pools, only a subset of all possible [RFC2960].
IP-addresses are returned by the name servers.
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 application
layer as much as possible by the transport protocol. This means that the layer as much as possible by the transport protocol. This means that the
underlying transport protocol must provide a strong network failure underlying transport protocol must provide a strong network failure
handling capability on top of an acknowledged error-free non-duplicated handling capability on top of an acknowledged error-free non-duplicated
data delivery service. The failure of a network element must be handled data delivery service. The failure of a network element must be handled
by the transport protocol in a way that the timing requirements are by the transport protocol in such a way that the timing requirements are
still fulfilled. still fulfilled.
2.4. Support of RSerPool Unaware Clients 2.6. Support of RSerPool Unaware Clients
Furthermore, it is expected that there will be a transition phase with The architecture should allow for ease of interaction between pools and
some systems supporting the RSerPool architecture and some are not. To non-RSerPool-aware clients. However, it is assumed that only RSerPool-
make this transition as seamless as possible it should be possible for aware participants will receive maximum timing and notification benefits
hosts not supporting this architecture to use also the new pooling the architecture offers.
services via some mechanism.
2.5. 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 register
to (become PEs) and deregister from a server pool transparently without to (become PEs) and deregister from a server pool transparently without
an interruption in service. This means that after a PE has an interruption in service. This means that after a PE has
deregistered, it will continue to serve PUs, which started the deregistered, it will continue to serve PUs which started their
connection before the deregistration of the PE. No PE will establish a connection before the deregistration of the PE. New connections will be
new connection with the deregistered PE, because other PE of the server directed towards an alternative PE.
pool will be used.
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.6. Server Selection 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 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 new
policies can be added as required. policies can be added as required. Non-stochastic and stochastic
policies can be supported.
There must be a way for the client to provide information to the name There must be a way for the client to provide operational status
server about the pool elements. feedback to the name server about the pool elements.
The name servers should be extensible using a plug-in architecture. The name server protocols must be extensible to allow more refined
These plug-ins would provide a more refined server selection by the name server selection mechanisms to be implemented as they are developed in
servers using additional information provided by clients as hints. the future.
For some applications it is important that a client repeatedly connects 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 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 still alive. This feature should be supported through the use of pool
element handles. element handles.
2.7. Timing Requirements 2.11. Timing Requirements and Scaling
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 of name resolution has to be
fast.
Another consequence of the real time requirement is the supervision of
the pool elements. The name resolution should not result in a pool
element which is not operational.
2.8. Failover Support
The RSerPool architecture must be able to detect server failure quickly Handling of name resolution must be fast to support real-time
and be able to perform failover without service interruption. 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.
2.9. Robustness The architecture should support control of timing parameters based on
specific needs, e.g., of an application or implementation.
The solution must allow itself to be implemented and deployed in such a In order to support more rapid and accurate response, the requirements
way that there is no single point of failure in the system. on scalability of the mechanism are limited to server pools consisting
of a suitably large but not Internet-wide number of elements, as
2.10. Naming necessary to support bounded delay in handling real-time name
resolution.
Server pools are identified by pool handles. These pool handles are only Also, there is no requirement to support hierarchical organization of
valid inside the operation scope. Interoperability between different name servers for scalability. Instead, it is envisioned that the set of
namespaces has to be provided by other mechanisms. 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.
2.11. 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 number
of server pools or on the number of pool users. 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.12. Security Requirements 2.13. Security Requirements
2.12.1. General 2.13.1. General
- The scaling characteristics of the security architecture - The scaling characteristics of the security architecture
should be compatible with those given previously. should be compatible with those given previously.
- The security architecture should support hosts having a wide - The security architecture should support hosts having a wide
range of processing powers. range of processing powers.
2.12.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 pool element with the name server either by masquerading as a 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 query to the name server 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 - It must be possible to protect the privacy of queries to the
name server and responses to those queries from the name 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.12.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 vulnerabilities
to existing applications application designers employing RSerPool should to existing applications application designers employing RSerPool should
be aware of problems inherent in failing over secured connections. be aware of problems inherent in failing over secured connections.
Security services necessarily retain some state and this state may have Security services necessarily retain some state and this state may have
to be moved or re-established. Examples of this state include to be moved or re-established. Examples of this state include
authentication or retained ciphertext for ciphers operating in cipher authentication or retained ciphertext for ciphers operating in cipher
block chaining (CBC) or cipher feedback (CFB) mode. These problems must block chaining (CBC) or cipher feedback (CFB) mode. These problems must
be addressed by the application or by future work on RSerPool. be addressed by the application or by future work on RSerPool.
3. Acknowledgements 3. Acknowledgements
The authors would like to thank Bernard Aboba, Matt Holdrege, The authors would like to thank Bernard Aboba, Matt Holdrege, Eliot
Christopher Ross, Werner Vogels and many others for their invaluable Lear, Christopher Ross, Werner Vogels and many others for their
invaluable comments and suggestions.
comments and suggestions.
4. References 4. References
[RFC793] J. B. Postel, "Transmission Control Protocol", RFC 793, [RFC793] J. B. Postel, "Transmission Control Protocol", RFC 793,
September 1981. September 1981.
[RFC959] J. B. Postel, J. Reynolds, "File Transfer Protocol (FTP)", [RFC959] J. B. Postel, J. Reynolds, "File Transfer Protocol (FTP)",
RFC 959, October 1985. RFC 959, October 1985.
[RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3",
skipping to change at page 8, line 11 skipping to change at page 8, line 23
24 Burning Bush Trail 24 Burning Bush Trail
Crystal Lake, Il 60012 Crystal Lake, Il 60012
USA USA
Melinda Shore Tel.: +1 607 272 7512 Melinda Shore Tel.: +1 607 272 7512
Cisco Systems, Inc. e-mail: mshore@cisco.com Cisco Systems, Inc. e-mail: mshore@cisco.com
809 Hayts Rd 809 Hayts Rd
Ithaca, NY 14850 Ithaca, NY 14850
USA USA
Lyndon Ong Tel.: +1 408 321 8237 Lyndon Ong Tel.: +1 408 366 3358
Point Reyes Networks e-mail: long@pointreyesnet.com Ciena e-mail: lyong@ciena.com
1991 Concourse Drive 10480 Ridgeview Court
San Jose, CA Cupertino, CA 95014
USA USA
John Loughney Tel.: John Loughney Tel.: +358 40 749 9122
Nokia Research Center e-mail: john.loughney@nokia.com Nokia Research Center e-mail: john.loughney@nokia.com
PO Box 407 PO Box 407
FIN-00045 Nokia Group FIN-00045 Nokia Group
Finland Finland
Maureen Stillman Tel.: +1 607 273 0724 62 Maureen Stillman Tel.: +1 607 273 0724 62
Nokia e-mail: maureen.stillman@nokia.com Nokia e-mail: maureen.stillman@nokia.com
127 W. State Street 127 W. State Street
Ithaca, NY 14850 Ithaca, NY 14850
USA USA
This Internet Draft expires October 2, 2001. This Internet Draft expires November 9, 2001.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/