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