draft-ietf-rserpool-arch-02.txt   draft-ietf-rserpool-arch-03.txt 
Network Working Group M. Tuexen Network Working Group M. Tuexen
INTERNET DRAFT Siemens AG Internet-Draft Siemens AG
Q. Xie Expires: November 30, 2002 Q. Xie
Motorola Motorola, Inc.
R. Stewart R. Stewart
M. Shore M. Shore
Cisco Cisco Systems, Inc.
L. Ong L. Ong
Point Reyes Networks Ciena Corporation
J. Loughney J. Loughney
Nokia Research Center
M. Stillman M. Stillman
Nokia Nokia
Expires October 24, 2002 April 24, 2002 June 2002
Architecture for Reliable Server Pooling Architecture for Reliable Server Pooling
<draft-ietf-rserpool-arch-02.txt> draft-ietf-rserpool-arch-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
provisions of Section 10 of [RFC2026]. all 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
Force (IETF), its areas, and its working groups. Note that other groups Task Force (IETF), its areas, and its working groups. Note that
may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference
or to cite them other than as "work in progress." material 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://
http://www.ietf.org/ietf/1id-abstracts.txt 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.
This Internet-Draft will expire on November 30, 2002.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
This document describes an architecture and protocols for the management This document describes an architecture and protocols for the
and operation of server pools supporting highly reliable applications, management and operation of server pools supporting highly reliable
and for client access mechanisms to a server pool. applications, and for client access mechanisms to a server pool.
[Editors note] This version is used as an input document for an Table of Contents
editors meeting and will updated shortly after that.
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . 4
2. Reliable Server Pooling Architecture . . . . . . . . . . . . 5
2.1 RSerPool Functional Components . . . . . . . . . . . . . . . 5
2.2 RSerPool Protocol Overview . . . . . . . . . . . . . . . . . 6
2.2.1 Endpoint Name Resolution Protocol . . . . . . . . . . . . . 6
2.2.2 Aggregate Server Access Protocol . . . . . . . . . . . . . . 6
2.2.3 PU <-> NS Communication . . . . . . . . . . . . . . . . . . 7
2.2.4 PE <-> NS Communication . . . . . . . . . . . . . . . . . . 7
2.2.5 PU <-> PE Communication . . . . . . . . . . . . . . . . . . 8
2.2.6 NS <-> NS Communication . . . . . . . . . . . . . . . . . . 9
2.2.7 PE <-> PE Communication . . . . . . . . . . . . . . . . . . 9
2.3 Failover Support . . . . . . . . . . . . . . . . . . . . . . 9
2.3.1 Testament . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.2 Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.3 Application level acknowledgements . . . . . . . . . . . . . 11
2.3.4 Business Cards . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Typical Interactions between RSerPool Components . . . . . . 11
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1 Two File Transfer Examples . . . . . . . . . . . . . . . . . 14
3.1.1 The RSerPool Aware Client . . . . . . . . . . . . . . . . . 15
3.1.2 The RSerPool Unaware Client . . . . . . . . . . . . . . . . 16
3.2 Telephony Signaling Example . . . . . . . . . . . . . . . . 17
3.2.1 Decomposed GWC and GK Scenario . . . . . . . . . . . . . . . 17
3.2.2 Collocated GWC and GK Scenario . . . . . . . . . . . . . . . 19
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
References . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 22
Full Copyright Statement . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
1.1. Overview 1.1 Overview
This document defines a proposed architecture, which can be used to This document defines a proposed architecture, which can be used to
provide highly available services. The way this is achieved is by using provide highly available services. The way this is achieved is by
servers grouped into pools. Therefore, if a client wants to access a using servers grouped into pools. Therefore, if a client wants to
server pool, it will be able to use any of the servers in the server access a server pool, it will be able to use any of the servers in
pool. Several server selection mechanisms, called server pool policies, the server pool. Several server selection mechanisms, called server
are supported. pool policies, are supported.
For accessing a server pool a flat system of name servers can be used. To access a server pool, the pool user consults a name server. The
The architecture of these name servers is also described in this name space for the server pools is flat, rather than hierachical. A
document. group of fault tolerant name servers are provided to resolve pool
name queries from the pools user.
1.2. Terminology 1.2 Terminology
This document uses the following terms: This document uses the following terms:
Operation scope: Home Name Server: The Name Server a Pool Element has registered with.
The part of the network visible to pool users by a specific This Name Server supervises the Pool Element.
instance of the reliable server pooling protocols.
Pool (or server pool): Operation scope: The part of the network visible to pool users by a
A collection of servers providing the same application specific instance of the reliable server pooling protocols.
functionality.
Pool handle (or pool name): Pool (or server pool): A collection of servers providing the same
A logical pointer to a pool. Each server pool will be application functionality.
identifiable in the operation scope of the system by a unique
pool handle or "name".
Pool element: Pool handle (or pool name): A logical pointer to a pool. Each server
A server entity having registered to a pool. pool will be identifiable in the operation scope of the system by
a unique pool handle or "name".
Pool user: Pool element: A server entity having registered to a pool.
A server pool user.
Pool element handle (or endpoint handle): Pool user: A server pool user.
A logical pointer to a particular pool element in a pool,
consisting of the name of the pool and a destination transport
address of the pool element.
Name space: Pool element handle (or endpoint handle): A logical pointer to a
A cohesive structure of pool names and relations that may be particular pool element in a pool, consisting of the name of the
queried by an internal or external agent. pool and a destination transport address of the pool element.
Name server: Name space: A cohesive structure of pool names and relations that may
Entity which the responsible for managing and maintaining the be queried by an internal or external agent.
name space within the RSerPool operation scope.
1.3. Abbreviations Name server: Entity which is responsible for managing and maintaining
the name space within the RSerPool operation scope.
1.3 Abbreviations
ASAP: Aggregate Server Access Protocol ASAP: Aggregate Server Access Protocol
ENRP: Endpoint Name Resolution Protocol ENRP: Endpoint Name Resolution Protocol
ES: ENRP Server Home NS: Home Name Server
NS: Name Server
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. Reliable Server Pooling Architecture 2. Reliable Server Pooling Architecture
In this section, we discuss what a typical reliable server pool In this section, we define a reliable server pool architecture.
architecture may look like.
2.1. RSerPool Functional Components 2.1 RSerPool Functional Components
There are three classes of entities in the RSerPool architecture: There are three classes of entities in the RSerPool architecture:
- Pool Elements (PEs). o Pool Elements (PEs).
- Name Servers, also called ENRP Servers (ESs).
- Pool Users (PUs).
A server pool is defined as a set of one or more servers providing the o Name Servers (NSs).
same application functionality. These servers are called Pool Elements
(PEs). Multiple PEs in a server pool can be used to provide fault
tolerance or load sharing, for example.
Each server pool will be identifiable by a unique name which is simply a o Pool Users (PUs).
byte string, called the pool handle.
[Editors note] Isn't a byte string more appropriate than an ASCII A server pool is defined as a set of one or more servers providing
string. the same application functionality. These servers are called Pool
Elements (PEs). PEs form the first class of entities in the RSerPool
architecture. Multiple PEs in a server pool can be used to provide
fault tolerance or load sharing, for example.
To fulfill the performance requirements given in [RFC3237] these names Each server pool will be identifiable by a unique name which is
are not valid in the whole Internet but only in smaller parts, called simply a byte string, called the pool handle. This allows binary
names to be used.
the operational scope. Also, the namespace is flat. These names are not valid in the whole internet but only in smaller
parts, called the operational scope. Furthermore, the namespace is
flat.
The second class of entities in the RSerPool architecture is the class The second class of entities in the RSerPool architecture is the
of the so called name servers. These name servers can resolve a pool class of the name servers. These name servers can resolve a pool
handle to a list of information which allows the PU to access a PE of handle to a list of information which allows the PU to access a PE of
the server pool identified by the handle. This information includes: the server pool identified by the handle. This information includes:
- A protocol field of the IP header specifying the upper layer o A list of IPv4 and/or IPv6 addresses.
o A protocol field of the IP header specifying the upper layer
protocol. protocol.
- A port number if the upper layer protocol is SCTP, TCP or UDP. o A port number if the upper layer protocol is SCTP, TCP or UDP.
In each operational scope there must be at least one name server. Most Please note that the RSerPool architecture supports both IPv4 and
likely there will be more than one. All these name servers have the IPv6 addressing. A PE can also support multiple transport layers.
complete knowledge about all server pools in the operational scope. The
name servers use a protocol called Endpoint Name Resolution Protocol In each operational scope there must be at least one name server.
(ENRP) for communication which each other to make sure that all have the Most likely there will be more than one. All these name servers have
same information about the server pools. The name servers are also the complete knowledge about all server pools in the operational
called ENRP servers. scope. The name servers use a protocol called Endpoint Name
Resolution Protocol (ENRP) for communication with 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 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. (PU). This is the third class of entities in the RSerPool
architecture.
If the PU wants to be served by a PE of a particular server pool it must If the PU wants to be served by a PE of a particular server pool it
know the pool handle of the server pool. The PU then uses the Aggregate must know the pool handle of the server pool. The PU then uses the
Server Access Protocol (ASAP) to query for transport layer addresses of Aggregate Server Access Protocol (ASAP) to query for transport layer
PEs belonging to the server pool identified by the pool handle. 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 RFC3237 [7] also requires that the name servers should not resolve a
handle to a transport layer address of a PE which is not in operation. pool handle to a transport layer address of a PE which is not in
Therefore each PE is supervised by one specific name server, called the operation. Therefore each PE is supervised by one specific name
home ENRP server of that PE. If it detects that the PE is out of service server, called the home NS of that PE. If it detects that the PE is
all other name servers are informed by using ENRP. 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 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, registers or deregisters itself by communicating with a name server,
which will normally the home ENRP server. which will normally the home NS.
2.2. RSerPool Protocol Overview
The RSerPool requested features can be obtained with the help of two 2.2 RSerPool Protocol Overview
protocols: ENRP (Endpoint Name Resolution Protocol) and ASAP (Aggregate
Server Access Protocol).
2.2.1. Endpoint Name Resolution Protocol The RSerPool requested features can be obtained with the help of the
combination of two protocols: ENRP (Endpoint Name Resolution
Protocol) and ASAP (Aggregate Server Access Protocol).
ENRP is designed to provide a fully distributed fault-tolerant real-time 2.2.1 Endpoint Name Resolution Protocol
translation service that maps a name to a set of transport addresses
pointing to a specific group of networked communication endpoints ENRP is designed to provide a fully distributed fault-tolerant real-
registered under that name. ENRP employs a client-server model with time translation service that maps a name to a set of transport
which an ENRP server will respond to the name translation service addresses pointing to a specific group of networked communication
requests from endpoint clients running on the same host or running on endpoints registered under that name. ENRP employs a client-server
different hosts. model with which an name server will respond to the name translation
service requests from endpoint clients running on the same host or
running on different hosts.
2.2.2. Aggregate Server Access Protocol 2.2.2 Aggregate Server Access Protocol
ASAP in conjunction with ENRP provides a fault tolerant data transfer ASAP in conjunction with ENRP provides a fault tolerant data transfer
mechanism over IP networks. ASAP uses a name-based addressing model mechanism over IP networks. ASAP uses a name-based addressing model
which isolates a logical communication endpoint from its IP address(es), which isolates a logical communication endpoint from its IP
thus effectively eliminating the binding between the communication address(es), thus effectively eliminating the binding between the
endpoint and its physical IP address(es) which normally constitutes a communication endpoint and its physical IP address(es) which normally
single point of failure. constitutes a single point of failure.
In addition, ASAP defines each logical communication destination as a In addition, ASAP defines each logical communication destination as a
server pool, providing full transparent support for server-pooling and server pool, providing full transparent support for server-pooling
load sharing. It also allows dynamic system scalability - members of a and load sharing. It also allows dynamic system scalability -
server pool can be added or removed at any time without interrupting the members of a server pool can be added or removed at any time without
service. interrupting the service.
2.2.3. PU <-> ES Communication 2.2.3 PU <-> NS Communication
The PU <-> ES communication is used for doing name queries. The PU sends The PU <-> NS communication is used for doing name queries. The PU
a pool handle to the ENRP server and gets back the information necessary sends a pool handle to the NS and gets back the information necessary
for accessing a server in a server pool. for accessing a server in a server pool.
******** ******** ******** ********
* PU * * ES * * PU * * NS *
******** ******** ******** ********
+------+ +------+ +------+ +------+
| ASAP | | ASAP | | ASAP | | ASAP |
+------+ +------+ +------+ +------+
| SCTP | | SCTP | | SCTP | | SCTP |
+------+ +------+ +------+ +------+
| IP | | IP | | IP | | IP |
+------+ +------+ +------+ +------+
Figure 1: Protocol stack between PU and ENRP server (SCTP variant)
If the PU does not use SCTP based services it may not be appropriate to Protocol stack between PU and NS (SCTP variant)
implement SCTP of PUs just to do the name queries. Therefore ASAP over
TCP can be used for doing the name queries. The protocol stack is shown If the PU does not use SCTP based services it may not be appropriate
in figure 2. to implement SCTP of PUs just to do the name queries. Therefore ASAP
over TCP can be used for doing the name queries. The protocol stack
is shown in the following figure.
******** ******** ******** ********
* PU * * ES * * PU * * NS *
******** ******** ******** ********
+------+ +------+ +------+ +------+
| ASAP | | ASAP | | ASAP | | ASAP |
+------+ +------+ +------+ +------+
| TCP | | TCP | | TCP | | TCP |
+------+ +------+ +------+ +------+
| IP | | IP | | IP | | IP |
+------+ +------+ +------+ +------+
Figure 2: Protocol stack between PU and ENRP server (TCP variant) Protocol stack between PU and NS (TCP variant)
2.2.4. PE <-> ES Communication 2.2.4 PE <-> NS Communication
The PE <-> ES communication is used for registration and deregistration The PE <-> NS communication is used for registration and
of the PE in one ore more pools and for the supervision of the PE by the deregistration of the PE in one ore more pools and for the
ENRP server. This communication is based on SCTP, the protocol stack is supervision of the PE by the home NS. This communication is based on
shown in figure 3. SCTP, the protocol stack is shown in the following figure.
******** ******** ******** ********
* PE * * ES * * PE * * NS *
******** ******** ******** ********
+------+ +------+ +------+ +------+
| ASAP | | ASAP | | ASAP | | ASAP |
+------+ +------+ +------+ +------+
| SCTP | | SCTP | | SCTP | | SCTP |
+------+ +------+ +------+ +------+
| IP | | IP | | IP | | IP |
+------+ +------+ +------+ +------+
Figure 3: Protocol stack between PE and ENRP server Protocol stack between PE and NS
2.2.5. PU <-> PE Communication 2.2.5 PU <-> PE Communication
The PU <-> PE communication is based on some IP based protocol. The The PU <-> PE communication can be divided into two parts:
necessary information for setting up this communication by the PU is
provided by the ENRP Server to the PU. The protocol stack used between
the PU and the PE is shown in figure 4.
******** ******** o control channel
* PU * * PE *
******** ********
+------+ +------+ o data channel
| ULP | | ULP |
+------+ +------+
| IP | | IP |
+------+ +------+
Figure 4: Protocol stack between PU and PE
[Editors note] This does not provide the necessary communication The data channel is used for the transmission of the upper layer
for exchanging 'business cards'. data. The ASAP layer at the PU and PE may or may not be involved in
the handling of the data channel.
2.2.6. ES <-> ES Communication The control channel can be established from the PU side, if needed,
to transport the following information:
The communication between ENRP servers is used to share the knowledge o The PE can send a testament to the PU for providing information to
about all server pools between all ENRP servers in an operational scope. which other PE the PU should failover in case of a failover.
o The PE can send cookies to the PU. The PE would store only the
last cookie and send it to the new PE in case of a failover.
o Both the PE and PU can send application level acknowledgements to
provide a user controlled buffer management at the RSerPool layer.
See Section 2.3 for further details.
The control channel is transported using the ASAP protocol making use
of SCTP or TCP as its transport protocol. The control and data
channel may be tranported over a single transport layer connection.
2.2.6 NS <-> NS Communication
The communication between name servers is used to share the knowledge
about all server pools between all name servers in an operational
scope.
******** ******** ******** ********
* ES * * ES * * NS * * NS *
******** ******** ******** ********
+------+ +------+ +------+ +------+
| ENRP | | ENRP | | ENRP | | ENRP |
+------+ +------+ +------+ +------+
| SCTP | | SCTP | | SCTP | | SCTP |
+------+ +------+ +------+ +------+
| IP | | IP | | IP | | IP |
+------+ +------+ +------+ +------+
Figure 5: Protocol stack between PE and ENRP server Protocol stack between NS and NS
[Editors note] What about the multicast based ENRP server For this communication ENRP over SCTP is used.
detection.
2.2.7. PE <-> PE Communication When a name server boots up a UDP multicast message may be sent out
for initial detection of other name servers in the operational scope.
The other name servers send an answer using a unicast UDP message.
[Editors note] This is a special case of the PU <-> PE 2.2.7 PE <-> PE Communication
communication. In this case the PU is also a PE in a server pool.
The 'business cards' mechanism will be described here.
2.3. Typical Interactions between RSerPool Components This is a special case of the PU <-> PE communication. In this case
the PU is also a PE in a server pool.
There is one additional point here: The PE acting as a PU can send
the PE the information that it is acually a PE of pool. This means
that the pool handle is transferred via the control channel. Also a
testament can be can be sent from the PE acting as a PU to the PE.
See Section 2.3 for further details.
2.3 Failover Support
If the PU detects the failure of a PE it may fail over to a different
PE. The selection to a new PE should be made such that most likely
the new PE is not affected by the failed one. This means, for
example, in case of the failure of a TCP connection between a PU and
a PE the PU should not fail over to a SCTP association on the same
host. It is better to use a different host. Therefore it is
possible for a PE to register multiple transports.
There are some mechanisms provided by RSerPool to support the
failover to a new PE.
2.3.1 Testament
Consider the szenario given in the following figure.
.......................
. +-------+ .
. | | .
. | PE 1 | .
. | | .
. +-------+ . .
. .
. Server Pool .
. .
. .
+-------+ . +-------+ . +-------+
| | . | | . | |
| PU 1 |------.------| PE 2 |------.-------| PU 2 |
| | . | | . | |
+-------+ . +-------+ . +-------+
. .
. .
. .
. .
. +-------+ .
. | | .
. | PE 3 | .
. | | .
. +-------+ .
.......................
Two PE accessing the same PE
PU 1 is using PE 2 of the server pool. Assume that PE 1 and PE 2
share state but not PE 2 and PE 3. Using the testament it is
possible for PE 2 to inform PU 1 that it should fail over to PE 1 in
case of a failure.
A slightly more complicated situation is if two pool users, PU 1 and
PU 2, use PE 2 but both, PU 1 and PU 2, need to use the same PE.
Then it is important that PU 1 and PU 2 fail over to the same PE.
This can be handled in a way such that PE 2 gives the same testament
to PU 1 and PU 2.
2.3.2 Cookies
Cookies are sent from the PE to the PU whenever the PE wants this to
do. The PU only stores the last received cookie. In case of a fail
over it sends this last recveived cookie to the new PE. This method
provides a simple way of state sharing between the PE. Please note
that the PE should sign the cookie and the receiving PE has to
verifiy the signature. For the PU is cookie has no structure and is
does only store it.
2.3.3 Application level acknowledgements
In case of a failure an upper layer might want to retrieve some data
from the communication to to failed PE and transfer it to the new
one. Because this data retrieval problem can not be completely
solved in a general way (and provide neither message loss nor message
duplication) the ASAP layer only provides the support of application
layer acknowledgements. ASAP uses this for upper layer supported
buffer management in the ASAP layer.
2.3.4 Business Cards
In case of a PE to PE communication one of the PEs acts as a PU for
establishing the communication. But the peer does not know the pool
handle of the PE which initiated the communication. A business card
can be used for the PE acting as a PE to provide the peer with the
pool handle. So even in case the PE which acts as a PU fails the
other PE can fail over to a different PE in the pool of the PE which
was initially acting as a PU.
2.4 Typical Interactions between RSerPool Components
The following drawing shows the typical RSerPool components and their The following drawing shows the typical RSerPool components and their
possible interactions with each other: possible interactions with each other:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ operation scope ~ ~ operation scope ~
~ ......................... ......................... ~ ~ ......................... ......................... ~
~ . Server Pool 1 . . Server Pool 2 . ~ ~ . Server Pool 1 . . Server Pool 2 . ~
~ . +-------+ +-------+ . (d) . +-------+ +-------+ . ~ ~ . +-------+ +-------+ . (d) . +-------+ +-------+ . ~
~ . |PE(1,A)| |PE(1,C)|<-------------->|PE(2,B)| |PE(2,A)|<---+ ~ ~ . |PE(1,A)| |PE(1,C)|<-------------->|PE(2,B)| |PE(2,A)|<---+ ~
skipping to change at page 8, line 25 skipping to change at page 12, line 25
~ . +-------+ | | . . | | . | ~ ~ . +-------+ | | . . | | . | ~
~ . |PE(1,B)|<---+ | | . . | | . | ~ ~ . |PE(1,B)|<---+ | | . . | | . | ~
~ . +-------+ | | | . . | | . | ~ ~ . +-------+ | | | . . | | . | ~
~ . ^ | | | . . | | . | ~ ~ . ^ | | | . . | | . | ~
~ .......|........|.|.|.... .......|.........|....... | ~ ~ .......|........|.|.|.... .......|.........|....... | ~
~ | | | | | | | ~ ~ | | | | | | | ~
~ (c)| (a)| | |(a) (a)| (a)| (c)| ~ ~ (c)| (a)| | |(a) (a)| (a)| (c)| ~
~ | | | | | | | ~ ~ | | | | | | | ~
~ | v v v v v | ~ ~ | v v v v v | ~
~ | +++++++++++++++ (e) +++++++++++++++ | ~ ~ | +++++++++++++++ (e) +++++++++++++++ | ~
~ | + ENRP-Server +<---------->+ ENRP-Server + | ~ ~ | + NS +<---------->+ NS + | ~
~ | +++++++++++++++ +++++++++++++++ | ~ ~ | +++++++++++++++ +++++++++++++++ | ~
~ v ^ ^ | ~ ~ v ^ ^ | ~
~ ********* | | | ~ ~ ********* | | | ~
~ * PU(A) *<-------+ (b)| | ~ ~ * PU(A) *<-------+ (b)| | ~
~ ********* (b) | | ~ ~ ********* (b) | | ~
~ v | ~ ~ v | ~
~ ::::::::::::::::: (f) ***************** | ~ ~ ::::::::::::::::: (f) ***************** | ~
~ : Other Clients :<------------->* Proxy/Gateway * <---+ ~ ~ : Other Clients :<------------->* Proxy/Gateway * <---+ ~
~ ::::::::::::::::: ***************** ~ ~ ::::::::::::::::: ***************** ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Figure 6: RSerPool components and their possible interactions. RSerPool components and their possible interactions.
In figure 6 we can identify the following possible interactions:
(a) Server Pool Elements <-> ENRP Server: (ASAP)
Each PE in a pool uses ASAP to register or de-register itself In this figure we can identify the following possible interactions:
as well as to exchange other auxiliary information with the
ENRP Server. The ENRP Server also uses ASAP to monitor the
operational status of each PE in a pool.
(b) PU <-> ENRP Server: (ASAP) (a) Server Pool Elements <-> NS: (ASAP) Each PE in a pool uses ASAP
to register or de-register itself as well as to exchange other
auxiliary information with the NS. The NS also uses ASAP to
monitor the operational status of each PE in a pool.
A PU normally uses ASAP to request the ENRP Server for a name- (b) PU <-> NS: (ASAP) A PU normally uses ASAP to request the NS for a
to-address translation service before the PU can send user name-to-address translation service before the PU can send user
messages addressed to a server pool by the pool's name. messages addressed to a server pool by the pool's name.
(c) PU <-> PE: (ASAP) (c) PU <-> PE: (ASAP) ASAP can be used to exchange some auxiliary
information of the two parties before they engage in user data
ASAP can be used to exchange some auxiliary information of the transfer.
two parties before they engage in user data transfer.
(d) Server Pool <-> Server Pool: (ASAP)
A PE in a server pool can become a PU to another pool when the
PE tries to initiate communication with the other pool. In
such a case, the interactions described in B) and C) above
will apply.
(e) ENRP Server <-> ENRP Server: (ENRP)
ENRP can be used to fulfill various Name Space operation, (d) Server Pool <-> Server Pool: (ASAP) A PE in a server pool can
administration, and maintenance (OAM) functions. become a PU to another pool when the PE tries to initiate
communication with the other pool. In such a case, the
interactions described in (a) and (c) above will apply.
(f) Other Clients <-> Proxy/Gateway: standard protocols (e) NS <-> NS: (ENRP) ENRP can be used to fulfill various Name Space
operation, administration, and maintenance (OAM) functions.
The proxy/gateway enables clients ("other clients"), which are (f) Other Clients <-> Proxy/Gateway: standard protocols The proxy/
not RSerPool aware, to access services provided by an RSerPool gateway enables clients ("other clients"), which are not RSerPool
based server pool. It should be noted that these aware, to access services provided by an RSerPool based server
proxies/gateways may become a single point of failure. pool. It should be noted that these proxies/gateways may become a
single point of failure.
3. Examples 3. Examples
[Editors note] This section has not been updated. The examples will [Editors note] This section has not been updated. The examples will
be updated after the architecture has been finalized. be updated after the architecture has been finalized.
In this section the basic concepts of ENRP and ASAP will be described. In this section the basic concepts of ENRP and ASAP will be
First an RSerPool aware FTP server is considered. The interaction with described. First an RSerPool aware FTP server is considered. The
an RSerPool aware and an non-aware client is given. Finally, a telephony interaction with an RSerPool aware and an non-aware client is given.
example is considered. Finally, a telephony example is considered.
3.1. Two File Transfer Examples 3.1 Two File Transfer Examples
In this section we present two separate file transfer examples using In this section we present two separate file transfer examples using
ENRP and ASAP. We present two separate examples demonstrating an ENRP and ASAP. We present two separate examples demonstrating an
ENRP/ASAP aware client and a client that is using a Proxy or Gateway to ENRP/ASAP aware client and a client that is using a Proxy or Gateway
perform the file transfer. In this example we will use a FTP [RFC959] to perform the file transfer. In this example we will use a FTP
model with some modifications. The first example (the RSerPool aware RFC959 [2] model with some modifications. The first example (the
one) will modify FTP concepts so that the file transfer takes place over RSerPool aware one) will modify FTP concepts so that the file
SCTP. In the second example we will use TCP between the unaware client transfer takes place over SCTP. In the second example we will use
and the Proxy. The Proxy itself will use the modified FTP with RSerPool TCP between the unaware client and the Proxy. The Proxy itself will
as illustrated in the first example. use the modified FTP with RSerPool as illustrated in the first
example.
Please note that in the example we do NOT follow FTP [RFC959] precisely
but use FTP-like concepts and attempt to adhere to the basic FTP model.
These examples use FTP for illustrative purposes, FTP was chosen since Please note that in the example we do NOT follow FTP RFC959 [2]
many of the basic concept are well known and should be familiar to precisely but use FTP-like concepts and attempt to adhere to the
readers. basic FTP model. These examples use FTP for illustrative purposes,
FTP was chosen since many of the basic concept are well known and
should be familiar to readers.
3.1.1. The RSerPool Aware Client 3.1.1 The RSerPool Aware Client
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ operation scope ~ ~ operation scope ~
~ ......................... ~ ~ ......................... ~
~ . "File Transfer Pool" . ~ ~ . "File Transfer Pool" . ~
~ . +-------+ +-------+ . ~ ~ . +-------+ +-------+ . ~
~ +-> |PE(1,A)| |PE(1,C)| . ~ ~ +-> |PE(1,A)| |PE(1,C)| . ~
~ |. +-------+ +-------+ . ~ ~ |. +-------+ +-------+ . ~
~ |. ^ ^ . ~ ~ |. ^ ^ . ~
~ |. +----------+ | . ~ ~ |. +----------+ | . ~
~ |. +-------+ | | . ~ ~ |. +-------+ | | . ~
~ |. |PE(1,B)|<---+ | | . ~ ~ |. |PE(1,B)|<---+ | | . ~
~ |. +-------+ | | | . ~ ~ |. +-------+ | | | . ~
~ |. ^ | | | . ~ ~ |. ^ | | | . ~
~ |.......|........|.|.|.... ~ ~ |.......|........|.|.|.... ~
~ | ASAP | ASAP| | |ASAP ~ ~ | ASAP | ASAP| | |ASAP ~
~ |(d) |(c) | | | ~ ~ |(d) |(c) | | | ~
~ | v v v v ~ ~ | v v v v ~
~ | ********* +++++++++++++++ ~ ~ | ********* +++++++++++++++ ~
~ + ->* PU(X) * + ENRP-Server + ~ ~ + ->* PU(X) * + NS + ~
~ ********* +++++++++++++++ ~ ~ ********* +++++++++++++++ ~
~ ^ ASAP ^ ~ ~ ^ ASAP ^ ~
~ | <-(b) | ~ ~ | <-(b) | ~
~ +--------------+ ~ ~ +--------------+ ~
~ (a)-> ~ ~ (a)-> ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Figure 7: Architecture for RSerPool aware client.
Architecture for RSerPool aware client.
To effect a file transfer the following steps would take place. To effect a file transfer the following steps would take place.
(1) The application in PU(X) would send a login request. The 1. The application in PU(X) would send a login request. The PU(X)'s
PU(X)'s ASAP layer would send an ASAP request to its ENRP ASAP layer would send an ASAP request to its NS to request the
server to request the list of pool elements (using (a)). The list of pool elements (using (a)). The pool handle to identify
pool handle to identify the pool would be "File Transfer the pool would be "File Transfer Pool". The ASAP layer queues
Pool". The ASAP layer queues the login request. the login request.
(2) The ENRP server would return a list of the three PEs PE(1,A), 2. The NS would return a list of the three PEs PE(1,A), PE(1,B) and
PE(1,B) and PE(1,C) to the ASAP layer in PU(X) (using (b)). PE(1,C) to the ASAP layer in PU(X) (using (b)).
(3) The ASAP layer selects one of the PEs, for example PE(1,B). It 3. The ASAP layer selects one of the PEs, for example PE(1,B). It
transmits the login request, the other FTP control data transmits the login request, the other FTP control data finally
finally starts the transmission of the requested files (using starts the transmission of the requested files (using (c)). For
(c)). For this the multiple stream feature of SCTP could be this the multiple stream feature of SCTP could be used.
used.
(4) If during the file transfer conversation, PE(1,B) fails, 4. If during the file transfer conversation, PE(1,B) fails, assuming
assuming the PE's were sharing state of file transfer, a fail- the PE's were sharing state of file transfer, a fail-over to
over to PE(1,A) could be initiated. PE(1,A) would continue the PE(1,A) could be initiated. PE(1,A) would continue the transfer
transfer until complete (see (d)). In parallel a request from until complete (see (d)). In parallel a request from PE(1,A)
PE(1,A) would be made to ENRP to request a cache update for would be made to ENRP to request a cache update for the server
the server pool "File Transfer Pool" and a report would also pool "File Transfer Pool" and a report would also be made that
be made that PE(1,B) is non-responsive (this would cause PE(1,B) is non-responsive (this would cause appropriate audits
appropriate audits that may remove PE(1,B) from the pool if that may remove PE(1,B) from the pool if the NS had not already
the ENRP servers had not already detected the failure) (using detected the failure) (using (a)).
(a)).
3.1.2. The RSerPool Unaware Client 3.1.2 The RSerPool Unaware Client
In this example we investigate the use of a Proxy server assuming the In this example we investigate the use of a Proxy server assuming the
same set of scenario as illustrated above. same set of scenario as illustrated above.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ operation scope ~ ~ operation scope ~
~ ......................... ~ ~ ......................... ~
~ . "File Transfer Pool" . ~ ~ . "File Transfer Pool" . ~
~ . +-------+ +-------+ . ~ ~ . +-------+ +-------+ . ~
~ . |PE(1,A)| |PE(1,C)| . ~ ~ . |PE(1,A)| |PE(1,C)| . ~
skipping to change at page 11, line 40 skipping to change at page 16, line 35
~ . +----------+ | . ~ ~ . +----------+ | . ~
~ . +-------+ | | . ~ ~ . +-------+ | | . ~
~ . |PE(1,B)|<---+ | | . ~ ~ . |PE(1,B)|<---+ | | . ~
~ . +-------+ | | | . ~ ~ . +-------+ | | | . ~
~ .......^........|.|.|.... ~ ~ .......^........|.|.|.... ~
~ | | | | ~ ~ | | | | ~
~ | ASAP| | |ASAP ~ ~ | ASAP| | |ASAP ~
~ | | | | ~ ~ | | | | ~
~ | v v v ~ ~ | v v v ~
~ | +++++++++++++++ +++++++++++++++ ~ ~ | +++++++++++++++ +++++++++++++++ ~
~ | + ENRP-Server +<--ENRP-->+ ENRP-Server + ~ ~ | + NS +<--ENRP-->+ NS + ~
~ | +++++++++++++++ +++++++++++++++ ~ ~ | +++++++++++++++ +++++++++++++++ ~
~ | ASAP ^ ~ ~ | ASAP ^ ~
~ | ASAP (c) (b) | ^ ~ ~ | ASAP (c) (b) | ^ ~
~ +---------------------------------+ | | | ~ ~ +---------------------------------+ | | | ~
~ | v | (a) ~ ~ | v | (a) ~
~ v v ~ ~ v v ~
~ ::::::::::::::::: (e)-> ***************** ~ ~ ::::::::::::::::: (e)-> ***************** ~
~ : FTP Client :<------------->* Proxy/Gateway * ~ ~ : FTP Client :<------------->* Proxy/Gateway * ~
~ ::::::::::::::::: (f) ***************** ~ ~ ::::::::::::::::: (f) ***************** ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Figure 8: Architecture for RserPool unaware client. Architecture for RserPool unaware client.
In this example the steps will occur: In this example the steps will occur:
(1) The FTP client and the Proxy/Gateway are using the TCP-based 1. The FTP client and the Proxy/Gateway are using the TCP-based ftp
ftp protocol. The client sends the login request to the proxy protocol. The client sends the login request to the proxy (using
(using (e)) (e)).
(2) The proxy behaves like a client and performs the actions 2. The proxy behaves like a client and performs the actions
described under (1), (2) and (3) of the above description described under (1), (2) and (3) of the above description (using
(using (a), (b) and (c)). (a), (b) and (c)).
(3) The ftp communication continues and will be translated by the 3. The ftp communication continues and will be translated by the
proxy into the RSerPool aware dialect. This interworking uses proxy into the RSerPool aware dialect. This interworking uses
(f) and (c). (f) and (c).
Note that in this example high availability is maintained between the Note that in this example high availability is maintained between the
Proxy and the server pool but a single point of failure exists between Proxy and the server pool but a single point of failure exists
the FTP client and the Proxy, i.e. the command TCP connection and its between the FTP client and the Proxy, i.e. the command TCP
one IP address it is using for commands. connection and its one IP address it is using for commands.
3.2. Telephony Signaling Example 3.2 Telephony Signaling Example
This example shows the use of ASAP/RSerPool to support server pooling This example shows the use of ASAP/RSerPool to support server pooling
for high availability of a telephony application such as a Voice over IP for high availability of a telephony application such as a Voice over
Gateway Controller (GWC) and Gatekeeper services (GK). IP Gateway Controller (GWC) and Gatekeeper services (GK).
In this example, we show two different scenarios of deploying these In this example, we show two different scenarios of deploying these
services using RSerPool in order to illustrate the flexibility of the services using RSerPool in order to illustrate the flexibility of the
RSerPool architecture. RSerPool architecture.
3.2.1. Decomposed GWC and GK Scenario 3.2.1 Decomposed GWC and GK Scenario
In this scenario, both GWC and GK services are deployed as separate In this scenario, both GWC and GK services are deployed as separate
pools with some number of PEs, as shown in the following diagram. Each pools with some number of PEs, as shown in the following diagram.
of the pools will register their unique pool handle (i.e. name) with the Each of the pools will register their unique pool handle (i.e. name)
ENRP Server. We also assume that there are a Signaling Gateway (SG) and with the NS. We also assume that there are a Signaling Gateway (SG)
a Media Gateway (MG) present and both are RSerPool aware. and a Media Gateway (MG) present and both are RSerPool aware.
................... ...................
. Gateway . . Gateway .
. Controller Pool . . Controller Pool .
................. . +-------+ . ................. . +-------+ .
. Gatekeeper . . |PE(2,A)| . . Gatekeeper . . |PE(2,A)| .
. Pool . . +-------+ . . Pool . . +-------+ .
. +-------+ . . +-------+ . . +-------+ . . +-------+ .
. |PE(1,A)| . . |PE(2,B)| . . |PE(1,A)| . . |PE(2,B)| .
. +-------+ . . +-------+ . . +-------+ . . +-------+ .
. +-------+ . (d) . +-------+ . . +-------+ . (d) . +-------+ .
. |PE(1,B)|<------------>|PE(2,C)|<-------------+ . |PE(1,B)|<------------>|PE(2,C)|<-------------+
. +-------+ . . +-------+ . | . +-------+ . . +-------+ . |
................. ........^.......... | ................. ........^.......... |
| | | |
(c)| (e)| (c)| (e)|
| v | v
+++++++++++++++ ********* ***************** +++++++++++++++ ********* *****************
+ ENRP-Server + * SG(X) * * Media Gateway * + NS + * SG(X) * * Media Gateway *
+++++++++++++++ ********* ***************** +++++++++++++++ ********* *****************
^ ^ ^ ^
| | | |
| <-(a) | | <-(a) |
+-------------------+ +-------------------+
(b)-> (b)->
Figure 9: Deployment of Decomposed GWC and GK. Deployment of Decomposed GWC and GK.
As shown in the figure 9, the following sequence takes place: As shown in the previous figure, the following sequence takes place:
(1) the Signaling Gateway (SG) receives an incoming signaling 1. the Signaling Gateway (SG) receives an incoming signaling message
message to be forwarded to the GWC. SG(X)'s ASAP layer would to be forwarded to the GWC. SG(X)'s ASAP layer would send an
send an ASAP request to its "local" ENRP server to request the ASAP request to its "local" NS to request the list of pool
list of pool elements (PE's) of GWC (using (a)). The key used elements (PE's) of GWC (using (a)). The key used for this query
for this query is the pool handle of the GWC. The ASAP layer is the pool handle of the GWC. The ASAP layer queues the data to
queues the data to be sent in local buffers until the ENRP be sent in local buffers until the NS responds.
server responds.
(2) the ENRP server would return a list of the three PE's A, B and 2. the NS would return a list of the three PE's A, B and C to the
C to the ASAP layer in SG(X) together with information to be ASAP layer in SG(X) together with information to be used for
used for load-sharing traffic across the gateway controller load-sharing traffic across the gateway controller pool (using
pool (using (b)). (b)).
(3) the ASAP layer in SG(X) will select one PE (e.g., PE(2,C)) and 3. the ASAP layer in SG(X) will select one PE (e.g., PE(2,C)) and
send the signaling message to it (using (c)). The selection is send the signaling message to it (using (c)). The selection is
based on the load sharing information of the gateway based on the load sharing information of the gateway controller
controller pool. pool.
(4) to progress the call, PE(2,C) finds that it needs to talk to 4. to progress the call, PE(2,C) finds that it needs to talk to the
the Gatekeeper. Assuming it has already had gatekeeper pool's Gatekeeper. Assuming it has already had gatekeeper pool's
information in its local cache (e.g., obtained and stored from information in its local cache (e.g., obtained and stored from
recent query to ENRP Server), PE(2,C) selects PE(1,B) and recent query to NS), PE(2,C) selects PE(1,B) and sends the call
sends the call control message to it (using (d)). control message to it (using (d)).
We assume PE(1,B) responds back to PE(2,C) and authorizes the 5. We assume PE(1,B) responds back to PE(2,C) and authorizes the
call to proceed. call to proceed.
(5) PE(2,C) issues media control commands to the Media Gateway 6. PE(2,C) issues media control commands to the Media Gateway (using
(using (e)). (e)).
RSerPool will provide service robustness to the system if some failure RSerPool will provide service robustness to the system if some
would occur in the system. failure would occur in the system.
For instance, if PE(1, B) in the Gatekeeper Pool crashed after receiving For instance, if PE(1, B) in the Gatekeeper Pool crashed after
the call control message from PE(2, C) in step (d) above, what most receiving the call control message from PE(2, C) in step (d) above,
likely will happen is that, due to the absence of a reply from the what most likely will happen is that, due to the absence of a reply
Gatekeeper, a timer expiration event will trigger the call state machine from the Gatekeeper, a timer expiration event will trigger the call
within PE(2, C) to resend the control message. The ASAP layer at PE(2, state machine within PE(2, C) to resend the control message. The
C) will then notice the failure of PE(1, B) through (likely) the ASAP layer at PE(2, C) will then notice the failure of PE(1, B)
endpoint unreachability detection by the transport protocol beneath ASAP through (likely) the endpoint unreachability detection by the
and automatically deliver the re-sent call control message to the transport protocol beneath ASAP and automatically deliver the re-sent
alternate GK pool member PE(1, A). With appropriate intra-pool call call control message to the alternate GK pool member PE(1, A). With
state sharing support, PE(1, A) will be able to correctly handle the appropriate intra-pool call state sharing support, PE(1, A) will be
call and reply to PE(2, C) and hence progress the call. able to correctly handle the call and reply to PE(2, C) and hence
progress the call.
3.2.2. Collocated GWC and GK Scenario 3.2.2 Collocated GWC and GK Scenario
In this scenario, the GWC and GK services are collocated (e.g., they are In this scenario, the GWC and GK services are collocated (e.g., they
implemented as a single process). In such a case, one can form a pool are implemented as a single process). In such a case, one can form a
that provides both GWC and GK services as shown in figure 6 below. pool that provides both GWC and GK services as shown in the figure
below.
........................................ ........................................
. Gateway Controller/Gatekeeper Pool . . Gateway Controller/Gatekeeper Pool .
. +-------+ . . +-------+ .
. |PE(3,A)| . . |PE(3,A)| .
. +-------+ . . +-------+ .
. +-------+ . . +-------+ .
. |PE(3,C)|<---------------------------+ . |PE(3,C)|<---------------------------+
. +-------+ . | . +-------+ . |
. +-------+ ^ . | . +-------+ ^ . |
. |PE(3,B)| | . | . |PE(3,B)| | . |
. +-------+ | . | . +-------+ | . |
................|....................... | ................|....................... |
| | | |
+-------------+ | +-------------+ |
| | | |
(c)| (e)| (c)| (e)|
v v v v
+++++++++++++++ ********* ***************** +++++++++++++++ ********* *****************
+ ENRP-Server + * SG(X) * * Media Gateway * + NS + * SG(X) * * Media Gateway *
+++++++++++++++ ********* ***************** +++++++++++++++ ********* *****************
^ ^ ^ ^
| | | |
| <-(a) | | <-(a) |
+-------------------+ +-------------------+
(b)-> (b)->
Figure 10: Deployment of Collocated GWC and GK. Deployment of Collocated GWC and GK.
The same sequence as described in 5.2.1 takes place, except that step The same sequence as described in 5.2.1 takes place, except that step
(4) now becomes internal to the PE(3,C) (again, we assume Server C is (4) now becomes internal to the PE(3,C) (again, we assume Server C is
selected by SG). selected by SG).
4. Acknowledgements 4. Acknowledgements
The authors would like to thank Bernard Aboba, Harrie Hazewinkel, Matt The authors would like to thank Bernard Aboba, Harrie Hazewinkel,
Holdrege, Christopher Ross, Werner Vogels and many others for their Matt Holdrege, Christopher Ross, Werner Vogels and many others for
invaluable comments and suggestions. their invaluable comments and suggestions.
5. References References
[RFC793] J. B. Postel, "Transmission Control Protocol", RFC 793, [1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981. September 1981.
[RFC959] J. B. Postel, J. Reynolds, "File Transfer Protocol (FTP)", [2] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC
RFC 959, October 1985. 959, October 1985.
[RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", [3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
RFC 2026, October 1996. 9, RFC 2026, October 1996.
[RFC2608] E. Guttman et al., "Service Location Protocol, Version 2", [4] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
RFC 2608, June 1999. Location Protocol, Version 2", RFC 2608, June 1999.
[RFC2719] L. Ong et al., "Framework Architecture for Signaling [5] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L.,
Transport", RFC 2719, October 1999. Lin, H., Juhasz, I., Holdrege, M. and C. Sharp, "Framework
Architecture for Signaling Transport", RFC 2719, October 1999.
[RFC2960] R. R. Stewart et al., "Stream Control Transmission [6] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
Protocol", RFC 2960, November 2000. H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC3237] M. Tuexen et al., "Requirements for Reliable Server [7] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney,
Pooling", RFC 3237, January 2002. J. and M. Stillman, "Requirements for Reliable Server Pooling",
RFC 3237, January 2002.
6. Authors' Addresses Authors' Addresses
Michael Tuexen Tel.: +49 89 722 47210 Michael Tuexen
Siemens AG e-mail: Michael.Tuexen@icn.siemens.de Siemens AG
ICN WN CS SE 51 ICN WN CC SE 7
D-81359 Munich D-81359 Munich
Germany Germany
Qiaobing Xie Tel.: +1 847 632 3028 Phone: +49 89 722 47210
Motorola, Inc. e-mail: qxie1@email.mot.com EMail: Michael.Tuexen@icn.siemens.de
Qiaobing Xie
Motorola, Inc.
1501 W. Shure Drive, #2309 1501 W. Shure Drive, #2309
Arlington Heights, Il 60004 Arlington Heights, IL 60004
USA USA
Randall Stewart Tel.: +1 815 477 2127 Phone: +1-847-632-3028
Cisco Systems, Inc. e-mail: rrs@cisco.com EMail: qxie1@email.mot.com
24 Burning Bush Trail Randall R. Stewart
Crystal Lake, Il 60012 Cisco Systems, Inc.
8725 West Higgins Road
Suite 300
Chicago, IL 60631
USA USA
Melinda Shore Tel.: +1 607 272 7512 Phone: +1-815-477-2127
Cisco Systems, Inc. e-mail: mshore@cisco.com EMail: rrs@cisco.com
Melinda Shore
Cisco Systems, Inc.
809 Hayts Rd 809 Hayts Rd
Ithaca, NY 14850 Ithaca, NY 14850
USA USA
Lyndon Ong Tel.: +1 408 321 8237 Phone: +1 607 272 7512
Point Reyes Networks e-mail: long@pointreyesnet.com EMail: mshore@cisco.com
1991 Concourse Drive
San Jose, CA Lyndon Ong
Ciena Corporation
10480 Ridgeview Drive
Cupertino, CA 95014
USA USA
John Loughney Tel.: EMail: lyong@ciena.com
Nokia Research Center e-mail: john.loughney@nokia.com
John Loughney
Nokia Research Center
PO Box 407 PO Box 407
FIN-00045 Nokia Group FIN-00045 Nokia Group FIN-00045
Finland Finland
Maureen Stillman Tel.: +1 607 273 0724 62 EMail: john.loughney@nokia.com
Nokia e-mail: maureen.stillman@nokia.com
Maureen Stillman
Nokia
127 W. State Street 127 W. State Street
Ithaca, NY 14850 Ithaca, NY 14850
USA USA
This Internet Draft expires October 24, 2002. Phone: +1-607-273-0724
EMail: maureen.stillman@nokia.com
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. 

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