rfc2391.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,012 行 · 第 1/3 页

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


       Load Sharing using IP Network Address Translation (LSNAT)

Status of this Memo

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

Copyright Notice

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

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.

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.

1. Introduction

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






Srisuresh & Gan              Informational                      [Page 1]

RFC 2391                         LSNAT                       August 1998


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

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

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

   The need for Load sharing arises when a single server is not able to
   cope with increasing demand for multiple sessions simultaneously.
   Clearly, load sharing across multiple servers would enhance
   responsiveness and scale well with session load. Popular applications
   inundating servers would include Web browsers, remote login, file
   transfer and mail applications.

   When a client attempts to access a server through an LSNAT router,
   the router selects a node in server pool, based on a load share
   algorithm and redirect the request to that node. LSNATs pose no
   restriction on the organization and rearrangement of nodes in server
   pool. Nodes in a pool may be replaced, new nodes may be added and
   others may be in transition. Changes of this kind to server pool can
   be shielded from client nodes by making LSNAT router the focal point
   for change management.

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



Srisuresh & Gan              Informational                      [Page 2]

RFC 2391                         LSNAT                       August 1998


   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.

   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.

2. Terminology and concepts used

2.1. TU ports, Server ports, Client ports

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

   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.

   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".

2.2. Session flow vs. Packet flow

   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



Srisuresh & Gan              Informational                      [Page 3]

RFC 2391                         LSNAT                       August 1998


   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.

   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).

2.3. Start of session for TCP, UDP and others

   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.

   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.

   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.

2.4. End of session for TCP, UDP and others

   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.

   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.



Srisuresh & Gan              Informational                      [Page 4]

RFC 2391                         LSNAT                       August 1998


   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.

2.5. Basic Network Address Translation (Basic NAT)

   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.

2.6. Network Address Port Translation (NAPT)

   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.

2.7. Load share

   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.






Srisuresh & Gan              Informational                      [Page 5]

RFC 2391                         LSNAT                       August 1998


   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.

3. Overview of Load sharing

   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.

   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.

   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.

   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.








Srisuresh & Gan              Informational                      [Page 6]