idnits 2.17.1 draft-tuexen-rserpool-policies-00.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 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 555. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 539. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 545. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 561), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 448 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 (July 6, 2004) is 7233 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 473, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 476, 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-05 ** 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-08 ** 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-07 ** 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-02 ** Downref: Normative reference to an Informational draft: draft-ietf-rserpool-threats (ref. '6') Summary: 12 errors (**), 0 flaws (~~), 10 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Tuexen 2 Internet-Draft Univ. of Applied Sciences Muenster 3 Expires: Januar 4, 2005 T. Dreibholz 4 University of Duisburg-Essen 5 July 6, 2004 7 Reliable Server Pooling Policies 8 draft-tuexen-rserpool-policies-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on Januar 4, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This document describes server pool policies for Reliable Server 41 Pooling including considerations for implementing them at name 42 servers and pool users. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 47 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 48 2.1 Load . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 2.2 Weight . . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 3. Static Policies . . . . . . . . . . . . . . . . . . . . . . . 5 51 3.1 Round Robin Policy . . . . . . . . . . . . . . . . . . . . 5 52 3.1.1 Description . . . . . . . . . . . . . . . . . . . . . 5 53 3.1.2 Name Server Considerations . . . . . . . . . . . . . . 5 54 3.1.3 Pool User Considerations . . . . . . . . . . . . . . . 5 55 3.1.4 Pool Member Selection Policy Parameter . . . . . . . . 5 56 3.2 Weighted Round Robin Policy . . . . . . . . . . . . . . . 5 57 3.2.1 Description . . . . . . . . . . . . . . . . . . . . . 5 58 3.2.2 Name Server Considerations . . . . . . . . . . . . . . 6 59 3.2.3 Pool User Considerations . . . . . . . . . . . . . . . 6 60 3.2.4 Pool Member Selection Policy Parameter . . . . . . . . 6 61 3.3 Random Policy . . . . . . . . . . . . . . . . . . . . . . 6 62 3.3.1 Description . . . . . . . . . . . . . . . . . . . . . 6 63 3.3.2 Name Server Considerations . . . . . . . . . . . . . . 6 64 3.3.3 Pool User Considerations . . . . . . . . . . . . . . . 6 65 3.3.4 Pool Member Selection Policy Parameter . . . . . . . . 7 66 3.4 Weighted Random Policy . . . . . . . . . . . . . . . . . . 7 67 3.4.1 Description . . . . . . . . . . . . . . . . . . . . . 7 68 3.4.2 Name Server Considerations . . . . . . . . . . . . . . 7 69 3.4.3 Pool User Considerations . . . . . . . . . . . . . . . 7 70 3.4.4 Pool Member Selection Policy Parameter . . . . . . . . 7 71 4. Dynamic Policies . . . . . . . . . . . . . . . . . . . . . . . 8 72 4.1 Least Used Policy . . . . . . . . . . . . . . . . . . . . 8 73 4.1.1 Description . . . . . . . . . . . . . . . . . . . . . 8 74 4.1.2 Name Server Considerations . . . . . . . . . . . . . . 8 75 4.1.3 Pool User Considerations . . . . . . . . . . . . . . . 8 76 4.1.4 Pool Member Selection Policy Parameter . . . . . . . . 8 77 4.2 Least Used with Degradation Policy . . . . . . . . . . . . 8 78 4.2.1 Description . . . . . . . . . . . . . . . . . . . . . 8 79 4.2.2 Name Server Considerations . . . . . . . . . . . . . . 9 80 4.2.3 Pool User Considerations . . . . . . . . . . . . . . . 9 81 4.2.4 Pool Member Selection Policy Parameter . . . . . . . . 9 82 4.3 Priority Least Used Policy . . . . . . . . . . . . . . . . 9 83 4.3.1 Description . . . . . . . . . . . . . . . . . . . . . 9 84 4.3.2 Name Server Considerations . . . . . . . . . . . . . . 10 85 4.3.3 Pool User Considerations . . . . . . . . . . . . . . . 10 86 4.3.4 Pool Member Selection Policy Parameter . . . . . . . . 10 87 4.4 Randomized Least Used Policy . . . . . . . . . . . . . . . 10 88 4.4.1 Description . . . . . . . . . . . . . . . . . . . . . 10 89 4.4.2 Name Server Considerations . . . . . . . . . . . . . . 10 90 4.4.3 Pool User Considerations . . . . . . . . . . . . . . . 11 91 4.4.4 Pool Member Selection Policy Parameter . . . . . . . . 11 93 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 94 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 95 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 96 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 97 7.2 Informative References . . . . . . . . . . . . . . . . . . . 12 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 99 Intellectual Property and Copyright Statements . . . . . . . . 13 101 1. Introduction 103 The protocols defined in ENRP [5], ASAP [4] and Parameters [3] 104 support a variety of server policies. Some of the policies use 105 dynamic load information of the pool elements and others do not. 106 Therefore, we classify them as dynamic and static. The selection of 107 the pool user is performed by two different entities. Some of the 108 consequences for policies which are not stateless are described in 109 Performance [7]. 111 Therefore this document describes not only packet formats but also 112 gives a detailed description of the procedures to be followed at the 113 name servers and the pool users to implement each server policy. 115 2. Terminology and Definitions 117 2.1 Load 119 The term load is a value specifying how much a pool element's 120 resources are currently utilized. 0x000000 states, that the pool 121 element is not utilized (0%), 0xffffff states that it is fully 122 utilized (100%). Defining what utilization means is 123 application-dependent and out of the scope of RSerPool. However, it 124 is required that all pool elements of the same pool using load 125 information have the same definition of load. 127 For example, load may define the current amount of users out of a 128 maximum on a FTP server, the CPU usage of a database server or the 129 memory utilization of a compute service. 131 2.2 Weight 133 Weight defines a pool element's service capacity relatively to other 134 pool elements of the same pool. Theoretically, there is no upper 135 limit for weight values (although limited by datatype size). Defining 136 what value weights compare is application-dependent and out of the 137 scope of RSerPool. However, it is required that all pool elements of 138 the same pool using weight information have the same definition of 139 weight. 141 A weight of 0 denotes that the pool element is not capable of 142 providing any service, a weight of 2*n denotes that the pool element 143 is capable of providing a two times better service than a pool 144 element having weight n. 146 For example, weight may define a compute service's computation 147 capacity. That is, a pool element of weight 100 will complete a work 148 package in half of the time compared to a pool element of weight 50. 150 3. Static Policies 152 3.1 Round Robin Policy 154 3.1.1 Description 156 The Round Robin (RR) policy is a very simple and efficient policy 157 which requires state. This policy is denoted as the default policy 158 and MUST be supported by all RSerPool components. 160 3.1.2 Name Server Considerations 162 The name server SHOULD hold the pool elements of each server pool in 163 a circular list and SHOULD store a pointer to one of the elements, 164 called the head. On reception of a name resolution request the name 165 server SHOULD return the pool elements from the circular list 166 starting with head. Then head SHOULD be advanced by one element. 168 Using this algorithm it is made sure that not all lists presented to 169 the pool users start with the same element. 171 3.1.3 Pool User Considerations 173 A pool user SHOULD use the list of pool elements returned by the name 174 server in a round robin fashion, starting with the first. If all 175 elements of the list have been used it should start from the 176 beginning again until the information is out of date. 178 3.1.4 Pool Member Selection Policy Parameter 180 0 1 2 3 181 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 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Param Type = 0x6 | Length = 0x8 | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Policy=0x1 | (reserved) | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 188 o Reserved: 24 bits, SHOULD be set to 0. 190 3.2 Weighted Round Robin Policy 192 3.2.1 Description 194 The Weighted Round Robin (WRR) policy is a generalization of the RR 195 policy. If all weights are 1 then WRR is just RR. 197 3.2.2 Name Server Considerations 199 The name server SHOULD follow the same rules as for RR but initialize 200 and modify the circular list differently. The name server puts each 201 pool element possibly multiple times into the list such that: 202 o The ratio of the number of occurrences of a pool element to the 203 list length is the same as the ratio of the weight of that pool 204 element to the sum of weights. 205 o Each pool element is inserted as distributed as possible in the 206 circular list. 208 3.2.3 Pool User Considerations 210 The pool user SHOULD follow the same rules as for RR. 212 3.2.4 Pool Member Selection Policy Parameter 214 0 1 2 3 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Param Type = 0x6 | Length = 0x8 | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Policy=0x2 | Weight | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 222 o Weight: Weight constant for the WRR process. 224 3.3 Random Policy 226 3.3.1 Description 228 The Random (RAND) policy is a very simple stateless policy. 230 3.3.2 Name Server Considerations 232 The name server selects at most the requested number of pool elements 233 from the list of pool elements. Each element MUST NOT be reported 234 more than once to the pool user. 236 3.3.3 Pool User Considerations 238 Each time the pool user must select one pool element it does this by 239 randomly selecting one element from the list of pool elements 240 received from the name server. 242 3.3.4 Pool Member Selection Policy Parameter 244 0 1 2 3 245 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 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Param Type = 0x6 | Length = 0x8 | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Policy=0x3 | (reserved) | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 252 o Reserved: 24 bits, SHOULD be set to 0. 254 3.4 Weighted Random Policy 256 3.4.1 Description 258 The Weighted Random (WRAND) policy is a generalization of the RAND 259 policy, adding a weight for each pool element entry. RAND is equal to 260 WRAND having all weights set to 1. 262 3.4.2 Name Server Considerations 264 The name server SHOULD select at most the requested number of pool 265 elements randomly from the list of pool elements. Each element MUST 266 NOT be reported more than once to the pool user. The probability of 267 selecting a pool element should be the ratio of the weight of that 268 pool element to the sum of weights. 270 3.4.3 Pool User Considerations 272 Each time the pool user must select one pool element it does this by 273 randomly selecting one element from the list of pool elements 274 received from the name server. 276 3.4.4 Pool Member Selection Policy Parameter 278 0 1 2 3 279 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 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Param Type = 0x6 | Length = 0x8 | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Policy=0x4 | Weight | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 286 o Weight: Weight constant for the WRAND process. 288 4. Dynamic Policies 290 4.1 Least Used Policy 292 4.1.1 Description 294 The Least Used (LU) policy uses load information provided by the pool 295 elements to select the lowest-loaded pool elements within the pool. 297 4.1.2 Name Server Considerations 299 The name server SHOULD select at most the requested number of pool 300 elements. Their load values SHOULD be the lowest possible ones within 301 the pool. Each element MUST NOT be reported more than once to the 302 pool user. If there is a choice of equal-loaded pool elements, round 303 robin selection SHOULD be made between these elements. The returned 304 list of pool elements MUST be sorted ascending by load value. 306 4.1.3 Pool User Considerations 308 The pool user should try to use the pool elements returned from the 309 list in the order returned by the name server. A subsequent call for 310 name resolution may result in the same list. Thereofore, it is 311 RECOMMENDED for a pool user to request multiple entries in order to 312 have a sufficient amount of feasible backup entries available. 314 4.1.4 Pool Member Selection Policy Parameter 316 0 1 2 3 317 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 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Param Type = 0x6 | Length = 0x8 | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Policy=0x5 | Load | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 324 o Load: Current load of the pool element. 326 4.2 Least Used with Degradation Policy 328 4.2.1 Description 330 The Least Used with Degradation (LUD) policy extends the LU policy by 331 a load degradation value describing the pool element's load increment 332 when a new service association is accepted. 334 4.2.2 Name Server Considerations 336 For every pool element entry, a degradation counter MUST be stored. 337 When a pool element entry is added or updated by registration or 338 reregistration, this counter MUST be set to 0. When an entry is 339 selected for being returned to a pool user, the internal degradation 340 counter MUST be incremented by the entry's load degradation constant. 341 The selection of pool element entries is handled like for LU, except 342 that the selected pool element entries SHOULD have the lowest 343 possible sum of load value + degradation counter. 345 4.2.3 Pool User Considerations 347 See LU policy. 349 4.2.4 Pool Member Selection Policy Parameter 351 0 1 2 3 352 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 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Param Type = 0x6 | Length = 0xc | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Policy=0x6 | Load | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 358 | (reserved) | Load Degradation | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 361 o Load: Current load of the pool element. 362 o Reserved: 8 bits, SHOULD be set to 0. 363 o Load Degradation: Load Degradation constant of the pool element. 365 4.3 Priority Least Used Policy 367 4.3.1 Description 369 The Priority Least Used (PLU) policy uses load information provided 370 by the pool elements to select the lowest-loaded pool elements within 371 the pool under the assumption that a new application request is 372 accepted by the pool elements. Therefore, the pool elements also have 373 to specify load degradation information. 375 Example: Pool elements A and B are loaded by 50%, but the load of A 376 will increase due to a new application request only by 10% while B 377 will be fully loaded. PLU allows to specify this load degradation in 378 the policy information, the selection is made on the lowest sum of 379 load and degradation value. That is, A will be selected (50+10=60) 380 instead of B (50+50=100). 382 4.3.2 Name Server Considerations 384 The name server SHOULD select at most the requested number of pool 385 elements. Their sums of load + degradation SHOULD be the lowest 386 possible ones within the pool. Each element MUST NOT be reported more 387 than once to the pool user. If there is a choice of equal-valued pool 388 element entries, round robin SHOULD be made between these elements. 389 The returned list of pool elements MUST be sorted ascending by the 390 sum of load and degradation value. 392 4.3.3 Pool User Considerations 394 The pool user should try to use the pool elements returned from the 395 list in the order returned by the name server. A subsequent call for 396 name resolution may result in the same list. Therefore, it is 397 RECOMMENDED for a pool user to request multiple entries in order to 398 have a sufficient amount of feasible backup entries available. 400 4.3.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 = 0xc | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Policy=0x7 | Load | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 409 | (reserved) | Load Degradation | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 412 o Load: Current load of the pool element. 413 o Load Degradation: Load Degradation constant of the pool element. 415 4.4 Randomized Least Used Policy 417 4.4.1 Description 419 The Randomized Least Used (RLU) policy combines LU and WRAND. That 420 is, the pool element entries are selected randomly; the probability 421 for a pool element entry to be selected is the ratio of 100%-load to 422 the sum of all pool elements' load values. 424 4.4.2 Name Server Considerations 426 The name server SHOULD behave like WRAND, having every PE's weight 427 set to (0xffffff - Load value provided by the pool element). 429 4.4.3 Pool User Considerations 431 See WRAND policy. 433 4.4.4 Pool Member Selection Policy Parameter 435 0 1 2 3 436 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 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Param Type = 0x7 | Length = 0x8 | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Policy=0x9 | Load | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 443 o Load: Current load of the pool element. 445 5. Security Considerations 447 The security threats regarding RSerPool have been analyzed in 448 RSerPool threats [6]. The server policy descriptions in this 449 document do not add any other threats. 451 6. IANA Considerations 453 IANA keeps a list of Policy Types which are 1 byte values. The Policy 454 values used in this document are: 456 Value Policy 457 ----- --------- 458 0x00 (reserved by IETF) 459 0x01 Round Robin 460 0x02 Weighted Round Robin 461 0x03 Random 462 0x04 Weighted Random 463 0x05 Least Used 464 0x06 Least Used with Degradation 465 0x07 Priority Least Used 466 0x09 Randomized Least Used 467 others (reserved by IETF) 469 7. References 471 7.1 Normative References 473 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 474 Levels", BCP 14, RFC 2119, March 1997. 476 [2] Bradner, S., "Intellectual Property Rights in IETF Technology", 477 BCP 79, RFC 3668, February 2004. 479 [3] Stewart, R., Xie, Q. and M. Tuexen, "Aggregate Server Access 480 Protocol (ASAP) and Endpoint Name Resolution (ENRP) 481 Parameters", draft-ietf-rserpool-common-param-05 (work in 482 progress), October 2003. 484 [4] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate 485 Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-08 486 (work in progress), October 2003. 488 [5] Xie, Q., Stewart, R. and M. Stillman, "Enpoint Name Resolution 489 Protocol (ENRP)", draft-ietf-rserpool-enrp-07 (work in 490 progress), October 2003. 492 [6] Stillman, M., "Threats Introduced by Rserpool and Requirements 493 for Security in response to Threats", 494 draft-ietf-rserpool-threats-02 (work in progress), October 2003. 496 7.2 Informative References 498 [7] Dreibholz, T., Rathgeb, E. and M. Tuexen, "Load Distribution 499 Performance of the Reliable Server Pooling Framework", Submitted 500 to Globecom 2004. 502 Authors' Addresses 504 Michael Tuexen 505 University of Applied Sciences Muenster 506 Stegerwaldstrasse 39 507 48565 Steinfurt, Nordrhein-Westfalen 508 Germany 510 EMail: tuexen@fh-muenster.de 512 Thomas Dreibholz 513 University of Duisburg-Essen, Institute for Experimental Mathematics 514 Ellernstrasse 29 515 45326 Essen, Nordrhein-Westfalen 516 Germany 518 Phone: +49 201 183-7637 519 Fax: +49 201 183-7673 520 EMail: dreibh@exp-math.uni-essen.de 521 URI: http://www.exp-math.uni-essen.de/~dreibh/ 523 Intellectual Property Statement 525 The IETF takes no position regarding the validity or scope of any 526 Intellectual Property Rights or other rights that might be claimed to 527 pertain to the implementation or use of the technology described in 528 this document or the extent to which any license under such rights 529 might or might not be available; nor does it represent that it has 530 made any independent effort to identify any such rights. Information 531 on the IETF's procedures with respect to rights in IETF Documents can 532 be found in BCP 78 and BCP 79. 534 Copies of IPR disclosures made to the IETF Secretariat and any 535 assurances of licenses to be made available, or the result of an 536 attempt made to obtain a general license or permission for the use of 537 such proprietary rights by implementers or users of this 538 specification can be obtained from the IETF on-line IPR repository at 539 http://www.ietf.org/ipr. 541 The IETF invites any interested party to bring to its attention any 542 copyrights, patents or patent applications, or other proprietary 543 rights that may cover technology that may be required to implement 544 this standard. Please address the information to the IETF at 545 ietf-ipr@ietf.org. 547 Disclaimer of Validity 549 This document and the information contained herein are provided on an 550 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 551 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 552 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 553 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 554 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 555 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 557 Copyright Statement 559 Copyright (C) The Internet Society (2004). This document is subject 560 to the rights, licenses and restrictions contained in BCP 78, and 561 except as set forth therein, the authors retain all their rights. 563 Acknowledgment 565 Funding for the RFC Editor function is currently provided by the 566 Internet Society.