As per Relevance of the word translation, we have this rfc below:

---

Network Working Group P.
Request for Comments: 2391 Lucent
Category: Informational D.
Juniper Networks, Inc
August 1998


Load Sharing using IP Network Address Translation (LSNAT

Status of this

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

Copyright

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



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



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

1.

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






Srisuresh & Gan Informational [Page 1]

RFC 2391 LSNAT August 1998


either direction. This document combines the characteristic
transparent address translation with real-time load share
to introduce Load Share Network Address Translators

The problem of Load sharing or Load balancing is not new and
back many years. A variety of techniques were applied to address
problem. Some very ad-hoc and platform specific and some
clever schemes to reorder DNS resource records. REF [11] uses
zone transfer program in name servers to periodically shuffle
order of resource records for server nodes based on a pre-
load balancing algorithm. The problem with this approach is
reordering time periods can be very large on the order of minutes
does not reflect real-time load variations on the servers. Secondly
all hosts in the server pool are assumed to have equal capability
offer all services. This may not often be the case. In addition
there may be requirement to support load balancing for a few
services only. The load share approach outlined in this
addresses both these concerns and offers a solution that does
require changes to clients or servers and one that can be tailored
individual services or for all services

For the reminder of this document, we will refer to NAT routers
provide load sharing support as LSNATs. Unlike traditional NATs
LSNATs are not required to operate between private and public
routing realms alone. LSNATs also operate in a single routing
and provide load sharing functionality

The need for Load sharing arises when a single server is not able
cope with increasing demand for multiple sessions simultaneously
Clearly, load sharing across multiple servers would
responsiveness and scale well with session load. Popular
inundating servers would include Web browsers, remote login,
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
algorithm and redirect the request to that node. LSNATs pose
restriction on the organization and rearrangement of nodes in
pool. Nodes in a pool may be replaced, new nodes may be added
others may be in transition. Changes of this kind to server pool
be shielded from client nodes by making LSNAT router the focal
for change management

There are limitations to using LSNATs. Firstly, it is mandatory
all requests and responses pertaining to a session between a
and server be routed via the same LSNAT router. For this reason,
recommend LSNATs to be operated on a single border router to a
domain in which the server pool would be confined. This would



Srisuresh & Gan Informational [Page 2]

RFC 2391 LSNAT August 1998


that all traffic directed to servers from clients outside the
and vice versa would necessarily traverse the LSNAT border router
Later in the document, we will examine a special case of LSNAT setup
which gets around the topological constraint on server pool.
limitation of LSNATs is the inability to switch loads between
in the midst of sessions. This is because LSNATs measure load
granularity of sessions. Once a session is assigned to a host,
session cannot be moved to a different host till the end of
session. Other limitations, inherent to NATs, as outlined in REF [1]
are also applicable to LSNATs

As with traditional NATs, LSNATs have the disadvantage of taking
the end-to-end significance of an IP address. The major advantage
however, is that it can be installed without changes to clients
servers

2. Terminology and concepts

2.1. TU ports, Server ports, Client

For the reminder of this document, we will refer TCP/UDP
associated with an IP address simply as "TU ports".

For most TCP/IP hosts, TU port range 0-1023 is used by
listening for incoming connections. Clients trying to initiate
connection typically select a TU port in the range of 1024-65535.
However, this convention is not universal and not always followed.
is possible for client nodes to initiate connections using a TU
number in the range of 0-1023, and there are applications
on TU port numbers in the range of 1024-65535.

A complete list of TU port services may be found in REF [2]. The
ports used by servers to listen for incoming connections are
"Server Ports" and the TU ports used by clients to initiate
connection to server are called "Client Ports".

2.2. Session flow vs. Packet

Connection or session flows are different from packet flows.
session flow indicates the direction in which the session
initiated with reference to a network port. Packet flow is
direction in which the packet has traversed with reference to
network port. A session flow is uniquely identified by the
in which the first packet of that session traversed

Take for example, a telnet session. The telnet session consists
packet flows in both inbound and outbound directions. Outbound
packets carry terminal keystrokes from the client and inbound



Srisuresh & Gan Informational [Page 3]

RFC 2391 LSNAT August 1998


packets carry screen displays from the telnet server.
address translation for a telnet session would involve translation
incoming as well as outgoing packets belonging to that session

Packets belonging to a TCP/UDP session are uniquely identified
the tuple of (source IP address, source TU port, target IP address
target TU port). ICMP sessions that correlate queries and
using query id are uniquely identified by the tuple of (source
address, ICMP Query Identifier, target IP address). For lack
well-known ways to distinguish, all other types of sessions
lumped together and distinguished by the tuple of (source IP address
IP protocol, target IP address).

2.3. Start of session for TCP, UDP and

The first packet of every TCP session tries to establish a
and contains connection startup information. The first packet of
TCP session may be recognized by the presence of SYN bit and
of ACK bit in the TCP flags. All TCP packets, with the exception
the first packet must have the ACK bit set

The first packet of every session, be it a TCP session, UDP session
ICMP query session or any other session, tries to establish
session. However, there is no deterministic way of recognizing
start of a UDP session or any other non-TCP session

Start of session is significant with NATs, as a state
translation parameters for the session is established at the
of session. Packets pertaining to the session cannot
translation, unless a state is established by NAT at the start
session

2.4. End of session for TCP, UDP and

The end of a TCP session is detected when FIN is acknowledged by
halves of the session or when either half receives RST bit in
flags field. Within a short period (say, a couple of seconds)
one of the session partners sets RST bit, the session can be
assumed to have been terminated

For all other types of session, there is no deterministic way
determining the end of session unless you know the
protocol. Many heuristic approaches are used to terminate sessions
You can make the assumption that TCP sessions that have not been
for say, 24 hours, and non-TCP sessions that have not been used
say, 1 minute, are terminated. Often this assumption works,
sometimes it doesn't. These idle period session timeouts may
considerably across the board and may be made user configurable



Srisuresh & Gan Informational [Page 4]

RFC 2391 LSNAT August 1998


Another way to handle session terminations is to timestamp
and keep them as long as possible and retire the longest idle
when it becomes necessary

2.5. Basic Network Address Translation (Basic NAT

Basic NAT is a method by which hosts in a private network domain
allowed access to hosts in the external network transparently.
block of external addresses are set aside for translating
of private hosts as the private hosts originate sessions
applications in external domain. Once an external address is bound
the NAT device to a specific private address, that address
remains in place for all subsequent sessions originating from
same private host. This binding may be terminated when there are
sessions left to use the binding

2.6. Network Address Port Translation (NAPT

Network Address Port Translation(NAPT) is a method by which hosts
a private network domain are allowed simultaneous access to hosts
the external network transparently using a single registered address
This is made possible by multiplexing transport layer identifiers
private hosts into the transport identifiers of the single
external address. For this reason, only the applications based on
and UDP protocols are supported by NAPT. ICMP query
applications are also supported as the ICMP header carries a
identifier that is used to corelate responses with requests
Sessions other than TCP, UDP and ICMP query type are simply
permitted from local nodes, serviced by a NAPT router

2.7. Load

Load sharing for the purpose of this document is defined as
spread of session load amongst a cluster of servers which
functionally similar or the same. In other words, each of the
in cluster can support a client session equally well with
discernible difference in functionality. Once a node is assigned
service a session, that session is bound to that node
termination. Sessions are not allowed to swap between nodes in
midst of session

Load sharing may be applicable for all services, if all hosts
server cluster carry the capability to carry out all services
Alternately, load sharing may be limited to one or more
services alone and not to others






Srisuresh & Gan Informational [Page 5]

RFC 2391 LSNAT August 1998


Note, the term "Session load" used in the context of load share
different from the term "system load" attributed to hosts by way
CPU, memory and other resource usage on the system

3. Overview of Load

While both traditional NATs and LSNATs perform address translations
and provide transparent connectivity between end nodes, there
distinctions between the two. Traditional NATs initiate
on outbound sessions, by binding a private address to a
address (basic NAT) or by binding a tuple of private address
transport identifier (such as TCP/UDP port or ICPM query ID) to
tuple of global address and transport identifier. LSNATs, on
other hand, initiate translations on inbound sessions, by
each session represented by a tuple such as (client address,
TU port, virtual server address, server TU port) to one of
pool nodes, selected based on a real-time load-share algorithm.
virtual server address is a globally unique IP address
identifies a physical server or a group of servers that can
similar or same functionality

For the reminder of this document, we will refer traditional
simply as NATs and refer LSNATs exclusively in the context of
share, without implying traditional NAT functionality

LSNATs are not limited to operate between private and public
routing realms. LSNATs may operate within a single routing realm
globally unique IP addresses, just as well as between private
public network domains. The only requirement is that server pool
confined to a stub domain, accessible to clients outside the
through a single LSNAT border router. However, as you will
later, this topology limitation on server pool can be overcome
certain configurations

Load Share NAT operates as follows. A client attempts to access
server by using the server virtual address. The LSNAT
transparently redirects the request to one of the hosts in
pool, selected using a real-time load sharing algorithm.
sessions may be initiated from the same client, and each
could be directed to a different host based on load balance
server pool hosts at the time. If load share is desired for just
few specific services, the configuration on LSNAT could be defined
restrict load share for just the services desired








Srisuresh & Gan Informational [Page 6]

RFC 2391 LSNAT August 1998


In the case where virtual server address is same as the
address of an LSNAT router, server applications (such as telnet)
LSNAT router must be disabled for external access on that address
This is the limitation to using address owned by LSNAT router as
virtual server address

Load share NAT operation is also applicable during individual
upgrades as follows. Say, a server, that needs to be upgraded
statically mapped to a backup server on the inbound. Subsequent
this mapping, new session requests to the original server would
redirected by LSNAT to the backup server. As an extension, it
also possible to statically map a specific TU port service on
server to that of backup sever

We illustrate the operation of LSNAT in the following subsections
where (a) servers are confined to a stub domain, and belong
globally unique address space as shared by clients, (b) servers
confined to private address space stub domain, and (c) servers
not restrained by any topological limitations

3.1 Operation of LSNAT in a globally unique address

In this section, we will illustrate the operation of LSNAT in
globally unique address space. The border router with LSNAT
on WAN link would perform load sharing and address translations
inbound sessions. However, sessions outbound from the hosts in
pool will not be subject to any type of translation, as all
have globally unique IP addresses

In the example below, servers S1 (172.85.0.1), S2(172.85.0.2)
S3(172.85.0.3) form a server pool, confined to a stub domain.
on the border router is enabled on the WAN link, such that
virtual server address S(172.87.0.100) is mapped to the server
consisting of hosts S1, S2 and S3. When a client 198.76.29.7
initiates a HTTP session to the virtual server S, the LSNAT
examines the load on hosts in server pool and selects a host, say S
to service the request. The transparent address and TU
translations performed by the LSNAT router become apparent as
follow the down arrow line. IP packets on the return path go
similar address translation. Suppose, we have another
198.23.47.2 initiating telnet session to the same virtual server S
The LSNAT would determine that host S3 is a better choice to
this session as S1 is busy with a session and redirect the session
S3. The second session redirection path is delineated with colons
The procedure continues for any number of sessions the same way






Srisuresh & Gan Informational [Page 7]

RFC 2391 LSNAT August 1998


Notice that this requires no changes to clients or servers. All
configuration and mapping necessary would be limited just to
LSNAT router

\ | /
+---------------+
|Backbone Router
+---------------+
WAN |
|
Stub domain border .......|.........
|
{s=198.76.29.7, 2745, v | {s=198.23.47.2, 3200,
d=172.87.0.100, 80 } v | d=172.87.0.100, 23 }
v +------------------+ :
v |Border Router with| :
v |LSNAT enabled on | :
v |WAN interface | :
v +------------------+ :
v | :
v | LAN :
------v----------------------:---
{s=198.76.29.7, 2745, v | | |:{s=198.23.47.2, 3200,
d=172.85.0.1, 80 } | | | d=172.85.0.3, 23 }
+--+ +--+ +--+
|S1| |S2| |S3|
|--| |--| |--|
/____\ /____\ /____\
172.85.0.1 172.85.0.2 172.85.0.3

Figure 1: Operation of LSNAT in Globally unique address

3.2. Operation of LSNAT in conjunction with a private

In this section, we will illustrate the operation of LSNAT
conjunction with NAT on the same router. The NAT configuration
required for translation of outbound sessions and could be
Basic NAT or NAPT. The illustration below will assume NAPT on
outbound and LSNAT on the inbound on WAN link

Say, an organization has a private IP network and a WAN link
backbone router. The private network's stub router is assigned
globally valid address on the WAN link and the remaining nodes in
organization have IP addresses that have only local significance.
border router is NAPT configured on the outbound allowing access
external hosts, using the single registered IP address





Srisuresh & Gan Informational [Page 8]

RFC 2391 LSNAT August 1998


In addition, say the organization has servers S1 (10.0.0.1),
S2(10.0.0.2) and S3 (10.0.0.3) that form a pool to provide
access to external clients. This is made possible by enabling
on the WAN link of the border router, such that virtual
address S(198.76.28.4) is mapped to the server pool consisting
hosts S1, S2 and S3. When an external client 198.76.29.7 initiates
HTTP session to the virtual server S, the LSNAT router examines
on hosts in server pool and selects a host, say S1 to service
request. The transparent address and TU port translations
by the LSNAT router are apparent as you follow the down arrow line
IP packets on the return path go through similar address translation
Suppose, we have another client 198.23.47.2 initiating telnet
to the same address. The LSNAT would determine that host S3 is
better choice to service this session as S1 is busy with a
and redirect the session to S3. The second session redirection
is delineated with colons. The procedure continues for any number
sessions the same way

\ | /
+---------------+
|Backbone Router
+---------------+
WAN |
|
Stub domain border ........|.........
|
{s=198.76.29.7, 2745, v | {s=198.23.47.2, 3200,
d=198.76.28.4, 80 }v | :d=198.76.28.4, 23 }
v+-------------------+:
v|Border Router with |:
v| LSNAT and NAPT |:
v|enabled on WAN link|:
v+-------------------+:
v | :
v | LAN :
------v---------------------:------
{s=198.76.29.7, 2745, v | | | : {s=198.23.47.2, 3200,
d=10.0.0.1, 80 } | | | d=10.0.0.3, 23 }
+--+ +--+ +--+
|S1| |S2| |S3|
|--| |--| |--|
/____\ /____\ /____\
10.0.0.1 10.0.0.2 10.0.0.3

Figure 2: Operation of LSNAT, in coexistence with






Srisuresh & Gan Informational [Page 9]

RFC 2391 LSNAT August 1998


Once again, notice that this requires no changes to clients
servers. The translation is completely transparent to end nodes
Address mapping on the LSNAT performs load sharing and
translations for inbound sessions. Sessions outbound from hosts
server pool are subject to NAPT. Both NAT and LSNAT co-exist
each other in the same router

3.3. Load Sharing with no topological restraints on

In this section, we will illustrate a configuration in which
sharing can be accomplished on a router without enforcing
limitations on servers. In this configuration, virtual server
will be owned by the router that supports load sharing. I.e.,
server address will be same as address of one of the interfaces
load share router. We will distinguish this configuration from
by referring this as "Load Share Network Address Port Translation
(LS-NAPT). Routers that support the LS-NAPT configuration will
termed "LS-NAPT routers", or simply LS-NAPTs

In an LSNAT router, inbound TCP/UDP sessions, represented by
tuple of (client address, client TU port, virtual server address
service port) are translated into a tuple of (client address,
TU port, selected server address, service port). Translation
carried out on all datagrams pertaining to the same session,
either direction. Whereas, LS-NAPT router would translate the
session into a tuple of (virtual server address, virtual server
port, selected server, service port). Notice that LS-NAPT
translates the client address and TU port with the address and
port of virtual server, which is same as the address of one of
interfaces. By doing this, datagrams from clients as well as
are forced to bear the address of LS-NAPT router as the
address, thereby guaranteeing that the datagrams would
traverse the LS-NAPT router. As a result, there is no need to
servers to be under topological constraints

Take for example, figure 1 in section 3.1. Let us say the router
which load sharing is enabled is not just a border router, but can
any kind of router. Let us also say that the virtual server address
(172.87.0.100) is same as the address of WAN link and LS-NAPT
enabled on the WAN interface. Figure 3 summarizes the new
configuration

When a client 198.76.29.7 initiates a HTTP session to the
server address S (i.e., address of the WAN interface), the LS-
router examines load on hosts in server pool and selects a host,
S1 to service the request. Appropriately, the destination address
translated to be S1 (172.85.0.1). Further, original client
and TU port are replaced with the address and TU port of the



Srisuresh & Gan Informational [Page 10]

RFC 2391 LSNAT August 1998


link. As a result, destination addresses as well as source
and source TU port are translated when the packet reaches S1, as
be noticed from the down-arrow path. IP packets on the return path
through similar translation. The second client 198.23.47.2
telnet session to the same virtual server address S is load
directed to S3. This packet once again undergoes LS-NAPT translation
just as with the first client. The data path and translations can
noticed following the colon line. The procedure continues for
number of sessions the same way. The translations made to
in either direction are completely transparent to end nodes

\ | /
+---------------+
| Router |
+---------------+
WAN |
|
|
{s=198.76.29.7, 2745, v | {s=198.23.47.2, 3200,
d=198.76.28.4, 80 }v | 198.76.28.4 :d=198.76.28.4, 23 }
v +----------------+ :
v | A Router with | :
v | LS-NAPT enabled| :
v | on WAN link | :
v +----------------+ :
v | :
v LAN | :
------v---------------------:------
{s=198.76.28.4, 7001, v| | |:{s=198.76.28.4,7002,
d=172.85.0.1, 80 } | | | d=172.85.0.3, 23 }
+--+ +--+ +--+
|S1| |S2| |S3|
|--| |--| |--|
/____\ /____\ /____\
172.85.0.1 172.85.0.2 172.85.0.3

Figure 3: LS-NAPT configuration on a

As you will notice, datagrams from clients as well as servers
forced to be directed to the router, because they use WAN
address of router as the destination address in their datagrams.
the assurance that all packets from clients and servers
traverse the router, there is no longer a requirement for servers
be confined to a stub domain and for LSNAT to be enabled only
border router to the stub domain






Srisuresh & Gan Informational [Page 11]

RFC 2391 LSNAT August 1998


The LS-NAPT configuration described in this section involves
translations and hence is more complex compared to
configurations described in the previous sections. While
processing is complex, there are benefits to this configuration
Firstly, it breaks down restraints on server topology. Secondly,
scales with bandwidth expansion for client access. Even if
providers have one link today for client access, the LS-
configuration allows them to expand to more links in the
guaranteeing the same LS-NAPT load share service on newer links

The configuration is not without its limitations. Server
(such as telnet) on the router box would have to be disabled for
interface address assigned to be virtual server address. Load
would be limited to TCP and UDP applications only.
concurrently allowed sessions would be limited by the maximum
TCP/UDP client ports on the same address. Assuming that ports 0-1023
must be set aside as well-known service ports, that would leave
maximum of 63K TCP client ports and 63K of UDP client ports on
LS-NAPT router to communicate with each load-share server. As
result, LS-NAPT routers will not be able to concurrently support
than a maximum of (63K * count of Load-share servers) TCP
and (63K * count of Load-share servers) UDP sessions

4.0. Translation phases of a session in LSNAT router

As with NATs, LSNATs must monitor the following three phases
relation to Address translation

4.1. Session binding

Session binding is the phase in which an incoming session
associated with the address of a host in server pool.
association essentially sets the translation parameters for
subsequent datagrams pertaining to the session. For addresses
have static mapping, the binding happens at startup time. Otherwise
each incoming session is dynamically bound to a different host
on a load sharing algorithm

4.2. Address lookup and translation

Once session binding is established for a connection setup,
subsequent packets belonging to the same connection will be
to session lookup for translation purposes

For outbound packets of a session, the source IP address (and
TU port, in case of TCP/UDP sessions) and related fields (such as IP
TCP, UDP and ICMP header checksums) will undergo translation.
inbound packets of a session, the destination IP address (



Srisuresh & Gan Informational [Page 12]

RFC 2391 LSNAT August 1998


destination TU port, in case of TCP/UDP sessions) and related
such as IP, TCP, UDP and ICMP header checksums) will
translation

The header and payload modifications made to IP datagrams subject
LSNAT will be exactly same as those subject to traditional NATs
described in section 5.0 of REF [1]. Hence, the reader is urged
refer REF [1] document for packet translation process

4.3. Session unbinding

Session unbinding is the phase in which a server node is no
responsible for the session. Usually, session unbinding happens
the end of session is detected. As described in the
section, it is not always easy to determine end of session

5. Load share

Many algorithms are available to select a host from a pool of
to service a new session. The load distribution is based primarily
(a) cost of accessing the network on which a server resides and
on the network interface used to access the server, and (b)
availability and system load on the server. A variety of policies
be adapted to distribute sessions across the servers in a
pool

For simplicity, we will consider two types algorithms, based
proximity between server nodes and LSNAT router. The higher the
of access to a sever, the farther the proximity of server is
to be. The first kind of algorithms will assume that all server
members are at equal or nearly equal proximity to LSNAT router
hence the load distribution can be based solely on
availability or system load on remote servers. Cost of network
will be considered irrelevant. The second kind would assume that
server pool members have equal resource availability and the
for selection would be proximity to servers. In other words,
consider algorithms which take into account the cost of
access

5.1. Local Load share

Ideally speaking, the selection process would have precise
of real-time resource availability and system load for each host
server pool, so that the selection of host with maximum
capacity would be the obvious choice. However, this is not so easy
achieve





Srisuresh & Gan Informational [Page 13]

RFC 2391 LSNAT August 1998


We consider here two kinds of heuristic approaches to monitor
load on server pool members. The first kind is where the load
selector tracks system load on individual servers in non-
way. The second kind is where the individual members
participate in communicating with the load share selector,
the selector of their load capacity

Listed below are the most common selection algorithms adapted in
non-intrusive category

1. Round-Robin
This is the simplest scheme, where a host is selected simply on
round robin basis, without regard to load on the host

2. Least Load first
This is an improvement over round-robin approach, in that,
host with least number of sessions bound to it is selected
service a new session. This approach is not without its caveats
Each session is assumed to be as resource consuming as any
session, independent of the type of service the session
and all hosts in server pool are assumed to be
resourceful

3. Least traffic first
A further improvement over the previous algorithm would be
measure system load by tracking packet count or byte
directed from or to each of the member hosts over a period
time. Although packet count is not the same as system load, it
a reasonable approximation

4. Least Weighted Load first
This would be an enhancement to the first two. This would
administrators to assign (a) weights to sessions, based on
resource consumption estimates of session types and (b) weights
hosts based on resource availability

The sum of all session loads by weight assigned to a server
divided by weight of server would be evaluated to select
server with least weighted load to assign for each new session
Say, FTP sessions are assigned 5 times the weight(5x) as a
session(x), and server S3 is assumed to be 3 times as
as server S1. Let us also say that S1 is assigned 1 FTP
and 1 telnet session, whereas S3 is assigned 2 FTP sessions and 5
telnet sessions. When a new telnet session need assignment,
weighted load on S3 is evaluated to be (2*5x+5*x)/3 = 5x, and
load on S1 is evaluated to be (1*5x+1*x) = 6x. Server S3
selected to bind the new telnet session, as the weighted load
S3 is smaller than that of S1.



Srisuresh & Gan Informational [Page 14]

RFC 2391 LSNAT August 1998


5. Ping to find the most responsive host
Till now, capacity of a member host is determined exclusively
the LSNAT using heuristic approaches. In reality, it is
to predict system capacity from remote, without interaction
member hosts. A prudent approach would be to periodically
member hosts and measure the response time to determine how
the hosts really are. Use the response time in conjunction
the heuristics to select the host most appropriate for the
session

In the active category, we involve individual member hosts
resource utilization monitoring process. An agent software on
node would notify the monitoring agent on resource availability
Clearly, this would imply having an application program (one
does not consume significant resources, by itself) to run on
member node. This strategy of involving member hosts in system
monitoring is likely to yield the most optimal results in
selection process

5.2. Distributed Load share

When server nodes are distributed geographically across
areas and cost to access them vary widely, the load share
could use that information in selecting a server to service a
session. In order to do this, the load share selector would need
consult the routing tables maintained by routing protocols such
RIP and OSPF to find the cost of accessing a server

All algorithms listed below would be non-intrusive kind where
server nodes do not actively participate in notifying the load
selector of their load capacity

1. Weighted Least Load first
The selection criteria would be based on (a) cost of access
server, and (b) the number of sessions assigned to server.
product of cost and session load for each server would
evaluated to select the server with least weighted load for
new session. Say, cost of accessing server S1 is twice as much
that of server S2. In that case, S1 will be assigned twice as
load as that of S2 during the distribution process. When a
is not accessible due to network failure, the cost of access
set to infinity and hence no further load can be assigned to
server

2. Weighted Least traffic first
An improvement over the previous algorithm would
to measure network load by tracking packet count or
count directed from or to each of the member hosts over



Srisuresh & Gan Informational [Page 15]

RFC 2391 LSNAT August 1998


period of time. Although packet count is not the same
system load, it is a reasonable approximation. So,
product of cost and traffic load (over a fixed duration
for each server would be evaluated to select the
with least weighted traffic load for each new session

6. Dead host

As sessions are assigned to hosts, it is important to detect
live-ness of the hosts. Otherwise, sessions could simply be black
holed into a dead host. Many heuristic approaches are adopted
Sending pings periodically would be one way to determine the live
ness. Another approach would be to track datagrams originating from
member host in response to new session assignments. If no
is detected in a few seconds, declare the server dead and do
assign new sessions to this host. The server can be monitored
again after a long pause (say, in the order of a few minutes)
periodically reassigning new sessions and monitoring response
and so on

7.

The IETF has been notified of potential intellectual Property
(IPR) issues with the technology described in this document
Interested people are requested to look in the IETF web
(http://www.ietf.org) under the Intellectual property Rights
section for the current information

8. Security

All security considerations associated with NAT routers, described
REF [1] are applicable to LSNAT routers as well



[1] Egevang, K. and P. Francis, "The IP Network Address
(NAT)", RFC 1631, May 1994.

[2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994. See also: http://www.iana.org/numbers.

[3] Braden, R., "Requirements for Internet Hosts --
Layers", STD 3, RFC 1122, October 1989.

[4] Braden, R., "Requirements for Internet Hosts -- Application
Support", STD 3, RFC 1123, October 1989.





Srisuresh & Gan Informational [Page 16]

RFC 2391 LSNAT August 1998


[5] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
June 1995.

[6] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)",
9, RFC 959, October 1985.

[7] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.

[8] Postel, J., "Internet Control Message (ICMP) Specification",
5, RFC 792, September 1981.

[9] Postel, J., "User Datagram Protocol (UDP)", STD 6, RFC 768,
August 1980.

[10] Mogul, J., and J. Postel, "Internet Standard
Procedure", STD 5, RFC 950, August 1985.

[11] Brisco, T., "DNS Support for Load Balancing", RFC 1794,
1995.

Authors'

Pyda
Lucent
4464 Willow
Pleasanton, CA 94588-8519
U.S.A

Voice: (925) 737-2153
Fax: (925) 737-2110
EMail: suresh@ra.lucent.


Der-hwa
Juniper Networks, Inc
385 Ravensdale Drive
Mountain View, CA 94043
U.S.A

Voice: (650) 526-8074
Fax: (650) 526-8001
EMail: dhg@juniper.








Srisuresh & Gan Informational [Page 17]

RFC 2391 LSNAT August 1998


Full Copyright

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

This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English

The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns

This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
























Srisuresh & Gan Informational [Page 18]

---

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.



RFC documents can be found at I.E.T.F.



Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX

---