rfc1098.txt

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


RFC 1098                          SNMP                        April 1989


   For each object type, t, for which the defined name, n, has a prefix
   of atEntry, an instance, i, of t is named by an OBJECT IDENTIFIER of
   the form n.y, where y is the name of the address translation
   equivalence about which i represents information.

   For example, suppose one wanted to find the physical address of an
   entry in the address translation table (ARP cache) associated with an
   IP address of 89.1.1.42 and interface 3.  Accordingly,
   atPhysAddress.3.1.89.1.1.42 would identify the desired instance.

3.2.6.3.3.  ipAddrTable Object Type Names

   The name of an IP-addressable network element, x, is the OBJECT
   IDENTIFIER of the form a.b.c.d such that a.b.c.d is the value (in the
   familiar "dot" notation) of that instance of the ipAdEntAddr object
   type associated with x.

   For each object type, t, for which the defined name, n, has a prefix
   of ipAddrEntry, an instance, i, of t is named by an OBJECT IDENTIFIER
   of the form n.y, where y is the name of the IP-addressable network
   element about which i represents information.

   For example, suppose one wanted to find the network mask of an entry
   in the IP interface table associated with an IP address of 89.1.1.42.
   Accordingly, ipAdEntNetMask.89.1.1.42 would identify the desired
   instance.

3.2.6.3.4.  ipRoutingTable Object Type Names

   The name of an IP route, x, is the OBJECT IDENTIFIER of the form
   a.b.c.d such that a.b.c.d is the value (in the familiar "dot"
   notation) of that instance of the ipRouteDest object type associated
   with x.

   For each object type, t, for which the defined name, n, has a prefix
   of ipRoutingEntry, an instance, i, of t is named by an OBJECT
   IDENTIFIER of the form n.y, where y is the name of the IP route about
   which i represents information.

   For example, suppose one wanted to find the next hop of an entry in
   the IP routing table associated  with the destination of 89.1.1.42.
   Accordingly, ipRouteNextHop.89.1.1.42 would identify the desired
   instance.

3.2.6.3.5.  tcpConnTable Object Type Names

   The name of a TCP connection, x, is the OBJECT IDENTIFIER of the form
   a.b.c.d.e.f.g.h.i.j such that a.b.c.d is the value (in the familiar



Case, Fedor, Schoffstall, & Davin                              [Page 13]

RFC 1098                          SNMP                        April 1989


   "dot" notation) of that instance of the tcpConnLocalAddress object
   type associated with x and such that f.g.h.i is the value (in the
   familiar "dot" notation) of that instance of the tcpConnRemoteAddress
   object type associated with x and such that e is the value of that
   instance of the tcpConnLocalPort object type associated with x and
   such that j is the value of that instance of the tcpConnRemotePort
   object type associated with x.

   For each object type, t, for which the defined name, n, has a prefix
   of  tcpConnEntry, an instance, i, of t is named by an OBJECT
   IDENTIFIER of the form n.y, where y is the name of the TCP connection
   about which i represents information.

   For example, suppose one wanted to find the state of a TCP connection
   between the local address of 89.1.1.42 on TCP port 21 and the remote
   address of 10.0.0.51 on TCP port 2059.  Accordingly,
   tcpConnState.89.1.1.42.21.10.0.0.51.2059 would identify the desired
   instance.

3.2.6.3.6.  egpNeighTable Object Type Names

   The name of an EGP neighbor, x, is the OBJECT IDENTIFIER of the form
   a.b.c.d such that a.b.c.d is the value (in the familiar "dot"
   notation) of that instance of the egpNeighAddr object type associated
   with x.

   For each object type, t, for which the defined name, n, has a prefix
   of egpNeighEntry, an instance, i, of t is named by an OBJECT
   IDENTIFIER of the form n.y, where y is the name of the EGP neighbor
   about which i represents information.

   For example, suppose one wanted to find the neighbor state for the IP
   address of 89.1.1.42.  Accordingly, egpNeighState.89.1.1.42 would
   identify the desired instance.

















Case, Fedor, Schoffstall, & Davin                              [Page 14]

RFC 1098                          SNMP                        April 1989


4.  Protocol Specification

   The network management protocol is an application protocol by which
   the variables of an agent's MIB may be inspected or altered.

   Communication among protocol entities is accomplished by the exchange
   of messages, each of which is entirely and independently represented
   within a single UDP datagram using the basic encoding rules of ASN.1
   (as discussed in Section 3.2.2).  A message consists of a version
   identifier, an SNMP community name, and a protocol data unit (PDU).
   A protocol entity receives messages at UDP port 161 on the host with
   which it is associated for all messages except for those which report
   traps (i.e., all messages except those which contain the Trap-PDU).
   Messages which report traps should be received on UDP port 162 for
   further processing.  An implementation of this protocol need not
   accept messages whose length exceeds 484 octets.  However, it is
   recommended that implementations support larger datagrams whenever
   feasible.

   It is mandatory that all implementations of the SNMP support the five
   PDUs: GetRequest-PDU, GetNextRequest-PDU, GetResponse-PDU,
   SetRequest-PDU, and Trap-PDU.

    RFC1098-SNMP DEFINITIONS ::= BEGIN

     IMPORTS
          ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
                  FROM RFC1065-SMI;


     -- top-level message

             Message ::=
                     SEQUENCE {
                          version        -- version-1 for this RFC
                             INTEGER {
                                 version-1(0)
                             },

                         community      -- community name
                             OCTET STRING,

                         data           -- e.g., PDUs if trivial
                             ANY        -- authentication is being used
                     }






Case, Fedor, Schoffstall, & Davin                              [Page 15]

RFC 1098                          SNMP                        April 1989


     -- protocol data units

             PDUs ::=
                     CHOICE {
                         get-request
                             GetRequest-PDU,

                         get-next-request
                             GetNextRequest-PDU,

                         get-response
                             GetResponse-PDU,

                         set-request
                             SetRequest-PDU,

                         trap
                             Trap-PDU
                          }

     -- the individual PDUs and commonly used
     -- data types will be defined later

     END


4.1.  Elements of Procedure

   This section describes the actions of a protocol entity implementing
   the SNMP. Note, however, that it is not intended to constrain the
   internal architecture of any conformant implementation.

   In the text that follows, the term transport address is used.  In the
   case of the UDP, a transport address consists of an IP address along
   with a UDP port.  Other transport services may be used to support the
   SNMP.  In these cases, the definition of a transport address should
   be made accordingly.

   The top-level actions of a protocol entity which generates a message
   are as follows:

        (1)  It first constructs the appropriate PDU, e.g., the
             GetRequest-PDU, as an ASN.1 object.

        (2)  It then passes this ASN.1 object along with a community
             name its source transport address and the destination
             transport address, to the service which implements the
             desired authentication scheme.  This authentication



Case, Fedor, Schoffstall, & Davin                              [Page 16]

RFC 1098                          SNMP                        April 1989


             service returns another ASN.1 object.

        (3)  The protocol entity then constructs an ASN.1 Message
             object, using the community name and the resulting ASN.1
             object.

        (4)  This new ASN.1 object is then serialized, using the basic
             encoding rules of ASN.1, and then sent using a transport
             service to the peer protocol entity.

   Similarly, the top-level actions of a protocol entity which receives
   a message are as follows:

        (1)  It performs a rudimentary parse of the incoming datagram
             to build an ASN.1 object corresponding to an ASN.1
             Message object. If the parse fails, it discards the
             datagram and performs no further actions.

        (2)  It then verifies the version number of the SNMP message.
             If there is a mismatch, it discards the datagram and
             performs no further actions.

        (3)  The protocol entity then passes the community name and
             user data found in the ASN.1 Message object, along with
             the datagram's source and destination transport addresses
             to the service which implements the desired
             authentication scheme.  This entity returns another ASN.1
             object, or signals an authentication failure.  In the
             latter case, the protocol entity notes this failure,
             (possibly) generates a trap, and discards the datagram
             and performs no further actions.

        (4)  The protocol entity then performs a rudimentary parse on
             the ASN.1 object returned from the authentication service
             to build an ASN.1 object corresponding to an ASN.1 PDUs
             object.  If the parse fails, it discards the datagram and
             performs no further actions.  Otherwise, using the named
             SNMP community, the appropriate profile is selected, and
             the PDU is processed accordingly.  If, as a result of
             this processing, a message is returned then the source
             transport address that the response message is sent from
             shall be identical to the destination transport address
             that the original request message was sent to.








Case, Fedor, Schoffstall, & Davin                              [Page 17]

RFC 1098                          SNMP                        April 1989


4.1.1.  Common Constructs

   Before introducing the six PDU types of the protocol, it is
   appropriate to consider some of the ASN.1 constructs used frequently:

                  -- request/response information

                  RequestID ::=
                          INTEGER

                  ErrorStatus ::=
                          INTEGER {
                              noError(0),
                              tooBig(1),
                              noSuchName(2),
                              badValue(3),
                              readOnly(4)
                              genErr(5)
                          }

                  ErrorIndex ::=
                          INTEGER


                  -- variable bindings

                  VarBind ::=
                          SEQUENCE {
                              name
                                  ObjectName,

                              value
                                  ObjectSyntax
                          }

                  VarBindList ::=
                          SEQUENCE OF
                              VarBind


   RequestIDs are used to distinguish among outstanding requests.  By
   use of the RequestID, an SNMP application entity can correlate
   incoming responses with outstanding requests.  In cases where an
   unreliable datagram service is being used, the RequestID also
   provides a simple means of identifying messages duplicated by the
   network.

   A non-zero instance of ErrorStatus is used to indicate that an



Case, Fedor, Schoffstall, & Davin                              [Page 18]