idnits 2.17.1 draft-dreibholz-rserpool-enrp-takeover-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (July 03, 2011) is 4671 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-34) exists of draft-dreibholz-rserpool-asap-hropt-08 == Outdated reference: A later version (-33) exists of draft-dreibholz-rserpool-delay-07 Summary: 0 errors (**), 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: January 4, 2012 Hainan University 6 July 03, 2011 8 Takeover Suggestion Flag for the ENRP Handle Update Message 9 draft-dreibholz-rserpool-enrp-takeover-06.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 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). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on January 4, 2012. 33 Copyright Notice 35 Copyright (c) 2011 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Takeover Suggestion Flag . . . . . . . . . . . . . . . . . . . 3 55 2.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Reference Implementation . . . . . . . . . . . . . . . . . . . 4 57 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 59 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 61 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 64 1. Introduction 66 Reliable Server Pooling as described in [RFC5351] defines protocols 67 for providing highly available services. The management component 68 used for pool administration is denoted as ENRP Server or Pool 69 Registrar (PR). Since a single ENRP server constitutes a single 70 point of failure, there must be multiple ENRP servers. Servers, 71 denoted as Pool Elements (PE), use an arbitrary ENRP server for 72 registration into the pool. The chosen ENRP server becomes the Home 73 ENRP Server, also denoted as Home PR (PR-H), of the PE. It is 74 responsible for making the PE identity known to the other ENRP 75 servers (by using ENRP_HANDLE_UPDATE messages) and also to monitor 76 the PE health (by using keep-alive messages). 78 As shown in [AINA2009], the following scenario leads to unbalanced 79 ENRP server workload: consider a set of multiple ENRP servers with 80 one subset being unreliable (for example, their network connection 81 has problems) and some reliable ENRP servers. After a while, the 82 reliable ENRP server will get the home ENRP server role for almost 83 all of the PEs, which results in high workload for this ENRP server. 84 Since the home ENRP server role is more computation-intensive (as 85 shown by [IJHIT2008]), this leads to highly unbalanced workload for 86 large RSerPool setups. This unbalanced workload remains, even when 87 the unreliable ENRP servers become reliable again (for example, when 88 the network problems have been solved). 90 1.1. Scope 92 The Takeover Suggestion Flag defined in this draft defines a flag for 93 the ENRP_HANDLE_UPDATE message. If the flag is set, the receiving 94 ENRP server is suggested to take over the PE specified in the 95 ENRP_HANDLE_UPDATE message. 97 1.2. Terminology 99 The terms are commonly identified in related work and can be found in 100 the RSerPool Overview document RFC 5351 [RFC5351]. 102 1.3. Conventions 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 2. Takeover Suggestion Flag 109 2.1. Definition 111 In this subsection, only the differences to the ENRP_HANDLE_UPDATE 112 message defined in [RFC5353] are explained. The following figure 113 shows the ENRP_HANDLE_UPDATE message: 115 0 1 2 3 116 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 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | Type = 0x04 |0|0|0|0|0|0|0|T| Message Length | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | Sending Server's ID | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | Receiving Server's ID | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Update Action | (reserved) | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 : Pool Handle Parameter : 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 : Pool Element Parameter : 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 T flag: 1 bit (boolean) 133 If set, the receiving ENRP server is suggested to take over the PE 134 specified by the Pool Handle and Pool Element Parameters. It is 135 RECOMMENDED for the receiving ENRP server to perform this takeover if 136 it has the resources to do so. 138 3. Reference Implementation 140 The RSerPool reference implementation RSPLIB can be found at 141 [RSerPoolPage]. It supports the functionalities defined by 142 [RFC5351], [RFC5352], [RFC5353], [RFC5354] and [RFC5356] as well as 143 the options [I-D.dreibholz-rserpool-asap-hropt], 144 [I-D.dreibholz-rserpool-delay] and of course the option defined by 145 this document. An introduction to this implementation is provided in 146 [Dre2006]. 148 4. Security Considerations 150 Security considerations for RSerPool systems are described by 151 [RFC5355]. 153 5. IANA Considerations 155 This document does not require additional IANA actions beyond those 156 already identified in the ENRP and ASAP protocol specifications. 158 6. References 160 6.1. Normative References 162 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 163 Requirement Levels", BCP 14, RFC 2119, March 1997. 165 [RFC5351] Lei, P., Ong, L., Tuexen, M., and T. Dreibholz, "An 166 Overview of Reliable Server Pooling Protocols", RFC 5351, 167 September 2008. 169 [RFC5352] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, 170 "Aggregate Server Access Protocol (ASAP)", RFC 5352, 171 September 2008. 173 [RFC5353] Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. 174 Silverton, "Endpoint Handlespace Redundancy Protocol 175 (ENRP)", RFC 5353, September 2008. 177 [RFC5354] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, 178 "Aggregate Server Access Protocol (ASAP) and Endpoint 179 Handlespace Redundancy Protocol (ENRP) Parameters", 180 RFC 5354, September 2008. 182 [RFC5355] Stillman, M., Gopal, R., Guttman, E., Sengodan, S., and M. 183 Holdrege, "Threats Introduced by Reliable Server Pooling 184 (RSerPool) and Requirements for Security in Response to 185 Threats", RFC 5355, September 2008. 187 [RFC5356] Dreibholz, T. and M. Tuexen, "Reliable Server Pooling 188 Policies", RFC 5356, September 2008. 190 [I-D.dreibholz-rserpool-asap-hropt] 191 Dreibholz, T., "Handle Resolution Option for ASAP", 192 draft-dreibholz-rserpool-asap-hropt-08 (work in progress), 193 January 2011. 195 [I-D.dreibholz-rserpool-delay] 196 Dreibholz, T. and X. Zhou, "Definition of a Delay 197 Measurement Infrastructure and Delay-Sensitive Least-Used 198 Policy for Reliable Server Pooling", 199 draft-dreibholz-rserpool-delay-07 (work in progress), 200 January 2011. 202 6.2. Informative References 204 [AINA2009] 205 Zhou, X., Dreibholz, T., Fa, F., Du, W., and E. Rathgeb, 206 "Evaluation and Optimization of the Registrar Redundancy 207 Handling in Reliable Server Pooling Systems", 208 Proceedings of the IEEE 23rd International Conference on 209 Advanced Information Networking and Applications (AINA 210 2009), May 2009. 212 [Dre2006] Dreibholz, T., "Reliable Server Pooling -- Evaluation, 213 Optimization and Extension of a Novel IETF Architecture", 214 Ph.D. Thesis University of Duisburg-Essen, Faculty of 215 Economics, Institute for Computer Science and Business 216 Information Systems, URL: http:// 217 duepublico.uni-duisburg-essen.de/servlets/DerivateServlet/ 218 Derivate-16326/Dre2006-final.pdf, March 2007. 220 [IJHIT2008] 221 Dreibholz, T. and E. Rathgeb, "An Evalulation of the Pool 222 Maintenance Overhead in Reliable Server Pooling Systems", 223 International Journal of Hybrid Information Technology 224 (IJHIT) Volume 1, Number 2, April 2008. 226 [RSerPoolPage] 227 Dreibholz, T., "Thomas Dreibholz's RSerPool Page", 228 URL: http://tdrwww.iem.uni-due.de.de/dreibholz/rserpool/. 230 Authors' Addresses 232 Thomas Dreibholz 233 University of Duisburg-Essen, Institute for Experimental Mathematics 234 Ellernstrasse 29 235 45326 Essen, Nordrhein-Westfalen 236 Germany 238 Phone: +49-201-1837637 239 Fax: +49-201-1837673 240 Email: dreibh@iem.uni-due.de 241 URI: http://www.iem.uni-due.de/~dreibh/ 242 Xing Zhou 243 Hainan University, College of Information Science and Technology 244 Renmin Avenue 58 245 570228 Haikou, Hainan 246 China 248 Phone: +86-898-66279141 249 Email: zhouxing@hainu.edu.cn