idnits 2.17.1 draft-ietf-rserpool-policies-08.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 667. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 678. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 685. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 691. 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 (March 10, 2008) is 5890 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'Dre2006' is defined on line 615, but no explicit reference was found in the text == Unused Reference: 'LCN2005' is defined on line 623, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) == Outdated reference: A later version (-18) exists of draft-ietf-rserpool-common-param-15 == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-asap-18 == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-enrp-18 == Outdated reference: A later version (-15) exists of draft-ietf-rserpool-threats-09 Summary: 2 errors (**), 0 flaws (~~), 7 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: September 11, 2008 University of Duisburg-Essen 6 March 10, 2008 8 Reliable Server Pooling Policies 9 draft-ietf-rserpool-policies-08.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 September 11, 2008. 36 Abstract 38 This document describes server pool policies for Reliable Server 39 Pooling including considerations for implementing them at ENRP 40 servers and pool users. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 45 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 46 3. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 47 3.1. Load . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 48 3.2. Weight . . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 4. Non-Adaptive Policies . . . . . . . . . . . . . . . . . . . . 5 50 4.1. Round Robin Policy . . . . . . . . . . . . . . . . . . . . 5 51 4.1.1. Description . . . . . . . . . . . . . . . . . . . . . 5 52 4.1.2. ENRP Server Considerations . . . . . . . . . . . . . . 5 53 4.1.3. Pool User Considerations . . . . . . . . . . . . . . . 5 54 4.1.4. Pool Member Selection Policy Parameter . . . . . . . . 5 55 4.2. Weighted Round Robin Policy . . . . . . . . . . . . . . . 6 56 4.2.1. Description . . . . . . . . . . . . . . . . . . . . . 6 57 4.2.2. ENRP Server Considerations . . . . . . . . . . . . . . 6 58 4.2.3. Pool User Considerations . . . . . . . . . . . . . . . 6 59 4.2.4. Pool Member Selection Policy Parameter . . . . . . . . 6 60 4.3. Random Policy . . . . . . . . . . . . . . . . . . . . . . 7 61 4.3.1. Description . . . . . . . . . . . . . . . . . . . . . 7 62 4.3.2. ENRP Server Considerations . . . . . . . . . . . . . . 7 63 4.3.3. Pool User Considerations . . . . . . . . . . . . . . . 7 64 4.3.4. Pool Member Selection Policy Parameter . . . . . . . . 7 65 4.4. Weighted Random Policy . . . . . . . . . . . . . . . . . . 7 66 4.4.1. Description . . . . . . . . . . . . . . . . . . . . . 7 67 4.4.2. ENRP Server Considerations . . . . . . . . . . . . . . 7 68 4.4.3. Pool User Considerations . . . . . . . . . . . . . . . 8 69 4.4.4. Pool Member Selection Policy Parameter . . . . . . . . 8 70 4.5. Priority Policy . . . . . . . . . . . . . . . . . . . . . 8 71 4.5.1. Description . . . . . . . . . . . . . . . . . . . . . 8 72 4.5.2. ENRP Server Considerations . . . . . . . . . . . . . . 8 73 4.5.3. Pool Element Considerations . . . . . . . . . . . . . 8 74 4.5.4. Pool Member Selection Policy Parameter . . . . . . . . 8 75 5. Adaptive Policies . . . . . . . . . . . . . . . . . . . . . . 9 76 5.1. Least Used Policy . . . . . . . . . . . . . . . . . . . . 9 77 5.1.1. Description . . . . . . . . . . . . . . . . . . . . . 9 78 5.1.2. ENRP Server Considerations . . . . . . . . . . . . . . 9 79 5.1.3. Pool User Considerations . . . . . . . . . . . . . . . 9 80 5.1.4. Pool Member Selection Policy Parameter . . . . . . . . 9 81 5.2. Least Used with Degradation Policy . . . . . . . . . . . . 10 82 5.2.1. Description . . . . . . . . . . . . . . . . . . . . . 10 83 5.2.2. ENRP Server Considerations . . . . . . . . . . . . . . 10 84 5.2.3. Pool User Considerations . . . . . . . . . . . . . . . 10 85 5.2.4. Pool Member Selection Policy Parameter . . . . . . . . 10 86 5.3. Priority Least Used Policy . . . . . . . . . . . . . . . . 11 87 5.3.1. Description . . . . . . . . . . . . . . . . . . . . . 11 88 5.3.2. ENRP Server Considerations . . . . . . . . . . . . . . 11 89 5.3.3. Pool User Considerations . . . . . . . . . . . . . . . 11 90 5.3.4. Pool Member Selection Policy Parameter . . . . . . . . 11 91 5.4. Randomized Least Used Policy . . . . . . . . . . . . . . . 12 92 5.4.1. Description . . . . . . . . . . . . . . . . . . . . . 12 93 5.4.2. ENRP Server Considerations . . . . . . . . . . . . . . 12 94 5.4.3. Pool User Considerations . . . . . . . . . . . . . . . 12 95 5.4.4. Pool Member Selection Policy Parameter . . . . . . . . 12 96 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 97 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 98 7.1. A New Table for RSerPool Policy Types . . . . . . . . . . 13 99 8. Reference Implementation . . . . . . . . . . . . . . . . . . . 14 100 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 101 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 102 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 104 Intellectual Property and Copyright Statements . . . . . . . . . . 17 106 1. Introduction 108 The protocols defined in ENRP [I-D.ietf-rserpool-enrp], ASAP 109 [I-D.ietf-rserpool-asap] and Parameters 110 [I-D.ietf-rserpool-common-param] support a variety of server 111 policies. Some of the policies use dynamic load information of the 112 pool elements and others do not. Therefore, we classify them as 113 adaptive and non-adaptive. The selection of the pool user is 114 performed by two different entities. Some of the consequences for 115 policies which are not stateless are described in Performance 116 [ICN2005]. 118 Therefore this document describes not only packet formats but also 119 gives a detailed description of the procedures to be followed at the 120 ENRP servers and the pool users to implement each server policy. 122 2. Conventions 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC2119 [RFC2119]. 128 3. Terminology and Definitions 130 3.1. Load 132 The term load is a value specifying how much a pool element's 133 resources are currently utilized. 0x00000000 states, that the pool 134 element is not utilized (0%), 0xffffffff states that it is fully 135 utilized (100%). Defining what utilization means is application- 136 dependent and out of the scope of RSerPool. However, it is required 137 that all pool elements of the same pool using load information have 138 the same definition of load. 140 For example, load may define the current amount of users out of a 141 maximum on a FTP server, the CPU usage of a database server or the 142 memory utilization of a compute service. 144 3.2. Weight 146 Weight defines a pool element's service capacity relatively to other 147 pool elements of the same pool. Theoretically, there is no upper 148 limit for weight values (although limited by datatype size). 149 Defining what value weights compare is application-dependent and out 150 of the scope of RSerPool. However, it is required that all pool 151 elements of the same pool using weight information have the same 152 definition of weight. 154 A weight of 0 denotes that the pool element is not capable of 155 providing any service, a weight of 2*n denotes that the pool element 156 is capable of providing a two times better service than a pool 157 element having weight n. 159 For example, weight may define a compute service's computation 160 capacity. That is, a pool element of weight 100 will complete a work 161 package in half of the time compared to a pool element of weight 50. 163 4. Non-Adaptive Policies 165 4.1. Round Robin Policy 167 4.1.1. Description 169 The Round Robin (RR) policy is a very simple and efficient policy 170 which requires state. This policy is denoted as the default policy 171 and MUST be supported by all RSerPool components. 173 4.1.2. ENRP Server Considerations 175 The ENRP server SHOULD hold the pool elements of each server pool in 176 a circular list and SHOULD store a pointer to one of the elements, 177 called the head. On reception of a handle resolution request the 178 ENRP server SHOULD return the pool elements from the circular list 179 starting with head. Then head SHOULD be advanced by one element. 181 Using this algorithm it is made sure that not all lists presented to 182 the pool users start with the same element. 184 4.1.3. Pool User Considerations 186 A pool user SHOULD use the list of pool elements returned by the ENRP 187 server in a round robin fashion, starting with the first. If all 188 elements of the list have been used it should start from the 189 beginning again until the information is out of date. 191 4.1.4. Pool Member Selection Policy Parameter 192 0 1 2 3 193 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 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Param Type = 0x8 | Length = 0x8 | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Policy Type = 0x00000001 | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 4.2. Weighted Round Robin Policy 202 4.2.1. Description 204 The Weighted Round Robin (WRR) policy is a generalization of the RR 205 policy. If all weights are 1 then WRR is just RR. 207 4.2.2. ENRP Server Considerations 209 The ENRP server SHOULD follow the same rules as for RR but initialize 210 and modify the circular list differently. The ENRP server puts each 211 pool element possibly multiple times into the list such that: 212 o The ratio of the number of occurrences of a pool element to the 213 list length is the same as the ratio of the weight of that pool 214 element to the sum of weights. 215 o Each pool element is inserted as distributed as possible in the 216 circular list. 218 4.2.3. Pool User Considerations 220 The pool user SHOULD follow the same rules as for RR. 222 4.2.4. Pool Member Selection Policy Parameter 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Param Type = 0x8 | Length = 0xc | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Policy Type = 0x00000002 | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Weight | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 o Weight: Weight constant for the WRR process. 236 4.3. Random Policy 238 4.3.1. Description 240 The Random (RAND) policy is a very simple stateless policy. 242 4.3.2. ENRP Server Considerations 244 The ENRP server selects at most the requested number of pool elements 245 from the list of pool elements. Each element MUST NOT be reported 246 more than once to the pool user. 248 4.3.3. Pool User Considerations 250 Each time the pool user must select one pool element it does this by 251 randomly selecting one element from the list of pool elements 252 received from the ENRP server. 254 4.3.4. Pool Member Selection Policy Parameter 256 0 1 2 3 257 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 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Param Type = 0x8 | Length = 0x8 | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Policy Type = 0x00000003 | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 4.4. Weighted Random Policy 266 4.4.1. Description 268 The Weighted Random (WRAND) policy is a generalization of the RAND 269 policy, adding a weight for each pool element entry. RAND is equal 270 to WRAND having all weights set to 1. 272 4.4.2. ENRP Server Considerations 274 The ENRP server SHOULD select at most the requested number of pool 275 elements randomly from the list of pool elements. Each element MUST 276 NOT be reported more than once to the pool user. The probability of 277 selecting a pool element should be the ratio of the weight of that 278 pool element to the sum of weights. 280 4.4.3. Pool User Considerations 282 Each time the pool user must select one pool element it does this by 283 randomly selecting one element from the list of pool elements 284 received from the ENRP server. 286 4.4.4. Pool Member Selection Policy Parameter 288 0 1 2 3 289 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 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Param Type = 0x8 | Length = 0xc | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Policy Type = 0x00000004 | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Weight | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 o Weight: Weight constant for the WRAND process. 300 4.5. Priority Policy 302 4.5.1. Description 304 The Priority (PRIO) policy can be used to select always a pool 305 element with the highest priority. 307 4.5.2. ENRP Server Considerations 309 The ENRP server MUST select the pool elements with the highest 310 priorities. They MUST be reported in decreasing order. If multiple 311 pool elements have the same priority, they may be listed in any 312 order. 314 4.5.3. Pool Element Considerations 316 The pool user MUST select the active pool element with the highest 317 priority. 319 4.5.4. Pool Member Selection Policy Parameter 320 0 1 2 3 321 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 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Param Type = 0x8 | Length = 0xc | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Policy Type = 0x00000005 | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Priority | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 o Priority: 32 bits, unsigned int. Larger numbers mean higher 331 priorities. 333 5. Adaptive Policies 335 5.1. Least Used Policy 337 5.1.1. Description 339 The Least Used (LU) policy uses load information provided by the pool 340 elements to select the lowest-loaded pool elements within the pool. 342 5.1.2. ENRP Server Considerations 344 The ENRP server SHOULD select at most the requested number of pool 345 elements. Their load values SHOULD be the lowest possible ones 346 within the pool. Each element MUST NOT be reported more than once to 347 the pool user. If there is a choice of equal-loaded pool elements, 348 round robin selection SHOULD be made among these elements. The 349 returned list of pool elements MUST be sorted ascending by load 350 value. 352 5.1.3. Pool User Considerations 354 The pool user should try to use the pool elements returned from the 355 list in the order returned by the ENRP server. A subsequent call for 356 handle resolution may result in the same list. Thereofore, it is 357 RECOMMENDED for a pool user to request multiple entries in order to 358 have a sufficient amount of feasible backup entries available. 360 5.1.4. Pool Member Selection Policy Parameter 361 0 1 2 3 362 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 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Param Type = 0x8 | Length = 0xc | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Policy Type = 0x40000001 | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Load | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 o Load: Current load of the pool element. 373 5.2. Least Used with Degradation Policy 375 5.2.1. Description 377 The Least Used with Degradation (LUD) policy extends the LU policy by 378 a load degradation value describing the pool element's load increment 379 when a new service association is accepted. 381 5.2.2. ENRP Server Considerations 383 For every pool element entry, a degradation counter MUST be stored. 384 When a pool element entry is added or updated by registration or 385 reregistration, this counter MUST be set to 0. When an entry is 386 selected for being returned to a pool user, the internal degradation 387 counter MUST be incremented by 1. The selection of pool element 388 entries is handled like for LU, except that the selected pool element 389 entries SHOULD have the lowest possible sum of load value + 390 degradation counter * load degradation value. 392 5.2.3. Pool User Considerations 394 See LU policy. 396 5.2.4. Pool Member Selection Policy Parameter 398 0 1 2 3 399 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 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Param Type = 0x8 | Length = 0x10 | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Policy Type = 0x40000002 | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Load | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Load Degradation | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 o Load: Current load of the pool element. 411 o Load Degradation: Load Degradation constant of the pool element. 413 5.3. Priority Least Used Policy 415 5.3.1. Description 417 The Priority Least Used (PLU) policy uses load information provided 418 by the pool elements to select the lowest-loaded pool elements within 419 the pool under the assumption that a new application request is 420 accepted by the pool elements. Therefore, the pool elements also 421 have to specify load degradation information. 423 Example: Pool elements A and B are loaded by 50%, but the load of A 424 will increase due to a new application request only by 10% while B 425 will be fully loaded. PLU allows to specify this load degradation in 426 the policy information, the selection is made on the lowest sum of 427 load and degradation value. That is, A will be selected (50+10=60) 428 instead of B (50+50=100). 430 5.3.2. ENRP Server Considerations 432 The ENRP server SHOULD select at most the requested number of pool 433 elements. Their sums of load + degradation SHOULD be the lowest 434 possible ones within the pool. Each element MUST NOT be reported 435 more than once to the pool user. If there is a choice of equal- 436 valued pool element entries, round robin SHOULD be made among these 437 elements. The returned list of pool elements MUST be sorted 438 ascending by the sum of load and degradation value. 440 5.3.3. Pool User Considerations 442 The pool user should try to use the pool elements returned from the 443 list in the order returned by the ENRP server. A subsequent call for 444 handle resolution may result in the same list. Therefore, it is 445 RECOMMENDED for a pool user to request multiple entries in order to 446 have a sufficient amount of feasible backup entries available. 448 5.3.4. Pool Member Selection Policy Parameter 449 0 1 2 3 450 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Param Type = 0x8 | Length = 0x10 | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Policy Type = 0x40000003 | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Load | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Load Degradation | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 o Load: Current load of the pool element. 462 o Load Degradation: Load Degradation constant of the pool element. 464 5.4. Randomized Least Used Policy 466 5.4.1. Description 468 The Randomized Least Used (RLU) policy combines LU and WRAND. That 469 is, the pool element entries are selected randomly. The probability 470 for a pool element entry A, utilized with load_A, to be selected is 471 (0xFFFFFFFF - load_A) / (sum(0xFFFFFFFF-load_x)), i.e. this PE's 472 unload part related to the whole pool unload rate. 474 5.4.2. ENRP Server Considerations 476 The ENRP server SHOULD behave like WRAND, having every PE's weight 477 set to (0xffffffff - Load value provided by the pool element). 479 5.4.3. Pool User Considerations 481 See WRAND policy. 483 5.4.4. Pool Member Selection Policy Parameter 485 0 1 2 3 486 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 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Param Type = 0x8 | Length = 0xc | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Policy Type = 0x40000004 | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Load | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 o Load: Current load of the pool element. 497 6. Security Considerations 499 The security threats regarding RSerPool have been analyzed in 500 RSerPool threats [I-D.ietf-rserpool-threats]. The server policy 501 descriptions in this document do not add any other threats. 503 7. IANA Considerations 505 [NOTE to RFC-Editor: 506 "RFCXXXX" is to be replaced by the RFC number you assign this 507 document. 508 ] 510 This document (RFCXXX) is the reference for all registrations 511 described in this section. All registrations need to be listed on an 512 RSerPool specific page. 514 7.1. A New Table for RSerPool Policy Types 516 RSerPool Policy Types which are 4 byte values have to be maintained 517 by IANA. The format of the policy type value is defined as follows: 519 0 1 2 3 520 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 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 |X|A| Policy Number | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 o X: If set to 1, the policy is user-defined and not standardized. 526 All standards policies reserved by the IETF use X=0. 527 o A: If set to 1, the policy is adaptive. Otherwise, it is non- 528 adaptive. 529 o Policy Number: The actual number of the policy. 531 Nine initial Policy Types should be assigned and maintained in a new 532 table "RSerPool Policy Types": 534 Value Policy Reference 535 ----- --------- --------- 536 0x00000000 (reserved by IETF) RFCXXXX 537 0x00000001 Round Robin RFCXXXX 538 0x00000002 Weighted Round Robin RFCXXXX 539 0x00000003 Random RFCXXXX 540 0x00000004 Weighted Random RFCXXXX 541 0x00000005 Priority RFCXXXX 542 0x00000006 (reserved by IETF) RFCXXXX 543 ... 544 0x3fffffff (reserved by IETF) RFCXXXX 546 0x40000000 (reserved by IETF) RFCXXXX 547 0x40000001 Least Used RFCXXXX 548 0x40000002 Least Used with Degradation RFCXXXX 549 0x40000003 Priority Least Used RFCXXXX 550 0x40000004 Randomized Least Used RFCXXXX 551 0x40000005 (reserved by IETF) RFCXXXX 552 ... 553 0x7fffffff (reserved by IETF) RFCXXXX 555 0x80000000 (private use, non-standard policy) RFCXXXX 556 ... 557 0xffffffff (private use, non-standard policy) RFCXXXX 559 For registering at IANA an RSerPool Policy Type in this table a 560 request has to be made to assign such a number. This number must be 561 unique and use the appropiate upper bits. The "Specification 562 Required" policy of RFC2434 [RFC2434] MUST be applied. 564 The Policy Type space from 0x80000000 to 0xffffffff is designated for 565 private use. 567 8. Reference Implementation 569 The reference implementation of RSerPool and the policies described 570 in this document is available at [RSerPoolPage]. 572 9. References 574 9.1. Normative References 576 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 577 Requirement Levels", BCP 14, RFC 2119, March 1997. 579 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 580 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 581 October 1998. 583 [I-D.ietf-rserpool-common-param] 584 Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, 585 "Aggregate Server Access Protocol (ASAP) and Endpoint 586 Handlespace Redundancy Protocol (ENRP) Parameters", 587 draft-ietf-rserpool-common-param-15 (work in progress), 588 December 2007. 590 [I-D.ietf-rserpool-asap] 591 Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, 592 "Aggregate Server Access Protocol (ASAP)", 593 draft-ietf-rserpool-asap-18 (work in progress), 594 November 2007. 596 [I-D.ietf-rserpool-enrp] 597 Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. 598 Silverton, "Endpoint Handlespace Redundancy Protocol 599 (ENRP)", draft-ietf-rserpool-enrp-18 (work in progress), 600 November 2007. 602 [I-D.ietf-rserpool-threats] 603 Stillman, M., Gopal, R., Guttman, E., Holdrege, M., and S. 604 Sengodan, "Threats Introduced by RSerPool and Requirements 605 for Security in Response to Threats", 606 draft-ietf-rserpool-threats-09 (work in progress), 607 October 2007. 609 9.2. Informative References 611 [RSerPoolPage] 612 Dreibholz, T., "Thomas Dreibholz's RSerPool Page", URL: 613 http://tdrwww.exp-math.uni-essen.de/dreibholz/rserpool/. 615 [Dre2006] Dreibholz, T., "Reliable Server Pooling -- Evaluation, 616 Optimization and Extension of a Novel IETF Architecture", 617 Ph.D. Thesis University of Duisburg-Essen, Faculty of 618 Economics, Institute for Computer Science and Business 619 Information Systems, URL: http:// 620 duepublico.uni-duisburg-essen.de/servlets/DerivateServlet/ 621 Derivate-16326/Dre2006-final.pdf, March 2007. 623 [LCN2005] Dreibholz, T. and E. Rathgeb, "On the Performance of 624 Reliable Server Pooling Systems", Proceedings of the 30th 625 IEEE Local Computer Networks Conference, November 2005. 627 [ICN2005] Dreibholz, T., Rathgeb, E., and M. Tuexen, "Load 628 Distribution Performance of the Reliable Server Pooling 629 Framework", Proceedings of the 4th IEEE International 630 Conference on Networking, April 2005. 632 Authors' Addresses 634 Michael Tuexen 635 Muenster University of Applied Sciences 636 Stegerwaldstrasse 39 637 48565 Steinfurt 638 Germany 640 Email: tuexen@fh-muenster.de 642 Thomas Dreibholz 643 University of Duisburg-Essen, Institute for Experimental Mathematics 644 Ellernstrasse 29 645 45326 Essen, Nordrhein-Westfalen 646 Germany 648 Phone: +49 201 183-7637 649 Fax: +49 201 183-7673 650 Email: dreibh@exp-math.uni-essen.de 651 URI: http://www.exp-math.uni-essen.de/~dreibh/ 653 Full Copyright Statement 655 Copyright (C) The IETF Trust (2008). 657 This document is subject to the rights, licenses and restrictions 658 contained in BCP 78, and except as set forth therein, the authors 659 retain all their rights. 661 This document and the information contained herein are provided on an 662 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 663 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 664 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 665 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 666 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 667 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 669 Intellectual Property 671 The IETF takes no position regarding the validity or scope of any 672 Intellectual Property Rights or other rights that might be claimed to 673 pertain to the implementation or use of the technology described in 674 this document or the extent to which any license under such rights 675 might or might not be available; nor does it represent that it has 676 made any independent effort to identify any such rights. Information 677 on the procedures with respect to rights in RFC documents can be 678 found in BCP 78 and BCP 79. 680 Copies of IPR disclosures made to the IETF Secretariat and any 681 assurances of licenses to be made available, or the result of an 682 attempt made to obtain a general license or permission for the use of 683 such proprietary rights by implementers or users of this 684 specification can be obtained from the IETF on-line IPR repository at 685 http://www.ietf.org/ipr. 687 The IETF invites any interested party to bring to its attention any 688 copyrights, patents or patent applications, or other proprietary 689 rights that may cover technology that may be required to implement 690 this standard. Please address the information to the IETF at 691 ietf-ipr@ietf.org.