rfc985.txt

RFC 相关的技术文档

      such as used in EGP.

      Failure and restoration of a link and/or gateway are considered
      network events and must be reported to the control center.  It is
      desirable, although not required, that reporting paths not require
      correct functioning of the routing algorithm itself.

   6.2.  Routing Algorithm

      It has been the repeated experience of the Internet community
      participants that the routing mechanism, whether static or
      dynamic, is the single most important engineering issue in network
      design.  In all but trivial network topologies it is necessary
      that some degree of routing dynamics is vital to successful
      operation, whether it be affected by manual or automatic means or
      some combination of both.  In particular, if routing changes are
      made manually, the changes must be possible without taking down
      the gateways for reconfiguration and, preferably, be possible from
      a remote site such as a control center.

      It is not likely that all nets can be maintained from a
      full-service control center, so that automatic-fallback or
      rerouting features may be required.  This must be considered the
      normal case, so that systems of gateways operating as the only


NTAG                                                           [Page 12]



RFC 985                                                         May 1986
Requirements for Internet Gateways -- DRAFT


      packet switches in a network would normally be expected to have a
      routing algorithm with the capability of reacting to link and
      other gateway failures and changing the routing automatically.
      Following is a list of features considered necessary:

         1.  The algorithm must sense the failure or restoration of a
             link or other gateway and switch to appropriate paths
             within an interval less than the typical TCP user timeout
             (one minute is a safe assumption).

         2.  The algorithm must never form routing loops between
             neighbor gateways and must contain provisions to avoid and
             suppress routing loops that may form between non-neighbor
             gateways.  In no case should a loop persist for longer than
             an interval greater than the typical TCP user timeout.

         3.  The control traffic necessary to operate the routing
             algorithm must not significantly degrade or disrupt normal
             network operation. Changes in state which might momentarily
             disrupt normal operation in a local area must not cause
             disruption in remote areas of the network.

         4.  As the size of the network increases, the demand on
             resources must be controlled in an efficient way.  Table
             lookups should be hashed, for example, and data-base
             updates handled piecemeal, with only the changes broadcast
             over a wide area.  Reachability and delay metrics, if used,
             must not depend on direct connectivity to all other
             gateways or the use of network-specific broadcast
             mechanisms. Polling procedures (e.g.  for consistency
             checking) should be used only sparingly and in no case
             introduce an overhead exceeding a constant independent of
             network topology times the longest non-looping path.

         5.  The use of a default gateway as a means to reduce the size
             of the routing data base is strongly discouraged in view of
             the many problems with multiple paths, loops and
             mis-configuration vulnerabilities.  If used at all, it
             should be limited to a discovery function, with operational
             routes cached from external or internal data bases via
             either the routing algorithm or EGP.

         6.  This document places no restriction on the type of routing
             algorithm, such as node-based, link-based or any other
             algorithm, or metric, such as delay or hop-count.  However,
             the size of the routing data base must not be allowed to
             exceed a constant independent of network topology times the


NTAG                                                           [Page 13]



RFC 985                                                         May 1986
Requirements for Internet Gateways -- DRAFT


             number of nodes times the mean connectivity (average number
             of incident links).  An advanced design would not require
             that the entire routing data base be kept in any particular
             gateway, so that discovery and caching techniques would be
             necessary.

7.  Operation and Maintenance

   Gateways and packets switches are often operated as a system by some
   organization who agrees to operate and maintain the gateways, as well
   as to resolve link problems with the respective common carriers. It
   is important to note that the network control site may not be
   physically attached to the network being monitored.  In general, the
   following requirements apply:

      1.  Each gateway must operate as a stand-alone device for the
          purposes of local hardware maintenance.  Means must be
          available to run diagnostic programs at the gateway site using
          only on-site tools, which might be only a diskette or tape and
          local terminal.  It is desirable, although not required, to
          run diagnostics via the network and to automatically reboot
          and dump the gateway via the net in case of fault.  In
          general, this requires special hardware.

          The use of full-blown transport services such as TCP is in
          general ill-advised if required just to reboot and dump the
          gateway. Consideration should be given simple
          retransmission-overlay protocols based on UDP or specific
          monitoring protocols such as HMP described in RFC-869 [7].

      2.  It must be possible to reboot and dump the gateway manually
          from the control site.  Every gateway must include a watchdog
          timer that either initiates a reboot or signals a remote
          control site if not reset periodically by the software.  It is
          desirable that the data involved reside at the control site
          and be transmitted via the net; however, the use of local
          devices at the gateway site is acceptable. Nevertheless, the
          operation of initiating reboot or dump must be possible via
          the net, assuming a path is available and the connecting links
          are operating.

      3.  A mechanism must be provided to accumulate traffic statistics
          including, but not limited to, packet tallies, error-message
          tallies and so forth.  The preferred method of retrieving
          these data is by explicit, periodic request from the control
          site using a standard datagram protocol based on UDP or HMP.



NTAG                                                           [Page 14]



RFC 985                                                         May 1986
Requirements for Internet Gateways -- DRAFT


          The use of full-blown transport services such as TCP is in
          general ill-advised if required just to collect statistics
          from the gateway. Consideration should be given simple
          retransmission-overlay protocols based on UDP or HMP.

      4.  Exception reports ("traps") occuring as the result of hardware
          or software malfunctions should be transmitted immediately
          (batched to reduce packet overheads when possible) to the
          control site using a standard datagram protocol based on UDP
          or HMP.

      5.  A mechanism must be provided to display link and node status
          on a continuous basis at the control site.  While it is
          desirable that a complete map of all links and nodes be
          available, it is acceptable that only those components in use
          by the routing algorithm be displayed.  This information is
          usually available locally at the control site, assuming that
          site is a participant in the routing algorithm.

   The above functions require in general the participation of a control
   site or agent.  The preferred way to provide this is as a user
   program suitable for operation in a standard software environment
   such as Unix.  The program would use standard IP protocols such as
   TCP, UDP, and HMP to control and monitor the gateways.  The use of
   specialized host hardware and software requiring significant
   additional investment is strongly discouraged;  nevertheless, some
   vendors may elect to provide the control agent as an integrated part
   of the network in which the gateways are a part.  If this is the
   case, it is required that a means be available to operate the control
   agent from a remote site using Internet protocols and paths and with
   equivalent functionality with respect to a local agent terminal.

   Remote control of a gateway via Internet paths can involve either a
   direct approach, in which the gateway supports TCP and/or UDP
   directly, or an indirect approach, in which the control agent
   supports these protocols and controls the gateway itself using
   proprietary protocols. The former approach is preferred, although
   either approach is acceptable.











NTAG                                                           [Page 15]



RFC 985                                                         May 1986
Requirements for Internet Gateways -- DRAFT


8.  References and Bibliography

   [1]  Defense Advanced Research Projects Agency, "Internet Protocol",
        DARPA Network Working Group Report RFC-791, USC Information
        Sciences Institute, September 1981.

   [2]  Defense Advanced Research Projects Agency, "Internet Control
        Message Protocol", DARPA Network Working Group Report RFC-792,
        USC Information Sciences Institute, September 1981.

   [3]  Advanced Research Projects Agency, "Interface Message Processor
        - Specifications for the Interconnection of a Host and an IMP",
        BBN Report 1822, Bolt Beranek and Newman, December 1981.

   [4]  Plummer, D., "An Ethernet Address Resolution Protocol", DARPA
        Network Working Group Report RFC-826, Symbolics, September 1982.

   [5]  United States Department of Defense, "Military Standard Internet
        Protocol", Military Standard MIL-STD-1777, August 1983.

   [6]  Defense Communications Agency, "Defense Data Network X.25 Host
        Interface Specification", BBN Communications, December 1983.

   [7]  Hinden, R., "A Host Monitoring Protocol", DARPA Network Working
        Group Report RFC-869, BBN Communications, December 1983.

   [8]  Korb, J.T., "A Standard for the Transmission of IP Datagrams
        over Public Data Networks", DARPA Network Working Group Report
        RFC-877, Purdue University, September 1983.

   [9]  Nagle, J., "Congestion Control in IP/TCP Internetworks", DARPA
        Network Working Group Report RFC-896, Ford Aerospace,
        January 1984.

   [10] Hornig, C., "A Standard for the Transmission of IP Datagrams
        over Ethernet Networks", DARPA Network Working Group Report
        RFC-894, Symbolics, April 1984.

   [11] Mills, D.L., "Exterior Gateway formal Specification", DARPA
        Network Working Group Report RFC-904, M/A-COM Linkabit,
        April 1984.

   [12] Postel, J., and J. Reynolds., "ARPA-Internet Protocol Policy",
        DARPA Network Working Group Report RFC-902, USC Information
        Sciences Institute, July 1984.




NTAG                                                           [Page 16]



RFC 985                                                         May 1986
Requirements for Internet Gateways -- DRAFT


   [13] Kirton, P., "EGP Gateway under Berkeley UNIX 4.2", DARPA Network
        Working Group Report RFC-911, USC Information Sciences
        Institute, August 1984.

   [14] Postel, J., "Multi-LAN Address Resolution", DARPA Network
        Working Group Report RFC-925, USC Information Sciences
        Institute, October 1984.

   [15] International Standards Organization, "Protocol for Providing
        the Connectionless-Mode Network Services", DARPA Network Working
        Group Report RFC-926, International Standards Organization,
        December 1984.

   [16] National Research Council, "Transport Protocols for Department
        of Defense Data Networks", DARPA Network Working Group Report
        RFC-942, National Research Council, March 1985.

   [17] Postel, J., "DOD Statement on NRC Report", DARPA Network Working
        Group Report RFC-945, USC Information Sciences Institute,
        April 1985.

   [18] International Standards Organization, "Addendum to the Network
        Service Definition Covering Network Layer Addressing", DARPA
        Network Working Group Report RFC-941, International Standards
        Organization, April 1985.

   [19] Leiner, B., J. Postel, R. Cole and D. Mills, "The DARPA Internet
        Protocol Suite", Proceedings INFOCOM 85, Washington DC,
        March 1985]  Also in: IEEE Communications Magazine, March 1985.

   [20] Winston, I., "Two Methods for the Transmission of IP Datagrams
        over IEEE 802.3 Networks", DARPA Network Working Group Report
        RFC-948, University of Pennsylvania, June 1985.

   [21] Mogul, J., and J. Postel, "Internet Standard Subnetting
        Procedure", DARPA Network Working Group Report RFC-950, Stanford
        University, August 1985.

   [22] Reynolds, J., and J. Postel, "Official ARPA-Internet Protocols",
        DARPA Network Working Group Report RFC-961, USC Information
        Sciences Institute, October 1985.

   [23] Reynolds, J., and J. Postel, "Assigned Numbers", DARPA Network
        Working Group Report RFC-960, USC Information Sciences
        Institute, December 1985.




NTAG                                                           [Page 17]



RFC 985                                                         May 1986
Requirements for Internet Gateways -- DRAFT


   [24] Nagle, J., "On Packet Switches with Infinite Storage", DARPA
        Network Working Group Report RFC-970, Ford Aerospace,
        December 1985.

   [25] Defense Communications Agency, "DDN Protocol Handbook",
        NIC-50004, NIC-50005, NIC-50006, (three volumes), SRI
        International, December 1985.

   [26] Defense Communications Agency, "ARPANET Information Brochure",