rfc1157.txt

RFC 的详细文档！

3.2.6.3.  Identification of Object Instances

   The names for all object types in the MIB are defined explicitly
   either in the Internet-standard MIB or in other documents which
   conform to the naming conventions of the SMI.  The SMI requires that
   conformant management protocols define mechanisms for identifying
   individual instances of those object types for a particular network
   element.

   Each instance of any object type defined in the MIB is identified in
   SNMP operations by a unique name called its "variable name." In
   general, the name of an SNMP variable is an OBJECT IDENTIFIER of the
   form x.y, where x is the name of a non-aggregate object type defined
   in the MIB and y is an OBJECT IDENTIFIER fragment that, in a way



Case, Fedor, Schoffstall, & Davin                              [Page 12]

RFC 1157                          SNMP                          May 1990


   specific to the named object type, identifies the desired instance.

   This naming strategy admits the fullest exploitation of the semantics
   of the GetNextRequest-PDU (see Section 4), because it assigns names
   for related variables so as to be contiguous in the lexicographical
   ordering of all variable names known in the MIB.

   The type-specific naming of object instances is defined below for a
   number of classes of object types.  Instances of an object type to
   which none of the following naming conventions are applicable are
   named by OBJECT IDENTIFIERs of the form x.0, where x is the name of
   said object type in the MIB definition.

   For example, suppose one wanted to identify an instance of the
   variable sysDescr The object class for sysDescr is:

             iso org dod internet mgmt mib system sysDescr
              1   3   6     1      2    1    1       1

   Hence, the object type, x, would be 1.3.6.1.2.1.1.1 to which is
   appended an instance sub-identifier of 0.  That is, 1.3.6.1.2.1.1.1.0
   identifies the one and only instance of sysDescr.

3.2.6.3.1.  ifTable Object Type Names

   The name of a subnet interface, s, is the OBJECT IDENTIFIER value of
   the form i, where i has the value of that instance of the ifIndex
   object type associated with s.

   For each object type, t, for which the defined name, n, has a prefix
   of ifEntry, an instance, i, of t is named by an OBJECT IDENTIFIER of
   the form n.s, where s is the name of the subnet interface about which
   i represents information.

   For example, suppose one wanted to identify the instance of the
   variable ifType associated with interface 2.  Accordingly, ifType.2
   would identify the desired instance.

3.2.6.3.2.  atTable Object Type Names

   The name of an AT-cached network address, x, is an OBJECT IDENTIFIER
   of the form 1.a.b.c.d, where a.b.c.d is the value (in the familiar
   "dot" notation) of the atNetAddress object type associated with x.

   The name of an address translation equivalence e is an OBJECT
   IDENTIFIER value of the form s.w, such that s is the value of that
   instance of the atIndex object type associated with e and such that w
   is the name of the AT-cached network address associated with e.



Case, Fedor, Schoffstall, & Davin                              [Page 13]

RFC 1157                          SNMP                          May 1990


   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 14]

RFC 1157                          SNMP                          May 1990


   "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 15]

RFC 1157                          SNMP                          May 1990


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.

    RFC1157-SNMP DEFINITIONS ::= BEGIN

     IMPORTS
          ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
                  FROM RFC1155-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 16]

RFC 1157                          SNMP                          May 1990


     -- 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 17]

RFC 1157                          SNMP                          May 1990


             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