idnits 2.17.1 draft-ietf-rserpool-arch-07.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 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 495 has weird spacing: '... figure we ca...' == Line 820 has weird spacing: '...esponse to Th...' -- 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 (October 12, 2003) is 7501 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: '3' is defined on line 825, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 831, 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 == Unused Reference: '7' is defined on line 838, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-rserpool-threats-02 ** Downref: Normative reference to an Informational draft: draft-ietf-rserpool-threats (ref. '2') -- Obsolete informational reference (is this intentional?): RFC 793 (ref. '3') (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2960 (ref. '7') (Obsoleted by RFC 4960) Summary: 4 errors (**), 0 flaws (~~), 10 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: April 11, 2004 Q. Xie 5 Motorola, Inc. 6 R. Stewart 7 M. Shore 8 Cisco Systems, Inc. 9 J. Loughney 10 Nokia Research Center 11 October 12, 2003 13 Architecture for Reliable Server Pooling 14 draft-ietf-rserpool-arch-07.txt 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at http:// 31 www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 11, 2004. 38 Copyright Notice 40 Copyright (C) The Internet Society (2003). All Rights Reserved. 42 Abstract 44 This document describes an architecture and protocols for the 45 management and operation of server pools supporting highly reliable 46 applications, and for client access mechanisms to a server pool. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.3 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. Reliable Server Pooling Architecture . . . . . . . . . . . . 4 55 2.1 RSerPool Functional Components . . . . . . . . . . . . . . . 4 56 2.2 RSerPool Protocol Overview . . . . . . . . . . . . . . . . . 5 57 2.2.1 Endpoint Name Resolution Protocol . . . . . . . . . . . . . 5 58 2.2.2 Aggregate Server Access Protocol . . . . . . . . . . . . . . 6 59 2.2.3 PU <-> NS Communication . . . . . . . . . . . . . . . . . . 6 60 2.2.4 PE <-> NS Communication . . . . . . . . . . . . . . . . . . 7 61 2.2.5 PU <-> PE Communication . . . . . . . . . . . . . . . . . . 7 62 2.2.6 NS <-> NS Communication . . . . . . . . . . . . . . . . . . 8 63 2.2.7 PE <-> PE Communication . . . . . . . . . . . . . . . . . . 9 64 2.3 Failover Support . . . . . . . . . . . . . . . . . . . . . . 9 65 2.3.1 Business Cards . . . . . . . . . . . . . . . . . . . . . . . 9 66 2.3.2 Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 2.4 Typical Interactions between RSerPool Components . . . . . . 11 68 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 3.1 Two File Transfer Examples . . . . . . . . . . . . . . . . . 12 70 3.1.1 The RSerPool Aware Client . . . . . . . . . . . . . . . . . 13 71 3.1.2 The RSerPool Unaware Client . . . . . . . . . . . . . . . . 14 72 3.2 Telephony Signaling Example . . . . . . . . . . . . . . . . 15 73 3.2.1 Decomposed GWC and GK Scenario . . . . . . . . . . . . . . . 15 74 3.2.2 Collocated GWC and GK Scenario . . . . . . . . . . . . . . . 17 75 4. Security Considerations . . . . . . . . . . . . . . . . . . 18 76 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 77 Normative References . . . . . . . . . . . . . . . . . . . . 18 78 Informative References . . . . . . . . . . . . . . . . . . . 19 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19 80 Intellectual Property and Copyright Statements . . . . . . . 21 82 1. Introduction 84 1.1 Overview 86 This document defines an architecture, for providing a highly 87 available reliable server function in support of a service or set of 88 services. This is achieved is by forming a pool of servers, each of 89 which is capable of supporting the desired service(s), and providing 90 a name service that will resolve requests from a service user to the 91 identity of a working server in the pool. 93 To access a server pool, the pool user consults a name server. The 94 name service itself can be provided by a pool of name servers using a 95 shared protocol to make the name resolution function fault-tolerant. 96 It is assumed that the name space is kept flat and designed for a 97 limited scale in order to keep the protocols simple, robust and fast. 99 The server pool itself is supported by a shared protocol between 100 servers and the name service allowing servers to enter and exit the 101 pool. Several server selection mechanisms, called server pool 102 policies, are supported for flexibility. 104 1.2 Terminology 106 This document uses the following terms: 108 Home Name Server: The Name Server a Pool Element has registered with. 109 This Name Server supervises the Pool Element. 111 Operation scope: The part of the network visible to pool users by a 112 specific instance of the reliable server pooling protocols. 114 Pool (or server pool): A collection of servers providing the same 115 application functionality. 117 Pool handle (or pool name): A logical pointer to a pool. Each server 118 pool will be identifiable in the operation scope of the system by 119 a unique pool handle or "name". 121 Pool element: A server entity having registered to a pool. 123 Pool user: A server pool user. 125 Pool element handle (or endpoint handle): A logical pointer to a 126 particular pool element in a pool, consisting of the name of the 127 pool and a destination transport address of the pool element. 129 Name space: A cohesive structure of pool names and relations that may 130 be queried by an internal or external agent. 132 Name server: Entity which is responsible for managing and maintaining 133 the name space within the RSerPool operation scope. 135 1.3 Abbreviations 137 ASAP: Aggregate Server Access Protocol 139 ENRP: Endpoint Name Resolution Protocol 141 Home NS: Home Name Server 143 NS: Name Server 145 PE: Pool element 147 PU: Pool user 149 SCTP: Stream Control Transmission Protocol 151 TCP: Transmission Control Protocol 153 2. Reliable Server Pooling Architecture 155 In this section, we define a reliable server pool architecture. 157 2.1 RSerPool Functional Components 159 There are three classes of entities in the RSerPool architecture: 161 o Pool Elements (PEs). 163 o Name Servers (NSs). 165 o Pool Users (PUs). 167 A server pool is defined as a set of one or more servers providing 168 the same application functionality. These servers are called Pool 169 Elements (PEs). PEs form the first class of entities in the RSerPool 170 architecture. Multiple PEs in a server pool can be used to provide 171 fault tolerance or load sharing, for example. 173 Each server pool is identified by a unique name which is simply a 174 byte string, called the pool handle. This allows binary names to be 175 used. 177 These names are not valid in the whole internet but only in smaller 178 domains, called the operational scope. Furthermore, the namespace is 179 assumed to be flat, so that multiple levels of query are not 180 necessary to resolve a name request. 182 The second class of entities in the RSerPool architecture is the 183 class of name servers (NSs). These name servers can resolve a pool 184 handle to a list of information which allows the PU to access a PE of 185 the server pool identified by the handle. This information includes: 187 o A list of IPv4 and/or IPv6 addresses. 189 o A protocol field specifying the transport layer protocol. 191 o A port number associated with the transport protocol, e.g. SCTP, 192 TCP or UDP. 194 Note that the RSerPool architecture supports both IPv4 and IPv6 195 addressing. 197 In each operational scope there must be at least one name server. All 198 name servers within the operational scope have knowledge of all 199 server pools within the operational scope. 201 A third class of entities in the architecture is the Pool User (PU) 202 class, consisting of the clients being served by the PEs of a server 203 pool. 205 2.2 RSerPool Protocol Overview 207 The RSerPool requested features can be obtained with the help of the 208 combination of two protocols: ENRP (Endpoint Name Resolution 209 Protocol) and ASAP (Aggregate Server Access Protocol). 211 2.2.1 Endpoint Name Resolution Protocol 213 The name servers use a protocol called Endpoint Name Resolution 214 Protocol (ENRP) for communication with each other to exchange 215 information and updates about the server pools. 217 ENRP is designed to provide a fully distributed fault-tolerant 218 real-time translation service that maps a name to a set of transport 219 addresses pointing to a specific group of networked communication 220 endpoints registered under that name. ENRP employs a client-server 221 model in which a name server will respond to the name translation 222 service requests from endpoint clients. 224 RFC3237 [8] also requires that the name servers should not resolve a 225 pool handle to a transport layer address of a PE which is not in 226 operation. Therefore each PE is supervised by one specific name 227 server, called the home NS of that PE. If it detects that the PE is 228 out of service all other name servers are informed by using ENRP. 230 2.2.2 Aggregate Server Access Protocol 232 The PU wanting service from the pool uses the Aggregate Server Access 233 Protocol (ASAP) to access members of the pool. Depending on the 234 level of support desired by the application, use of ASAP may be 235 limited to an initial query for an active PE, or ASAP may be used to 236 mediate all communication between the PU and PE, so that automatic 237 failover from a failed PE to an alternate PE can be supported. 239 ASAP uses a name-based addressing model which isolates a logical 240 communication endpoint from its IP address(es), thus effectively 241 eliminating the binding between the communication endpoint and its 242 physical IP address(es) which normally constitutes a single point of 243 failure. 245 In addition, ASAP provides some mechanisms to support loadsharing 246 between PEs within the same pool and to support the upper layer in 247 case of a failover between PEs becomes necessary. 249 ASAP is also used by a PE to join or leave a server pool. It 250 registers or deregisters itself by communicating with a name server, 251 which will normally the home NS. ASAP allows dynamic system 252 scalability, allowing the pool membership to change at any time. 254 2.2.3 PU <-> NS Communication 256 The PU <-> NS communication is used for performing name queries. The 257 PU sends a pool handle to the NS and gets back the information 258 necessary for accessing a server in a server pool. 260 This communication can be based on SCTP or TCP if the PU does not 261 support SCTP. The protocol stack for an SCTP capable PU is given in 262 Figure 1. 264 ******** ******** 265 * PU * * NS * 266 ******** ******** 268 +------+ +------+ 269 | ASAP | | ASAP | 270 +------+ +------+ 271 | SCTP | | SCTP | 272 +------+ +------+ 273 | IP | | IP | 274 +------+ +------+ 276 Protocol stack between PU and NS 278 Figure 1 280 2.2.4 PE <-> NS Communication 282 The PE <-> NS communication is used for registration and 283 deregistration of the PE in one or more pools and for the supervision 284 of the PE by the home NS. This communication is based on SCTP, the 285 protocol stack is shown in the following figure. 287 ******** ******** 288 * PE * * NS * 289 ******** ******** 291 +------+ +------+ 292 | ASAP | | ASAP | 293 +------+ +------+ 294 | SCTP | | SCTP | 295 +------+ +------+ 296 | IP | | IP | 297 +------+ +------+ 298 Protocol stack between PE and NS 300 Figure 2 302 2.2.5 PU <-> PE Communication 304 The PU <-> PE communication can be divided into two parts: 306 o control channel 308 o data channel 309 The data channel is used for the transmission of the upper layer 310 data, the control channel is used to exchange RSerPool information. 312 There are two supported scenarios: 314 o Multiplexed data and control channel. Both channels are 315 transported over one transport connection. This can either be an 316 SCTP association, with data and control channel are separated by 317 the PPID, or an TCP connection, with data and control channel 318 being handled by a TCP mapping layer. 320 o Data channel and no control channel. There is no restriction on 321 the transport protocol in this case. Note that certain enhanced 322 failover services (e.g. business cards, state cookies, message 323 failover) are not available when this method is used. 325 For a given pool, all PUs and PEs should make the same choice for the 326 style of interaction between each other: that is, for a given pool, 327 either all PEs and PUs in that pool use a multiplexed control/data 328 channel for PU-PE communication, or all PEs and PUs in that pool use 329 a data channel only for PU-PE communication. 331 When the multiplexed data and control channel is used, enhanced 332 failover services may be provided, including: 334 o The PE can send a business card to the PU for providing 335 information to which other PE the PU should failover in case of a 336 failover. 338 o The PE can send cookies to the PU. The PE would store only the 339 last cookie and send it to the new PE in case of a failover. 341 See Section 2.3 for further details. 343 2.2.6 NS <-> NS Communication 345 The communication between name servers is used to share the knowledge 346 about all server pools between all name servers in an operational 347 scope. 349 For this communication ENRP over SCTP is used and the protocol stack 350 is shown in Figure 3. 352 ******** ******** 353 * NS * * NS * 354 ******** ******** 356 +------+ +------+ 357 | ENRP | | ENRP | 358 +------+ +------+ 359 | SCTP | | SCTP | 360 +------+ +------+ 361 | IP | | IP | 362 +------+ +------+ 363 Protocol stack between NS and NS 365 Figure 3 367 When a name initializes a UDP multicast message may be transmitted 368 for initial detection of other name servers in the operational scope. 369 The other name servers send a response using a unicast UDP message. 371 2.2.7 PE <-> PE Communication 373 This is a special case of the PU <-> PE communication. In this case 374 the PU is also a PE in a server pool. 376 There is one additional point here: The PE acting as a PU can send 377 the PE the information that it is actually a PE of a pool. This means 378 that the pool handle is transferred via the control channel. See 379 Section 2.3 for further details. 381 2.3 Failover Support 383 If the PU detects the failure of a PE it may fail over to a different 384 PE. The selection to a new PE should be made such that most likely 385 the new PE is not affected by the failed one. 387 There are some mechanisms provided by RSerPool to support the 388 failover to a new PE. 390 2.3.1 Business Cards 392 A PE can send a business card to its peer containing its pool handle 393 and optionally information to which other PEs the peer should 394 failover. 396 Presenting the pool handle is important in case of PE <-> PE 397 communication in which one of the PEs acts as a PU for establishing 398 the communication. The pool handle of the PE which initiated the 399 communication may not be known by the peer. 401 Providing information to which PE the PU should failover can also be 402 very important. Consider the scenario presented in the following 403 figure. 405 ....................... 406 . +-------+ . 407 . | | . 408 . | PE 1 | . 409 . | | . 410 . +-------+ . 411 . . 412 . Server Pool . 413 . . 414 . . 415 +-------+ . +-------+ . +-------+ 416 | | . | | . | | 417 | PU 1 |------.------| PE 2 |------.-------| PU 2 | 418 | | . | | . | | 419 +-------+ . +-------+ . +-------+ 420 . . 421 . . 422 . . 423 . . 424 . +-------+ . 425 . | | . 426 . | PE 3 | . 427 . | | . 428 . +-------+ . 429 ....................... 430 Two PUs accessing the same PE 432 Figure 4 434 PU 1 is using PE 2 of the server pool. Assume that PE 1 and PE 2 435 share state but not PE 2 and PE 3. Using the business card of PE 2 it 436 is possible for PE 2 to inform PU 1 that it should fail over to PE 1 437 in case of a failure. 439 A slightly more complicated situation is if two pool users, PU 1 and 440 PU 2, use PE 2 but both, PU 1 and PU 2, need to use the same PE. Then 441 it is important that PU 1 and PU 2 fail over to the same PE. This can 442 be handled in a way such that PE 2 gives the same business card to PU 443 1 and PU 2. 445 2.3.2 Cookies 447 Cookies may optionally be sent from the PE to the PU. The PU only 448 stores the last received cookie. In case of fail over the PU sends 449 this last received cookie to the new PE. This method provides a 450 simple way of state sharing between the PEs. Please note that the old 451 PE should sign the cookie and the receiving PE should verify the 452 signature. For the PU, the cookie has no structure and is only stored 453 and transmitted to the new PE. 455 2.4 Typical Interactions between RSerPool Components 457 The following drawing shows the typical RSerPool components and their 458 possible interactions with each other: 460 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 461 ~ operation scope ~ 462 ~ ......................... ......................... ~ 463 ~ . Server Pool 1 . . Server Pool 2 . ~ 464 ~ . +-------+ +-------+ . (d) . +-------+ +-------+ . ~ 465 ~ . |PE(1,A)| |PE(1,C)|<-------------->|PE(2,B)| |PE(2,A)|<---+ ~ 466 ~ . +-------+ +-------+ . . +-------+ +-------+ . | ~ 467 ~ . ^ ^ . . ^ ^ . | ~ 468 ~ . | (a) | . . | | . | ~ 469 ~ . +----------+ | . . | | . | ~ 470 ~ . +-------+ | | . . | | . | ~ 471 ~ . |PE(1,B)|<---+ | | . . | | . | ~ 472 ~ . +-------+ | | | . . | | . | ~ 473 ~ . ^ | | | . . | | . | ~ 474 ~ .......|........|.|.|.... .......|.........|....... | ~ 475 ~ | | | | | | | ~ 476 ~ (c)| (a)| | |(a) (a)| (a)| (c)| ~ 477 ~ | | | | | | | ~ 478 ~ | v v v v v | ~ 479 ~ | +++++++++++++++ (e) +++++++++++++++ | ~ 480 ~ | + NS +<---------->+ NS + | ~ 481 ~ | +++++++++++++++ +++++++++++++++ | ~ 482 ~ v ^ ^ | ~ 483 ~ ********* | | | ~ 484 ~ * PU(A) *<-------+ (b)| | ~ 485 ~ ********* (b) | | ~ 486 ~ v | ~ 487 ~ ::::::::::::::::: (f) ***************** | ~ 488 ~ : Other Clients :<------------->* Proxy/Gateway * <---+ ~ 489 ~ ::::::::::::::::: ***************** ~ 490 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 491 RSerPool components and their possible interactions. 493 Figure 5 495 In this figure we can identify the following possible interactions: 497 (a) Server Pool Elements <-> NS: (ASAP) Each PE in a pool uses ASAP 498 to register or de-register itself as well as to exchange other 499 auxiliary information with the NS. The NS also uses ASAP to 500 monitor the operational status of each PE in a pool. 502 (b) PU <-> NS: (ASAP) A PU normally uses ASAP to request the NS for a 503 name-to-address translation service before the PU can send user 504 messages addressed to a server pool by the pool's name. 506 (c) PU <-> PE: (ASAP) ASAP can be used to exchange some auxiliary 507 information of the two parties before they engage in user data 508 transfer. 510 (d) Server Pool <-> Server Pool: (ASAP) A PE in a server pool can 511 become a PU to another pool when the PE tries to initiate 512 communication with the other pool. In such a case, the 513 interactions described in (a) and (c) above will apply. 515 (e) NS <-> NS: (ENRP) ENRP can be used to fulfill various Name Space 516 operation, administration, and maintenance (OAM) functions. 518 (f) Other Clients <-> Proxy/Gateway: standard protocols The proxy/ 519 gateway enables clients ("other clients"), which are not RSerPool 520 aware, to access services provided by an RSerPool based server 521 pool. It should be noted that these proxies/gateways may become a 522 single point of failure. 524 3. Examples 526 In this section the basic concepts of ENRP and ASAP will be 527 described. First an RSerPool aware FTP server is considered. The 528 interaction with an RSerPool aware and an non-aware client is given. 529 Finally, a telephony example is considered. 531 3.1 Two File Transfer Examples 533 In this section we present two separate file transfer examples using 534 ENRP and ASAP. We present two separate examples demonstrating an 535 ENRP/ASAP aware client and a client that is using a Proxy or Gateway 536 to perform the file transfer. In this example we will use a FTP 537 RFC959 [4] model with some modifications. The first example (the 538 RSerPool aware one) will modify FTP concepts so that the file 539 transfer takes place over SCTP. In the second example we will use TCP 540 between the unaware client and the Proxy. The Proxy itself will use 541 the modified FTP with RSerPool as illustrated in the first example. 543 Please note that in the example we do NOT follow FTP RFC959 [4] 544 precisely but use FTP-like concepts and attempt to adhere to the 545 basic FTP model. These examples use FTP for illustrative purposes, 546 FTP was chosen since many of the basic concept are well known and 547 should be familiar to readers. 549 3.1.1 The RSerPool Aware Client 551 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 552 ~ operation scope ~ 553 ~ ......................... ~ 554 ~ . "File Transfer Pool" . ~ 555 ~ . +-------+ +-------+ . ~ 556 ~ +-> |PE(1,A)| |PE(1,C)| . ~ 557 ~ |. +-------+ +-------+ . ~ 558 ~ |. ^ ^ . ~ 559 ~ |. +----------+ | . ~ 560 ~ |. +-------+ | | . ~ 561 ~ |. |PE(1,B)|<---+ | | . ~ 562 ~ |. +-------+ | | | . ~ 563 ~ |. ^ | | | . ~ 564 ~ |.......|........|.|.|.... ~ 565 ~ | ASAP | ASAP| | |ASAP ~ 566 ~ |(d) |(c) | | | ~ 567 ~ | v v v v ~ 568 ~ | ********* +++++++++++++++ ~ 569 ~ + ->* PU(X) * + NS + ~ 570 ~ ********* +++++++++++++++ ~ 571 ~ ^ ASAP ^ ~ 572 ~ | <-(b) | ~ 573 ~ +--------------+ ~ 574 ~ (a)-> ~ 575 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 577 Architecture for RSerPool aware client. 579 Figure 6 581 To effect a file transfer the following steps would take place. 583 1. The application in PU(X) would send a login request. The PU(X)'s 584 ASAP layer would send an ASAP request to its NS to request the 585 list of pool elements (using (a)). The pool handle to identify 586 the pool would be "File Transfer Pool". The ASAP layer queues the 587 login request. 589 2. The NS would return a list of the three PEs PE(1,A), PE(1,B) and 590 PE(1,C) to the ASAP layer in PU(X) (using (b)). 592 3. The ASAP layer selects one of the PEs, for example PE(1,B). It 593 transmits the login request, the other FTP control data finally 594 starts the transmission of the requested files (using (c)). For 595 this the multiple stream feature of SCTP could be used. 597 4. If during the file transfer conversation, PE(1,B) fails, assuming 598 the PE's were sharing state of file transfer, a fail-over to 599 PE(1,A) could be initiated. PE(1,A) would continue the transfer 600 until complete (see (d)). In parallel a request from PE(1,A) 601 would be made to ENRP to request a cache update for the server 602 pool "File Transfer Pool" and a report would also be made that 603 PE(1,B) is non-responsive (this would cause appropriate audits 604 that may remove PE(1,B) from the pool if the NS had not already 605 detected the failure) (using (a)). 607 3.1.2 The RSerPool Unaware Client 609 In this example we investigate the use of a Proxy server assuming the 610 same set of scenario as illustrated above. 612 In this example the steps will occur: 614 1. The FTP client and the Proxy/Gateway are using the TCP-based ftp 615 protocol. The client sends the login request to the proxy (using 616 (e)). 618 2. The proxy behaves like a client and performs the actions 619 described under (1), (2) and (3) of the above description (using 620 (a), (b) and (c)). 622 3. The ftp communication continues and will be translated by the 623 proxy into the RSerPool aware dialect. This interworking uses (f) 624 and (c). 626 Note that in this example high availability is maintained between the 627 Proxy and the server pool but a single point of failure exists 628 between the FTP client and the Proxy, i.e. the command TCP connection 629 and its one IP address it is using for commands. 631 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 632 ~ operation scope ~ 633 ~ ......................... ~ 634 ~ . "File Transfer Pool" . ~ 635 ~ . +-------+ +-------+ . ~ 636 ~ . |PE(1,A)| |PE(1,C)| . ~ 637 ~ . +-------+ +-------+ . ~ 638 ~ . ^ ^ . ~ 639 ~ . +----------+ | . ~ 640 ~ . +-------+ | | . ~ 641 ~ . |PE(1,B)|<---+ | | . ~ 642 ~ . +-------+ | | | . ~ 643 ~ .......^........|.|.|.... ~ 644 ~ | | | | ~ 645 ~ | ASAP| | |ASAP ~ 646 ~ | | | | ~ 647 ~ | v v v ~ 648 ~ | +++++++++++++++ +++++++++++++++ ~ 649 ~ | + NS +<--ENRP-->+ NS + ~ 650 ~ | +++++++++++++++ +++++++++++++++ ~ 651 ~ | ASAP ^ ~ 652 ~ | ASAP (c) (b) | ^ ~ 653 ~ +---------------------------------+ | | | ~ 654 ~ | v | (a) ~ 655 ~ v v ~ 656 ~ ::::::::::::::::: (e)-> ***************** ~ 657 ~ : FTP Client :<------------->* Proxy/Gateway * ~ 658 ~ ::::::::::::::::: (f) ***************** ~ 659 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 660 Architecture for RserPool unaware client. 662 Figure 7 664 3.2 Telephony Signaling Example 666 This example shows the use of ASAP/RSerPool to support server pooling 667 for high availability of a telephony application such as a Voice over 668 IP Gateway Controller (GWC) and Gatekeeper services (GK). 670 In this example, we show two different scenarios of deploying these 671 services using RSerPool in order to illustrate the flexibility of the 672 RSerPool architecture. 674 3.2.1 Decomposed GWC and GK Scenario 676 In this scenario, both GWC and GK services are deployed as separate 677 pools with some number of PEs, as shown in the following diagram. 679 Each of the pools will register their unique pool handle (i.e. name) 680 with the NS. We also assume that there are a Signaling Gateway (SG) 681 and a Media Gateway (MG) present and both are RSerPool aware. 683 ................... 684 . Gateway . 685 . Controller Pool . 686 ................. . +-------+ . 687 . Gatekeeper . . |PE(2,A)| . 688 . Pool . . +-------+ . 689 . +-------+ . . +-------+ . 690 . |PE(1,A)| . . |PE(2,B)| . 691 . +-------+ . . +-------+ . 692 . +-------+ . (d) . +-------+ . 693 . |PE(1,B)|<------------>|PE(2,C)|<-------------+ 694 . +-------+ . . +-------+ . | 695 ................. ........^.......... | 696 | | 697 (c)| (e)| 698 | v 699 +++++++++++++++ ********* ***************** 700 + NS + * SG(X) * * Media Gateway * 701 +++++++++++++++ ********* ***************** 702 ^ ^ 703 | | 704 | <-(a) | 705 +-------------------+ 706 (b)-> 708 Deployment of Decomposed GWC and GK. 710 Figure 8 712 As shown in the previous figure, the following sequence takes place: 714 1. the Signaling Gateway (SG) receives an incoming signaling message 715 to be forwarded to the GWC. SG(X)'s ASAP layer would send an ASAP 716 request to its "local" NS to request the list of pool elements 717 (PE's) of GWC (using (a)). The key used for this query is the 718 pool handle of the GWC. The ASAP layer queues the data to be sent 719 to the GWC in local buffers until the NS responds. 721 2. the NS would return a list of the three PE's A, B and C to the 722 ASAP layer in SG(X) together with information to be used for 723 load-sharing traffic across the gateway controller pool (using 724 (b)). 726 3. the ASAP layer in SG(X) will select one PE (e.g., PE(2,C)) and 727 send the signaling message to it (using (c)). The selection is 728 based on the load sharing information of the gateway controller 729 pool. 731 4. to progress the call, PE(2,C) finds that it needs to talk to the 732 Gatekeeper. Assuming it has already had gatekeeper pool's 733 information in its local cache (e.g., obtained and stored from 734 recent query to NS), PE(2,C) selects PE(1,B) and sends the call 735 control message to it (using (d)). 737 5. We assume PE(1,B) responds back to PE(2,C) and authorizes the 738 call to proceed. 740 6. PE(2,C) issues media control commands to the Media Gateway (using 741 (e)). 743 RSerPool will provide service robustness to the system if some 744 failure would occur in the system. 746 For instance, if PE(1, B) in the Gatekeeper Pool crashed after 747 receiving the call control message from PE(2, C) in step (d) above, 748 what most likely will happen is that, due to the absence of a reply 749 from the Gatekeeper, a timer expiration event will trigger the call 750 state machine within PE(2, C) to resend the control message. The ASAP 751 layer at PE(2, C) will then notice the failure of PE(1, B) through 752 (likely) the endpoint unreachability detection by the transport 753 protocol beneath ASAP and automatically deliver the re-sent call 754 control message to the alternate GK pool member PE(1, A). With 755 appropriate intra-pool call state sharing support, PE(1, A) will be 756 able to correctly handle the call and reply to PE(2, C) and hence 757 progress the call. 759 3.2.2 Collocated GWC and GK Scenario 761 In this scenario, the GWC and GK services are collocated (e.g., they 762 are implemented as a single process). In such a case, one can form a 763 pool that provides both GWC and GK services as shown in the figure 764 below. 766 The same sequence as described in 5.2.1 takes place, except that step 767 (4) now becomes internal to the PE(3,C) (again, we assume Server C is 768 selected by SG). 770 ........................................ 771 . Gateway Controller/Gatekeeper Pool . 772 . +-------+ . 773 . |PE(3,A)| . 774 . +-------+ . 775 . +-------+ . 776 . |PE(3,C)|<---------------------------+ 777 . +-------+ . | 778 . +-------+ ^ . | 779 . |PE(3,B)| | . | 780 . +-------+ | . | 781 ................|....................... | 782 | | 783 +-------------+ | 784 | | 785 (c)| (e)| 786 v v 787 +++++++++++++++ ********* ***************** 788 + NS + * SG(X) * * Media Gateway * 789 +++++++++++++++ ********* ***************** 790 ^ ^ 791 | | 792 | <-(a) | 793 +-------------------+ 794 (b)-> 796 Deployment of Collocated GWC and GK. 798 Figure 9 800 4. Security Considerations 802 The RSerPool protocol must allow us to secure the RSerPool 803 infrastructure. There are security and privacy issues that relate to 804 the namespace, pool element registration and user queries of the 805 namespace. In [2] a complete threat analysis of RSerPool components 806 is presented. 808 5. 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 [2] Stillman, M., "Threats Introduced by Rserpool and Requirements 820 for Security in response to Threats", 821 draft-ietf-rserpool-threats-02 (work in progress), October 2003. 823 Informative References 825 [3] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 826 September 1981. 828 [4] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 829 959, October 1985. 831 [5] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service 832 Location Protocol, Version 2", RFC 2608, June 1999. 834 [6] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L., 835 Lin, H., Juhasz, I., Holdrege, M. and C. Sharp, "Framework 836 Architecture for Signaling Transport", RFC 2719, October 1999. 838 [7] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 839 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 840 "Stream Control Transmission Protocol", RFC 2960, October 2000. 842 [8] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, 843 J. and M. Stillman, "Requirements for Reliable Server Pooling", 844 RFC 3237, January 2002. 846 Authors' Addresses 848 Michael Tuexen (editor) 849 Univ. of Applied Sciences Muenster 850 Stegerwaldstr. 39 851 48565 Steinfurt 852 Germany 854 EMail: tuexen@fh-muenster.de 855 Qiaobing Xie 856 Motorola, Inc. 857 1501 W. Shure Drive, #2309 858 Arlington Heights, IL 60004 859 USA 861 Phone: +1-847-632-3028 862 EMail: qxie1@email.mot.com 864 Randall R. Stewart 865 Cisco Systems, Inc. 866 8725 West Higgins Road 867 Suite 300 868 Chicago, IL 60631 869 USA 871 Phone: +1-815-477-2127 872 EMail: rrs@cisco.com 874 Melinda Shore 875 Cisco Systems, Inc. 876 809 Hayts Rd 877 Ithaca, NY 14850 878 USA 880 Phone: +1 607 272 7512 881 EMail: mshore@cisco.com 883 John Loughney 884 Nokia Research Center 885 PO Box 407 886 FIN-00045 Nokia Group FIN-00045 887 Finland 889 EMail: john.loughney@nokia.com 891 Intellectual Property Statement 893 The IETF takes no position regarding the validity or scope of any 894 intellectual property or other rights that might be claimed to 895 pertain to the implementation or use of the technology described in 896 this document or the extent to which any license under such rights 897 might or might not be available; neither does it represent that it 898 has made any effort to identify any such rights. Information on the 899 IETF's procedures with respect to rights in standards-track and 900 standards-related documentation can be found in BCP-11. Copies of 901 claims of rights made available for publication and any assurances of 902 licenses to be made available, or the result of an attempt made to 903 obtain a general license or permission for the use of such 904 proprietary rights by implementors or users of this specification can 905 be obtained from the IETF Secretariat. 907 The IETF invites any interested party to bring to its attention any 908 copyrights, patents or patent applications, or other proprietary 909 rights which may cover technology that may be required to practice 910 this standard. Please address the information to the IETF Executive 911 Director. 913 Full Copyright Statement 915 Copyright (C) The Internet Society (2003). All Rights Reserved. 917 This document and translations of it may be copied and furnished to 918 others, and derivative works that comment on or otherwise explain it 919 or assist in its implementation may be prepared, copied, published 920 and distributed, in whole or in part, without restriction of any 921 kind, provided that the above copyright notice and this paragraph are 922 included on all such copies and derivative works. However, this 923 document itself may not be modified in any way, such as by removing 924 the copyright notice or references to the Internet Society or other 925 Internet organizations, except as needed for the purpose of 926 developing Internet standards in which case the procedures for 927 copyrights defined in the Internet Standards process must be 928 followed, or as required to translate it into languages other than 929 English. 931 The limited permissions granted above are perpetual and will not be 932 revoked by the Internet Society or its successors or assignees. 934 This document and the information contained herein is provided on an 935 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 936 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 937 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 938 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 939 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 941 Acknowledgment 943 Funding for the RFC Editor function is currently provided by the 944 Internet Society.