draft-ietf-rserpool-arch-01.txt   draft-ietf-rserpool-arch-02.txt 
skipping to change at page 1, line 15 skipping to change at page 1, line 15
Q. Xie Q. Xie
Motorola Motorola
R. Stewart R. Stewart
M. Shore M. Shore
Cisco Cisco
L. Ong L. Ong
Point Reyes Networks Point Reyes Networks
J. Loughney J. Loughney
M. Stillman M. Stillman
Nokia Nokia
Expires September 1, 2002 March 1, 2002 Expires October 24, 2002 April 24, 2002
Architecture for Reliable Server Pooling Architecture for Reliable Server Pooling
<draft-ietf-rserpool-arch-01.txt> <draft-ietf-rserpool-arch-02.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of [RFC2026]. provisions of Section 10 of [RFC2026].
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
or to cite them other than as "work in progress." 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://www.ietf.org/ietf/1id-abstracts.txt http://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.
Abstract Abstract
The goal is to develop an architecture and protocols for the management This document describes an architecture and protocols for the management
and operation of server pools supporting highly reliable applications, and operation of server pools supporting highly reliable applications,
and for client access mechanisms to a server pool. and for client access mechanisms to a server pool.
A proposed architecture is presented and illustrated by examples. [Editors note] This version is used as an input document for an
editors meeting and will updated shortly after that.
1. Introduction 1. Introduction
1.1. Overview 1.1. Overview
The Internet is always on. Many users expect services to be always
available; many business depend upon connectivity 24 hours a day, 7 days
a week, 365 days a year. In order to fulfill this, many proprietary
solutions and operating system dependent solutions have been developed
to provide highly reliable and highly available servers.
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 using
servers grouped into pools. Therefore, if a client wants to access a servers grouped into pools. Therefore, if a client wants to access a
server pool, it will be able to use any of the servers in the server server pool, it will be able to use any of the servers in the server
pool taking into account the server pool policy. pool. Several server selection mechanisms, called server pool policies,
are supported.
Highly available services also put the same high reliability
requirements upon the transport layer protocol beneath RSerPool - it
must provide strong survivability in the face of network component
failures.
Supporting real time applications is another main focus of RSerPool
which leads to requirements on the processing time needed.
Scalability is another important requirement. For accessing a server pool a flat system of name servers can be used.
The architecture of these name servers is also described in this
document.
1.2. Terminology 1.2. Terminology
This document uses the following terms: This document uses the following terms:
Operation scope: Operation scope:
The part of the network visible to pool users by a specific The part of the network visible to pool users by a specific
instance of the reliable server pooling protocols. instance of the reliable server pooling protocols.
Pool (or server pool): Pool (or server pool):
skipping to change at page 3, line 24 skipping to change at page 3, line 15
Name server: Name server:
Entity which the responsible for managing and maintaining the Entity which the responsible for managing and maintaining the
name space within the RSerPool operation scope. name space within the RSerPool operation scope.
1.3. Abbreviations 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
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 discuss what a typical reliable server pool
architecture may look like. 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). - Pool Elements (PEs).
- Name Servers, also called ENRP Servers. - Name Servers, also called ENRP Servers (ESs).
- Pool Users (PUs). - Pool Users (PUs).
A server pool is defined as a set of one or more servers providing the A server pool is defined as a set of one or more servers providing the
same application functionality. These servers are called Pool Elements same application functionality. These servers are called Pool Elements
(PEs). Using multiple PEs in a server pool can be for fault tolerance or (PEs). Multiple PEs in a server pool can be used to provide fault
load sharing, for example. tolerance or load sharing, for example.
Each server pool will be identifiable by a unique name which is simply Each server pool will be identifiable by a unique name which is simply a
an ASCII string, called the pool handle. To fulfill the performance byte string, called the pool handle.
requirements given in [RFC3237] these names are not valid in the whole
Internet but only in smaller parts, called the operational scope. Also, [Editors note] Isn't a byte string more appropriate than an ASCII
the namespace is flat. string.
To fulfill the performance requirements given in [RFC3237] these names
are not valid in the whole Internet but only in smaller parts, called
the operational scope. Also, the namespace is flat.
The second class of entities in the RSerPool architecture is the class The second class of entities in the RSerPool architecture is the class
of the so called name servers. These name servers can resolve a pool of the so called name servers. These name servers can resolve a pool
handle to a list of transport layer end-point addresses of PEs of the handle to a list of information which allows the PU to access a PE of
server pool identified by the handle. the server pool identified by the handle. This information includes:
Editors note: Should we talk about UDP, TCP, SCTP specifically? - A protocol field of the IP header specifying the upper layer
protocol.
- 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 In each operational scope there must be at least one name server. Most
likely there will be more than one. All these servers have the complete likely there will be more than one. All these name servers have the
knowledge about all server pools in the operational scope. The name complete knowledge about all server pools in the operational scope. The
servers use a protocol called Endpoint Name Resolution Protocol (ENRP) name servers use a protocol called Endpoint Name Resolution Protocol
to communication which each other to make sure that all have the same (ENRP) for communication which each other to make sure that all have the
information about the server pools. same information about the server pools. The name servers are also
called ENRP servers.
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.
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 must
know the pool handle of the server pool. The PU then uses the Aggregate know the pool handle of the server pool. The PU then uses the Aggregate
Server Access Protocol (ASAP) to query for transport layer addresses of Server Access Protocol (ASAP) to query for transport layer addresses of
PEs belonging to the server pool identified by the pool handle. PEs belonging to the server pool identified by the pool handle.
[RFC3237] also requires that the name servers should not resolve a pool [RFC3237] also requires that the name servers should not resolve a pool
handle to a transport layer address of a PE which is not in operation. handle to a transport layer address of a PE which is not in operation.
Therefore each PE is supervised by one specific name server, called the Therefore each PE is supervised by one specific name server, called the
home ENRP server of that PE. If it detects that the PE is out of service home ENRP server of that PE. If it detects that the PE is out of service
all other name servers are informed by using ENRP. 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 the home ENRP server. which will normally the home ENRP server.
2.2. RSerPool Protocol Overview 2.2. RSerPool Protocol Overview
The RSerPool requested features can be obtained with the help of two The RSerPool requested features can be obtained with the help of two
protocols: ENRP (Endpoint Name Resolution Protocol) and ASAP (Aggregate protocols: ENRP (Endpoint Name Resolution Protocol) and ASAP (Aggregate
Server Access Protocol). Server Access Protocol).
2.2.1. Endpoint Name Resolution Protocol
ENRP is designed to provide a fully distributed fault-tolerant real-time ENRP is designed to provide a fully distributed fault-tolerant real-time
translation service that maps a name to a set of transport addresses translation service that maps a name to a set of transport addresses
pointing to a specific group of networked communication endpoints pointing to a specific group of networked communication endpoints
registered under that name. ENRP employs a client-server model with registered under that name. ENRP employs a client-server model with
which an ENRP server will respond to the name translation service which an ENRP server will respond to the name translation service
requests from endpoint clients running on the same host or running on requests from endpoint clients running on the same host or running on
different hosts. different hosts.
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 address(es),
thus effectively eliminating the binding between the communication thus effectively eliminating the binding between the communication
endpoint and its physical IP address(es) which normally constitutes a endpoint and its physical IP address(es) which normally constitutes a
single point of failure. 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 and
load sharing. It also allows dynamic system scalability - members of a load sharing. It also allows dynamic system scalability - members of a
server pool can be added or removed at any time without interrupting the server pool can be added or removed at any time without interrupting the
service. service.
The fault tolerant server pooling is gained by combining two parts, 2.2.3. PU <-> ES Communication
namely ASAP and ENRP. ASAP provides the user interface for name to
address translation, load sharing management, and fault management. ENRP
defines the fault tolerant name translation service. The protocol stack
used is described by the following figure 1.
********* *********** The PU <-> ES communication is used for doing name queries. The PU sends
* PE/PU * *ENRP Srvr* a pool handle to the ENRP server and gets back the information necessary
********* *********** for accessing a server in a server pool.
+-------+ +----+----+ ******** ********
To other <-->| ASAP |<------>|ASAP|ENRP| <---To Peer ENRP * PU * * ES *
PE/PU +-------+ +----+----+ Name Servers ******** ********
+------+ +------+
| ASAP | | ASAP |
+------+ +------+
| SCTP | | SCTP | | SCTP | | SCTP |
+-------+ +---------+ +------+ +------+
| IP | | IP | | IP | | IP |
+-------+ +---------+ +------+ +------+
Figure 1: Typical protocol stack 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
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 figure 2.
******** ********
* PU * * ES *
******** ********
+------+ +------+
| ASAP | | ASAP |
+------+ +------+
| TCP | | TCP |
+------+ +------+
| IP | | IP |
+------+ +------+
Figure 2: Protocol stack between PU and ENRP server (TCP variant)
2.2.4. PE <-> ES Communication
The PE <-> ES communication is used for registration and deregistration
of the PE in one ore more pools and for the supervision of the PE by the
ENRP server. This communication is based on SCTP, the protocol stack is
shown in figure 3.
******** ********
* PE * * ES *
******** ********
+------+ +------+
| ASAP | | ASAP |
+------+ +------+
| SCTP | | SCTP |
+------+ +------+
| IP | | IP |
+------+ +------+
Figure 3: Protocol stack between PE and ENRP server
2.2.5. PU <-> PE Communication
The PU <-> PE communication is based on some IP based protocol. The
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.
******** ********
* PU * * PE *
******** ********
+------+ +------+
| ULP | | ULP |
+------+ +------+
| IP | | IP |
+------+ +------+
Figure 4: Protocol stack between PU and PE
[Editors note] This does not provide the necessary communication
for exchanging 'business cards'.
2.2.6. ES <-> ES Communication
The communication between ENRP servers is used to share the knowledge
about all server pools between all ENRP servers in an operational scope.
******** ********
* ES * * ES *
******** ********
+------+ +------+
| ENRP | | ENRP |
+------+ +------+
| SCTP | | SCTP |
+------+ +------+
| IP | | IP |
+------+ +------+
Figure 5: Protocol stack between PE and ENRP server
[Editors note] What about the multicast based ENRP server
detection.
2.2.7. PE <-> PE Communication
[Editors note] This is a special case of the PU <-> PE
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 2.3. 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 . ~
skipping to change at page 6, line 36 skipping to change at page 8, line 36
~ | +++++++++++++++ +++++++++++++++ | ~ ~ | +++++++++++++++ +++++++++++++++ | ~
~ v ^ ^ | ~ ~ v ^ ^ | ~
~ ********* | | | ~ ~ ********* | | | ~
~ * PU(A) *<-------+ (b)| | ~ ~ * PU(A) *<-------+ (b)| | ~
~ ********* (b) | | ~ ~ ********* (b) | | ~
~ v | ~ ~ v | ~
~ ::::::::::::::::: (f) ***************** | ~ ~ ::::::::::::::::: (f) ***************** | ~
~ : Other Clients :<------------->* Proxy/Gateway * <---+ ~ ~ : Other Clients :<------------->* Proxy/Gateway * <---+ ~
~ ::::::::::::::::: ***************** ~ ~ ::::::::::::::::: ***************** ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Figure 2: RSerPool components and their possible interactions. Figure 6: RSerPool components and their possible interactions.
In figure 2 we can identify the following possible interactions: In figure 6 we can identify the following possible interactions:
(a) Server Pool Elements <-> ENRP Server: (ASAP) (a) Server Pool Elements <-> ENRP Server: (ASAP)
Each PE in a pool uses ASAP to register or de-register itself Each PE in a pool uses ASAP to register or de-register itself
as well as to exchange other auxiliary information with the as well as to exchange other auxiliary information with the
ENRP Server. The ENRP Server also uses ASAP to monitor the ENRP Server. The ENRP Server also uses ASAP to monitor the
operational status of each PE in a pool. operational status of each PE in a pool.
(b) PU <-> ENRP Server: (ASAP) (b) PU <-> ENRP Server: (ASAP)
skipping to change at page 7, line 31 skipping to change at page 9, line 31
(f) Other Clients <-> Proxy/Gateway: standard protocols (f) Other Clients <-> Proxy/Gateway: standard protocols
The proxy/gateway enables clients ("other clients"), which are The proxy/gateway enables clients ("other clients"), which are
not RSerPool aware, to access services provided by an RSerPool not RSerPool aware, to access services provided by an RSerPool
based server pool. It should be noted that these based server pool. It should be noted that these
proxies/gateways may become a single point of failure. proxies/gateways may become a single point of failure.
3. Examples 3. Examples
[Editors note] This section has not been updated. The examples will
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 described.
First an RSerPool aware FTP server is considered. The interaction with First an RSerPool aware FTP server is considered. The interaction with
an RSerPool aware and an non-aware client is given. Finally, a telephony an RSerPool aware and an non-aware client is given. Finally, a telephony
example is considered. 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 to
skipping to change at page 8, line 32 skipping to change at page 10, line 36
~ |(d) |(c) | | | ~ ~ |(d) |(c) | | | ~
~ | v v v v ~ ~ | v v v v ~
~ | ********* +++++++++++++++ ~ ~ | ********* +++++++++++++++ ~
~ + ->* PU(X) * + ENRP-Server + ~ ~ + ->* PU(X) * + ENRP-Server + ~
~ ********* +++++++++++++++ ~ ~ ********* +++++++++++++++ ~
~ ^ ASAP ^ ~ ~ ^ ASAP ^ ~
~ | <-(b) | ~ ~ | <-(b) | ~
~ +--------------+ ~ ~ +--------------+ ~
~ (a)-> ~ ~ (a)-> ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Figure 3: Architecture for RSerPool aware client. Figure 7: 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 ASAP layer would send an ASAP request to its ENRP PU(X)'s ASAP layer would send an ASAP request to its ENRP
server to request the list of pool elements (using (a)). The server to request the list of pool elements (using (a)). The
pool handle to identify the pool would be "File Transfer pool handle to identify the pool would be "File Transfer
Pool". The ASAP layer queues the login request. Pool". The ASAP layer queues the login request.
(2) The ENRP server would return a list of the three PEs PE(1,A), (2) The ENRP server 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,B) and 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
transmitts the login request, the other FTP control data transmits the login request, the other FTP control data
finally starts the transmission of the requested files (using finally starts the transmission of the requested files (using
(c)). For this the multiple stream feature of SCTP could be (c)). For 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 the PE's were sharing state of file transfer, a fail- assuming the PE's were sharing state of file transfer, a fail-
over to PE(1,A) could be initiated. PE(1,A) would continue the over to PE(1,A) could be initiated. PE(1,A) would continue the
transfer until complete (see (d)). In parallel a request from transfer until complete (see (d)). In parallel a request from
PE(1,A) would be made to ENRP to request a cache update for PE(1,A) would be made to ENRP to request a cache update for
the server pool "File Transfer Pool" and a report would also the server pool "File Transfer Pool" and a report would also
skipping to change at page 9, line 47 skipping to change at page 11, line 51
~ | +++++++++++++++ +++++++++++++++ ~ ~ | +++++++++++++++ +++++++++++++++ ~
~ | 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 4: Architecture for RserPool unaware client. Figure 8: 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 protocol. The client sends the login request to the proxy ftp protocol. The client sends the login request to the proxy
(using (e)) (using (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 (a), (b) and (c)). (using (a), (b) and (c)).
skipping to change at page 11, line 30 skipping to change at page 13, line 30
| v | v
+++++++++++++++ ********* ***************** +++++++++++++++ ********* *****************
+ ENRP-Server + * SG(X) * * Media Gateway * + ENRP-Server + * SG(X) * * Media Gateway *
+++++++++++++++ ********* ***************** +++++++++++++++ ********* *****************
^ ^ ^ ^
| | | |
| <-(a) | | <-(a) |
+-------------------+ +-------------------+
(b)-> (b)->
Figure 5: Deployment of Decomposed GWC and GK. Figure 9: Deployment of Decomposed GWC and GK.
As shown in the figure 5, the following sequence takes place: As shown in the figure 9, the following sequence takes place:
(1) the Signaling Gateway (SG) receives an incoming signaling (1) the Signaling Gateway (SG) receives an incoming signaling
message to be forwarded to the GWC. SG(X)'s ASAP layer would message to be forwarded to the GWC. SG(X)'s ASAP layer would
send an ASAP request to its "local" ENRP server to request the send an ASAP request to its "local" ENRP server to request the
list of pool elements (PE's) of GWC (using (a)). The key used list of pool elements (PE's) of GWC (using (a)). The key used
for this query is the pool handle of the GWC. The ASAP layer for this query is the pool handle of the GWC. The ASAP layer
queues the data to be sent in local buffers until the ENRP queues the data to be sent in local buffers until the ENRP
server responds. server responds.
(2) the ENRP server would return a list of the three PE's A, B and (2) the ENRP server would return a list of the three PE's A, B and
skipping to change at page 13, line 31 skipping to change at page 15, line 31
v v v v
+++++++++++++++ ********* ***************** +++++++++++++++ ********* *****************
+ ENRP-Server + * SG(X) * * Media Gateway * + ENRP-Server + * SG(X) * * Media Gateway *
+++++++++++++++ ********* ***************** +++++++++++++++ ********* *****************
^ ^ ^ ^
| | | |
| <-(a) | | <-(a) |
+-------------------+ +-------------------+
(b)-> (b)->
Figure 6: Deployment of Collocated GWC and GK. Figure 10: 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, Matt Holdrege, The authors would like to thank Bernard Aboba, Harrie Hazewinkel, Matt
Christopher Ross, Werner Vogels and many others for their invaluable Holdrege, Christopher Ross, Werner Vogels and many others for their
comments and suggestions. invaluable comments and suggestions.
5. References 5. References
[RFC793] J. B. Postel, "Transmission Control Protocol", RFC 793, [RFC793] J. B. Postel, "Transmission Control Protocol", RFC 793,
September 1981. September 1981.
[RFC959] J. B. Postel, J. Reynolds, "File Transfer Protocol (FTP)", [RFC959] J. B. Postel, J. Reynolds, "File Transfer Protocol (FTP)",
RFC 959, October 1985. RFC 959, October 1985.
[RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3",
skipping to change at page 15, line 17 skipping to change at page 17, line 17
PO Box 407 PO Box 407
FIN-00045 Nokia Group FIN-00045 Nokia Group
Finland Finland
Maureen Stillman Tel.: +1 607 273 0724 62 Maureen Stillman Tel.: +1 607 273 0724 62
Nokia e-mail: maureen.stillman@nokia.com Nokia e-mail: maureen.stillman@nokia.com
127 W. State Street 127 W. State Street
Ithaca, NY 14850 Ithaca, NY 14850
USA USA
This Internet Draft expires September 1, 2002. This Internet Draft expires October 24, 2002.
 End of changes. 

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