[要約] RFC 2391は、IPネットワークアドレス変換（LSNAT）を使用した負荷分散に関するものであり、その目的は、複数のサーバー間でのトラフィックを均等に分散することです。
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.
Copyright（C）The Internet Society（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.
このドキュメントでは、RFC 1631で説明されているアドレス変換のアイデアとリアルタイムの負荷分散アルゴリズムを組み合わせて、負荷分散ネットワークアドレストランスレータ（または単に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は、プライベートネットワークドメインが1つのグローバルに一意の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 either direction. This document combines the characteristic of transparent address translation with real-time load share algorithms to introduce Load Share Network Address Translators.
従来、プライベートネットワークドメインをグローバルに一意のパブリックドメインIPネットワークに接続するために、ネットワークアドレストランスレータ、または単にNATが使用されていました。アプリケーションはプライベートドメインで発生し、NATはこれらのアプリケーションに属するデータグラムをどちらかの方向に透過的に変換します。このドキュメントでは、透過的なアドレス変換の特性とリアルタイムの負荷分散アルゴリズムを組み合わせて、負荷分散ネットワークアドレストランスレータを紹介します。
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リソースレコードを並べ替えるための巧妙なスキームを採用しています。 REF [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 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境界ルーターを通過します。このドキュメントの後半で、LSNATセットアップの特殊なケースを検討します。これは、サーバープールのトポロジー制約を回避します。 LSNATのもう1つの制限は、セッションの最中にホスト間で負荷を切り替えることができないことです。これは、LSNATがセッションの粒度で負荷を測定するためです。セッションがホストに割り当てられると、そのセッションが終了するまで、そのセッションを別のホストに移動することはできません。 REF [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ポートサービスの完全なリストは、REF [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 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セッションは、インバウンド方向とアウトバウンド方向の両方のパケットフローで構成されます。アウトバウンドtelnetパケットはクライアントからの端末のキーストロークを伝達し、インバウンドtelnetパケットは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.
TCPセッションの終わりは、FINがセッションの両方の半分によって確認されたとき、またはいずれかの半分がTCPフラグフィールドのRSTビットを受け取ったときに検出されます。セッションパートナーの1つが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.
セッションの終了を処理するもう1つの方法は、セッションにタイムスタンプを付けてできるだけ長く保持し、必要に応じて最長のアイドルセッションをリタイアすることです。
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ヘッダーベースのクエリIDは、応答と要求を関連付けるために使用されるので、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.
サーバークラスタ内のすべてのホストがすべてのサービスを実行する機能を備えている場合、負荷分散はすべてのサービスに適用できます。または、負荷分散は1つ以上の特定のサービスのみに制限され、他のサービスには制限されない場合があります。
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ポート）などのタプルで表される各セッションを、に基づいて選択されたサーバープールノードの1つにバインドすることにより、インバウンドセッションで変換を開始します。リアルタイムの負荷分散アルゴリズム。仮想サーバーアドレスは、類似した機能または同じ機能を提供できる物理サーバーまたはサーバーグループを識別するグローバルに一意の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と呼び、従来のNAT機能を示唆することなく、ロードシェアリングのコンテキストでのみLSNATを参照します。
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ルーターは、リアルタイムの負荷分散アルゴリズムを使用して選択されたサーバープール内のホストの1つに透過的に要求をリダイレクトします。同じクライアントから複数のセッションを開始することができ、そのときのサーバープールホスト間の負荷分散に基づいて、各セッションを異なるホストに送信できます。少数の特定のサービスだけにロードシェアが必要な場合は、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ポートサービスをバックアップサーバーのサービスに静的にマッピングすることもできます。
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）が、スタブドメインに限定されたサーバープールを形成しています。境界ルーターのLSNATがWANリンクで有効になっているため、仮想サーバーアドレスS（172.87.0.100）は、ホストS1、S2、およびS3で構成されるサーバープールにマップされます。クライアント198.76.29.7が仮想サーバーSへのHTTPセッションを開始すると、LSNATルーターはサーバープール内のホストの負荷を調べ、要求を処理するS1などのホストを選択します。 LSNATルーターによって実行される透過的なアドレスとTUポートの変換は、下矢印の線をたどると明らかになります。リターンパス上のIPパケットは、同様のアドレス変換を通過します。同じ仮想サーバーSへのTelnetセッションを開始する別のクライアント198.23.47.2があるとします。LSNATは、S1がセッションでビジーであり、セッションをS3にリダイレクトするため、ホストS3がこのセッションにサービスを提供するのに適していると判断します。 2番目のセッションリダイレクトパスは、コロンで区切られています。手順は、同じ方法で任意の数のセッションに対して続行されます。
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
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構成は、アウトバウンドセッションの変換に必要であり、Basic NATまたはNAPTのいずれかになります。次の図では、WANリンクのアウトバウンドがNAPT、インバウンドが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）があるとします。これは、仮想サーバーアドレスS（198.76.28.4）がホストS1、S2、S3で構成されるサーバープールにマップされるように、境界ルーターのWANリンクでLSNATを有効にすることで可能になります。外部クライアント198.76.29.7が仮想サーバーSへのHTTPセッションを開始すると、LSNATルーターはサーバープール内のホストの負荷を調べ、要求を処理するS1などのホストを選択します。 LSNATルーターによって実行される透過的なアドレスとTUポートの変換は、下矢印の線をたどると明らかです。リターンパス上のIPパケットは、同様のアドレス変換を通過します。同じアドレスへのTelnetセッションを開始する別のクライアント198.23.47.2があるとします。 S1はセッションでビジーであり、セッションをS3にリダイレクトするため、LSNATはホストS3がこのセッションにサービスを提供するのに適していると判断します。 2番目のセッションリダイレクトパスは、コロンで区切られています。手順は、同じ方法で任意の数のセッションに対して続行されます。
\ | /
+---------------+
|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：LPTATの運用、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.
このセクションでは、サーバーにトポロジ上の制限を適用せずにルーターで負荷分散を実現できる構成について説明します。この構成では、仮想サーバーアドレスは、負荷分散をサポートするルーターによって所有されます。つまり、仮想サーバーのアドレスは、負荷分散ルーターのインターフェースの1つのアドレスと同じになります。この構成をLSNATと区別するために、これを「負荷分散ネットワークアドレスポート変換」（LS-NAPT）と呼びます。 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ポートに変換することに注意してください。これは、そのインターフェイスの1つのアドレスと同じです。これにより、クライアントとサーバーからのデータグラムは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 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.
クライアント198.76.29.7が仮想サーバーアドレスS（つまり、WANインターフェイスのアドレス）へのHTTPセッションを開始すると、LS-NAPTルーターはサーバープール内のホストの負荷を調べ、要求を処理するS1などのホストを選択します。適切に、宛先アドレスはS1（172.85.0.1）に変換されます。さらに、元のクライアントアドレスとTUポートは、WANリンクのアドレスとTUポートに置き換えられます。その結果、下向き矢印のパスからわかるように、パケットがS1に到達すると、宛先アドレス、送信元アドレス、送信元TUポートが変換されます。リターンパス上のIPパケットは、同様の変換を通過します。同じ仮想サーバーアドレスSへのTelnetセッションを開始する2番目のクライアント198.23.47.2は、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
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構成に比べて複雑になります。処理は複雑ですが、この構成には利点があります。まず、サーバートポロジの制約を打破します。次に、クライアントアクセスの帯域幅拡張に合わせて拡張されます。現在、サービスプロバイダーがクライアントアクセス用に1つのリンクを持っている場合でも、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はアドレス変換に関連して次の3つのフェーズを監視する必要があります。
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 destination TU port, in case of TCP/UDP sessions) and related fields such as IP, TCP, UDP and ICMP header checksums) will undergo translation.
セッションの送信パケットの場合、送信元IPアドレス（およびTCP / UDPセッションの場合は送信元TUポート）と関連フィールド（IP、TCP、UDP、ICMPヘッダーチェックサムなど）が変換されます。セッションのインバウンドパケットの場合、宛先IPアドレス（およびTCP / UDPセッションの場合は宛先TUポート）および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データグラムに行われるヘッダーとペイロードの変更は、REF [1]のセクション5.0で説明されている従来のNATの対象となるものとまったく同じです。したがって、パケット変換プロセスについては、REF [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ルーター間の近接度に基づいて、2つのタイプのアルゴリズムを検討します。サーバーへのアクセスのコストが高いほど、サーバーの距離は遠いと見なされます。最初の種類のアルゴリズムは、すべてのサーバープールメンバーがLSNATルーターに等しいかほぼ等しいことを前提としているため、負荷分散は、リソースの可用性またはリモートサーバーのシステム負荷のみに基づくことができます。ネットワークアクセスのコストは無関係と見なされます。 2番目の種類は、すべてのサーバープールメンバーが等しいリソースの可用性を持ち、選択基準がサーバーに近いことを前提としています。つまり、ネットワークアクセスのコストを考慮したアルゴリズムを検討します。
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.
ここでは、サーバープールメンバーのセッション負荷を監視するための2種類のヒューリスティックなアプローチを検討します。最初の種類は、負荷分散セレクターが個々のサーバーのシステム負荷を非侵入型の方法で追跡する場所です。 2番目の種類は、個々のメンバーが負荷分散セレクターとの通信に積極的に参加し、負荷容量をセレクターに通知します。
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. 最小加重負荷の最初のアプローチこれは、最初の2つに対する拡張機能です。これにより、管理者は（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セッションには、telnetセッション（x）の5倍の重み（5x）が割り当てられており、サーバー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の加重負荷はS1のそれよりも小さいため、サーバーS3が新しいtelnetセッションをバインドするために選択されています。
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の2倍です。その場合、S1には、配布プロセス中にS2の2倍の負荷が割り当てられます。ネットワーク障害のためにサーバーにアクセスできない場合、アクセスのコストは無限に設定されるため、そのサーバーにそれ以上の負荷を割り当てることはできません。
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 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.
2.重み付け最小トラフィック最初のアルゴリズム以前のアルゴリズムに対する改善点は、一定期間に各メンバーホストからまたはメンバーホストに送信されたパケット数またはバイト数を追跡することにより、ネットワーク負荷を測定することです。パケット数はシステム負荷と同じではありませんが、妥当な概算です。したがって、各サーバーのコストとトラフィック負荷の積（一定の期間にわたる）を評価して、新しいセッションごとにトラフィック負荷が最小のサーバーを選択します。
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を送信することは、活性を判断する1つの方法です。別のアプローチは、新しいセッションの割り当てに応答して、メンバーホストから発信されたデータグラムを追跡することです。数秒以内に応答が検出されない場合は、サーバーが停止していることを宣言し、このホストに新しいセッションを割り当てないでください。定期的に新しいセッションを再割り当てして応答時間を監視することにより、長い休止後（たとえば、数分程度）にサーバーを再び監視できます。
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 Webページ（http://www.ietf.org）をご覧ください。
All security considerations associated with NAT routers, described in REF [1] are applicable to LSNAT routers as well.
REF [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、「The IP Network Address Translator（NAT）」、RFC 1631、1994年5月。
[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] ブレーデン、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] ベイカー、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、「File Transfer Protocol（FTP）」、STD 9、RFC 959、1985年10月。
[7] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[7] Postel、J。、「Transmission Control Protocol」、STD 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。、「User Datagram Protocol（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.
Pyda Srisuresh Lucent Technologies 4464 Willow Road Pleasanton、CA 94588-8519 U.S.A.
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 Ravensdale Drive。 Mountain View、CA 94043 U.S.A.
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.
Copyright（C）The Internet Society（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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。