draft-ietf-rserpool-arch-00.txt   draft-ietf-rserpool-arch-01.txt 
skipping to change at page 1, line 15 skipping to change at page 1, line 15
Q. Xie Q. Xie
Motorola Motorola
R. Stewart R. Stewart
M. Shore M. Shore
Cisco Cisco
L. Ong L. Ong
Point Reyes Networks Point Reyes Networks
J. Loughney J. Loughney
M. Stillman M. Stillman
Nokia Nokia
Expires October 2, 2001 April 2, 2001 Expires September 1, 2002 March 1, 2002
Architecture for Reliable Server Pooling Architecture for Reliable Server Pooling
<draft-ietf-rserpool-arch-00.txt> <draft-ietf-rserpool-arch-01.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 3, line 37 skipping to change at page 3, line 37
SCTP: Stream Control Transmission Protocol SCTP: Stream Control Transmission Protocol
TCP: Transmission Control Protocol TCP: Transmission Control Protocol
2. Reliable Server Pooling Architecture 2. Reliable Server Pooling Architecture
In this section, we discuss what a typical reliable server pool In this section, we discuss what a typical reliable server pool
architecture may look like. architecture may look like.
2.1. Common RSerPool Functional Areas 2.1. RSerPool Functional Components
The following functional areas or components may likely be present in a There are three classes of entities in the RSerPool architecture:
typical RSerPool system architecture:
- A number of logical "Server Pools" to provide distinct - Pool Elements (PEs).
application services.
Each of those server pools will likely be composed of some - Name Servers, also called ENRP Servers.
number of "Pool Elements (PEs)" - which are application
programs running on distributed host machines, collectively
providing the desired application services via, for example,
data sharing and/or load sharing.
Each server pool will be identifiable in the operation scope - Pool Users (PUs).
of the system by a unique "name".
- Some "Pool Users (PUs)" which are the users of the application A server pool is defined as a set of one or more servers providing the
services provided by the various server pools. same application functionality. These servers are called Pool Elements
(PEs). Using multiple PEs in a server pool can be for fault tolerance or
load sharing, for example.
- PEs may or may not be PU, depending on whether or not they Each server pool will be identifiable by a unique name which is simply
wish to access other pools in the operation scope of the an ASCII string, called the pool handle. To fulfill the performance
system. requirements given in [RFC3237] these names are not valid in the whole
Internet but only in smaller parts, called the operational scope. Also,
the namespace is flat.
- A "Name Space" which contains all the defined names within the The second class of entities in the RSerPool architecture is the class
operation scope of the system. of the so called name servers. These name servers can resolve a pool
handle to a list of transport layer end-point addresses of PEs of the
server pool identified by the handle.
- One or more "Name Servers" which carry out various maintenance Editors note: Should we talk about UDP, TCP, SCTP specifically?
functions (e.g., registration and de-registration, integrity
checking) for the "Name Space". In each operational scope there must be at least one name server. Most
likely there will be more than one. All these servers have the complete
knowledge about all server pools in the operational scope. The name
servers use a protocol called Endpoint Name Resolution Protocol (ENRP)
to communication which each other to make sure that all have the same
information about the server pools.
A client being served by a PE of a server pool is called a Pool User
(PU). This is the third class of entities in the RSerPool architecture.
The PU wants to be served by a PE of a particular server pool it must
know the pool handle of the server pool. The PU then uses the Aggregate
Server Access Protocol (ASAP) to query for transport layer addresses of
PEs belonging to the server pool identified by the pool handle.
[RFC3237] also requires that the name servers should not resolve a pool
handle to a transport layer address of a PE which is not in operation.
Therefore each PE is supervised by one specific name server, called the
home ENRP server of that PE. If it detects that the PE is out of service
all other name servers are informed by using ENRP.
ASAP is also used by a server to join or leave a server pool. It
registers or deregisters itself by communicating with a name server,
which will normally the the home ENRP server.
2.2. RSerPool Protocol Overview 2.2. RSerPool Protocol Overview
The RSerPool requested features can be obtained with the help of two The RSerPool requested features can be obtained with the help of two
protocols: ENRP (Endpoint Name Resolution Protocol) and ASAP (Aggregate protocols: ENRP (Endpoint Name Resolution Protocol) and ASAP (Aggregate
Server Access Protocol). Server Access Protocol).
ENRP is designed to provide a fully distributed fault-tolerant real-time ENRP is designed to provide a fully distributed fault-tolerant real-time
translation service that maps a name to a set of transport addresses translation service that maps a name to a set of transport addresses
pointing to a specific group of networked communication endpoints pointing to a specific group of networked communication endpoints
skipping to change at page 14, line 14 skipping to change at page 14, line 14
[RFC2608] E. Guttman et al., "Service Location Protocol, Version 2", [RFC2608] E. Guttman et al., "Service Location Protocol, Version 2",
RFC 2608, June 1999. RFC 2608, June 1999.
[RFC2719] L. Ong et al., "Framework Architecture for Signaling [RFC2719] L. Ong et al., "Framework Architecture for Signaling
Transport", RFC 2719, October 1999. Transport", RFC 2719, October 1999.
[RFC2960] R. R. Stewart et al., "Stream Control Transmission [RFC2960] R. R. Stewart et al., "Stream Control Transmission
Protocol", RFC 2960, November 2000. Protocol", RFC 2960, November 2000.
[RFC3237] M. Tuexen et al., "Requirements for Reliable Server
Pooling", RFC 3237, January 2002.
6. Authors' Addresses 6. Authors' Addresses
Michael Tuexen Tel.: +49 89 722 47210 Michael Tuexen Tel.: +49 89 722 47210
Siemens AG e-mail: Michael.Tuexen@icn.siemens.de Siemens AG e-mail: Michael.Tuexen@icn.siemens.de
ICN WN CS SE 51 ICN WN CS SE 51
D-81359 Munich D-81359 Munich
Germany Germany
Qiaobing Xie Tel.: +1 847 632 3028 Qiaobing Xie Tel.: +1 847 632 3028
Motorola, Inc. e-mail: qxie1@email.mot.com Motorola, Inc. e-mail: qxie1@email.mot.com
skipping to change at page 15, line 17 skipping to change at page 15, line 17
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 September 1, 2002.
 End of changes. 

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