DHC Load Balancing Algorithm
RFC 3074
| Document | Type |
RFC - Proposed Standard
(February 2001; No errata)
Was draft-ietf-dhc-loadb (dhc WG)
|
|
|---|---|---|---|
| Last updated | 2013-03-02 | ||
| Stream | IETF | ||
| Formats | plain text html pdf htmlized bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 3074 (Proposed Standard) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | (None) | ||
| Send notices to | (None) | ||
Network Working Group B. Volz
Request for Comments: 3074 Ericsson
Category: Standards Track S. Gonczi
Network Engines, Inc.
T. Lemon
Internet Engines, Inc.
R. Stevens
Join Systems, Inc.
February 2001
DHC Load Balancing Algorithm
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document proposes a method of algorithmic load balancing. It
enables multiple, cooperating servers to decide which one should
service a client, without exchanging any information beyond initial
configuration.
The server selection is based on the servers hashing client Media
Access Control (MAC) addresses when multiple Dynamic Host
Configuration Protocol (DHCP) servers are available to service DHCP
clients. The proposed technique provides for efficient server
selection when multiple DHCP servers offer services on a network
without requiring any changes to existing DHCP clients. The same
method is proposed to select the target server of a forwarding agent
such as a Bootstrap Protocol (BOOTP) relay.
1. Introduction
This protocol was originally devised to support a specific load
balancing optimization of the DHCP Failover Protocol [FAILOVR]. The
authors later realized that it could be used to optimize the behavior
of cooperating DHCP servers and the BOOTP relay agents that forward
packets to them. The proposal makes it possible to set up each
Volz, et al. Standards Track [Page 1]
RFC 3074 DHC Load Balancing Algorithm February 2001
participating server to accept a preconfigured (approximate)
percentage of the client load. This is done using a deterministic
hashing algorithm, that could easily be applied to other protocols
having similar characteristics.
2. Terminology
This section discusses both the generic requirements terminology
common to many IETF protocol specifications, and also terminology
introduced by this document.
2.1. Requirements Terminology
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 RFC 2119 [RFC 2119].
2.2. Load Balancing Terminology
This document introduces the following terms:
Service Delay, SD
A load balancing parameter, allowing delayed service of a client
by a server participating in the load-balancing scheme, instead of
ignoring the client.
Hash Bucket Assignments, HBA
A configuration directive that assigns a set of hash bucket values
to a server participating in the load-balancing scheme.
Server ID, SID
An identifier that can be used to designate one of the
participating Servers. In the context of DHCP, the SID is the IP
address or DNS name of the server.
Service Transaction, ST
A set of client-server exchanges that lead to a server providing
or denying some service to a client. Example: the DISCOVER/OFFER/
REQUEST/ACK message exchange between a DHCP server and client is a
service transaction.
Service Transaction ID, STID
An attribute of the individual client requests used for load-
balancing.
Volz, et al. Standards Track [Page 2]
RFC 3074 DHC Load Balancing Algorithm February 2001
3. Background and External Requirements
Because DHCP clients use UDP broadcasts to contact DHCP servers, a
client DHCPDISCOVER message may be received by more than one server.
All servers receiving such a broadcast may respond to the client,
letting the client choose which server it will use.
When a BOOTP relay agent is used, it typically forwards or
rebroadcasts client broadcasts to all configured servers, so a
similar inefficiency is present.
The optimization described allows a server to be chosen for each such
transaction by performing a "serve" / "do not serve" computation. A
forwarding agent can perform the same computation to choose a
Show full document text