DHC Load Balancing Algorithm
RFC 3074
Document | Type |
RFC - Proposed Standard
(February 2001; No errata)
Was draft-ietf-dhc-loadb (dhc WG)
|
|
---|---|---|---|
Authors | Bernie Volz , Steve Gonczi , Ted Lemon , Rick Stevens | ||
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 aShow full document text