idnits 2.17.1 draft-coene-rserpool-applic-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 134 has weird spacing: '...olution and t...' == Line 135 has weird spacing: '...running over ...' == Line 209 has weird spacing: '...quenced and/o...' -- 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 (March 3, 2003) is 7718 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) -- Looks like a reference, but probably isn't: 'RFC3057' on line 240 == Unused Reference: '1' is defined on line 249, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 257, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 261, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 268, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 271, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3237 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 2960 (ref. '7') (Obsoleted by RFC 4960) -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Downref: Normative reference to an Informational RFC: RFC 3257 (ref. '9') Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Reliable Server Pooling Working L. Coene 3 group Siemens 4 Internet-Draft March 3, 2003 5 Expires: September 1, 2003 7 Reliable Server pool applicability Statement 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on September 1, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 This document describes the applicability of the reliable server pool 39 architecture and protocols to applications which want to have High 40 avialebility services. This is accomplished by using redundant 41 servers and failover between servers of the same pool in case of 42 server failure. Processing load in a pool may de distributed/shared 43 between the members of the pool according to a certain policy. Also 44 some guidance is given on the choice of underlying transport protocol 45 (and corresponding transport protocol mapping) for transporting 46 application data and Rserpool specific control data. 48 1. INTRODUCTION 50 Reliable server pooling provides protocols for providing higly 51 available services. The services are located in pool of redundant 52 servers and if a server fails, another server will take over. The 53 only requirement put on these servers belonging to the pool is that 54 if state is maintained by the server, this state must be transfered 55 to the other server taking over. The mechanism for transfering this 56 state information is NOT part of the Reliable server pooling 57 architecture and/or protocols and must be provided by other 58 protocols. 60 The goal is to provide server based redundancy. Transport and network 61 level redundancy are handle by the transport and network layer 62 protcols. 64 The application may choose to distribute its traffic over the servers 65 of the pool conforming to a certain policy. 67 The application wishing to make use of Rserpool protocols may use 68 different transport layers(such as UDP, TCP and SCTP). However some 69 transport layers may have restrictions build in in the way they might 70 be operating in the Rserpool architecture and its protocols. 72 1.1 Scope 74 The scope of this document is to explore the different ways that 75 Reliable server pool protocols can be used in order to provide a 76 higly available service towards applications with different 77 requirements. 79 1.2 Terminology 81 The terms are commonly identified in related work and can be found in 82 the Aggregate Server Access Protocol and Endpoint Name Resolution 83 Protocol Common Parameters documentRFC COMM [5]. 85 2. Reliable serverpool 87 2.1 Architecture 89 A overview of the reliable server pool architecture is given in the 90 Rserpool architecture document RFC ARCH [2]. 92 The Rserpool architecture is made up of clients(Pool Users - PU) and 93 servers(Pool Elements - PE). Both PU and PE's can be grouped into a 94 pool in which a PE provides a service(File transfer, storage, bank 95 transaction) to a PU. The PU's may try to find out via the endpoint 96 resolution protocol(ENRP) which PE's are active. The PU can set up a 97 communication channel with a particular PE(chosen out of the server 98 pool) by using the Aggregate Server Access Protocol (ASAP) or by 99 using directly any of the transport protcols(UDP/TCP/SCTP/RTP). ASAP 100 may be running on top of UDP, TCP or SCTP. 102 The minimum mode of using Rserpool is to use only the ENRP for 103 Endpoint name resolution. The PU may setup the client - server 104 communication WITHOUT ASAP, but using present transport 105 protocols(such as UDP, TCP..) 107 The normal use of Rserpool is to use ENRP for Enpoint name resolution 108 and ASAP for client - server communication. ASAP may be using as 109 underlying transport protocol UDP, TCP or SCTP. 111 2.2 ASAP/ENRP applicability 113 2.2.1 Minimal rserpool service 115 The minimum service provided by Rserpool is the use of ENRP for 116 Endpoint name resolution. The ENRP procol may be running over TCP or 117 SCTP. 119 o Endpoint name resolution 121 o no automatic failover from one PE to another, has to be done by 122 the application itself 124 o bussinesscard or cookie mechanism not possible 126 o May be used by allready existing applications which do not want to 127 change the interface between PU and PE. 129 o Only PU-NS and PE-NS communication will use Rserpool protocols 131 2.2.2 Full Rserpool service 133 The fullservice provided by Rserpool is the use of ENRP for Endpoint 134 name resolution and the Use of ASAP for PU - PE communication . ENRP 135 may be running over TCP or SCTP while ASAP may be running over TCP, 136 SCTP, UDP or RTP. 138 o Endpoint name resolution 140 o automatic failover from one PE to another is transparent for the 141 application itself 143 o bussinesscard exhange for determining if a PU is a pool or not. It 144 allows the PE to treat the PU's as pool and use Rserpool protocols 145 for it 147 o cookie mechanism can be used for state transfer between PE's 149 o May be used by allready existing applications which do not want to 150 change the interface between PU and PE. 152 o All entities wil use Rspool protocols for communication withs 153 their respective peers 155 3. Application and Control data Transport 157 3.1 Rserpool use between 2 pools 159 Bussinesscards will allow to detect if their peer is part of a pool 160 itself. Both the PU and the PE can be part of their own pools. If the 161 PU or PE would fails, then the businesscard will have informed the 162 respective peer to contact a alternative fellow PE/PU belonging to 163 the pool. 165 3.2 state sharing via the cookie 167 Every time a response is send back, a cookie could be send along the 168 response. The cookie is "encrypted" and is stored by the PU, no 169 modification at all it done to the cookie . If a PE fails then the 170 cookie is send to a alternate PE, the PE check if the cookie is 171 valid. The contents of the cookie is only provided and validated by 172 the PE. It can be used for state sharing between the PE. 174 4. Transport protocols used by ENRP & ASAP 176 4.1 ASAP on top of UDP 178 UDP is a unreliable message transport delivery protocol, so if a 179 message gets lost due to a changeover of server(or client), then the 180 message will not be retransmitted after changeover has occured. New 181 messages will be sent to alternate server/client within the 182 serverpool. 184 This service may be of some importance to services where realtime 185 constraints apply.(Example video servers: a few lost message ain't 186 that important as long as the big bulk of messages get through). No 187 conegstion control is done and as such no real measure of the 188 congestion status on the server(or client) is taken into account, 189 thus making loadsharing harder. Only the ENRP server responsible for 190 that particular server pool will have a up to date view of the load 191 distribution in the pool. 193 4.2 ASAP on top of TCP 195 TCP provides full reliable delivery with congestion control of the 196 message to its peer node. It provides for a single homed, single 197 stream delivery of a byte stream from or to the server. Change over 198 will retrieve the unsent messages and send them on another TCP 199 connection to a different server of the server pool. 201 4.3 ASAP on top of SCTP 203 PR-SCTP is the only know protocol which allows the choice of full, 204 partial or no reliable delivery with congestion control of the 205 message to its peer node. If the no-reliable delivery option is 206 selected of SCTP, then ASAP will function as described in ASAP over 207 UDP and including congestion control. 209 if multihoming, streams, unsequenced and/or assured delivery are 210 required for the application, then SCTP should be used for ASAP. See 211 SCTP aplicability statement RFC 3257 [9]. 213 5. Issues for Reliable Server pooling 215 5.1 State transfer accoss the server pool 217 Rserpool protocols(ENRP and ASAP) do NOT provide any service for 218 transfering state information of a application from one Processing 219 Element(PE) to another. 221 6. Security considerations 223 The protocols used in the Reliable server pool architecture only 224 tries to increase the availability of the servers in the network. 225 Rserpool protocols does not contain any protocol mechanisms which are 226 directly related to user message authentication, integrity and 227 confidentiality functions. For such features, it depends on the IPSEC 228 protocols or on Transport Layer Security(TLS) protocols for its own 229 security and on the architecture and/or security features of its user 230 protocols. 232 A overview of possible treats to Reliable Server pooll protcols is 233 detailed in RFC TREAT [8]. 235 Rserpool architecture allows the use of different Transport protocols 236 for its application and control data exchange. Those transport 237 protocols may have mechanisms for reducing the risk of blind 238 denial-of-service attacks and/or masquerade attacks. If such measures 239 are required by the applications, then it is advised to check the 240 SCTP applicability statement[RFC3057] for guidance on this issue. 242 7. Acknowledgments 244 The authors wish to thank X, Y and M. Stillman and many others for 245 their invaluable comments. 247 References 249 [1] Tuexen, M., Stewart, R., Shore, M., Xie, Q., Ong, L., Loughney, 250 J. and M. Stillman, "Requirements for Reliable Server Pooling", 251 RFC 3237, January 2002. 253 [2] Tuexen, M., Stewart, R., Shore, M., Xie, Q., Ong, L., Loughney, 254 J. and M. Stillman, "Architecture for Reliable Server Pooling", 255 Draft in progress , October 2002. 257 [3] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate 258 Server Access Protocol (ASAP)", Draft in progress , October 259 2002. 261 [4] Xie, Q., Stewart, R. and M. Stillman, "Endpoint Name Resolution 262 Protocol (ENRP)", Draft in progress , October 2002. 264 [5] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate 265 Server Access Protocol and Endpoint Name Resolution Protocol 266 Common Parameters", Draft in progress , October 2002. 268 [6] Conrad, P. and P. Lei, ""Services Provided By Reliable Server 269 Pooling", Draft in progress , January 2003. 271 [7] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 272 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 273 ""Stream Control Transmission Protocol"", RFC 2960, October 274 2000. 276 [8] Stillman, M., Gopal, R., Sengodan, S., Guttman, E. and M. 277 Holdrege, ""Threats Introduced by Rserpool and Requirements for 278 Security in response to Threats"", RFC zzzz, Nov 2002. 280 [9] Coene, L., ""Stream Control Transmission Protocol Applicability 281 statement"", RFC 3257, April 2002. 283 Author's Address 285 Lode Coene 286 Siemens 287 Atealaan 32 288 Herentals 2200 289 Belgium 291 Phone: +32-14-252081 292 EMail: lode.coene@siemens.com 294 Intellectual Property Statement 296 The IETF takes no position regarding the validity or scope of any 297 intellectual property or other rights that might be claimed to 298 pertain to the implementation or use of the technology described in 299 this document or the extent to which any license under such rights 300 might or might not be available; neither does it represent that it 301 has made any effort to identify any such rights. Information on the 302 IETF's procedures with respect to rights in standards-track and 303 standards-related documentation can be found in BCP-11. Copies of 304 claims of rights made available for publication and any assurances of 305 licenses to be made available, or the result of an attempt made to 306 obtain a general license or permission for the use of such 307 proprietary rights by implementors or users of this specification can 308 be obtained from the IETF Secretariat. 310 The IETF invites any interested party to bring to its attention any 311 copyrights, patents or patent applications, or other proprietary 312 rights which may cover technology that may be required to practice 313 this standard. Please address the information to the IETF Executive 314 Director. 316 Full Copyright Statement 318 Copyright (C) The Internet Society (2003). All Rights Reserved. 320 This document and translations of it may be copied and furnished to 321 others, and derivative works that comment on or otherwise explain it 322 or assist in its implementation may be prepared, copied, published 323 and distributed, in whole or in part, without restriction of any 324 kind, provided that the above copyright notice and this paragraph are 325 included on all such copies and derivative works. However, this 326 document itself may not be modified in any way, such as by removing 327 the copyright notice or references to the Internet Society or other 328 Internet organizations, except as needed for the purpose of 329 developing Internet standards in which case the procedures for 330 copyrights defined in the Internet Standards process must be 331 followed, or as required to translate it into languages other than 332 English. 334 The limited permissions granted above are perpetual and will not be 335 revoked by the Internet Society or its successors or assignees. 337 This document and the information contained herein is provided on an 338 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 339 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 340 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 341 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 342 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 344 Acknowledgement 346 Funding for the RFC Editor function is currently provided by the 347 Internet Society.