draft-ietf-rserpool-arch-05.txt   draft-ietf-rserpool-arch-06.txt 
Network Working Group M. Tuexen Network Working Group M. Tuexen, Ed.
Internet-Draft Siemens AG Internet-Draft Univ. of Applied Sciences Muenster
Expires: August 2, 2003 Q. Xie Expires: December 28, 2003 Q. Xie
Motorola, Inc. Motorola, Inc.
R. Stewart R. Stewart
M. Shore M. Shore
Cisco Systems, Inc. Cisco Systems, Inc.
L. Ong L. Ong
Ciena Corporation Ciena Corporation
J. Loughney J. Loughney
Nokia Research Center Nokia Research Center
M. Stillman M. Stillman
Nokia Nokia
February 2003 June 29, 2003
Architecture for Reliable Server Pooling Architecture for Reliable Server Pooling
draft-ietf-rserpool-arch-05.txt draft-ietf-rserpool-arch-06.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 time. It is inappropriate to use Internet-Drafts as reference
material 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 http:// The list of current Internet-Drafts can be accessed at 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 August 2, 2003. This Internet-Draft will expire on December 28, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This document describes an architecture and protocols for the This document describes an architecture and protocols for the
management and operation of server pools supporting highly reliable management and operation of server pools supporting highly reliable
applications, and for client access mechanisms to a server pool. applications, and for client access mechanisms to a server pool.
skipping to change at page 2, line 23 skipping to change at page 2, line 23
2.1 RSerPool Functional Components . . . . . . . . . . . . . . . 4 2.1 RSerPool Functional Components . . . . . . . . . . . . . . . 4
2.2 RSerPool Protocol Overview . . . . . . . . . . . . . . . . . 5 2.2 RSerPool Protocol Overview . . . . . . . . . . . . . . . . . 5
2.2.1 Endpoint Name Resolution Protocol . . . . . . . . . . . . . 5 2.2.1 Endpoint Name Resolution Protocol . . . . . . . . . . . . . 5
2.2.2 Aggregate Server Access Protocol . . . . . . . . . . . . . . 6 2.2.2 Aggregate Server Access Protocol . . . . . . . . . . . . . . 6
2.2.3 PU <-> NS Communication . . . . . . . . . . . . . . . . . . 6 2.2.3 PU <-> NS Communication . . . . . . . . . . . . . . . . . . 6
2.2.4 PE <-> NS Communication . . . . . . . . . . . . . . . . . . 7 2.2.4 PE <-> NS Communication . . . . . . . . . . . . . . . . . . 7
2.2.5 PU <-> PE Communication . . . . . . . . . . . . . . . . . . 7 2.2.5 PU <-> PE Communication . . . . . . . . . . . . . . . . . . 7
2.2.6 NS <-> NS Communication . . . . . . . . . . . . . . . . . . 8 2.2.6 NS <-> NS Communication . . . . . . . . . . . . . . . . . . 8
2.2.7 PE <-> PE Communication . . . . . . . . . . . . . . . . . . 9 2.2.7 PE <-> PE Communication . . . . . . . . . . . . . . . . . . 9
2.3 Failover Support . . . . . . . . . . . . . . . . . . . . . . 9 2.3 Failover Support . . . . . . . . . . . . . . . . . . . . . . 9
2.3.1 Testament . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.1 Business Cards . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.2 Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3.2 Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.3 Business Cards . . . . . . . . . . . . . . . . . . . . . . . 11 2.4 Typical Interactions between RSerPool Components . . . . . . 10
2.4 Typical Interactions between RSerPool Components . . . . . . 11
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1 Two File Transfer Examples . . . . . . . . . . . . . . . . . 12 3.1 Two File Transfer Examples . . . . . . . . . . . . . . . . . 12
3.1.1 The RSerPool Aware Client . . . . . . . . . . . . . . . . . 13 3.1.1 The RSerPool Aware Client . . . . . . . . . . . . . . . . . 13
3.1.2 The RSerPool Unaware Client . . . . . . . . . . . . . . . . 14 3.1.2 The RSerPool Unaware Client . . . . . . . . . . . . . . . . 14
3.2 Telephony Signaling Example . . . . . . . . . . . . . . . . 16 3.2 Telephony Signaling Example . . . . . . . . . . . . . . . . 15
3.2.1 Decomposed GWC and GK Scenario . . . . . . . . . . . . . . . 16 3.2.1 Decomposed GWC and GK Scenario . . . . . . . . . . . . . . . 15
3.2.2 Collocated GWC and GK Scenario . . . . . . . . . . . . . . . 17 3.2.2 Collocated GWC and GK Scenario . . . . . . . . . . . . . . . 17
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
References . . . . . . . . . . . . . . . . . . . . . . . . . 18 Normative References . . . . . . . . . . . . . . . . . . . . 18
Informative References . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . 21
1. Introduction 1. Introduction
1.1 Overview 1.1 Overview
This document defines an architecture, for providinge a highly This document defines an architecture, for providinge a highly
available reliable server function in support of some service. The available reliable server function in support of some service. The
way this is achieved is by forming a pool of servers, each of which way this is achieved is by forming a pool of servers, each of which
skipping to change at page 7, line 21 skipping to change at page 7, line 13
+------+ +------+ +------+ +------+
| SCTP | | SCTP | | SCTP | | SCTP |
+------+ +------+ +------+ +------+
| IP | | IP | | IP | | IP |
+------+ +------+ +------+ +------+
Protocol stack between PU and NS Protocol stack between PU and NS
Figure 1 Figure 1
This communication can be based on SCTP or TCP if the PU does not
support SCTP. The protocol stack for an SCTP capable PU is given in
Figure 1.
2.2.4 PE <-> NS Communication 2.2.4 PE <-> NS Communication
The PE <-> NS communication is used for registration and The PE <-> NS communication is used for registration and
deregistration of the PE in one ore more pools and for the deregistration of the PE in one ore more pools and for the
supervision of the PE by the home NS. This communication is based on supervision of the PE by the home NS. This communication is based on
SCTP, the protocol stack is shown in the following figure. SCTP, the protocol stack is shown in the following figure.
******** ******** ******** ********
* PE * * NS * * PE * * NS *
******** ******** ******** ********
+------+ +------+ +------+ +------+
| ASAP | | ASAP | | ASAP | | ASAP |
+------+ +------+ +------+ +------+
| SCTP | | SCTP | | SCTP | | SCTP |
+------+ +------+ +------+ +------+
| IP | | IP | | IP | | IP |
+------+ +------+ +------+ +------+
Protocol stack between PE and NS Protocol stack between PE and NS
Figure 2
2.2.5 PU <-> PE Communication 2.2.5 PU <-> PE Communication
The PU <-> PE communication can be divided into two parts: The PU <-> PE communication can be divided into two parts:
o control channel o control channel
o data channel o data channel
The data channel is used for the transmission of the upper layer The data channel is used for the transmission of the upper layer
data. The ASAP layer at the PU and PE may or may not be involved in data, the control channel is used to exchange RSerPool information.
the handling of the data channel.
The control channel can be established from the PU side, if needed, There are two supported scenarios:
to transport the following information:
o The PE can send a testament to the PU for providing information to o Multiplexed data and control channel. Both channels are
which other PE the PU should failover in case of a failover. transported over one transport connection. This can either be an
SCTP association, with data and control channel are seperated by
the PPID, or an TCP connection, with data and control channel
being handled by a TCP mapping layer.
o The PE can send cookies to the PU. The PE would store only the o Data channel and no control channel. There is no restriction on
last cookie and send it to the new PE in case of a failover. the transport protocol in this case. Note that certain enhanced
failover services (e.g. business cards, state cookies, message
failover) are not available when this method is used.
See Section 2.3 for further details. For a given pool, all PUs and PEs should make the same choice for the
style of interaction between each other: that is, for a given pool,
either all PEs and PUs in that pool use a multiplexed control/data
channel for PU-PE communication, or all PEs and PUs in that pool use
a data channel only for PU-PE communication.
There are several ways for handling the control and data channel: When the multiplexed data and control channel is used, enhanced
failover services may be provided, including:
1. If the data channel is transported over SCTP the control channel o The PE can send a business card to the PU for providing
can be transported over the same SCTP association or over a information to which other PE the PU should failover in case of a
separate one. In case of using only one association the PPID is failover.
used to distinguish between the channels. If two associations are
used a special message on the control channel is required to tie
both channels together.
2. If the data channel is transported over TCP control channel can o The PE can send cookies to the PU. The PE would store only the
be transported over the same TCP connection or over a separate last cookie and send it to the new PE in case of a failover.
one. In case of using only one connection a multiplexing layer
has to be used between TCP and the data / control channel. If two
connections are used a special message on the control channel is
required to tie both channels together.
3. If the data channel is transported over UDP the control channel See Section 2.3 for further details.
can be transported over TCP or SCTP using a special message on
the control channel to tie both channels together.
2.2.6 NS <-> NS Communication 2.2.6 NS <-> NS Communication
The communication between name servers is used to share the knowledge The communication between name servers is used to share the knowledge
about all server pools between all name servers in an operational about all server pools between all name servers in an operational
scope. scope.
******** ******** ******** ********
* NS * * NS * * NS * * NS *
******** ******** ******** ********
+------+ +------+ +------+ +------+
| ENRP | | ENRP | | ENRP | | ENRP |
+------+ +------+ +------+ +------+
| SCTP | | SCTP | | SCTP | | SCTP |
+------+ +------+ +------+ +------+
| IP | | IP | | IP | | IP |
+------+ +------+ +------+ +------+
Protocol stack between NS and NS Protocol stack between NS and NS
Figure 3
For this communication ENRP over SCTP is used. For this communication ENRP over SCTP is used.
When a name server boots up a UDP multicast message may be sent out 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. for initial detection of other name servers in the operational scope.
The other name servers send an answer using a unicast UDP message. The other name servers send an answer using a unicast UDP message.
2.2.7 PE <-> PE Communication 2.2.7 PE <-> PE Communication
This is a special case of the PU <-> PE communication. In this case This is a special case of the PU <-> PE communication. In this case
the PU is also a PE in a server pool. the PU is also a PE in a server pool.
There is one additional point here: The PE acting as a PU can send 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 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 that the pool handle is transferred via the control channel. See
testament can be can be sent from the PE acting as a PU to the PE. Section 2.3 for further details.
See Section 2.3 for further details.
2.3 Failover Support 2.3 Failover Support
If the PU detects the failure of a PE it may fail over to a different 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 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 the new PE is not affected by the failed one.
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 There are some mechanisms provided by RSerPool to support the
failover to a new PE. failover to a new PE.
2.3.1 Testament 2.3.1 Business Cards
Consider the szenario given in the following figure. A PE can send a business card to its peer containing its pool handle
and optionally information to which other PEs the peer should
failover.
Presenting the pool handle is important in case of PE <-> PE
communication in which one of the PEs acts as a PU for establishing
the communication. The pool handle of the PE which initiated the
communication may not be know by the peer.
Providing information to which PE the OU should failover can also be
very important. Consider the scenario given in the following figure.
....................... .......................
. +-------+ . . +-------+ .
. | | . . | | .
. | PE 1 | . . | PE 1 | .
. | | . . | | .
. +-------+ . . . +-------+ .
. . . .
. Server Pool . . Server Pool .
. . . .
. . . .
+-------+ . +-------+ . +-------+ +-------+ . +-------+ . +-------+
| | . | | . | | | | . | | . | |
| PU 1 |------.------| PE 2 |------.-------| PU 2 | | PU 1 |------.------| PE 2 |------.-------| PU 2 |
| | . | | . | | | | . | | . | |
+-------+ . +-------+ . +-------+ +-------+ . +-------+ . +-------+
. . . .
. . . .
skipping to change at page 10, line 32 skipping to change at page 10, line 25
. . . .
. . . .
. +-------+ . . +-------+ .
. | | . . | | .
. | PE 3 | . . | PE 3 | .
. | | . . | | .
. +-------+ . . +-------+ .
....................... .......................
Two PE accessing the same PE Two PE accessing the same PE
Figure 4
PU 1 is using PE 2 of the server pool. Assume that PE 1 and PE 2 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 of PE 2 it is share state but not PE 2 and PE 3. Using the business card of PE 2 it
possible for PE 2 to inform PU 1 that it should fail over to PE 1 in is possible for PE 2 to inform PU 1 that it should fail over to PE 1
case of a failure. in case of a failure.
A slightly more complicated situation is if two pool users, PU 1 and 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 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 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 be handled in a way such that PE 2 gives the same business card to PU
and PU 2. 1 and PU 2.
2.3.2 Cookies 2.3.2 Cookies
Cookies may be sent from the PE to the PU if the PE wants this to do. Cookies may be sent from the PE to the PU if the PE wants to do this.
The PU only stores the last received cookie. In case of a fail over The PU only stores the last received cookie. In case of a fail over
it sends this last received cookie to the new PE. This method it sends this last received cookie to the new PE. This method
provides a simple way of state sharing between the PEs. Please note provides a simple way of state sharing between the PEs. Please note
that the old PE should sign the cookie and the receiving PE should that the old PE should sign the cookie and the receiving PE should
verify the signature. For the PU, the cookie has no structure and is verify the signature. For the PU, the cookie has no structure and is
only stored and transmitted to the new PE. only stored and transmitted to the new PE.
2.3.3 Business Cards
In case of a PE to PE communication one of the PEs acts as a PU for
establishing the communication. The receiving may not know the pool
handle of the PE which initiated the communication. A business card
can be used for the initiating PE to provide its peer with a pool
handle, allowing the peer PE to fail over the communication in case
the initiating PE fails.
2.4 Typical Interactions between RSerPool Components 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) . +-------+ +-------+ . ~
skipping to change at page 12, line 5 skipping to change at page 11, line 38
~ ********* | | | ~ ~ ********* | | | ~
~ * PU(A) *<-------+ (b)| | ~ ~ * PU(A) *<-------+ (b)| | ~
~ ********* (b) | | ~ ~ ********* (b) | | ~
~ v | ~ ~ v | ~
~ ::::::::::::::::: (f) ***************** | ~ ~ ::::::::::::::::: (f) ***************** | ~
~ : Other Clients :<------------->* Proxy/Gateway * <---+ ~ ~ : Other Clients :<------------->* Proxy/Gateway * <---+ ~
~ ::::::::::::::::: ***************** ~ ~ ::::::::::::::::: ***************** ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
RSerPool components and their possible interactions. RSerPool components and their possible interactions.
Figure 5
In this figure we can identify the following possible interactions: In this figure we can identify the following possible interactions:
(a) Server Pool Elements <-> NS: (ASAP) Each PE in a pool uses 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 to register or de-register itself as well as to exchange other
auxiliary information with the NS. The NS also uses ASAP to auxiliary information with the NS. The NS also uses ASAP to
monitor the operational status of each PE in a pool. monitor the operational status of each PE in a pool.
(b) PU <-> NS: (ASAP) A PU normally uses ASAP to request the NS for a (b) PU <-> NS: (ASAP) A PU normally uses ASAP to request the NS for a
name-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.
skipping to change at page 12, line 50 skipping to change at page 12, line 39
described. First an RSerPool aware FTP server is considered. The described. First an RSerPool aware FTP server is considered. The
interaction with an RSerPool aware and an non-aware client is given. interaction with an RSerPool aware and an non-aware client is given.
Finally, a telephony 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 ENRP/ASAP aware client and a client that is using a Proxy or Gateway
to perform the file transfer. In this example we will use a FTP to perform the file transfer. In this example we will use a FTP
RFC959 [2] model with some modifications. The first example (the RFC959 [3] model with some modifications. The first example (the
RSerPool aware one) will modify FTP concepts so that the file RSerPool aware one) will modify FTP concepts so that the file
transfer takes place over SCTP. In the second example we will use TCP transfer takes place over SCTP. In the second example we will use TCP
between the unaware client and the Proxy. The Proxy itself will use between the unaware client and the Proxy. The Proxy itself will use
the modified FTP with RSerPool as illustrated in the first example. the modified FTP with RSerPool as illustrated in the first example.
Please note that in the example we do NOT follow FTP RFC959 [2] Please note that in the example we do NOT follow FTP RFC959 [3]
precisely but use FTP-like concepts and attempt to adhere to the precisely but use FTP-like concepts and attempt to adhere to the
basic FTP model. These examples use FTP for illustrative purposes, basic FTP model. These examples use FTP for illustrative purposes,
FTP was chosen since many of the basic concept are well known and FTP was chosen since many of the basic concept are well known and
should be familiar to readers. should be familiar to readers.
3.1.1 The RSerPool Aware Client 3.1.1 The RSerPool Aware Client
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ operation scope ~ ~ operation scope ~
~ ......................... ~ ~ ......................... ~
skipping to change at page 13, line 44 skipping to change at page 13, line 35
~ + ->* PU(X) * + NS + ~ ~ + ->* PU(X) * + NS + ~
~ ********* +++++++++++++++ ~ ~ ********* +++++++++++++++ ~
~ ^ ASAP ^ ~ ~ ^ ASAP ^ ~
~ | <-(b) | ~ ~ | <-(b) | ~
~ +--------------+ ~ ~ +--------------+ ~
~ (a)-> ~ ~ (a)-> ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Architecture for RSerPool aware client. Architecture for RSerPool aware client.
Figure 6
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 PU(X)'s 1. The application in PU(X) would send a login request. The PU(X)'s
ASAP layer would send an ASAP request to its NS to request the ASAP layer would send an ASAP request to its NS to request the
list of pool elements (using (a)). The pool handle to identify list of pool elements (using (a)). The pool handle to identify
the pool would be "File Transfer Pool". The ASAP layer queues the the pool would be "File Transfer Pool". The ASAP layer queues the
login request. login request.
2. The NS would return a list of the three PEs PE(1,A), PE(1,B) and 2. The NS would return a list of the three PEs PE(1,A), 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)).
skipping to change at page 15, line 36 skipping to change at page 14, line 51
~ | 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) ***************** ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Architecture for RserPool unaware client. Architecture for RserPool unaware client.
Figure 7
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 ftp 1. The FTP client and the Proxy/Gateway are using the TCP-based ftp
protocol. The client sends the login request to the proxy (using protocol. The client sends the login request to the proxy (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 (using described under (1), (2) and (3) of the above description (using
(a), (b) and (c)). (a), (b) and (c)).
skipping to change at page 16, line 51 skipping to change at page 16, line 20
+ NS + * SG(X) * * Media Gateway * + NS + * SG(X) * * Media Gateway *
+++++++++++++++ ********* ***************** +++++++++++++++ ********* *****************
^ ^ ^ ^
| | | |
| <-(a) | | <-(a) |
+-------------------+ +-------------------+
(b)-> (b)->
Deployment of Decomposed GWC and GK. Deployment of Decomposed GWC and GK.
Figure 8
As shown in the previous figure, 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 message 1. the Signaling Gateway (SG) receives an incoming signaling message
to be forwarded to the GWC. SG(X)'s ASAP layer would send an ASAP to be forwarded to the GWC. SG(X)'s ASAP layer would send an ASAP
request to its "local" NS to request the list of pool elements request to its "local" NS to request the list of pool elements
(PE's) of GWC (using (a)). The key used for this query is the (PE's) of GWC (using (a)). The key used for this query is the
pool handle of the GWC. The ASAP layer queues the data to be sent pool handle of the GWC. The ASAP layer queues the data to be sent
in local buffers until the NS responds. in local buffers until the NS responds.
2. the NS would return a list of the three PE's A, B and C to the 2. the NS would return a list of the three PE's A, B and C to the
skipping to change at page 18, line 33 skipping to change at page 18, line 4
(c)| (e)| (c)| (e)|
v v v v
+++++++++++++++ ********* ***************** +++++++++++++++ ********* *****************
+ NS + * SG(X) * * Media Gateway * + NS + * SG(X) * * Media Gateway *
+++++++++++++++ ********* ***************** +++++++++++++++ ********* *****************
^ ^ ^ ^
| | | |
| <-(a) | | <-(a) |
+-------------------+ +-------------------+
(b)-> (b)->
Deployment of Collocated GWC and GK. Deployment of Collocated GWC and GK.
Figure 9
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, The authors would like to thank Bernard Aboba, Phillip Conrad, Harrie
Matt Holdrege, Christopher Ross, Werner Vogels and many others for Hazewinkel, Matt Holdrege, Christopher Ross, Werner Vogels and many
their invaluable comments and suggestions. others for their invaluable comments and suggestions.
References Normative References
[1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
Informative References
[2] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981. September 1981.
[2] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC [3] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC
959, October 1985. 959, October 1985.
[3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[4] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service [4] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
Location Protocol, Version 2", RFC 2608, June 1999. Location Protocol, Version 2", RFC 2608, June 1999.
[5] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L., [5] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L.,
Lin, H., Juhasz, I., Holdrege, M. and C. Sharp, "Framework Lin, H., Juhasz, I., Holdrege, M. and C. Sharp, "Framework
Architecture for Signaling Transport", RFC 2719, October 1999. Architecture for Signaling Transport", RFC 2719, October 1999.
[6] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, [6] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000. "Stream Control Transmission Protocol", RFC 2960, October 2000.
[7] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, [7] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney,
J. and M. Stillman, "Requirements for Reliable Server Pooling", J. and M. Stillman, "Requirements for Reliable Server Pooling",
RFC 3237, January 2002. RFC 3237, January 2002.
Authors' Addresses Authors' Addresses
Michael Tuexen Michael Tuexen (editor)
Siemens AG Univ. of Applied Sciences Muenster
ICN CP SE C 7 Stegerwaldstr. 39
D-81359 Munich 48565 Steinfurt
Germany Germany
Phone: +49 89 722 47210 EMail: tuexen@fh-muenster.de
EMail: Michael.Tuexen@siemens.com
Qiaobing Xie Qiaobing Xie
Motorola, Inc. Motorola, Inc.
1501 W. Shure Drive, #2309 1501 W. Shure Drive, #2309
Arlington Heights, IL 60004 Arlington Heights, IL 60004
USA USA
Phone: +1-847-632-3028 Phone: +1-847-632-3028
EMail: qxie1@email.mot.com EMail: qxie1@email.mot.com
Randall R. Stewart Randall R. Stewart
Cisco Systems, Inc. Cisco Systems, Inc.
8725 West Higgins Road 8725 West Higgins Road
Suite 300 Suite 300
Chicago, IL 60631 Chicago, IL 60631
USA USA
Phone: +1-815-477-2127 Phone: +1-815-477-2127
EMail: rrs@cisco.com EMail: rrs@cisco.com
skipping to change at page 22, line 7 skipping to change at page 22, line 7
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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