RFC 2391 (rfc2391) - Page 2 of 18
Load Sharing using IP Network Address Translation (LSNAT)
Alternative Format: Original Text Document
RFC 2391 LSNAT August 1998
either direction. This document combines the characteristic of
transparent address translation with real-time load share algorithms
to introduce Load Share Network Address Translators.
The problem of Load sharing or Load balancing is not new and goes
back many years. A variety of techniques were applied to address the
problem. Some very ad-hoc and platform specific and some employing
clever schemes to reorder DNS resource records. REF [11] uses DNS
zone transfer program in name servers to periodically shuffle the
order of resource records for server nodes based on a pre-determined
load balancing algorithm. The problem with this approach is that
reordering time periods can be very large on the order of minutes and
does not reflect real-time load variations on the servers. Secondly,
all hosts in the server pool are assumed to have equal capability to
offer all services. This may not often be the case. In addition,
there may be requirement to support load balancing for a few specific
services only. The load share approach outlined in this document
addresses both these concerns and offers a solution that does not
require changes to clients or servers and one that can be tailored to
individual services or for all services.
For the reminder of this document, we will refer to NAT routers that
provide load sharing support as LSNATs. Unlike traditional NATs,
LSNATs are not required to operate between private and public domain
routing realms alone. LSNATs also operate in a single routing realm
and provide load sharing functionality.
The need for Load sharing arises when a single server is not able to
cope with increasing demand for multiple sessions simultaneously.
Clearly, load sharing across multiple servers would enhance
responsiveness and scale well with session load. Popular applications
inundating servers would include Web browsers, remote login, file
transfer and mail applications.
When a client attempts to access a server through an LSNAT router,
the router selects a node in server pool, based on a load share
algorithm and redirect the request to that node. LSNATs pose no
restriction on the organization and rearrangement of nodes in server
pool. Nodes in a pool may be replaced, new nodes may be added and
others may be in transition. Changes of this kind to server pool can
be shielded from client nodes by making LSNAT router the focal point
for change management.
There are limitations to using LSNATs. Firstly, it is mandatory that
all requests and responses pertaining to a session between a client
and server be routed via the same LSNAT router. For this reason, we
recommend LSNATs to be operated on a single border router to a stub
domain in which the server pool would be confined. This would ensure
Srisuresh & Gan Informational