draft-ietf-rserpool-policies-10.txt   rfc5356.txt 
Network Working Group T. Dreibholz Network Working Group T. Dreibholz
Internet-Draft University of Duisburg-Essen Request for Comments: 5356 University of Duisburg-Essen
Intended status: Experimental M. Tuexen Category: Experimental M. Tuexen
Expires: January 15, 2009 Muenster Univ. of Applied Sciences Muenster Univ. of Applied Sciences
July 14, 2008 September 2008
Reliable Server Pooling Policies Reliable Server Pooling Policies
draft-ietf-rserpool-policies-10.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Status of This Memo
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 15, 2009. This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Abstract Abstract
This document describes server pool policies for Reliable Server This document describes server pool policies for Reliable Server
Pooling including considerations for implementing them at ENRP Pooling (RSerPool) including considerations for implementing them at
servers and pool users. Endpoint Handlespace Redundancy Protocol (ENRP) servers and pool
users.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions .....................................................3
3. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 3. Terminology and Definitions .....................................3
3.1. Load . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Load .......................................................3
3.2. Weight . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Weight .....................................................3
4. Non-Adaptive Policies . . . . . . . . . . . . . . . . . . . . 5 4. Non-Adaptive Policies ...........................................4
4.1. Round Robin Policy . . . . . . . . . . . . . . . . . . . . 5 4.1. Round Robin Policy .........................................4
4.1.1. Description . . . . . . . . . . . . . . . . . . . . . 5 4.1.1. Description .........................................4
4.1.2. ENRP Server Considerations . . . . . . . . . . . . . . 5 4.1.2. ENRP Server Considerations ..........................4
4.1.3. Pool User Considerations . . . . . . . . . . . . . . . 5 4.1.3. Pool User Considerations ............................4
4.1.4. Pool Member Selection Policy Parameter . . . . . . . . 5 4.1.4. Pool Member Selection Policy Parameter ..............4
4.2. Weighted Round Robin Policy . . . . . . . . . . . . . . . 6 4.2. Weighted Round Robin Policy ................................5
4.2.1. Description . . . . . . . . . . . . . . . . . . . . . 6 4.2.1. Description .........................................5
4.2.2. ENRP Server Considerations . . . . . . . . . . . . . . 6 4.2.2. ENRP Server Considerations ..........................5
4.2.3. Pool User Considerations . . . . . . . . . . . . . . . 6 4.2.3. Pool User Considerations ............................5
4.2.4. Pool Member Selection Policy Parameter . . . . . . . . 6 4.2.4. Pool Member Selection Policy Parameter ..............5
4.3. Random Policy . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Random Policy ..............................................5
4.3.1. Description . . . . . . . . . . . . . . . . . . . . . 6 4.3.1. Description .........................................5
4.3.2. ENRP Server Considerations . . . . . . . . . . . . . . 7 4.3.2. ENRP Server Considerations ..........................6
4.3.3. Pool User Considerations . . . . . . . . . . . . . . . 7 4.3.3. Pool User Considerations ............................6
4.3.4. Pool Member Selection Policy Parameter . . . . . . . . 7 4.3.4. Pool Member Selection Policy Parameter ..............6
4.4. Weighted Random Policy . . . . . . . . . . . . . . . . . . 7 4.4. Weighted Random Policy .....................................6
4.4.1. Description . . . . . . . . . . . . . . . . . . . . . 7 4.4.1. Description .........................................6
4.4.2. ENRP Server Considerations . . . . . . . . . . . . . . 7 4.4.2. ENRP Server Considerations ..........................6
4.4.3. Pool User Considerations . . . . . . . . . . . . . . . 7 4.4.3. Pool User Considerations ............................6
4.4.4. Pool Member Selection Policy Parameter . . . . . . . . 8 4.4.4. Pool Member Selection Policy Parameter ..............7
4.5. Priority Policy . . . . . . . . . . . . . . . . . . . . . 8 4.5. Priority Policy ............................................7
4.5.1. Description . . . . . . . . . . . . . . . . . . . . . 8 4.5.1. Description .........................................7
4.5.2. ENRP Server Considerations . . . . . . . . . . . . . . 8 4.5.2. ENRP Server Considerations ..........................7
4.5.3. Pool Element Considerations . . . . . . . . . . . . . 8 4.5.3. Pool Element Considerations .........................7
4.5.4. Pool Member Selection Policy Parameter . . . . . . . . 8 4.5.4. Pool Member Selection Policy Parameter ..............7
5. Adaptive Policies . . . . . . . . . . . . . . . . . . . . . . 9 5. Adaptive Policies ...............................................8
5.1. Least Used Policy . . . . . . . . . . . . . . . . . . . . 9 5.1. Least Used Policy ..........................................8
5.1.1. Description . . . . . . . . . . . . . . . . . . . . . 9 5.1.1. Description .........................................8
5.1.2. ENRP Server Considerations . . . . . . . . . . . . . . 9 5.1.2. ENRP Server Considerations ..........................8
5.1.3. Pool User Considerations . . . . . . . . . . . . . . . 9 5.1.3. Pool User Considerations ............................8
5.1.4. Pool Member Selection Policy Parameter . . . . . . . . 9 5.1.4. Pool Member Selection Policy Parameter ..............8
5.2. Least Used with Degradation Policy . . . . . . . . . . . . 10 5.2. Least Used with Degradation Policy .........................9
5.2.1. Description . . . . . . . . . . . . . . . . . . . . . 10 5.2.1. Description .........................................9
5.2.2. ENRP Server Considerations . . . . . . . . . . . . . . 10 5.2.2. ENRP Server Considerations ..........................9
5.2.3. Pool User Considerations . . . . . . . . . . . . . . . 10 5.2.3. Pool User Considerations ............................9
5.2.4. Pool Member Selection Policy Parameter . . . . . . . . 10 5.2.4. Pool Member Selection Policy Parameter ..............9
5.3. Priority Least Used Policy . . . . . . . . . . . . . . . . 11 5.3. Priority Least Used Policy ................................10
5.3.1. Description . . . . . . . . . . . . . . . . . . . . . 11 5.3.1. Description ........................................10
5.3.2. ENRP Server Considerations . . . . . . . . . . . . . . 11 5.3.2. ENRP Server Considerations .........................10
5.3.3. Pool User Considerations . . . . . . . . . . . . . . . 11 5.3.3. Pool User Considerations ...........................10
5.3.4. Pool Member Selection Policy Parameter . . . . . . . . 11 5.3.4. Pool Member Selection Policy Parameter .............10
5.4. Randomized Least Used Policy . . . . . . . . . . . . . . . 12 5.4. Randomized Least Used Policy ..............................11
5.4.1. Description . . . . . . . . . . . . . . . . . . . . . 12 5.4.1. Description ........................................11
5.4.2. ENRP Server Considerations . . . . . . . . . . . . . . 12 5.4.2. ENRP Server Considerations .........................11
5.4.3. Pool User Considerations . . . . . . . . . . . . . . . 12 5.4.3. Pool User Considerations ...........................11
5.4.4. Pool Member Selection Policy Parameter . . . . . . . . 12 5.4.4. Pool Member Selection Policy Parameter .............11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations ........................................11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations ............................................12
7.1. A New Table for RSerPool Policy Types . . . . . . . . . . 13 7.1. A New Table for RSerPool Policy Types .....................12
8. Reference Implementation . . . . . . . . . . . . . . . . . . . 14 8. Reference Implementation .......................................13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References .....................................................13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References ......................................13
9.2. Informative References . . . . . . . . . . . . . . . . . . 15 9.2. Informative References ....................................14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
1. Introduction 1. Introduction
The protocols defined in [I-D.ietf-rserpool-enrp], The protocols defined in [RFC5353], [RFC5352], and [RFC5354] support
[I-D.ietf-rserpool-asap] and [I-D.ietf-rserpool-common-param] support
a variety of server policies. Some of the policies use dynamic load a variety of server policies. Some of the policies use dynamic load
information of the pool elements and others do not. Therefore, we information of the pool elements and others do not. Therefore, we
classify them as adaptive and non-adaptive. The selection of the classify them as adaptive and non-adaptive. The selection of the
pool element is performed by two different entities, the ENRP server pool element is performed by two different entities, the ENRP server
and the pool user. Some of the consequences for policies which are and the pool user. Some of the consequences for policies that are
not stateless are described in [ICN2005] and [LCN2005]. not stateless are described in [ICN2005] and [LCN2005].
Therefore this document describes not only packet formats but also Therefore, this document describes not only packet formats but also
gives a detailed description of the procedures to be followed at the gives a detailed description of the procedures to be followed at the
ENRP servers and the pool users to implement each server policy. ENRP servers and the pool users to implement each server policy.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Terminology and Definitions 3. Terminology and Definitions
3.1. Load 3.1. Load
The term load is a value specifying how much a pool element's The term load is a value specifying how much a pool element's
resources are currently utilized. 0x00000000 states, that the pool resources are currently utilized. 0x00000000 states that the pool
element is not utilized (0%), 0xffffffff states that it is fully element is not utilized (0%); 0xffffffff states that it is fully
utilized (100%). Defining what utilization means is application- utilized (100%). Defining what utilization means is application-
dependent and out of the scope of RSerPool. However, it is required dependent and out of the scope of RSerPool. However, it is required
that all pool elements of the same pool using load information have that all pool elements of the same pool using load information have
the same definition of load. the same definition of load.
For example, load may define the current amount of users out of a For example, load may define the current amount of users out of a
maximum on a FTP server, the CPU usage of a database server or the maximum on an FTP server, the CPU usage of a database server, or the
memory utilization of a compute service. memory utilization of a compute service.
3.2. Weight 3.2. Weight
Weight defines a pool element's service capacity relatively to other Weight defines a pool element's service capacity relative to other
pool elements of the same pool. Theoretically, there is no upper pool elements of the same pool. Theoretically, there is no upper
limit for weight values (although limited by datatype size). limit for weight values (although limited by datatype size).
Defining what value weights compare is application-dependent and out Defining what value weights compare is application-dependent and out
of the scope of RSerPool. However, it is required that all pool of the scope of RSerPool. However, it is required that all pool
elements of the same pool using weight information have the same elements of the same pool using weight information have the same
definition of weight. definition of weight.
A weight of 0 denotes that the pool element is not capable of A weight of 0 denotes that the pool element is not capable of
providing any service, a higher weight of denotes that the pool providing any service; a higher weight denotes that the pool element
element is capable of providing better service than a pool element is capable of providing better service than a pool element having a
having a lower weight. lower weight.
For example, weight may define a compute service's computation For example, weight may define a compute service's computation
capacity. That is, a pool element of weight 100 will complete a work capacity. That is, a pool element of weight 100 will complete a work
package in half of the time compared to a pool element of weight 50. package in half the time compared to a pool element of weight 50.
4. Non-Adaptive Policies 4. Non-Adaptive Policies
4.1. Round Robin Policy 4.1. Round Robin Policy
4.1.1. Description 4.1.1. Description
The Round Robin (RR) policy is a very simple and efficient policy The Round Robin (RR) policy is a very simple and efficient policy
which requires state. This policy is denoted as the default policy that requires state. This policy is denoted as the default policy
and MUST be supported by all RSerPool components. and MUST be supported by all RSerPool components.
4.1.2. ENRP Server Considerations 4.1.2. ENRP Server Considerations
The ENRP server SHOULD hold the pool elements of each server pool in The ENRP server SHOULD hold the pool elements of each server pool in
a circular list and SHOULD store a pointer to one of the elements, a circular list and SHOULD store a pointer to one of the elements,
called the head. On reception of a handle resolution request the called the head. On reception of a handle resolution request, the
ENRP server SHOULD return the pool elements from the circular list ENRP server SHOULD return the pool elements from the circular list,
starting with head. Then head SHOULD be advanced by one element. starting with head. Then the head SHOULD be advanced by one element.
Using this algorithm it is made sure that not all lists presented to Using this algorithm ensures that not all lists presented to the pool
the pool users start with the same element. users start with the same element.
4.1.3. Pool User Considerations 4.1.3. Pool User Considerations
A pool user SHOULD use the list of pool elements returned by the ENRP A pool user SHOULD use the list of pool elements returned by the ENRP
server in a round robin fashion, starting with the first. If all server in a round robin fashion, starting with the first. If all
elements of the list have been used it should start from the elements of the list have been used, it should start from the
beginning again until the information is out of date. beginning again until the information is out of date.
4.1.4. Pool Member Selection Policy Parameter 4.1.4. Pool Member Selection Policy Parameter
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Param Type = 0x8 | Length = 0x8 | | Param Type = 0x8 | Length = 0x8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Policy Type = 0x00000001 | | Policy Type = 0x00000001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2. Weighted Round Robin Policy 4.2. Weighted Round Robin Policy
4.2.1. Description 4.2.1. Description
The Weighted Round Robin (WRR) policy is a generalization of the RR The Weighted Round Robin (WRR) policy is a generalization of the RR
policy. If all weights are 1 then WRR is just RR. policy. If all weights are 1, then WRR is just RR.
4.2.2. ENRP Server Considerations 4.2.2. ENRP Server Considerations
The ENRP server SHOULD follow the same rules as for RR but initialize The ENRP server SHOULD follow the same rules as RR but initialize and
and modify the circular list differently. The ENRP server puts each modify the circular list differently. The ENRP server puts each pool
pool element possibly multiple times into the list such that: element, possibly, multiple times into the list such that:
o The ratio of the number of occurrences of a pool element to the o The ratio of the number of occurrences of a pool element to the
list length is the same as the ratio of the weight of that pool list length is the same as the ratio of the weight of that pool
element to the sum of weights. element to the sum of weights.
o Each pool element is inserted as distributed as possible in the o The multiple entries of each pool element should be as evenly
circular list. distributed as possible in the circular list.
4.2.3. Pool User Considerations 4.2.3. Pool User Considerations
The pool user SHOULD follow the same rules as for RR. The pool user SHOULD follow the same rules as RR.
4.2.4. Pool Member Selection Policy Parameter 4.2.4. Pool Member Selection Policy Parameter
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Param Type = 0x8 | Length = 0xc | | Param Type = 0x8 | Length = 0xc |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Policy Type = 0x00000002 | | Policy Type = 0x00000002 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 7, line 7 skipping to change at page 6, line 7
process. process.
4.3. Random Policy 4.3. Random Policy
4.3.1. Description 4.3.1. Description
The Random (RAND) policy is a very simple stateless policy. The Random (RAND) policy is a very simple stateless policy.
4.3.2. ENRP Server Considerations 4.3.2. ENRP Server Considerations
The ENRP server selects at most the requested number of pool elements The ENRP server selects, at most, the requested number of pool
from the list of pool elements. Each element MUST NOT be reported elements from the list of pool elements. Each element MUST NOT be
more than once to the pool user. reported more than once to the pool user.
4.3.3. Pool User Considerations 4.3.3. Pool User Considerations
Each time the pool user must select one pool element it does this by Each time the pool user must select one pool element, it does this by
randomly selecting one element from the list of pool elements randomly selecting one element from the list of pool elements
received from the ENRP server. received from the ENRP server.
4.3.4. Pool Member Selection Policy Parameter 4.3.4. Pool Member Selection Policy Parameter
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Param Type = 0x8 | Length = 0x8 | | Param Type = 0x8 | Length = 0x8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 7, line 37 skipping to change at page 6, line 37
4.4. Weighted Random Policy 4.4. Weighted Random Policy
4.4.1. Description 4.4.1. Description
The Weighted Random (WRAND) policy is a generalization of the RAND The Weighted Random (WRAND) policy is a generalization of the RAND
policy, adding a weight for each pool element entry. RAND is equal policy, adding a weight for each pool element entry. RAND is equal
to WRAND having all weights set to 1. to WRAND having all weights set to 1.
4.4.2. ENRP Server Considerations 4.4.2. ENRP Server Considerations
The ENRP server SHOULD select at most the requested number of pool The ENRP server SHOULD select, at most, the requested number of pool
elements randomly from the list of pool elements. Each element MUST elements randomly from the list of pool elements. Each element MUST
NOT be reported more than once to the pool user. The probability of NOT be reported more than once to the pool user. The probability of
selecting a pool element should be the ratio of the weight of that selecting a pool element should be the ratio of the weight of that
pool element to the sum of weights. pool element to the sum of weights.
4.4.3. Pool User Considerations 4.4.3. Pool User Considerations
Each time the pool user must select one pool element it does this by Each time the pool user must select one pool element, it does this by
randomly selecting one element from the list of pool elements randomly selecting one element from the list of pool elements
received from the ENRP server. received from the ENRP server.
4.4.4. Pool Member Selection Policy Parameter 4.4.4. Pool Member Selection Policy Parameter
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Param Type = 0x8 | Length = 0xc | | Param Type = 0x8 | Length = 0xc |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 9, line 18 skipping to change at page 8, line 18
5.1. Least Used Policy 5.1. Least Used Policy
5.1.1. Description 5.1.1. Description
The Least Used (LU) policy uses load information provided by the pool The Least Used (LU) policy uses load information provided by the pool
elements to select the lowest-loaded pool elements within the pool. elements to select the lowest-loaded pool elements within the pool.
5.1.2. ENRP Server Considerations 5.1.2. ENRP Server Considerations
The ENRP server SHOULD select at most the requested number of pool The ENRP server SHOULD select, at most, the requested number of pool
elements. Their load values SHOULD be the lowest possible ones elements. Their load values SHOULD be the lowest possible ones
within the pool. Each element MUST NOT be reported more than once to within the pool. Each element MUST NOT be reported more than once to
the pool user. If there is a choice of equal-loaded pool elements, the pool user. If there is a choice of equal-loaded pool elements,
round robin selection SHOULD be made among these elements. The round robin selection SHOULD be made among these elements. The
returned list of pool elements MUST be sorted ascending by load returned list of pool elements MUST be sorted in ascending order by
value. load value.
5.1.3. Pool User Considerations 5.1.3. Pool User Considerations
The pool user should try to use the pool elements returned from the The pool user should try to use the pool elements returned from the
list in the order returned by the ENRP server. A subsequent call for list in the order returned by the ENRP server. A subsequent call for
handle resolution may result in the same list. Thereofore, it is handle resolution may result in the same list. Therefore, it is
RECOMMENDED for a pool user to request multiple entries in order to RECOMMENDED for a pool user to request multiple entries in order to
have a sufficient amount of feasible backup entries available. have a sufficient amount of feasible backup entries available.
5.1.4. Pool Member Selection Policy Parameter 5.1.4. Pool Member Selection Policy Parameter
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Param Type = 0x8 | Length = 0xc | | Param Type = 0x8 | Length = 0xc |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 10, line 16 skipping to change at page 9, line 16
5.2.1. Description 5.2.1. Description
The Least Used with Degradation (LUD) policy extends the LU policy by The Least Used with Degradation (LUD) policy extends the LU policy by
a load degradation value describing the pool element's load increment a load degradation value describing the pool element's load increment
when a new service association is accepted. when a new service association is accepted.
5.2.2. ENRP Server Considerations 5.2.2. ENRP Server Considerations
For every pool element entry, a degradation counter MUST be stored. For every pool element entry, a degradation counter MUST be stored.
When a pool element entry is added or updated by registration or When a pool element entry is added or updated by registration or re-
reregistration, this counter MUST be set to 0. When an entry is registration, this counter MUST be set to 0. When an entry is
selected for being returned to a pool user, the internal degradation selected for being returned to a pool user, the internal degradation
counter MUST be incremented by 1. The selection of pool element counter MUST be incremented by 1. The selection of pool element
entries is handled like for LU, except that the selected pool element entries is handled like for LU, except that the selected pool element
entries SHOULD have the lowest possible sum of load value + entries SHOULD have the lowest possible sum of load value +
degradation counter * load degradation value. degradation counter * load degradation value.
5.2.3. Pool User Considerations 5.2.3. Pool User Considerations
See LU policy. See LU policy.
skipping to change at page 11, line 17 skipping to change at page 10, line 17
5.3.1. Description 5.3.1. Description
The Priority Least Used (PLU) policy uses load information provided The Priority Least Used (PLU) policy uses load information provided
by the pool elements to select the lowest-loaded pool elements within by the pool elements to select the lowest-loaded pool elements within
the pool under the assumption that a new application request is the pool under the assumption that a new application request is
accepted by the pool elements. Therefore, the pool elements also accepted by the pool elements. Therefore, the pool elements also
have to specify load degradation information. have to specify load degradation information.
Example: Pool elements A and B are loaded by 50%, but the load of A Example: Pool elements A and B are loaded by 50%, but the load of A
will increase due to a new application request only by 10% while B will increase due to a new application request only by 10% while B
will be fully loaded. PLU allows to specify this load degradation in will be fully loaded. PLU allows the specification of this load
the policy information, the selection is made on the lowest sum of degradation in the policy information; the selection is made on the
load and degradation value. That is, A will be selected (50+10=60) lowest sum of load and degradation value. That is, A will be
instead of B (50+50=100). selected (50+10=60) instead of B (50+50=100).
5.3.2. ENRP Server Considerations 5.3.2. ENRP Server Considerations
The ENRP server SHOULD select at most the requested number of pool The ENRP server SHOULD select, at most, the requested number of pool
elements. Their sums of load + degradation SHOULD be the lowest elements. Their sums of load + degradation SHOULD be the lowest
possible ones within the pool. Each element MUST NOT be reported possible ones within the pool. Each element MUST NOT be reported
more than once to the pool user. If there is a choice of equal- more than once to the pool user. If there is a choice of equal-
valued pool element entries, round robin SHOULD be made among these valued pool element entries, round robin SHOULD be made among these
elements. The returned list of pool elements MUST be sorted elements. The returned list of pool elements MUST be sorted
ascending by the sum of load and degradation value. ascending by the sum of load and degradation value.
5.3.3. Pool User Considerations 5.3.3. Pool User Considerations
The pool user should try to use the pool elements returned from the The pool user should try to use the pool elements returned from the
skipping to change at page 12, line 19 skipping to change at page 11, line 17
o Load Degradation (32 bits, unsigned integer): Load Degradation o Load Degradation (32 bits, unsigned integer): Load Degradation
constant of the pool element. constant of the pool element.
5.4. Randomized Least Used Policy 5.4. Randomized Least Used Policy
5.4.1. Description 5.4.1. Description
The Randomized Least Used (RLU) policy combines LU and WRAND. That The Randomized Least Used (RLU) policy combines LU and WRAND. That
is, the pool element entries are selected randomly. The probability is, the pool element entries are selected randomly. The probability
for a pool element entry A, utilized with load_A, to be selected is for a pool element entry A, utilized with load_A, to be selected is
(0xFFFFFFFF - load_A) / (sum(0xFFFFFFFF-load_x)), i.e. this PE's (0xFFFFFFFF - load_A) / (sum(0xFFFFFFFF-load_x)), i.e., this PE's
unload part related to the whole pool unload rate. unload part related to the whole pool unload rate.
5.4.2. ENRP Server Considerations 5.4.2. ENRP Server Considerations
The ENRP server SHOULD behave like WRAND, having every PE's weight The ENRP server SHOULD behave like WRAND, having every PE's weight
set to (0xffffffff - Load value provided by the pool element). set to (0xffffffff -- load value provided by the pool element).
5.4.3. Pool User Considerations 5.4.3. Pool User Considerations
See WRAND policy. See WRAND policy.
5.4.4. Pool Member Selection Policy Parameter 5.4.4. Pool Member Selection Policy Parameter
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 49 skipping to change at page 11, line 47
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Load | | Load |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Load (32 bits, unsigned integer): Current load of the pool o Load (32 bits, unsigned integer): Current load of the pool
element. element.
6. Security Considerations 6. Security Considerations
The security threats regarding RSerPool have been analyzed in The security threats regarding RSerPool have been analyzed in
RSerPool threats [I-D.ietf-rserpool-threats]. The server policy RSerPool threats [RFC5355]. The server policy descriptions in this
descriptions in this document do not add any other threats. document do not add any other threats.
7. IANA Considerations 7. IANA Considerations
[NOTE to RFC-Editor: This document (RFC 5356) is the reference for all registrations
described in this section. All registrations have been listed on the
"RFCXXXX" is to be replaced by the RFC number you assign this RSerPool Parameters page.
document.
]
This document (RFCXXX) is the reference for all registrations
described in this section. All registrations need to be listed on an
RSerPool specific page.
7.1. A New Table for RSerPool Policy Types 7.1. A New Table for RSerPool Policy Types
RSerPool Policy Types which are 4 byte values have to be maintained RSerPool policy types that are 4-byte values are maintained by IANA.
by IANA. The format of the policy type value is defined as follows: The format of the policy type value is defined as follows:
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X|A| Policy Number | |X|A| Policy Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o X: If set to 1, the policy is user-defined and not standardized. o X: If set to 1, the policy is user defined and not standardized.
All standards policies reserved by the IETF use X=0. All standards policies reserved by the IETF use X=0.
o A: If set to 1, the policy is adaptive. Otherwise, it is non- o A: If set to 1, the policy is adaptive. Otherwise, it is non-
adaptive. adaptive.
o Policy Number: The actual number of the policy. o Policy Number: The actual number of the policy.
Nine initial Policy Types should be assigned and maintained in a new Nine initial policy types have been assigned and are maintained in a
table "RSerPool Policy Types": new table, "RSerPool Policy Types":
Value Policy Reference Value Policy Reference
----- --------- --------- ----- --------- ---------
0x00000000 (reserved, invalid value) RFCXXXX 0x00000000 (reserved, invalid value) RFC 5356
0x00000001 Round Robin RFCXXXX 0x00000001 Round Robin RFC 5356
0x00000002 Weighted Round Robin RFCXXXX 0x00000002 Weighted Round Robin RFC 5356
0x00000003 Random RFCXXXX 0x00000003 Random RFC 5356
0x00000004 Weighted Random RFCXXXX 0x00000004 Weighted Random RFC 5356
0x00000005 Priority RFCXXXX 0x00000005 Priority RFC 5356
0x00000006 (reserved by IETF) RFCXXXX 0x00000006 (reserved by IETF) RFC 5356
... ...
0x3fffffff (reserved by IETF) RFCXXXX 0x3fffffff (reserved by IETF) RFC 5356
0x40000000 (reserved, invalid value) RFCXXXX 0x40000000 (reserved, invalid value) RFC 5356
0x40000001 Least Used RFCXXXX 0x40000001 Least Used RFC 5356
0x40000002 Least Used with Degradation RFCXXXX 0x40000002 Least Used with Degradation RFC 5356
0x40000003 Priority Least Used RFCXXXX 0x40000003 Priority Least Used RFC 5356
0x40000004 Randomized Least Used RFCXXXX 0x40000004 Randomized Least Used RFC 5356
0x40000005 (reserved by IETF) RFCXXXX 0x40000005 (reserved by IETF) RFC 5356
... ...
0x7fffffff (reserved by IETF) RFCXXXX 0x7fffffff (reserved by IETF) RFC 5356
0x80000000 (private use, non-standard policy) RFCXXXX 0x80000000 (private use, non-standard policy) RFC 5356
... ...
0xffffffff (private use, non-standard policy) RFCXXXX 0xffffffff (private use, non-standard policy) RFC 5356
For registering at IANA an RSerPool Policy Type in this table a Requests to register an RSerPool policy type in this table should be
request has to be made to assign such a number. This number must be sent to IANA. The number must be unique and use the appropriate
unique and use the appropiate upper bits. The "Specification upper bits. The "Specification Required" policy of [RFC5226] MUST be
Required" policy of [RFC5226] MUST be applied. applied.
The Policy Type space from 0x80000000 to 0xffffffff is designated for The policy type space from 0x80000000 to 0xffffffff is designated for
private use. private use.
8. Reference Implementation 8. Reference Implementation
The reference implementation of RSerPool and the policies described A reference implementation of RSerPool and the policies described in
in this document is available at [RSerPoolPage] and described in this document is available at [RSerPoolPage] and described in
[Dre2006]. [Dre2006].
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
IANA Considerations Section in RFCs", BCP 26, RFC 5226, an IANA Considerations Section in RFCs", BCP 26,
May 2008. RFC 5226, May 2008.
[I-D.ietf-rserpool-common-param] [RFC5354] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen,
Stewart, R., Xie, Q., Stillman, M., and M. Tuexen,
"Aggregate Server Access Protocol (ASAP) and Endpoint "Aggregate Server Access Protocol (ASAP) and Endpoint
Handlespace Redundancy Protocol (ENRP) Parameters", Handlespace Redundancy Protocol (ENRP) Parameters",
draft-ietf-rserpool-common-param-17 (work in progress), RFC 5354, September 2008.
May 2008.
[I-D.ietf-rserpool-asap] [RFC5352] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen,
Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate Server Access Protocol (ASAP)", RFC 5352,
"Aggregate Server Access Protocol (ASAP)", September 2008.
draft-ietf-rserpool-asap-21 (work in progress), July 2008.
[I-D.ietf-rserpool-enrp] [RFC5353] Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and
Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. A. Silverton, "Endpoint Handlespace Redundancy
Silverton, "Endpoint Handlespace Redundancy Protocol Protocol (ENRP)", RFC 5353, September 2008.
(ENRP)", draft-ietf-rserpool-enrp-21 (work in progress),
July 2008.
[I-D.ietf-rserpool-threats] [RFC5355] Stillman, M., Ed., Gopal, R., Guttman, E., Holdrege,
Stillman, M., Gopal, R., Guttman, E., Holdrege, M., and S. M., and S. Sengodan, "Threats Introduced by Reliable
Sengodan, "Threats Introduced by RSerPool and Requirements Server Pooling (RSerPool) and Requirements for
for Security in Response to Threats", Security in Response to Threats", RFC 5355,
draft-ietf-rserpool-threats-15 (work in progress), September 2008.
July 2008.
9.2. Informative References 9.2. Informative References
[RSerPoolPage] [RSerPoolPage] Dreibholz, T., "Thomas Dreibholz's RSerPool Page",
Dreibholz, T., "Thomas Dreibholz's RSerPool Page", <http://tdrwww.iem.uni-due.de/dreibholz/rserpool/>.
URL: http://tdrwww.iem.uni-due.de/dreibholz/rserpool/.
[Dre2006] Dreibholz, T., "Reliable Server Pooling -- Evaluation, [Dre2006] Dreibholz, T., "Reliable Server Pooling --
Optimization and Extension of a Novel IETF Architecture", Evaluation, Optimization and Extension of a Novel
Ph.D. Thesis University of Duisburg-Essen, Faculty of IETF Architecture", Ph.D. Thesis University of
Economics, Institute for Computer Science and Business Duisburg-Essen, Faculty of Economics, Institute for
Information Systems, URL: http:// Computer Science and Business Information Systems,
duepublico.uni-duisburg-essen.de/servlets/DerivateServlet/ March 2007, <http://duepublico.uni-duisburg-essen.de/
Derivate-16326/Dre2006-final.pdf, March 2007. servlets/DerivateServlet/Derivate-16326/
Dre2006-final.pdf>.
[LCN2005] Dreibholz, T. and E. Rathgeb, "On the Performance of [LCN2005] Dreibholz, T. and E. Rathgeb, "On the Performance of
Reliable Server Pooling Systems", Proceedings of the 30th Reliable Server Pooling Systems", Proceedings of the
IEEE Local Computer Networks Conference, November 2005. 30th IEEE Local Computer Networks Conference,
November 2005.
[ICN2005] Dreibholz, T., Rathgeb, E., and M. Tuexen, "Load [ICN2005] Dreibholz, T., Rathgeb, E., and M. Tuexen, "Load
Distribution Performance of the Reliable Server Pooling Distribution Performance of the Reliable Server
Framework", Proceedings of the 4th IEEE International Pooling Framework", Proceedings of the 4th IEEE
Conference on Networking, April 2005. International Conference on Networking, April 2005.
Authors' Addresses Authors' Addresses
Thomas Dreibholz Thomas Dreibholz
University of Duisburg-Essen, Institute for Experimental Mathematics University of Duisburg-Essen, Institute for Experimental Mathematics
Ellernstrasse 29 Ellernstrasse 29
45326 Essen, Nordrhein-Westfalen 45326 Essen, Nordrhein-Westfalen
Germany Germany
Phone: +49-201-1837637 Phone: +49-201-1837637
Fax: +49-201-1837673 Fax: +49-201-1837673
Email: dreibh@iem.uni-due.de EMail: dreibh@iem.uni-due.de
URI: http://www.iem.uni-due.de/~dreibh/ URI: http://www.iem.uni-due.de/~dreibh/
Michael Tuexen Michael Tuexen
Muenster University of Applied Sciences Muenster University of Applied Sciences
Stegerwaldstrasse 39 Stegerwaldstrasse 39
48565 Steinfurt, Nordrhein-Westfalen 48565 Steinfurt
Germany Germany
Phone: +49-2551-962550 Phone: +49-2551-962550
Fax: +49-2551-962563 Fax: +49-2551-962563
Email: tuexen@fh-muenster.de EMail: tuexen@fh-muenster.de
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
 End of changes. 61 change blocks. 
217 lines changed or deleted 184 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/