draft-ietf-rserpool-arch-04.txt   draft-ietf-rserpool-arch-05.txt 
Network Working Group M. Tuexen Network Working Group M. Tuexen
Internet-Draft Siemens AG Internet-Draft Siemens AG
Expires: May 5, 2003 Q. Xie Expires: August 2, 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
November 4, 2002 February 2003
Architecture for Reliable Server Pooling Architecture for Reliable Server Pooling
draft-ietf-rserpool-arch-04.txt draft-ietf-rserpool-arch-05.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 Task Force (IETF), its areas, and its working groups. Note that other
other groups may also distribute working documents as Internet- groups may also distribute working documents as Internet-Drafts.
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 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 May 5, 2003. This Internet-Draft will expire on August 2, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). 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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . 4
2. Reliable Server Pooling Architecture . . . . . . . . . . . . 5 2. Reliable Server Pooling Architecture . . . . . . . . . . . . 4
2.1 RSerPool Functional Components . . . . . . . . . . . . . . . 5 2.1 RSerPool Functional Components . . . . . . . . . . . . . . . 4
2.2 RSerPool Protocol Overview . . . . . . . . . . . . . . . . . 6 2.2 RSerPool Protocol Overview . . . . . . . . . . . . . . . . . 5
2.2.1 Endpoint Name Resolution Protocol . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . 8 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 Testament . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.2 Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3.2 Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.3 Application level acknowledgements . . . . . . . . . . . . . 11 2.3.3 Business Cards . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.4 Business Cards . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Typical Interactions between RSerPool Components . . . . . . 11 2.4 Typical Interactions between RSerPool Components . . . . . . 11
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1 Two File Transfer Examples . . . . . . . . . . . . . . . . . 14 3.1 Two File Transfer Examples . . . . . . . . . . . . . . . . . 12
3.1.1 The RSerPool Aware Client . . . . . . . . . . . . . . . . . 15 3.1.1 The RSerPool Aware Client . . . . . . . . . . . . . . . . . 13
3.1.2 The RSerPool Unaware Client . . . . . . . . . . . . . . . . 16 3.1.2 The RSerPool Unaware Client . . . . . . . . . . . . . . . . 14
3.2 Telephony Signaling Example . . . . . . . . . . . . . . . . 17 3.2 Telephony Signaling Example . . . . . . . . . . . . . . . . 16
3.2.1 Decomposed GWC and GK Scenario . . . . . . . . . . . . . . . 17 3.2.1 Decomposed GWC and GK Scenario . . . . . . . . . . . . . . . 16
3.2.2 Collocated GWC and GK Scenario . . . . . . . . . . . . . . . 19 3.2.2 Collocated GWC and GK Scenario . . . . . . . . . . . . . . . 17
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
References . . . . . . . . . . . . . . . . . . . . . . . . . 22 References . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19
Full Copyright Statement . . . . . . . . . . . . . . . . . . 24 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
is capable of supporting the desired service, and providing a name is capable of supporting the desired service, and providing a name
service that will resolve requests from a service user to the service that will resolve requests from a service user to the
skipping to change at page 5, line 50 skipping to change at page 5, line 27
o A protocol field of the IP header specifying the transport layer o A protocol field of the IP header specifying the transport layer
protocol or protocols. protocol or protocols.
o A port number associatiated with the transport protocol, e.g. o A port number associatiated with the transport protocol, e.g.
SCTP, TCP or UDP. SCTP, TCP or UDP.
Please note that the RSerPool architecture supports both IPv4 and Please note that the RSerPool architecture supports both IPv4 and
IPv6 addressing. A PE can also support multiple transport layers. IPv6 addressing. A PE can also support multiple transport layers.
In each operational scope there must be at least one name server. In each operational scope there must be at least one name server. All
All name servers within the operational scope have knowledge of all name servers within the operational scope have knowledge of all
server pools within the operational scope. server pools within the operational scope.
A third class of entities in the architecture is the Pool User (PU) A third class of entities in the architecture is the Pool User (PU)
class, consisting of the clients being served by the PEs of a server class, consisting of the clients being served by the PEs of a server
pool. pool.
2.2 RSerPool Protocol Overview 2.2 RSerPool Protocol Overview
The RSerPool requested features can be obtained with the help of the The RSerPool requested features can be obtained with the help of the
combination of two protocols: ENRP (Endpoint Name Resolution combination of two protocols: ENRP (Endpoint Name Resolution
Protocol) and ASAP (Aggregate Server Access Protocol). Protocol) and ASAP (Aggregate Server Access Protocol).
2.2.1 Endpoint Name Resolution Protocol 2.2.1 Endpoint Name Resolution Protocol
The name servers use a protocol called Endpoint Name Resolution The name servers use a protocol called Endpoint Name Resolution
Protocol (ENRP) for communication with each other to make sure that Protocol (ENRP) for communication with each other to make sure that
all have the same information about the server pools. all have the same information about the server pools.
ENRP is designed to provide a fully distributed fault-tolerant real- ENRP is designed to provide a fully distributed fault-tolerant
time translation service that maps a name to a set of transport real-time translation service that maps a name to a set of transport
addresses pointing to a specific group of networked communication addresses pointing to a specific group of networked communication
endpoints registered under that name. ENRP employs a client-server endpoints registered under that name. ENRP employs a client-server
model with which an name server will respond to the name translation model with which an name server will respond to the name translation
service requests from endpoint clients running on the same host or service requests from endpoint clients running on the same host or
running on different hosts. running on different hosts.
RFC3237 [7] also requires that the name servers should not resolve a RFC3237 [7] also requires that the name servers should not resolve a
pool handle to a transport layer address of a PE which is not in pool handle to a transport layer address of a PE which is not in
operation. Therefore each PE is supervised by one specific name operation. Therefore each PE is supervised by one specific name
server, called the home NS of that PE. If it detects that the PE is server, called the home NS of that PE. If it detects that the PE is
skipping to change at page 7, line 32 skipping to change at page 7, line 19
+------+ +------+ +------+ +------+
| ASAP | | ASAP | | ASAP | | ASAP |
+------+ +------+ +------+ +------+
| SCTP | | SCTP | | SCTP | | SCTP |
+------+ +------+ +------+ +------+
| IP | | IP | | IP | | IP |
+------+ +------+ +------+ +------+
Protocol stack between PU and NS Protocol stack between PU and NS
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 *
******** ******** ******** ********
skipping to change at page 8, line 26 skipping to change at page 8, line 15
The control channel can be established from the PU side, if needed, The control channel can be established from the PU side, if needed,
to transport the following information: to transport the following information:
o The PE can send a testament to the PU for providing information to o The PE can send a testament to the PU for providing information to
which other PE the PU should failover in case of a failover. 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 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. 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. See Section 2.3 for further details.
The control channel is transported using the ASAP protocol making use There are several ways for handling the control and data channel:
of SCTP as its transport protocol. The control and data channel may
be tranported over a single transport layer connection. 1. If the data channel is transported over SCTP the control channel
can be transported over the same SCTP association or over a
separate one. In case of using only one association the PPID is
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
be transported over the same TCP connection or over a separate
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
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 *
******** ******** ******** ********
skipping to change at page 9, line 28 skipping to change at page 9, line 42
testament can be can be sent from the PE acting as a PU to the PE. testament can be can be sent from the PE acting as a PU to the PE.
See 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. This means, for
example, in case of the failure of a TCP connection between a PU and 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 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 host. It is better to use a different host. Therefore it is possible
possible for a PE to register multiple transports. 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 Testament
Consider the szenario given in the following figure. Consider the szenario given in the following figure.
....................... .......................
. +-------+ . . +-------+ .
skipping to change at page 10, line 38 skipping to change at page 10, line 38
. +-------+ . . +-------+ .
....................... .......................
Two PE accessing the same PE Two PE accessing the same PE
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 testament of PE 2 it is
possible for PE 2 to inform PU 1 that it should fail over to PE 1 in possible for PE 2 to inform PU 1 that it should fail over to PE 1 in
case of a failure. 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. PU 2, use PE 2 but both, PU 1 and PU 2, need to use the same PE. Then
Then it is important that PU 1 and PU 2 fail over to the same PE. it is important that PU 1 and PU 2 fail over to the same PE. This can
This can be handled in a way such that PE 2 gives the same testament be handled in a way such that PE 2 gives the same testament to PU 1
to PU 1 and PU 2. 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 this to do.
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 Application level acknowledgements 2.3.3 Business Cards
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 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 establishing the communication. The receiving may not know the pool
handle of the PE which initiated the communication. A business card 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 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 handle, allowing the peer PE to fail over the communication in case
the initiating PE fails. the initiating PE fails.
2.4 Typical Interactions between RSerPool Components 2.4 Typical Interactions between RSerPool Components
skipping to change at page 14, line 23 skipping to change at page 13, line 4
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 [2] 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 transfer takes place over SCTP. In the second example we will use TCP
TCP between the unaware client and the Proxy. The Proxy itself will between the unaware client and the Proxy. The Proxy itself will use
use the modified FTP with RSerPool as illustrated in the first the modified FTP with RSerPool as illustrated in the first example.
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 [2]
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
skipping to change at page 15, line 40 skipping to change at page 13, line 49
~ (a)-> ~ ~ (a)-> ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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 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 pool would be "File Transfer Pool". The ASAP layer queues the
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)).
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 finally transmits the login request, the other FTP control data finally
starts the transmission of the requested files (using (c)). For starts the transmission of the requested files (using (c)). For
this the multiple stream feature of SCTP could be used. this the multiple stream feature of SCTP could be used.
4. If during the file transfer conversation, PE(1,B) fails, assuming 4. If during the file transfer conversation, PE(1,B) fails, assuming
skipping to change at page 17, line 12 skipping to change at page 15, line 47
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)).
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)
(f) and (c). 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 Proxy and the server pool but a single point of failure exists
between the FTP client and the Proxy, i.e. the command TCP between the FTP client and the Proxy, i.e. the command TCP connection
connection and its one IP address it is using for commands. 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 for high availability of a telephony application such as a Voice over
IP 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.
skipping to change at page 18, line 35 skipping to change at page 17, line 6
| | | |
| <-(a) | | <-(a) |
+-------------------+ +-------------------+
(b)-> (b)->
Deployment of Decomposed GWC and GK. Deployment of Decomposed GWC and GK.
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 to be forwarded to the GWC. SG(X)'s ASAP layer would send an ASAP
ASAP request to its "local" NS to request the list of pool request to its "local" NS to request the list of pool elements
elements (PE's) of GWC (using (a)). The key used for this query (PE's) of GWC (using (a)). The key used for this query is the
is the pool handle of the GWC. The ASAP layer queues the data to pool handle of the GWC. The ASAP layer queues the data to be sent
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
ASAP layer in SG(X) together with information to be used for ASAP layer in SG(X) together with information to be used for
load-sharing traffic across the gateway controller pool (using load-sharing traffic across the gateway controller 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 controller based on the load sharing information of the gateway controller
pool. pool.
skipping to change at page 19, line 21 skipping to change at page 17, line 41
6. PE(2,C) issues media control commands to the Media Gateway (using 6. PE(2,C) issues media control commands to the Media Gateway (using
(e)). (e)).
RSerPool will provide service robustness to the system if some RSerPool will provide service robustness to the system if some
failure would occur in the system. failure would occur in the system.
For instance, if PE(1, B) in the Gatekeeper Pool crashed after For instance, if PE(1, B) in the Gatekeeper Pool crashed after
receiving the call control message from PE(2, C) in step (d) above, receiving the call control message from PE(2, C) in step (d) above,
what most likely will happen is that, due to the absence of a reply what most likely will happen is that, due to the absence of a reply
from the Gatekeeper, a timer expiration event will trigger the call from the Gatekeeper, a timer expiration event will trigger the call
state machine within PE(2, C) to resend the control message. The state machine within PE(2, C) to resend the control message. The ASAP
ASAP layer at PE(2, C) will then notice the failure of PE(1, B) layer at PE(2, C) will then notice the failure of PE(1, B) through
through (likely) the endpoint unreachability detection by the (likely) the endpoint unreachability detection by the transport
transport protocol beneath ASAP and automatically deliver the re-sent protocol beneath ASAP and automatically deliver the re-sent call
call control message to the alternate GK pool member PE(1, A). With control message to the alternate GK pool member PE(1, A). With
appropriate intra-pool call state sharing support, PE(1, A) will be appropriate intra-pool call state sharing support, PE(1, A) will be
able to correctly handle the call and reply to PE(2, C) and hence able to correctly handle the call and reply to PE(2, C) and hence
progress the call. 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 In this scenario, the GWC and GK services are collocated (e.g., they
are implemented as a single process). In such a case, one can form a are implemented as a single process). In such a case, one can form a
pool that provides both GWC and GK services as shown in the figure pool that provides both GWC and GK services as shown in the figure
below. below.
skipping to change at page 22, line 35 skipping to change at page 19, line 28
"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
Siemens AG Siemens AG
ICN WN CC SE 7 ICN CP SE C 7
D-81359 Munich D-81359 Munich
Germany Germany
Phone: +49 89 722 47210 Phone: +49 89 722 47210
EMail: Michael.Tuexen@siemens.com 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
skipping to change at page 24, line 5 skipping to change at page 21, line 5
Maureen Stillman Maureen Stillman
Nokia Nokia
127 W. State Street 127 W. State Street
Ithaca, NY 14850 Ithaca, NY 14850
USA USA
Phone: +1-607-273-0724 Phone: +1-607-273-0724
EMail: maureen.stillman@nokia.com EMail: maureen.stillman@nokia.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
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 assigns. 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 Acknowledgement
 End of changes. 

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