idnits 2.17.1 draft-ietf-rserpool-arch-02.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-24) 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? ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 (April 24, 2002) is 8036 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 673, but no explicit reference was found in the text == Unused Reference: 'RFC2608' is defined on line 682, but no explicit reference was found in the text == Unused Reference: 'RFC2719' is defined on line 685, but no explicit reference was found in the text == Unused Reference: 'RFC2960' is defined on line 688, 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: 10 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 October 24, 2002 April 24, 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 This document describes 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 [Editors note] This version is used as an input document for an 46 editors meeting and will updated shortly after that. 48 1. Introduction 50 1.1. Overview 52 This document defines a proposed architecture, which can be used to 53 provide highly available services. The way this is achieved is by using 54 servers grouped into pools. Therefore, if a client wants to access a 55 server pool, it will be able to use any of the servers in the server 56 pool. Several server selection mechanisms, called server pool policies, 57 are supported. 59 For accessing a server pool a flat system of name servers can be used. 60 The architecture of these name servers is also described in this 61 document. 63 1.2. Terminology 65 This document uses the following terms: 67 Operation scope: 68 The part of the network visible to pool users by a specific 69 instance of the reliable server pooling protocols. 71 Pool (or server pool): 72 A collection of servers providing the same application 73 functionality. 75 Pool handle (or pool name): 76 A logical pointer to a pool. Each server pool will be 77 identifiable in the operation scope of the system by a unique 78 pool handle or "name". 80 Pool element: 81 A server entity having registered to a pool. 83 Pool user: 84 A server pool user. 86 Pool element handle (or endpoint handle): 87 A logical pointer to a particular pool element in a pool, 88 consisting of the name of the pool and a destination transport 89 address of the pool element. 91 Name space: 92 A cohesive structure of pool names and relations that may be 93 queried by an internal or external agent. 95 Name server: 96 Entity which the responsible for managing and maintaining the 97 name space within the RSerPool operation scope. 99 1.3. Abbreviations 101 ASAP: Aggregate Server Access Protocol 103 ENRP: Endpoint Name Resolution Protocol 105 ES: ENRP Server 107 PE: Pool element 109 PU: Pool user 111 SCTP: Stream Control Transmission Protocol 113 TCP: Transmission Control Protocol 115 2. Reliable Server Pooling Architecture 117 In this section, we discuss what a typical reliable server pool 118 architecture may look like. 120 2.1. RSerPool Functional Components 122 There are three classes of entities in the RSerPool architecture: 124 - Pool Elements (PEs). 126 - Name Servers, also called ENRP Servers (ESs). 128 - Pool Users (PUs). 130 A server pool is defined as a set of one or more servers providing the 131 same application functionality. These servers are called Pool Elements 132 (PEs). Multiple PEs in a server pool can be used to provide fault 133 tolerance or load sharing, for example. 135 Each server pool will be identifiable by a unique name which is simply a 136 byte string, called the pool handle. 138 [Editors note] Isn't a byte string more appropriate than an ASCII 139 string. 141 To fulfill the performance requirements given in [RFC3237] these names 142 are not valid in the whole Internet but only in smaller parts, called 143 the operational scope. Also, the namespace is flat. 145 The second class of entities in the RSerPool architecture is the class 146 of the so called name servers. These name servers can resolve a pool 147 handle to a list of information which allows the PU to access a PE of 148 the server pool identified by the handle. This information includes: 150 - A protocol field of the IP header specifying the upper layer 151 protocol. 153 - A port number if the upper layer protocol is SCTP, TCP or UDP. 155 In each operational scope there must be at least one name server. Most 156 likely there will be more than one. All these name servers have the 157 complete knowledge about all server pools in the operational scope. The 158 name servers use a protocol called Endpoint Name Resolution Protocol 159 (ENRP) for communication which each other to make sure that all have the 160 same information about the server pools. The name servers are also 161 called ENRP servers. 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 If 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 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 2.2.1. Endpoint Name Resolution Protocol 189 ENRP is designed to provide a fully distributed fault-tolerant real-time 190 translation service that maps a name to a set of transport addresses 191 pointing to a specific group of networked communication endpoints 192 registered under that name. ENRP employs a client-server model with 193 which an ENRP server will respond to the name translation service 194 requests from endpoint clients running on the same host or running on 195 different hosts. 197 2.2.2. Aggregate Server Access Protocol 199 ASAP in conjunction with ENRP provides a fault tolerant data transfer 200 mechanism over IP networks. ASAP uses a name-based addressing model 201 which isolates a logical communication endpoint from its IP address(es), 202 thus effectively eliminating the binding between the communication 203 endpoint and its physical IP address(es) which normally constitutes a 204 single point of failure. 206 In addition, ASAP defines each logical communication destination as a 207 server pool, providing full transparent support for server-pooling and 208 load sharing. It also allows dynamic system scalability - members of a 209 server pool can be added or removed at any time without interrupting the 210 service. 212 2.2.3. PU <-> ES Communication 214 The PU <-> ES communication is used for doing name queries. The PU sends 215 a pool handle to the ENRP server and gets back the information necessary 216 for accessing a server in a server pool. 218 ******** ******** 219 * PU * * ES * 220 ******** ******** 222 +------+ +------+ 223 | ASAP | | ASAP | 224 +------+ +------+ 225 | SCTP | | SCTP | 226 +------+ +------+ 227 | IP | | IP | 228 +------+ +------+ 229 Figure 1: Protocol stack between PU and ENRP server (SCTP variant) 231 If the PU does not use SCTP based services it may not be appropriate to 232 implement SCTP of PUs just to do the name queries. Therefore ASAP over 233 TCP can be used for doing the name queries. The protocol stack is shown 234 in figure 2. 236 ******** ******** 237 * PU * * ES * 238 ******** ******** 240 +------+ +------+ 241 | ASAP | | ASAP | 242 +------+ +------+ 243 | TCP | | TCP | 244 +------+ +------+ 245 | IP | | IP | 246 +------+ +------+ 247 Figure 2: Protocol stack between PU and ENRP server (TCP variant) 249 2.2.4. PE <-> ES Communication 251 The PE <-> ES communication is used for registration and deregistration 252 of the PE in one ore more pools and for the supervision of the PE by the 253 ENRP server. This communication is based on SCTP, the protocol stack is 254 shown in figure 3. 256 ******** ******** 257 * PE * * ES * 258 ******** ******** 260 +------+ +------+ 261 | ASAP | | ASAP | 262 +------+ +------+ 263 | SCTP | | SCTP | 264 +------+ +------+ 265 | IP | | IP | 266 +------+ +------+ 267 Figure 3: Protocol stack between PE and ENRP server 269 2.2.5. PU <-> PE Communication 271 The PU <-> PE communication is based on some IP based protocol. The 272 necessary information for setting up this communication by the PU is 273 provided by the ENRP Server to the PU. The protocol stack used between 274 the PU and the PE is shown in figure 4. 276 ******** ******** 277 * PU * * PE * 278 ******** ******** 280 +------+ +------+ 281 | ULP | | ULP | 282 +------+ +------+ 283 | IP | | IP | 284 +------+ +------+ 285 Figure 4: Protocol stack between PU and PE 287 [Editors note] This does not provide the necessary communication 288 for exchanging 'business cards'. 290 2.2.6. ES <-> ES Communication 292 The communication between ENRP servers is used to share the knowledge 293 about all server pools between all ENRP servers in an operational scope. 295 ******** ******** 296 * ES * * ES * 297 ******** ******** 299 +------+ +------+ 300 | ENRP | | ENRP | 301 +------+ +------+ 302 | SCTP | | SCTP | 303 +------+ +------+ 304 | IP | | IP | 305 +------+ +------+ 306 Figure 5: Protocol stack between PE and ENRP server 308 [Editors note] What about the multicast based ENRP server 309 detection. 311 2.2.7. PE <-> PE Communication 313 [Editors note] This is a special case of the PU <-> PE 314 communication. In this case the PU is also a PE in a server pool. 315 The 'business cards' mechanism will be described here. 317 2.3. Typical Interactions between RSerPool Components 319 The following drawing shows the typical RSerPool components and their 320 possible interactions with each other: 322 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 323 ~ operation scope ~ 324 ~ ......................... ......................... ~ 325 ~ . Server Pool 1 . . Server Pool 2 . ~ 326 ~ . +-------+ +-------+ . (d) . +-------+ +-------+ . ~ 327 ~ . |PE(1,A)| |PE(1,C)|<-------------->|PE(2,B)| |PE(2,A)|<---+ ~ 328 ~ . +-------+ +-------+ . . +-------+ +-------+ . | ~ 329 ~ . ^ ^ . . ^ ^ . | ~ 330 ~ . | (a) | . . | | . | ~ 331 ~ . +----------+ | . . | | . | ~ 332 ~ . +-------+ | | . . | | . | ~ 333 ~ . |PE(1,B)|<---+ | | . . | | . | ~ 334 ~ . +-------+ | | | . . | | . | ~ 335 ~ . ^ | | | . . | | . | ~ 336 ~ .......|........|.|.|.... .......|.........|....... | ~ 337 ~ | | | | | | | ~ 338 ~ (c)| (a)| | |(a) (a)| (a)| (c)| ~ 339 ~ | | | | | | | ~ 340 ~ | v v v v v | ~ 341 ~ | +++++++++++++++ (e) +++++++++++++++ | ~ 342 ~ | + ENRP-Server +<---------->+ ENRP-Server + | ~ 343 ~ | +++++++++++++++ +++++++++++++++ | ~ 344 ~ v ^ ^ | ~ 345 ~ ********* | | | ~ 346 ~ * PU(A) *<-------+ (b)| | ~ 347 ~ ********* (b) | | ~ 348 ~ v | ~ 349 ~ ::::::::::::::::: (f) ***************** | ~ 350 ~ : Other Clients :<------------->* Proxy/Gateway * <---+ ~ 351 ~ ::::::::::::::::: ***************** ~ 352 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 353 Figure 6: RSerPool components and their possible interactions. 355 In figure 6 we can identify the following possible interactions: 357 (a) Server Pool Elements <-> ENRP Server: (ASAP) 359 Each PE in a pool uses ASAP to register or de-register itself 360 as well as to exchange other auxiliary information with the 361 ENRP Server. The ENRP Server also uses ASAP to monitor the 362 operational status of each PE in a pool. 364 (b) PU <-> ENRP Server: (ASAP) 366 A PU normally uses ASAP to request the ENRP Server for a name- 367 to-address translation service before the PU can send user 368 messages addressed to a server pool by the pool's name. 370 (c) PU <-> PE: (ASAP) 372 ASAP can be used to exchange some auxiliary information of the 373 two parties before they engage in user data transfer. 375 (d) Server Pool <-> Server Pool: (ASAP) 377 A PE in a server pool can become a PU to another pool when the 378 PE tries to initiate communication with the other pool. In 379 such a case, the interactions described in B) and C) above 380 will apply. 382 (e) ENRP Server <-> ENRP Server: (ENRP) 384 ENRP can be used to fulfill various Name Space operation, 385 administration, and maintenance (OAM) functions. 387 (f) Other Clients <-> Proxy/Gateway: standard protocols 389 The proxy/gateway enables clients ("other clients"), which are 390 not RSerPool aware, to access services provided by an RSerPool 391 based server pool. It should be noted that these 392 proxies/gateways may become a single point of failure. 394 3. Examples 396 [Editors note] This section has not been updated. The examples will 397 be updated after the architecture has been finalized. 399 In this section the basic concepts of ENRP and ASAP will be described. 400 First an RSerPool aware FTP server is considered. The interaction with 401 an RSerPool aware and an non-aware client is given. Finally, a telephony 402 example is considered. 404 3.1. Two File Transfer Examples 406 In this section we present two separate file transfer examples using 407 ENRP and ASAP. We present two separate examples demonstrating an 408 ENRP/ASAP aware client and a client that is using a Proxy or Gateway to 409 perform the file transfer. In this example we will use a FTP [RFC959] 410 model with some modifications. The first example (the RSerPool aware 411 one) will modify FTP concepts so that the file transfer takes place over 412 SCTP. In the second example we will use TCP between the unaware client 413 and the Proxy. The Proxy itself will use the modified FTP with RSerPool 414 as illustrated in the first example. 416 Please note that in the example we do NOT follow FTP [RFC959] precisely 417 but use FTP-like concepts and attempt to adhere to the basic FTP model. 419 These examples use FTP for illustrative purposes, FTP was chosen since 420 many of the basic concept are well known and should be familiar to 421 readers. 423 3.1.1. The RSerPool Aware Client 425 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 426 ~ operation scope ~ 427 ~ ......................... ~ 428 ~ . "File Transfer Pool" . ~ 429 ~ . +-------+ +-------+ . ~ 430 ~ +-> |PE(1,A)| |PE(1,C)| . ~ 431 ~ |. +-------+ +-------+ . ~ 432 ~ |. ^ ^ . ~ 433 ~ |. +----------+ | . ~ 434 ~ |. +-------+ | | . ~ 435 ~ |. |PE(1,B)|<---+ | | . ~ 436 ~ |. +-------+ | | | . ~ 437 ~ |. ^ | | | . ~ 438 ~ |.......|........|.|.|.... ~ 439 ~ | ASAP | ASAP| | |ASAP ~ 440 ~ |(d) |(c) | | | ~ 441 ~ | v v v v ~ 442 ~ | ********* +++++++++++++++ ~ 443 ~ + ->* PU(X) * + ENRP-Server + ~ 444 ~ ********* +++++++++++++++ ~ 445 ~ ^ ASAP ^ ~ 446 ~ | <-(b) | ~ 447 ~ +--------------+ ~ 448 ~ (a)-> ~ 449 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 450 Figure 7: Architecture for RSerPool aware client. 452 To effect a file transfer the following steps would take place. 454 (1) The application in PU(X) would send a login request. The 455 PU(X)'s ASAP layer would send an ASAP request to its ENRP 456 server to request the list of pool elements (using (a)). The 457 pool handle to identify the pool would be "File Transfer 458 Pool". The ASAP layer queues the login request. 460 (2) The ENRP server would return a list of the three PEs PE(1,A), 461 PE(1,B) and PE(1,C) to the ASAP layer in PU(X) (using (b)). 463 (3) The ASAP layer selects one of the PEs, for example PE(1,B). It 464 transmits the login request, the other FTP control data 465 finally starts the transmission of the requested files (using 466 (c)). For this the multiple stream feature of SCTP could be 467 used. 469 (4) If during the file transfer conversation, PE(1,B) fails, 470 assuming the PE's were sharing state of file transfer, a fail- 471 over to PE(1,A) could be initiated. PE(1,A) would continue the 472 transfer until complete (see (d)). In parallel a request from 473 PE(1,A) would be made to ENRP to request a cache update for 474 the server pool "File Transfer Pool" and a report would also 475 be made that PE(1,B) is non-responsive (this would cause 476 appropriate audits that may remove PE(1,B) from the pool if 477 the ENRP servers had not already detected the failure) (using 478 (a)). 480 3.1.2. The RSerPool Unaware Client 482 In this example we investigate the use of a Proxy server assuming the 483 same set of scenario as illustrated above. 485 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 486 ~ operation scope ~ 487 ~ ......................... ~ 488 ~ . "File Transfer Pool" . ~ 489 ~ . +-------+ +-------+ . ~ 490 ~ . |PE(1,A)| |PE(1,C)| . ~ 491 ~ . +-------+ +-------+ . ~ 492 ~ . ^ ^ . ~ 493 ~ . +----------+ | . ~ 494 ~ . +-------+ | | . ~ 495 ~ . |PE(1,B)|<---+ | | . ~ 496 ~ . +-------+ | | | . ~ 497 ~ .......^........|.|.|.... ~ 498 ~ | | | | ~ 499 ~ | ASAP| | |ASAP ~ 500 ~ | | | | ~ 501 ~ | v v v ~ 502 ~ | +++++++++++++++ +++++++++++++++ ~ 503 ~ | + ENRP-Server +<--ENRP-->+ ENRP-Server + ~ 504 ~ | +++++++++++++++ +++++++++++++++ ~ 505 ~ | ASAP ^ ~ 506 ~ | ASAP (c) (b) | ^ ~ 507 ~ +---------------------------------+ | | | ~ 508 ~ | v | (a) ~ 509 ~ v v ~ 510 ~ ::::::::::::::::: (e)-> ***************** ~ 511 ~ : FTP Client :<------------->* Proxy/Gateway * ~ 512 ~ ::::::::::::::::: (f) ***************** ~ 513 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 514 Figure 8: Architecture for RserPool unaware client. 516 In this example the steps will occur: 518 (1) The FTP client and the Proxy/Gateway are using the TCP-based 519 ftp protocol. The client sends the login request to the proxy 520 (using (e)) 522 (2) The proxy behaves like a client and performs the actions 523 described under (1), (2) and (3) of the above description 524 (using (a), (b) and (c)). 526 (3) The ftp communication continues and will be translated by the 527 proxy into the RSerPool aware dialect. This interworking uses 528 (f) and (c). 530 Note that in this example high availability is maintained between the 531 Proxy and the server pool but a single point of failure exists between 532 the FTP client and the Proxy, i.e. the command TCP connection and its 533 one IP address it is using for commands. 535 3.2. Telephony Signaling Example 537 This example shows the use of ASAP/RSerPool to support server pooling 538 for high availability of a telephony application such as a Voice over IP 539 Gateway Controller (GWC) and Gatekeeper services (GK). 541 In this example, we show two different scenarios of deploying these 542 services using RSerPool in order to illustrate the flexibility of the 543 RSerPool architecture. 545 3.2.1. Decomposed GWC and GK Scenario 547 In this scenario, both GWC and GK services are deployed as separate 548 pools with some number of PEs, as shown in the following diagram. Each 549 of the pools will register their unique pool handle (i.e. name) with the 550 ENRP Server. We also assume that there are a Signaling Gateway (SG) and 551 a Media Gateway (MG) present and both are RSerPool aware. 553 ................... 554 . Gateway . 555 . Controller Pool . 556 ................. . +-------+ . 557 . Gatekeeper . . |PE(2,A)| . 558 . Pool . . +-------+ . 559 . +-------+ . . +-------+ . 560 . |PE(1,A)| . . |PE(2,B)| . 561 . +-------+ . . +-------+ . 562 . +-------+ . (d) . +-------+ . 563 . |PE(1,B)|<------------>|PE(2,C)|<-------------+ 564 . +-------+ . . +-------+ . | 565 ................. ........^.......... | 566 | | 567 (c)| (e)| 568 | v 569 +++++++++++++++ ********* ***************** 570 + ENRP-Server + * SG(X) * * Media Gateway * 571 +++++++++++++++ ********* ***************** 572 ^ ^ 573 | | 574 | <-(a) | 575 +-------------------+ 576 (b)-> 578 Figure 9: Deployment of Decomposed GWC and GK. 580 As shown in the figure 9, the following sequence takes place: 582 (1) the Signaling Gateway (SG) receives an incoming signaling 583 message to be forwarded to the GWC. SG(X)'s ASAP layer would 584 send an ASAP request to its "local" ENRP server to request the 585 list of pool elements (PE's) of GWC (using (a)). The key used 586 for this query is the pool handle of the GWC. The ASAP layer 587 queues the data to be sent in local buffers until the ENRP 588 server responds. 590 (2) the ENRP server would return a list of the three PE's A, B and 591 C to the ASAP layer in SG(X) together with information to be 592 used for load-sharing traffic across the gateway controller 593 pool (using (b)). 595 (3) the ASAP layer in SG(X) will select one PE (e.g., PE(2,C)) and 596 send the signaling message to it (using (c)). The selection is 597 based on the load sharing information of the gateway 598 controller pool. 600 (4) to progress the call, PE(2,C) finds that it needs to talk to 601 the Gatekeeper. Assuming it has already had gatekeeper pool's 602 information in its local cache (e.g., obtained and stored from 603 recent query to ENRP Server), PE(2,C) selects PE(1,B) and 604 sends the call control message to it (using (d)). 606 We assume PE(1,B) responds back to PE(2,C) and authorizes the 607 call to proceed. 609 (5) PE(2,C) issues media control commands to the Media Gateway 610 (using (e)). 612 RSerPool will provide service robustness to the system if some failure 613 would occur in the system. 615 For instance, if PE(1, B) in the Gatekeeper Pool crashed after receiving 616 the call control message from PE(2, C) in step (d) above, what most 617 likely will happen is that, due to the absence of a reply from the 618 Gatekeeper, a timer expiration event will trigger the call state machine 619 within PE(2, C) to resend the control message. The ASAP layer at PE(2, 620 C) will then notice the failure of PE(1, B) through (likely) the 621 endpoint unreachability detection by the transport protocol beneath ASAP 622 and automatically deliver the re-sent call control message to the 623 alternate GK pool member PE(1, A). With appropriate intra-pool call 624 state sharing support, PE(1, A) will be able to correctly handle the 625 call and reply to PE(2, C) and hence progress the call. 627 3.2.2. Collocated GWC and GK Scenario 629 In this scenario, the GWC and GK services are collocated (e.g., they are 630 implemented as a single process). In such a case, one can form a pool 631 that provides both GWC and GK services as shown in figure 6 below. 633 ........................................ 634 . Gateway Controller/Gatekeeper Pool . 635 . +-------+ . 636 . |PE(3,A)| . 637 . +-------+ . 638 . +-------+ . 639 . |PE(3,C)|<---------------------------+ 640 . +-------+ . | 641 . +-------+ ^ . | 642 . |PE(3,B)| | . | 643 . +-------+ | . | 644 ................|....................... | 645 | | 646 +-------------+ | 647 | | 648 (c)| (e)| 649 v v 650 +++++++++++++++ ********* ***************** 651 + ENRP-Server + * SG(X) * * Media Gateway * 652 +++++++++++++++ ********* ***************** 653 ^ ^ 654 | | 655 | <-(a) | 656 +-------------------+ 657 (b)-> 659 Figure 10: Deployment of Collocated GWC and GK. 661 The same sequence as described in 5.2.1 takes place, except that step 662 (4) now becomes internal to the PE(3,C) (again, we assume Server C is 663 selected by SG). 665 4. Acknowledgements 667 The authors would like to thank Bernard Aboba, Harrie Hazewinkel, Matt 668 Holdrege, Christopher Ross, Werner Vogels and many others for their 669 invaluable comments and suggestions. 671 5. References 673 [RFC793] J. B. Postel, "Transmission Control Protocol", RFC 793, 674 September 1981. 676 [RFC959] J. B. Postel, J. Reynolds, "File Transfer Protocol (FTP)", 677 RFC 959, October 1985. 679 [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", 680 RFC 2026, October 1996. 682 [RFC2608] E. Guttman et al., "Service Location Protocol, Version 2", 683 RFC 2608, June 1999. 685 [RFC2719] L. Ong et al., "Framework Architecture for Signaling 686 Transport", RFC 2719, October 1999. 688 [RFC2960] R. R. Stewart et al., "Stream Control Transmission 689 Protocol", RFC 2960, November 2000. 691 [RFC3237] M. Tuexen et al., "Requirements for Reliable Server 692 Pooling", RFC 3237, January 2002. 694 6. Authors' Addresses 696 Michael Tuexen Tel.: +49 89 722 47210 697 Siemens AG e-mail: Michael.Tuexen@icn.siemens.de 698 ICN WN CS SE 51 699 D-81359 Munich 700 Germany 702 Qiaobing Xie Tel.: +1 847 632 3028 703 Motorola, Inc. e-mail: qxie1@email.mot.com 704 1501 W. Shure Drive, #2309 705 Arlington Heights, Il 60004 706 USA 708 Randall Stewart Tel.: +1 815 477 2127 709 Cisco Systems, Inc. e-mail: rrs@cisco.com 710 24 Burning Bush Trail 711 Crystal Lake, Il 60012 712 USA 714 Melinda Shore Tel.: +1 607 272 7512 715 Cisco Systems, Inc. e-mail: mshore@cisco.com 716 809 Hayts Rd 717 Ithaca, NY 14850 718 USA 720 Lyndon Ong Tel.: +1 408 321 8237 721 Point Reyes Networks e-mail: long@pointreyesnet.com 722 1991 Concourse Drive 723 San Jose, CA 724 USA 725 John Loughney Tel.: 726 Nokia Research Center e-mail: john.loughney@nokia.com 727 PO Box 407 728 FIN-00045 Nokia Group 729 Finland 731 Maureen Stillman Tel.: +1 607 273 0724 62 732 Nokia e-mail: maureen.stillman@nokia.com 733 127 W. State Street 734 Ithaca, NY 14850 735 USA 737 This Internet Draft expires October 24, 2002.