idnits 2.17.1 draft-ietf-rserpool-service-02.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 764. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 741. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 748. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 754. ** 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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (October 6, 2005) is 6776 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 691, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-rserpool-arch-10 ** Downref: Normative reference to an Informational draft: draft-ietf-rserpool-arch (ref. '3') == Outdated reference: A later version (-11) exists of draft-ietf-rserpool-comp-10 ** Downref: Normative reference to an Informational draft: draft-ietf-rserpool-comp (ref. '4') == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-asap-12 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-asap (ref. '5') == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-enrp-12 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-enrp (ref. '6') Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Lei 3 Internet-Draft Cisco Systems 4 Expires: April 9, 2006 P. Conrad 5 University of Delaware 6 October 6, 2005 8 Services Provided By Reliable Server Pooling 9 draft-ietf-rserpool-service-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 9, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 The Reliable Server Pooling architecture (abbreviated "RSerPool", and 43 defined in [3]), provides a set of services and protocols for 44 building fault tolerant and highly available client/server 45 applications. This memo describes the semantics of the services that 46 RSerPool provides to upper layer protocols. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Conventions Used In This Document . . . . . . . . . . . . . . 4 52 3. Example Application Scenarios . . . . . . . . . . . . . . . . 4 53 3.1. Example Scenario for Failover Without RSerPool . . . . . . 4 54 3.2. Example Scenario Using RSerPool Basic Mode . . . . . . . . 5 55 3.3. Example Scenario Using RSerPool Enhanced Mode . . . . . . 7 56 4. Service Primitives . . . . . . . . . . . . . . . . . . . . . . 8 57 4.1. Initialization . . . . . . . . . . . . . . . . . . . . . . 9 58 4.2. PE Registration Services . . . . . . . . . . . . . . . . . 9 59 4.3. PE Selection Services . . . . . . . . . . . . . . . . . . 9 60 4.4. RSerPool Managed Data Channel . . . . . . . . . . . . . . 10 61 4.5. Failover Services . . . . . . . . . . . . . . . . . . . . 11 62 4.5.1. State Cookie Exchange . . . . . . . . . . . . . . . . 11 63 4.5.2. Failover Callback Function . . . . . . . . . . . . . . 11 64 4.5.3. Business Card . . . . . . . . . . . . . . . . . . . . 13 65 5. Transport Mappings . . . . . . . . . . . . . . . . . . . . . . 13 66 5.1. Defined Transport Mappings . . . . . . . . . . . . . . . . 13 67 5.2. Transport Mappings Requirements . . . . . . . . . . . . . 14 68 5.2.1. Mappings: Mandatory Requirements . . . . . . . . . . . 14 69 5.2.2. Mappings: Optional Requirements . . . . . . . . . . . 14 70 5.2.3. Mappings: Other Requirements . . . . . . . . . . . . . 15 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 76 Intellectual Property and Copyright Statements . . . . . . . . . . 18 78 1. Introduction 80 The Reliable Server Pooling architecture is defined in [3]. The 81 central idea of this architecture is to provide client applications 82 ("pool users") with the ability to select a server (a "pool element") 83 from among a group of servers providing equivalent service (a 84 "pool"). The pool is accessed via an identifier called a "pool 85 handle". The RSerPool architecture supports high-availabilty and 86 load balancing by enabling a pool user to identify the most 87 appropriate server from the server pool at a given time. The 88 architecture also supports failover to an alternate server when 89 needed. 91 This memo describes how an upper layer protocol or application for a 92 pool user or pool element uses the RSerPool architecture and 93 protocols. Specifically, it describes how the ASAP protocol [5] and 94 transport protocols (SCTP, TCP, etc.) can be utilized to realize 95 highly available services between pool users and pool elements. 97 The purpose of this document is to describe: 99 1. the precise services provided by RSerPool to the upper layer, 101 2. the tradeoffs in choosing which services to utilize, 103 3. how applications must be designed for each of these services, 105 4. how applications written over various transports (SCTP, TCP, and 106 others) can be mapped into these services. 108 RSerPool services can be used in one of two modes: "Basic Mode" and 109 "Enhanced Mode". Basic Mode provides a smaller set of services than 110 Enhanced Mode, but offers imposes fewer restrictions on the 111 application layer protocols that can be supported. Enhanced Mode 112 provides extra capabilities, including some features that require 113 applications to exchange application data messages via RSerPool 114 service primitives (a restriction not present in Basic Mode). 116 For Enhanced Mode, the RSerPool data exchange primitives are 117 implemented by multiplexing the ASAP messages and application data 118 over a single transport protocol connection or association. This 119 memo defines how to do this multiplexing over SCTP. This memo also 120 describes the requirments needed to extend support to other transport 121 protocols as required. 123 Note that while RSerPool services are divided into Basic and Enhanced 124 Modes, both modes assume a full implementation of the ASAP protocol. 125 The purpose of dividing RSerPool services into two modes is solely to 126 provide more flexibility for applications to interact with RSerPool. 127 In particular, Basic Mode provides an easy migration path for legacy 128 applications to take advantage of many useful RSerPool services, 129 including load balancing and high availability. Enhanced Mode 130 extends the services provided by Basic Mode with enhanced failover 131 capabilities. 133 2. Conventions Used In This Document 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [2]. 139 3. Example Application Scenarios 141 To illustrate the differences between Basic and Enhanced Mode, this 142 section decribes example failover scenarios for: 144 an application written directly over a transport layer protocol, 145 not utilizing RSerPool 147 an application using RSerPool Basic Mode, and 149 an application using RSerPool Enhanced Mode. 151 3.1. Example Scenario for Failover Without RSerPool 153 Consider a typical client/server application that does not use a 154 reliable server pooling framework of any kind. Typically, the server 155 is specified by a DNS name. At some point, the application 156 translates this name to an IP address (via DNS), and subsequently 157 makes initial contact with the server to begin a session, via SCTP, 158 TCP, UDP, or other transport protocol. If the client loses contact 159 or fails to make contact with the server (either due to server 160 failure, or a failure in the network) the client must either abandon 161 the session, or try to contact another server. 163 In this scenario, the client must first determine that a failure took 164 place. There are several ways that a client application may 165 determine that a server failed, including the following: 167 1. The client may have sent a request to the server, and may time 168 out waiting for a response, or may receive a message such as "no 169 route to host", "port not available", or "connection refused". 171 2. The client may have sent a request to the server, or may have 172 tried to initiate a connection or association and may have 173 received a connection/association failure error. 175 3. The client may already have established a connection to server, 176 but at some point receives an indication from the transport layer 177 that the connection failed. 179 Suppose that the client application has a feature by which the user 180 can enter the hostname of a secondary server to contact in the event 181 of failure. Once the application determines that a failure took 182 place on the primary server, the application can then attempt to 183 resolve the hostname of the secondary server, and contact the 184 secondary server to establish a session there. This process can be 185 iterated to a tertiary server, and so forth. 187 In this scenario, the identification of these alternate servers is an 188 additional burden placedd on the end user. Furthermore, there is no 189 capability in this model to dynamically update the identity of the 190 alternate servers based on current availablity or reachability. DNS 191 has some capabilities that can be used to help, but there are 192 significant limitations to these capabilities (See [4] for a 193 discussion of this point). 195 3.2. Example Scenario Using RSerPool Basic Mode 197 Now consider the same client/server application mentioned in 198 Section 3.1. First we describe what the application programmer must 199 do to modify the code to use RSerPool Basic Mode. We then describe 200 the benefits that these modifications provide. 202 For pool user ("client") applications, if an ASAP implementation is 203 available on the client system, there are typically only three 204 modifications required to the application source code: 206 1. Instead of specifying the hostnames of primary, secondary, 207 tertiary servers, etc., the application user specifies a pool 208 handle. 210 2. Instead of using a DNS based service (e.g. the Unix library 211 function gethostbyname()) to translate from a hostname to an IP 212 address, the application will invoke an RSerPool service 213 primitive GETPRIMARYSERVER that takes as input a pool handle, and 214 returns the IP address of the primary server. The application 215 then uses that IP address just as it would have used the IP 216 address returned by the DNS in the previous scenario. 218 3. Without the use of additional RSerPool services, failure 219 detection is application specific just as in the previous 220 scenario. However, when failure is detected on the primary 221 server, instead of invoking DNS translation again on the hostname 222 of a secondary server, the application invokes the service 223 primitive GETNEXTSERVER, which performs two functions in a single 224 operation. 226 1. First it indicates to the RSerPool layer the failure of the 227 server returned by a previous GETPRIMARYSERVER or 228 GETNEXTSERVER call. 230 2. Second, it provides the IP address of the next server that 231 should be contacted, according to the best information 232 available to the RSerPool layer at the present time (e.g. set 233 of available pool elements, pool element policy in effect for 234 the pool, etc.). 236 For pool element ("server") applications where an ASAP implementation 237 is available, two changes are required to the application source 238 code: 240 1. The server should invoke the REGISTER service primitive upon 241 startup to add itself into the server pool using an appropriate 242 pool handle. This also includes the address(es) protocol or 243 mapping id, port (if required by the mapping), and pooling 244 policy(s). 246 2. The server should invoke the DEREGISTER service primitive to 247 remove itself from the server pool when shutting down. 249 When using these RSerPool services, RSerPool provides benefits that 250 are limited (as compared to utilizing all services, described in 251 Section 3.3), but nevertheless quite useful as compared to not using 252 RSerPool at all (as in Section 3.1). First, the client user need 253 only supply a single string, i.e. the pool handle, rather than a list 254 of servers. Second, the decision as to which server is to be used 255 can be determined dynamically by the server selection mechanism (i.e. 256 a "pool policy" performed by ASAP; see [3]). Finally, when failures 257 occur, these are reported to the pool via signaling present in ASAP 258 [5]) and ENRP [6], other clients will eventually know (once this 259 failure is confirmed by other elements of the RSerPool architecture) 260 that this server has failed. 262 Utilizing this subset of services is useful for: 264 applications built over connectionless protocols such as UDP that 265 cannot easily be adapted to the transport layer requirements 266 required for enhanced services (see section Section 5) 268 applications running on systems which do not provide an 269 appropriate mapping layer for the desired transport protcol 271 an expedient way to provide some of the benefits of RSerPool to 272 legacy applications (regardless of the transport protocol used) 274 However, to take full advantage of the RSerPool framework, 275 utilization of the complete set of Enhanced Mode services as 276 described in the next section is recommended. 278 3.3. Example Scenario Using RSerPool Enhanced Mode 280 Finally, consider the same client/server application as in 281 Section 3.1, but this time, modified to take advantage of RSerPool 282 Enhanced Mode services. As in the Section 3.1, we first describe the 283 modifications needed, then we describe the benefits provided. 285 When the full suite of RSerPool services are used, all communication 286 between the pool user and the pool element is mediated by the 287 RSerPool framework, including session establishment and teardown, and 288 the sending and receiving of data. Accordingly, it is necessary to 289 modify the application to use the service primitives (i.e. the API) 290 provided by RSerPool, rather than the transport layer primitives 291 provided by TCP, SCTP, or whatever transport protocol is being used. 293 As in the previous case, sessions (rather than connections or 294 associations) are established, and the destination endpoint is 295 specified as a pool handle rather than as a list of IP addresses with 296 a port number. However, failover from one pool element to another is 297 fully automatic, and can be transparent to the application: 299 The RSerPool framework control channel provides maintainance 300 functions to keep pool element lists, policies, etc. current. 302 Since the application data (e.g. data channel) is managed by the 303 RSerPool framework, unsent data (data not yet submitted by 304 RSerPool to the underlying transport protocol) is automatically 305 redirected to the newly selected pool element upon failover. If 306 the underlying transport layer supports retrieval of unsent data 307 (as in SCTP), retrieved unsent data can also be automatically re- 308 sent to the newly selected pool element. 310 An application server (pool element) can provide a state cookie 311 (described in Section 4.5.1) that is automatically passed on to 312 another pool element (by the ASAP layer at the pool user) in the 313 event of a failover. This state cookie can be used to assist the 314 application at the new pool element in recreating whatever state 315 is needed to continue a session or transaction that was 316 interrupted by a failure in the communication between a pool user 317 and the original pool element. 319 The application client (pool user) can provide a callback function 320 (described in Section 4.5.2) that is invoked on the pool user side 321 in the case of a failover. This callback function can execute any 322 application specific failover code, such as generating a special 323 message (or sequence of messages) that helps the new pool element 324 construct any state needed to continue an in-process session. 326 Suppose in a particular peer-to-peer application, PU A is 327 communicating with PE B, and it so happens that PU A is also a PE 328 in pool X. PU A can pass a "business card" to PE B identifying it 329 as a member of pool X. In the event of a failure at A, or a 330 failure in the communication link between A and B, PE B can use 331 the information in the business card to contact an equivalent PE 332 to PU A from pool X. 334 Additionally, if the application at PU A is aware of some 335 particular PEs of pool X that would be preferred for B to contact 336 in the event that A becomes unreachable from B, PU A can provide 337 that list to the ASAP layer, and it will be included in A's 338 business card. (See Section 4.5.3)). 340 Retrofitting an existing application for Enhanced Mode requires more 341 application programmer effort than retrofitting an application for 342 Basic Mode. In particular, all use of the transport layer's 343 primitives (e.g. the calls to the sockets API) must be replaced by 344 the use of the RSerPool primitives (e.g. the RSerPool API). This can 345 be mitigated by making the RSerPool API as close to existing 346 transport APIs as possible. However, the benefit is that failure 347 detection and failover is automated in this case. This automatic 348 failure detection takes advantage of heartbeat mechanisms that are 349 provided either in the underlying transport protocol, or in a mapping 350 defined on top of that protocol (see Section 4.5). 352 Provided that developers of APIs for RSerPool stay close to familiar 353 APIs for existing transport protocols, the effort of writing a new 354 applications over RSerPool Enhanced Mode need not be significantly 355 different from writing the same application directly over a supported 356 transport protocol or mapping. 358 4. Service Primitives 360 Upper layer protocols and applications may "choose" to use these 361 primitive services as needed. By selecting and using the appropriate 362 set of service primitives, a range of failover scenarios may be 363 supported. These service primitives are described in the sub- 364 sections that follow. 366 4.1. Initialization 368 The INITIALIZE service is used to establish a service access point to 369 communicate with the ASAP layer on the local host. This is the first 370 service accessed by either a PU or a PE. 372 4.2. PE Registration Services 374 Pool Elements ("server") must use the following services to add or 375 remove themselves from server pools: 377 REGISTER, to add the pool element into a server pool using {pool 378 handle, mapping mode, protocol or mapping id, port, policy info} 379 where mapping mode is defined in Section 5. A response result 380 code is returned. 382 DEREGISTER, to remove the pool element from a server pool using 383 {pool handle, mapping mode, protocol or mapping id, port, policy 384 info} where mapping mode is defined in Section 5. A response 385 result code is returned. 387 4.3. PE Selection Services 389 When automatic failover is enabled, selection of a new pool element 390 according to the pool policy in place is automatically performed by 391 the RSerPool framework in case of a detected failure (e.g. provides 392 automatic failover). No application intervention is required. 394 Automatic failover may be enabled by setting the appropriate send 395 flag when used in conjuction with data channel services (described in 396 Section 4.4) or explicitly during initialization when data channel 397 services are not used. 399 FAILOVER_INDICATION, delivered by callback, indicates that a 400 failover has occurred and that any required application level 401 state recovery should be performed. The newly selected pool 402 element handle is provided. 404 Business Card services: when automatic failover is used, the 405 exchange of business cards for rendezvous services is 406 automatically performed by the RSerPool framework (e.g. no 407 application intervention is required. 409 When automatic failover is not enabled, failover detection and 410 selection of an alternate PE must be done by the upper layer/ 411 application. The following primitives are provided: 413 GET_PRIMARY_SERVER, takes as input a pool handle and returns the 414 {IP address, transport protocol, transport protocol port} of the 415 primary server. 417 GET_NEXT_SERVER has a dual meaning. First, it indicates to the 418 RSerPool layer the failure of the server returned by a previous 419 GET_PRIMARY_SERVER or GET_NEXT_SERVER call. Second, it provides 420 the {IP address, transport protocol, transport protocol port} of 421 the next server that should be contacted, according to the best 422 information available to the RSerPool layer at the present time. 423 The appropriate pool policy for server selection for the pool 424 should be used for selecting the next server. 426 4.4. RSerPool Managed Data Channel 428 The RSerPool framework provides these services to send and receive 429 application layer data, which are used in place of the direct call of 430 transport level system functions (e.g. send/sendto, recv/recvfrom) 431 and provides additional functionality to those calls. 433 DATA_SEND_REQUEST, to send data to a pool element by using a pool 434 handle, specific pool element handle, or by transport address. 435 When sending to a pool handle, the specific pool element handle 436 chosen is returned. In the case that data is sent to a pool 437 handle, or specific pool element handle, the user can request 438 automatic resending (on a best-effort basis) if the original pool 439 element selected is unreachable. (However, it is ultimately the 440 application's responsibility to detect and recover from errors, 441 using acknowledgements at the application layer if needed.) 443 When sending to a specific transport address, this primitive is 444 considered a "pass thru" to the underlying transport, and no 445 failover services are performed. 447 In each case, appropriate error code(s) are returned in the event 448 of failure. (see [5] for more detail). 450 DATA_RECEIVED_NOTIFICATION, delivered by callback, to indicate 451 that data has been received from a pool element and to pass that 452 data to the application layer protocol. An application layer 453 acknowledgement request can be indicated along with the data. 455 4.5. Failover Services 457 The charter of the RSerPool Working Group specifically states that 458 transaction failover is out of scope for RSerPool, i.e. "if a server 459 fails during processing of a transaction this transaction may be 460 lost. Some services may provide a way to handle the failure, but 461 this is not guaranteed." Accordingly, the RSerPool framework 462 provides three "hooks" for applications to provide their own 463 application-specific failover mechanism(s), one on the PE side (State 464 Cookie Exchange), one on the PU side (Failover Callback), and one for 465 entities that are combination of PU/PE (business card). 467 4.5.1. State Cookie Exchange 469 SET_COOKIE: This is invoked by a PE to set the state cookie that 470 is sent periodically over the control channel, when present, from 471 a PE to a PU. The most recently received cookie is cached by the 472 PU; in the event of failover, it is forwarded to the new PE. 474 COOKIE_INDICATION: This is invoked by callback at a PE, when that 475 PE receives a cookie from a PU. This cookie is an indication that 476 the PU has failed over to the current PE from some other PE. The 477 contents of the cookie are provided to the PE prior to any 478 data.indication for messages arriving from the PU that sent the 479 cookie. This provides a hook by which a PE "X" can send a "hint" 480 to its successor PE "Y", in the event that one of X's PU's fails 481 over from X to Y. PE "Y" can use the contents of the cookie to 482 establish application layer state prior to processing resent or 483 new messages from the PU. The PU application layer is not 484 involved in any way in this exchange; it is handled automatically 485 by the ASAP layer. 487 4.5.2. Failover Callback Function 489 AUTHOR'S NOTE (PTC): the service defined in this section is not a 490 part of section 4 of the current version ASAP draft. It should 491 either be added to the ASAP draft, or this service should be removed 492 from the services draft, after discussion on the list. Open 493 question: does the cookie feature eliminate the need for this 494 feature? 496 An PU that establishing a session with a PE can specify a callback 497 function that is invoked whenever a failover has taken place. This 498 callback function is invoked immediately after the new transport 499 layer connection/ association is established with a new server, and 500 gives the application the opportunity to send one or more messages 501 that may help the server to resume any transaction or session that 502 was in progress when the first server failed. In essence, this 503 allows an application designed to put the reestablishment of state 504 into the PU side instead of the PE side, if desired. 506 This service that complements the cookie feature, in the following 507 way: the cookie feature provides failover hooks on the PE side, where 508 the callback is a failover hook for the PU side. The on-the-wire 509 impact is that it is important that the ASAP entity should invoke the 510 failover callback (if any is registered) prior to resending any 511 messages from previous DATA_SEND_REQUEST primitives. 513 Note that if both a state cookie from a PU and a failover callback 514 are present, the state cookie should be sent before the failover 515 callback is issued. 517 As a simple example of how such a callback is useful, consider a file 518 transfer service built using RSerPool. Let us assume that some FTP 519 mirroring software is used to maintain mirrored sites, and that the 520 actual mirroring is out of scope. However, we would like to use 521 RSerPool to select a server from among the available mirror sites, 522 and to failover in the middle of a file transfer if a primary server 523 fails. 525 For this example, assume that a simple request/response protocol is 526 used, where one request message results in one or more response 527 messages. Each request message contains the filename, and the offset 528 desired within the file, (default zero.) Each response message 529 contains some portion of the file, along with the offset, length of 530 the portion in this message, and the length of the entire file. 532 A single request is sufficient to result in a sequence of response 533 messages from the requested offset to the end of the file. 535 In this protocol, all that is needed for failover is for the 536 application to: 538 keep track of the lowest byte that it has not yet received from 539 the server, 541 provide a callback function that reissues the request to the new 542 server, replacing the offset with this number. 544 When there is no failover, only one request message is sent and the 545 minimum number of response messages are returned; in the event of 546 failover(s), single new request message is sent for each failover 547 that occurs. 549 While this is a simple example, for more complex application 550 requirements, the failover callback could be used in a variety of 551 ways: 553 The client might send security credentials for authentication by 554 the server, and/or to provide a "key" by which the server could 555 locate and setup state by accessing some application-specific (and 556 out-of-scope) state sharing mechanism used by the servers. 558 The client might keep track of various synchronization points in 559 the transaction, and use the failover callback to replay message 560 from a recent synchronization point. 562 4.5.3. Business Card 564 This section TBD... describe a service primitive 565 Set.BusinessCard.PE.List. What should the parameters be? This 566 service primitive should also be defined in Section 4 of the ASAP 567 draft. 569 5. Transport Mappings 571 While SCTP is the preferred transport layer protocol for applications 572 built for RSerPool failover mode (for reasons explained shortly), it 573 is also possible to use other transport protocols as well (e.g. TCP) 574 if an SCTP implementation is not available on the client and/or 575 server. However, there are certain features present in SCTP that are 576 required if the RSerPool framework is to function in failover mode. 577 When a transport protocol other than SCTP is used, these features 578 must be provided by an "adaption layer" (also called a "shim 579 protocol") that sits between the base transport protocol (e.g. TCP) 580 and the RSerPool layer. We refer to these "adaptation layers" or 581 "shim protocols" as "mappings" as the idea is that the requirements 582 of the RSerPool framework are "mapped" onto the capabilities of the 583 underlying protocol (e.g. SCTP or TCP). 585 5.1. Defined Transport Mappings 587 In order to support the RSerPool framework over a variety of 588 transport protocols and configurations, several mappings are defined 589 to provide RSerPool services over a given transport protocol. Each 590 mapping translates the requirements of the RSerPool framework onto 591 the capabilities of the transport protocol desired (e.g. SCTP, TCP, 592 etc.). Initially, three mappings are defined: 594 NO_MAPPING (0x00): With this mapping, no RserPool control channel 595 is provided and the application specific communication between a 596 pool user and the pool element (e.g. data channel) is out of scope 597 of RSerPool. However, pool elements can register the application 598 specific communication "protocol" and "port", and thus can be 599 provided to pool users. 601 SCTP (0x01): SCTP transport is used for the RSerPool control 602 channel. The data channel MAY be multiplexed onto the same SCTP 603 association, if desired. This mapping is the preferred mapping. 605 TCP (0x02): TCP transport is used for the RSerPool control 606 channel. The data channel MAY be multiplexed onto the same TCP 607 connection, if desired. 609 A particular pool element might support any combination of these 610 mappings in order to support a variety of pool users with different 611 capabilities (i.e. different mapping support). In this case, pool 612 elements should register each mapping that it supports with its 613 pool(s). 615 5.2. Transport Mappings Requirements 617 5.2.1. Mappings: Mandatory Requirements 619 These features MUST be present in any mapping of the RSerPool 620 framework mode to TCP (or any other transport protocol): 622 1. Message orientation, which facilitates application re- 623 synchronization during failover. Messages must be "framed" in 624 order to allow for undelivered message retrieval from the 625 transport protocol. 627 2. A heartbeat mechanism to monitor the health of an association or 628 connection. 630 3. A mechanism to transport and differentiate between control 631 channel messages (e.g. ASAP messages) and data channel messages. 632 For example in SCTP, the payload protocol identifier (PPID) may 633 be used. 635 4. [NOTE: retrieval was eliminated here as a requirement, now that 636 failover is best effort.] 638 5.2.2. Mappings: Optional Requirements 640 There are several additional features that are present in SCTP that 641 are lacking in TCP. While these features are not crucial to 642 RSerPool, providing them in the mapping layer makes it easier for an 643 application layer programmer to write to a single API. This single 644 API can then be mapped over both SCTP and TCP, as well as any other 645 transport protocol for which a mapping is provided. Since these 646 features are not essential for RSerPool, they are optional in any 647 defined mapping. However, appropriate error messages or indications 648 should be provided when these features are not available. These 649 features include: 651 1. Support for multiple streams 653 2. Support for unordered delivery of messages 655 5.2.3. Mappings: Other Requirements 657 There are some features of SCTP that a mapping may not be able to 658 provide, because they would require access to transport layer 659 internals, or modifications in the transport layer itself. The 660 services provided by the RSerPool layer to the application should 661 therefore provide mechanisms for the upper layer to access these 662 features when present (e.g. in SCTP), but also provide appropriate 663 error messages or indications that these features are not available 664 when they cannot be provided. These features include: 666 1. Application access to the RTT and RTO estimates 668 2. Application access to the Path MTU value 670 3. Application access to set the lifetime parameter on outgoing SCTP 671 messages 673 6. Security Considerations 675 [Open Issue TBD: Security issues are not discussed in this memo at 676 this time, but will be added in a later version of this draft.] 678 7. IANA Considerations 680 [Open Issue TBD: Will there be an enumeration of the various 681 transport layer mappings that must be registered with IANA?] 683 8. Acknowledgements 685 The authors wish to thank Maureen Stillman, Qiaobing Xie, Michael 686 Tuexen, Randall Stewart, and many others for their invaluable 687 comments. 689 9. References 691 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 692 BCP 9, RFC 2026, October 1996. 694 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 695 Levels", BCP 14, RFC 2119, March 1997. 697 [3] Tuexen, M., "Architecture for Reliable Server Pooling", 698 draft-ietf-rserpool-arch-10 (work in progress), July 2005. 700 [4] Loughney, J., "Comparison of Protocols for Reliable Server 701 Pooling", draft-ietf-rserpool-comp-10 (work in progress), 702 July 2005. 704 [5] Stewart, R., "Aggregate Server Access Protocol (ASAP)", 705 draft-ietf-rserpool-asap-12 (work in progress), July 2005. 707 [6] Stewart, R., "Endpoint Handlespace Redundancy Protocol (ENRP)", 708 draft-ietf-rserpool-enrp-12 (work in progress), July 2005. 710 Authors' Addresses 712 Peter Lei 713 Cisco Systems 714 8735 W Higgins Rd, Suite 300 715 Chicago, IL 60631 716 US 718 Phone: +1 773 695 8201 719 Email: peterlei@cisco.com 721 Phillip T. Conrad 722 University of Delaware 723 Dept. of Computer and Information Sciences 724 103 Smith Hall 725 Newark, DE 19716 726 US 728 Phone: +1 302 831 8622 729 Email: conrad@acm.org 730 URI: http://udel.edu/~pconrad 732 Intellectual Property Statement 734 The IETF takes no position regarding the validity or scope of any 735 Intellectual Property Rights or other rights that might be claimed to 736 pertain to the implementation or use of the technology described in 737 this document or the extent to which any license under such rights 738 might or might not be available; nor does it represent that it has 739 made any independent effort to identify any such rights. Information 740 on the procedures with respect to rights in RFC documents can be 741 found in BCP 78 and BCP 79. 743 Copies of IPR disclosures made to the IETF Secretariat and any 744 assurances of licenses to be made available, or the result of an 745 attempt made to obtain a general license or permission for the use of 746 such proprietary rights by implementers or users of this 747 specification can be obtained from the IETF on-line IPR repository at 748 http://www.ietf.org/ipr. 750 The IETF invites any interested party to bring to its attention any 751 copyrights, patents or patent applications, or other proprietary 752 rights that may cover technology that may be required to implement 753 this standard. Please address the information to the IETF at 754 ietf-ipr@ietf.org. 756 Disclaimer of Validity 758 This document and the information contained herein are provided on an 759 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 760 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 761 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 762 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 763 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 764 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 766 Copyright Statement 768 Copyright (C) The Internet Society (2005). This document is subject 769 to the rights, licenses and restrictions contained in BCP 78, and 770 except as set forth therein, the authors retain all their rights. 772 Acknowledgment 774 Funding for the RFC Editor function is currently provided by the 775 Internet Society.