idnits 2.17.1 draft-dreibholz-rserpool-nextgen-ideas-13.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 (March 13, 2020) is 1477 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4960 (ref. '10') (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 6824 (ref. '11') (Obsoleted by RFC 8684) == Outdated reference: A later version (-33) exists of draft-dreibholz-rserpool-asap-hropt-25 == Outdated reference: A later version (-32) exists of draft-dreibholz-rserpool-delay-24 == Outdated reference: A later version (-30) exists of draft-dreibholz-rserpool-enrp-takeover-22 Summary: 2 errors (**), 0 flaws (~~), 4 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 SimulaMet 4 Intended status: Informational March 13, 2020 5 Expires: September 14, 2020 7 Ideas for a Next Generation of the Reliable Server Pooling Framework 8 draft-dreibholz-rserpool-nextgen-ideas-13 10 Abstract 12 This document collects some idea for a next generation of the 13 Reliable Server Pooling framework. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on September 14, 2020. 32 Copyright Notice 34 Copyright (c) 2020 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 2 51 1.2. Reliable Server Pooling . . . . . . . . . . . . . . . . . 2 52 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. What to Change in the Next Generation of RSerPool? . . . . . 3 54 2.1. Security Considerations . . . . . . . . . . . . . . . . . 4 55 2.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 4 56 3. Reference Implementation . . . . . . . . . . . . . . . . . . 4 57 4. Testbed Platform . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 59 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 61 6.2. Informative References . . . . . . . . . . . . . . . . . 6 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 64 1. Introduction 66 1.1. Abbreviations 68 o ASAP: Aggregate Server Access Protocol 70 o ENRP: Endpoint Handlespace Redundancy Protocol 72 o ID: Identifier 74 o MPTCP: Multi-Path Transmission Control Protocol 76 o PE: Pool Element 78 o PR: Pool Registrar 80 o PU: Pool User 82 o RSerPool: Reliable Server Pooling 84 o SCTP: Stream Control Transmission Protocol 86 o TCP: Transmission Control Protocol 88 o VNFPOOL: Virtual Network Function Resource Pooling 90 1.2. Reliable Server Pooling 92 Reliable Server Pooling (RSerPool) has been defined as RFCs in [1], 93 [2], [3], [4], [5], [6], [7], [8]. There is also a detailed 94 introduction provided by [16] as well as lots of further information 95 material on [22]. RSerPool is therefore not introduced in more 96 detail here. 98 1.3. Scope 100 The scope of this document is to collect some ideas of what to 101 update/change for a next generation of the RSerPool framework. It is 102 a result of lessons learned with more than one decade of RSerPool 103 deployment (see also [17], [18], [19]) as well as ongoing discussions 104 on applying RSerPool for Virtual Network Function Resource 105 Pooling (VNFPOOL; as introduced in more detail in [15]). 107 2. What to Change in the Next Generation of RSerPool? 109 o ENRP servers denote the management systems in the context of 110 RSerPool. The term "server" is misleading, since ENRP servers are 111 actually ENRP peers. Literature on RSerPool -- for example [16] 112 -- therefore uses the more accurate term "Pool Registrar" (PR). A 113 future revision of RSerPool should also use this term. (The 114 RSerPool documents did not use "registrar" to avoid confusion with 115 SIP registrars.) 117 o Pool Element Identifiers (PE ID) and Pool Registrar 118 Identifiers (PR ID) are 32-bit random numbers used for the 119 identification of PEs and PRs. Since 64-bit CPUs are standard 120 since quite a long time, these IDs should be extended to 64 bits. 122 o ENRP uses the Internet-16 checksum defined in [9] to detect 123 handlespace inconsistencies. It is trivially possible to extend 124 the underlying algorithm to 32 bits, and the computation is more 125 efficient on today's CPUs. The checksum algorithm should 126 therefore be changed. (The Internet-16 checksum was finally 127 chosen in 2005 after long decisions to avoid any possible patent 128 issues. The trivial extension of Internet-16 to Internet-32 is 129 probably not an issue any more?) 131 o PR failures lead to possible concentration of all PUs and PEs at a 132 single PR. To achieve a better load balancing, the solution ENRP 133 Takeover Suggestion -- as defined in [14] -- should be included in 134 ENRP. 136 o For a Handle Resolution, a PR has to decide on how many PEs to 137 select. Selecting too many ones causes additional overhead (which 138 might be unnecessary), selecting too few ones may cause problems 139 for the applications. The extension Handle Resolution Option -- 140 defined in [12] -- provides a possibility for the PU to specify 141 the amount of PEs to be selected. This possibility should be 142 integrated into ASAP. 144 o RSerPool defines SCTP (defined in [10]) as transport protocol for 145 RSerPool. TCP and particularly Multi-Path TCP (MPTCP; see [11]) 146 should be possible further transport protocols for all RSerPool 147 traffic. SCTP should still be the recommended choice, but 148 allowing TCP/MPTCP could make the deployment much easier. (SCTP 149 is superior, but it lacks of support in operating systems and 150 support by underlying network infrastructure, like firewalls and 151 middleboxes.) 153 2.1. Security Considerations 155 Security considerations for RSerPool can be found in [6]. 157 2.2. IANA Considerations 159 This document introduces no additional considerations for IANA. 161 3. Reference Implementation 163 The RSerPool reference implementation RSPLIB, including example 164 applications, can be found at [22]. It supports the functionalities 165 defined by [2], [3], [4], [5] and [6] as well as the options [12], 166 [14] and [13]. An introduction to this implementation is provided in 167 [16]. 169 4. Testbed Platform 171 NorNet is a large-scale and realistic Internet testbed platform with 172 support for Reliable Server Pooling as well as the underlying 173 transport protocols SCTP and MPTCP. A description of and 174 introduction to NorNet is provided in [19], [20], [21]. Further 175 information can be found on the project website [23]. 177 5. Acknowledgments 179 The author would like to thank Randall R. Stewart, Michael Tuexen, 180 Ning Zong for their discussions and support. 182 6. References 184 6.1. Normative References 186 [1] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., 187 Loughney, J., and M. Stillman, "Requirements for Reliable 188 Server Pooling", RFC 3237, DOI 10.17487/RFC3237, January 189 2002, . 191 [2] Lei, P., Ong, L., Tuexen, M., and T. Dreibholz, "An 192 Overview of Reliable Server Pooling Protocols", RFC 5351, 193 DOI 10.17487/RFC5351, September 2008, 194 . 196 [3] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, 197 "Aggregate Server Access Protocol (ASAP)", RFC 5352, 198 DOI 10.17487/RFC5352, September 2008, 199 . 201 [4] Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. 202 Silverton, "Endpoint Handlespace Redundancy Protocol 203 (ENRP)", RFC 5353, DOI 10.17487/RFC5353, September 2008, 204 . 206 [5] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, 207 "Aggregate Server Access Protocol (ASAP) and Endpoint 208 Handlespace Redundancy Protocol (ENRP) Parameters", 209 RFC 5354, DOI 10.17487/RFC5354, September 2008, 210 . 212 [6] Stillman, M., Ed., Gopal, R., Guttman, E., Sengodan, S., 213 and M. Holdrege, "Threats Introduced by Reliable Server 214 Pooling (RSerPool) and Requirements for Security in 215 Response to Threats", RFC 5355, DOI 10.17487/RFC5355, 216 September 2008, . 218 [7] Dreibholz, T. and M. Tuexen, "Reliable Server Pooling 219 Policies", RFC 5356, DOI 10.17487/RFC5356, September 2008, 220 . 222 [8] Dreibholz, T. and J. Mulik, "Reliable Server Pooling MIB 223 Module Definition", RFC 5525, DOI 10.17487/RFC5525, April 224 2009, . 226 [9] Braden, R., Borman, D., and C. Partridge, "Computing the 227 Internet checksum", RFC 1071, DOI 10.17487/RFC1071, 228 September 1988, . 230 [10] Stewart, R., Ed., "Stream Control Transmission Protocol", 231 RFC 4960, DOI 10.17487/RFC4960, September 2007, 232 . 234 [11] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 235 "TCP Extensions for Multipath Operation with Multiple 236 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 237 . 239 [12] Dreibholz, T., "Handle Resolution Option for ASAP", draft- 240 dreibholz-rserpool-asap-hropt-25 (work in progress), 241 September 2019. 243 [13] Dreibholz, T. and X. Zhou, "Definition of a Delay 244 Measurement Infrastructure and Delay-Sensitive Least-Used 245 Policy for Reliable Server Pooling", draft-dreibholz- 246 rserpool-delay-24 (work in progress), September 2019. 248 [14] Dreibholz, T. and X. Zhou, "Takeover Suggestion Flag for 249 the ENRP Handle Update Message", draft-dreibholz-rserpool- 250 enrp-takeover-22 (work in progress), September 2019. 252 [15] Zong, N., Dunbar, L., Shore, M., Lopez, D., and G. 253 Karagiannis, "Virtualized Network Function (VNF) Pool 254 Problem Statement", draft-zong-vnfpool-problem- 255 statement-06 (work in progress), July 2014. 257 6.2. Informative References 259 [16] Dreibholz, T., "Reliable Server Pooling - Evaluation, 260 Optimization and Extension of a Novel IETF Architecture", 261 March 2007, . 265 [17] Dreibholz, T. and E. Rathgeb, "A Powerful Tool-Chain for 266 Setup, Distributed Processing, Analysis and Debugging of 267 OMNeT++ Simulations", Proceedings of the 1st ACM/ICST 268 International Workshop on OMNeT++ ISBN 978-963-9799-20-2, 269 DOI 10.4108/ICST.SIMUTOOLS2008.2990, March 2008, 270 . 273 [18] Dreibholz, T., "Evaluation and Optimisation of Multi-Path 274 Transport using the Stream Control Transmission 275 Protocol", Habilitation Treatise, March 2012, 276 . 280 [19] Dreibholz, T. and E. Gran, "Design and Implementation of 281 the NorNet Core Research Testbed for Multi-Homed Systems", 282 Proceedings of the 3nd International Workshop on Protocols 283 and Applications with Multi-Homing Support (PAMS) Pages 284 1094-1100, ISBN 978-0-7695-4952-1, 285 DOI 10.1109/WAINA.2013.71, March 2013, 286 . 290 [20] Dreibholz, T., "The NorNet Core Testbed - Introduction and 291 Status", Proceedings of the 1st International NorNet 292 Users Workshop (NNUW-1), September 2013, 293 . 295 [21] Dreibholz, T., "The NorNet Core Testbed - An Experiment 296 Tutorial", Proceedings of the 1st International NorNet 297 Users Workshop (NNUW-1), September 2013, 298 . 300 [22] Dreibholz, T., "Thomas Dreibholz's RSerPool Page", 301 Online: https://www.uni-due.de/~be0001/rserpool/, 2019, 302 . 304 [23] Dreibholz, T., "NorNet - A Real-World, Large-Scale Multi- 305 Homing Testbed", Online: https://www.nntb.no/, 2019, 306 . 308 Author's Address 310 Thomas Dreibholz 311 Simula Metropolitan Centre for Digital Engineering 312 Pilestredet 52 313 0167 Oslo, Oslo 314 Norway 316 Phone: +47-6782-8200 317 Fax: +47-6782-8201 318 Email: dreibh@simula.no 319 URI: https://www.simula.no/people/dreibh