idnits 2.17.1 draft-ietf-rserpool-policies-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 on line 571. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 582. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 589. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 595. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 24, 2006) is 6417 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '1' is defined on line 493, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 496, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 519, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 523, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 527, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3668 (ref. '2') (Obsoleted by RFC 3979) == Outdated reference: A later version (-18) exists of draft-ietf-rserpool-common-param-10 == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-asap-13 == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-enrp-13 == Outdated reference: A later version (-15) exists of draft-ietf-rserpool-threats-05 Summary: 4 errors (**), 0 flaws (~~), 11 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: Informational T. Dreibholz 5 Expires: March 28, 2007 University of Duisburg-Essen 6 September 24, 2006 8 Reliable Server Pooling Policies 9 draft-ietf-rserpool-policies-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 March 28, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 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. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 50 2.1. Load . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 2.2. Weight . . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Non-Adaptive Policies . . . . . . . . . . . . . . . . . . . . 5 53 3.1. Round Robin Policy . . . . . . . . . . . . . . . . . . . . 5 54 3.1.1. Description . . . . . . . . . . . . . . . . . . . . . 5 55 3.1.2. ENRP Server Considerations . . . . . . . . . . . . . . 5 56 3.1.3. Pool User Considerations . . . . . . . . . . . . . . . 5 57 3.1.4. Pool Member Selection Policy Parameter . . . . . . . . 5 58 3.2. Weighted Round Robin Policy . . . . . . . . . . . . . . . 5 59 3.2.1. Description . . . . . . . . . . . . . . . . . . . . . 6 60 3.2.2. ENRP Server Considerations . . . . . . . . . . . . . . 6 61 3.2.3. Pool User Considerations . . . . . . . . . . . . . . . 6 62 3.2.4. Pool Member Selection Policy Parameter . . . . . . . . 6 63 3.3. Random Policy . . . . . . . . . . . . . . . . . . . . . . 6 64 3.3.1. Description . . . . . . . . . . . . . . . . . . . . . 6 65 3.3.2. ENRP Server Considerations . . . . . . . . . . . . . . 6 66 3.3.3. Pool User Considerations . . . . . . . . . . . . . . . 7 67 3.3.4. Pool Member Selection Policy Parameter . . . . . . . . 7 68 3.4. Weighted Random Policy . . . . . . . . . . . . . . . . . . 7 69 3.4.1. Description . . . . . . . . . . . . . . . . . . . . . 7 70 3.4.2. ENRP Server Considerations . . . . . . . . . . . . . . 7 71 3.4.3. Pool User Considerations . . . . . . . . . . . . . . . 7 72 3.4.4. Pool Member Selection Policy Parameter . . . . . . . . 7 73 4. Adaptive Policies . . . . . . . . . . . . . . . . . . . . . . 8 74 4.1. Least Used Policy . . . . . . . . . . . . . . . . . . . . 8 75 4.1.1. Description . . . . . . . . . . . . . . . . . . . . . 8 76 4.1.2. ENRP Server Considerations . . . . . . . . . . . . . . 8 77 4.1.3. Pool User Considerations . . . . . . . . . . . . . . . 8 78 4.1.4. Pool Member Selection Policy Parameter . . . . . . . . 8 79 4.2. Least Used with Degradation Policy . . . . . . . . . . . . 9 80 4.2.1. Description . . . . . . . . . . . . . . . . . . . . . 9 81 4.2.2. ENRP Server Considerations . . . . . . . . . . . . . . 9 82 4.2.3. Pool User Considerations . . . . . . . . . . . . . . . 9 83 4.2.4. Pool Member Selection Policy Parameter . . . . . . . . 9 84 4.3. Priority Least Used Policy . . . . . . . . . . . . . . . . 10 85 4.3.1. Description . . . . . . . . . . . . . . . . . . . . . 10 86 4.3.2. ENRP Server Considerations . . . . . . . . . . . . . . 10 87 4.3.3. Pool User Considerations . . . . . . . . . . . . . . . 10 88 4.3.4. Pool Member Selection Policy Parameter . . . . . . . . 11 89 4.4. Randomized Least Used Policy . . . . . . . . . . . . . . . 11 90 4.4.1. Description . . . . . . . . . . . . . . . . . . . . . 11 91 4.4.2. ENRP Server Considerations . . . . . . . . . . . . . . 11 92 4.4.3. Pool User Considerations . . . . . . . . . . . . . . . 11 93 4.4.4. Pool Member Selection Policy Parameter . . . . . . . . 11 95 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 96 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 97 7. Reference Implementation . . . . . . . . . . . . . . . . . . . 12 98 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 99 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 100 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 102 Intellectual Property and Copyright Statements . . . . . . . . . . 15 104 1. Introduction 106 The protocols defined in ENRP [5], ASAP [4] and Parameters [3] 107 support a variety of server policies. Some of the policies use 108 dynamic load information of the pool elements and others do not. 109 Therefore, we classify them as adaptive and non-adaptive. The 110 selection of the pool user is performed by two different entities. 111 Some of the consequences for policies which are not stateless are 112 described in Performance [11]. 114 Therefore this document describes not only packet formats but also 115 gives a detailed description of the procedures to be followed at the 116 ENRP servers and the pool users to implement each server policy. 118 2. Terminology and Definitions 120 2.1. Load 122 The term load is a value specifying how much a pool element's 123 resources are currently utilized. 0x00000000 states, that the pool 124 element is not utilized (0%), 0xffffffff states that it is fully 125 utilized (100%). Defining what utilization means is application- 126 dependent and out of the scope of RSerPool. However, it is required 127 that all pool elements of the same pool using load information have 128 the same definition of load. 130 For example, load may define the current amount of users out of a 131 maximum on a FTP server, the CPU usage of a database server or the 132 memory utilization of a compute service. 134 2.2. Weight 136 Weight defines a pool element's service capacity relatively to other 137 pool elements of the same pool. Theoretically, there is no upper 138 limit for weight values (although limited by datatype size). 139 Defining what value weights compare is application-dependent and out 140 of the scope of RSerPool. However, it is required that all pool 141 elements of the same pool using weight information have the same 142 definition of weight. 144 A weight of 0 denotes that the pool element is not capable of 145 providing any service, a weight of 2*n denotes that the pool element 146 is capable of providing a two times better service than a pool 147 element having weight n. 149 For example, weight may define a compute service's computation 150 capacity. That is, a pool element of weight 100 will complete a work 151 package in half of the time compared to a pool element of weight 50. 153 3. Non-Adaptive Policies 155 3.1. Round Robin Policy 157 3.1.1. Description 159 The Round Robin (RR) policy is a very simple and efficient policy 160 which requires state. This policy is denoted as the default policy 161 and MUST be supported by all RSerPool components. 163 3.1.2. ENRP Server Considerations 165 The ENRP server SHOULD hold the pool elements of each server pool in 166 a circular list and SHOULD store a pointer to one of the elements, 167 called the head. On reception of a handle resolution request the 168 ENRP server SHOULD return the pool elements from the circular list 169 starting with head. Then head SHOULD be advanced by one element. 171 Using this algorithm it is made sure that not all lists presented to 172 the pool users start with the same element. 174 3.1.3. Pool User Considerations 176 A pool user SHOULD use the list of pool elements returned by the ENRP 177 server in a round robin fashion, starting with the first. If all 178 elements of the list have been used it should start from the 179 beginning again until the information is out of date. 181 3.1.4. Pool Member Selection Policy Parameter 183 0 1 2 3 184 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 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Param Type = 0x6 | Length = 0x8 | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Policy=0x1 | (reserved) | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 o Reserved: 24 bits, SHOULD be set to 0. 193 3.2. Weighted Round Robin Policy 194 3.2.1. Description 196 The Weighted Round Robin (WRR) policy is a generalization of the RR 197 policy. If all weights are 1 then WRR is just RR. 199 3.2.2. ENRP Server Considerations 201 The ENRP server SHOULD follow the same rules as for RR but initialize 202 and modify the circular list differently. The ENRP server puts each 203 pool element possibly multiple times into the list such that: 204 o The ratio of the number of occurrences of a pool element to the 205 list length is the same as the ratio of the weight of that pool 206 element to the sum of weights. 207 o Each pool element is inserted as distributed as possible in the 208 circular list. 210 3.2.3. Pool User Considerations 212 The pool user SHOULD follow the same rules as for RR. 214 3.2.4. Pool Member Selection Policy Parameter 216 0 1 2 3 217 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 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Param Type = 0x6 | Length = 0xc | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Policy=0x2 | (reserved) | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Weight | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 o Reserved: 24 bits, SHOULD be set to 0. 227 o Weight: Weight constant for the WRR process. 229 3.3. Random Policy 231 3.3.1. Description 233 The Random (RAND) policy is a very simple stateless policy. 235 3.3.2. ENRP Server Considerations 237 The ENRP server selects at most the requested number of pool elements 238 from the list of pool elements. Each element MUST NOT be reported 239 more than once to the pool user. 241 3.3.3. Pool User Considerations 243 Each time the pool user must select one pool element it does this by 244 randomly selecting one element from the list of pool elements 245 received from the ENRP server. 247 3.3.4. Pool Member Selection Policy Parameter 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Param Type = 0x6 | Length = 0x8 | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Policy=0x3 | (reserved) | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 o Reserved: 24 bits, SHOULD be set to 0. 259 3.4. Weighted Random Policy 261 3.4.1. Description 263 The Weighted Random (WRAND) policy is a generalization of the RAND 264 policy, adding a weight for each pool element entry. RAND is equal 265 to WRAND having all weights set to 1. 267 3.4.2. ENRP Server Considerations 269 The ENRP server SHOULD select at most the requested number of pool 270 elements randomly from the list of pool elements. Each element MUST 271 NOT be reported more than once to the pool user. The probability of 272 selecting a pool element should be the ratio of the weight of that 273 pool element to the sum of weights. 275 3.4.3. Pool User Considerations 277 Each time the pool user must select one pool element it does this by 278 randomly selecting one element from the list of pool elements 279 received from the ENRP server. 281 3.4.4. Pool Member Selection Policy Parameter 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Param Type = 0x6 | Length = 0xc | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Policy=0x4 | (reserved) | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Weight | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 o Reserved: 24 bits, SHOULD be set to 0. 293 o Weight: Weight constant for the WRAND process. 295 4. Adaptive Policies 297 4.1. Least Used Policy 299 4.1.1. Description 301 The Least Used (LU) policy uses load information provided by the pool 302 elements to select the lowest-loaded pool elements within the pool. 304 4.1.2. ENRP Server Considerations 306 The ENRP server SHOULD select at most the requested number of pool 307 elements. Their load values SHOULD be the lowest possible ones 308 within the pool. Each element MUST NOT be reported more than once to 309 the pool user. If there is a choice of equal-loaded pool elements, 310 round robin selection SHOULD be made between these elements. The 311 returned list of pool elements MUST be sorted ascending by load 312 value. 314 4.1.3. Pool User Considerations 316 The pool user should try to use the pool elements returned from the 317 list in the order returned by the ENRP server. A subsequent call for 318 handle resolution may result in the same list. Thereofore, it is 319 RECOMMENDED for a pool user to request multiple entries in order to 320 have a sufficient amount of feasible backup entries available. 322 4.1.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=0x5 | (reserved) | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Load | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 o Reserved: 24 bits, SHOULD be set to 0. 334 o Load: Current load of the pool element. 336 4.2. Least Used with Degradation Policy 338 4.2.1. Description 340 The Least Used with Degradation (LUD) policy extends the LU policy by 341 a load degradation value describing the pool element's load increment 342 when a new service association is accepted. 344 4.2.2. ENRP Server Considerations 346 For every pool element entry, a degradation counter MUST be stored. 347 When a pool element entry is added or updated by registration or 348 reregistration, this counter MUST be set to 0. When an entry is 349 selected for being returned to a pool user, the internal degradation 350 counter MUST be incremented by the entry's load degradation constant. 351 The selection of pool element entries is handled like for LU, except 352 that the selected pool element entries SHOULD have the lowest 353 possible sum of load value + degradation counter. 355 4.2.3. Pool User Considerations 357 See LU policy. 359 4.2.4. Pool Member Selection Policy Parameter 360 0 1 2 3 361 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 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Param Type = 0x6 | Length = 0x10 | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Policy=0x6 | (reserved) | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Load | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Load Degradation | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 o Reserved: 8 bits, SHOULD be set to 0. 373 o Load: Current load of the pool element. 374 o Load Degradation: Load Degradation constant of the pool element. 376 4.3. Priority Least Used Policy 378 4.3.1. Description 380 The Priority Least Used (PLU) policy uses load information provided 381 by the pool elements to select the lowest-loaded pool elements within 382 the pool under the assumption that a new application request is 383 accepted by the pool elements. Therefore, the pool elements also 384 have to specify load degradation information. 386 Example: Pool elements A and B are loaded by 50%, but the load of A 387 will increase due to a new application request only by 10% while B 388 will be fully loaded. PLU allows to specify this load degradation in 389 the policy information, the selection is made on the lowest sum of 390 load and degradation value. That is, A will be selected (50+10=60) 391 instead of B (50+50=100). 393 4.3.2. ENRP Server Considerations 395 The ENRP server SHOULD select at most the requested number of pool 396 elements. Their sums of load + degradation SHOULD be the lowest 397 possible ones within the pool. Each element MUST NOT be reported 398 more than once to the pool user. If there is a choice of equal- 399 valued pool element entries, round robin SHOULD be made between these 400 elements. The returned list of pool elements MUST be sorted 401 ascending by the sum of load and degradation value. 403 4.3.3. Pool User Considerations 405 The pool user should try to use the pool elements returned from the 406 list in the order returned by the ENRP server. A subsequent call for 407 handle resolution may result in the same list. Therefore, it is 408 RECOMMENDED for a pool user to request multiple entries in order to 409 have a sufficient amount of feasible backup entries available. 411 4.3.4. Pool Member Selection Policy Parameter 413 0 1 2 3 414 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Param Type = 0x6 | Length = 0x10 | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Policy=0x7 | (reserved) | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Load | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Load Degradation | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 o Reserved: 8 bits, SHOULD be set to 0. 426 o Load: Current load of the pool element. 427 o Load Degradation: Load Degradation constant of the pool element. 429 4.4. Randomized Least Used Policy 431 4.4.1. Description 433 The Randomized Least Used (RLU) policy combines LU and WRAND. That 434 is, the pool element entries are selected randomly; the probability 435 for a pool element entry to be selected is the ratio of 100%-load to 436 the sum of all pool elements' load values. 438 4.4.2. ENRP Server Considerations 440 The ENRP server SHOULD behave like WRAND, having every PE's weight 441 set to (0xffffffff - Load value provided by the pool element). 443 4.4.3. Pool User Considerations 445 See WRAND policy. 447 4.4.4. Pool Member Selection Policy Parameter 448 0 1 2 3 449 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 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Param Type = 0x7 | Length = 0xc | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Policy=0x9 | (reserved) | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Load | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 o Reserved: 8 bits, SHOULD be set to 0. 459 o Load: Current load of the pool element. 461 5. Security Considerations 463 The security threats regarding RSerPool have been analyzed in 464 RSerPool threats [6]. The server policy descriptions in this 465 document do not add any other threats. 467 6. IANA Considerations 469 IANA keeps a list of Policy Types which are 1 byte values. The 470 Policy values used in this document are: 472 Value Policy 473 ----- --------- 474 0x00 (reserved by IETF) 475 0x01 Round Robin 476 0x02 Weighted Round Robin 477 0x03 Random 478 0x04 Weighted Random 479 0x05 Least Used 480 0x06 Least Used with Degradation 481 0x07 Priority Least Used 482 0x09 Randomized Least Used 483 others (reserved by IETF) 485 7. Reference Implementation 487 The reference implementation of RSerPool and the policies described 488 in this document is available at [7]. 490 8. References 491 8.1. Normative References 493 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 494 Levels", BCP 14, RFC 2119, March 1997. 496 [2] Bradner, S., "Intellectual Property Rights in IETF Technology", 497 RFC 3668, February 2004. 499 [3] Stewart, R., "Aggregate Server Access Protocol (ASAP) and 500 Endpoint Handlespace Redundancy Protocol (ENRP) Parameters", 501 draft-ietf-rserpool-common-param-10 (work in progress), 502 February 2006. 504 [4] Stewart, R., "Aggregate Server Access Protocol (ASAP)", 505 draft-ietf-rserpool-asap-13 (work in progress), February 2006. 507 [5] Stewart, R., "Endpoint Handlespace Redundancy Protocol (ENRP)", 508 draft-ietf-rserpool-enrp-13 (work in progress), February 2006. 510 [6] Stillman, M., "Threats Introduced by Rserpool and Requirements 511 for Security in response to Threats", 512 draft-ietf-rserpool-threats-05 (work in progress), July 2005. 514 8.2. Informative References 516 [7] Dreibholz, T., "Thomas Dreibholz's RSerPool Page", 517 URL: http://tdrwww.exp-math.uni-essen.de/dreibholz/rserpool/. 519 [8] Dreibholz, T. and E. Rathgeb, "On the Performance of Reliable 520 Server Pooling Systems", Proceedings of the 30th IEEE Local 521 Computer Networks Conference, November 2005. 523 [9] Dreibholz, T. and E. Rathgeb, "The Performance of Reliable 524 Server Pooling Systems in Different Server Capacity Scenarios", 525 Proceedings of the IEEE TENCON, November 2005. 527 [10] Dreibholz, T. and E. Rathgeb, "Implementing the Reliable Server 528 Pooling Framework", Proceedings of the 8th IEEE International 529 Conference on Telecommunications, June 2005. 531 [11] Dreibholz, T., Rathgeb, E., and M. Tuexen, "Load Distribution 532 Performance of the Reliable Server Pooling Framework", 533 Proceedings of the 4th IEEE International Conference on 534 Networking, April 2005. 536 Authors' Addresses 538 Michael Tuexen 539 Muenster University of Applied Sciences 540 Stegerwaldstrasse 39 541 48565 Steinfurt 542 Germany 544 Email: tuexen@fh-muenster.de 546 Thomas Dreibholz 547 University of Duisburg-Essen, Institute for Experimental Mathematics 548 Ellernstrasse 29 549 45326 Essen, Nordrhein-Westfalen 550 Germany 552 Phone: +49 201 183-7637 553 Fax: +49 201 183-7673 554 Email: dreibh@exp-math.uni-essen.de 555 URI: http://www.exp-math.uni-essen.de/~dreibh/ 557 Full Copyright Statement 559 Copyright (C) The Internet Society (2006). 561 This document is subject to the rights, licenses and restrictions 562 contained in BCP 78, and except as set forth therein, the authors 563 retain all their rights. 565 This document and the information contained herein are provided on an 566 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 567 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 568 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 569 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 570 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 571 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 573 Intellectual Property 575 The IETF takes no position regarding the validity or scope of any 576 Intellectual Property Rights or other rights that might be claimed to 577 pertain to the implementation or use of the technology described in 578 this document or the extent to which any license under such rights 579 might or might not be available; nor does it represent that it has 580 made any independent effort to identify any such rights. Information 581 on the procedures with respect to rights in RFC documents can be 582 found in BCP 78 and BCP 79. 584 Copies of IPR disclosures made to the IETF Secretariat and any 585 assurances of licenses to be made available, or the result of an 586 attempt made to obtain a general license or permission for the use of 587 such proprietary rights by implementers or users of this 588 specification can be obtained from the IETF on-line IPR repository at 589 http://www.ietf.org/ipr. 591 The IETF invites any interested party to bring to its attention any 592 copyrights, patents or patent applications, or other proprietary 593 rights that may cover technology that may be required to implement 594 this standard. Please address the information to the IETF at 595 ietf-ipr@ietf.org. 597 Acknowledgment 599 Funding for the RFC Editor function is provided by the IETF 600 Administrative Support Activity (IASA).