idnits 2.17.1 draft-dreibholz-rserpool-enrp-takeover-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 5, 2010) is 5196 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-33) exists of draft-dreibholz-rserpool-asap-hropt-04 == Outdated reference: A later version (-32) exists of draft-dreibholz-rserpool-delay-03 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Dreibholz 3 Internet-Draft University of Duisburg-Essen 4 Intended status: Experimental X. Zhou 5 Expires: July 9, 2010 Hainan University 6 January 5, 2010 8 Takeover Suggestion Flag for the ENRP Handle Update Message 9 draft-dreibholz-rserpool-enrp-takeover-03.txt 11 Abstract 13 This document describes the Takeover Suggestion Flag for the 14 ENRP_HANDLE_UPDATE message of the ENRP protocol. 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on July 9, 2010. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Takeover Suggestion Flag . . . . . . . . . . . . . . . . . . . 3 61 2.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Reference Implementation . . . . . . . . . . . . . . . . . . . 4 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 65 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 67 6.2. Informative References . . . . . . . . . . . . . . . . . . 5 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 70 1. Introduction 72 Reliable Server Pooling as described in [RFC5351] defines protocols 73 for providing highly available services. The management component 74 used for pool administration is denoted as ENRP Server or Pool 75 Registrar (PR). Since a single ENRP server constitutes a single 76 point of failure, there must be multiple ENRP servers. Servers, 77 denoted as Pool Elements (PE), use an arbitrary ENRP server for 78 registration into the pool. The chosen ENRP server becomes the Home 79 ENRP Server, also denoted as Home PR (PR-H), of the PE. It is 80 responsible for making the PE identity known to the other ENRP 81 servers (by using ENRP_HANDLE_UPDATE messages) and also to monitor 82 the PE health (by using keep-alive messages). 84 As shown in [AINA2009], the following scenario leads to unbalanced 85 ENRP server workload: consider a set of multiple ENRP servers with 86 one subset being unreliable (for example, their network connection 87 has problems) and some reliable ENRP servers. After a while, the 88 reliable ENRP server will get the home ENRP server role for almost 89 all of the PEs, which results in high workload for this ENRP server. 90 Since the home ENRP server role is more computation-intensive (as 91 shown by [IJHIT2008]), this leads to highly unbalanced workload for 92 large RSerPool setups. This unbalanced workload remains, even when 93 the unreliable ENRP servers become reliable again (for example, when 94 the network problems have been solved). 96 1.1. Scope 98 The Takeover Suggestion Flag defined in this draft defines a flag for 99 the ENRP_HANDLE_UPDATE message. If the flag is set, the receiving 100 ENRP server is suggested to take over the PE specified in the 101 ENRP_HANDLE_UPDATE message. 103 1.2. Terminology 105 The terms are commonly identified in related work and can be found in 106 the RSerPool Overview document RFC 5351 [RFC5351]. 108 1.3. Conventions 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 2. Takeover Suggestion Flag 115 2.1. Definition 117 In this subsection, only the differences to the ENRP_HANDLE_UPDATE 118 message defined in [RFC5353] are explained. The following figure 119 shows the ENRP_HANDLE_UPDATE message: 121 0 1 2 3 122 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Type = 0x04 |0|0|0|0|0|0|0|T| Message Length | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Sending Server's ID | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | Receiving Server's ID | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Update Action | (reserved) | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 : Pool Handle Parameter : 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 : Pool Element Parameter : 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 T flag: 1 bit (boolean) 139 If set, the receiving ENRP server is suggested to take over the PE 140 specified by the Pool Handle and Pool Element Parameters. It is 141 RECOMMENDED for the receiving ENRP server to perform this takeover if 142 it has the resources to do so. 144 3. Reference Implementation 146 The RSerPool reference implementation RSPLIB can be found at 147 [RSerPoolPage]. It supports the functionalities defined by 148 [RFC5351], [RFC5352], [RFC5353], [RFC5354] and [RFC5356] as well as 149 the options [I-D.dreibholz-rserpool-asap-hropt], 150 [I-D.dreibholz-rserpool-delay] and of course the option defined by 151 this document. An introduction to this implementation is provided in 152 [Dre2006]. 154 4. Security Considerations 156 Security considerations for RSerPool systems are described by 157 [RFC5355]. 159 5. IANA Considerations 161 This document does not require additional IANA actions beyond those 162 already identified in the ENRP and ASAP protocol specifications. 164 6. References 166 6.1. Normative References 168 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 169 Requirement Levels", BCP 14, RFC 2119, March 1997. 171 [RFC5351] Lei, P., Ong, L., Tuexen, M., and T. Dreibholz, "An 172 Overview of Reliable Server Pooling Protocols", RFC 5351, 173 September 2008. 175 [RFC5352] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, 176 "Aggregate Server Access Protocol (ASAP)", RFC 5352, 177 September 2008. 179 [RFC5353] Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. 180 Silverton, "Endpoint Handlespace Redundancy Protocol 181 (ENRP)", RFC 5353, September 2008. 183 [RFC5354] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, 184 "Aggregate Server Access Protocol (ASAP) and Endpoint 185 Handlespace Redundancy Protocol (ENRP) Parameters", 186 RFC 5354, September 2008. 188 [RFC5355] Stillman, M., Gopal, R., Guttman, E., Sengodan, S., and M. 189 Holdrege, "Threats Introduced by Reliable Server Pooling 190 (RSerPool) and Requirements for Security in Response to 191 Threats", RFC 5355, September 2008. 193 [RFC5356] Dreibholz, T. and M. Tuexen, "Reliable Server Pooling 194 Policies", RFC 5356, September 2008. 196 6.2. Informative References 198 [AINA2009] 199 Zhou, X., Dreibholz, T., Fa, F., Du, W., and E. Rathgeb, 200 "Evaluation and Optimization of the Registrar Redundancy 201 Handling in Reliable Server Pooling Systems", 202 Proceedings of the IEEE 23rd International Conference on 203 Advanced Information Networking and Applications (AINA 204 2009), May 2009. 206 [RSerPoolPage] 207 Dreibholz, T., "Thomas Dreibholz's RSerPool Page", 208 URL: http://tdrwww.iem.uni-due.de.de/dreibholz/rserpool/. 210 [Dre2006] Dreibholz, T., "Reliable Server Pooling -- Evaluation, 211 Optimization and Extension of a Novel IETF Architecture", 212 Ph.D. Thesis University of Duisburg-Essen, Faculty of 213 Economics, Institute for Computer Science and Business 214 Information Systems, URL: http:// 215 duepublico.uni-duisburg-essen.de/servlets/DerivateServlet/ 216 Derivate-16326/Dre2006-final.pdf, March 2007. 218 [IJHIT2008] 219 Dreibholz, T. and E. Rathgeb, "An Evalulation of the Pool 220 Maintenance Overhead in Reliable Server Pooling Systems", 221 International Journal of Hybrid Information Technology 222 (IJHIT) Volume 1, Number 2, April 2008. 224 [I-D.dreibholz-rserpool-asap-hropt] 225 Dreibholz, T., "Handle Resolution Option for ASAP", 226 draft-dreibholz-rserpool-asap-hropt-04 (work in progress), 227 January 2009. 229 [I-D.dreibholz-rserpool-delay] 230 Dreibholz, T. and X. Zhou, "Definition of a Delay 231 Measurement Infrastructure and Delay-Sensitive Least-Used 232 Policy for Reliable Server Pooling", 233 draft-dreibholz-rserpool-delay-03 (work in progress), 234 January 2009. 236 Authors' Addresses 238 Thomas Dreibholz 239 University of Duisburg-Essen, Institute for Experimental Mathematics 240 Ellernstrasse 29 241 45326 Essen, Nordrhein-Westfalen 242 Germany 244 Phone: +49-201-1837637 245 Fax: +49-201-1837673 246 Email: dreibh@iem.uni-due.de 247 URI: http://www.iem.uni-due.de/~dreibh/ 248 Xing Zhou 249 Hainan University, College of Information Science and Technology 250 Renmin Avenue 58 251 570228 Haikou, Hainan 252 China 254 Phone: +86-898-66279141 255 Email: zhouxing@hainu.edu.cn