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