TOC 
Network Working GroupT. Dreibholz
Internet-DraftUniversity of Duisburg-Essen
Intended status: ExperimentalM. Tuexen
Expires: January 15, 2009Muenster Univ. of Applied Sciences
 July 14, 2008


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 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.

Abstract

This document describes server pool policies for Reliable Server Pooling including considerations for implementing them at ENRP servers and pool users.



Table of Contents

1.  Introduction
2.  Conventions
3.  Terminology and Definitions
    3.1.  Load
    3.2.  Weight
4.  Non-Adaptive Policies
    4.1.  Round Robin Policy
        4.1.1.  Description
        4.1.2.  ENRP Server Considerations
        4.1.3.  Pool User Considerations
        4.1.4.  Pool Member Selection Policy Parameter
    4.2.  Weighted Round Robin Policy
        4.2.1.  Description
        4.2.2.  ENRP Server Considerations
        4.2.3.  Pool User Considerations
        4.2.4.  Pool Member Selection Policy Parameter
    4.3.  Random Policy
        4.3.1.  Description
        4.3.2.  ENRP Server Considerations
        4.3.3.  Pool User Considerations
        4.3.4.  Pool Member Selection Policy Parameter
    4.4.  Weighted Random Policy
        4.4.1.  Description
        4.4.2.  ENRP Server Considerations
        4.4.3.  Pool User Considerations
        4.4.4.  Pool Member Selection Policy Parameter
    4.5.  Priority Policy
        4.5.1.  Description
        4.5.2.  ENRP Server Considerations
        4.5.3.  Pool Element Considerations
        4.5.4.  Pool Member Selection Policy Parameter
5.  Adaptive Policies
    5.1.  Least Used Policy
        5.1.1.  Description
        5.1.2.  ENRP Server Considerations
        5.1.3.  Pool User Considerations
        5.1.4.  Pool Member Selection Policy Parameter
    5.2.  Least Used with Degradation Policy
        5.2.1.  Description
        5.2.2.  ENRP Server Considerations
        5.2.3.  Pool User Considerations
        5.2.4.  Pool Member Selection Policy Parameter
    5.3.  Priority Least Used Policy
        5.3.1.  Description
        5.3.2.  ENRP Server Considerations
        5.3.3.  Pool User Considerations
        5.3.4.  Pool Member Selection Policy Parameter
    5.4.  Randomized Least Used Policy
        5.4.1.  Description
        5.4.2.  ENRP Server Considerations
        5.4.3.  Pool User Considerations
        5.4.4.  Pool Member Selection Policy Parameter
6.  Security Considerations
7.  IANA Considerations
    7.1.  A New Table for RSerPool Policy Types
8.  Reference Implementation
9.  References
    9.1.  Normative References
    9.2.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements




 TOC 

1.  Introduction

The protocols defined in [I‑D.ietf‑rserpool‑enrp] (Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. Silverton, “Endpoint Handlespace Redundancy Protocol (ENRP),” July 2008.), [I‑D.ietf‑rserpool‑asap] (Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, “Aggregate Server Access Protocol (ASAP),” July 2008.) and [I‑D.ietf‑rserpool‑common‑param] (Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, “Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters,” July 2008.) support a variety of server policies. Some of the policies use dynamic load information of the pool elements and others do not. Therefore, we classify them as adaptive and non-adaptive. The selection of the pool element is performed by two different entities, the ENRP server and the pool user. Some of the consequences for policies which are not stateless are described in [ICN2005] (Dreibholz, T., Rathgeb, E., and M. Tuexen, “Load Distribution Performance of the Reliable Server Pooling Framework,” April 2005.) and [LCN2005] (Dreibholz, T. and E. Rathgeb, “On the Performance of Reliable Server Pooling Systems,” November 2005.).

Therefore this document describes not only packet formats but also gives a detailed description of the procedures to be followed at the ENRP servers and the pool users to implement each server policy.



 TOC 

2.  Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).



 TOC 

3.  Terminology and Definitions



 TOC 

3.1.  Load

The term load is a value specifying how much a pool element's resources are currently utilized. 0x00000000 states, that the pool element is not utilized (0%), 0xffffffff states that it is fully utilized (100%). Defining what utilization means is application-dependent and out of the scope of RSerPool. However, it is required that all pool elements of the same pool using load information have the same definition of load.

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 memory utilization of a compute service.



 TOC 

3.2.  Weight

Weight defines a pool element's service capacity relatively to other pool elements of the same pool. Theoretically, there is no upper limit for weight values (although limited by datatype size). Defining what value weights compare is application-dependent and out of the scope of RSerPool. However, it is required that all pool elements of the same pool using weight information have the same definition of weight.

A weight of 0 denotes that the pool element is not capable of providing any service, a higher weight of denotes that the pool element is capable of providing better service than a pool element having a lower weight.

For example, weight may define a compute service's computation 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.



 TOC 

4.  Non-Adaptive Policies



 TOC 

4.1.  Round Robin Policy



 TOC 

4.1.1.  Description

The Round Robin (RR) policy is a very simple and efficient policy which requires state. This policy is denoted as the default policy and MUST be supported by all RSerPool components.



 TOC 

4.1.2.  ENRP Server Considerations

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, called the head. On reception of a handle resolution request the ENRP server SHOULD return the pool elements from the circular list starting with head. Then head SHOULD be advanced by one element.

Using this algorithm it is made sure that not all lists presented to the pool users start with the same element.



 TOC 

4.1.3.  Pool User Considerations

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 elements of the list have been used it should start from the beginning again until the information is out of date.



 TOC 

4.1.4.  Pool Member Selection Policy Parameter

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Param Type = 0x8           |         Length = 0x8          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Policy Type = 0x00000001                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



 TOC 

4.2.  Weighted Round Robin Policy



 TOC 

4.2.1.  Description

The Weighted Round Robin (WRR) policy is a generalization of the RR policy. If all weights are 1 then WRR is just RR.



 TOC 

4.2.2.  ENRP Server Considerations

The ENRP server SHOULD follow the same rules as for RR but initialize and modify the circular list differently. The ENRP server puts each pool element possibly multiple times into the list such that:



 TOC 

4.2.3.  Pool User Considerations

The pool user SHOULD follow the same rules as for RR.



 TOC 

4.2.4.  Pool Member Selection Policy Parameter

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Param Type = 0x8           |         Length = 0xc          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Policy Type = 0x00000002                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              Weight                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



 TOC 

4.3.  Random Policy



 TOC 

4.3.1.  Description

The Random (RAND) policy is a very simple stateless policy.



 TOC 

4.3.2.  ENRP Server Considerations

The ENRP server selects at most the requested number of pool elements from the list of pool elements. Each element MUST NOT be reported more than once to the pool user.



 TOC 

4.3.3.  Pool User Considerations

Each time the pool user must select one pool element it does this by randomly selecting one element from the list of pool elements received from the ENRP server.



 TOC 

4.3.4.  Pool Member Selection Policy Parameter

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Param Type = 0x8           |         Length = 0x8          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Policy Type = 0x00000003                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



 TOC 

4.4.  Weighted Random Policy



 TOC 

4.4.1.  Description

The Weighted Random (WRAND) policy is a generalization of the RAND policy, adding a weight for each pool element entry. RAND is equal to WRAND having all weights set to 1.



 TOC 

4.4.2.  ENRP Server Considerations

The ENRP server SHOULD select at most the requested number of pool elements randomly from the list of pool elements. Each element MUST 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 pool element to the sum of weights.



 TOC 

4.4.3.  Pool User Considerations

Each time the pool user must select one pool element it does this by randomly selecting one element from the list of pool elements received from the ENRP server.



 TOC 

4.4.4.  Pool Member Selection Policy Parameter

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Param Type = 0x8           |         Length = 0xc          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Policy Type = 0x00000004                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              Weight                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



 TOC 

4.5.  Priority Policy



 TOC 

4.5.1.  Description

The Priority (PRIO) policy can be used to select always a pool element with the highest priority.



 TOC 

4.5.2.  ENRP Server Considerations

The ENRP server MUST select the pool elements with the highest priorities. They MUST be reported in decreasing order. If multiple pool elements have the same priority, they may be listed in any order.



 TOC 

4.5.3.  Pool Element Considerations

The pool user MUST select the active pool element with the highest priority.



 TOC 

4.5.4.  Pool Member Selection Policy Parameter

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Param Type = 0x8           |         Length = 0xc          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Policy Type = 0x00000005                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Priority                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



 TOC 

5.  Adaptive Policies



 TOC 

5.1.  Least Used Policy



 TOC 

5.1.1.  Description

The Least Used (LU) policy uses load information provided by the pool elements to select the lowest-loaded pool elements within the pool.



 TOC 

5.1.2.  ENRP Server Considerations

The ENRP server SHOULD select at most the requested number of pool elements. Their load values SHOULD be the lowest 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-loaded pool elements, round robin selection SHOULD be made among these elements. The returned list of pool elements MUST be sorted ascending by load value.



 TOC 

5.1.3.  Pool User Considerations

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 handle resolution may result in the same list. Thereofore, it is RECOMMENDED for a pool user to request multiple entries in order to have a sufficient amount of feasible backup entries available.



 TOC 

5.1.4.  Pool Member Selection Policy Parameter

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Param Type = 0x8           |         Length = 0xc          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Policy Type = 0x40000001                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              Load                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



 TOC 

5.2.  Least Used with Degradation Policy



 TOC 

5.2.1.  Description

The Least Used with Degradation (LUD) policy extends the LU policy by a load degradation value describing the pool element's load increment when a new service association is accepted.



 TOC 

5.2.2.  ENRP Server Considerations

For every pool element entry, a degradation counter MUST be stored. When a pool element entry is added or updated by registration or reregistration, this counter MUST be set to 0. When an entry is selected for being returned to a pool user, the internal degradation counter MUST be incremented by 1. The selection of pool element entries is handled like for LU, except that the selected pool element entries SHOULD have the lowest possible sum of load value + degradation counter * load degradation value.



 TOC 

5.2.3.  Pool User Considerations

See LU policy.



 TOC 

5.2.4.  Pool Member Selection Policy Parameter

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Param Type = 0x8           |         Length = 0x10         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Policy Type = 0x40000002                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              Load                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Load Degradation                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



 TOC 

5.3.  Priority Least Used Policy



 TOC 

5.3.1.  Description

The Priority Least Used (PLU) policy uses load information provided by the pool elements to select the lowest-loaded pool elements within the pool under the assumption that a new application request is accepted by the pool elements. Therefore, the pool elements also have to specify load degradation information.

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 be fully loaded. PLU allows to specify this load degradation in the policy information, the selection is made on the lowest sum of load and degradation value. That is, A will be selected (50+10=60) instead of B (50+50=100).



 TOC 

5.3.2.  ENRP Server Considerations

The ENRP server SHOULD select at most the requested number of pool elements. Their sums of load + degradation SHOULD be the lowest 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-valued pool element entries, round robin SHOULD be made among these elements. The returned list of pool elements MUST be sorted ascending by the sum of load and degradation value.



 TOC 

5.3.3.  Pool User Considerations

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 handle resolution may result in the same list. Therefore, it is RECOMMENDED for a pool user to request multiple entries in order to have a sufficient amount of feasible backup entries available.



 TOC 

5.3.4.  Pool Member Selection Policy Parameter

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Param Type = 0x8           |         Length = 0x10         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Policy Type = 0x40000003                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              Load                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Load Degradation                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



 TOC 

5.4.  Randomized Least Used Policy



 TOC 

5.4.1.  Description

The Randomized Least Used (RLU) policy combines LU and WRAND. That is, the pool element entries are selected randomly. The probability 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 unload part related to the whole pool unload rate.



 TOC 

5.4.2.  ENRP Server Considerations

The ENRP server SHOULD behave like WRAND, having every PE's weight set to (0xffffffff - Load value provided by the pool element).



 TOC 

5.4.3.  Pool User Considerations

See WRAND policy.



 TOC 

5.4.4.  Pool Member Selection Policy Parameter

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Param Type = 0x8           |         Length = 0xc          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Policy Type = 0x40000004                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              Load                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



 TOC 

6.  Security Considerations

The security threats regarding RSerPool have been analyzed in RSerPool threats (Stillman, M., Gopal, R., Guttman, E., Holdrege, M., and S. Sengodan, “Threats Introduced by RSerPool and Requirements for Security in Response to Threats,” July 2008.) [I‑D.ietf‑rserpool‑threats]. The server policy descriptions in this document do not add any other threats.



 TOC 

7.  IANA Considerations

[NOTE to RFC-Editor:

"RFCXXXX" is to be replaced by the RFC number you assign this 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.



 TOC 

7.1.  A New Table for RSerPool Policy Types

RSerPool Policy Types which are 4 byte values have to be maintained by IANA. The format of the policy type value is defined as follows:

       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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |X|A|                   Policy Number                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Nine initial Policy Types should be assigned and maintained in a new table "RSerPool Policy Types":

  Value           Policy                                  Reference
  -----           ---------                               ---------
  0x00000000      (reserved, invalid value)               RFCXXXX
  0x00000001      Round Robin                             RFCXXXX
  0x00000002      Weighted Round Robin                    RFCXXXX
  0x00000003      Random                                  RFCXXXX
  0x00000004      Weighted Random                         RFCXXXX
  0x00000005      Priority                                RFCXXXX
  0x00000006      (reserved by IETF)                      RFCXXXX
  ...
  0x3fffffff      (reserved by IETF)                      RFCXXXX

  0x40000000      (reserved, invalid value)               RFCXXXX
  0x40000001      Least Used                              RFCXXXX
  0x40000002      Least Used with Degradation             RFCXXXX
  0x40000003      Priority Least Used                     RFCXXXX
  0x40000004      Randomized Least Used                   RFCXXXX
  0x40000005      (reserved by IETF)                      RFCXXXX
  ...
  0x7fffffff      (reserved by IETF)                      RFCXXXX

  0x80000000      (private use, non-standard policy)      RFCXXXX
  ...
  0xffffffff      (private use, non-standard policy)      RFCXXXX

For registering at IANA an RSerPool Policy Type in this table a request has to be made to assign such a number. This number must be unique and use the appropiate upper bits. The "Specification Required" policy of [RFC5226] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.) MUST be applied.

The Policy Type space from 0x80000000 to 0xffffffff is designated for private use.



 TOC 

8.  Reference Implementation

The reference implementation of RSerPool and the policies described in this document is available at [RSerPoolPage] (Dreibholz, T., “Thomas Dreibholz's RSerPool Page,” .) and described in [Dre2006] (Dreibholz, T., “Reliable Server Pooling -- Evaluation, Optimization and Extension of a Novel IETF Architecture,” March 2007.).



 TOC 

9.  References



 TOC 

9.1. Normative References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC5226] Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” BCP 26, RFC 5226, May 2008 (TXT).
[I-D.ietf-rserpool-common-param] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, “Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters,” draft-ietf-rserpool-common-param-18 (work in progress), July 2008 (TXT).
[I-D.ietf-rserpool-asap] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, “Aggregate Server Access Protocol (ASAP),” draft-ietf-rserpool-asap-21 (work in progress), July 2008 (TXT).
[I-D.ietf-rserpool-enrp] Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. Silverton, “Endpoint Handlespace Redundancy Protocol (ENRP),” draft-ietf-rserpool-enrp-21 (work in progress), July 2008 (TXT).
[I-D.ietf-rserpool-threats] Stillman, M., Gopal, R., Guttman, E., Holdrege, M., and S. Sengodan, “Threats Introduced by RSerPool and Requirements for Security in Response to Threats,” draft-ietf-rserpool-threats-15 (work in progress), July 2008 (TXT).


 TOC 

9.2. Informative References

[RSerPoolPage] Dreibholz, T., “Thomas Dreibholz's RSerPool Page,” URL: http://tdrwww.iem.uni-due.de/dreibholz/rserpool/.
[Dre2006] Dreibholz, T., “Reliable Server Pooling -- Evaluation, Optimization and Extension of a Novel IETF Architecture,” Ph.D. Thesis University of Duisburg-Essen, Faculty of Economics, Institute for Computer Science and Business Information Systems, URL: http://duepublico.uni-duisburg-essen.de/servlets/DerivateServlet/Derivate-16326/Dre2006-final.pdf, March 2007.
[LCN2005] Dreibholz, T. and E. Rathgeb, “On the Performance of Reliable Server Pooling Systems,” Proceedings of the 30th IEEE Local Computer Networks Conference, November 2005.
[ICN2005] Dreibholz, T., Rathgeb, E., and M. Tuexen, “Load Distribution Performance of the Reliable Server Pooling Framework,” Proceedings of the 4th IEEE International Conference on Networking, April 2005.


 TOC 

Authors' Addresses

  Thomas Dreibholz
  University of Duisburg-Essen, Institute for Experimental Mathematics
  Ellernstrasse 29
  45326 Essen, Nordrhein-Westfalen
  Germany
Phone:  +49-201-1837637
Fax:  +49-201-1837673
Email:  dreibh@iem.uni-due.de
URI:  http://www.iem.uni-due.de/~dreibh/
  
  Michael Tuexen
  Muenster University of Applied Sciences
  Stegerwaldstrasse 39
  48565 Steinfurt
  Germany
Phone:  +49-2551-962550
Fax:  +49-2551-962563
Email:  tuexen@fh-muenster.de


 TOC 

Full Copyright Statement

Intellectual Property