idnits 2.17.1 draft-ietf-rserpool-arch-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1, 2002) is 8084 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC793' is defined on line 579, but no explicit reference was found in the text == Unused Reference: 'RFC2608' is defined on line 588, but no explicit reference was found in the text == Unused Reference: 'RFC2719' is defined on line 591, but no explicit reference was found in the text == Unused Reference: 'RFC2960' is defined on line 594, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Downref: Normative reference to an Informational RFC: RFC 2719 ** Obsolete normative reference: RFC 2960 (Obsoleted by RFC 4960) ** Downref: Normative reference to an Informational RFC: RFC 3237 Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Tuexen 3 INTERNET DRAFT Siemens AG 4 Q. Xie 5 Motorola 6 R. Stewart 7 M. Shore 8 Cisco 9 L. Ong 10 Point Reyes Networks 11 J. Loughney 12 M. Stillman 13 Nokia 14 Expires September 1, 2002 March 1, 2002 16 Architecture for Reliable Server Pooling 17 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with all 22 provisions of Section 10 of [RFC2026]. 24 Internet-Drafts are working documents of the Internet Engineering Task 25 Force (IETF), its areas, and its working groups. Note that other groups 26 may also distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet Drafts as reference material 31 or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 The goal is to develop an architecture and protocols for the management 42 and operation of server pools supporting highly reliable applications, 43 and for client access mechanisms to a server pool. 45 A proposed architecture is presented and illustrated by examples. 47 1. Introduction 49 1.1. Overview 51 The Internet is always on. Many users expect services to be always 52 available; many business depend upon connectivity 24 hours a day, 7 days 53 a week, 365 days a year. In order to fulfill this, many proprietary 54 solutions and operating system dependent solutions have been developed 55 to provide highly reliable and highly available servers. 57 This document defines a proposed architecture, which can be used to 58 provide highly available services. The way this is achieved is by using 59 servers grouped into pools. Therefore, if a client wants to access a 60 server pool, it will be able to use any of the servers in the server 61 pool taking into account the server pool policy. 63 Highly available services also put the same high reliability 64 requirements upon the transport layer protocol beneath RSerPool - it 65 must provide strong survivability in the face of network component 66 failures. 68 Supporting real time applications is another main focus of RSerPool 69 which leads to requirements on the processing time needed. 71 Scalability is another important requirement. 73 1.2. Terminology 75 This document uses the following terms: 77 Operation scope: 78 The part of the network visible to pool users by a specific 79 instance of the reliable server pooling protocols. 81 Pool (or server pool): 82 A collection of servers providing the same application 83 functionality. 85 Pool handle (or pool name): 86 A logical pointer to a pool. Each server pool will be 87 identifiable in the operation scope of the system by a unique 88 pool handle or "name". 90 Pool element: 91 A server entity having registered to a pool. 93 Pool user: 94 A server pool user. 96 Pool element handle (or endpoint handle): 97 A logical pointer to a particular pool element in a pool, 98 consisting of the name of the pool and a destination transport 99 address of the pool element. 101 Name space: 102 A cohesive structure of pool names and relations that may be 103 queried by an internal or external agent. 105 Name server: 106 Entity which the responsible for managing and maintaining the 107 name space within the RSerPool operation scope. 109 1.3. Abbreviations 111 ASAP: Aggregate Server Access Protocol 113 ENRP: Endpoint Name Resolution Protocol 115 PE: Pool element 117 PU: Pool user 119 SCTP: Stream Control Transmission Protocol 121 TCP: Transmission Control Protocol 123 2. Reliable Server Pooling Architecture 125 In this section, we discuss what a typical reliable server pool 126 architecture may look like. 128 2.1. RSerPool Functional Components 130 There are three classes of entities in the RSerPool architecture: 132 - Pool Elements (PEs). 134 - Name Servers, also called ENRP Servers. 136 - Pool Users (PUs). 138 A server pool is defined as a set of one or more servers providing the 139 same application functionality. These servers are called Pool Elements 140 (PEs). Using multiple PEs in a server pool can be for fault tolerance or 141 load sharing, for example. 143 Each server pool will be identifiable by a unique name which is simply 144 an ASCII string, called the pool handle. To fulfill the performance 145 requirements given in [RFC3237] these names are not valid in the whole 146 Internet but only in smaller parts, called the operational scope. Also, 147 the namespace is flat. 149 The second class of entities in the RSerPool architecture is the class 150 of the so called name servers. These name servers can resolve a pool 151 handle to a list of transport layer end-point addresses of PEs of the 152 server pool identified by the handle. 154 Editors note: Should we talk about UDP, TCP, SCTP specifically? 156 In each operational scope there must be at least one name server. Most 157 likely there will be more than one. All these servers have the complete 158 knowledge about all server pools in the operational scope. The name 159 servers use a protocol called Endpoint Name Resolution Protocol (ENRP) 160 to communication which each other to make sure that all have the same 161 information about the server pools. 163 A client being served by a PE of a server pool is called a Pool User 164 (PU). This is the third class of entities in the RSerPool architecture. 166 The PU wants to be served by a PE of a particular server pool it must 167 know the pool handle of the server pool. The PU then uses the Aggregate 168 Server Access Protocol (ASAP) to query for transport layer addresses of 169 PEs belonging to the server pool identified by the pool handle. 171 [RFC3237] also requires that the name servers should not resolve a pool 172 handle to a transport layer address of a PE which is not in operation. 173 Therefore each PE is supervised by one specific name server, called the 174 home ENRP server of that PE. If it detects that the PE is out of service 175 all other name servers are informed by using ENRP. 177 ASAP is also used by a server to join or leave a server pool. It 178 registers or deregisters itself by communicating with a name server, 179 which will normally the the home ENRP server. 181 2.2. RSerPool Protocol Overview 183 The RSerPool requested features can be obtained with the help of two 184 protocols: ENRP (Endpoint Name Resolution Protocol) and ASAP (Aggregate 185 Server Access Protocol). 187 ENRP is designed to provide a fully distributed fault-tolerant real-time 188 translation service that maps a name to a set of transport addresses 189 pointing to a specific group of networked communication endpoints 190 registered under that name. ENRP employs a client-server model with 191 which an ENRP server will respond to the name translation service 192 requests from endpoint clients running on the same host or running on 193 different hosts. 195 ASAP in conjunction with ENRP provides a fault tolerant data transfer 196 mechanism over IP networks. ASAP uses a name-based addressing model 197 which isolates a logical communication endpoint from its IP address(es), 198 thus effectively eliminating the binding between the communication 199 endpoint and its physical IP address(es) which normally constitutes a 200 single point of failure. 202 In addition, ASAP defines each logical communication destination as a 203 server pool, providing full transparent support for server-pooling and 204 load sharing. It also allows dynamic system scalability - members of a 205 server pool can be added or removed at any time without interrupting the 206 service. 208 The fault tolerant server pooling is gained by combining two parts, 209 namely ASAP and ENRP. ASAP provides the user interface for name to 210 address translation, load sharing management, and fault management. ENRP 211 defines the fault tolerant name translation service. The protocol stack 212 used is described by the following figure 1. 214 ********* *********** 215 * PE/PU * *ENRP Srvr* 216 ********* *********** 218 +-------+ +----+----+ 219 To other <-->| ASAP |<------>|ASAP|ENRP| <---To Peer ENRP 220 PE/PU +-------+ +----+----+ Name Servers 221 | SCTP | | SCTP | 222 +-------+ +---------+ 223 | IP | | IP | 224 +-------+ +---------+ 225 Figure 1: Typical protocol stack 227 2.3. Typical Interactions between RSerPool Components 229 The following drawing shows the typical RSerPool components and their 230 possible interactions with each other: 232 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 233 ~ operation scope ~ 234 ~ ......................... ......................... ~ 235 ~ . Server Pool 1 . . Server Pool 2 . ~ 236 ~ . +-------+ +-------+ . (d) . +-------+ +-------+ . ~ 237 ~ . |PE(1,A)| |PE(1,C)|<-------------->|PE(2,B)| |PE(2,A)|<---+ ~ 238 ~ . +-------+ +-------+ . . +-------+ +-------+ . | ~ 239 ~ . ^ ^ . . ^ ^ . | ~ 240 ~ . | (a) | . . | | . | ~ 241 ~ . +----------+ | . . | | . | ~ 242 ~ . +-------+ | | . . | | . | ~ 243 ~ . |PE(1,B)|<---+ | | . . | | . | ~ 244 ~ . +-------+ | | | . . | | . | ~ 245 ~ . ^ | | | . . | | . | ~ 246 ~ .......|........|.|.|.... .......|.........|....... | ~ 247 ~ | | | | | | | ~ 248 ~ (c)| (a)| | |(a) (a)| (a)| (c)| ~ 249 ~ | | | | | | | ~ 250 ~ | v v v v v | ~ 251 ~ | +++++++++++++++ (e) +++++++++++++++ | ~ 252 ~ | + ENRP-Server +<---------->+ ENRP-Server + | ~ 253 ~ | +++++++++++++++ +++++++++++++++ | ~ 254 ~ v ^ ^ | ~ 255 ~ ********* | | | ~ 256 ~ * PU(A) *<-------+ (b)| | ~ 257 ~ ********* (b) | | ~ 258 ~ v | ~ 259 ~ ::::::::::::::::: (f) ***************** | ~ 260 ~ : Other Clients :<------------->* Proxy/Gateway * <---+ ~ 261 ~ ::::::::::::::::: ***************** ~ 262 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 263 Figure 2: RSerPool components and their possible interactions. 265 In figure 2 we can identify the following possible interactions: 267 (a) Server Pool Elements <-> ENRP Server: (ASAP) 269 Each PE in a pool uses ASAP to register or de-register itself 270 as well as to exchange other auxiliary information with the 271 ENRP Server. The ENRP Server also uses ASAP to monitor the 272 operational status of each PE in a pool. 274 (b) PU <-> ENRP Server: (ASAP) 276 A PU normally uses ASAP to request the ENRP Server for a name- 277 to-address translation service before the PU can send user 278 messages addressed to a server pool by the pool's name. 280 (c) PU <-> PE: (ASAP) 282 ASAP can be used to exchange some auxiliary information of the 283 two parties before they engage in user data transfer. 285 (d) Server Pool <-> Server Pool: (ASAP) 287 A PE in a server pool can become a PU to another pool when the 288 PE tries to initiate communication with the other pool. In 289 such a case, the interactions described in B) and C) above 290 will apply. 292 (e) ENRP Server <-> ENRP Server: (ENRP) 294 ENRP can be used to fulfill various Name Space operation, 295 administration, and maintenance (OAM) functions. 297 (f) Other Clients <-> Proxy/Gateway: standard protocols 299 The proxy/gateway enables clients ("other clients"), which are 300 not RSerPool aware, to access services provided by an RSerPool 301 based server pool. It should be noted that these 302 proxies/gateways may become a single point of failure. 304 3. Examples 306 In this section the basic concepts of ENRP and ASAP will be described. 307 First an RSerPool aware FTP server is considered. The interaction with 308 an RSerPool aware and an non-aware client is given. Finally, a telephony 309 example is considered. 311 3.1. Two File Transfer Examples 313 In this section we present two separate file transfer examples using 314 ENRP and ASAP. We present two separate examples demonstrating an 315 ENRP/ASAP aware client and a client that is using a Proxy or Gateway to 316 perform the file transfer. In this example we will use a FTP [RFC959] 317 model with some modifications. The first example (the RSerPool aware 318 one) will modify FTP concepts so that the file transfer takes place over 319 SCTP. In the second example we will use TCP between the unaware client 320 and the Proxy. The Proxy itself will use the modified FTP with RSerPool 321 as illustrated in the first example. 323 Please note that in the example we do NOT follow FTP [RFC959] precisely 324 but use FTP-like concepts and attempt to adhere to the basic FTP model. 325 These examples use FTP for illustrative purposes, FTP was chosen since 326 many of the basic concept are well known and should be familiar to 327 readers. 329 3.1.1. The RSerPool Aware Client 331 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 332 ~ operation scope ~ 333 ~ ......................... ~ 334 ~ . "File Transfer Pool" . ~ 335 ~ . +-------+ +-------+ . ~ 336 ~ +-> |PE(1,A)| |PE(1,C)| . ~ 337 ~ |. +-------+ +-------+ . ~ 338 ~ |. ^ ^ . ~ 339 ~ |. +----------+ | . ~ 340 ~ |. +-------+ | | . ~ 341 ~ |. |PE(1,B)|<---+ | | . ~ 342 ~ |. +-------+ | | | . ~ 343 ~ |. ^ | | | . ~ 344 ~ |.......|........|.|.|.... ~ 345 ~ | ASAP | ASAP| | |ASAP ~ 346 ~ |(d) |(c) | | | ~ 347 ~ | v v v v ~ 348 ~ | ********* +++++++++++++++ ~ 349 ~ + ->* PU(X) * + ENRP-Server + ~ 350 ~ ********* +++++++++++++++ ~ 351 ~ ^ ASAP ^ ~ 352 ~ | <-(b) | ~ 353 ~ +--------------+ ~ 354 ~ (a)-> ~ 355 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 356 Figure 3: Architecture for RSerPool aware client. 358 To effect a file transfer the following steps would take place. 360 (1) The application in PU(X) would send a login request. The 361 PU(X)'s ASAP layer would send an ASAP request to its ENRP 362 server to request the list of pool elements (using (a)). The 363 pool handle to identify the pool would be "File Transfer 364 Pool". The ASAP layer queues the login request. 366 (2) The ENRP server would return a list of the three PEs PE(1,A), 367 PE(1,B) and PE(1,C) to the ASAP layer in PU(X) (using (b)). 369 (3) The ASAP layer selects one of the PEs, for example PE(1,B). It 370 transmitts the login request, the other FTP control data 371 finally starts the transmission of the requested files (using 372 (c)). For this the multiple stream feature of SCTP could be 373 used. 375 (4) If during the file transfer conversation, PE(1,B) fails, 376 assuming the PE's were sharing state of file transfer, a fail- 377 over to PE(1,A) could be initiated. PE(1,A) would continue the 378 transfer until complete (see (d)). In parallel a request from 379 PE(1,A) would be made to ENRP to request a cache update for 380 the server pool "File Transfer Pool" and a report would also 381 be made that PE(1,B) is non-responsive (this would cause 382 appropriate audits that may remove PE(1,B) from the pool if 383 the ENRP servers had not already detected the failure) (using 384 (a)). 386 3.1.2. The RSerPool Unaware Client 388 In this example we investigate the use of a Proxy server assuming the 389 same set of scenario as illustrated above. 391 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 392 ~ operation scope ~ 393 ~ ......................... ~ 394 ~ . "File Transfer Pool" . ~ 395 ~ . +-------+ +-------+ . ~ 396 ~ . |PE(1,A)| |PE(1,C)| . ~ 397 ~ . +-------+ +-------+ . ~ 398 ~ . ^ ^ . ~ 399 ~ . +----------+ | . ~ 400 ~ . +-------+ | | . ~ 401 ~ . |PE(1,B)|<---+ | | . ~ 402 ~ . +-------+ | | | . ~ 403 ~ .......^........|.|.|.... ~ 404 ~ | | | | ~ 405 ~ | ASAP| | |ASAP ~ 406 ~ | | | | ~ 407 ~ | v v v ~ 408 ~ | +++++++++++++++ +++++++++++++++ ~ 409 ~ | + ENRP-Server +<--ENRP-->+ ENRP-Server + ~ 410 ~ | +++++++++++++++ +++++++++++++++ ~ 411 ~ | ASAP ^ ~ 412 ~ | ASAP (c) (b) | ^ ~ 413 ~ +---------------------------------+ | | | ~ 414 ~ | v | (a) ~ 415 ~ v v ~ 416 ~ ::::::::::::::::: (e)-> ***************** ~ 417 ~ : FTP Client :<------------->* Proxy/Gateway * ~ 418 ~ ::::::::::::::::: (f) ***************** ~ 419 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 420 Figure 4: Architecture for RserPool unaware client. 422 In this example the steps will occur: 424 (1) The FTP client and the Proxy/Gateway are using the TCP-based 425 ftp protocol. The client sends the login request to the proxy 426 (using (e)) 428 (2) The proxy behaves like a client and performs the actions 429 described under (1), (2) and (3) of the above description 430 (using (a), (b) and (c)). 432 (3) The ftp communication continues and will be translated by the 433 proxy into the RSerPool aware dialect. This interworking uses 434 (f) and (c). 436 Note that in this example high availability is maintained between the 437 Proxy and the server pool but a single point of failure exists between 438 the FTP client and the Proxy, i.e. the command TCP connection and its 439 one IP address it is using for commands. 441 3.2. Telephony Signaling Example 443 This example shows the use of ASAP/RSerPool to support server pooling 444 for high availability of a telephony application such as a Voice over IP 445 Gateway Controller (GWC) and Gatekeeper services (GK). 447 In this example, we show two different scenarios of deploying these 448 services using RSerPool in order to illustrate the flexibility of the 449 RSerPool architecture. 451 3.2.1. Decomposed GWC and GK Scenario 453 In this scenario, both GWC and GK services are deployed as separate 454 pools with some number of PEs, as shown in the following diagram. Each 455 of the pools will register their unique pool handle (i.e. name) with the 456 ENRP Server. We also assume that there are a Signaling Gateway (SG) and 457 a Media Gateway (MG) present and both are RSerPool aware. 459 ................... 460 . Gateway . 461 . Controller Pool . 462 ................. . +-------+ . 463 . Gatekeeper . . |PE(2,A)| . 464 . Pool . . +-------+ . 465 . +-------+ . . +-------+ . 466 . |PE(1,A)| . . |PE(2,B)| . 467 . +-------+ . . +-------+ . 468 . +-------+ . (d) . +-------+ . 469 . |PE(1,B)|<------------>|PE(2,C)|<-------------+ 470 . +-------+ . . +-------+ . | 471 ................. ........^.......... | 472 | | 473 (c)| (e)| 474 | v 475 +++++++++++++++ ********* ***************** 476 + ENRP-Server + * SG(X) * * Media Gateway * 477 +++++++++++++++ ********* ***************** 478 ^ ^ 479 | | 480 | <-(a) | 481 +-------------------+ 482 (b)-> 484 Figure 5: Deployment of Decomposed GWC and GK. 486 As shown in the figure 5, the following sequence takes place: 488 (1) the Signaling Gateway (SG) receives an incoming signaling 489 message to be forwarded to the GWC. SG(X)'s ASAP layer would 490 send an ASAP request to its "local" ENRP server to request the 491 list of pool elements (PE's) of GWC (using (a)). The key used 492 for this query is the pool handle of the GWC. The ASAP layer 493 queues the data to be sent in local buffers until the ENRP 494 server responds. 496 (2) the ENRP server would return a list of the three PE's A, B and 497 C to the ASAP layer in SG(X) together with information to be 498 used for load-sharing traffic across the gateway controller 499 pool (using (b)). 501 (3) the ASAP layer in SG(X) will select one PE (e.g., PE(2,C)) and 502 send the signaling message to it (using (c)). The selection is 503 based on the load sharing information of the gateway 504 controller pool. 506 (4) to progress the call, PE(2,C) finds that it needs to talk to 507 the Gatekeeper. Assuming it has already had gatekeeper pool's 508 information in its local cache (e.g., obtained and stored from 509 recent query to ENRP Server), PE(2,C) selects PE(1,B) and 510 sends the call control message to it (using (d)). 512 We assume PE(1,B) responds back to PE(2,C) and authorizes the 513 call to proceed. 515 (5) PE(2,C) issues media control commands to the Media Gateway 516 (using (e)). 518 RSerPool will provide service robustness to the system if some failure 519 would occur in the system. 521 For instance, if PE(1, B) in the Gatekeeper Pool crashed after receiving 522 the call control message from PE(2, C) in step (d) above, what most 523 likely will happen is that, due to the absence of a reply from the 524 Gatekeeper, a timer expiration event will trigger the call state machine 525 within PE(2, C) to resend the control message. The ASAP layer at PE(2, 526 C) will then notice the failure of PE(1, B) through (likely) the 527 endpoint unreachability detection by the transport protocol beneath ASAP 528 and automatically deliver the re-sent call control message to the 529 alternate GK pool member PE(1, A). With appropriate intra-pool call 530 state sharing support, PE(1, A) will be able to correctly handle the 531 call and reply to PE(2, C) and hence progress the call. 533 3.2.2. Collocated GWC and GK Scenario 535 In this scenario, the GWC and GK services are collocated (e.g., they are 536 implemented as a single process). In such a case, one can form a pool 537 that provides both GWC and GK services as shown in figure 6 below. 539 ........................................ 540 . Gateway Controller/Gatekeeper Pool . 541 . +-------+ . 542 . |PE(3,A)| . 543 . +-------+ . 544 . +-------+ . 545 . |PE(3,C)|<---------------------------+ 546 . +-------+ . | 547 . +-------+ ^ . | 548 . |PE(3,B)| | . | 549 . +-------+ | . | 550 ................|....................... | 551 | | 552 +-------------+ | 553 | | 554 (c)| (e)| 555 v v 556 +++++++++++++++ ********* ***************** 557 + ENRP-Server + * SG(X) * * Media Gateway * 558 +++++++++++++++ ********* ***************** 559 ^ ^ 560 | | 561 | <-(a) | 562 +-------------------+ 563 (b)-> 565 Figure 6: Deployment of Collocated GWC and GK. 567 The same sequence as described in 5.2.1 takes place, except that step 568 (4) now becomes internal to the PE(3,C) (again, we assume Server C is 569 selected by SG). 571 4. Acknowledgements 573 The authors would like to thank Bernard Aboba, Matt Holdrege, 574 Christopher Ross, Werner Vogels and many others for their invaluable 575 comments and suggestions. 577 5. References 579 [RFC793] J. B. Postel, "Transmission Control Protocol", RFC 793, 580 September 1981. 582 [RFC959] J. B. Postel, J. Reynolds, "File Transfer Protocol (FTP)", 583 RFC 959, October 1985. 585 [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", 586 RFC 2026, October 1996. 588 [RFC2608] E. Guttman et al., "Service Location Protocol, Version 2", 589 RFC 2608, June 1999. 591 [RFC2719] L. Ong et al., "Framework Architecture for Signaling 592 Transport", RFC 2719, October 1999. 594 [RFC2960] R. R. Stewart et al., "Stream Control Transmission 595 Protocol", RFC 2960, November 2000. 597 [RFC3237] M. Tuexen et al., "Requirements for Reliable Server 598 Pooling", RFC 3237, January 2002. 600 6. Authors' Addresses 602 Michael Tuexen Tel.: +49 89 722 47210 603 Siemens AG e-mail: Michael.Tuexen@icn.siemens.de 604 ICN WN CS SE 51 605 D-81359 Munich 606 Germany 608 Qiaobing Xie Tel.: +1 847 632 3028 609 Motorola, Inc. e-mail: qxie1@email.mot.com 610 1501 W. Shure Drive, #2309 611 Arlington Heights, Il 60004 612 USA 614 Randall Stewart Tel.: +1 815 477 2127 615 Cisco Systems, Inc. e-mail: rrs@cisco.com 616 24 Burning Bush Trail 617 Crystal Lake, Il 60012 618 USA 620 Melinda Shore Tel.: +1 607 272 7512 621 Cisco Systems, Inc. e-mail: mshore@cisco.com 622 809 Hayts Rd 623 Ithaca, NY 14850 624 USA 626 Lyndon Ong Tel.: +1 408 321 8237 627 Point Reyes Networks e-mail: long@pointreyesnet.com 628 1991 Concourse Drive 629 San Jose, CA 630 USA 631 John Loughney Tel.: 632 Nokia Research Center e-mail: john.loughney@nokia.com 633 PO Box 407 634 FIN-00045 Nokia Group 635 Finland 637 Maureen Stillman Tel.: +1 607 273 0724 62 638 Nokia e-mail: maureen.stillman@nokia.com 639 127 W. State Street 640 Ithaca, NY 14850 641 USA 643 This Internet Draft expires September 1, 2002.