idnits 2.17.1 draft-ietf-rserpool-arch-10.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 on line 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1077. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1054. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1061. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1067. ** 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. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (July 7, 2005) is 6860 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 956, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 969, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 975, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 978, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 982, 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-09 ** 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: 5 errors (**), 0 flaws (~~), 9 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: January 8, 2006 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 July 7, 2005 15 Architecture for Reliable Server Pooling 16 draft-ietf-rserpool-arch-10.txt 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on January 8, 2006. 43 Copyright Notice 45 Copyright (C) The Internet Society (2005). 47 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 . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.3 Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Reliable Server Pooling Architecture . . . . . . . . . . . . . 5 59 2.1 RSerPool Functional Components . . . . . . . . . . . . . . 5 60 2.1.1 Pool Elements . . . . . . . . . . . . . . . . . . . . 5 61 2.1.2 ENRP Servers . . . . . . . . . . . . . . . . . . . . . 5 62 2.1.3 Pool Users . . . . . . . . . . . . . . . . . . . . . . 6 63 2.2 RSerPool Protocol Overview . . . . . . . . . . . . . . . . 6 64 2.2.1 Endpoint Handlespace Redundancy Protocol . . . . . . . 6 65 2.2.2 Aggregate Server Access Protocol . . . . . . . . . . . 7 66 2.2.3 PU <-> ENRP Server Communication . . . . . . . . . . . 7 67 2.2.4 PE <-> ENRP Server Communication . . . . . . . . . . . 8 68 2.2.5 PU <-> PE Communication . . . . . . . . . . . . . . . 8 69 2.2.6 ENRP Server <-> ENRP Server Communication . . . . . . 9 70 2.2.7 PE <-> PE Communication . . . . . . . . . . . . . . . 10 71 2.3 Failover Support . . . . . . . . . . . . . . . . . . . . . 10 72 2.3.1 Business Cards . . . . . . . . . . . . . . . . . . . . 10 73 2.3.2 Cookies . . . . . . . . . . . . . . . . . . . . . . . 12 74 2.4 Typical Interactions between RSerPool Components . . . . . 12 75 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 3.1 Two File Transfer Examples . . . . . . . . . . . . . . . . 14 77 3.1.1 The RSerPool Aware Client . . . . . . . . . . . . . . 15 78 3.1.2 The RSerPool Unaware Client . . . . . . . . . . . . . 16 79 3.2 Load Balancing Example . . . . . . . . . . . . . . . . . . 17 80 3.3 Telephony Signaling Example . . . . . . . . . . . . . . . 18 81 3.3.1 Decomposed GWC and GK Scenario . . . . . . . . . . . . 19 82 3.3.2 Collocated GWC and GK Scenario . . . . . . . . . . . . 20 83 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21 84 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 85 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 86 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 87 7.1 Normative References . . . . . . . . . . . . . . . . . . . 22 88 7.2 Informative References . . . . . . . . . . . . . . . . . . 22 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 90 Intellectual Property and Copyright Statements . . . . . . . . 25 92 1. Introduction 94 1.1 Overview 96 A server pool is defined as a set of one or more servers providing 97 the same application functionality. These servers are called Pool 98 Elements (PEs). PEs form the first class of entities in the RSerPool 99 architecture. Multiple PEs in a server pool can be used to provide 100 fault tolerance or load sharing, for example. 102 Each server pool is identified by a unique identifier which is simply 103 a byte string, called the pool handle. This allows binary 104 identifiers to be used. 106 These pool handles are not valid in the whole internet but only in 107 smaller domains, called the operational scope. Furthermore, the 108 handle-space is assumed to be flat, so that multiple levels of query 109 are not necessary to resolve a pool handle. 111 The second class of entities in the RSerPool architecture is the 112 class of Endpoint haNdlespace Redundancy Protocol (ENRP) servers. 113 ENRP servers are designed to provide a fully distributed fault- 114 tolerant real-time translation service that maps a pool handle to set 115 of transport addresses pointing to a specific group of networked 116 communication endpoints registered under that pool handle. To be 117 more precise, ENRP servers can resolve a pool handle to a list of 118 information which allows the Pool User (PU) to access a PE of the 119 server pool identified by the handle. This information includes: 121 o A list of IPv4 and/or IPv6 addresses. 123 o A protocol field specifying the transport layer protocol. 125 o A port number associated with the transport protocol, e.g. SCTP, 126 TCP or UDP. 128 Note that the RSerPool architecture supports both IPv4 and IPv6 129 addressing. 131 In each operational scope there must be at least one ENRP server. 132 All ENRP servers within the operational scope have knowledge of all 133 server pools within the operational scope. 135 RFC3237 [9] also requires that the ENRP servers should not resolve a 136 pool handle to a transport layer address of a PE which is not in 137 operation. Therefore each PE is supervised by one specific ENRP 138 server, called the home ENRP server of that PE. If it detects that 139 the PE is out of service all other ENRP servers are informed. 141 1.2 Terminology 143 This document uses the following terms: 145 Home ENRP Server: The ENRP server a Pool Element has registered with. 146 This ENRP server supervises the Pool Element. 148 Operational scope: The part of the network visible to pool users by a 149 specific instance of the reliable server pooling protocols. 151 Pool (or server pool): A collection of servers providing the same 152 application functionality. 154 Pool handle: A logical pointer to a pool. Each server pool will be 155 identifiable in the operational scope of the system by a unique 156 pool handle. 158 Pool element: A server entity having registered to a pool. 160 Pool user: A server pool user. 162 Pool element handle (or endpoint handle): A logical pointer to a 163 particular pool element in a pool, consisting of the pool handle 164 and a destination transport address of the pool element. 166 Handle space: A cohesive structure of pool handles and relations that 167 may be queried by an internal or external agent. 169 ENRP server: Entity which is responsible for managing and maintaining 170 the handle space within the RSerPool operational scope. 172 1.3 Abbreviations 174 ASAP: Aggregate Server Access Protocol 176 ENRP: Endpoint haNdlespace Redundancy Protocol 178 PE: Pool element 180 PU: Pool user 182 SCTP: Stream Control Transmission Protocol 184 TCP: Transmission Control Protocol 186 2. Reliable Server Pooling Architecture 188 In this section, we define a reliable server pool architecture. 190 2.1 RSerPool Functional Components 192 There are three classes of entities in the RSerPool architecture: 194 o Pool Elements (PEs). 196 o ENRP Servers. 198 o Pool Users (PUs). 200 2.1.1 Pool Elements 202 A server pool is defined as a set of one or more servers providing 203 the same application functionality. These servers are called Pool 204 Elements (PEs). PEs form the first class of entities in the RSerPool 205 architecture. Multiple PEs in a server pool can be used to provide 206 fault tolerance or load sharing, for example. 208 Each server pool is identified by a unique identifier which is simply 209 a byte string, called the pool handle. This allows binary 210 identifiers to be used. 212 These pool handles are not valid in the whole internet but only in 213 smaller domains, called the operational scope. Furthermore, the 214 handle-space is assumed to be flat, so that multiple levels of query 215 are not necessary to resolve a pool handle. 217 2.1.2 ENRP Servers 219 The second class of entities in the RSerPool architecture is the 220 class of ENRP servers. ENRP servers are designed to provide a fully 221 distributed fault-tolerant real-time translation service that maps a 222 pool handle to set of transport addresses pointing to a specific 223 group of networked communication endpoints registered under that pool 224 handle. To be more precise, ENRP servers can resolve a pool handle 225 to a list of information which allows the PU to access a PE of the 226 server pool identified by the handle. This information includes: 228 o A list of IPv4 and/or IPv6 addresses. 230 o A protocol field specifying the transport layer protocol. 232 o A port number associated with the transport protocol, e.g. SCTP, 233 TCP or UDP. 235 Note that the RSerPool architecture supports both IPv4 and IPv6 236 addressing. 238 In each operational scope there must be at least one ENRP server. 239 All ENRP servers within the operational scope have knowledge of all 240 server pools within the operational scope. 242 RFC3237 [9] also requires that the ENRP servers should not resolve a 243 pool handle to a transport layer address of a PE which is not in 244 operation. Therefore each PE is supervised by one specific ENRP 245 server, called the home ENRP server of that PE. If it detects that 246 the PE is out of service all other ENRP servers are informed. 248 2.1.3 Pool Users 250 A third class of entities in the architecture is the Pool User (PU) 251 class, consisting of the clients being served by the PEs of a server 252 pool. 254 2.2 RSerPool Protocol Overview 256 Based on the requirements in RFC3237 [9], the architecture of two new 257 protocols is introduced in this document: ENRP (Endpoint haNdlespace 258 Redundancy Protocol) and ASAP (Aggregate Server Access Protocol). 259 These are used because no existing protocols are suitable (see [3]). 261 2.2.1 Endpoint Handlespace Redundancy Protocol 263 The ENRP servers use a protocol called Endpoint haNdlespace 264 Redundancy Protocol (ENRP) for communication with each other to 265 exchange information and updates about the server pools. 267 ENRP guarantees the integrity of the RSerPool handlespace by 268 providing the means for an ENRP server to 270 o update its peers regarding changes to the handlspace caused by the 271 addition of a PE or the status change of an existing PE, 273 o monitor the health of its peers, and, if necessary, take over the 274 responsibility of being the home ENRP server for a set of PEs when 275 the ENRP server previously responsible for those PEs has failed, 276 and 278 o audit the handlespace for inconsistencies and synchronize the 279 handlespace amongst its peers when inconsistencies have been 280 found. 282 2.2.2 Aggregate Server Access Protocol 284 The PU wanting service from the pool uses the Aggregate Server Access 285 Protocol (ASAP) to access members of the pool. Depending on the 286 level of support desired by the application, use of ASAP may be 287 limited to an initial query for an active PE, or ASAP may be used to 288 mediate all communication between the PU and PE, so that automatic 289 failover from a failed PE to an alternate PE can be supported. 291 ASAP uses pool handles for addressing which isolates a logical 292 communication endpoint from its IP address(es), thus effectively 293 eliminating the binding between the communication endpoint and its 294 physical IP address(es) which normally constitutes a single point of 295 failure. 297 In addition, ASAP provides some mechanisms to support loadsharing 298 between PEs within the same pool and to support the upper layer in 299 case of a failover between PEs becomes necessary. 301 ASAP is also used by a PE to join or leave a server pool. The PE 302 registers or deregisters itself by communicating with an ENRP server, 303 which will normally be the home ENRP server. ASAP allows dynamic 304 system scalability, allowing the pool membership to change at any 305 time. 307 ASAP is used by a home ENRP server to supervise the PEs that have 308 registered with that ENRP server. If the home ENRP server detects 309 that a PE is out of service via ASAP, it notifies its peers using 310 ENRP as described previously. 312 2.2.3 PU <-> ENRP Server Communication 314 The PU <-> ENRP server communication is used for resolving pool 315 handles and uses ASAP. The PU sends a pool handle to the ENRP server 316 and gets back the information necessary for accessing a server in a 317 server pool. 319 This communication can be based on SCTP or TCP if the PU does not 320 support SCTP. The protocol stack for a PU is shown in Figure 1. 322 ********** ************ 323 * PU * * ENRP * 324 * * * server * 325 ********** ************ 327 +--------+ +--------+ 328 | ASAP | | ASAP | 329 +--------+ +--------+ 330 |SCTP/TCP| |SCTP/TCP| 331 +--------+ +--------+ 332 | IP | | IP | 333 +--------+ +--------+ 335 Protocol stack between PU and ENRP server 337 Figure 1 339 2.2.4 PE <-> ENRP Server Communication 341 The PE <-> ENRP server communication is used for registration and 342 deregistration of the PE in one or more pools and for the supervision 343 of the PE by the home ENRP server. This communication uses ASAP and 344 is based on SCTP, the protocol stack is shown in the following 345 figure. 347 ******** ********** 348 * PE * * ENRP * 349 * * * server * 350 ******** ********** 352 +------+ +------+ 353 | ASAP | | ASAP | 354 +------+ +------+ 355 | SCTP | | SCTP | 356 +------+ +------+ 357 | IP | | IP | 358 +------+ +------+ 359 Protocol stack between PE and ENRP server 361 Figure 2 363 2.2.5 PU <-> PE Communication 365 The PU <-> PE communication can be divided into two parts: 367 o control channel 369 o data channel 371 The data channel is used for the transmission of the upper layer 372 data, the control channel is used to exchange RSerPool information. 374 There are two supported scenarios: 376 o Multiplexed data and control channel. Both channels are 377 transported over one transport connection. This can either be an 378 SCTP association, with data and control channel are separated by 379 the PPID, or an TCP connection, with data and control channel 380 being handled by a TCP mapping layer. 382 o Data channel and no control channel. There is no restriction on 383 the transport protocol in this case. Note that certain enhanced 384 failover services (e.g. business cards, state cookies, message 385 failover) are not available when this method is used. 387 For a given pool, all PUs and PEs should make the same choice for the 388 style of interaction between each other: that is, for a given pool, 389 either all PEs and PUs in that pool use a multiplexed control/data 390 channel for PU-PE communication, or all PEs and PUs in that pool use 391 a data channel only for PU-PE communication. 393 When the multiplexed data and control channel is used, enhanced 394 failover services may be provided, including: 396 o The PE can send a business card to the PU for providing 397 information to which other PE the PU should failover in case of a 398 failover. 400 o The PE can send cookies to the PU. The PE would store only the 401 last cookie and send it to the new PE in case of a failover. 403 See Section 2.3 for further details. 405 2.2.6 ENRP Server <-> ENRP Server Communication 407 The communication between ENRP servers is used to share the knowledge 408 about all server pools between all ENRP servers in an operational 409 scope. 411 For this communication ENRP over SCTP is used and the protocol stack 412 is shown in Figure 3. 414 ********** ********** 415 * ENRP * * ENRP * 416 * server * * server * 417 ********** ********** 419 +------+ +------+ 420 | ENRP | | ENRP | 421 +------+ +------+ 422 | SCTP | | SCTP | 423 +------+ +------+ 424 | IP | | IP | 425 +------+ +------+ 426 Protocol stack between ENRP servers 428 Figure 3 430 When a ENRP server initializes a UDP multicast message may be 431 transmitted for initial detection of other ENRP servers in the 432 operational scope. The other ENRP servers send a response using a 433 unicast UDP message. 435 2.2.7 PE <-> PE Communication 437 This is a special case of the PU <-> PE communication. In this case 438 the PU is also a PE in a server pool, this means that one PE is 439 acting like a PU during the communication setup. 441 The difference between a pure PU <-> PE communication is that the PE 442 acting as a PU can send the PE the information that it is actually a 443 PE of a pool. This means that the pool handle is transferred via the 444 control channel. See Section 2.3 for further details. 446 2.3 Failover Support 448 If the PU detects the failure of a PE it may fail over to a different 449 PE. The selection to a new PE should be made such that most likely 450 the new PE is not affected by the failed one. 452 There are some mechanisms provided by RSerPool to support the 453 failover to a new PE. 455 2.3.1 Business Cards 457 A PE can send a business card to its peer containing its pool handle 458 and optionally information to which other PEs the peer should 459 failover. 461 Presenting the pool handle is important in case of PE <-> PE 462 communication in which one of the PEs acts as a PU for establishing 463 the communication. The pool handle of the PE which initiated the 464 communication may not be known by the peer. 466 Providing information to which PE the PU should failover can also be 467 very important. Consider the scenario presented in the following 468 figure. 470 ....................... 471 . +-------+ . 472 . | | . 473 . | PE 1 | . 474 . | | . 475 . +-------+ . 476 . . 477 . server pool . 478 . . 479 . . 480 +-------+ . +-------+ . +-------+ 481 | | . | | . | | 482 | PU 1 |------.------| PE 2 |------.-------| PU 2 | 483 | | . | | . | | 484 +-------+ . +-------+ . +-------+ 485 . . 486 . . 487 . . 488 . . 489 . +-------+ . 490 . | | . 491 . | PE 3 | . 492 . | | . 493 . +-------+ . 494 ....................... 495 Two PUs accessing the same PE 497 Figure 4 499 PU 1 is using PE 2 of the server pool. Assume that PE 1 and PE 2 500 share state but not PE 2 and PE 3. Using the business card of PE 2 501 it is possible for PE 2 to inform PU 1 that it should fail over to PE 502 1 in case of a failure. 504 A slightly more complicated situation is if two pool users, PU 1 and 505 PU 2, use PE 2 but both, PU 1 and PU 2, need to use the same PE. 506 Then it is important that PU 1 and PU 2 fail over to the same PE. 507 This can be handled in a way such that PE 2 gives the same business 508 card to PU 1 and PU 2. 510 2.3.2 Cookies 512 Cookies may optionally be sent from the PE to the PU. The PU only 513 stores the last received cookie. In case of fail over the PU sends 514 this last received cookie to the new PE. This method provides a 515 simple way of state sharing between the PEs. Please note that the 516 old PE should sign the cookie and the receiving PE should verify the 517 signature. For the PU, the cookie has no structure and is only 518 stored and transmitted to the new PE. 520 2.4 Typical Interactions between RSerPool Components 522 The following drawing shows the typical RSerPool components and their 523 possible interactions with each other: 525 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 526 ~ operational scope ~ 527 ~ ......................... ......................... ~ 528 ~ . server pool 1 . . server pool 2 . ~ 529 ~ . +-------+ +-------+ . (d) . +-------+ +-------+ . ~ 530 ~ . |PE(1,A)| |PE(1,C)|<-------------->|PE(2,B)| |PE(2,A)|<---+ ~ 531 ~ . +-------+ +-------+ . . +-------+ +-------+ . | ~ 532 ~ . ^ ^ . . ^ ^ . | ~ 533 ~ . | (a) | . . | | . | ~ 534 ~ . +----------+ | . . | | . | ~ 535 ~ . +-------+ | | . . | | . | ~ 536 ~ . |PE(1,B)|<---+ | | . . | | . | ~ 537 ~ . +-------+ | | | . . | | . | ~ 538 ~ . ^ | | | . . | | . | ~ 539 ~ .......|........|.|.|.... .......|.........|....... | ~ 540 ~ | | | | | | | ~ 541 ~ (c)| (a)| | |(a) (a)| (a)| (c)| ~ 542 ~ | | | | | | | ~ 543 ~ | v v v v v | ~ 544 ~ | +++++++++++++++ (e) +++++++++++++++ | ~ 545 ~ | + ENRP server +<---------->+ ENRP server + | ~ 546 ~ | +++++++++++++++ +++++++++++++++ | ~ 547 ~ v ^ ^ | ~ 548 ~ ********* | | | ~ 549 ~ * PU(A) *<-------+ (b)| | ~ 550 ~ ********* (b) | | ~ 551 ~ v | ~ 552 ~ ::::::::::::::::: (f) ***************** | ~ 553 ~ : other clients :<------------->* proxy/gateway * <---+ ~ 554 ~ ::::::::::::::::: ***************** ~ 555 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 556 RSerPool components and their possible interactions. 558 Figure 5 560 In this figure we can identify the following possible interactions: 562 (a) server pool elements <-> ENRP server: (ASAP) Each PE in a pool 563 uses ASAP to register or de-register itself as well as to exchange 564 other auxiliary information with the ENRP server. The ENRP server 565 also uses ASAP to monitor the operational status of each PE in a 566 pool. 568 (b) PU <-> ENRP server: (ASAP) A PU normally uses ASAP to request the 569 ENRP server for a pool handle to address translation service 570 before the PU can send user messages addressed to a server pool by 571 the pool's handle. 573 (c) PU <-> PE: (ASAP) ASAP can be used to exchange some auxiliary 574 information of the two parties before they engage in user data 575 transfer. 577 (d) server pool <-> server pool: (ASAP) A PE in a server pool can 578 become a PU to another pool when the PE tries to initiate 579 communication with the other pool. In such a case, the 580 interactions described in (a) and (c) above will apply. 582 (e) ENRP server <-> ENRP server: (ENRP) ENRP can be used to fulfill 583 various handle space operation, administration, and maintenance 584 (OAM) functions. 586 (f) Other Clients <-> Proxy/Gateway: standard protocols The proxy/ 587 gateway enables clients ("other clients"), which are not RSerPool 588 aware, to access services provided by an RSerPool based server 589 pool. It should be noted that these proxies/gateways may become a 590 single point of failure. 592 3. Examples 594 In this section the basic concepts behind ENRP and ASAP are motivated 595 through examples. First, an RSerPool aware FTP server and Rserpool 596 aware clients are presented. Secondly, a scenario with an RSerPool 597 aware server with an Rserpool non-aware client shows how to 598 effectively use Rserpool with legacy clients or in a situation where 599 exposure to the PU of the list of addresses associated with the 600 handlespace is undesirable. This requirement has been expressed by 601 some telephony network operators who are concerned about potential 602 network address mapping. The last two examples illustrate load 603 balancing and telephony scenarios. 605 In this section the basic concepts of ENRP and ASAP will be 606 described. First an RSerPool aware FTP server is considered. The 607 interaction with an RSerPool aware and an non-aware client is given. 608 Finally, a telephony example is considered. 610 3.1 Two File Transfer Examples 612 In this section we present two file transfer examples using ENRP and 613 ASAP. We present two separate examples demonstrating an RSerPool- 614 aware client and an RSerPool-unaware client that is using a Proxy or 615 Gateway to perform the file transfer. In these examples we will use 616 a FTP RFC959 [5] model with some modifications. In the first example 617 (client is RSerPool-aware) we will modify FTP concepts so that the 618 file transfer takes place over SCTP. In the second example, we will 619 use TCP between the RSerPool-unaware client and the Proxy. The Proxy 620 itself will use the modified FTP with RSerPool as illustrated in the 621 first example. 623 Please note that in the example we do NOT follow FTP RFC959 [5] 624 precisely but use FTP-like concepts and attempt to adhere to the 625 basic FTP model. These examples use FTP for illustrative purposes. 626 FTP was chosen since many of the basic concept are well known and 627 should be familiar to readers. 629 3.1.1 The RSerPool Aware Client 631 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 632 ~ operational 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| | |ASAP ~ 646 ~ |(d) |(c) | | | ~ 647 ~ | v v v v ~ 648 ~ | ********* +++++++++++++++ ~ 649 ~ + ->* PU(X) * + ENRP server + ~ 650 ~ ********* +++++++++++++++ ~ 651 ~ ^ ASAP ^ ~ 652 ~ | <-(b) | ~ 653 ~ +--------------+ ~ 654 ~ (a)-> ~ 655 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 657 Architecture for RSerPool aware client. 659 Figure 6 661 To effect a file transfer the following steps would take place. 663 1. The application in PU(X) sends a login request. The PU(X)'s ASAP 664 layer sends an ASAP request to an ENRP server to request the list 665 of pool elements (using (a)). The pool handle to identify the 666 pool is "File Transfer Pool". The ASAP layer queues the login 667 request. 669 2. The ENRP server returns a list of the three PEs PE(1,A), PE(1,B) 670 and PE(1,C) to the ASAP layer in PU(X) (using (b)). 672 3. The ASAP layer selects one of the PEs, for example PE(1,B). It 673 transmits the login request and the other FTP control data. 674 Finally, it starts the transmission of the requested files (using 675 (c)). Note that optionally, the multiple stream feature of SCTP 676 could be used. 678 4. Suppose that during the file transfer transmission, PE(1,B) 679 fails. If the PE's are sharing file transfer state, a fail-over 680 to PE(1,A) could be initiated. PE(1,A) then continues the 681 transfer until complete (see (d)). In parallel, a request from 682 PE(1,A) is made to the ENRP server to request a cache update for 683 the server pool "File Transfer Pool". Furthermore, a report is 684 generated that PE(1,B) is non-responsive. This would trigger 685 appropriate audits that may remove PE(1,B) from the pool if the 686 ENRP server had not already detected the failure) (using (a)). 688 3.1.2 The RSerPool Unaware Client 690 In this example we investigate the use of a Proxy server assuming the 691 same set of scenario as illustrated above. 693 In this example the steps will occur: 695 1. The FTP client and the Proxy/Gateway are using the TCP-based ftp 696 protocol. The client sends the login request to the proxy (using 697 (e)). 699 2. The proxy behaves like a client and performs the actions 700 described under (1), (2) and (3) of the above description (using 701 (a), (b) and (c)). 703 3. The ftp communication continues and will be translated by the 704 proxy into the RSerPool aware dialect. This interworking uses 705 (f) and (c). 707 Note that in this example high availability is maintained between the 708 Proxy and the server pool but a single point of failure exists 709 between the FTP client and the Proxy, i.e. the command TCP connection 710 and its one IP address it is using for commands. 712 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 713 ~ operational scope ~ 714 ~ ......................... ~ 715 ~ . "file transfer pool" . ~ 716 ~ . +-------+ +-------+ . ~ 717 ~ . |PE(1,A)| |PE(1,C)| . ~ 718 ~ . +-------+ +-------+ . ~ 719 ~ . ^ ^ . ~ 720 ~ . +----------+ | . ~ 721 ~ . +-------+ | | . ~ 722 ~ . |PE(1,B)|<---+ | | . ~ 723 ~ . +-------+ | | | . ~ 724 ~ .......^........|.|.|.... ~ 725 ~ | | | | ~ 726 ~ | ASAP| | |ASAP ~ 727 ~ | | | | ~ 728 ~ | v v v ~ 729 ~ | +++++++++++++++ +++++++++++++++ ~ 730 ~ | + ENRP server +<--ENRP-->+ ENRP server + ~ 731 ~ | +++++++++++++++ +++++++++++++++ ~ 732 ~ | ASAP ^ ~ 733 ~ | ASAP (c) (b) | ^ ~ 734 ~ +---------------------------------+ | | | ~ 735 ~ | v | (a) ~ 736 ~ v v ~ 737 ~ ::::::::::::::::: (e)-> ***************** ~ 738 ~ : FTP client :<------------->* proxy/gateway * ~ 739 ~ ::::::::::::::::: (f) ***************** ~ 740 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 741 Architecture for RSerPool unaware client. 743 Figure 7 745 3.2 Load Balancing Example 747 This example is similar to the one above describing an RSerPool 748 unaware client. In both examples the clients do not need to support 749 the RSerPool protocol suite. 751 There are several servers in a pool and the traffic from clients is 752 distributed among them by a load balancer. The load balancer can 753 make use of load information provided by the servers for optimal load 754 distribution. 756 One possibility of using RSerPool for this application is described 757 in the next figure. The servers become pool elements in a pool and 758 register themselves with ENRP servers. They can also provide load 759 information. The load balancer acts as a pool user and gets the 760 addresses and possibly the load information via ASAP communication 761 with ENRP servers. The communication between the clients and servers 762 is not affected. 764 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 765 ~ operational scope ~ 766 ~ ......................... ~ 767 ~ . "server pool" . ~ 768 ~ . +-------+ +-------+ . ~ 769 ~ . |PE(1,A)| |PE(1,C)| . ~ 770 ~ . +-------+ +-------+ . ~ 771 ~ . ^ ^ . ~ 772 ~ . +----------+ | . ~ 773 ~ . +-------+ | | . ~ 774 ~ . |PE(1,B)|<---+ | | . ~ 775 ~ . +-------+ | | | . ~ 776 ~ .......^........|.|.|.... ~ 777 ~ | | | | ~ 778 ~ | ASAP| | |ASAP ~ 779 ~ | | | | ~ 780 ~ | v v v ~ 781 ~ | +++++++++++++++ +++++++++++++++ ~ 782 ~ | + ENRP server +<--ENRP-->+ ENRP server + ~ 783 ~ | +++++++++++++++ +++++++++++++++ ~ 784 ~ | ^ ~ 785 ~ | (c) | ~ 786 ~ +---------------------------------+ | ASAP ~ 787 ~ | | (a) ~ 788 ~ v v ~ 789 ~ ::::::::::::::::: (b) ********************** ~ 790 ~ : client :<----------->* load balancer (PU) * ~ 791 ~ ::::::::::::::::: ********************** ~ 792 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 793 Architecture for an RSerPool based load balancer. 795 Figure 8 797 3.3 Telephony Signaling Example 799 This example shows the use of ASAP/RSerPool to support server pooling 800 for high availability of a telephony application such as a Voice over 801 IP Gateway Controller (GWC) and Gatekeeper services (GK). 803 In this example, we show two different scenarios of deploying these 804 services using RSerPool in order to illustrate the flexibility of the 805 RSerPool architecture. 807 3.3.1 Decomposed GWC and GK Scenario 809 In this scenario, both GWC and GK services are deployed as separate 810 pools with some number of PEs, as shown in the following diagram. 811 Each of the pools will register their unique pool handle with the 812 ENRP server. We also assume that there are a Signaling Gateway (SG) 813 and a Media Gateway (MG) present and both are RSerPool aware. 815 ................... 816 . gateway . 817 . controller pool . 818 ................. . +-------+ . 819 . gatekeeper . . |PE(2,A)| . 820 . pool . . +-------+ . 821 . +-------+ . . +-------+ . 822 . |PE(1,A)| . . |PE(2,B)| . 823 . +-------+ . . +-------+ . 824 . +-------+ . (d) . +-------+ . 825 . |PE(1,B)|<------------>|PE(2,C)|<-------------+ 826 . +-------+ . . +-------+ . | 827 ................. ........^.......... | 828 | | 829 (c)| (e)| 830 | v 831 +++++++++++++++ ********* ***************** 832 + ENRP server + * SG(X) * * media gateway * 833 +++++++++++++++ ********* ***************** 834 ^ ^ 835 | | 836 | <-(a) | 837 +-------------------+ 838 (b)-> 840 Deployment of Decomposed GWC and GK. 842 Figure 9 844 As shown in the previous figure, the following sequence takes place: 846 1. The Signaling Gateway (SG) receives an incoming signaling message 847 to be forwarded to the GWC. SG(X)'s ASAP layer sends an ASAP 848 request to its "local" ENRP server to request the list of pool 849 elements (PE's) of GWC (using (a)). The handle used for this 850 query is the pool handle of the GWC. The ASAP layer queues the 851 data to be sent to the GWC in local buffers until the ENRP server 852 responds. 854 2. The ENRP server returns a list of the three PE's A, B and C to 855 the ASAP layer in SG(X) together with information to be used for 856 load-sharing traffic across the gateway controller pool (using 857 (b)). 859 3. The ASAP layer in SG(X) will select one PE (e.g., PE(2,C)) and 860 send the signaling message to it (using (c)). The selection is 861 based on the load sharing information of the gateway controller 862 pool. 864 4. To progress the call, PE(2,C) finds that it needs to talk to the 865 Gatekeeper. Assuming it has the gatekeeper pool's information in 866 its local cache (e.g., obtained and stored from a recent query to 867 ENRP server), PE(2,C) selects PE(1,B) and sends the call control 868 message (using (d)). 870 5. We assume PE(1,B) responds to PE(2,C) and authorizes the call to 871 proceed. 873 6. PE(2,C) issues media control commands to the Media Gateway (using 874 (e)). 876 RSerPool will provide service robustness to the system if some 877 failure occurs in the system. 879 For example, if PE(1, B) in the Gatekeeper Pool crashed after 880 receiving the call control message from PE(2, C) in step (d) above. 881 What most likely will happen is that, due to the absence of a reply 882 from the Gatekeeper, a timer expiration event will trigger the call 883 state machine within PE(2, C) to resend the control message. The 884 ASAP layer at PE(2, C) will then notice the failure of PE(1, B) 885 through the endpoint unreachability detection by the transport 886 protocol beneath ASAP and automatically deliver the re-sent call 887 control message to the alternate GK pool member PE(1, A). With 888 appropriate intra-pool call state sharing support, PE(1, A) will 889 correctly handle the call and reply to PE(2, C) and hence progress 890 the call. 892 3.3.2 Collocated GWC and GK Scenario 894 In this scenario, the GWC and GK services are collocated (e.g., they 895 are implemented as a single process). In this case, one can form a 896 pool that provides both GWC and GK services as shown in the figure 897 below. 899 The same sequence as described in 5.2.1 takes place, except that step 900 (4) now becomes internal to the PE(3,C). Again, we assume server C 901 is selected by SG. 903 ........................................ 904 . gateway controller/gatekeeper pool . 905 . +-------+ . 906 . |PE(3,A)| . 907 . +-------+ . 908 . +-------+ . 909 . |PE(3,C)|<---------------------------+ 910 . +-------+ . | 911 . +-------+ ^ . | 912 . |PE(3,B)| | . | 913 . +-------+ | . | 914 ................|....................... | 915 | | 916 +-------------+ | 917 | | 918 (c)| (e)| 919 v v 920 +++++++++++++++ ********* ***************** 921 + ENRP server + * SG(X) * * media gateway * 922 +++++++++++++++ ********* ***************** 923 ^ ^ 924 | | 925 | <-(a) | 926 +-------------------+ 927 (b)-> 929 Deployment of Collocated GWC and GK. 931 Figure 10 933 4. Security Considerations 935 The RSerPool protocol must allow us to secure the RSerPool 936 infrastructure. There are security and privacy issues that relate to 937 the handle space, pool element registration and user queries of the 938 handle space. In [2] a complete threat analysis of RSerPool 939 components is presented. 941 5. IANA Considerations 943 There are no actions needed. 945 6. Acknowledgements 947 The authors would like to thank Bernard Aboba, Phillip Conrad, Harrie 948 Hazewinkel, Matt Holdrege, Lyndon Ong, Christopher Ross, Maureen 949 Stillman, Werner Vogels and many others for their invaluable comments 950 and suggestions. 952 7. References 954 7.1 Normative References 956 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 957 BCP 9, RFC 2026, October 1996. 959 [2] Stillman, M., "Threats Introduced by Rserpool and Requirements 960 for Security in response to Threats", 961 draft-ietf-rserpool-threats-04 (work in progress), January 2005. 963 [3] Loughney, J., "Comparison of Protocols for Reliable Server 964 Pooling", draft-ietf-rserpool-comp-09 (work in progress), 965 February 2005. 967 7.2 Informative References 969 [4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 970 September 1981. 972 [5] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, 973 RFC 959, October 1985. 975 [6] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service 976 Location Protocol, Version 2", RFC 2608, June 1999. 978 [7] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L., 979 Lin, H., Juhasz, I., Holdrege, M., and C. Sharp, "Framework 980 Architecture for Signaling Transport", RFC 2719, October 1999. 982 [8] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 983 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, 984 "Stream Control Transmission Protocol", RFC 2960, October 2000. 986 [9] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, 987 J., and M. Stillman, "Requirements for Reliable Server Pooling", 988 RFC 3237, January 2002. 990 Authors' Addresses 992 Michael Tuexen (editor) 993 Muenster Univ. of Applied Sciences 994 Stegerwaldstr. 39 995 48565 Steinfurt 996 Germany 998 Email: tuexen@fh-muenster.de 1000 Qiaobing Xie 1001 Motorola, Inc. 1002 1501 W. Shure Drive, #2309 1003 Arlington Heights, IL 60004 1004 USA 1006 Phone: +1-847-632-3028 1007 Email: qxie1@email.mot.com 1009 Randall R. Stewart 1010 Cisco Systems, Inc. 1011 8725 West Higgins Road 1012 Suite 300 1013 Chicago, IL 60631 1014 USA 1016 Phone: +1-815-477-2127 1017 Email: rrs@cisco.com 1019 Melinda Shore 1020 Cisco Systems, Inc. 1021 809 Hayts Rd 1022 Ithaca, NY 14850 1023 USA 1025 Phone: +1 607 272 7512 1026 Email: mshore@cisco.com 1027 John Loughney 1028 Nokia Research Center 1029 PO Box 407 1030 FIN-00045 Nokia Group FIN-00045 1031 Finland 1033 Email: john.loughney@nokia.com 1035 Aron J. Silverton 1036 Motorola Labs 1037 1301 E. Algonquin Road 1038 Room 2246 1039 Schaumburg, IL 60196 1040 US 1042 Phone: +1 847-576-8747 1043 Email: aron.j.silverton@motorola.com 1045 Intellectual Property Statement 1047 The IETF takes no position regarding the validity or scope of any 1048 Intellectual Property Rights or other rights that might be claimed to 1049 pertain to the implementation or use of the technology described in 1050 this document or the extent to which any license under such rights 1051 might or might not be available; nor does it represent that it has 1052 made any independent effort to identify any such rights. Information 1053 on the procedures with respect to rights in RFC documents can be 1054 found in BCP 78 and BCP 79. 1056 Copies of IPR disclosures made to the IETF Secretariat and any 1057 assurances of licenses to be made available, or the result of an 1058 attempt made to obtain a general license or permission for the use of 1059 such proprietary rights by implementers or users of this 1060 specification can be obtained from the IETF on-line IPR repository at 1061 http://www.ietf.org/ipr. 1063 The IETF invites any interested party to bring to its attention any 1064 copyrights, patents or patent applications, or other proprietary 1065 rights that may cover technology that may be required to implement 1066 this standard. Please address the information to the IETF at 1067 ietf-ipr@ietf.org. 1069 Disclaimer of Validity 1071 This document and the information contained herein are provided on an 1072 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1073 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1074 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1075 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1076 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1077 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1079 Copyright Statement 1081 Copyright (C) The Internet Society (2005). This document is subject 1082 to the rights, licenses and restrictions contained in BCP 78, and 1083 except as set forth therein, the authors retain all their rights. 1085 Acknowledgment 1087 Funding for the RFC Editor function is currently provided by the 1088 Internet Society.