idnits 2.17.1 draft-ietf-rserpool-policies-06.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 645. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 656. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 663. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 669. 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 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 (September 22, 2007) is 6053 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2434 (ref. '2') (Obsoleted by RFC 5226) == Outdated reference: A later version (-18) exists of draft-ietf-rserpool-common-param-12 == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-asap-16 == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-enrp-16 == Outdated reference: A later version (-15) exists of draft-ietf-rserpool-threats-08 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Tuexen 3 Internet-Draft Muenster Univ. of Applied Sciences 4 Intended status: Experimental T. Dreibholz 5 Expires: March 25, 2008 University of Duisburg-Essen 6 September 22, 2007 8 Reliable Server Pooling Policies 9 draft-ietf-rserpool-policies-06.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 March 25, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document describes server pool policies for Reliable Server 43 Pooling including considerations for implementing them at ENRP 44 servers and pool users. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 3. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 51 3.1. Load . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3.2. Weight . . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 4. Non-Adaptive Policies . . . . . . . . . . . . . . . . . . . . 5 54 4.1. Round Robin Policy . . . . . . . . . . . . . . . . . . . . 5 55 4.1.1. Description . . . . . . . . . . . . . . . . . . . . . 5 56 4.1.2. ENRP Server Considerations . . . . . . . . . . . . . . 5 57 4.1.3. Pool User Considerations . . . . . . . . . . . . . . . 5 58 4.1.4. Pool Member Selection Policy Parameter . . . . . . . . 5 59 4.2. Weighted Round Robin Policy . . . . . . . . . . . . . . . 6 60 4.2.1. Description . . . . . . . . . . . . . . . . . . . . . 6 61 4.2.2. ENRP Server Considerations . . . . . . . . . . . . . . 6 62 4.2.3. Pool User Considerations . . . . . . . . . . . . . . . 6 63 4.2.4. Pool Member Selection Policy Parameter . . . . . . . . 6 64 4.3. Random Policy . . . . . . . . . . . . . . . . . . . . . . 6 65 4.3.1. Description . . . . . . . . . . . . . . . . . . . . . 6 66 4.3.2. ENRP Server Considerations . . . . . . . . . . . . . . 6 67 4.3.3. Pool User Considerations . . . . . . . . . . . . . . . 7 68 4.3.4. Pool Member Selection Policy Parameter . . . . . . . . 7 69 4.4. Weighted Random Policy . . . . . . . . . . . . . . . . . . 7 70 4.4.1. Description . . . . . . . . . . . . . . . . . . . . . 7 71 4.4.2. ENRP Server Considerations . . . . . . . . . . . . . . 7 72 4.4.3. Pool User Considerations . . . . . . . . . . . . . . . 7 73 4.4.4. Pool Member Selection Policy Parameter . . . . . . . . 7 74 4.5. Priority Policy . . . . . . . . . . . . . . . . . . . . . 8 75 4.5.1. Description . . . . . . . . . . . . . . . . . . . . . 8 76 4.5.2. ENRP Server Considerations . . . . . . . . . . . . . . 8 77 4.5.3. Pool Element Considerations . . . . . . . . . . . . . 8 78 4.5.4. Pool Member Selection Policy Parameter . . . . . . . . 8 79 5. Adaptive Policies . . . . . . . . . . . . . . . . . . . . . . 9 80 5.1. Least Used Policy . . . . . . . . . . . . . . . . . . . . 9 81 5.1.1. Description . . . . . . . . . . . . . . . . . . . . . 9 82 5.1.2. ENRP Server Considerations . . . . . . . . . . . . . . 9 83 5.1.3. Pool User Considerations . . . . . . . . . . . . . . . 9 84 5.1.4. Pool Member Selection Policy Parameter . . . . . . . . 9 85 5.2. Least Used with Degradation Policy . . . . . . . . . . . . 9 86 5.2.1. Description . . . . . . . . . . . . . . . . . . . . . 9 87 5.2.2. ENRP Server Considerations . . . . . . . . . . . . . . 10 88 5.2.3. Pool User Considerations . . . . . . . . . . . . . . . 10 89 5.2.4. Pool Member Selection Policy Parameter . . . . . . . . 10 90 5.3. Priority Least Used Policy . . . . . . . . . . . . . . . . 10 91 5.3.1. Description . . . . . . . . . . . . . . . . . . . . . 10 92 5.3.2. ENRP Server Considerations . . . . . . . . . . . . . . 11 93 5.3.3. Pool User Considerations . . . . . . . . . . . . . . . 11 94 5.3.4. Pool Member Selection Policy Parameter . . . . . . . . 11 95 5.4. Randomized Least Used Policy . . . . . . . . . . . . . . . 11 96 5.4.1. Description . . . . . . . . . . . . . . . . . . . . . 11 97 5.4.2. ENRP Server Considerations . . . . . . . . . . . . . . 12 98 5.4.3. Pool User Considerations . . . . . . . . . . . . . . . 12 99 5.4.4. Pool Member Selection Policy Parameter . . . . . . . . 12 100 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 101 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 102 7.1. A New Table for RSerPool Policy Types . . . . . . . . . . 12 103 8. Reference Implementation . . . . . . . . . . . . . . . . . . . 14 104 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 105 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 106 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 108 Intellectual Property and Copyright Statements . . . . . . . . . . 16 110 1. Introduction 112 The protocols defined in ENRP [5], ASAP [4] and Parameters [3] 113 support a variety of server policies. Some of the policies use 114 dynamic load information of the pool elements and others do not. 115 Therefore, we classify them as adaptive and non-adaptive. The 116 selection of the pool user is performed by two different entities. 117 Some of the consequences for policies which are not stateless are 118 described in Performance [8]. 120 Therefore this document describes not only packet formats but also 121 gives a detailed description of the procedures to be followed at the 122 ENRP servers and the pool users to implement each server policy. 124 2. Conventions 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC2119 [1]. 130 3. Terminology and Definitions 132 3.1. Load 134 The term load is a value specifying how much a pool element's 135 resources are currently utilized. 0x00000000 states, that the pool 136 element is not utilized (0%), 0xffffffff states that it is fully 137 utilized (100%). Defining what utilization means is application- 138 dependent and out of the scope of RSerPool. However, it is required 139 that all pool elements of the same pool using load information have 140 the same definition of load. 142 For example, load may define the current amount of users out of a 143 maximum on a FTP server, the CPU usage of a database server or the 144 memory utilization of a compute service. 146 3.2. Weight 148 Weight defines a pool element's service capacity relatively to other 149 pool elements of the same pool. Theoretically, there is no upper 150 limit for weight values (although limited by datatype size). 151 Defining what value weights compare is application-dependent and out 152 of the scope of RSerPool. However, it is required that all pool 153 elements of the same pool using weight information have the same 154 definition of weight. 156 A weight of 0 denotes that the pool element is not capable of 157 providing any service, a weight of 2*n denotes that the pool element 158 is capable of providing a two times better service than a pool 159 element having weight n. 161 For example, weight may define a compute service's computation 162 capacity. That is, a pool element of weight 100 will complete a work 163 package in half of the time compared to a pool element of weight 50. 165 4. Non-Adaptive Policies 167 4.1. Round Robin Policy 169 4.1.1. Description 171 The Round Robin (RR) policy is a very simple and efficient policy 172 which requires state. This policy is denoted as the default policy 173 and MUST be supported by all RSerPool components. 175 4.1.2. ENRP Server Considerations 177 The ENRP server SHOULD hold the pool elements of each server pool in 178 a circular list and SHOULD store a pointer to one of the elements, 179 called the head. On reception of a handle resolution request the 180 ENRP server SHOULD return the pool elements from the circular list 181 starting with head. Then head SHOULD be advanced by one element. 183 Using this algorithm it is made sure that not all lists presented to 184 the pool users start with the same element. 186 4.1.3. Pool User Considerations 188 A pool user SHOULD use the list of pool elements returned by the ENRP 189 server in a round robin fashion, starting with the first. If all 190 elements of the list have been used it should start from the 191 beginning again until the information is out of date. 193 4.1.4. Pool Member Selection Policy Parameter 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Param Type = 0x6 | Length = 0x8 | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Policy Type = 0x00000001 | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 4.2. Weighted Round Robin Policy 205 4.2.1. Description 207 The Weighted Round Robin (WRR) policy is a generalization of the RR 208 policy. If all weights are 1 then WRR is just RR. 210 4.2.2. ENRP Server Considerations 212 The ENRP server SHOULD follow the same rules as for RR but initialize 213 and modify the circular list differently. The ENRP server puts each 214 pool element possibly multiple times into the list such that: 215 o The ratio of the number of occurrences of a pool element to the 216 list length is the same as the ratio of the weight of that pool 217 element to the sum of weights. 218 o Each pool element is inserted as distributed as possible in the 219 circular list. 221 4.2.3. Pool User Considerations 223 The pool user SHOULD follow the same rules as for RR. 225 4.2.4. Pool Member Selection Policy Parameter 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Param Type = 0x6 | Length = 0xc | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Policy Type = 0x00000002 | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Weight | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 o Weight: Weight constant for the WRR process. 239 4.3. Random Policy 241 4.3.1. Description 243 The Random (RAND) policy is a very simple stateless policy. 245 4.3.2. ENRP Server Considerations 247 The ENRP server selects at most the requested number of pool elements 248 from the list of pool elements. Each element MUST NOT be reported 249 more than once to the pool user. 251 4.3.3. Pool User Considerations 253 Each time the pool user must select one pool element it does this by 254 randomly selecting one element from the list of pool elements 255 received from the ENRP server. 257 4.3.4. Pool Member Selection Policy Parameter 259 0 1 2 3 260 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 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Param Type = 0x6 | Length = 0x8 | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Policy Type = 0x00000003 | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 4.4. Weighted Random Policy 269 4.4.1. Description 271 The Weighted Random (WRAND) policy is a generalization of the RAND 272 policy, adding a weight for each pool element entry. RAND is equal 273 to WRAND having all weights set to 1. 275 4.4.2. ENRP Server Considerations 277 The ENRP server SHOULD select at most the requested number of pool 278 elements randomly from the list of pool elements. Each element MUST 279 NOT be reported more than once to the pool user. The probability of 280 selecting a pool element should be the ratio of the weight of that 281 pool element to the sum of weights. 283 4.4.3. Pool User Considerations 285 Each time the pool user must select one pool element it does this by 286 randomly selecting one element from the list of pool elements 287 received from the ENRP server. 289 4.4.4. Pool Member Selection Policy Parameter 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Param Type = 0x6 | Length = 0xc | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Policy Type = 0x00000004 | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Weight | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 o Weight: Weight constant for the WRAND process. 302 4.5. Priority Policy 304 4.5.1. Description 306 The Priority (PRIO) policy can be used to select always a pool 307 element with the highest priority. 309 4.5.2. ENRP Server Considerations 311 The ENRP server MUST select the pool elements with the highest 312 priorities. They MUST be reported in decreasing order. If multiple 313 pool elements have the same priority, they may be listed in any 314 order. 316 4.5.3. Pool Element Considerations 318 The pool user MUST select the active pool element with the highest 319 priority. 321 4.5.4. Pool Member Selection Policy Parameter 323 0 1 2 3 324 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 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Param Type = 0x6 | Length = 0xc | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Policy Type = 0x00000005 | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Priority | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 o Priority: 32 bits, unsigned int. Larger numbers mean higher 334 priorities. 336 5. Adaptive Policies 338 5.1. Least Used Policy 340 5.1.1. Description 342 The Least Used (LU) policy uses load information provided by the pool 343 elements to select the lowest-loaded pool elements within the pool. 345 5.1.2. ENRP Server Considerations 347 The ENRP server SHOULD select at most the requested number of pool 348 elements. Their load values SHOULD be the lowest possible ones 349 within the pool. Each element MUST NOT be reported more than once to 350 the pool user. If there is a choice of equal-loaded pool elements, 351 round robin selection SHOULD be made among these elements. The 352 returned list of pool elements MUST be sorted ascending by load 353 value. 355 5.1.3. Pool User Considerations 357 The pool user should try to use the pool elements returned from the 358 list in the order returned by the ENRP server. A subsequent call for 359 handle resolution may result in the same list. Thereofore, it is 360 RECOMMENDED for a pool user to request multiple entries in order to 361 have a sufficient amount of feasible backup entries available. 363 5.1.4. Pool Member Selection Policy Parameter 365 0 1 2 3 366 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 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Param Type = 0x6 | Length = 0xc | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Policy Type = 0x40000001 | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Load | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 o Load: Current load of the pool element. 377 5.2. Least Used with Degradation Policy 379 5.2.1. Description 381 The Least Used with Degradation (LUD) policy extends the LU policy by 382 a load degradation value describing the pool element's load increment 383 when a new service association is accepted. 385 5.2.2. ENRP Server Considerations 387 For every pool element entry, a degradation counter MUST be stored. 388 When a pool element entry is added or updated by registration or 389 reregistration, this counter MUST be set to 0. When an entry is 390 selected for being returned to a pool user, the internal degradation 391 counter MUST be incremented by the entry's load degradation constant. 392 The selection of pool element entries is handled like for LU, except 393 that the selected pool element entries SHOULD have the lowest 394 possible sum of load value + degradation counter. 396 5.2.3. Pool User Considerations 398 See LU policy. 400 5.2.4. Pool Member Selection Policy Parameter 402 0 1 2 3 403 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 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Param Type = 0x6 | Length = 0x10 | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Policy Type = 0x40000002 | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Load | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Load Degradation | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 o Load: Current load of the pool element. 415 o Load Degradation: Load Degradation constant of the pool element. 417 5.3. Priority Least Used Policy 419 5.3.1. Description 421 The Priority Least Used (PLU) policy uses load information provided 422 by the pool elements to select the lowest-loaded pool elements within 423 the pool under the assumption that a new application request is 424 accepted by the pool elements. Therefore, the pool elements also 425 have to specify load degradation information. 427 Example: Pool elements A and B are loaded by 50%, but the load of A 428 will increase due to a new application request only by 10% while B 429 will be fully loaded. PLU allows to specify this load degradation in 430 the policy information, the selection is made on the lowest sum of 431 load and degradation value. That is, A will be selected (50+10=60) 432 instead of B (50+50=100). 434 5.3.2. ENRP Server Considerations 436 The ENRP server SHOULD select at most the requested number of pool 437 elements. Their sums of load + degradation SHOULD be the lowest 438 possible ones within the pool. Each element MUST NOT be reported 439 more than once to the pool user. If there is a choice of equal- 440 valued pool element entries, round robin SHOULD be made among these 441 elements. The returned list of pool elements MUST be sorted 442 ascending by the sum of load and degradation value. 444 5.3.3. Pool User Considerations 446 The pool user should try to use the pool elements returned from the 447 list in the order returned by the ENRP server. A subsequent call for 448 handle resolution may result in the same list. Therefore, it is 449 RECOMMENDED for a pool user to request multiple entries in order to 450 have a sufficient amount of feasible backup entries available. 452 5.3.4. Pool Member Selection Policy Parameter 454 0 1 2 3 455 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 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Param Type = 0x6 | Length = 0x10 | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Policy Type = 0x40000003 | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Load | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Load Degradation | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 o Load: Current load of the pool element. 467 o Load Degradation: Load Degradation constant of the pool element. 469 5.4. Randomized Least Used Policy 471 5.4.1. Description 473 The Randomized Least Used (RLU) policy combines LU and WRAND. That 474 is, the pool element entries are selected randomly; the probability 475 for a pool element entry to be selected is the ratio of 100%-load to 476 the sum of all pool elements' load values. 478 5.4.2. ENRP Server Considerations 480 The ENRP server SHOULD behave like WRAND, having every PE's weight 481 set to (0xffffffff - Load value provided by the pool element). 483 5.4.3. Pool User Considerations 485 See WRAND policy. 487 5.4.4. Pool Member Selection Policy Parameter 489 0 1 2 3 490 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 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Param Type = 0x7 | Length = 0xc | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Policy Type = 0x40000004 | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Load | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 o Load: Current load of the pool element. 501 6. Security Considerations 503 The security threats regarding RSerPool have been analyzed in 504 RSerPool threats [6]. The server policy descriptions in this 505 document do not add any other threats. 507 7. IANA Considerations 509 [NOTE to RFC-Editor: 510 "RFCXXXX" is to be replaced by the RFC number you assign this 511 document. 512 ] 514 This document (RFCXXX) is the reference for all registrations 515 described in this section. All registrations need to be listed on an 516 RSerPool specific page. 518 7.1. A New Table for RSerPool Policy Types 520 RSerPool Policy Types which are 4 byte values have to be maintained 521 by IANA. The format of the policy type value is defined as follows: 523 0 1 2 3 524 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 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 |X|A| Policy Number | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 o X: If set to 1, the policy is user-defined and not standardized. 530 All standards policies reserved by the IETF use X=0. 531 o A: If set to 1, the policy is adaptive. Otherwise, it is non- 532 adaptive. 533 o Policy Number: The actual number of the policy. 535 Nine initial Policy Types should be assigned and maintained in a new 536 table "RSerPool Policy Types": 538 Value Policy Reference 539 ----- --------- --------- 540 0x00000000 (reserved by IETF) RFCXXXX 541 0x00000001 Round Robin RFCXXXX 542 0x00000002 Weighted Round Robin RFCXXXX 543 0x00000003 Random RFCXXXX 544 0x00000004 Weighted Random RFCXXXX 545 0x00000005 Priority RFCXXXX 546 0x00000006 (reserved by IETF) RFCXXXX 547 ... 548 0x3fffffff (reserved by IETF) RFCXXXX 550 0x40000000 (reserved by IETF) RFCXXXX 551 0x40000001 Least Used RFCXXXX 552 0x40000002 Least Used with Degradation RFCXXXX 553 0x40000003 Priority Least Used RFCXXXX 554 0x40000004 Randomized Least Used RFCXXXX 555 0x40000005 (reserved by IETF) RFCXXXX 556 ... 557 0x7fffffff (reserved by IETF) RFCXXXX 559 0x80000000 (user-defined, non-standard policy) RFCXXXX 560 ... 561 0xffffffff (user-defined, non-standard policy) RFCXXXX 563 For registering at IANA an RSerPool Policy Type in this table a 564 request has to be made to assign such a number. This number must be 565 unique and use the appropiate upper bits. The "Specification 566 Required" policy of RFC2434 [2] MUST be applied. 568 8. Reference Implementation 570 The reference implementation of RSerPool and the policies described 571 in this document is available at [7]. 573 9. References 575 9.1. Normative References 577 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 578 Levels", BCP 14, RFC 2119, March 1997. 580 [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 581 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 583 [3] Stewart, R., "Aggregate Server Access Protocol (ASAP) and 584 Endpoint Handlespace Redundancy Protocol (ENRP) Parameters", 585 draft-ietf-rserpool-common-param-12 (work in progress), 586 July 2007. 588 [4] Stewart, R., "Aggregate Server Access Protocol (ASAP)", 589 draft-ietf-rserpool-asap-16 (work in progress), July 2007. 591 [5] Stewart, R., "Endpoint Handlespace Redundancy Protocol (ENRP)", 592 draft-ietf-rserpool-enrp-16 (work in progress), July 2007. 594 [6] Gopal, R., Guttman, E., Holdrege, M., Sengodan, S., and M. 595 Stillman, "Threats Introduced by Rserpool and Requirements for 596 Security in response to Threats", 597 draft-ietf-rserpool-threats-08 (work in progress), 598 September 2007. 600 9.2. Informative References 602 [7] Dreibholz, T., "Thomas Dreibholz's RSerPool Page", 603 URL: http://tdrwww.exp-math.uni-essen.de/dreibholz/rserpool/. 605 [8] Dreibholz, T., Rathgeb, E., and M. Tuexen, "Load Distribution 606 Performance of the Reliable Server Pooling Framework", 607 Proceedings of the 4th IEEE International Conference on 608 Networking, April 2005. 610 Authors' Addresses 612 Michael Tuexen 613 Muenster University of Applied Sciences 614 Stegerwaldstrasse 39 615 48565 Steinfurt 616 Germany 618 Email: tuexen@fh-muenster.de 620 Thomas Dreibholz 621 University of Duisburg-Essen, Institute for Experimental Mathematics 622 Ellernstrasse 29 623 45326 Essen, Nordrhein-Westfalen 624 Germany 626 Phone: +49 201 183-7637 627 Fax: +49 201 183-7673 628 Email: dreibh@exp-math.uni-essen.de 629 URI: http://www.exp-math.uni-essen.de/~dreibh/ 631 Full Copyright Statement 633 Copyright (C) The IETF Trust (2007). 635 This document is subject to the rights, licenses and restrictions 636 contained in BCP 78, and except as set forth therein, the authors 637 retain all their rights. 639 This document and the information contained herein are provided on an 640 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 641 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 642 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 643 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 644 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 645 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 647 Intellectual Property 649 The IETF takes no position regarding the validity or scope of any 650 Intellectual Property Rights or other rights that might be claimed to 651 pertain to the implementation or use of the technology described in 652 this document or the extent to which any license under such rights 653 might or might not be available; nor does it represent that it has 654 made any independent effort to identify any such rights. Information 655 on the procedures with respect to rights in RFC documents can be 656 found in BCP 78 and BCP 79. 658 Copies of IPR disclosures made to the IETF Secretariat and any 659 assurances of licenses to be made available, or the result of an 660 attempt made to obtain a general license or permission for the use of 661 such proprietary rights by implementers or users of this 662 specification can be obtained from the IETF on-line IPR repository at 663 http://www.ietf.org/ipr. 665 The IETF invites any interested party to bring to its attention any 666 copyrights, patents or patent applications, or other proprietary 667 rights that may cover technology that may be required to implement 668 this standard. Please address the information to the IETF at 669 ietf-ipr@ietf.org. 671 Acknowledgment 673 Funding for the RFC Editor function is provided by the IETF 674 Administrative Support Activity (IASA).