idnits 2.17.1 draft-ietf-rserpool-arch-06.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.) ** 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 454 has weird spacing: '...kie. In case ...' == Line 501 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 29, 2003) is 7599 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 816, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 821, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 827, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 830, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 834, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 793 (ref. '2') (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2960 (ref. '6') (Obsoleted by RFC 4960) Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Tuexen, Ed. 3 Internet-Draft Univ. of Applied Sciences Muenster 4 Expires: December 28, 2003 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 29, 2003 17 Architecture for Reliable Server Pooling 18 draft-ietf-rserpool-arch-06.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 other 27 groups may also distribute working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at http:// 35 www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on December 28, 2003. 42 Copyright Notice 44 Copyright (C) The Internet Society (2003). All Rights Reserved. 46 Abstract 48 This document describes an architecture and protocols for the 49 management and operation of server pools supporting highly reliable 50 applications, and for client access mechanisms to a server pool. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.3 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Reliable Server Pooling Architecture . . . . . . . . . . . . 4 59 2.1 RSerPool Functional Components . . . . . . . . . . . . . . . 4 60 2.2 RSerPool Protocol Overview . . . . . . . . . . . . . . . . . 5 61 2.2.1 Endpoint Name Resolution Protocol . . . . . . . . . . . . . 5 62 2.2.2 Aggregate Server Access Protocol . . . . . . . . . . . . . . 6 63 2.2.3 PU <-> NS Communication . . . . . . . . . . . . . . . . . . 6 64 2.2.4 PE <-> NS Communication . . . . . . . . . . . . . . . . . . 7 65 2.2.5 PU <-> PE Communication . . . . . . . . . . . . . . . . . . 7 66 2.2.6 NS <-> NS Communication . . . . . . . . . . . . . . . . . . 8 67 2.2.7 PE <-> PE Communication . . . . . . . . . . . . . . . . . . 9 68 2.3 Failover Support . . . . . . . . . . . . . . . . . . . . . . 9 69 2.3.1 Business Cards . . . . . . . . . . . . . . . . . . . . . . . 9 70 2.3.2 Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 2.4 Typical Interactions between RSerPool Components . . . . . . 10 72 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 3.1 Two File Transfer Examples . . . . . . . . . . . . . . . . . 12 74 3.1.1 The RSerPool Aware Client . . . . . . . . . . . . . . . . . 13 75 3.1.2 The RSerPool Unaware Client . . . . . . . . . . . . . . . . 14 76 3.2 Telephony Signaling Example . . . . . . . . . . . . . . . . 15 77 3.2.1 Decomposed GWC and GK Scenario . . . . . . . . . . . . . . . 15 78 3.2.2 Collocated GWC and GK Scenario . . . . . . . . . . . . . . . 17 79 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 80 Normative References . . . . . . . . . . . . . . . . . . . . 18 81 Informative References . . . . . . . . . . . . . . . . . . . 18 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19 83 Intellectual Property and Copyright Statements . . . . . . . 21 85 1. Introduction 87 1.1 Overview 89 This document defines an architecture, for providinge a highly 90 available reliable server function in support of some service. The 91 way this is achieved is by forming a pool of servers, each of which 92 is capable of supporting the desired service, and providing a name 93 service that will resolve requests from a service user to the 94 identity of a working server in the pool. 96 To access a server pool, the pool user consults a name server. The 97 name service itself can be provided by a pool of name servers using a 98 shared protocol to make the name resolution function fault-tolerant. 99 It is assumed that the name space is kept flat and designed for a 100 limited scale in order to keep the protocols simple, robust and fast. 102 The server pool itself is supported by a shared protocol between 103 servers and the name service allowing servers to enter and exit the 104 pool. Several server selection mechanisms, called server pool 105 policies, are supported for flexibility. 107 1.2 Terminology 109 This document uses the following terms: 111 Home Name Server: The Name Server a Pool Element has registered with. 112 This Name Server supervises the Pool Element. 114 Operation scope: The part of the network visible to pool users by a 115 specific instance of the reliable server pooling protocols. 117 Pool (or server pool): A collection of servers providing the same 118 application functionality. 120 Pool handle (or pool name): A logical pointer to a pool. Each server 121 pool will be identifiable in the operation scope of the system by 122 a unique pool handle or "name". 124 Pool element: A server entity having registered to a pool. 126 Pool user: A server pool user. 128 Pool element handle (or endpoint handle): A logical pointer to a 129 particular pool element in a pool, consisting of the name of the 130 pool and a destination transport address of the pool element. 132 Name space: A cohesive structure of pool names and relations that may 133 be queried by an internal or external agent. 135 Name server: Entity which is responsible for managing and maintaining 136 the name space within the RSerPool operation scope. 138 1.3 Abbreviations 140 ASAP: Aggregate Server Access Protocol 142 ENRP: Endpoint Name Resolution Protocol 144 Home NS: Home Name Server 146 NS: Name Server 148 PE: Pool element 150 PU: Pool user 152 SCTP: Stream Control Transmission Protocol 154 TCP: Transmission Control Protocol 156 2. Reliable Server Pooling Architecture 158 In this section, we define a reliable server pool architecture. 160 2.1 RSerPool Functional Components 162 There are three classes of entities in the RSerPool architecture: 164 o Pool Elements (PEs). 166 o Name Servers (NSs). 168 o Pool Users (PUs). 170 A server pool is defined as a set of one or more servers providing 171 the same application functionality. These servers are called Pool 172 Elements (PEs). PEs form the first class of entities in the RSerPool 173 architecture. Multiple PEs in a server pool can be used to provide 174 fault tolerance or load sharing, for example. 176 Each server pool will be identifiable by a unique name which is 177 simply a byte string, called the pool handle. This allows binary 178 names to be used. 180 These names are not valid in the whole internet but only in smaller 181 domains, called the operational scope. Furthermore, the namespace is 182 assumed to be flat, so that multiple levels of query are not 183 necessary to resolve a name request. 185 The second class of entities in the RSerPool architecture is the 186 class of name servers (NSs). These name servers can resolve a pool 187 handle to a list of information which allows the PU to access a PE of 188 the server pool identified by the handle. This information includes: 190 o A list of IPv4 and/or IPv6 addresses. 192 o A protocol field of the IP header specifying the transport layer 193 protocol or protocols. 195 o A port number associatiated with the transport protocol, e.g. 196 SCTP, TCP or UDP. 198 Please note that the RSerPool architecture supports both IPv4 and 199 IPv6 addressing. A PE can also support multiple transport layers. 201 In each operational scope there must be at least one name server. All 202 name servers within the operational scope have knowledge of all 203 server pools within the operational scope. 205 A third class of entities in the architecture is the Pool User (PU) 206 class, consisting of the clients being served by the PEs of a server 207 pool. 209 2.2 RSerPool Protocol Overview 211 The RSerPool requested features can be obtained with the help of the 212 combination of two protocols: ENRP (Endpoint Name Resolution 213 Protocol) and ASAP (Aggregate Server Access Protocol). 215 2.2.1 Endpoint Name Resolution Protocol 217 The name servers use a protocol called Endpoint Name Resolution 218 Protocol (ENRP) for communication with each other to make sure that 219 all have the same information about the server pools. 221 ENRP is designed to provide a fully distributed fault-tolerant 222 real-time translation service that maps a name to a set of transport 223 addresses pointing to a specific group of networked communication 224 endpoints registered under that name. ENRP employs a client-server 225 model with which an name server will respond to the name translation 226 service requests from endpoint clients running on the same host or 227 running on different hosts. 229 RFC3237 [7] also requires that the name servers should not resolve a 230 pool handle to a transport layer address of a PE which is not in 231 operation. Therefore each PE is supervised by one specific name 232 server, called the home NS of that PE. If it detects that the PE is 233 out of service all other name servers are informed by using ENRP. 235 2.2.2 Aggregate Server Access Protocol 237 The PU wanting service from the pool uses the Aggregate Server Access 238 Protocol (ASAP) to access members of the pool. Depending on the 239 level of support desired by the application, use of ASAP may be 240 limited to an initial query for an active PE, or ASAP may be used to 241 mediate all communication between the PU and PE, so that automatic 242 failover from a failed PE to an alternate PE can be supported. 244 ASAP in conjunction with ENRP provides a fault tolerant data transfer 245 mechanism over IP networks. ASAP uses a name-based addressing model 246 which isolates a logical communication endpoint from its IP 247 address(es), thus effectively eliminating the binding between the 248 communication endpoint and its physical IP address(es) which normally 249 constitutes a single point of failure. 251 In addition, ASAP defines each logical communication destination as a 252 server pool, providing full transparent support for server-pooling 253 and load sharing. 255 ASAP is also used by a server to join or leave a server pool. It 256 registers or deregisters itself by communicating with a name server, 257 which will normally the home NS. ASAP allows dynamic system 258 scalability, allowing the pool membership to change at any time 259 without interruption of the service. 261 2.2.3 PU <-> NS Communication 263 The PU <-> NS communication is used for doing name queries. The PU 264 sends a pool handle to the NS and gets back the information necessary 265 for accessing a server in a server pool. 267 ******** ******** 268 * PU * * NS * 269 ******** ******** 271 +------+ +------+ 272 | ASAP | | ASAP | 273 +------+ +------+ 274 | SCTP | | SCTP | 275 +------+ +------+ 276 | IP | | IP | 277 +------+ +------+ 279 Protocol stack between PU and NS 281 Figure 1 283 This communication can be based on SCTP or TCP if the PU does not 284 support SCTP. The protocol stack for an SCTP capable PU is given in 285 Figure 1. 287 2.2.4 PE <-> NS Communication 289 The PE <-> NS communication is used for registration and 290 deregistration of the PE in one ore more pools and for the 291 supervision of the PE by the home NS. This communication is based on 292 SCTP, the protocol stack is shown in the following figure. 294 ******** ******** 295 * PE * * NS * 296 ******** ******** 298 +------+ +------+ 299 | ASAP | | ASAP | 300 +------+ +------+ 301 | SCTP | | SCTP | 302 +------+ +------+ 303 | IP | | IP | 304 +------+ +------+ 305 Protocol stack between PE and NS 307 Figure 2 309 2.2.5 PU <-> PE Communication 311 The PU <-> PE communication can be divided into two parts: 313 o control channel 315 o data channel 317 The data channel is used for the transmission of the upper layer 318 data, the control channel is used to exchange RSerPool information. 320 There are two supported scenarios: 322 o Multiplexed data and control channel. Both channels are 323 transported over one transport connection. This can either be an 324 SCTP association, with data and control channel are seperated by 325 the PPID, or an TCP connection, with data and control channel 326 being handled by a TCP mapping layer. 328 o Data channel and no control channel. There is no restriction on 329 the transport protocol in this case. Note that certain enhanced 330 failover services (e.g. business cards, state cookies, message 331 failover) are not available when this method is used. 333 For a given pool, all PUs and PEs should make the same choice for the 334 style of interaction between each other: that is, for a given pool, 335 either all PEs and PUs in that pool use a multiplexed control/data 336 channel for PU-PE communication, or all PEs and PUs in that pool use 337 a data channel only for PU-PE communication. 339 When the multiplexed data and control channel is used, enhanced 340 failover services may be provided, including: 342 o The PE can send a business card to the PU for providing 343 information to which other PE the PU should failover in case of a 344 failover. 346 o The PE can send cookies to the PU. The PE would store only the 347 last cookie and send it to the new PE in case of a failover. 349 See Section 2.3 for further details. 351 2.2.6 NS <-> NS Communication 353 The communication between name servers is used to share the knowledge 354 about all server pools between all name servers in an operational 355 scope. 357 ******** ******** 358 * NS * * NS * 359 ******** ******** 361 +------+ +------+ 362 | ENRP | | ENRP | 363 +------+ +------+ 364 | SCTP | | SCTP | 365 +------+ +------+ 366 | IP | | IP | 367 +------+ +------+ 368 Protocol stack between NS and NS 369 Figure 3 371 For this communication ENRP over SCTP is used. 373 When a name server boots up a UDP multicast message may be sent out 374 for initial detection of other name servers in the operational scope. 375 The other name servers send an answer using a unicast UDP message. 377 2.2.7 PE <-> PE Communication 379 This is a special case of the PU <-> PE communication. In this case 380 the PU is also a PE in a server pool. 382 There is one additional point here: The PE acting as a PU can send 383 the PE the information that it is acually a PE of pool. This means 384 that the pool handle is transferred via the control channel. See 385 Section 2.3 for further details. 387 2.3 Failover Support 389 If the PU detects the failure of a PE it may fail over to a different 390 PE. The selection to a new PE should be made such that most likely 391 the new PE is not affected by the failed one. 393 There are some mechanisms provided by RSerPool to support the 394 failover to a new PE. 396 2.3.1 Business Cards 398 A PE can send a business card to its peer containing its pool handle 399 and optionally information to which other PEs the peer should 400 failover. 402 Presenting the pool handle is important in case of PE <-> PE 403 communication in which one of the PEs acts as a PU for establishing 404 the communication. The pool handle of the PE which initiated the 405 communication may not be know by the peer. 407 Providing information to which PE the OU should failover can also be 408 very important. Consider the scenario given in the following figure. 410 ....................... 411 . +-------+ . 412 . | | . 413 . | PE 1 | . 414 . | | . 415 . +-------+ . 416 . . 418 . Server Pool . 419 . . 420 . . 421 +-------+ . +-------+ . +-------+ 422 | | . | | . | | 423 | PU 1 |------.------| PE 2 |------.-------| PU 2 | 424 | | . | | . | | 425 +-------+ . +-------+ . +-------+ 426 . . 427 . . 428 . . 429 . . 430 . +-------+ . 431 . | | . 432 . | PE 3 | . 433 . | | . 434 . +-------+ . 435 ....................... 436 Two PE accessing the same PE 438 Figure 4 440 PU 1 is using PE 2 of the server pool. Assume that PE 1 and PE 2 441 share state but not PE 2 and PE 3. Using the business card of PE 2 it 442 is possible for PE 2 to inform PU 1 that it should fail over to PE 1 443 in case of a failure. 445 A slightly more complicated situation is if two pool users, PU 1 and 446 PU 2, use PE 2 but both, PU 1 and PU 2, need to use the same PE. Then 447 it is important that PU 1 and PU 2 fail over to the same PE. This can 448 be handled in a way such that PE 2 gives the same business card to PU 449 1 and PU 2. 451 2.3.2 Cookies 453 Cookies may be sent from the PE to the PU if the PE wants to do this. 454 The PU only stores the last received cookie. In case of a fail over 455 it sends this last received cookie to the new PE. This method 456 provides a simple way of state sharing between the PEs. Please note 457 that the old PE should sign the cookie and the receiving PE should 458 verify the signature. For the PU, the cookie has no structure and is 459 only stored and transmitted to the new PE. 461 2.4 Typical Interactions between RSerPool Components 463 The following drawing shows the typical RSerPool components and their 464 possible interactions with each other: 466 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 467 ~ operation scope ~ 468 ~ ......................... ......................... ~ 469 ~ . Server Pool 1 . . Server Pool 2 . ~ 470 ~ . +-------+ +-------+ . (d) . +-------+ +-------+ . ~ 471 ~ . |PE(1,A)| |PE(1,C)|<-------------->|PE(2,B)| |PE(2,A)|<---+ ~ 472 ~ . +-------+ +-------+ . . +-------+ +-------+ . | ~ 473 ~ . ^ ^ . . ^ ^ . | ~ 474 ~ . | (a) | . . | | . | ~ 475 ~ . +----------+ | . . | | . | ~ 476 ~ . +-------+ | | . . | | . | ~ 477 ~ . |PE(1,B)|<---+ | | . . | | . | ~ 478 ~ . +-------+ | | | . . | | . | ~ 479 ~ . ^ | | | . . | | . | ~ 480 ~ .......|........|.|.|.... .......|.........|....... | ~ 481 ~ | | | | | | | ~ 482 ~ (c)| (a)| | |(a) (a)| (a)| (c)| ~ 483 ~ | | | | | | | ~ 484 ~ | v v v v v | ~ 485 ~ | +++++++++++++++ (e) +++++++++++++++ | ~ 486 ~ | + NS +<---------->+ NS + | ~ 487 ~ | +++++++++++++++ +++++++++++++++ | ~ 488 ~ v ^ ^ | ~ 489 ~ ********* | | | ~ 490 ~ * PU(A) *<-------+ (b)| | ~ 491 ~ ********* (b) | | ~ 492 ~ v | ~ 493 ~ ::::::::::::::::: (f) ***************** | ~ 494 ~ : Other Clients :<------------->* Proxy/Gateway * <---+ ~ 495 ~ ::::::::::::::::: ***************** ~ 496 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 497 RSerPool components and their possible interactions. 499 Figure 5 501 In this figure we can identify the following possible interactions: 503 (a) Server Pool Elements <-> NS: (ASAP) Each PE in a pool uses ASAP 504 to register or de-register itself as well as to exchange other 505 auxiliary information with the NS. The NS also uses ASAP to 506 monitor the operational status of each PE in a pool. 508 (b) PU <-> NS: (ASAP) A PU normally uses ASAP to request the NS for a 509 name-to-address translation service before the PU can send user 510 messages addressed to a server pool by the pool's name. 512 (c) PU <-> PE: (ASAP) ASAP can be used to exchange some auxiliary 513 information of the two parties before they engage in user data 514 transfer. 516 (d) Server Pool <-> Server Pool: (ASAP) A PE in a server pool can 517 become a PU to another pool when the PE tries to initiate 518 communication with the other pool. In such a case, the 519 interactions described in (a) and (c) above will apply. 521 (e) NS <-> NS: (ENRP) ENRP can be used to fulfill various Name Space 522 operation, administration, and maintenance (OAM) functions. 524 (f) Other Clients <-> Proxy/Gateway: standard protocols The proxy/ 525 gateway enables clients ("other clients"), which are not RSerPool 526 aware, to access services provided by an RSerPool based server 527 pool. It should be noted that these proxies/gateways may become a 528 single point of failure. 530 3. Examples 532 [Editors note] This section has not been updated. The examples will 533 be updated after the architecture has been finalized. 535 In this section the basic concepts of ENRP and ASAP will be 536 described. First an RSerPool aware FTP server is considered. The 537 interaction with an RSerPool aware and an non-aware client is given. 538 Finally, a telephony example is considered. 540 3.1 Two File Transfer Examples 542 In this section we present two separate file transfer examples using 543 ENRP and ASAP. We present two separate examples demonstrating an 544 ENRP/ASAP aware client and a client that is using a Proxy or Gateway 545 to perform the file transfer. In this example we will use a FTP 546 RFC959 [3] model with some modifications. The first example (the 547 RSerPool aware one) will modify FTP concepts so that the file 548 transfer takes place over SCTP. In the second example we will use TCP 549 between the unaware client and the Proxy. The Proxy itself will use 550 the modified FTP with RSerPool as illustrated in the first example. 552 Please note that in the example we do NOT follow FTP RFC959 [3] 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 Figure 6 590 To effect a file transfer the following steps would take place. 592 1. The application in PU(X) would send a login request. The PU(X)'s 593 ASAP layer would send an ASAP request to its NS to request the 594 list of pool elements (using (a)). The pool handle to identify 595 the pool would be "File Transfer Pool". The ASAP layer queues the 596 login request. 598 2. The NS would return a list of the three PEs PE(1,A), PE(1,B) and 599 PE(1,C) to the ASAP layer in PU(X) (using (b)). 601 3. The ASAP layer selects one of the PEs, for example PE(1,B). It 602 transmits the login request, the other FTP control data finally 603 starts the transmission of the requested files (using (c)). For 604 this the multiple stream feature of SCTP could be used. 606 4. If during the file transfer conversation, PE(1,B) fails, assuming 607 the PE's were sharing state of file transfer, a fail-over to 608 PE(1,A) could be initiated. PE(1,A) would continue the transfer 609 until complete (see (d)). In parallel a request from PE(1,A) 610 would be made to ENRP to request a cache update for the server 611 pool "File Transfer Pool" and a report would also be made that 612 PE(1,B) is non-responsive (this would cause appropriate audits 613 that may remove PE(1,B) from the pool if the NS had not already 614 detected the failure) (using (a)). 616 3.1.2 The RSerPool Unaware Client 618 In this example we investigate the use of a Proxy server assuming the 619 same set of scenario as illustrated above. 621 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 622 ~ operation scope ~ 623 ~ ......................... ~ 624 ~ . "File Transfer Pool" . ~ 625 ~ . +-------+ +-------+ . ~ 626 ~ . |PE(1,A)| |PE(1,C)| . ~ 627 ~ . +-------+ +-------+ . ~ 628 ~ . ^ ^ . ~ 629 ~ . +----------+ | . ~ 630 ~ . +-------+ | | . ~ 631 ~ . |PE(1,B)|<---+ | | . ~ 632 ~ . +-------+ | | | . ~ 633 ~ .......^........|.|.|.... ~ 634 ~ | | | | ~ 635 ~ | ASAP| | |ASAP ~ 636 ~ | | | | ~ 637 ~ | v v v ~ 638 ~ | +++++++++++++++ +++++++++++++++ ~ 639 ~ | + NS +<--ENRP-->+ NS + ~ 640 ~ | +++++++++++++++ +++++++++++++++ ~ 641 ~ | ASAP ^ ~ 642 ~ | ASAP (c) (b) | ^ ~ 643 ~ +---------------------------------+ | | | ~ 644 ~ | v | (a) ~ 645 ~ v v ~ 646 ~ ::::::::::::::::: (e)-> ***************** ~ 647 ~ : FTP Client :<------------->* Proxy/Gateway * ~ 648 ~ ::::::::::::::::: (f) ***************** ~ 649 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 650 Architecture for RserPool unaware client. 652 Figure 7 654 In this example the steps will occur: 656 1. The FTP client and the Proxy/Gateway are using the TCP-based ftp 657 protocol. The client sends the login request to the proxy (using 658 (e)). 660 2. The proxy behaves like a client and performs the actions 661 described under (1), (2) and (3) of the above description (using 662 (a), (b) and (c)). 664 3. The ftp communication continues and will be translated by the 665 proxy into the RSerPool aware dialect. This interworking uses (f) 666 and (c). 668 Note that in this example high availability is maintained between the 669 Proxy and the server pool but a single point of failure exists 670 between the FTP client and the Proxy, i.e. the command TCP connection 671 and its one IP address it is using for commands. 673 3.2 Telephony Signaling Example 675 This example shows the use of ASAP/RSerPool to support server pooling 676 for high availability of a telephony application such as a Voice over 677 IP Gateway Controller (GWC) and Gatekeeper services (GK). 679 In this example, we show two different scenarios of deploying these 680 services using RSerPool in order to illustrate the flexibility of the 681 RSerPool architecture. 683 3.2.1 Decomposed GWC and GK Scenario 685 In this scenario, both GWC and GK services are deployed as separate 686 pools with some number of PEs, as shown in the following diagram. 687 Each of the pools will register their unique pool handle (i.e. name) 688 with the NS. We also assume that there are a Signaling Gateway (SG) 689 and a Media Gateway (MG) present and both are RSerPool aware. 691 ................... 692 . Gateway . 693 . Controller Pool . 694 ................. . +-------+ . 695 . Gatekeeper . . |PE(2,A)| . 696 . Pool . . +-------+ . 697 . +-------+ . . +-------+ . 698 . |PE(1,A)| . . |PE(2,B)| . 699 . +-------+ . . +-------+ . 700 . +-------+ . (d) . +-------+ . 701 . |PE(1,B)|<------------>|PE(2,C)|<-------------+ 702 . +-------+ . . +-------+ . | 703 ................. ........^.......... | 704 | | 705 (c)| (e)| 706 | v 707 +++++++++++++++ ********* ***************** 708 + NS + * SG(X) * * Media Gateway * 709 +++++++++++++++ ********* ***************** 710 ^ ^ 711 | | 712 | <-(a) | 713 +-------------------+ 714 (b)-> 716 Deployment of Decomposed GWC and GK. 718 Figure 8 720 As shown in the previous figure, the following sequence takes place: 722 1. the Signaling Gateway (SG) receives an incoming signaling message 723 to be forwarded to the GWC. SG(X)'s ASAP layer would send an ASAP 724 request to its "local" NS to request the list of pool elements 725 (PE's) of GWC (using (a)). The key used for this query is the 726 pool handle of the GWC. The ASAP layer queues the data to be sent 727 in local buffers until the NS responds. 729 2. the NS would return a list of the three PE's A, B and C to the 730 ASAP layer in SG(X) together with information to be used for 731 load-sharing traffic across the gateway controller pool (using 732 (b)). 734 3. the ASAP layer in SG(X) will select one PE (e.g., PE(2,C)) and 735 send the signaling message to it (using (c)). The selection is 736 based on the load sharing information of the gateway controller 737 pool. 739 4. to progress the call, PE(2,C) finds that it needs to talk to the 740 Gatekeeper. Assuming it has already had gatekeeper pool's 741 information in its local cache (e.g., obtained and stored from 742 recent query to NS), PE(2,C) selects PE(1,B) and sends the call 743 control message to it (using (d)). 745 5. We assume PE(1,B) responds back to PE(2,C) and authorizes the 746 call to proceed. 748 6. PE(2,C) issues media control commands to the Media Gateway (using 749 (e)). 751 RSerPool will provide service robustness to the system if some 752 failure would occur in the system. 754 For instance, if PE(1, B) in the Gatekeeper Pool crashed after 755 receiving the call control message from PE(2, C) in step (d) above, 756 what most likely will happen is that, due to the absence of a reply 757 from the Gatekeeper, a timer expiration event will trigger the call 758 state machine within PE(2, C) to resend the control message. The ASAP 759 layer at PE(2, C) will then notice the failure of PE(1, B) through 760 (likely) the endpoint unreachability detection by the transport 761 protocol beneath ASAP and automatically deliver the re-sent call 762 control message to the alternate GK pool member PE(1, A). With 763 appropriate intra-pool call state sharing support, PE(1, A) will be 764 able to correctly handle the call and reply to PE(2, C) and hence 765 progress the call. 767 3.2.2 Collocated GWC and GK Scenario 769 In this scenario, the GWC and GK services are collocated (e.g., they 770 are implemented as a single process). In such a case, one can form a 771 pool that provides both GWC and GK services as shown in the figure 772 below. 774 ........................................ 775 . Gateway Controller/Gatekeeper Pool . 776 . +-------+ . 777 . |PE(3,A)| . 778 . +-------+ . 779 . +-------+ . 780 . |PE(3,C)|<---------------------------+ 781 . +-------+ . | 782 . +-------+ ^ . | 783 . |PE(3,B)| | . | 784 . +-------+ | . | 785 ................|....................... | 786 | | 787 +-------------+ | 788 | | 789 (c)| (e)| 790 v v 791 +++++++++++++++ ********* ***************** 792 + NS + * SG(X) * * Media Gateway * 793 +++++++++++++++ ********* ***************** 794 ^ ^ 795 | | 796 | <-(a) | 797 +-------------------+ 798 (b)-> 800 Deployment of Collocated GWC and GK. 802 Figure 9 804 The same sequence as described in 5.2.1 takes place, except that step 805 (4) now becomes internal to the PE(3,C) (again, we assume Server C is 806 selected by SG). 808 4. Acknowledgements 810 The authors would like to thank Bernard Aboba, Phillip Conrad, Harrie 811 Hazewinkel, Matt Holdrege, Christopher Ross, Werner Vogels and many 812 others for their invaluable comments and suggestions. 814 Normative References 816 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 817 9, RFC 2026, October 1996. 819 Informative References 821 [2] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 822 September 1981. 824 [3] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 825 959, October 1985. 827 [4] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service 828 Location Protocol, Version 2", RFC 2608, June 1999. 830 [5] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L., 831 Lin, H., Juhasz, I., Holdrege, M. and C. Sharp, "Framework 832 Architecture for Signaling Transport", RFC 2719, October 1999. 834 [6] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 835 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 836 "Stream Control Transmission Protocol", RFC 2960, October 2000. 838 [7] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, 839 J. and M. Stillman, "Requirements for Reliable Server Pooling", 840 RFC 3237, January 2002. 842 Authors' Addresses 844 Michael Tuexen (editor) 845 Univ. of Applied Sciences Muenster 846 Stegerwaldstr. 39 847 48565 Steinfurt 848 Germany 850 EMail: tuexen@fh-muenster.de 852 Qiaobing Xie 853 Motorola, Inc. 854 1501 W. Shure Drive, #2309 855 Arlington Heights, IL 60004 856 USA 858 Phone: +1-847-632-3028 859 EMail: qxie1@email.mot.com 861 Randall R. Stewart 862 Cisco Systems, Inc. 863 8725 West Higgins Road 864 Suite 300 865 Chicago, IL 60631 866 USA 868 Phone: +1-815-477-2127 869 EMail: rrs@cisco.com 871 Melinda Shore 872 Cisco Systems, Inc. 873 809 Hayts Rd 874 Ithaca, NY 14850 875 USA 877 Phone: +1 607 272 7512 878 EMail: mshore@cisco.com 879 Lyndon Ong 880 Ciena Corporation 881 10480 Ridgeview Drive 882 Cupertino, CA 95014 883 USA 885 EMail: lyong@ciena.com 887 John Loughney 888 Nokia Research Center 889 PO Box 407 890 FIN-00045 Nokia Group FIN-00045 891 Finland 893 EMail: john.loughney@nokia.com 895 Maureen Stillman 896 Nokia 897 127 W. State Street 898 Ithaca, NY 14850 899 USA 901 Phone: +1-607-273-0724 902 EMail: maureen.stillman@nokia.com 904 Intellectual Property Statement 906 The IETF takes no position regarding the validity or scope of any 907 intellectual property or other rights that might be claimed to 908 pertain to the implementation or use of the technology described in 909 this document or the extent to which any license under such rights 910 might or might not be available; neither does it represent that it 911 has made any effort to identify any such rights. Information on the 912 IETF's procedures with respect to rights in standards-track and 913 standards-related documentation can be found in BCP-11. Copies of 914 claims of rights made available for publication and any assurances of 915 licenses to be made available, or the result of an attempt made to 916 obtain a general license or permission for the use of such 917 proprietary rights by implementors or users of this specification can 918 be obtained from the IETF Secretariat. 920 The IETF invites any interested party to bring to its attention any 921 copyrights, patents or patent applications, or other proprietary 922 rights which may cover technology that may be required to practice 923 this standard. Please address the information to the IETF Executive 924 Director. 926 Full Copyright Statement 928 Copyright (C) The Internet Society (2003). All Rights Reserved. 930 This document and translations of it may be copied and furnished to 931 others, and derivative works that comment on or otherwise explain it 932 or assist in its implementation may be prepared, copied, published 933 and distributed, in whole or in part, without restriction of any 934 kind, provided that the above copyright notice and this paragraph are 935 included on all such copies and derivative works. However, this 936 document itself may not be modified in any way, such as by removing 937 the copyright notice or references to the Internet Society or other 938 Internet organizations, except as needed for the purpose of 939 developing Internet standards in which case the procedures for 940 copyrights defined in the Internet Standards process must be 941 followed, or as required to translate it into languages other than 942 English. 944 The limited permissions granted above are perpetual and will not be 945 revoked by the Internet Society or its successors or assignees. 947 This document and the information contained herein is provided on an 948 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 949 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 950 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 951 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 952 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 954 Acknowledgment 956 Funding for the RFC Editor function is currently provided by the 957 Internet Society.