idnits 2.17.1 draft-ietf-rserpool-arch-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 25. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1033. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1010. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1017. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1023. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 534 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 (February 20, 2005) is 7002 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 914, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 926, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 932, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 935, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 939, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-rserpool-threats-04 ** Downref: Normative reference to an Informational draft: draft-ietf-rserpool-threats (ref. '2') == Outdated reference: A later version (-11) exists of draft-ietf-rserpool-comp-08 ** Downref: Normative reference to an Informational draft: draft-ietf-rserpool-comp (ref. '3') -- Obsolete informational reference (is this intentional?): RFC 793 (ref. '4') (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2960 (ref. '8') (Obsoleted by RFC 4960) Summary: 9 errors (**), 0 flaws (~~), 10 warnings (==), 9 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 Muenster Univ. of Applied Sciences 4 Expires: August 24, 2005 Q. Xie 5 Motorola, Inc. 6 R. Stewart 7 M. Shore 8 Cisco Systems, Inc. 9 J. Loughney 10 Nokia Research Center 11 A. Silverton 12 Motorola Labs 13 February 20, 2005 15 Architecture for Reliable Server Pooling 16 draft-ietf-rserpool-arch-09.txt 18 Status of this Memo 20 This document is an Internet-Draft and is subject to all provisions 21 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 22 author represents that any applicable patent or other IPR claims of 23 which he or she is aware have been or will be disclosed, and any of 24 which he or she become aware will be disclosed, in accordance with 25 RFC 3668. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as 30 Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on August 24, 2005. 45 Copyright Notice 47 Copyright (C) The Internet Society (2005). 49 Abstract 51 This document describes an architecture and protocols for the 52 management and operation of server pools supporting highly reliable 53 applications, and for client access mechanisms to a server pool. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.3 Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Reliable Server Pooling Architecture . . . . . . . . . . . . . 4 62 2.1 RSerPool Functional Components . . . . . . . . . . . . . . 4 63 2.1.1 Pool Elements . . . . . . . . . . . . . . . . . . . . 4 64 2.1.2 ENRP Servers . . . . . . . . . . . . . . . . . . . . . 5 65 2.1.3 Pool Users . . . . . . . . . . . . . . . . . . . . . . 5 66 2.2 RSerPool Protocol Overview . . . . . . . . . . . . . . . . 5 67 2.2.1 Endpoint Handlespace Redundancy Protocol . . . . . . . 6 68 2.2.2 Aggregate Server Access Protocol . . . . . . . . . . . 6 69 2.2.3 PU <-> ENRP Server Communication . . . . . . . . . . . 7 70 2.2.4 PE <-> ENRP Server Communication . . . . . . . . . . . 8 71 2.2.5 PU <-> PE Communication . . . . . . . . . . . . . . . 8 72 2.2.6 ENRP Server <-> ENRP Server Communication . . . . . . 9 73 2.2.7 PE <-> PE Communication . . . . . . . . . . . . . . . 10 74 2.3 Failover Support . . . . . . . . . . . . . . . . . . . . . 10 75 2.3.1 Business Cards . . . . . . . . . . . . . . . . . . . . 10 76 2.3.2 Cookies . . . . . . . . . . . . . . . . . . . . . . . 12 77 2.4 Typical Interactions between RSerPool Components . . . . . 12 78 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 3.1 Two File Transfer Examples . . . . . . . . . . . . . . . . 13 80 3.1.1 The RSerPool Aware Client . . . . . . . . . . . . . . 14 81 3.1.2 The RSerPool Unaware Client . . . . . . . . . . . . . 15 82 3.2 Load Balancing Example . . . . . . . . . . . . . . . . . . 16 83 3.3 Telephony Signaling Example . . . . . . . . . . . . . . . 17 84 3.3.1 Decomposed GWC and GK Scenario . . . . . . . . . . . . 18 85 3.3.2 Collocated GWC and GK Scenario . . . . . . . . . . . . 19 86 4. Security Considerations . . . . . . . . . . . . . . . . . . . 20 87 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 88 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 89 6.1 Normative References . . . . . . . . . . . . . . . . . . . 21 90 6.2 Informative References . . . . . . . . . . . . . . . . . . 21 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21 92 Intellectual Property and Copyright Statements . . . . . . . . 24 94 1. Introduction 96 1.1 Overview 98 This document defines an architecture, for providing a highly 99 available reliable server function in support of a service or set of 100 services. This is achieved by forming a pool of servers, each of 101 which is capable of supporting the desired service(s), and providing 102 a name service that will resolve requests from a service user to the 103 identity of a working server in the pool. 105 To access a server pool, the pool user consults an ENRP server. The 106 name service itself can be provided by a pool of ENRP servers using a 107 shared protocol to make the name resolution function fault-tolerant. 108 It is assumed that the handle space is kept flat and designed for a 109 limited scale in order to keep the protocols simple, robust and fast. 111 The server pool itself is supported by a shared protocol between 112 servers and the name service allowing servers to enter and exit the 113 pool. Several server selection mechanisms, called server pool 114 policies, are supported for flexibility. 116 1.2 Terminology 118 This document uses the following terms: 120 Home ENRP Server: The ENRP server a Pool Element has registered with. 121 This ENRP server supervises the Pool Element. 123 Operational scope: The part of the network visible to pool users by a 124 specific instance of the reliable server pooling protocols. 126 Pool (or server pool): A collection of servers providing the same 127 application functionality. 129 Pool handle: A logical pointer to a pool. Each server pool will be 130 identifiable in the operational scope of the system by a unique 131 pool handle. 133 Pool element: A server entity having registered to a pool. 135 Pool user: A server pool user. 137 Pool element handle (or endpoint handle): A logical pointer to a 138 particular pool element in a pool, consisting of the pool handle 139 and a destination transport address of the pool element. 141 Handle space: A cohesive structure of pool handles and relations that 142 may be queried by an internal or external agent. 144 ENRP server: Entity which is responsible for managing and maintaining 145 the handle space within the RSerPool operational scope. 147 1.3 Abbreviations 149 ASAP: Aggregate Server Access Protocol 151 ENRP: Endpoint haNdlespace Redundancy Protocol 153 PE: Pool element 155 PU: Pool user 157 SCTP: Stream Control Transmission Protocol 159 TCP: Transmission Control Protocol 161 2. Reliable Server Pooling Architecture 163 In this section, we define a reliable server pool architecture. 165 2.1 RSerPool Functional Components 167 There are three classes of entities in the RSerPool architecture: 169 o Pool Elements (PEs). 171 o ENRP Servers. 173 o Pool Users (PUs). 175 2.1.1 Pool Elements 177 A server pool is defined as a set of one or more servers providing 178 the same application functionality. These servers are called Pool 179 Elements (PEs). PEs form the first class of entities in the RSerPool 180 architecture. Multiple PEs in a server pool can be used to provide 181 fault tolerance or load sharing, for example. 183 Each server pool is identified by a unique identifier which is simply 184 a byte string, called the pool handle. This allows binary 185 identifiers to be used. 187 These pool handles are not valid in the whole internet but only in 188 smaller domains, called the operational scope. Furthermore, the 189 handle-space is assumed to be flat, so that multiple levels of query 190 are not necessary to resolve a pool handle. 192 2.1.2 ENRP Servers 194 The second class of entities in the RSerPool architecture is the 195 class of ENRP servers. ENRP servers are designed to provide a fully 196 distributed fault-tolerant real-time translation service that maps a 197 pool handle to set of transport addresses pointing to a specific 198 group of networked communication endpoints registered under that pool 199 handle. To be more precise, ENRP servers can resolve a pool handle 200 to a list of information which allows the PU to access a PE of the 201 server pool identified by the handle. This information includes: 203 o A list of IPv4 and/or IPv6 addresses. 205 o A protocol field specifying the transport layer protocol. 207 o A port number associated with the transport protocol, e.g. SCTP, 208 TCP or UDP. 210 Note that the RSerPool architecture supports both IPv4 and IPv6 211 addressing. 213 In each operational scope there must be at least one ENRP server. 214 All ENRP servers within the operational scope have knowledge of all 215 server pools within the operational scope. 217 RFC3237 [9] also requires that the ENRP servers should not resolve a 218 pool handle to a transport layer address of a PE which is not in 219 operation. Therefore each PE is supervised by one specific ENRP 220 server, called the home ENRP server of that PE. If it detects that 221 the PE is out of service all other ENRP servers are informed. 223 2.1.3 Pool Users 225 A third class of entities in the architecture is the Pool User (PU) 226 class, consisting of the clients being served by the PEs of a server 227 pool. 229 2.2 RSerPool Protocol Overview 231 Based on the requirements in RFC3237 [9], two new protocols: ENRP 232 (Endpoint haNdlespace Redundancy Protocol) and ASAP (Aggregate Server 233 Access Protocol). These are used because no existing protocols are 234 suitable (see [3]). 236 2.2.1 Endpoint Handlespace Redundancy Protocol 238 The ENRP servers use a protocol called Endpoint haNdlespace 239 Redundancy Protocol (ENRP) for communication with each other to 240 exchange information and updates about the server pools. 242 ENRP guarantees the integrity of the RSerPool handlespace by 243 providing the means for an ENRP server to 245 o update its peers regarding changes to the handlspace caused by the 246 addition of a PE or the status change of an existing PE, 248 o monitor the health of its peers, and, if necessary, take over the 249 responsibility of being the home ENRP server for a set of PEs when 250 the ENRP server previously responsbile for those PEs has failed, 251 and 253 o audit the handlespace for inconsistencies and synchronize the 254 handlespace amongst its peers when inconsistencies have been 255 found. 257 2.2.2 Aggregate Server Access Protocol 259 The PU wanting service from the pool uses the Aggregate Server Access 260 Protocol (ASAP) to access members of the pool. Depending on the 261 level of support desired by the application, use of ASAP may be 262 limited to an initial query for an active PE, or ASAP may be used to 263 mediate all communication between the PU and PE, so that automatic 264 failover from a failed PE to an alternate PE can be supported. 266 ASAP uses pool handles for addressing which isolates a logical 267 communication endpoint from its IP address(es), thus effectively 268 eliminating the binding between the communication endpoint and its 269 physical IP address(es) which normally constitutes a single point of 270 failure. 272 In addition, ASAP provides some mechanisms to support loadsharing 273 between PEs within the same pool and to support the upper layer in 274 case of a failover between PEs becomes necessary. 276 ASAP is also used by a PE to join or leave a server pool. It 277 registers or deregisters itself by communicating with a ENRP server, 278 which will normally the home ENRP server. ASAP allows dynamic system 279 scalability, allowing the pool membership to change at any time. 281 ASAP is used by a home ENRP server to supervise the PEs that have 282 registered with that ENRP server. If the home ENRP server detects 283 that a PE is out of service via ASAP, it notifies its peers using 284 ENRP as described previously. 286 2.2.3 PU <-> ENRP Server Communication 288 The PU <-> ENRP server communication is used for resolving pool 289 handles and uses ASAP. The PU sends a pool handle to the ENRP server 290 and gets back the information necessary for accessing a server in a 291 server pool. 293 This communication can be based on SCTP or TCP if the PU does not 294 support SCTP. The protocol stack for an SCTP capable PU is given in 295 Figure 1. 297 ******** ********** 298 * PU * * ENRP * 299 * * * server * 300 ******** ********** 302 +------+ +------+ 303 | ASAP | | ASAP | 304 +------+ +------+ 305 | SCTP | | SCTP | 306 +------+ +------+ 307 | IP | | IP | 308 +------+ +------+ 310 Protocol stack between PU and ENRP server 312 Figure 1 314 2.2.4 PE <-> ENRP Server Communication 316 The PE <-> ENRP server communication is used for registration and 317 deregistration of the PE in one or more pools and for the supervision 318 of the PE by the home ENRP server. This communication uses ASAP and 319 is based on SCTP, the protocol stack is shown in the following 320 figure. 322 ******** ********** 323 * PE * * ENRP * 324 * * * server * 325 ******** ********** 327 +------+ +------+ 328 | ASAP | | ASAP | 329 +------+ +------+ 330 | SCTP | | SCTP | 331 +------+ +------+ 332 | IP | | IP | 333 +------+ +------+ 334 Protocol stack between PE and ENRP server 336 Figure 2 338 2.2.5 PU <-> PE Communication 340 The PU <-> PE communication can be divided into two parts: 342 o control channel 343 o data channel 345 The data channel is used for the transmission of the upper layer 346 data, the control channel is used to exchange RSerPool information. 348 There are two supported scenarios: 350 o Multiplexed data and control channel. Both channels are 351 transported over one transport connection. This can either be an 352 SCTP association, with data and control channel are separated by 353 the PPID, or an TCP connection, with data and control channel 354 being handled by a TCP mapping layer. 356 o Data channel and no control channel. There is no restriction on 357 the transport protocol in this case. Note that certain enhanced 358 failover services (e.g. business cards, state cookies, message 359 failover) are not available when this method is used. 361 For a given pool, all PUs and PEs should make the same choice for the 362 style of interaction between each other: that is, for a given pool, 363 either all PEs and PUs in that pool use a multiplexed control/data 364 channel for PU-PE communication, or all PEs and PUs in that pool use 365 a data channel only for PU-PE communication. 367 When the multiplexed data and control channel is used, enhanced 368 failover services may be provided, including: 370 o The PE can send a business card to the PU for providing 371 information to which other PE the PU should failover in case of a 372 failover. 374 o The PE can send cookies to the PU. The PE would store only the 375 last cookie and send it to the new PE in case of a failover. 377 See Section 2.3 for further details. 379 2.2.6 ENRP Server <-> ENRP Server Communication 381 The communication between ENRP servers is used to share the knowledge 382 about all server pools between all ENRP servers in an operational 383 scope. 385 For this communication ENRP over SCTP is used and the protocol stack 386 is shown in Figure 3. 388 ********** ********** 389 * ENRP * * ENRP * 390 * server * * server * 391 ********** ********** 393 +------+ +------+ 394 | ENRP | | ENRP | 395 +------+ +------+ 396 | SCTP | | SCTP | 397 +------+ +------+ 398 | IP | | IP | 399 +------+ +------+ 400 Protocol stack between ENRP servers 402 Figure 3 404 When a ENRP server initializes a UDP multicast message may be 405 transmitted for initial detection of other ENRP servers in the 406 operational scope. The other ENRP servers send a response using a 407 unicast UDP message. 409 2.2.7 PE <-> PE Communication 411 This is a special case of the PU <-> PE communication. In this case 412 the PU is also a PE in a server pool, this means that one PE is 413 acting like a PU during the communication setup. 415 The difference between a pure PU <-> PE communication is that the PE 416 acting as a PU can send the PE the information that it is actually a 417 PE of a pool. This means that the pool handle is transferred via the 418 control channel. See Section 2.3 for further details. 420 2.3 Failover Support 422 If the PU detects the failure of a PE it may fail over to a different 423 PE. The selection to a new PE should be made such that most likely 424 the new PE is not affected by the failed one. 426 There are some mechanisms provided by RSerPool to support the 427 failover to a new PE. 429 2.3.1 Business Cards 431 A PE can send a business card to its peer containing its pool handle 432 and optionally information to which other PEs the peer should 433 failover. 435 Presenting the pool handle is important in case of PE <-> PE 436 communication in which one of the PEs acts as a PU for establishing 437 the communication. The pool handle of the PE which initiated the 438 communication may not be known by the peer. 440 Providing information to which PE the PU should failover can also be 441 very important. Consider the scenario presented in the following 442 figure. 444 ....................... 445 . +-------+ . 446 . | | . 447 . | PE 1 | . 448 . | | . 449 . +-------+ . 450 . . 451 . server pool . 452 . . 453 . . 454 +-------+ . +-------+ . +-------+ 455 | | . | | . | | 456 | PU 1 |------.------| PE 2 |------.-------| PU 2 | 457 | | . | | . | | 458 +-------+ . +-------+ . +-------+ 459 . . 460 . . 461 . . 462 . . 463 . +-------+ . 464 . | | . 465 . | PE 3 | . 466 . | | . 467 . +-------+ . 468 ....................... 469 Two PUs accessing the same PE 471 Figure 4 473 PU 1 is using PE 2 of the server pool. Assume that PE 1 and PE 2 474 share state but not PE 2 and PE 3. Using the business card of PE 2 475 it is possible for PE 2 to inform PU 1 that it should fail over to PE 476 1 in case of a failure. 478 A slightly more complicated situation is if two pool users, PU 1 and 479 PU 2, use PE 2 but both, PU 1 and PU 2, need to use the same PE. 480 Then it is important that PU 1 and PU 2 fail over to the same PE. 481 This can be handled in a way such that PE 2 gives the same business 482 card to PU 1 and PU 2. 484 2.3.2 Cookies 486 Cookies may optionally be sent from the PE to the PU. The PU only 487 stores the last received cookie. In case of fail over the PU sends 488 this last received cookie to the new PE. This method provides a 489 simple way of state sharing between the PEs. Please note that the 490 old PE should sign the cookie and the receiving PE should verify the 491 signature. For the PU, the cookie has no structure and is only 492 stored and transmitted to the new PE. 494 2.4 Typical Interactions between RSerPool Components 496 The following drawing shows the typical RSerPool components and their 497 possible interactions with each other: 499 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 500 ~ operational scope ~ 501 ~ ......................... ......................... ~ 502 ~ . server pool 1 . . server pool 2 . ~ 503 ~ . +-------+ +-------+ . (d) . +-------+ +-------+ . ~ 504 ~ . |PE(1,A)| |PE(1,C)|<-------------->|PE(2,B)| |PE(2,A)|<---+ ~ 505 ~ . +-------+ +-------+ . . +-------+ +-------+ . | ~ 506 ~ . ^ ^ . . ^ ^ . | ~ 507 ~ . | (a) | . . | | . | ~ 508 ~ . +----------+ | . . | | . | ~ 509 ~ . +-------+ | | . . | | . | ~ 510 ~ . |PE(1,B)|<---+ | | . . | | . | ~ 511 ~ . +-------+ | | | . . | | . | ~ 512 ~ . ^ | | | . . | | . | ~ 513 ~ .......|........|.|.|.... .......|.........|....... | ~ 514 ~ | | | | | | | ~ 515 ~ (c)| (a)| | |(a) (a)| (a)| (c)| ~ 516 ~ | | | | | | | ~ 517 ~ | v v v v v | ~ 518 ~ | +++++++++++++++ (e) +++++++++++++++ | ~ 519 ~ | + ENRP server +<---------->+ ENRP server + | ~ 520 ~ | +++++++++++++++ +++++++++++++++ | ~ 521 ~ v ^ ^ | ~ 522 ~ ********* | | | ~ 523 ~ * PU(A) *<-------+ (b)| | ~ 524 ~ ********* (b) | | ~ 525 ~ v | ~ 526 ~ ::::::::::::::::: (f) ***************** | ~ 527 ~ : other clients :<------------->* proxy/gateway * <---+ ~ 528 ~ ::::::::::::::::: ***************** ~ 529 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 530 RSerPool components and their possible interactions. 532 Figure 5 534 In this figure we can identify the following possible interactions: 536 (a) server pool elements <-> ENRP server: (ASAP) Each PE in a pool 537 uses ASAP to register or de-register itself as well as to exchange 538 other auxiliary information with the ENRP server. The ENRP server 539 also uses ASAP to monitor the operational status of each PE in a 540 pool. 542 (b) PU <-> ENRP server: (ASAP) A PU normally uses ASAP to request the 543 ENRP server for a pool handle to address translation service 544 before the PU can send user messages addressed to a server pool by 545 the pool's handle. 547 (c) PU <-> PE: (ASAP) ASAP can be used to exchange some auxiliary 548 information of the two parties before they engage in user data 549 transfer. 551 (d) server pool <-> server pool: (ASAP) A PE in a server pool can 552 become a PU to another pool when the PE tries to initiate 553 communication with the other pool. In such a case, the 554 interactions described in (a) and (c) above will apply. 556 (e) ENRP server <-> ENRP server: (ENRP) ENRP can be used to fulfill 557 various handle space operation, administration, and maintenance 558 (OAM) functions. 560 (f) Other Clients <-> Proxy/Gateway: standard protocols The 561 proxy/gateway enables clients ("other clients"), which are not 562 RSerPool aware, to access services provided by an RSerPool based 563 server pool. It should be noted that these proxies/gateways may 564 become a single point of failure. 566 3. Examples 568 In this section the basic concepts of ENRP and ASAP will be 569 described. First an RSerPool aware FTP server is considered. The 570 interaction with an RSerPool aware and an non-aware client is given. 571 Finally, a telephony example is considered. 573 3.1 Two File Transfer Examples 575 In this section we present two separate file transfer examples using 576 ENRP and ASAP. We present two separate examples demonstrating an 577 RSerPool-aware client and a client that is using a Proxy or Gateway 578 to perform the file transfer. In this example we will use a FTP 579 RFC959 [5] model with some modifications. The first example (the 580 RSerPool aware one) will modify FTP concepts so that the file 581 transfer takes place over SCTP. In the second example we will use 582 TCP between the unaware client and the Proxy. The Proxy itself will 583 use the modified FTP with RSerPool as illustrated in the first 584 example. 586 Please note that in the example we do NOT follow FTP RFC959 [5] 587 precisely but use FTP-like concepts and attempt to adhere to the 588 basic FTP model. These examples use FTP for illustrative purposes, 589 FTP was chosen since many of the basic concept are well known and 590 should be familiar to readers. 592 3.1.1 The RSerPool Aware Client 594 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 595 ~ operational scope ~ 596 ~ ......................... ~ 597 ~ . "file transfer pool" . ~ 598 ~ . +-------+ +-------+ . ~ 599 ~ +-> |PE(1,A)| |PE(1,C)| . ~ 600 ~ |. +-------+ +-------+ . ~ 601 ~ |. ^ ^ . ~ 602 ~ |. +----------+ | . ~ 603 ~ |. +-------+ | | . ~ 604 ~ |. |PE(1,B)|<---+ | | . ~ 605 ~ |. +-------+ | | | . ~ 606 ~ |. ^ | | | . ~ 607 ~ |.......|........|.|.|.... ~ 608 ~ | ASAP | ASAP| | |ASAP ~ 609 ~ |(d) |(c) | | | ~ 610 ~ | v v v v ~ 611 ~ | ********* +++++++++++++++ ~ 612 ~ + ->* PU(X) * + ENRP server + ~ 613 ~ ********* +++++++++++++++ ~ 614 ~ ^ ASAP ^ ~ 615 ~ | <-(b) | ~ 616 ~ +--------------+ ~ 617 ~ (a)-> ~ 618 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 620 Architecture for RSerPool aware client. 622 Figure 6 624 To effect a file transfer the following steps would take place. 626 1. The application in PU(X) would send a login request. The PU(X)'s 627 ASAP layer would send an ASAP request to its ENRP server to 628 request the list of pool elements (using (a)). The pool handle 629 to identify the pool would be "File Transfer Pool". The ASAP 630 layer queues the login request. 632 2. The ENRP server would return a list of the three PEs PE(1,A), 633 PE(1,B) and PE(1,C) to the ASAP layer in PU(X) (using (b)). 635 3. The ASAP layer selects one of the PEs, for example PE(1,B). It 636 transmits the login request, the other FTP control data finally 637 starts the transmission of the requested files (using (c)). For 638 this the multiple stream feature of SCTP could be used. 640 4. If during the file transfer conversation, PE(1,B) fails, assuming 641 the PE's were sharing state of file transfer, a fail-over to 642 PE(1,A) could be initiated. PE(1,A) would continue the transfer 643 until complete (see (d)). In parallel a request from PE(1,A) 644 would be made to the ENRP server to request a cache update for 645 the server pool "File Transfer Pool" and a report would also be 646 made that PE(1,B) is non-responsive (this would cause appropriate 647 audits that may remove PE(1,B) from the pool if the ENRP server 648 had not already detected the failure) (using (a)). 650 3.1.2 The RSerPool Unaware Client 652 In this example we investigate the use of a Proxy server assuming the 653 same set of scenario as illustrated above. 655 In this example the steps will occur: 657 1. The FTP client and the Proxy/Gateway are using the TCP-based ftp 658 protocol. The client sends the login request to the proxy (using 659 (e)). 661 2. The proxy behaves like a client and performs the actions 662 described under (1), (2) and (3) of the above description (using 663 (a), (b) and (c)). 665 3. The ftp communication continues and will be translated by the 666 proxy into the RSerPool aware dialect. This interworking uses 667 (f) and (c). 669 Note that in this example high availability is maintained between the 670 Proxy and the server pool but a single point of failure exists 671 between the FTP client and the Proxy, i.e. the command TCP 672 connection and its one IP address it is using for commands. 674 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 675 ~ operational scope ~ 676 ~ ......................... ~ 677 ~ . "file transfer pool" . ~ 678 ~ . +-------+ +-------+ . ~ 679 ~ . |PE(1,A)| |PE(1,C)| . ~ 680 ~ . +-------+ +-------+ . ~ 681 ~ . ^ ^ . ~ 682 ~ . +----------+ | . ~ 683 ~ . +-------+ | | . ~ 684 ~ . |PE(1,B)|<---+ | | . ~ 685 ~ . +-------+ | | | . ~ 686 ~ .......^........|.|.|.... ~ 687 ~ | | | | ~ 688 ~ | ASAP| | |ASAP ~ 689 ~ | | | | ~ 690 ~ | v v v ~ 691 ~ | +++++++++++++++ +++++++++++++++ ~ 692 ~ | + ENRP server +<--ENRP-->+ ENRP server + ~ 693 ~ | +++++++++++++++ +++++++++++++++ ~ 694 ~ | ASAP ^ ~ 695 ~ | ASAP (c) (b) | ^ ~ 696 ~ +---------------------------------+ | | | ~ 697 ~ | v | (a) ~ 698 ~ v v ~ 699 ~ ::::::::::::::::: (e)-> ***************** ~ 700 ~ : FTP client :<------------->* proxy/gateway * ~ 701 ~ ::::::::::::::::: (f) ***************** ~ 702 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 703 Architecture for RSerPool unaware client. 705 Figure 7 707 3.2 Load Balancing Example 709 This examples is similar to the one above describing an RSerPool 710 unaware client. In both examples the clients do not need to support 711 the RSerPool protocol suite. 713 There are several servers in a pool and the traffic from clients is 714 distributed among them by a load balancer. The load balancer can 715 make use of load information of the servers for optimal load 716 distribution. 718 One possibility of using RSerPool for this application is described 719 in the next figure. The servers become pool elements in one pool and 720 register themselves at ENRP servers. They can also provide load 721 information. The load balancer acts as a pool user and gets the 722 addresses and possibly the load information via ASAP communication 723 with ENRP servers. The communication between the clients and servers 724 is not affected. 726 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 727 ~ operational scope ~ 728 ~ ......................... ~ 729 ~ . "server pool" . ~ 730 ~ . +-------+ +-------+ . ~ 731 ~ . |PE(1,A)| |PE(1,C)| . ~ 732 ~ . +-------+ +-------+ . ~ 733 ~ . ^ ^ . ~ 734 ~ . +----------+ | . ~ 735 ~ . +-------+ | | . ~ 736 ~ . |PE(1,B)|<---+ | | . ~ 737 ~ . +-------+ | | | . ~ 738 ~ .......^........|.|.|.... ~ 739 ~ | | | | ~ 740 ~ | ASAP| | |ASAP ~ 741 ~ | | | | ~ 742 ~ | v v v ~ 743 ~ | +++++++++++++++ +++++++++++++++ ~ 744 ~ | + ENRP server +<--ENRP-->+ ENRP server + ~ 745 ~ | +++++++++++++++ +++++++++++++++ ~ 746 ~ | ^ ~ 747 ~ | (c) | ~ 748 ~ +---------------------------------+ | ASAP ~ 749 ~ | | (a) ~ 750 ~ v v ~ 751 ~ ::::::::::::::::: (b) ********************** ~ 752 ~ : client :<----------->* load balancer (PU) * ~ 753 ~ ::::::::::::::::: ********************** ~ 754 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 755 Architecture for an RSerPool based load balancer. 757 Figure 8 759 3.3 Telephony Signaling Example 761 This example shows the use of ASAP/RSerPool to support server pooling 762 for high availability of a telephony application such as a Voice over 763 IP Gateway Controller (GWC) and Gatekeeper services (GK). 765 In this example, we show two different scenarios of deploying these 766 services using RSerPool in order to illustrate the flexibility of the 767 RSerPool architecture. 769 3.3.1 Decomposed GWC and GK Scenario 771 In this scenario, both GWC and GK services are deployed as separate 772 pools with some number of PEs, as shown in the following diagram. 773 Each of the pools will register their unique pool handle with the 774 ENRP server. We also assume that there are a Signaling Gateway (SG) 775 and a Media Gateway (MG) present and both are RSerPool aware. 777 ................... 778 . gateway . 779 . controller pool . 780 ................. . +-------+ . 781 . gatekeeper . . |PE(2,A)| . 782 . pool . . +-------+ . 783 . +-------+ . . +-------+ . 784 . |PE(1,A)| . . |PE(2,B)| . 785 . +-------+ . . +-------+ . 786 . +-------+ . (d) . +-------+ . 787 . |PE(1,B)|<------------>|PE(2,C)|<-------------+ 788 . +-------+ . . +-------+ . | 789 ................. ........^.......... | 790 | | 791 (c)| (e)| 792 | v 793 +++++++++++++++ ********* ***************** 794 + ENRP server + * SG(X) * * media gateway * 795 +++++++++++++++ ********* ***************** 796 ^ ^ 797 | | 798 | <-(a) | 799 +-------------------+ 800 (b)-> 802 Deployment of Decomposed GWC and GK. 804 Figure 9 806 As shown in the previous figure, the following sequence takes place: 808 1. the Signaling Gateway (SG) receives an incoming signaling message 809 to be forwarded to the GWC. SG(X)'s ASAP layer would send an 810 ASAP request to its "local" ENRP server to request the list of 811 pool elements (PE's) of GWC (using (a)). The key used for this 812 query is the pool handle of the GWC. The ASAP layer queues the 813 data to be sent to the GWC in local buffers until the ENRP server 814 responds. 816 2. the ENRP server would return a list of the three PE's A, B and C 817 to the ASAP layer in SG(X) together with information to be used 818 for load-sharing traffic across the gateway controller pool 819 (using (b)). 821 3. the ASAP layer in SG(X) will select one PE (e.g., PE(2,C)) and 822 send the signaling message to it (using (c)). The selection is 823 based on the load sharing information of the gateway controller 824 pool. 826 4. to progress the call, PE(2,C) finds that it needs to talk to the 827 Gatekeeper. Assuming it has already had gatekeeper pool's 828 information in its local cache (e.g., obtained and stored from 829 recent query to ENRP server), PE(2,C) selects PE(1,B) and sends 830 the call control message to it (using (d)). 832 5. We assume PE(1,B) responds back to PE(2,C) and authorizes the 833 call to proceed. 835 6. PE(2,C) issues media control commands to the Media Gateway (using 836 (e)). 838 RSerPool will provide service robustness to the system if some 839 failure would occur in the system. 841 For instance, if PE(1, B) in the Gatekeeper Pool crashed after 842 receiving the call control message from PE(2, C) in step (d) above, 843 what most likely will happen is that, due to the absence of a reply 844 from the Gatekeeper, a timer expiration event will trigger the call 845 state machine within PE(2, C) to resend the control message. The 846 ASAP layer at PE(2, C) will then notice the failure of PE(1, B) 847 through (likely) the endpoint unreachability detection by the 848 transport protocol beneath ASAP and automatically deliver the re-sent 849 call control message to the alternate GK pool member PE(1, A). With 850 appropriate intra-pool call state sharing support, PE(1, A) will be 851 able to correctly handle the call and reply to PE(2, C) and hence 852 progress the call. 854 3.3.2 Collocated GWC and GK Scenario 856 In this scenario, the GWC and GK services are collocated (e.g., they 857 are implemented as a single process). In such a case, one can form a 858 pool that provides both GWC and GK services as shown in the figure 859 below. 861 The same sequence as described in 5.2.1 takes place, except that step 862 (4) now becomes internal to the PE(3,C) (again, we assume server C is 863 selected by SG). 865 ........................................ 866 . gateway controller/gatekeeper pool . 867 . +-------+ . 868 . |PE(3,A)| . 869 . +-------+ . 870 . +-------+ . 871 . |PE(3,C)|<---------------------------+ 872 . +-------+ . | 873 . +-------+ ^ . | 874 . |PE(3,B)| | . | 875 . +-------+ | . | 876 ................|....................... | 877 | | 878 +-------------+ | 879 | | 880 (c)| (e)| 881 v v 882 +++++++++++++++ ********* ***************** 883 + ENRP server + * SG(X) * * media gateway * 884 +++++++++++++++ ********* ***************** 885 ^ ^ 886 | | 887 | <-(a) | 888 +-------------------+ 889 (b)-> 891 Deployment of Collocated GWC and GK. 893 Figure 10 895 4. Security Considerations 897 The RSerPool protocol must allow us to secure the RSerPool 898 infrastructure. There are security and privacy issues that relate to 899 the handle space, pool element registration and user queries of the 900 handle space. In [2] a complete threat analysis of RSerPool 901 components is presented. 903 5. Acknowledgements 905 The authors would like to thank Bernard Aboba, Phillip Conrad, Harrie 906 Hazewinkel, Matt Holdrege, Lyndon Ong, Christopher Ross, Maureen 907 Stillman, Werner Vogels and many others for their invaluable comments 908 and suggestions. 910 6. References 912 6.1 Normative References 914 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 915 BCP 9, RFC 2026, October 1996. 917 [2] Stillman, M., "Threats Introduced by Rserpool and Requirements 918 for Security in response to Threats", 919 Internet-Draft draft-ietf-rserpool-threats-04, January 2005. 921 [3] Loughney, J., "Comparison of Protocols for Reliable Server 922 Pooling", Internet-Draft draft-ietf-rserpool-comp-08, July 2004. 924 6.2 Informative References 926 [4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 927 September 1981. 929 [5] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, 930 RFC 959, October 1985. 932 [6] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service 933 Location Protocol, Version 2", RFC 2608, June 1999. 935 [7] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L., 936 Lin, H., Juhasz, I., Holdrege, M. and C. Sharp, "Framework 937 Architecture for Signaling Transport", RFC 2719, October 1999. 939 [8] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 940 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 941 "Stream Control Transmission Protocol", RFC 2960, October 2000. 943 [9] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, 944 J. and M. Stillman, "Requirements for Reliable Server Pooling", 945 RFC 3237, January 2002. 947 Authors' Addresses 949 Michael Tuexen (editor) 950 Muenster Univ. of Applied Sciences 951 Stegerwaldstr. 39 952 48565 Steinfurt 953 Germany 955 Email: tuexen@fh-muenster.de 956 Qiaobing Xie 957 Motorola, Inc. 958 1501 W. Shure Drive, #2309 959 Arlington Heights, IL 60004 960 USA 962 Phone: +1-847-632-3028 963 Email: qxie1@email.mot.com 965 Randall R. Stewart 966 Cisco Systems, Inc. 967 8725 West Higgins Road 968 Suite 300 969 Chicago, IL 60631 970 USA 972 Phone: +1-815-477-2127 973 Email: rrs@cisco.com 975 Melinda Shore 976 Cisco Systems, Inc. 977 809 Hayts Rd 978 Ithaca, NY 14850 979 USA 981 Phone: +1 607 272 7512 982 Email: mshore@cisco.com 984 John Loughney 985 Nokia Research Center 986 PO Box 407 987 FIN-00045 Nokia Group FIN-00045 988 Finland 990 Email: john.loughney@nokia.com 991 Aron J. Silverton 992 Motorola Labs 993 1301 E. Algonquin Road 994 Room 2246 995 Schaumburg, IL 60196 996 US 998 Phone: +1 847-576-8747 999 Email: aron.j.silverton@motorola.com 1001 Intellectual Property Statement 1003 The IETF takes no position regarding the validity or scope of any 1004 Intellectual Property Rights or other rights that might be claimed to 1005 pertain to the implementation or use of the technology described in 1006 this document or the extent to which any license under such rights 1007 might or might not be available; nor does it represent that it has 1008 made any independent effort to identify any such rights. Information 1009 on the procedures with respect to rights in RFC documents can be 1010 found in BCP 78 and BCP 79. 1012 Copies of IPR disclosures made to the IETF Secretariat and any 1013 assurances of licenses to be made available, or the result of an 1014 attempt made to obtain a general license or permission for the use of 1015 such proprietary rights by implementers or users of this 1016 specification can be obtained from the IETF on-line IPR repository at 1017 http://www.ietf.org/ipr. 1019 The IETF invites any interested party to bring to its attention any 1020 copyrights, patents or patent applications, or other proprietary 1021 rights that may cover technology that may be required to implement 1022 this standard. Please address the information to the IETF at 1023 ietf-ipr@ietf.org. 1025 Disclaimer of Validity 1027 This document and the information contained herein are provided on an 1028 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1029 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1030 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1031 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1032 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1033 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1035 Copyright Statement 1037 Copyright (C) The Internet Society (2005). This document is subject 1038 to the rights, licenses and restrictions contained in BCP 78, and 1039 except as set forth therein, the authors retain all their rights. 1041 Acknowledgment 1043 Funding for the RFC Editor function is currently provided by the 1044 Internet Society.