idnits 2.17.1 draft-dreibholz-rserpool-score-03.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, updated by RFC 4748 on line 411. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 422. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 429. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 435. 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 : ---------------------------------------------------------------------------- ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (July 11, 2008) is 5767 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-rserpool-arch' is defined on line 300, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rserpool-enrp' is defined on line 310, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rserpool-policies' is defined on line 323, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rserpool-service' is defined on line 328, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rserpool-api' is defined on line 333, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rserpool-threats' is defined on line 338, but no explicit reference was found in the text == Unused Reference: 'I-D.dreibholz-rserpool-applic-distcomp' is defined on line 345, but no explicit reference was found in the text == Unused Reference: 'I-D.coene-rserpool-applic-ipfix' is defined on line 351, but no explicit reference was found in the text == Unused Reference: 'I-D.dreibholz-rserpool-applic-mobility' is defined on line 357, but no explicit reference was found in the text == Unused Reference: 'RSerPoolPage' is defined on line 365, but no explicit reference was found in the text == Unused Reference: 'Dre2006' is defined on line 369, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-asap-20 == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-enrp-20 == Outdated reference: A later version (-18) exists of draft-ietf-rserpool-common-param-17 == Outdated reference: A later version (-10) exists of draft-ietf-rserpool-policies-09 == Outdated reference: A later version (-15) exists of draft-ietf-rserpool-threats-14 == Outdated reference: A later version (-36) exists of draft-dreibholz-rserpool-applic-distcomp-04 == Outdated reference: A later version (-20) exists of draft-coene-rserpool-applic-ipfix-05 == Outdated reference: A later version (-35) exists of draft-dreibholz-rserpool-applic-mobility-03 Summary: 2 errors (**), 0 flaws (~~), 20 warnings (==), 7 comments (--). 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: Informational M. Tuexen 5 Expires: January 12, 2009 Univ. of Applied Sciences Muenster 6 July 11, 2008 8 Reliable Server Pooling (RSerPool) Bakeoff Scoring 9 draft-dreibholz-rserpool-score-03.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 January 12, 2009. 36 Abstract 38 This memo describes some of the scoring to be used in the testing of 39 Reliable Server Pooling protocols ASAP and ENRP at upcoming bakeoffs. 41 Table of Contents 43 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 44 2. Aggregate Server Access Protocol . . . . . . . . . . . . . . . 3 45 2.1. Pool Element Communication . . . . . . . . . . . . . . . . 3 46 2.2. Pool User Communication . . . . . . . . . . . . . . . . . 4 47 2.3. ENRP Server Communication . . . . . . . . . . . . . . . . 4 48 3. Endpoint Handlespace Redundancy Protocol . . . . . . . . . . . 5 49 3.1. Peer Management . . . . . . . . . . . . . . . . . . . . . 5 50 3.2. Update . . . . . . . . . . . . . . . . . . . . . . . . . . 6 51 3.3. Synchronization . . . . . . . . . . . . . . . . . . . . . 6 52 3.4. Takeover . . . . . . . . . . . . . . . . . . . . . . . . . 7 53 4. Bonus Points . . . . . . . . . . . . . . . . . . . . . . . . . 7 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 55 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 56 6.1. Normative References . . . . . . . . . . . . . . . . . . . 8 57 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 59 Intellectual Property and Copyright Statements . . . . . . . . . . 11 61 1. Introduction 63 This document will be used as a basis for point scoring at upcoming 64 RSerPool bakeoffs. Its purpose is similar to that described in 65 RFC1025. It is hoped that a clear definition of where and how to 66 score points will further the development of RSerPool. 68 Note that while attending a bakeoff no one else will score your 69 points for you. We trust that all implementations will faithfully 70 record their points that are received honestly. Note also that these 71 scores are NOT to be used for marketing purposes. They are for the 72 use of the implementations to know how well they are doing. The only 73 reporting that will be done is a basic summary to the Reliable Server 74 Pooling Working Group but please note that NO company or 75 implementation names will be attached. 77 2. Aggregate Server Access Protocol 79 The ASAP protocol is described in the follwing documents: 81 o draft-ietf-rserpool-asap [I-D.ietf-rserpool-asap] 83 o draft-ietf-rserpool-common-param [I-D.ietf-rserpool-common-param] 85 2.1. Pool Element Communication 87 These points will be scored for EACH peer implementation that you 88 successfully communicate with. 90 o 2 Successful ASAP Registration Request of a PE in a pool using 91 Round Robin policy and handling of ASAP Registration Response. 93 o 2 Failing ASAP Registration Request of a PE requesting Least Used 94 policy in a pool using Round Robin policy and appropriate handling 95 of ASAP Registration Response (e.g. printing error message, but 96 not retrying registration). 98 o 2 Successful re-registration of a PE in a pool using Round Robin 99 policy. 101 o 2 Successful ASAP Deregistration Request of the PE from its pool 102 and handling of ASAP Deregistration Response. 104 o 2 Successful handling of ASAP Endpoint Keep-Alive without Home bit 105 set, i.e. answering with ASAP Endpoint Keep-Alive Ack. 107 o 5 Successful handling of ASAP Endpoint Keep-Alive with Home bit 108 set: respond with ASAP Endpoint Keep-Alive Ack and use new ENRP 109 server for re-registration. 111 o 5 Successful connection to and registration at an ENRP server 112 announcing itself via multicast ASAP Announces. 114 o 1 Successful registration into pool using Least Used policy. 116 o 1 Successful registration into pool using Weighted Round Robin 117 policy. 119 o 1 Successful registration into pool using Random policy. 121 o 1 Successful registration into pool using Weighted Random policy. 123 2.2. Pool User Communication 125 These points will be scored for EACH peer implementation that you 126 successfully communicate with. 128 o 5 Successful ASAP Handle Resolution in a pool using Round Robin 129 policy, correct handling of ASAP Handle Resolution Response. 131 o 2 Successful failure reporting using ASAP Endpoint Unreachable. 133 o 5 Successful connection to and handle resolution at ENRP server 134 announcing itself via multicast ASAP Announces. 136 o 1 Successful handle resolution in a pool using Least Used policy. 138 o 1 Successful handle resolution in a pool using Weighted Round 139 Robin policy. 141 o 1 Successful handle resolution in a pool using Random policy. 143 o 1 Successful handle resolution in a pool using Weighted Random 144 policy. 146 2.3. ENRP Server Communication 148 These points will be scored for EACH peer implementation that you 149 successfully communicate with. 151 o 2 Successful handling of an ASAP Registration Request into a pool 152 using Round Robin policy (ENRP server answers with successful ASAP 153 Registration Response). 155 o 2 Rejecting registration of a PE requesting Round Robin policy 156 into a pool using Least Used policy. 158 o 5 Rejecting registration of a PE with all addresses *not* being 159 part of the ASAP association. 161 o 5 Successful registration of a PE with some addresses *not* being 162 part of the ASAP association. The invalid addresses may *not* go 163 into the handlespace. 165 o 5 Successful handling of ASAP Endpoint Unreachable messages. The 166 ENRP server must remove the given PE after MAX-BAD-PE-REPORTS=3 167 unreachability reports. 169 o 2 Sending regular ASAP Endpoint Keep-Alives to its PEs. 171 o 2 Removing PE not answering to ASAP Endpoint Keep-Alive. 173 3. Endpoint Handlespace Redundancy Protocol 175 The ENRP protocol is described in the follwing documents: 177 o draft-ietf-rserpool-enrp [I-D.ietf-rserpool-asap] 179 o draft-ietf-rserpool-common-param [I-D.ietf-rserpool-common-param] 181 3.1. Peer Management 183 These points will be scored for EACH peer implementation that you 184 successfully communicate with. 186 o 2 Sending ENRP Presence to a new ENRP server. 188 o 2 Sending ENRP Presences in the interval given by PEER-HEARTBEAT- 189 CYCLE. 191 o 5 Requesting peer list from new ENRP server using ENRP Peer List 192 Request, handling ENRP Peer List Response and adding entries to 193 its own peer list. 195 o 2 Handling ENRP Peer List Request and replying with own peer list 196 in ENRP Peer List Response. 198 o 5 Requesting handlespace from new ENRP server using ENRP Handle 199 Table Request, handling ENRP Handle Table Response (without M-bit 200 set) and inserting entries into its own handlespace copy. 202 o 5 Requesting handlespace from new ENRP server using ENRP Handle 203 Table Request, handling ENRP Handle Table Response with M-bit set, 204 requesting more entries and inserting entries into its own 205 handlespace copy. 207 o 2 Handling ENRP Handle Table Request and replying own handlespace 208 in ENRP Handle Table Response (without M-bit). 210 o 10 Handling ENRP Handle Table Request and replying own handlespace 211 in ENRP Handle Table Response with M-bit set, remembering point to 212 continue from, responding next block of handlespace entries upon 213 following ENRP Handle Table Request, etc. until transfer of 214 handlespace data is complete. 216 o 5 Successful addition of new ENRP server announcing itself via 217 multicast ENRP Presence (including association establishment as 218 well as download of peer list and handlespace). 220 3.2. Update 222 These points will be scored for EACH peer implementation that you 223 successfully communicate with. 225 o 2 Handling an ENRP Handle Update adding a PE. 227 o 2 Handling an ENRP Handle Update updating a PE. The changes must 228 be entered into the local handlespace copy. 230 o 2 Handling an ENRP Handle Update removing a PE. 232 3.3. Synchronization 234 These points will be scored for EACH peer implementation that you 235 successfully communicate with. 237 o 5 Successful detection of different handlespace checksums upon 238 reception of ENRP Presence (due to additional PE), request of 239 Handle Table with W-bit set, integration of missing PE into local 240 handlespace copy and reporting the correct checksum in own ENRP 241 Presence. 243 o 5 Successful detection of different handlespace checksums upon 244 reception of ENRP Presence (due to out-of-date PE), request of 245 Handle Table with W-bit set, removal of PE from local handlespace 246 copy and reporting the correct checksum in own ENRP Presence. 248 o 10 Successful detection of different handlespace checksums upon 249 reception of ENRP Presence (due to multiple new and out-of-date PE 250 identities; size of PE identities is larger than maximum ENRP 251 message size), request of Handle Table with W-bit set, handling of 252 ENRP Handle Table Responses with M-bit set, removal of out-of-date 253 PEs, integration of new PEs into the local handlespace copy and 254 reporting correct checksum in own ENRP Presence. 256 3.4. Takeover 258 These points will be scored for EACH peer implementation that you 259 successfully communicate with. The setup contains your ENRP server 260 plus a set of peers running another implementation. 262 o 5 Successfully detecting the failure of a remote peer and 263 initiating a takeover procedure. 265 o 5 Acknowledging another peer's takeover and aborting own takeover 266 procedure. 268 o 10 Correctly handling a remote peer's Takeover Server message, 269 including ownership change for the remote peer's PEs. 271 o 10 Successfully taking over a dead peer, including ownership 272 change and informing the PEs taken over. 274 4. Bonus Points 276 You can also earn Bonus Points: 278 o 20 points for the ENRP server handling the largest number of PEs. 280 o 20 points for the ENRP server achieving the highest handle 281 resolution throughput for a pool containing 100 (should this be 282 larger?) PEs. 284 Please note that the whole period of the bakeoff is relevant. 286 5. Security Considerations 288 This document does only describe test scenarios and therefore does 289 not introduce any new security issues. 291 For security considerations of the protocols see 292 draft-ietf-rserpool-asap [I-D.ietf-rserpool-asap], 293 draft-ietf-rserpool-enrp [I-D.ietf-rserpool-asap], and 294 draft-ietf-rserpool-common-param [I-D.ietf-rserpool-common-param]. 296 6. References 298 6.1. Normative References 300 [I-D.ietf-rserpool-arch] 301 Tuexen, M., "Architecture for Reliable Server Pooling", 302 draft-ietf-rserpool-arch-12 (work in progress), 303 November 2006. 305 [I-D.ietf-rserpool-asap] 306 Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, 307 "Aggregate Server Access Protocol (ASAP)", 308 draft-ietf-rserpool-asap-20 (work in progress), May 2008. 310 [I-D.ietf-rserpool-enrp] 311 Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. 312 Silverton, "Endpoint Handlespace Redundancy Protocol 313 (ENRP)", draft-ietf-rserpool-enrp-20 (work in progress), 314 May 2008. 316 [I-D.ietf-rserpool-common-param] 317 Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, 318 "Aggregate Server Access Protocol (ASAP) and Endpoint 319 Handlespace Redundancy Protocol (ENRP) Parameters", 320 draft-ietf-rserpool-common-param-17 (work in progress), 321 May 2008. 323 [I-D.ietf-rserpool-policies] 324 Tuexen, M. and T. Dreibholz, "Reliable Server Pooling 325 Policies", draft-ietf-rserpool-policies-09 (work in 326 progress), May 2008. 328 [I-D.ietf-rserpool-service] 329 Conrad, P. and P. Lei, "Services Provided By Reliable 330 Server Pooling", draft-ietf-rserpool-service-02 (work in 331 progress), October 2005. 333 [I-D.ietf-rserpool-api] 334 Silverton, A., "Reliable Server Pooling Sockets API 335 Extensions", draft-ietf-rserpool-api-00 (work in 336 progress), October 2005. 338 [I-D.ietf-rserpool-threats] 339 Stillman, M., Gopal, R., Guttman, E., Holdrege, M., and S. 340 Sengodan, "Threats Introduced by RSerPool and Requirements 341 for Security in Response to Threats", 342 draft-ietf-rserpool-threats-14 (work in progress), 343 June 2008. 345 [I-D.dreibholz-rserpool-applic-distcomp] 346 Dreibholz, T., "Applicability of Reliable Server Pooling 347 for Real-Time Distributed Computing", 348 draft-dreibholz-rserpool-applic-distcomp-04 (work in 349 progress), January 2008. 351 [I-D.coene-rserpool-applic-ipfix] 352 Coene, L., "Reliable Server Pooling Applicability for IP 353 Flow Information Exchange", 354 draft-coene-rserpool-applic-ipfix-05 (work in progress), 355 January 2008. 357 [I-D.dreibholz-rserpool-applic-mobility] 358 Dreibholz, T. and J. Pulinthanath, "Applicability of 359 Reliable Server Pooling for SCTP-Based Endpoint Mobility", 360 draft-dreibholz-rserpool-applic-mobility-03 (work in 361 progress), January 2008. 363 6.2. Informative References 365 [RSerPoolPage] 366 Dreibholz, T., "Thomas Dreibholz's RSerPool Page", URL: 367 http://tdrwww.exp-math.uni-essen.de/dreibholz/rserpool/. 369 [Dre2006] Dreibholz, T., "Reliable Server Pooling -- Evaluation, 370 Optimization and Extension of a Novel IETF Architecture", 371 Ph.D. Thesis University of Duisburg-Essen, Faculty of 372 Economics, Institute for Computer Science and Business 373 Information Systems, URL: http:// 374 duepublico.uni-duisburg-essen.de/servlets/DerivateServlet/ 375 Derivate-16326/Dre2006-final.pdf, March 2007. 377 Authors' Addresses 379 Thomas Dreibholz 380 University of Duisburg-Essen, Institute for Experimental Mathematics 381 Ellernstrasse 29 382 45326 Essen, Nordrhein-Westfalen 383 Germany 385 Phone: +49-201-1837637 386 Fax: +49-201-1837673 387 Email: dreibh@iem.uni-due.de 388 URI: http://www.iem.uni-due.de/~dreibh/ 389 Michael Tuexen 390 University of Applied Sciences Muenster 391 Stegerwaldstrasse 39 392 48565 Steinfurt, Nordrhein-Westfalen 393 Germany 395 Email: tuexen@fh-muenster.de 397 Full Copyright Statement 399 Copyright (C) The IETF Trust (2008). 401 This document is subject to the rights, licenses and restrictions 402 contained in BCP 78, and except as set forth therein, the authors 403 retain all their rights. 405 This document and the information contained herein are provided on an 406 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 407 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 408 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 409 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 410 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 411 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 413 Intellectual Property 415 The IETF takes no position regarding the validity or scope of any 416 Intellectual Property Rights or other rights that might be claimed to 417 pertain to the implementation or use of the technology described in 418 this document or the extent to which any license under such rights 419 might or might not be available; nor does it represent that it has 420 made any independent effort to identify any such rights. Information 421 on the procedures with respect to rights in RFC documents can be 422 found in BCP 78 and BCP 79. 424 Copies of IPR disclosures made to the IETF Secretariat and any 425 assurances of licenses to be made available, or the result of an 426 attempt made to obtain a general license or permission for the use of 427 such proprietary rights by implementers or users of this 428 specification can be obtained from the IETF on-line IPR repository at 429 http://www.ietf.org/ipr. 431 The IETF invites any interested party to bring to its attention any 432 copyrights, patents or patent applications, or other proprietary 433 rights that may cover technology that may be required to implement 434 this standard. Please address the information to the IETF at 435 ietf-ipr@ietf.org.