As per Relevance of the word reliable, we have this rfc below:
Network Working Group M.
Request for Comments: 3237 Siemens
Category: Informational Q.
R.
M.
L.
J.
M.
January 2002
Requirements for Reliable Server
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This document defines a basic set of requirements for reliable
pooling
The goal of Reliable Server Pooling (RSerPool) is to develop
architecture and protocols for the management and operation of
pools supporting highly reliable applications, and for client
mechanisms to a server pool
1.
1.1.
The Internet is always on. Many users expect services to be
available; many businesses depend upon connectivity 24 hours a day, 7
days a week, 365 days a year. In order to fulfill this level
performance, many proprietary solutions and operating
dependent solutions have been developed to provide highly
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
enabling pooling of servers to support high reliability
availability for applications
The range of applications that can benefit from reliable
pooling includes both mobile and real-time applications.
server pooling mechanisms will be designed to support
for flexible pooling such as registration and deregistration,
load balancing of traffic across the server pool. Mechanisms
need to balance the needs of scalability, overhead traffic
response time to changes in pool status, as discussed below
1.2.
This document uses the following terms
Operation scope
The part of the network visible to pool users by a
instance of the reliable server pooling protocols
Pool (or server pool):
A collection of servers providing the same
functionality
Pool handle (or pool name):
A logical pointer to a pool. Each server pool will
identifiable in the operation scope of the system by a
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
transport addresses for the pool element
Name space
A cohesive structure of pool names and relations that may
queried by an internal or external agent
Name server
Entity which is responsible for managing and maintaining
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.
PE: Pool
PU: Pool
SCTP: Stream Control Transmission
TCP: Transmission Control
2.
2.1.
The solution must allow itself to be implemented and deployed in
a way that there is no single point of failure in the system
2.2. Failover
The RSerPool architecture must be able to detect failure of
elements and name servers supporting the pool, and support
to available alternate resources
2.3. Communication
The general architecture should support flexibility of
communication model between pool users and pool elements,
allowing for a peer-to-peer relationship to support
applications
2.4. Processing
It should be possible to use the protocol stack in small devices
like handheld wireless devices. The solution must scale to
with a differing range of processing power
2.5. Transport
The protocols used for the pool handling should not cause
congestion. This means that it should not generate heavy traffic
even in case of failures, and has to use flow control and
avoidance algorithms which are interoperable with currently
techniques, especially the flow control of TCP [RFC793] and
[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
underlying layer. Nevertheless, it can make use of it if
capabilities are available
Network failures have to be handled and concealed from
application layer as much as possible by the transport protocol
This means that the underlying transport protocol must provide
strong network failure handling capability on top of an
error-free non-duplicated data delivery service. The failure of
network element must be handled by the transport protocol in such
way that the timing requirements are still fulfilled
2.6. Support of RSerPool Unaware
The architecture should allow for ease of interaction between
and non-RSerPool-aware clients. However, it is assumed that
RSerPool-aware participants will receive maximum timing
notification benefits the architecture offers
2.7. Registering and
Another important requirement is that servers should be able
register to (become PEs) and deregister from a server
transparently without an interruption in service. This means
after a PE has deregistered, it will continue to serve PUs
started their connection before the deregistration of the PE.
connections will be directed towards an alternative PE
Servers should be able to register in multiple server pools which
belong to different namespaces
2.8.
Server pools are identified by pool handles. These pool handles
only valid inside the operation scope. Interoperability
different namespaces has to be provided by other mechanisms
2.9. Name
The name resolution should not result in a pool element which is
operational. This might be important for fulfilling the
requirements described below
2.10. Server
The RSerPool mechanisms must be able to support different
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
- Least
- Most
The set of supported policies must be extensible in the sense
new policies can be added as required. Non-stochastic and
policies can be supported
There must be a way for the client to provide operational
feedback to the name server about the pool elements
The name server protocols must be extensible to allow more
server selection mechanisms to be implemented as they are
in the future
For some applications it is important that a client
connects to the same server in a pool if it is possible, i.e.,
that server is still alive. This feature should be supported
the use of pool element handles
2.11. Timing Requirements and
Handling of name resolution must be fast to support real-
applications. Moreover, the name space should reflect
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
specific needs, e.g., of an application or implementation
In order to support more rapid and accurate response,
requirements on scalability of the mechanism are limited to
pools consisting of a suitably large but not Internet-wide number
elements, as necessary to support bounded delay in handling real-
name resolution
Also, there is no requirement to support hierarchical organization
name servers for scalability. Instead, it is envisioned that the
of name servers supporting a particular pool is organized as a
space of equivalent servers. Accordingly, the impact of
frequent updates to ensure accurate reflection of the status of
elements is limited to the set of name servers supporting a
pool
Tuexen, et al. Informational [Page 5]
RFC 3237 Requirements for Reliable Server Pooling January 2002
2.12.
The RSerPool architecture should not require a limitation on
number of server pools or on the number of pool users, although
size of an individual pool may be limited by timing requirements
defined above
2.13. Security
2.13.1.
- The scaling characteristics of the security architecture should
compatible with those given previously
- The security architecture should support hosts having a wide
of processing powers
2.13.2. Name Space
- It must not be possible for an attacker to falsely register as
pool element with the name server either by masquerading
another pool element or by registering in violation of
authorization policy
- It must not be possible for an attacker to deregister a
which has successfully registered with the name server
- It must not be possible for an attacker to spoof the response to
query to the name
- It must be possible to protect the privacy of queries to the
server and responses to those queries from the name server
- Communication among name servers must be afforded the
protections as communication between clients and name servers
2.13.3. Security
The security context of an application is a subset of the
context, and context or state sharing is explicitly out-of-scope
RSerPool. Because RSerPool does introduce new
vulnerabilities to existing applications application
employing RSerPool should be aware of problems inherent in
over secured connections. Security services necessarily retain
state and this state may have to be moved or re-established
Examples of this state include authentication or retained
Tuexen, et al. Informational [Page 6]
RFC 3237 Requirements for Reliable Server Pooling January 2002
for ciphers operating in cipher block chaining (CBC) or
feedback (CFB) mode. These problems must be addressed by
application or by future work on RSerPool
3. Security
Security issues are discussed in section 2.13.
4.
The authors would like to thank Bernard Aboba, Matt Holdrege,
Lear, Christopher Ross, Werner Vogels and many others for
invaluable comments and suggestions
5.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7,
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 --
3", BCP 9, RFC 2026, October 1996.
[RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "
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,
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'
Michael
Siemens
ICN WN CS SE 51
D-81359
Phone: +49 89 722 47210
EMail: Michael.Tuexen@icn.siemens.
Qiaobing
Motorola, Inc
1501 W. Shure Drive, #2309
Arlington Heights, Il 60004
Phone: +1 847 632 3028
EMail: qxie1@email.mot.
Randall
Cisco Systems, Inc
24 Burning Bush
Crystal Lake, Il 60012
Phone: +1 815 477 2127
EMail: rrs@cisco.
Melinda
Cisco Systems, Inc
809 Hayts
Ithaca, NY 14850
Phone: +1 607 272 7512
EMail: mshore@cisco.
Tuexen, et al. Informational [Page 8]
RFC 3237 Requirements for Reliable Server Pooling January 2002
Lyndon
10480 Ridgeview
Cupertino, CA 95014
Phone: +1 408 366 3358
EMail: lyong@ciena.
John
Nokia Research
PO Box 407
FIN-00045 Nokia
Phone: +358 50 483 6242
EMail: john.loughney@nokia.
Maureen
127 W. State
Ithaca, NY 14850
Phone: +1 607 273 0724 62
EMail: maureen.stillman@nokia.
Tuexen, et al. Informational [Page 9]
RFC 3237 Requirements for Reliable Server Pooling January 2002
7. Full Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Tuexen, et al. Informational [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
