Load Sharing using IP Network Address Translation (LSNAT)
RFC 2391

Document Type RFC - Informational (August 1998; Errata)
Was draft-srisuresh-lsnat (individual)
Authors Pyda Srisuresh  , Der-Hwa Gan 
Last updated 2013-03-02
Stream Legacy
Formats plain text html pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 2391 (Informational)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                       P. Srisuresh
Request for Comments: 2391                           Lucent Technologies
Category: Informational                                           D. Gan
                                                  Juniper Networks, Inc.
                                                             August 1998

       Load Sharing using IP Network Address Translation (LSNAT)

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.


   This document combines the idea of address translation described in
   RFC 1631 with real-time load share algorithms to introduce Load Share
   Network Address Translators(or, simply LSNATs). LSNATs would
   transparently offload network load on a single server and distribute
   the load across a pool of servers.


   Network Address Translators (NATs) translate IP addresses in a
   datagram, transparent to end nodes, while routing the datagram. NATs
   have traditionally been been used to allow private network domains to
   connect to Global networks using as few as one globally unique IP
   address.  In this document, we extend the use of NATs to offer Load
   share feature, where session load can be distributed across a pool of
   servers, instead of directing to a single server.  Load sharing is
   beneficial to service providers and system administrators alike in
   grappling with scalability of servers with increasing session load.

1. Introduction

   Traditionally, Network Address Translators, or simply NATs were used
   to connect private network domains to globally unique public domain
   IP networks. Applications originate in private domains and NATs would
   transparently translate datagrams belonging to these applications in

Srisuresh & Gan              Informational                      [Page 1]
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
Show full document text