rfc2391.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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

   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.

4.3. Session unbinding:

   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.

5. Load share algorithms

   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.

   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.

5.1. Local Load share algorithms

   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.





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


   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.

   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.

   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.

   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.

      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.



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


   5. Ping to find the most responsive host.
      Till now, capacity of a member host is determined exclusively 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.

   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.

5.2. Distributed Load share algorithms

   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.

   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.

   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



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


      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.

6. Dead host detection

   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.

7. Miscellaneous

   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.

8. Security Considerations

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

REFERENCES

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

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

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

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





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


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

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

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

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

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

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

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

Authors' Addresses

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

   Voice: [phone]
   Fax:   [phone]
   EMail: [e-mail]


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

   Voice: [phone]
   Fax:   [phone]
   EMail: [e-mail]








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


Full Copyright Statement

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

   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.
























Srisuresh & Gan              Informational                     [Page 18]