rfc1448.txt

RFC 的详细文档！

          Case, McCloghrie, Rose & Waldbusser                  [Page 11]





          RFC 1448        Protocol Operations for SNMPv2      April 1993


          4.  Protocol Specification


          4.1.  Common Constructs

          The value of the request-id field in a Response-PDU takes the
          value of the request-id field in the request PDU to which it
          is a response.  By use of the request-id value, a SNMPv2
          application can distinguish the (potentially multiple)
          outstanding requests, and thereby correlate incoming responses
          with outstanding requests.  In cases where an unreliable
          datagram service is used, the request-id also provides a
          simple means of identifying messages duplicated by the
          network.  Use of the same request-id on a retransmission of a
          request allows the response to either the original
          transmission or the retransmission to satisfy the request.
          However, in order to calculate the round trip time for
          transmission and processing of a request-response transaction,
          the SNMPv2 application needs to use a different request-id
          value on a retransmitted request.  The latter strategy is
          recommended for use in the majority of situations.

          A non-zero value of the error-status field in a Response-PDU
          is used to indicate that an exception occurred to prevent the
          processing of the request.  In these cases, a non-zero value
          of the Response-PDU's error-index field provides additional
          information by identifying which variable binding in the list
          caused the exception.  A variable binding is identified by its
          index value.  The first variable binding in a variable-binding
          list is index one, the second is index two, etc.

          SNMPv2 limits OBJECT IDENTIFIER values to a maximum of 128
          sub-identifiers, where each sub-identifier has a maximum value
          of 2**32-1.


          4.2.  PDU Processing

          It is mandatory that all SNMPv2 entities acting in an agent
          role be able to generate the following PDU types: Response-PDU
          and SNMPv2-Trap-PDU; further, all such implementations must be
          able to receive the following PDU types: GetRequest-PDU,
          GetNextRequest-PDU, GetBulkRequest-PDU, and SetRequest-PDU.







          Case, McCloghrie, Rose & Waldbusser                  [Page 12]





          RFC 1448        Protocol Operations for SNMPv2      April 1993


          It is mandatory that all SNMPv2 entities acting in a manager
          role be able to generate the following PDU types: GetRequest-
          PDU, GetNextRequest-PDU, GetBulkRequest-PDU, SetRequest-PDU,
          InformRequest-PDU, and Response-PDU; further, all such
          implementations must be able to receive the following PDU
          types: Response-PDU, SNMPv2-Trap-PDU, InformRequest-PDU;

          In the elements of procedure below, any field of a PDU which
          is not referenced by the relevant procedure is ignored by the
          receiving SNMPv2 entity.  However, all components of a PDU,
          including those whose values are ignored by the receiving
          SNMPv2 entity, must have valid ASN.1 syntax and encoding.  For
          example, some PDUs (e.g., the GetRequest-PDU) are concerned
          only with the name of a variable and not its value.  In this
          case, the value portion of the variable binding is ignored by
          the receiving SNMPv2 entity.  The unSpecified value is defined
          for use as the value portion of such bindings.

          For all generated PDUs, the message "wrapper" to encapsulate
          the PDU is generated and transmitted as specified in [3].  The
          size of a message is limited only by constraints on the
          maximum message size, either a local limitation or the limit
          associated with the message's destination party, i.e., it is
          not limited by the number of variable bindings.

          On receiving a management communication, the procedures
          defined in Section 3.2 of [3] are followed.  If these
          procedures indicate that the PDU contained within the message
          "wrapper" is to be processed, then the SNMPv2 context
          associated with the PDU defines the object resources which are
          visible to the operation.


          4.2.1.  The GetRequest-PDU

          A GetRequest-PDU is generated and transmitted at the request
          of a SNMPv2 application.

          Upon receipt of a GetRequest-PDU, the receiving SNMPv2 entity
          processes each variable binding in the variable-binding list
          to produce a Response-PDU.  All fields of the Response-PDU
          have the same values as the corresponding fields of the
          received request except as indicated below.  Each variable
          binding is processed as follows:






          Case, McCloghrie, Rose & Waldbusser                  [Page 13]





          RFC 1448        Protocol Operations for SNMPv2      April 1993


          (1)  If the variable binding's name does not have an OBJECT
               IDENTIFIER prefix which exactly matches the OBJECT
               IDENTIFIER prefix of any variable accessible by this
               request, then its value field is set to `noSuchObject'.

          (2)  Otherwise, if the variable binding's name does not
               exactly match the name of a variable accessible by this
               request, then its value field is set to `noSuchInstance'.

          (3)  Otherwise, the variable binding's value field is set to
               the value of the named variable.

          If the processing of any variable binding fails for a reason
          other than listed above, then the Response-PDU is re-formatted
          with the same values in its request-id and variable-bindings
          fields as the received GetRequest-PDU, with the value of its
          error-status field set to `genErr', and the value of its
          error-index field is set to the index of the failed variable
          binding.

          Otherwise, the value of the Response-PDU's error-status field
          is set to `noError', and the value of its error-index field is
          zero.

          The generated Response-PDU is then encapsulated into a
          message.  If the size of the resultant message is less than or
          equal to both a local constraint and the maximum message size
          of the request's source party, it is transmitted to the
          originator of the GetRequest-PDU.

          Otherwise, an alternate Response-PDU is generated.  This
          alternate Response-PDU is formatted with the same value in its
          request-id field as the received GetRequest-PDU, with the
          value of its error-status field set to `tooBig', the value of
          its error-index field set to zero, and an empty variable-
          bindings field.  This alternate Response-PDU is then
          encapsulated into a message.  If the size of the resultant
          message is less than or equal to both a local constraint and
          the maximum message size of the request's source party, it is
          transmitted to the originator of the GetRequest-PDU.
          Otherwise, the resultant message is discarded.









          Case, McCloghrie, Rose & Waldbusser                  [Page 14]





          RFC 1448        Protocol Operations for SNMPv2      April 1993


          4.2.2.  The GetNextRequest-PDU

          A GetNextRequest-PDU is generated and transmitted at the
          request of a SNMPv2 application.

          Upon receipt of a GetNextRequest-PDU, the receiving SNMPv2
          entity processes each variable binding in the variable-binding
          list to produce a Response-PDU.  All fields of the Response-
          PDU have the same values as the corresponding fields of the
          received request except as indicated below.  Each variable
          binding is processed as follows:

          (1)  The variable is located which is in the lexicographically
               ordered list of the names of all variables which are
               accessible by this request and whose name is the first
               lexicographic successor of the variable binding's name in
               the incoming GetNextRequest-PDU.  The corresponding
               variable binding's name and value fields in the
               Response-PDU are set to the name and value of the located
               variable.

          (2)  If the requested variable binding's name does not
               lexicographically precede the name of any variable
               accessible by this request, i.e., there is no
               lexicographic successor, then the corresponding variable
               binding produced in the Response-PDU has its value field
               set to 'endOfMibView', and its name field set to the
               variable binding's name in the request.

          If the processing of any variable binding fails for a reason
          other than listed above, then the Response-PDU is re-formatted
          with the same values in its request-id and variable-bindings
          fields as the received GetNextRequest-PDU, with the value of
          its error-status field set to `genErr', and the value of its
          error-index field is set to the index of the failed variable
          binding.

          Otherwise, the value of the Response-PDU's error-status field
          is set to `noError', and the value of its error-index field is
          zero.

          The generated Response-PDU is then encapsulated into a
          message.  If the size of the resultant message is less than or
          equal to both a local constraint and the maximum message size
          of the request's source party, it is transmitted to the





          Case, McCloghrie, Rose & Waldbusser                  [Page 15]





          RFC 1448        Protocol Operations for SNMPv2      April 1993


          originator of the GetNextRequest-PDU.

          Otherwise, an alternate Response-PDU is generated.  This
          alternate Response-PDU is formatted with the same values in
          its request-id field as the received GetNextRequest-PDU, with
          the value of its error-status field set to `tooBig', the value
          of its error-index field set to zero, and an empty variable-
          bindings field.  This alternate Response-PDU is then
          encapsulated into a message.  If the size of the resultant
          message is less than or equal to both a local constraint and
          the maximum message size of the request's source party, it is
          transmitted to the originator of the GetNextRequest-PDU.
          Otherwise, the resultant message is discarded.


          4.2.2.1.  Example of Table Traversal

          An important use of the GetNextRequest-PDU is the traversal of
          conceptual tables of information within a MIB.  The semantics
          of this type of request, together with the method of
          identifying individual instances of objects in the MIB,
          provides access to related objects in the MIB as if they
          enjoyed a tabular organization.

          In the protocol exchange sketched below, a SNMPv2 application
          retrieves the media-dependent physical address and the
          address-mapping type for each entry in the IP net-to-media
          Address Translation Table [9] of a particular network element.
          It also retrieves the value of sysUpTime [9], at which the
          mappings existed.  Suppose that the agent's IP net-to-media
          table has three entries:

            Interface-Number  Network-Address  Physical-Address  Type

                   1            10.0.0.51     00:00:10:01:23:45  static
                   1             9.2.3.4      00:00:10:54:32:10  dynamic
                   2            10.0.0.15     00:00:10:98:76:54  dynamic

          The SNMPv2 entity acting in a manager role begins by sending a
          GetNextRequest-PDU containing the indicated OBJECT IDENTIFIER
          values as the requested variable names:

              GetNextRequest ( sysUpTime,
                               ipNetToMediaPhysAddress,
                               ipNetToMediaType )





          Case, McCloghrie, Rose & Waldbusser                  [Page 16]





          RFC 1448        Protocol Operations for SNMPv2      April 1993


          The SNMPv2 entity acting in an agent role responds with a
          Response-PDU:

              Response (( sysUpTime.0 =  "123456" ),
                        ( ipNetToMediaPhysAddress.1.9.2.3.4 =
                                                   "000010543210" ),
                        ( ipNetToMediaType.1.9.2.3.4 =  "dynamic" ))

          The SNMPv2 entity acting in a manager role continues with:

              GetNextRequest ( sysUpTime,
                               ipNetToMediaPhysAddress.1.9.2.3.4,
                               ipNetToMediaType.1.9.2.3.4 )

          The SNMPv2 entity acting in an agent role responds with:

              Response (( sysUpTime.0 =  "123461" ),
                        ( ipNetToMediaPhysAddress.1.10.0.0.51 =
                                                    "000010012345" ),
                        ( ipNetToMediaType.1.10.0.0.51 =  "static" ))

          The SNMPv2 entity acting in a manager role continues with:

              GetNextRequest ( sysUpTime,
                               ipNetToMediaPhysAddress.1.10.0.0.51,
                               ipNetToMediaType.1.10.0.0.51 )

          The SNMPv2 entity acting in an agent role responds with:

              Response (( sysUpTime.0 =  "123466" ),
                        ( ipNetToMediaPhysAddress.2.10.0.0.15 =
                                                     "000010987654" ),
                        ( ipNetToMediaType.2.10.0.0.15 =  "dynamic" ))

          The SNMPv2 entity acting in a manager role continues with:

              GetNextRequest ( sysUpTime,
                               ipNetToMediaPhysAddress.2.10.0.0.15,
                               ipNetToMediaType.2.10.0.0.15 )

          As there are no further entries in the table, the SNMPv2
          entity acting in an agent role responds with the variables
          that are next in the lexicographical ordering of the
          accessible object names, for example: