Network Working Group P. Srisuresh
Request for Comments: 2391 Lucent Technologies
Category: Informational D. Gan
Juniper Networks, Inc.
August 1998
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)
使用IP网络地址转换（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.
版权所有（C）互联网协会（1998年）。版权所有。
Preface
前言
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.
本文档将RFC1631中描述的地址转换思想与实时负载共享算法相结合，以引入负载共享网络地址转换器（或简称LSNAT）。LSNAT将透明地卸载单个服务器上的网络负载，并将负载分布到服务器池中。
Abstract
摘要
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.
网络地址转换器（NAT）在路由数据报的同时，对终端节点透明地转换数据报中的IP地址。NAT传统上被用来允许私有网络域使用一个全球唯一的IP地址连接到全球网络。在本文中，我们扩展了NAT的使用，以提供负载共享功能，其中会话负载可以分布在服务器池中，而不是定向到单个服务器。负载共享对于服务提供商和系统管理员来说都是有益的，因为它们可以在会话负载不断增加的情况下解决服务器的可伸缩性问题。
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
传统上，使用网络地址转换器或简单的NAT将专用网络域连接到全局唯一的公共域IP网络。应用程序起源于私有域，NAT将以透明的方式转换属于这些应用程序的数据报
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.
负载共享或负载平衡的问题并不新鲜，可以追溯到很多年前。应用了多种技术来解决这个问题。有些是非常特别的和特定于平台的，有些则采用巧妙的方案对DNS资源记录进行重新排序。参考文献[11]使用名称服务器中的DNS区域传输程序，根据预先确定的负载平衡算法定期洗牌服务器节点的资源记录顺序。这种方法的问题是，重新排序的时间段可能非常大，以分钟为单位，并且不能反映服务器上的实时负载变化。其次，假定服务器池中的所有主机具有提供所有服务的同等能力。这种情况可能并不常见。此外，可能需要仅支持少数特定服务的负载平衡。本文档中概述的负载共享方法解决了这两个问题，并提供了一个解决方案，该解决方案不需要对客户端或服务器进行更改，并且可以针对单个服务或所有服务进行定制。
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.
对于本文档的提醒，我们将提供负载共享支持的NAT路由器称为LSNAT。与传统NAT不同，LSNAT不需要单独在私有和公共域路由领域之间运行。LSNAT也在单一路由领域中运行，并提供负载共享功能。
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.
当单个服务器无法同时处理多个会话的日益增长的需求时，就需要负载共享。显然，跨多台服务器的负载共享将提高响应能力，并能很好地适应会话负载。淹没服务器的流行应用程序包括Web浏览器、远程登录、文件传输和邮件应用程序。
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.
当客户端试图通过LSNAT路由器访问服务器时，路由器根据负载共享算法选择服务器池中的节点，并将请求重定向到该节点。LSNAT对服务器池中节点的组织和重新排列没有限制。池中的节点可能会被替换，新节点可能会被添加，其他节点可能会处于转换中。通过使LSNAT路由器成为变更管理的焦点，可以屏蔽对服务器池的此类变更与客户端节点。
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
使用lsnat有一些限制。首先，必须通过相同的LSNAT路由器路由与客户端和服务器之间的会话相关的所有请求和响应。因此，我们建议在单个边界路由器上操作LSNAT，并将其连接到服务器池将被限制的存根域。这将确保
that all traffic directed to servers from clients outside the domain 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. Another limitation of LSNATs is the inability to switch loads between hosts in the midst of sessions. This is because LSNATs measure load in granularity of sessions. Once a session is assigned to a host, the session cannot be moved to a different host till the end of that session. Other limitations, inherent to NATs, as outlined in REF [1] are also applicable to LSNATs.
所有从域外的客户端定向到服务器的流量，反之亦然，都必须通过LSNAT边界路由器。在本文档的后面，我们将研究LSNAT设置的一个特例，它绕过了服务器池上的拓扑约束。LSNAT的另一个限制是无法在会话期间在主机之间切换负载。这是因为lsnat以会话的粒度度量负载。将会话分配给主机后，在会话结束之前，无法将会话移动到其他主机。参考文献[1]中概述的NAT固有的其他限制也适用于LSNAT。
As with traditional NATs, LSNATs have the disadvantage of taking away the end-to-end significance of an IP address. The major advantage, however, is that it can be installed without changes to clients or servers.
与传统的NAT一样，LSNAT的缺点是去掉了IP地址的端到端重要性。但是，它的主要优点是可以在不更改客户端或服务器的情况下安装。
For the reminder of this document, we will refer TCP/UDP ports associated with an IP address simply as "TU ports".
为了提醒您注意本文档，我们将与IP地址关联的TCP/UDP端口简称为“TU端口”。
For most TCP/IP hosts, TU port range 0-1023 is used by servers listening for incoming connections. Clients trying to initiate a connection typically select a TU port in the range of 1024-65535. However, this convention is not universal and not always followed. It is possible for client nodes to initiate connections using a TU port number in the range of 0-1023, and there are applications listening on TU port numbers in the range of 1024-65535.
对于大多数TCP/IP主机，侦听传入连接的服务器使用TU端口范围0-1023。尝试启动连接的客户端通常选择1024-65535范围内的TU端口。然而，这项公约并不普遍，也不总是得到遵守。客户端节点可以使用0-1023范围内的TU端口号启动连接，并且有应用程序侦听1024-65535范围内的TU端口号。
A complete list of TU port services may be found in REF [2]. The TU ports used by servers to listen for incoming connections are called "Server Ports" and the TU ports used by clients to initiate a connection to server are called "Client Ports".
TU端口服务的完整列表见参考文献[2]。服务器用于侦听传入连接的TU端口称为“服务器端口”，客户端用于启动到服务器的连接的TU端口称为“客户端端口”。
Connection or session flows are different from packet flows. A session flow indicates the direction in which the session was initiated with reference to a network port. Packet flow is the direction in which the packet has traversed with reference to a network port. A session flow is uniquely identified by the direction in which the first packet of that session traversed.
连接或会话流与数据包流不同。会话流指示会话相对于网络端口启动的方向。数据包流是数据包相对于网络端口经过的方向。会话流由该会话的第一个数据包所经过的方向唯一标识。
Take for example, a telnet session. The telnet session consists of packet flows in both inbound and outbound directions. Outbound telnet packets carry terminal keystrokes from the client and inbound telnet
以telnet会话为例。telnet会话由入站和出站方向的数据包流组成。出站telnet数据包携带来自客户端和入站telnet的终端击键
packets carry screen displays from the telnet server. Performing address translation for a telnet session would involve translation of incoming as well as outgoing packets belonging to that session.
数据包携带来自telnet服务器的屏幕显示。为telnet会话执行地址转换将涉及转换属于该会话的传入和传出数据包。
Packets belonging to a TCP/UDP session are uniquely identified by the tuple of (source IP address, source TU port, target IP address, target TU port). ICMP sessions that correlate queries and responses using query id are uniquely identified by the tuple of (source IP address, ICMP Query Identifier, target IP address). For lack of well-known ways to distinguish, all other types of sessions are lumped together and distinguished by the tuple of (source IP address, IP protocol, target IP address).
属于TCP/UDP会话的数据包由（源IP地址、源TU端口、目标IP地址、目标TU端口）的元组唯一标识。使用查询id关联查询和响应的ICMP会话由（源IP地址、ICMP查询标识符、目标IP地址）的元组唯一标识。由于缺乏众所周知的区分方法，所有其他类型的会话都集中在一起，并通过元组（源IP地址、IP协议、目标IP地址）进行区分。
The first packet of every TCP session tries to establish a session and contains connection startup information. The first packet of a TCP session may be recognized by the presence of SYN bit and absence of ACK bit in the TCP flags. All TCP packets, with the exception of the first packet must have the ACK bit set.
每个TCP会话的第一个数据包尝试建立会话，并包含连接启动信息。TCP会话的第一个分组可以通过TCP标志中存在SYN位和不存在ACK位来识别。除第一个数据包外，所有TCP数据包都必须设置ACK位。
The first packet of every session, be it a TCP session, UDP session, ICMP query session or any other session, tries to establish a session. However, there is no deterministic way of recognizing the start of a UDP session or any other non-TCP session.
每个会话的第一个数据包，无论是TCP会话、UDP会话、ICMP查询会话还是任何其他会话，都会尝试建立会话。但是，没有确定的方法来识别UDP会话或任何其他非TCP会话的开始。
Start of session is significant with NATs, as a state describing translation parameters for the session is established at the start of session. Packets pertaining to the session cannot undergo translation, unless a state is established by NAT at the start of session.
会话的开始对于NAT很重要，因为描述会话转换参数的状态是在会话开始时建立的。与会话相关的数据包不能进行转换，除非NAT在会话开始时建立状态。
The end of a TCP session is detected when FIN is acknowledged by both halves of the session or when either half receives RST bit in TCP flags field. Within a short period (say, a couple of seconds) after one of the session partners sets RST bit, the session can be safely assumed to have been terminated.
当FIN被会话的两个部分确认时，或者当任一部分接收到TCP标志字段中的RST位时，会检测到TCP会话的结束。在会话伙伴之一设置RST位后的短时间内（例如，几秒钟），可以安全地假定会话已终止。
For all other types of session, there is no deterministic way of determining the end of session unless you know the application protocol. Many heuristic approaches are used to terminate sessions. You can make the assumption that TCP sessions that have not been used for say, 24 hours, and non-TCP sessions that have not been used for say, 1 minute, are terminated. Often this assumption works, but sometimes it doesn't. These idle period session timeouts may vary considerably across the board and may be made user configurable.
对于所有其他类型的会话，除非您了解应用程序协议，否则无法确定会话的结束。许多启发式方法用于终止会话。您可以假设24小时内未使用的TCP会话和1分钟内未使用的非TCP会话都会终止。这种假设通常有效，但有时无效。这些空闲期会话超时可能会因系统而异，并且可以由用户配置。
Another way to handle session terminations is to timestamp sessions and keep them as long as possible and retire the longest idle session when it becomes necessary.
处理会话终止的另一种方法是为会话添加时间戳，并尽可能长地保留会话，并在必要时退出最长的空闲会话。
Basic NAT is a method by which hosts in a private network domain are allowed access to hosts in the external network transparently. A block of external addresses are set aside for translating addresses of private hosts as the private hosts originate sessions to applications in external domain. Once an external address is bound by the NAT device to a specific private address, that address binding remains in place for all subsequent sessions originating from the same private host. This binding may be terminated when there are no sessions left to use the binding.
基本NAT是一种允许私有网络域中的主机透明地访问外部网络中主机的方法。当私有主机发起会话到外部域中的应用程序时，会留出一块外部地址来转换私有主机的地址。一旦NAT设备将一个外部地址绑定到一个特定的专用地址，该地址绑定将保留在源于同一个专用主机的所有后续会话中。当没有剩余会话可使用绑定时，此绑定可能会终止。
Network Address Port Translation(NAPT) is a method by which hosts in a private network domain are allowed simultaneous access to hosts in the external network transparently using a single registered address. This is made possible by multiplexing transport layer identifiers of private hosts into the transport identifiers of the single assigned external address. For this reason, only the applications based on TCP and UDP protocols are supported by NAPT. ICMP query based applications are also supported as the ICMP header carries a query identifier that is used to corelate responses with requests. Sessions other than TCP, UDP and ICMP query type are simply not permitted from local nodes, serviced by a NAPT router.
网络地址端口转换（NAPT）是一种允许专用网络域中的主机使用单个注册地址透明地同时访问外部网络中主机的方法。这是通过将专用主机的传输层标识符多路复用到单个分配的外部地址的传输标识符中实现的。因此，NAPT只支持基于TCP和UDP协议的应用程序。还支持基于ICMP查询的应用程序，因为ICMP标头带有一个查询标识符，用于将响应与请求关联起来。除了TCP、UDP和ICMP查询类型之外的会话，根本不允许来自本地节点，由NAPT路由器提供服务。
Load sharing for the purpose of this document is defined as the spread of session load amongst a cluster of servers which are functionally similar or the same. In other words, each of the nodes in cluster can support a client session equally well with no discernible difference in functionality. Once a node is assigned to service a session, that session is bound to that node till termination. Sessions are not allowed to swap between nodes in the midst of session.
本文档中的负载共享定义为功能相似或相同的服务器集群之间的会话负载分布。换句话说，集群中的每个节点都可以同样好地支持客户机会话，并且在功能上没有明显差异。一旦一个节点被指派为会话服务，该会话将绑定到该节点，直到终止。在会话期间，不允许在节点之间交换会话。
Load sharing may be applicable for all services, if all hosts in server cluster carry the capability to carry out all services. Alternately, load sharing may be limited to one or more specific services alone and not to others.
如果服务器集群中的所有主机都具有执行所有服务的能力，则负载共享可能适用于所有服务。或者，负载共享可能仅限于一个或多个特定服务，而不限于其他服务。
Note, the term "Session load" used in the context of load share is different from the term "system load" attributed to hosts by way of CPU, memory and other resource usage on the system.
注意，在负载共享上下文中使用的术语“会话负载”不同于通过CPU、内存和系统上的其他资源使用归属于主机的术语“系统负载”。
While both traditional NATs and LSNATs perform address translations, and provide transparent connectivity between end nodes, there are distinctions between the two. Traditional NATs initiate translations on outbound sessions, by binding a private address to a global address (basic NAT) or by binding a tuple of private address and transport identifier (such as TCP/UDP port or ICPM query ID) to a tuple of global address and transport identifier. LSNATs, on the other hand, initiate translations on inbound sessions, by binding each session represented by a tuple such as (client address, client TU port, virtual server address, server TU port) to one of server pool nodes, selected based on a real-time load-share algorithm. A virtual server address is a globally unique IP address that identifies a physical server or a group of servers that can provide similar or same functionality.
虽然传统NAT和LSNAT都执行地址转换，并在终端节点之间提供透明连接，但两者之间存在区别。传统NAT通过将专用地址绑定到全局地址（基本NAT）或将专用地址和传输标识符的元组（如TCP/UDP端口或ICPM查询ID）绑定到全局地址和传输标识符的元组，在出站会话上启动转换。另一方面，LSNAT通过将元组（例如（客户端地址、客户端TU端口、虚拟服务器地址、服务器TU端口）表示的每个会话绑定到基于实时负载共享算法选择的服务器池节点之一，在入站会话上启动翻译。虚拟服务器地址是一个全局唯一的IP地址，用于标识可以提供类似或相同功能的物理服务器或服务器组。
For the reminder of this document, we will refer traditional NATs simply as NATs and refer LSNATs exclusively in the context of load share, without implying traditional NAT functionality.
为了提醒您注意本文档，我们将传统NAT简单地称为NAT，并在负载共享上下文中专门称为LSNAT，而不暗示传统NAT功能。
LSNATs are not limited to operate between private and public domain routing realms. LSNATs may operate within a single routing realm with globally unique IP addresses, just as well as between private and public network domains. The only requirement is that server pool be confined to a stub domain, accessible to clients outside the domain through a single LSNAT border router. However, as you will notice later, this topology limitation on server pool can be overcome under certain configurations.
LSNAT不限于在私有和公共域路由领域之间运行。LSNAT可以在具有全局唯一IP地址的单一路由域内运行，也可以在私有和公共网络域之间运行。唯一的要求是服务器池被限制在存根域中，域外的客户端可以通过单个LSNAT边界路由器访问。但是，正如您稍后将注意到的，在某些配置下，服务器池上的这种拓扑限制是可以克服的。
Load Share NAT operates as follows. A client attempts to access a server by using the server virtual address. The LSNAT router transparently redirects the request to one of the hosts in server pool, selected using a real-time load sharing algorithm. Multiple sessions may be initiated from the same client, and each session could be directed to a different host based on load balance across server pool hosts at the time. If load share is desired for just a few specific services, the configuration on LSNAT could be defined to restrict load share for just the services desired.
负载共享NAT的操作如下。客户端尝试使用服务器虚拟地址访问服务器。LSNAT路由器透明地将请求重定向到服务器池中使用实时负载共享算法选择的主机之一。可以从同一客户机启动多个会话，并且根据当时服务器池主机之间的负载平衡，可以将每个会话定向到不同的主机。如果只需要为几个特定的服务共享负载，那么可以定义LSNAT上的配置来限制只需要为所需的服务共享负载。
In the case where virtual server address is same as the interface address of an LSNAT router, server applications (such as telnet) on LSNAT router must be disabled for external access on that address. This is the limitation to using address owned by LSNAT router as the virtual server address.
在虚拟服务器地址与LSNAT路由器的接口地址相同的情况下，必须禁用LSNAT路由器上的服务器应用程序（如telnet），以便外部访问该地址。这是使用LSNAT路由器拥有的地址作为虚拟服务器地址的限制。
Load share NAT operation is also applicable during individual server upgrades as follows. Say, a server, that needs to be upgraded is statically mapped to a backup server on the inbound. Subsequent to this mapping, new session requests to the original server would be redirected by LSNAT to the backup server. As an extension, it is also possible to statically map a specific TU port service on a server to that of backup sever.
负载共享NAT操作也适用于单个服务器升级，如下所示。例如，需要升级的服务器静态映射到入站服务器上的备份服务器。在此映射之后，到原始服务器的新会话请求将由LSNAT重定向到备份服务器。作为扩展，还可以静态地将服务器上的特定TU端口服务映射到备份服务器的TU端口服务。
We illustrate the operation of LSNAT in the following subsections, where (a) servers are confined to a stub domain, and belong to globally unique address space as shared by clients, (b) servers are confined to private address space stub domain, and (c) servers are not restrained by any topological limitations.
我们在以下小节中说明了LSNAT的操作，其中（a）服务器被限制在存根域，并且属于客户端共享的全局唯一地址空间，（b）服务器被限制在私有地址空间存根域，并且（c）服务器不受任何拓扑限制。
In this section, we will illustrate the operation of LSNAT in a globally unique address space. The border router with LSNAT enabled on WAN link would perform load sharing and address translations for inbound sessions. However, sessions outbound from the hosts in server pool will not be subject to any type of translation, as all nodes have globally unique IP addresses.
在本节中，我们将说明LSNAT在全局唯一地址空间中的操作。WAN链路上启用LSNAT的边界路由器将为入站会话执行负载共享和地址转换。但是，由于所有节点都具有全局唯一的IP地址，所以从服务器池中的主机出站的会话将不受任何类型的转换的影响。
In the example below, servers S1 (172.85.0.1), S2(172.85.0.2) and S3(172.85.0.3) form a server pool, confined to a stub domain. LSNAT on the border router is enabled on the WAN link, such that the virtual server address S(172.87.0.100) is mapped to the server pool 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 router examines the load on hosts in server pool and selects a host, say S1 to service the request. The transparent address and TU port translations performed by the LSNAT router become 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 session to the same virtual server S. The LSNAT would determine that host S3 is a better choice to service this session as S1 is busy with a session and redirect the session to S3. The second session redirection path is delineated with colons. The procedure continues for any number of sessions the same way.
在下面的示例中，服务器S1（172.85.0.1）、S2（172.85.0.2）和S3（172.85.0.3）构成一个服务器池，仅限于存根域。在WAN链路上启用边界路由器上的LSNAT，以便虚拟服务器地址S（172.87.0.100）映射到由主机S1、S2和S3组成的服务器池。当客户端198.76.29.7启动到虚拟服务器S的HTTP会话时，LSNAT路由器检查服务器池中主机上的负载，并选择主机（例如S1）为请求提供服务。当您沿着向下箭头线移动时，LSNAT路由器执行的透明地址和TU端口转换变得显而易见。返回路径上的IP数据包经过类似的地址转换。假设我们有另一个客户端198.23.47.2启动到同一虚拟服务器的telnet会话。LSNAT将确定主机S3是更好的选择，因为S1正忙于会话，并将会话重定向到S3。第二个会话重定向路径用冒号表示。对于任意数量的会话，该过程以相同的方式继续。
Notice that this requires no changes to clients or servers. All the configuration and mapping necessary would be limited just to the LSNAT router.
请注意，这不需要更改客户端或服务器。所有必要的配置和映射将仅限于LSNAT路由器。
\ | /
+---------------+
|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
\ | /
+---------------+
|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 space
图1:LSNAT在全局唯一地址空间中的操作
In this section, we will illustrate the operation of LSNAT in conjunction with NAT on the same router. The NAT configuration is required for translation of outbound sessions and could be either Basic NAT or NAPT. The illustration below will assume NAPT on the outbound and LSNAT on the inbound on WAN link.
在本节中，我们将说明LSNAT与NAT在同一路由器上的操作。NAT配置是出站会话转换所必需的，可以是基本NAT或NAPT。下图将假定出站链路上的NAPT和入站WAN链路上的LSNAT。
Say, an organization has a private IP network and a WAN link to backbone router. The private network's stub router is assigned a globally valid address on the WAN link and the remaining nodes in the organization have IP addresses that have only local significance. The border router is NAPT configured on the outbound allowing access to external hosts, using the single registered IP address.
比如说，一个组织有一个专用IP网络和一个到骨干路由器的WAN链路。专用网络的存根路由器在WAN链路上分配了一个全局有效地址，组织中的其余节点具有仅具有本地意义的IP地址。边界路由器在出站上配置为NAPT，允许使用单个注册IP地址访问外部主机。
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 inbound access to external clients. This is made possible by enabling LSNAT on the WAN link of the border router, such that virtual server address S(198.76.28.4) is mapped to the server pool consisting of hosts S1, S2 and S3. When an external client 198.76.29.7 initiates a HTTP session to the virtual server S, the LSNAT router examines load on hosts in server pool and selects a host, say S1 to service the request. The transparent address and TU port translations performed 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 session to the same address. The LSNAT would determine that host S3 is a better choice to service this session as S1 is busy with a session and redirect the session to S3. The second session redirection path is delineated with colons. The procedure continues for any number of sessions the same way.
此外，假设该组织有服务器S1（10.0.0.1）、S2（10.0.0.2）和S3（10.0.0.3），它们构成一个池，为外部客户端提供入站访问。这是通过在边界路由器的WAN链路上启用LSNAT实现的，这样虚拟服务器地址S（198.76.28.4）映射到由主机S1、S2和S3组成的服务器池。当外部客户端198.76.29.7启动到虚拟服务器S的HTTP会话时，LSNAT路由器检查服务器池中主机上的负载，并选择主机（例如S1）来服务请求。LSNAT路由器执行的透明地址和TU端口转换在沿着向下箭头线进行时非常明显。返回路径上的IP数据包经过类似的地址转换。假设，我们有另一个客户端198.23.47.2启动到同一地址的telnet会话。LSNAT将确定主机S3是服务此会话的更好选择，因为S1正忙于会话并将会话重定向到S3。第二个会话重定向路径用冒号表示。对于任意数量的会话，该过程以相同的方式继续。
\ | /
+---------------+
|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
\ | /
+---------------+
|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 NAPT
图2:LSNAT与NAPT共存时的运行
Once again, notice that this requires no changes to clients or servers. The translation is completely transparent to end nodes. Address mapping on the LSNAT performs load sharing and address translations for inbound sessions. Sessions outbound from hosts in server pool are subject to NAPT. Both NAT and LSNAT co-exist with each other in the same router.
再次注意，这不需要更改客户端或服务器。转换对结束节点是完全透明的。LSNAT上的地址映射为入站会话执行负载共享和地址转换。来自服务器池中主机的出站会话受NAPT约束。NAT和LSNAT在同一路由器中共存。
In this section, we will illustrate a configuration in which load sharing can be accomplished on a router without enforcing topological limitations on servers. In this configuration, virtual server address will be owned by the router that supports load sharing. I.e., virtual server address will be same as address of one of the interfaces of load share router. We will distinguish this configuration from LSNAT by referring this as "Load Share Network Address Port Translation" (LS-NAPT). Routers that support the LS-NAPT configuration will be termed "LS-NAPT routers", or simply LS-NAPTs.
在本节中，我们将演示一种配置，在这种配置中，负载共享可以在路由器上完成，而无需对服务器施加拓扑限制。在此配置中，虚拟服务器地址将由支持负载共享的路由器拥有。即，虚拟服务器地址将与负载共享路由器的一个接口的地址相同。我们将通过将其称为“负载共享网络地址端口转换”（LS-NAPT）来区分此配置与LSNAT。支持LS-NAPT配置的路由器将被称为“LS-NAPT路由器”，或简称为LS-NAPT。
In an LSNAT router, inbound TCP/UDP sessions, represented by the tuple of (client address, client TU port, virtual server address, service port) are translated into a tuple of (client address, client TU port, selected server address, service port). Translation is carried out on all datagrams pertaining to the same session, in either direction. Whereas, LS-NAPT router would translate the same session into a tuple of (virtual server address, virtual server TU port, selected server, service port). Notice that LS-NAPT router translates the client address and TU port with the address and TU port of virtual server, which is same as the address of one of its interfaces. By doing this, datagrams from clients as well as servers are forced to bear the address of LS-NAPT router as the destination address, thereby guaranteeing that the datagrams would necessarily traverse the LS-NAPT router. As a result, there is no need to require servers to be under topological constraints.
在LSNAT路由器中，以元组（客户端地址、客户端TU端口、虚拟服务器地址、服务端口）表示的入站TCP/UDP会话被转换为元组（客户端地址、客户端TU端口、所选服务器地址、服务端口）。翻译是在同一会话的所有数据报上执行的，在任何一个方向。然而，LS-NAPT路由器将同一会话转换为（虚拟服务器地址、虚拟服务器TU端口、所选服务器、服务端口）的元组。请注意，LS-NAPT路由器将客户机地址和TU端口转换为虚拟服务器的地址和TU端口，这与其一个接口的地址相同。通过这样做，来自客户端和服务器的数据报被迫以LS-NAPT路由器的地址作为目标地址，从而保证数据报必然会穿过LS-NAPT路由器。因此，不需要要求服务器受拓扑约束。
Take for example, figure 1 in section 3.1. Let us say the router on which load sharing is enabled is not just a border router, but can be any kind of router. Let us also say that the virtual server address S (172.87.0.100) is same as the address of WAN link and LS-NAPT is enabled on the WAN interface. Figure 3 summarizes the new router configuration.
以第3.1节中的图1为例。假设启用负载共享的路由器不仅仅是边界路由器，还可以是任何类型的路由器。我们还可以说，虚拟服务器地址S（172.87.0.100）与WAN链路的地址相同，并且在WAN接口上启用了LS-NAPT。图3总结了新的路由器配置。
When a client 198.76.29.7 initiates a HTTP session to the virtual server address S (i.e., address of the WAN interface), the LS-NAPT router examines load on hosts in server pool and selects a host, say S1 to service the request. Appropriately, the destination address is translated to be S1 (172.85.0.1). Further, original client address and TU port are replaced with the address and TU port of the WAN
当客户端198.76.29.7向虚拟服务器地址S（即WAN接口的地址）发起HTTP会话时，LS-NAPT路由器检查服务器池中主机上的负载，并选择主机，例如S1来服务请求。适当地，目标地址被转换为S1（172.85.0.1）。此外，原始客户端地址和TU端口被替换为WAN的地址和TU端口
link. As a result, destination addresses as well as source address and source TU port are translated when the packet reaches S1, as can be noticed from the down-arrow path. IP packets on the return path go through similar translation. The second client 198.23.47.2 initiating telnet session to the same virtual server address S is load share directed to S3. This packet once again undergoes LS-NAPT translation, just as with the first client. The data path and translations can be noticed following the colon line. The procedure continues for any number of sessions the same way. The translations made to datagrams in either direction are completely transparent to end nodes.
链接结果，当分组到达S1时，目的地地址以及源地址和源TU端口被转换，这可以从向下箭头路径中注意到。返回路径上的IP数据包经过类似的转换。第二个客户端198.23.47.2启动到相同虚拟服务器地址S的telnet会话，并将负载共享定向到S3。此数据包再次进行LS-NAPT转换，就像第一个客户端一样。在冒号线之后可以看到数据路径和转换。对于任意数量的会话，该过程以相同的方式继续。在任意方向对数据报进行的转换对终端节点都是完全透明的。
\ | /
+---------------+
| 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
\ | /
+---------------+
| 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 router
图3：路由器上的LS-NAPT配置
As you will notice, datagrams from clients as well as servers are forced to be directed to the router, because they use WAN interface address of router as the destination address in their datagrams. With the assurance that all packets from clients and servers would traverse the router, there is no longer a requirement for servers to be confined to a stub domain and for LSNAT to be enabled only on border router to the stub domain.
正如您将注意到的，来自客户端和服务器的数据报被强制定向到路由器，因为它们使用路由器的WAN接口地址作为其数据报中的目标地址。在保证来自客户端和服务器的所有数据包都将通过路由器的情况下，不再需要将服务器限制在存根域中，也不再需要仅在存根域的边界路由器上启用LSNAT。
The LS-NAPT configuration described in this section involves more translations and hence is more complex compared to LSNAT configurations described in the previous sections. While the processing is complex, there are benefits to this configuration. Firstly, it breaks down restraints on server topology. Secondly, it scales with bandwidth expansion for client access. Even if Service providers have one link today for client access, the LS-NAPT configuration allows them to expand to more links in the future guaranteeing the same LS-NAPT load share service on newer links.
本节中描述的LS-NAPT配置涉及更多的转换，因此与前几节中描述的LSNAT配置相比更加复杂。虽然处理过程很复杂，但这种配置也有好处。首先，它打破了对服务器拓扑结构的限制。其次，它随着客户端访问的带宽扩展而扩展。即使服务提供商现在有一个用于客户端访问的链路，LS-NAPT配置也允许他们将来扩展到更多链路，从而保证在较新的链路上提供相同的LS-NAPT负载共享服务。
The configuration is not without its limitations. Server applications (such as telnet) on the router box would have to be disabled for the interface address assigned to be virtual server address. Load sharing would be limited to TCP and UDP applications only. Maximum concurrently allowed sessions would be limited by the maximum allowed 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 a maximum of 63K TCP client ports and 63K of UDP client ports on the LS-NAPT router to communicate with each load-share server. As a result, LS-NAPT routers will not be able to concurrently support more than a maximum of (63K * count of Load-share servers) TCP sessions and (63K * count of Load-share servers) UDP sessions.
这种配置并非没有其局限性。对于分配为虚拟服务器地址的接口地址，必须禁用路由器盒上的服务器应用程序（如telnet）。负载共享将仅限于TCP和UDP应用程序。同时允许的最大会话数将受到同一地址上允许的最大TCP/UDP客户端端口数的限制。假设端口0-1023必须作为已知服务端口留出，则LS-NAPT路由器上最多会有63K TCP客户端端口和63K UDP客户端端口与每个负载共享服务器通信。因此，LS-NAPT路由器最多不能同时支持（63K*负载共享服务器数）TCP会话和（63K*负载共享服务器数）UDP会话。
4.0. Translation phases of a session in LSNAT router.
4.0. LSNAT路由器中会话的转换阶段。
As with NATs, LSNATs must monitor the following three phases in relation to Address translation.
与NAT一样，LSNAT必须监控地址转换的以下三个阶段。
4.1. Session binding:
4.1. 会话绑定：
Session binding is the phase in which an incoming session is associated with the address of a host in server pool. This association essentially sets the translation parameters for all subsequent datagrams pertaining to the session. For addresses that have static mapping, the binding happens at startup time. Otherwise, each incoming session is dynamically bound to a different host based on a load sharing algorithm.
会话绑定是将传入会话与服务器池中主机的地址关联的阶段。此关联本质上为与会话相关的所有后续数据报设置转换参数。对于具有静态映射的地址，绑定在启动时发生。否则，每个传入会话将基于负载共享算法动态绑定到不同的主机。
4.2. Address lookup and translation:
4.2. 地址查找和转换：
Once session binding is established for a connection setup, all subsequent packets belonging to the same connection will be subject to session lookup for translation purposes.
一旦为连接设置建立了会话绑定，属于同一连接的所有后续数据包都将进行会话查找，以便进行转换。
For outbound packets of a session, the source IP address (and source TU port, in case of TCP/UDP sessions) and related fields (such as IP, TCP, UDP and ICMP header checksums) will undergo translation. For inbound packets of a session, the destination IP address (and
对于会话的出站数据包，将对源IP地址（以及源TU端口，如果是TCP/UDP会话）和相关字段（如IP、TCP、UDP和ICMP标头校验和）进行转换。对于会话的入站数据包，目标IP地址（和
destination TU port, in case of TCP/UDP sessions) and related fields such as IP, TCP, UDP and ICMP header checksums) will undergo translation.
目标TU端口（在TCP/UDP会话的情况下）和相关字段（如IP、TCP、UDP和ICMP标头校验和）将进行转换。
The header and payload modifications made to IP datagrams subject to LSNAT will be exactly same as those subject to traditional NATs, described in section 5.0 of REF [1]. Hence, the reader is urged to refer REF [1] document for packet translation process.
对受LSNAT约束的IP数据报进行的报头和有效载荷修改将与受传统NAT约束的报头和有效载荷修改完全相同，如参考文献[1]第5.0节所述。因此，敦促读者参考参考文献[1]以进行分组翻译过程。
4.3. Session unbinding:
4.3. 会话解除绑定：
Session unbinding is the phase in which a server node is no longer responsible for the session. Usually, session unbinding happens when the end of session is detected. As described in the terminology section, it is not always easy to determine end of session.
会话解除绑定是服务器节点不再负责会话的阶段。通常，当检测到会话结束时，会发生会话解除绑定。如术语部分所述，确定会话结束并不总是容易的。
Many algorithms are available to select a host from a pool of servers to service a new session. The load distribution is based primarily on (a) cost of accessing the network on which a server resides and load on the network interface used to access the server, and (b)resource availability and system load on the server. A variety of policies can be adapted to distribute sessions across the servers in a server pool.
有许多算法可用于从服务器池中选择主机为新会话提供服务。负载分布主要基于（a）访问服务器所在网络的成本和用于访问服务器的网络接口上的负载，以及（b）服务器上的资源可用性和系统负载。可以调整各种策略，以便在服务器池中跨服务器分发会话。
For simplicity, we will consider two types algorithms, based on proximity between server nodes and LSNAT router. The higher the cost of access to a sever, the farther the proximity of server is assumed to be. The first kind of algorithms will assume that all server pool members are at equal or nearly equal proximity to LSNAT router and hence the load distribution can be based solely on resource availability or system load on remote servers. Cost of network access will be considered irrelevant. The second kind would assume that all server pool members have equal resource availability and the criteria for selection would be proximity to servers. In other words, we consider algorithms which take into account the cost of network access.
为了简单起见，我们将考虑两种类型的算法，基于服务器节点和LSNAT路由器之间的接近度。访问服务器的成本越高，服务器的距离就越近。第一类算法将假定所有服务器池成员与LSNAT路由器的距离相等或几乎相等，因此负载分布可以仅基于远程服务器上的资源可用性或系统负载。网络接入成本将被视为无关紧要。第二类假设所有服务器池成员具有相同的资源可用性，选择的标准是接近服务器。换言之，我们考虑算法，考虑到网络接入的成本。
Ideally speaking, the selection process would have precise knowledge of real-time resource availability and system load for each host in server pool, so that the selection of host with maximum unutilized capacity would be the obvious choice. However, this is not so easy to achieve.
理想情况下，选择过程将精确了解服务器池中每个主机的实时资源可用性和系统负载，因此选择具有最大未使用容量的主机将是显而易见的选择。然而，这并非易事。
We consider here two kinds of heuristic approaches to monitor session load on server pool members. The first kind is where the load share selector tracks system load on individual servers in non-intrusive way. The second kind is where the individual members actively participate in communicating with the load share selector, notifying the selector of their load capacity.
这里我们考虑两种启发式方法来监视服务器池成员的会话负载。第一种是负载共享选择器以非侵入方式跟踪单个服务器上的系统负载。第二种情况是，各个成员积极参与与负载共享选择器的通信，通知选择器其负载能力。
Listed below are the most common selection algorithms adapted in the non-intrusive category.
下面列出了适用于非侵入性类别的最常见选择算法。
1. Round-Robin algorithm This is the simplest scheme, where a host is selected simply on a round robin basis, without regard to load on the host.
1. 循环算法这是最简单的方案，只需在循环的基础上选择主机，而不考虑主机上的负载。
2. Least Load first algorithm This is an improvement over round-robin approach, in that, the host with least number of sessions bound to it is selected to service a new session. This approach is not without its caveats. Each session is assumed to be as resource consuming as any other session, independent of the type of service the session represents and all hosts in server pool are assumed to be equally resourceful.
2. 最小负载优先算法这是对循环方法的改进，即选择绑定会话数最少的主机为新会话提供服务。这种方法并非没有警告。假定每个会话与任何其他会话一样消耗资源，独立于会话所代表的服务类型，并且假定服务器池中的所有主机资源相同。
3. Least traffic first algorithm A further improvement over the previous algorithm would be to measure system load by tracking packet count or byte count directed from or to each of the member hosts over a period of time. Although packet count is not the same as system load, it is a reasonable approximation.
3. 最小流量优先算法与先前算法相比的进一步改进是通过跟踪一段时间内从每个成员主机发送或发送到每个成员主机的数据包计数或字节计数来测量系统负载。虽然数据包计数与系统负载不同，但它是一个合理的近似值。
4. Least Weighted Load first approach This would be an enhancement to the first two. This would allow administrators to assign (a) weights to sessions, based on likely resource consumption estimates of session types and (b) weights to hosts based on resource availability.
4. 最小加权负载优先法这是对前两种方法的改进。这将允许管理员（a）根据会话类型的可能资源消耗估计为会话分配权重，（b）根据资源可用性为主机分配权重。
The sum of all session loads by weight assigned to a server, divided by weight of server would be evaluated to select the server with least weighted load to assign for each new session. Say, FTP sessions are assigned 5 times the weight(5x) as a telnet session(x), and server S3 is assumed to be 3 times as resourceful as server S1. Let us also say that S1 is assigned 1 FTP session and 1 telnet session, whereas S3 is assigned 2 FTP sessions and 5 telnet sessions. When a new telnet session need assignment, the weighted load on S3 is evaluated to be (2*5x+5*x)/3 = 5x, and the load on S1 is evaluated to be (1*5x+1*x) = 6x. Server S3 is selected to bind the new telnet session, as the weighted load on S3 is smaller than that of S1.
将计算所有会话负载的总和（按分配给服务器的权重除以服务器的权重），以选择为每个新会话分配的负载权重最小的服务器。比如说，FTP会话的权重（5x）是telnet会话（x）的5倍，服务器S3的资源是服务器S1的3倍。我们还可以说，S1分配了1个FTP会话和1个telnet会话，而S3分配了2个FTP会话和5个telnet会话。当新的telnet会话需要分配时，S3上的加权负载评估为（2*5x+5*x）/3=5x，S1上的负载评估为（1*5x+1*x）=6x。选择服务器S3绑定新的telnet会话，因为S3上的加权负载小于S1。
5. Ping to find the most responsive host. Till now, capacity of a member host is determined exclusively by the LSNAT using heuristic approaches. In reality, it is impossible to predict system capacity from remote, without interaction with member hosts. A prudent approach would be to periodically ping member hosts and measure the response time to determine how busy the hosts really are. Use the response time in conjunction with the heuristics to select the host most appropriate for the new session.
5. Ping以查找响应速度最快的主机。到目前为止，成员主机的容量完全由LSNAT使用启发式方法确定。实际上，如果不与成员主机交互，就不可能从远程预测系统容量。谨慎的方法是定期ping成员主机并测量响应时间，以确定主机的实际繁忙程度。将响应时间与启发式方法结合使用，以选择最适合新会话的主机。
In the active category, we involve individual member hosts in resource utilization monitoring process. An agent software on each node would notify the monitoring agent on resource availability. Clearly, this would imply having an application program (one that does not consume significant resources, by itself) to run on each member node. This strategy of involving member hosts in system load monitoring is likely to yield the most optimal results in the selection process.
在活动类别中，我们让单个成员主机参与资源利用率监视过程。每个节点上的代理软件将通知监视代理资源可用性。显然，这意味着在每个成员节点上运行一个应用程序（一个本身不消耗大量资源的应用程序）。这种让成员主机参与系统负载监控的策略可能会在选择过程中产生最佳结果。
When server nodes are distributed geographically across different areas and cost to access them vary widely, the load share selector could use that information in selecting a server to service a new session. In order to do this, the load share selector would need to consult the routing tables maintained by routing protocols such as RIP and OSPF to find the cost of accessing a server.
当服务器节点在地理上分布在不同的区域并且访问它们的成本差异很大时，负载共享选择器可以使用该信息来选择为新会话提供服务的服务器。为此，负载共享选择器需要查阅路由协议（如RIP和OSPF）维护的路由表，以查找访问服务器的成本。
All algorithms listed below would be non-intrusive kind where the server nodes do not actively participate in notifying the load share selector of their load capacity.
下面列出的所有算法都是非侵入式的，其中服务器节点不主动参与通知负载共享选择器其负载容量。
1. Weighted Least Load first algorithm The selection criteria would be based on (a) cost of access to server, and (b) the number of sessions assigned to server. The product of cost and session load for each server would be evaluated to select the server with least weighted load for each new session. Say, cost of accessing server S1 is twice as much as that of server S2. In that case, S1 will be assigned twice as much load as that of S2 during the distribution process. When a server is not accessible due to network failure, the cost of access is set to infinity and hence no further load can be assigned to that server.
1. 加权最小负载优先算法选择标准将基于（a）访问服务器的成本和（b）分配给服务器的会话数。将评估每个服务器的成本和会话负载的乘积，以选择每个新会话的负载加权最小的服务器。比如说，访问服务器S1的成本是服务器S2的两倍。在这种情况下，在分配过程中，S1将被分配两倍于S2的负载。当由于网络故障而无法访问服务器时，访问成本设置为无穷大，因此无法为该服务器分配更多负载。
2. Weighted Least traffic first algorithm An improvement over the previous algorithm would be to measure network load by tracking packet count or byte count directed from or to each of the member hosts over a
2. 加权最小流量优先算法与前一种算法相比的一个改进是，通过跟踪一段时间内从每个成员主机发送或发送到每个成员主机的数据包计数或字节计数来测量网络负载
period of time. Although packet count is not the same as system load, it is a reasonable approximation. So, the product of cost and traffic load (over a fixed duration) for each server would be evaluated to select the server with least weighted traffic load for each new session.
一段时间。虽然数据包计数与系统负载不同，但它是一个合理的近似值。因此，将评估每台服务器的成本和流量负载（在固定的持续时间内）的乘积，以便为每个新会话选择具有最小加权流量负载的服务器。
As sessions are assigned to hosts, it is important to detect the 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 a member host in response to new session assignments. If no response is detected in a few seconds, declare the server dead and do not assign new sessions to this host. The server can be monitored later again after a long pause (say, in the order of a few minutes) by periodically reassigning new sessions and monitoring response times and so on.
由于会话被分配给主机，因此检测主机的活动状态非常重要。否则，会话可能会被隐藏在一个死主机中。采用了许多启发式方法。定期发送ping将是确定活动状态的一种方法。另一种方法是跟踪来自成员主机的数据报，以响应新的会话分配。如果在几秒钟内未检测到响应，请声明服务器已死亡，并且不要为此主机分配新会话。在长时间暂停（比如几分钟）后，可以通过定期重新分配新会话和监视响应时间等方式再次监视服务器。
The IETF has been notified of potential intellectual Property Rights (IPR) issues with the technology described in this document. Interested people are requested to look in the IETF web page (http://www.ietf.org) under the Intellectual property Rights Notices section for the current information.
IETF已收到关于本文件所述技术的潜在知识产权（IPR）问题的通知。请感兴趣的人查看IETF网页(http://www.ietf.org)有关当前信息，请参见“知识产权公告”部分。
All security considerations associated with NAT routers, described in REF [1] are applicable to LSNAT routers as well.
参考文献[1]中描述的与NAT路由器相关的所有安全注意事项也适用于LSNAT路由器。
REFERENCES
参考资料
[1] Egevang, K. and P. Francis, "The IP Network Address Translator (NAT)", RFC 1631, May 1994.
[1] Egevang，K.和P.Francis，“IP网络地址转换器（NAT）”，RFC16311994年5月。
[2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994. See also: http://www.iana.org/numbers.html
[2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994. See also: http://www.iana.org/numbers.html
[3] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[3] Braden，R.，“互联网主机的要求——通信层”，STD 3，RFC 1122，1989年10月。
[4] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[4] Braden，R.，“互联网主机的要求——应用和支持”，STD 3，RFC 1123，1989年10月。
[5] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[5] Baker，F.，“IP版本4路由器的要求”，RFC 1812，1995年6月。
[6] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, October 1985.
[6] Postel，J.和J.Reynolds，“文件传输协议（FTP）”，标准9，RFC 959，1985年10月。
[7] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[7] 《传输控制协议》，标准7，RFC 793，1981年9月。
[8] Postel, J., "Internet Control Message (ICMP) Specification", STD 5, RFC 792, September 1981.
[8] Postel，J.，“互联网控制信息（ICMP）规范”，STD 5，RFC 792，1981年9月。
[9] Postel, J., "User Datagram Protocol (UDP)", STD 6, RFC 768, August 1980.
[9] Postel，J.，“用户数据报协议（UDP）”，STD 6，RFC 768，1980年8月。
[10] Mogul, J., and J. Postel, "Internet Standard Subnetting Procedure", STD 5, RFC 950, August 1985.
[10] Mogul，J.和J.Postel，“互联网标准子网程序”，STD 5，RFC 950，1985年8月。
[11] Brisco, T., "DNS Support for Load Balancing", RFC 1794, April 1995.
[11] Brisco，T.，“DNS对负载平衡的支持”，RFC 1794，1995年4月。
Authors' Addresses
作者地址
Pyda Srisuresh Lucent Technologies 4464 Willow Road Pleasanton, CA 94588-8519 U.S.A.
美国加利福尼亚州普莱森顿柳树路4464号Pyda Srisuresh-Lucent Technologies，邮编94588-8519。
Voice: (925) 737-2153 Fax: (925) 737-2110 EMail: suresh@ra.lucent.com
语音：（925）737-2153传真：（925）737-2110电子邮件：suresh@ra.lucent.com
Der-hwa Gan Juniper Networks, Inc. 385 Ravensdale Drive. Mountain View, CA 94043 U.S.A.
Der hwa Gan Juniper Networks，Inc.天之谷大道385号。美国加利福尼亚州山景城94043。
Voice: (650) 526-8074 Fax: (650) 526-8001 EMail: dhg@juniper.net
语音：（650）526-8074传真：（650）526-8001电子邮件：dhg@juniper.net
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。