rfc1270.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 619 行 · 第 1/2 页

   what higher-level protocol services may be available, so those
   services can not be used.  If an arbitrary choice is made for
   example, to put in an elementary UDP/IP stack, then there may be two
   independent UDP/IPs in the system (which is undesireable as this
   would require two IP addresses per managed node), or a new protocol
   stack will be introduced into the environment.

6.  Connection Oriented vs. Connectionless

   While this section primarily addresses itself to transport layer
   issues, its basic discussion of connection oriented vs connectionless
   applies to any layer which provides communication services for SNMP.

   For SNMP, connectionless transport service (UDP) is specified in the
   Protocol Specification [1].  This choice was made after careful study
   and consideration by the original SNMP developers.

   The prime motivation of this choice is that SNMP must continue to
   operate (if at all possible) when the network is operating at its
   worst.  For other applications, such as Telnet or FTP, the user can
   always "try again later" if the network is operating poorly.  On the
   other hand, the major purpose of a network management protocol is to
   fix the network when it is operating poorly so the "try again later"
   strategy is useless.



SNMP Working Group                                              [Page 6]

RFC 1270              SNMP Communications Services          October 1991


   By using a connectionless transport protocol, SNMP takes on the
   responsibility of reliable data transmission (A SNMP application may
   time out outstanding requests and either retransmit them or abort
   them as appropriate).  However, the SNMP requires these functions
   only of the sender of a Request PDU (get, getNext, or Set), which
   typically is a network management station.  Since the Agent only
   generates responses, it need not perform any of these functions.
   This vastly reduces the resource and functional requirements on the
   Agent.

   If a connection oriented transport is used, then a fundamental design
   choice must be made with respect to connection maintenance:

          (1)  Keep a connection open to each managed object on the
               network,

          (2)  Establish and tear down connections on a per-operation
               basis, or

          (3)  Keep a fixed number of connections open and, when another
               connection is needed, use some algorithm (e.g., LRU) to
               select one for closing and opening to the new agent.

   All of these alternatives pose severe problems, and because of them,
   each is undesirable.

   The first option reduces the amount of resources required to perform
   a single operation in that the connection establishment and
   termination cost is "amortized" over many operations.  On the other
   hand, keeping a connection open implies that the management station
   needs to maintain a large number of connection records (in the
   hundreds or even thousands).  Furthermore, if either side of the
   connection engages in "keep-alives" (even though such behavior is
   frowned upon), a large amount of traffic will be generated, consuming
   a large amount of network resources, all for no gain.

   The second option reduces the amount of idle resources such as
   connection records, but vastly increases the amount of resources
   required to perform an operation.  A connection must be established,
   the request Message sent and the response returned, and then the
   connection closed for each operation.  For a TCP, this would
   typically require 10 separate packet transfers plus the TCP Time-Wait
   (see the Appendix for details).

   In the face of pathological network problems, a connection oriented
   transport protocol may simply cease to operate because the
   probability of getting all of these packets through reduces to a very
   small number.



SNMP Working Group                                              [Page 7]

RFC 1270              SNMP Communications Services          October 1991


   The third option requires that the management station maintain
   connection usage information in order to implement the LRU algorithm.
   This excessively complicates the management station.  Furthermore,
   this option tends to reduce to the second option when doing health
   check polling for a number of agents that is large compared to the
   number of supported connections.

   A connection oriented transport protocol may provide services that
   are undesirable or unneeded by SNMP.

   For example, one application of network management is to poll nodes
   to determine if they are up or not.  When a node is up, it makes
   little difference whether SNMP operates over TCP or UDP.  However, if
   the node goes down then TCP will eventually close the connection.
   Every poll request must then be translated into a TCP Open request
   while the managed node is down.  Once the node comes up, the send
   must then be done.

   For connection oriented transports, the transport ACK does not
   necessarily indicate delivery of data to the destination application
   process (for TCP, see section 2.6 of [4]).  The SNMP would still need
   its own timeout/retry procedure to ensure that the SNMP software
   actually got the packet.

   A connection oriented transport such as TCP provides flow control for
   the data stream.  Because of the lock-step nature of SNMP protocol
   exchanges, this is not a service that SNMP requires.

   Architectural purists may argue that an "Application" layer entity
   (SNMP) must not perform operations that are properly the realm of the
   Transport layer (timeouts, retransmissions, and so on).  While
   architecturally pure, this line of reasoning is not relevant.  The
   network management applications and protocols are monitoring the
   "health" of the network and, as a result, have the best information
   and are in the best position to adapt their own behavior to the state
   of the network, and thereby, continuing operations in the face of
   network adversity.

7.  Which Protocol

   The final point of discussion is the actual choice of a protocol to
   support SNMP.

   If a device is destined for use in the Internet then it must operate
   SNMP over UDP/IP.

   If the device is operating in some other protocol environment, then
   SNMP ought to use the transport services that are native to that



SNMP Working Group                                              [Page 8]

RFC 1270              SNMP Communications Services          October 1991


   environment.  It may make very little sense to introduce a new
   protocol stack into a network in order to provide just one service.
   For example, it could require that the network operations staff
   understand and be able to administer and operate two protocol stacks,
   that hosts and routers understand both protocols, and so on.  It may
   also be bureaucratically impossible to introduce UDP/IP into the
   environment (the "We are only a FOONET shop - if it doesn't speak
   FOONET, we don't want it" argument).

   References [2] and [6] are experimental standards for operating SNMP
   over IPX and OSI respectively.  In these environments, those
   standards ought to be adhered to.

8.  Security Considerations

   Security issues are not discussed in this memo.

9.  Appendix

   This appendix details the TCP packet transfers required to perform a
   single SNMP operation assuming that the connection is established
   only for that operation and that a single SNMP operation (e.g., get
   request) is performed.  We also assume that all operations are
   "normal" i.e., that there are no lost packets, no simultaneous opens,
   no half opens, and no simultaneous closes.  We also ignore the
   possibility of TCP segmentation and IP fragmentation.

   The nomenclature used to illustrate the packet transactions is the
   same as that used in the TCP Specification [4].






















SNMP Working Group                                              [Page 9]

RFC 1270              SNMP Communications Services          October 1991


              Packet  Management                         Managed
              Number  Station                            Object
                               Connection Open...
               1         >--<CTL=SYN>----------------------->
               2         <--<CTL=SYN,ACK>-------------------<
               3         >--<CTL=ACK>----------------------->
                           Connection now open,
                           SNMP Request is sent.
               4         >--<DATA=SNMP Request>------------->
                           Response comes back
               5         <--<DATA=SNMP Response, CTL=ACK>---<
               6         >--<CTL=ACK>----------------------->
                           Operation is complete,
                           Management station initiates the
                           close.
               7         >--<CTL=FIN,ACK>------------------->
               8         <--<CTL=ACK>-----------------------<
               9         <--<CTL=FIN,ACK>-------------------<
              10         >--<CTL=ACK>----------------------->
                          Wait 2 MSL
                          Connection now closed.

   Some optimizations are possible IF the TCP has knowledge of the type
   of operation.  However, a general purpose TCP would not be tuned to
   SNMP operations so those optimizations would not be done.

10.  References

   [1] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
       Network Management Protocol", RFC 1157, SNMP Research,
       Performance Systems International, Performance Systems
       International, MIT Laboratory for Computer Science, May 1990.

   [2] Rose, M., Editor, "SNMP over OSI", RFC 1161, Performance Systems
       International, Inc., June 1990.

   [3] Schoffstall, M., Davin, C., Fedor, M., and J. Case, "SNMP over
       Ethernet", RFC 1089, Rensselaer Polytechnic Institute, MIT
       Laboratory for Computer Science, NYSERNet, Inc., University of
       Tennessee at Knoxville, February 1989.

   [4] Postel, J., "Transmission Control Protocol - DARPA Internet
       Program Protocol Specification", RFC 793, DARPA, September 1981.

   [5] Postel, J., "User Datagram Protocol", RFC 768, USC/Information
       Sciences Institute, August 1980.

   [6] Wormley, R., "SNMP Over IPX", draft in process, August 1990.



SNMP Working Group                                             [Page 10]

RFC 1270              SNMP Communications Services          October 1991


   [7] Postel, J., Editor, "IAB Official Protocol Standards", RFC 1250,
       IAB, August 1991.

   [8] Cerf, V., "IAB Recommendations for the Development of Internet
       Network Management Standards", RFC 1052, NRI, April 1988.

   [9] Rose M., and K. McCloghrie, "Structure and Identification of
       Management Information for TCP/IP-based internets", RFC 1155,
       Performance Systems International, Hughes LAN Systems, May 1990.

  [10] McCloghrie K., and M. Rose, "Management Information Base for
       Network Management of TCP/IP-based internets", RFC 1156, Hughes
       LAN Systems, Performance Systems International, May 1990.

11.  Acknowledgements

   The author wishes to thank Jeff Case, Chuck Davin and Keith
   McCloghrie for their technical and editorial contributions to this
   document.

12.  Author's Address

   Frank Kastenholz
   Clearpoint Research Corporation
   35 Parkwood Drive
   Hopkinton, Mass. 01748

   Phone: [phone]

   Email: [e-mail]





















SNMP Working Group                                             [Page 11]