idnits 2.17.1 draft-ietf-rserpool-arch-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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. ** There are 31 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 435 has weird spacing: '...ie. In case ...' == Line 500 has weird spacing: '... figure we ca...' -- 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 (June 2002) is 7984 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: '1' is defined on line 808, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 814, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 817, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 820, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 824, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (ref. '1') (Obsoleted by RFC 9293) ** Downref: Normative reference to an Informational RFC: RFC 2719 (ref. '5') ** Obsolete normative reference: RFC 2960 (ref. '6') (Obsoleted by RFC 4960) ** Downref: Normative reference to an Informational RFC: RFC 3237 (ref. '7') Summary: 9 errors (**), 0 flaws (~~), 9 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 Expires: November 30, 2002 Q. Xie 5 Motorola, Inc. 6 R. Stewart 7 M. Shore 8 Cisco Systems, Inc. 9 L. Ong 10 Ciena Corporation 11 J. Loughney 12 Nokia Research Center 13 M. Stillman 14 Nokia 15 June 2002 17 Architecture for Reliable Server Pooling 18 draft-ietf-rserpool-arch-03.txt 20 Status of this Memo 22 This document is an Internet-Draft and is in full conformance with 23 all provisions of Section 10 of RFC2026. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at http:// 36 www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on November 30, 2002. 43 Copyright Notice 45 Copyright (C) The Internet Society (2002). All Rights Reserved. 47 Abstract 49 This document describes an architecture and protocols for the 50 management and operation of server pools supporting highly reliable 51 applications, and for client access mechanisms to a server pool. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.3 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Reliable Server Pooling Architecture . . . . . . . . . . . . 5 60 2.1 RSerPool Functional Components . . . . . . . . . . . . . . . 5 61 2.2 RSerPool Protocol Overview . . . . . . . . . . . . . . . . . 6 62 2.2.1 Endpoint Name Resolution Protocol . . . . . . . . . . . . . 6 63 2.2.2 Aggregate Server Access Protocol . . . . . . . . . . . . . . 6 64 2.2.3 PU <-> NS Communication . . . . . . . . . . . . . . . . . . 7 65 2.2.4 PE <-> NS Communication . . . . . . . . . . . . . . . . . . 7 66 2.2.5 PU <-> PE Communication . . . . . . . . . . . . . . . . . . 8 67 2.2.6 NS <-> NS Communication . . . . . . . . . . . . . . . . . . 9 68 2.2.7 PE <-> PE Communication . . . . . . . . . . . . . . . . . . 9 69 2.3 Failover Support . . . . . . . . . . . . . . . . . . . . . . 9 70 2.3.1 Testament . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 2.3.2 Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 2.3.3 Application level acknowledgements . . . . . . . . . . . . . 11 73 2.3.4 Business Cards . . . . . . . . . . . . . . . . . . . . . . . 11 74 2.4 Typical Interactions between RSerPool Components . . . . . . 11 75 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 3.1 Two File Transfer Examples . . . . . . . . . . . . . . . . . 14 77 3.1.1 The RSerPool Aware Client . . . . . . . . . . . . . . . . . 15 78 3.1.2 The RSerPool Unaware Client . . . . . . . . . . . . . . . . 16 79 3.2 Telephony Signaling Example . . . . . . . . . . . . . . . . 17 80 3.2.1 Decomposed GWC and GK Scenario . . . . . . . . . . . . . . . 17 81 3.2.2 Collocated GWC and GK Scenario . . . . . . . . . . . . . . . 19 82 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 83 References . . . . . . . . . . . . . . . . . . . . . . . . . 22 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 22 85 Full Copyright Statement . . . . . . . . . . . . . . . . . . 24 87 1. Introduction 89 1.1 Overview 91 This document defines a proposed architecture, which can be used to 92 provide highly available services. The way this is achieved is by 93 using servers grouped into pools. Therefore, if a client wants to 94 access a server pool, it will be able to use any of the servers in 95 the server pool. Several server selection mechanisms, called server 96 pool policies, are supported. 98 To access a server pool, the pool user consults a name server. The 99 name space for the server pools is flat, rather than hierachical. A 100 group of fault tolerant name servers are provided to resolve pool 101 name queries from the pools user. 103 1.2 Terminology 105 This document uses the following terms: 107 Home Name Server: The Name Server a Pool Element has registered with. 108 This Name Server supervises the Pool Element. 110 Operation scope: The part of the network visible to pool users by a 111 specific instance of the reliable server pooling protocols. 113 Pool (or server pool): A collection of servers providing the same 114 application functionality. 116 Pool handle (or pool name): A logical pointer to a pool. Each server 117 pool will be identifiable in the operation scope of the system by 118 a unique pool handle or "name". 120 Pool element: A server entity having registered to a pool. 122 Pool user: A server pool user. 124 Pool element handle (or endpoint handle): A logical pointer to a 125 particular pool element in a pool, consisting of the name of the 126 pool and a destination transport address of the pool element. 128 Name space: A cohesive structure of pool names and relations that may 129 be queried by an internal or external agent. 131 Name server: Entity which is responsible for managing and maintaining 132 the name space within the RSerPool operation scope. 134 1.3 Abbreviations 136 ASAP: Aggregate Server Access Protocol 138 ENRP: Endpoint Name Resolution Protocol 140 Home NS: Home Name Server 142 NS: Name Server 144 PE: Pool element 146 PU: Pool user 148 SCTP: Stream Control Transmission Protocol 150 TCP: Transmission Control Protocol 152 2. Reliable Server Pooling Architecture 154 In this section, we define a reliable server pool architecture. 156 2.1 RSerPool Functional Components 158 There are three classes of entities in the RSerPool architecture: 160 o Pool Elements (PEs). 162 o Name Servers (NSs). 164 o Pool Users (PUs). 166 A server pool is defined as a set of one or more servers providing 167 the same application functionality. These servers are called Pool 168 Elements (PEs). PEs form the first class of entities in the RSerPool 169 architecture. Multiple PEs in a server pool can be used to provide 170 fault tolerance or load sharing, for example. 172 Each server pool will be identifiable by a unique name which is 173 simply a byte string, called the pool handle. This allows binary 174 names to be used. 176 These names are not valid in the whole internet but only in smaller 177 parts, called the operational scope. Furthermore, the namespace is 178 flat. 180 The second class of entities in the RSerPool architecture is the 181 class of the name servers. These name servers can resolve a pool 182 handle to a list of information which allows the PU to access a PE of 183 the server pool identified by the handle. This information includes: 185 o A list of IPv4 and/or IPv6 addresses. 187 o A protocol field of the IP header specifying the upper layer 188 protocol. 190 o A port number if the upper layer protocol is SCTP, TCP or UDP. 192 Please note that the RSerPool architecture supports both IPv4 and 193 IPv6 addressing. A PE can also support multiple transport layers. 195 In each operational scope there must be at least one name server. 196 Most likely there will be more than one. All these name servers have 197 the complete knowledge about all server pools in the operational 198 scope. The name servers use a protocol called Endpoint Name 199 Resolution Protocol (ENRP) for communication with each other to make 200 sure that all have the same information about the server pools. 202 A client being served by a PE of a server pool is called a Pool User 203 (PU). This is the third class of entities in the RSerPool 204 architecture. 206 If the PU wants to be served by a PE of a particular server pool it 207 must know the pool handle of the server pool. The PU then uses the 208 Aggregate Server Access Protocol (ASAP) to query for transport layer 209 addresses of PEs belonging to the server pool identified by the pool 210 handle. 212 RFC3237 [7] also requires that the name servers should not resolve a 213 pool handle to a transport layer address of a PE which is not in 214 operation. Therefore each PE is supervised by one specific name 215 server, called the home NS of that PE. If it detects that the PE is 216 out of service all other name servers are informed by using ENRP. 218 ASAP is also used by a server to join or leave a server pool. It 219 registers or deregisters itself by communicating with a name server, 220 which will normally the home NS. 222 2.2 RSerPool Protocol Overview 224 The RSerPool requested features can be obtained with the help of the 225 combination of two protocols: ENRP (Endpoint Name Resolution 226 Protocol) and ASAP (Aggregate Server Access Protocol). 228 2.2.1 Endpoint Name Resolution Protocol 230 ENRP is designed to provide a fully distributed fault-tolerant real- 231 time translation service that maps a name to a set of transport 232 addresses pointing to a specific group of networked communication 233 endpoints registered under that name. ENRP employs a client-server 234 model with which an name server will respond to the name translation 235 service requests from endpoint clients running on the same host or 236 running on different hosts. 238 2.2.2 Aggregate Server Access Protocol 240 ASAP in conjunction with ENRP provides a fault tolerant data transfer 241 mechanism over IP networks. ASAP uses a name-based addressing model 242 which isolates a logical communication endpoint from its IP 243 address(es), thus effectively eliminating the binding between the 244 communication endpoint and its physical IP address(es) which normally 245 constitutes a single point of failure. 247 In addition, ASAP defines each logical communication destination as a 248 server pool, providing full transparent support for server-pooling 249 and load sharing. It also allows dynamic system scalability - 250 members of a server pool can be added or removed at any time without 251 interrupting the service. 253 2.2.3 PU <-> NS Communication 255 The PU <-> NS communication is used for doing name queries. The PU 256 sends a pool handle to the NS and gets back the information necessary 257 for accessing a server in a server pool. 259 ******** ******** 260 * PU * * NS * 261 ******** ******** 263 +------+ +------+ 264 | ASAP | | ASAP | 265 +------+ +------+ 266 | SCTP | | SCTP | 267 +------+ +------+ 268 | IP | | IP | 269 +------+ +------+ 271 Protocol stack between PU and NS (SCTP variant) 273 If the PU does not use SCTP based services it may not be appropriate 274 to implement SCTP of PUs just to do the name queries. Therefore ASAP 275 over TCP can be used for doing the name queries. The protocol stack 276 is shown in the following figure. 278 ******** ******** 279 * PU * * NS * 280 ******** ******** 282 +------+ +------+ 283 | ASAP | | ASAP | 284 +------+ +------+ 285 | TCP | | TCP | 286 +------+ +------+ 287 | IP | | IP | 288 +------+ +------+ 289 Protocol stack between PU and NS (TCP variant) 291 2.2.4 PE <-> NS Communication 293 The PE <-> NS communication is used for registration and 294 deregistration of the PE in one ore more pools and for the 295 supervision of the PE by the home NS. This communication is based on 296 SCTP, the protocol stack is shown in the following figure. 298 ******** ******** 299 * PE * * NS * 300 ******** ******** 302 +------+ +------+ 303 | ASAP | | ASAP | 304 +------+ +------+ 305 | SCTP | | SCTP | 306 +------+ +------+ 307 | IP | | IP | 308 +------+ +------+ 309 Protocol stack between PE and NS 311 2.2.5 PU <-> PE Communication 313 The PU <-> PE communication can be divided into two parts: 315 o control channel 317 o data channel 319 The data channel is used for the transmission of the upper layer 320 data. The ASAP layer at the PU and PE may or may not be involved in 321 the handling of the data channel. 323 The control channel can be established from the PU side, if needed, 324 to transport the following information: 326 o The PE can send a testament to the PU for providing information to 327 which other PE the PU should failover in case of a failover. 329 o The PE can send cookies to the PU. The PE would store only the 330 last cookie and send it to the new PE in case of a failover. 332 o Both the PE and PU can send application level acknowledgements to 333 provide a user controlled buffer management at the RSerPool layer. 335 See Section 2.3 for further details. 337 The control channel is transported using the ASAP protocol making use 338 of SCTP or TCP as its transport protocol. The control and data 339 channel may be tranported over a single transport layer connection. 341 2.2.6 NS <-> NS Communication 343 The communication between name servers is used to share the knowledge 344 about all server pools between all name servers in an operational 345 scope. 347 ******** ******** 348 * NS * * NS * 349 ******** ******** 351 +------+ +------+ 352 | ENRP | | ENRP | 353 +------+ +------+ 354 | SCTP | | SCTP | 355 +------+ +------+ 356 | IP | | IP | 357 +------+ +------+ 358 Protocol stack between NS and NS 360 For this communication ENRP over SCTP is used. 362 When a name server boots up a UDP multicast message may be sent out 363 for initial detection of other name servers in the operational scope. 364 The other name servers send an answer using a unicast UDP message. 366 2.2.7 PE <-> PE Communication 368 This is a special case of the PU <-> PE communication. In this case 369 the PU is also a PE in a server pool. 371 There is one additional point here: The PE acting as a PU can send 372 the PE the information that it is acually a PE of pool. This means 373 that the pool handle is transferred via the control channel. Also a 374 testament can be can be sent from the PE acting as a PU to the PE. 375 See Section 2.3 for further details. 377 2.3 Failover Support 379 If the PU detects the failure of a PE it may fail over to a different 380 PE. The selection to a new PE should be made such that most likely 381 the new PE is not affected by the failed one. This means, for 382 example, in case of the failure of a TCP connection between a PU and 383 a PE the PU should not fail over to a SCTP association on the same 384 host. It is better to use a different host. Therefore it is 385 possible for a PE to register multiple transports. 387 There are some mechanisms provided by RSerPool to support the 388 failover to a new PE. 390 2.3.1 Testament 392 Consider the szenario given in the following figure. 394 ....................... 395 . +-------+ . 396 . | | . 397 . | PE 1 | . 398 . | | . 399 . +-------+ . . 400 . . 401 . Server Pool . 402 . . 403 . . 404 +-------+ . +-------+ . +-------+ 405 | | . | | . | | 406 | PU 1 |------.------| PE 2 |------.-------| PU 2 | 407 | | . | | . | | 408 +-------+ . +-------+ . +-------+ 409 . . 410 . . 411 . . 412 . . 413 . +-------+ . 414 . | | . 415 . | PE 3 | . 416 . | | . 417 . +-------+ . 418 ....................... 419 Two PE accessing the same PE 421 PU 1 is using PE 2 of the server pool. Assume that PE 1 and PE 2 422 share state but not PE 2 and PE 3. Using the testament it is 423 possible for PE 2 to inform PU 1 that it should fail over to PE 1 in 424 case of a failure. 426 A slightly more complicated situation is if two pool users, PU 1 and 427 PU 2, use PE 2 but both, PU 1 and PU 2, need to use the same PE. 428 Then it is important that PU 1 and PU 2 fail over to the same PE. 429 This can be handled in a way such that PE 2 gives the same testament 430 to PU 1 and PU 2. 432 2.3.2 Cookies 434 Cookies are sent from the PE to the PU whenever the PE wants this to 435 do. The PU only stores the last received cookie. In case of a fail 436 over it sends this last recveived cookie to the new PE. This method 437 provides a simple way of state sharing between the PE. Please note 438 that the PE should sign the cookie and the receiving PE has to 439 verifiy the signature. For the PU is cookie has no structure and is 440 does only store it. 442 2.3.3 Application level acknowledgements 444 In case of a failure an upper layer might want to retrieve some data 445 from the communication to to failed PE and transfer it to the new 446 one. Because this data retrieval problem can not be completely 447 solved in a general way (and provide neither message loss nor message 448 duplication) the ASAP layer only provides the support of application 449 layer acknowledgements. ASAP uses this for upper layer supported 450 buffer management in the ASAP layer. 452 2.3.4 Business Cards 454 In case of a PE to PE communication one of the PEs acts as a PU for 455 establishing the communication. But the peer does not know the pool 456 handle of the PE which initiated the communication. A business card 457 can be used for the PE acting as a PE to provide the peer with the 458 pool handle. So even in case the PE which acts as a PU fails the 459 other PE can fail over to a different PE in the pool of the PE which 460 was initially acting as a PU. 462 2.4 Typical Interactions between RSerPool Components 464 The following drawing shows the typical RSerPool components and their 465 possible interactions with each other: 467 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 468 ~ operation scope ~ 469 ~ ......................... ......................... ~ 470 ~ . Server Pool 1 . . Server Pool 2 . ~ 471 ~ . +-------+ +-------+ . (d) . +-------+ +-------+ . ~ 472 ~ . |PE(1,A)| |PE(1,C)|<-------------->|PE(2,B)| |PE(2,A)|<---+ ~ 473 ~ . +-------+ +-------+ . . +-------+ +-------+ . | ~ 474 ~ . ^ ^ . . ^ ^ . | ~ 475 ~ . | (a) | . . | | . | ~ 476 ~ . +----------+ | . . | | . | ~ 477 ~ . +-------+ | | . . | | . | ~ 478 ~ . |PE(1,B)|<---+ | | . . | | . | ~ 479 ~ . +-------+ | | | . . | | . | ~ 480 ~ . ^ | | | . . | | . | ~ 481 ~ .......|........|.|.|.... .......|.........|....... | ~ 482 ~ | | | | | | | ~ 483 ~ (c)| (a)| | |(a) (a)| (a)| (c)| ~ 484 ~ | | | | | | | ~ 485 ~ | v v v v v | ~ 486 ~ | +++++++++++++++ (e) +++++++++++++++ | ~ 487 ~ | + NS +<---------->+ NS + | ~ 488 ~ | +++++++++++++++ +++++++++++++++ | ~ 489 ~ v ^ ^ | ~ 490 ~ ********* | | | ~ 491 ~ * PU(A) *<-------+ (b)| | ~ 492 ~ ********* (b) | | ~ 493 ~ v | ~ 494 ~ ::::::::::::::::: (f) ***************** | ~ 495 ~ : Other Clients :<------------->* Proxy/Gateway * <---+ ~ 496 ~ ::::::::::::::::: ***************** ~ 497 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 498 RSerPool components and their possible interactions. 500 In this figure we can identify the following possible interactions: 502 (a) Server Pool Elements <-> NS: (ASAP) Each PE in a pool uses ASAP 503 to register or de-register itself as well as to exchange other 504 auxiliary information with the NS. The NS also uses ASAP to 505 monitor the operational status of each PE in a pool. 507 (b) PU <-> NS: (ASAP) A PU normally uses ASAP to request the NS for a 508 name-to-address translation service before the PU can send user 509 messages addressed to a server pool by the pool's name. 511 (c) PU <-> PE: (ASAP) ASAP can be used to exchange some auxiliary 512 information of the two parties before they engage in user data 513 transfer. 515 (d) Server Pool <-> Server Pool: (ASAP) A PE in a server pool can 516 become a PU to another pool when the PE tries to initiate 517 communication with the other pool. In such a case, the 518 interactions described in (a) and (c) above will apply. 520 (e) NS <-> NS: (ENRP) ENRP can be used to fulfill various Name Space 521 operation, administration, and maintenance (OAM) functions. 523 (f) Other Clients <-> Proxy/Gateway: standard protocols The proxy/ 524 gateway enables clients ("other clients"), which are not RSerPool 525 aware, to access services provided by an RSerPool based server 526 pool. It should be noted that these proxies/gateways may become a 527 single point of failure. 529 3. Examples 531 [Editors note] This section has not been updated. The examples will 532 be updated after the architecture has been finalized. 534 In this section the basic concepts of ENRP and ASAP will be 535 described. First an RSerPool aware FTP server is considered. The 536 interaction with an RSerPool aware and an non-aware client is given. 537 Finally, a telephony example is considered. 539 3.1 Two File Transfer Examples 541 In this section we present two separate file transfer examples using 542 ENRP and ASAP. We present two separate examples demonstrating an 543 ENRP/ASAP aware client and a client that is using a Proxy or Gateway 544 to perform the file transfer. In this example we will use a FTP 545 RFC959 [2] model with some modifications. The first example (the 546 RSerPool aware one) will modify FTP concepts so that the file 547 transfer takes place over SCTP. In the second example we will use 548 TCP between the unaware client and the Proxy. The Proxy itself will 549 use the modified FTP with RSerPool as illustrated in the first 550 example. 552 Please note that in the example we do NOT follow FTP RFC959 [2] 553 precisely but use FTP-like concepts and attempt to adhere to the 554 basic FTP model. These examples use FTP for illustrative purposes, 555 FTP was chosen since many of the basic concept are well known and 556 should be familiar to readers. 558 3.1.1 The RSerPool Aware Client 560 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 561 ~ operation scope ~ 562 ~ ......................... ~ 563 ~ . "File Transfer Pool" . ~ 564 ~ . +-------+ +-------+ . ~ 565 ~ +-> |PE(1,A)| |PE(1,C)| . ~ 566 ~ |. +-------+ +-------+ . ~ 567 ~ |. ^ ^ . ~ 568 ~ |. +----------+ | . ~ 569 ~ |. +-------+ | | . ~ 570 ~ |. |PE(1,B)|<---+ | | . ~ 571 ~ |. +-------+ | | | . ~ 572 ~ |. ^ | | | . ~ 573 ~ |.......|........|.|.|.... ~ 574 ~ | ASAP | ASAP| | |ASAP ~ 575 ~ |(d) |(c) | | | ~ 576 ~ | v v v v ~ 577 ~ | ********* +++++++++++++++ ~ 578 ~ + ->* PU(X) * + NS + ~ 579 ~ ********* +++++++++++++++ ~ 580 ~ ^ ASAP ^ ~ 581 ~ | <-(b) | ~ 582 ~ +--------------+ ~ 583 ~ (a)-> ~ 584 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 586 Architecture for RSerPool aware client. 588 To effect a file transfer the following steps would take place. 590 1. The application in PU(X) would send a login request. The PU(X)'s 591 ASAP layer would send an ASAP request to its NS to request the 592 list of pool elements (using (a)). The pool handle to identify 593 the pool would be "File Transfer Pool". The ASAP layer queues 594 the login request. 596 2. The NS would return a list of the three PEs PE(1,A), PE(1,B) and 597 PE(1,C) to the ASAP layer in PU(X) (using (b)). 599 3. The ASAP layer selects one of the PEs, for example PE(1,B). It 600 transmits the login request, the other FTP control data finally 601 starts the transmission of the requested files (using (c)). For 602 this the multiple stream feature of SCTP could be used. 604 4. If during the file transfer conversation, PE(1,B) fails, assuming 605 the PE's were sharing state of file transfer, a fail-over to 606 PE(1,A) could be initiated. PE(1,A) would continue the transfer 607 until complete (see (d)). In parallel a request from PE(1,A) 608 would be made to ENRP to request a cache update for the server 609 pool "File Transfer Pool" and a report would also be made that 610 PE(1,B) is non-responsive (this would cause appropriate audits 611 that may remove PE(1,B) from the pool if the NS had not already 612 detected the failure) (using (a)). 614 3.1.2 The RSerPool Unaware Client 616 In this example we investigate the use of a Proxy server assuming the 617 same set of scenario as illustrated above. 619 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 620 ~ operation scope ~ 621 ~ ......................... ~ 622 ~ . "File Transfer Pool" . ~ 623 ~ . +-------+ +-------+ . ~ 624 ~ . |PE(1,A)| |PE(1,C)| . ~ 625 ~ . +-------+ +-------+ . ~ 626 ~ . ^ ^ . ~ 627 ~ . +----------+ | . ~ 628 ~ . +-------+ | | . ~ 629 ~ . |PE(1,B)|<---+ | | . ~ 630 ~ . +-------+ | | | . ~ 631 ~ .......^........|.|.|.... ~ 632 ~ | | | | ~ 633 ~ | ASAP| | |ASAP ~ 634 ~ | | | | ~ 635 ~ | v v v ~ 636 ~ | +++++++++++++++ +++++++++++++++ ~ 637 ~ | + NS +<--ENRP-->+ NS + ~ 638 ~ | +++++++++++++++ +++++++++++++++ ~ 639 ~ | ASAP ^ ~ 640 ~ | ASAP (c) (b) | ^ ~ 641 ~ +---------------------------------+ | | | ~ 642 ~ | v | (a) ~ 643 ~ v v ~ 644 ~ ::::::::::::::::: (e)-> ***************** ~ 645 ~ : FTP Client :<------------->* Proxy/Gateway * ~ 646 ~ ::::::::::::::::: (f) ***************** ~ 647 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 648 Architecture for RserPool unaware client. 650 In this example the steps will occur: 652 1. The FTP client and the Proxy/Gateway are using the TCP-based ftp 653 protocol. The client sends the login request to the proxy (using 654 (e)). 656 2. The proxy behaves like a client and performs the actions 657 described under (1), (2) and (3) of the above description (using 658 (a), (b) and (c)). 660 3. The ftp communication continues and will be translated by the 661 proxy into the RSerPool aware dialect. This interworking uses 662 (f) and (c). 664 Note that in this example high availability is maintained between the 665 Proxy and the server pool but a single point of failure exists 666 between the FTP client and the Proxy, i.e. the command TCP 667 connection and its one IP address it is using for commands. 669 3.2 Telephony Signaling Example 671 This example shows the use of ASAP/RSerPool to support server pooling 672 for high availability of a telephony application such as a Voice over 673 IP Gateway Controller (GWC) and Gatekeeper services (GK). 675 In this example, we show two different scenarios of deploying these 676 services using RSerPool in order to illustrate the flexibility of the 677 RSerPool architecture. 679 3.2.1 Decomposed GWC and GK Scenario 681 In this scenario, both GWC and GK services are deployed as separate 682 pools with some number of PEs, as shown in the following diagram. 683 Each of the pools will register their unique pool handle (i.e. name) 684 with the NS. We also assume that there are a Signaling Gateway (SG) 685 and a Media Gateway (MG) present and both are RSerPool aware. 687 ................... 688 . Gateway . 689 . Controller Pool . 690 ................. . +-------+ . 691 . Gatekeeper . . |PE(2,A)| . 692 . Pool . . +-------+ . 693 . +-------+ . . +-------+ . 694 . |PE(1,A)| . . |PE(2,B)| . 695 . +-------+ . . +-------+ . 696 . +-------+ . (d) . +-------+ . 697 . |PE(1,B)|<------------>|PE(2,C)|<-------------+ 698 . +-------+ . . +-------+ . | 699 ................. ........^.......... | 700 | | 701 (c)| (e)| 702 | v 703 +++++++++++++++ ********* ***************** 704 + NS + * SG(X) * * Media Gateway * 705 +++++++++++++++ ********* ***************** 706 ^ ^ 707 | | 708 | <-(a) | 709 +-------------------+ 710 (b)-> 712 Deployment of Decomposed GWC and GK. 714 As shown in the previous figure, the following sequence takes place: 716 1. the Signaling Gateway (SG) receives an incoming signaling message 717 to be forwarded to the GWC. SG(X)'s ASAP layer would send an 718 ASAP request to its "local" NS to request the list of pool 719 elements (PE's) of GWC (using (a)). The key used for this query 720 is the pool handle of the GWC. The ASAP layer queues the data to 721 be sent in local buffers until the NS responds. 723 2. the NS would return a list of the three PE's A, B and C to the 724 ASAP layer in SG(X) together with information to be used for 725 load-sharing traffic across the gateway controller pool (using 726 (b)). 728 3. the ASAP layer in SG(X) will select one PE (e.g., PE(2,C)) and 729 send the signaling message to it (using (c)). The selection is 730 based on the load sharing information of the gateway controller 731 pool. 733 4. to progress the call, PE(2,C) finds that it needs to talk to the 734 Gatekeeper. Assuming it has already had gatekeeper pool's 735 information in its local cache (e.g., obtained and stored from 736 recent query to NS), PE(2,C) selects PE(1,B) and sends the call 737 control message to it (using (d)). 739 5. We assume PE(1,B) responds back to PE(2,C) and authorizes the 740 call to proceed. 742 6. PE(2,C) issues media control commands to the Media Gateway (using 743 (e)). 745 RSerPool will provide service robustness to the system if some 746 failure would occur in the system. 748 For instance, if PE(1, B) in the Gatekeeper Pool crashed after 749 receiving the call control message from PE(2, C) in step (d) above, 750 what most likely will happen is that, due to the absence of a reply 751 from the Gatekeeper, a timer expiration event will trigger the call 752 state machine within PE(2, C) to resend the control message. The 753 ASAP layer at PE(2, C) will then notice the failure of PE(1, B) 754 through (likely) the endpoint unreachability detection by the 755 transport protocol beneath ASAP and automatically deliver the re-sent 756 call control message to the alternate GK pool member PE(1, A). With 757 appropriate intra-pool call state sharing support, PE(1, A) will be 758 able to correctly handle the call and reply to PE(2, C) and hence 759 progress the call. 761 3.2.2 Collocated GWC and GK Scenario 763 In this scenario, the GWC and GK services are collocated (e.g., they 764 are implemented as a single process). In such a case, one can form a 765 pool that provides both GWC and GK services as shown in the figure 766 below. 768 ........................................ 769 . Gateway Controller/Gatekeeper Pool . 770 . +-------+ . 771 . |PE(3,A)| . 772 . +-------+ . 773 . +-------+ . 774 . |PE(3,C)|<---------------------------+ 775 . +-------+ . | 776 . +-------+ ^ . | 777 . |PE(3,B)| | . | 778 . +-------+ | . | 779 ................|....................... | 780 | | 781 +-------------+ | 782 | | 783 (c)| (e)| 784 v v 785 +++++++++++++++ ********* ***************** 786 + NS + * SG(X) * * Media Gateway * 787 +++++++++++++++ ********* ***************** 788 ^ ^ 789 | | 790 | <-(a) | 791 +-------------------+ 792 (b)-> 794 Deployment of Collocated GWC and GK. 796 The same sequence as described in 5.2.1 takes place, except that step 797 (4) now becomes internal to the PE(3,C) (again, we assume Server C is 798 selected by SG). 800 4. Acknowledgements 802 The authors would like to thank Bernard Aboba, Harrie Hazewinkel, 803 Matt Holdrege, Christopher Ross, Werner Vogels and many others for 804 their invaluable comments and suggestions. 806 References 808 [1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 809 September 1981. 811 [2] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 812 959, October 1985. 814 [3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 815 9, RFC 2026, October 1996. 817 [4] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service 818 Location Protocol, Version 2", RFC 2608, June 1999. 820 [5] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L., 821 Lin, H., Juhasz, I., Holdrege, M. and C. Sharp, "Framework 822 Architecture for Signaling Transport", RFC 2719, October 1999. 824 [6] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 825 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 826 "Stream Control Transmission Protocol", RFC 2960, October 2000. 828 [7] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, 829 J. and M. Stillman, "Requirements for Reliable Server Pooling", 830 RFC 3237, January 2002. 832 Authors' Addresses 834 Michael Tuexen 835 Siemens AG 836 ICN WN CC SE 7 837 D-81359 Munich 838 Germany 840 Phone: +49 89 722 47210 841 EMail: Michael.Tuexen@icn.siemens.de 843 Qiaobing Xie 844 Motorola, Inc. 845 1501 W. Shure Drive, #2309 846 Arlington Heights, IL 60004 847 USA 849 Phone: +1-847-632-3028 850 EMail: qxie1@email.mot.com 851 Randall R. Stewart 852 Cisco Systems, Inc. 853 8725 West Higgins Road 854 Suite 300 855 Chicago, IL 60631 856 USA 858 Phone: +1-815-477-2127 859 EMail: rrs@cisco.com 861 Melinda Shore 862 Cisco Systems, Inc. 863 809 Hayts Rd 864 Ithaca, NY 14850 865 USA 867 Phone: +1 607 272 7512 868 EMail: mshore@cisco.com 870 Lyndon Ong 871 Ciena Corporation 872 10480 Ridgeview Drive 873 Cupertino, CA 95014 874 USA 876 EMail: lyong@ciena.com 878 John Loughney 879 Nokia Research Center 880 PO Box 407 881 FIN-00045 Nokia Group FIN-00045 882 Finland 884 EMail: john.loughney@nokia.com 886 Maureen Stillman 887 Nokia 888 127 W. State Street 889 Ithaca, NY 14850 890 USA 892 Phone: +1-607-273-0724 893 EMail: maureen.stillman@nokia.com 895 Full Copyright Statement 897 Copyright (C) The Internet Society (2002). All Rights Reserved. 899 This document and translations of it may be copied and furnished to 900 others, and derivative works that comment on or otherwise explain it 901 or assist in its implementation may be prepared, copied, published 902 and distributed, in whole or in part, without restriction of any 903 kind, provided that the above copyright notice and this paragraph are 904 included on all such copies and derivative works. However, this 905 document itself may not be modified in any way, such as by removing 906 the copyright notice or references to the Internet Society or other 907 Internet organizations, except as needed for the purpose of 908 developing Internet standards in which case the procedures for 909 copyrights defined in the Internet Standards process must be 910 followed, or as required to translate it into languages other than 911 English. 913 The limited permissions granted above are perpetual and will not be 914 revoked by the Internet Society or its successors or assigns. 916 This document and the information contained herein is provided on an 917 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 918 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 919 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 920 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 921 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 923 Acknowledgement 925 Funding for the RFC Editor function is currently provided by the 926 Internet Society.