idnits 2.17.1 draft-ietf-rserpool-policies-01.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 556. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 533. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 540. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 546. ** 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 'Intended status' indicated for this document; assuming Proposed Standard 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 == Line 451 has weird spacing: '...iptions in th...' == 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 (June 12, 2005) is 6892 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 475, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 478, 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-08 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-common-param (ref. '3') == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-asap-11 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-asap (ref. '4') == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-enrp-11 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-enrp (ref. '5') == Outdated reference: A later version (-15) exists of draft-ietf-rserpool-threats-04 ** Downref: Normative reference to an Informational draft: draft-ietf-rserpool-threats (ref. '6') Summary: 8 errors (**), 0 flaws (~~), 10 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 Expires: December 14, 2005 T. Dreibholz 5 University of Duisburg-Essen 6 June 12, 2005 8 Reliable Server Pooling Policies 9 draft-ietf-rserpool-policies-01.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 December 14, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document describes server pool policies for Reliable Server 43 Pooling including considerations for implementing them at name 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 Name 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 . . . . . . . . . . . . . . . . . . . . . 5 60 3.2.2 Name 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 Name Server Considerations . . . . . . . . . . . . . . 6 66 3.3.3 Pool User Considerations . . . . . . . . . . . . . . . 6 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 Name 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 Name 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 . . . . . . . . . . . . 8 80 4.2.1 Description . . . . . . . . . . . . . . . . . . . . . 8 81 4.2.2 Name 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 . . . . . . . . . . . . . . . . 9 85 4.3.1 Description . . . . . . . . . . . . . . . . . . . . . 9 86 4.3.2 Name Server Considerations . . . . . . . . . . . . . . 10 87 4.3.3 Pool User Considerations . . . . . . . . . . . . . . . 10 88 4.3.4 Pool Member Selection Policy Parameter . . . . . . . . 10 89 4.4 Randomized Least Used Policy . . . . . . . . . . . . . . . 10 90 4.4.1 Description . . . . . . . . . . . . . . . . . . . . . 10 91 4.4.2 Name 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 . . . . . . . . . . . . . . . . . . . 11 96 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 97 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 98 7.1 Normative References . . . . . . . . . . . . . . . . . . . 12 99 7.2 Informative References . . . . . . . . . . . . . . . . . . 12 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 101 Intellectual Property and Copyright Statements . . . . . . . . 14 103 1. Introduction 105 The protocols defined in ENRP [5], ASAP [4] and Parameters [3] 106 support a variety of server policies. Some of the policies use 107 dynamic load information of the pool elements and others do not. 108 Therefore, we classify them as adaptive and non-adaptive. The 109 selection of the pool user is performed by two different entities. 110 Some of the consequences for policies which are not stateless are 111 described in Performance [7]. 113 Therefore this document describes not only packet formats but also 114 gives a detailed description of the procedures to be followed at the 115 name servers and the pool users to implement each server policy. 117 2. Terminology and Definitions 119 2.1 Load 121 The term load is a value specifying how much a pool element's 122 resources are currently utilized. 0x000000 states, that the pool 123 element is not utilized (0%), 0xffffff states that it is fully 124 utilized (100%). Defining what utilization means is application- 125 dependent and out of the scope of RSerPool. However, it is required 126 that all pool elements of the same pool using load information have 127 the same definition of load. 129 For example, load may define the current amount of users out of a 130 maximum on a FTP server, the CPU usage of a database server or the 131 memory utilization of a compute service. 133 2.2 Weight 135 Weight defines a pool element's service capacity relatively to other 136 pool elements of the same pool. Theoretically, there is no upper 137 limit for weight values (although limited by datatype size). 138 Defining what value weights compare is application-dependent and out 139 of the scope of RSerPool. However, it is required that all pool 140 elements of the same pool using weight information have the same 141 definition of weight. 143 A weight of 0 denotes that the pool element is not capable of 144 providing any service, a weight of 2*n denotes that the pool element 145 is capable of providing a two times better service than a pool 146 element having weight n. 148 For example, weight may define a compute service's computation 149 capacity. That is, a pool element of weight 100 will complete a work 150 package in half of the time compared to a pool element of weight 50. 152 3. Non-Adaptive Policies 154 3.1 Round Robin Policy 156 3.1.1 Description 158 The Round Robin (RR) policy is a very simple and efficient policy 159 which requires state. This policy is denoted as the default policy 160 and MUST be supported by all RSerPool components. 162 3.1.2 Name Server Considerations 164 The name server SHOULD hold the pool elements of each server pool in 165 a circular list and SHOULD store a pointer to one of the elements, 166 called the head. On reception of a name resolution request the name 167 server SHOULD return the pool elements from the circular list 168 starting with head. Then head SHOULD be advanced by one element. 170 Using this algorithm it is made sure that not all lists presented to 171 the pool users start with the same element. 173 3.1.3 Pool User Considerations 175 A pool user SHOULD use the list of pool elements returned by the name 176 server in a round robin fashion, starting with the first. If all 177 elements of the list have been used it should start from the 178 beginning again until the information is out of date. 180 3.1.4 Pool Member Selection Policy Parameter 182 0 1 2 3 183 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 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Param Type = 0x6 | Length = 0x8 | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Policy=0x1 | (reserved) | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 190 o Reserved: 24 bits, SHOULD be set to 0. 192 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 Name Server Considerations 201 The name server SHOULD follow the same rules as for RR but initialize 202 and modify the circular list differently. The name 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 = 0x8 | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Policy=0x2 | Weight | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 224 o Weight: Weight constant for the WRR process. 226 3.3 Random Policy 228 3.3.1 Description 230 The Random (RAND) policy is a very simple stateless policy. 232 3.3.2 Name Server Considerations 234 The name server selects at most the requested number of pool elements 235 from the list of pool elements. Each element MUST NOT be reported 236 more than once to the pool user. 238 3.3.3 Pool User Considerations 240 Each time the pool user must select one pool element it does this by 241 randomly selecting one element from the list of pool elements 242 received from the name server. 244 3.3.4 Pool Member Selection Policy Parameter 246 0 1 2 3 247 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 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Param Type = 0x6 | Length = 0x8 | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Policy=0x3 | (reserved) | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 254 o Reserved: 24 bits, SHOULD be set to 0. 256 3.4 Weighted Random Policy 258 3.4.1 Description 260 The Weighted Random (WRAND) policy is a generalization of the RAND 261 policy, adding a weight for each pool element entry. RAND is equal 262 to WRAND having all weights set to 1. 264 3.4.2 Name Server Considerations 266 The name server SHOULD select at most the requested number of pool 267 elements randomly from the list of pool elements. Each element MUST 268 NOT be reported more than once to the pool user. The probability of 269 selecting a pool element should be the ratio of the weight of that 270 pool element to the sum of weights. 272 3.4.3 Pool User Considerations 274 Each time the pool user must select one pool element it does this by 275 randomly selecting one element from the list of pool elements 276 received from the name server. 278 3.4.4 Pool Member Selection Policy Parameter 280 0 1 2 3 281 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 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Param Type = 0x6 | Length = 0x8 | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Policy=0x4 | Weight | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 288 o Weight: Weight constant for the WRAND process. 290 4. Adaptive Policies 292 4.1 Least Used Policy 294 4.1.1 Description 296 The Least Used (LU) policy uses load information provided by the pool 297 elements to select the lowest-loaded pool elements within the pool. 299 4.1.2 Name Server Considerations 301 The name server SHOULD select at most the requested number of pool 302 elements. Their load values SHOULD be the lowest possible ones 303 within the pool. Each element MUST NOT be reported more than once to 304 the pool user. If there is a choice of equal-loaded pool elements, 305 round robin selection SHOULD be made between these elements. The 306 returned list of pool elements MUST be sorted ascending by load 307 value. 309 4.1.3 Pool User Considerations 311 The pool user should try to use the pool elements returned from the 312 list in the order returned by the name server. A subsequent call for 313 name resolution may result in the same list. Thereofore, it is 314 RECOMMENDED for a pool user to request multiple entries in order to 315 have a sufficient amount of feasible backup entries available. 317 4.1.4 Pool Member Selection Policy Parameter 319 0 1 2 3 320 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 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Param Type = 0x6 | Length = 0x8 | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Policy=0x5 | Load | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 327 o Load: Current load of the pool element. 329 4.2 Least Used with Degradation Policy 331 4.2.1 Description 333 The Least Used with Degradation (LUD) policy extends the LU policy by 334 a load degradation value describing the pool element's load increment 335 when a new service association is accepted. 337 4.2.2 Name Server Considerations 339 For every pool element entry, a degradation counter MUST be stored. 340 When a pool element entry is added or updated by registration or 341 reregistration, this counter MUST be set to 0. When an entry is 342 selected for being returned to a pool user, the internal degradation 343 counter MUST be incremented by the entry's load degradation constant. 344 The selection of pool element entries is handled like for LU, except 345 that the selected pool element entries SHOULD have the lowest 346 possible sum of load value + degradation counter. 348 4.2.3 Pool User Considerations 350 See LU policy. 352 4.2.4 Pool Member Selection Policy Parameter 354 0 1 2 3 355 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 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Param Type = 0x6 | Length = 0xc | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Policy=0x6 | Load | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 361 | (reserved) | Load Degradation | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 364 o Load: Current load of the pool element. 365 o Reserved: 8 bits, SHOULD be set to 0. 366 o Load Degradation: Load Degradation constant of the pool element. 368 4.3 Priority Least Used Policy 370 4.3.1 Description 372 The Priority Least Used (PLU) policy uses load information provided 373 by the pool elements to select the lowest-loaded pool elements within 374 the pool under the assumption that a new application request is 375 accepted by the pool elements. Therefore, the pool elements also 376 have to specify load degradation information. 378 Example: Pool elements A and B are loaded by 50%, but the load of A 379 will increase due to a new application request only by 10% while B 380 will be fully loaded. PLU allows to specify this load degradation in 381 the policy information, the selection is made on the lowest sum of 382 load and degradation value. That is, A will be selected (50+10=60) 383 instead of B (50+50=100). 385 4.3.2 Name Server Considerations 387 The name server SHOULD select at most the requested number of pool 388 elements. Their sums of load + degradation SHOULD be the lowest 389 possible ones within the pool. Each element MUST NOT be reported 390 more than once to the pool user. If there is a choice of equal- 391 valued pool element entries, round robin SHOULD be made between these 392 elements. The returned list of pool elements MUST be sorted 393 ascending by the sum of load and degradation value. 395 4.3.3 Pool User Considerations 397 The pool user should try to use the pool elements returned from the 398 list in the order returned by the name server. A subsequent call for 399 name resolution may result in the same list. Therefore, it is 400 RECOMMENDED for a pool user to request multiple entries in order to 401 have a sufficient amount of feasible backup entries available. 403 4.3.4 Pool Member Selection Policy Parameter 405 0 1 2 3 406 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 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Param Type = 0x6 | Length = 0xc | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Policy=0x7 | Load | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 412 | (reserved) | Load Degradation | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 415 o Load: Current load of the pool element. 416 o Load Degradation: Load Degradation constant of the pool element. 418 4.4 Randomized Least Used Policy 420 4.4.1 Description 422 The Randomized Least Used (RLU) policy combines LU and WRAND. That 423 is, the pool element entries are selected randomly; the probability 424 for a pool element entry to be selected is the ratio of 100%-load to 425 the sum of all pool elements' load values. 427 4.4.2 Name Server Considerations 429 The name server SHOULD behave like WRAND, having every PE's weight 430 set to (0xffffff - Load value provided by the pool element). 432 4.4.3 Pool User Considerations 434 See WRAND policy. 436 4.4.4 Pool Member Selection Policy Parameter 438 0 1 2 3 439 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 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Param Type = 0x7 | Length = 0x8 | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Policy=0x9 | Load | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 446 o Load: Current load of the pool element. 448 5. Security Considerations 450 The security threats regarding RSerPool have been analyzed in 451 RSerPool threats [6]. The server policy descriptions in this 452 document do not add any other threats. 454 6. IANA Considerations 456 IANA keeps a list of Policy Types which are 1 byte values. The 457 Policy values used in this document are: 459 Value Policy 460 ----- --------- 461 0x00 (reserved by IETF) 462 0x01 Round Robin 463 0x02 Weighted Round Robin 464 0x03 Random 465 0x04 Weighted Random 466 0x05 Least Used 467 0x06 Least Used with Degradation 468 0x07 Priority Least Used 469 0x09 Randomized Least Used 470 others (reserved by IETF) 472 7. References 473 7.1 Normative References 475 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 476 Levels", BCP 14, RFC 2119, March 1997. 478 [2] Bradner, S., "Intellectual Property Rights in IETF Technology", 479 RFC 3668, February 2004. 481 [3] Stewart, R., Xie, Q., and M. Tuexen, "Aggregate Server Access 482 Protocol (ASAP) and Endpoint Name Resolution (ENRP) 483 Parameters", draft-ietf-rserpool-common-param-08 (work in 484 progress), February 2005. 486 [4] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate 487 Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-11 488 (work in progress), February 2005. 490 [5] Xie, Q., Stewart, R., and M. Stillman, "Enpoint Name Resolution 491 Protocol (ENRP)", draft-ietf-rserpool-enrp-11 (work in 492 progress), February 2005. 494 [6] Stillman, M., "Threats Introduced by Rserpool and Requirements 495 for Security in response to Threats", 496 draft-ietf-rserpool-threats-04 (work in progress), January 2005. 498 7.2 Informative References 500 [7] Dreibholz, T., Rathgeb, E., and M. Tuexen, "Load Distribution 501 Performance of the Reliable Server Pooling Framework", Submitted 502 to Globecom 2004. 504 Authors' Addresses 506 Michael Tuexen 507 Muenster University of Applied Sciences 508 Stegerwaldstrasse 39 509 48565 Steinfurt 510 Germany 512 Email: tuexen@fh-muenster.de 513 Thomas Dreibholz 514 University of Duisburg-Essen, Institute for Experimental Mathematics 515 Ellernstrasse 29 516 45326 Essen, Nordrhein-Westfalen 517 Germany 519 Phone: +49 201 183-7637 520 Fax: +49 201 183-7673 521 Email: dreibh@exp-math.uni-essen.de 522 URI: http://www.exp-math.uni-essen.de/~dreibh/ 524 Intellectual Property Statement 526 The IETF takes no position regarding the validity or scope of any 527 Intellectual Property Rights or other rights that might be claimed to 528 pertain to the implementation or use of the technology described in 529 this document or the extent to which any license under such rights 530 might or might not be available; nor does it represent that it has 531 made any independent effort to identify any such rights. Information 532 on the procedures with respect to rights in RFC documents can be 533 found in BCP 78 and BCP 79. 535 Copies of IPR disclosures made to the IETF Secretariat and any 536 assurances of licenses to be made available, or the result of an 537 attempt made to obtain a general license or permission for the use of 538 such proprietary rights by implementers or users of this 539 specification can be obtained from the IETF on-line IPR repository at 540 http://www.ietf.org/ipr. 542 The IETF invites any interested party to bring to its attention any 543 copyrights, patents or patent applications, or other proprietary 544 rights that may cover technology that may be required to implement 545 this standard. Please address the information to the IETF at 546 ietf-ipr@ietf.org. 548 Disclaimer of Validity 550 This document and the information contained herein are provided on an 551 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 552 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 553 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 554 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 555 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 556 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 558 Copyright Statement 560 Copyright (C) The Internet Society (2005). This document is subject 561 to the rights, licenses and restrictions contained in BCP 78, and 562 except as set forth therein, the authors retain all their rights. 564 Acknowledgment 566 Funding for the RFC Editor function is currently provided by the 567 Internet Society.