rfc1905.txt

radius服务器


RFC 1905             Protocol Operations for SNMPv2         January 1996


   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:

    Response (( sysUpTime.0 =  "123471" ),
              ( ipNetToMediaNetAddress.1.9.2.3.4 =
                                               "9.2.3.4" ),
              ( ipRoutingDiscards.0 =  "2" ))

   This response signals the end of the table to the SNMPv2 entity
   acting in a manager role.







SNMPv2 Working Group        Standards Track                    [Page 13]

RFC 1905             Protocol Operations for SNMPv2         January 1996


4.2.3.  The GetBulkRequest-PDU

   A GetBulkRequest-PDU is generated and transmitted at the request of a
   SNMPv2 application.  The purpose of the GetBulkRequest-PDU is to
   request the transfer of a potentially large amount of data,
   including, but not limited to, the efficient and rapid retrieval of
   large tables.

   Upon receipt of a GetBulkRequest-PDU, the receiving SNMPv2 entity
   processes each variable binding in the variable-binding list to
   produce a Response-PDU with its request-id field having the same
   value as in the request.  Processing begins by examining the values
   in the non-repeaters and max-repetitions fields.  If the value in the
   non-repeaters field is less than zero, then the value of the field is
   set to zero.  Similarly, if the value in the max-repetitions field is
   less than zero, then the value of the field is set to zero.

   For the GetBulkRequest-PDU type, the successful processing of each
   variable binding in the request generates zero or more variable
   bindings in the Response-PDU.  That is, the one-to-one mapping
   between the variable bindings of the GetRequest-PDU, GetNextRequest-
   PDU, and SetRequest-PDU types and the resultant Response-PDUs does
   not apply for the mapping between the variable bindings of a
   GetBulkRequest-PDU and the resultant Response-PDU.

   The values of the non-repeaters and max-repetitions fields in the
   request specify the processing requested.  One variable binding in
   the Response-PDU is requested for the first N variable bindings in
   the request and M variable bindings are requested for each of the R
   remaining variable bindings in the request.  Consequently, the total
   number of requested variable bindings communicated by the request is
   given by N + (M * R), where N is the minimum of:  a) the value of the
   non-repeaters field in the request, and b) the number of variable
   bindings in the request; M is the value of the max-repetitions field
   in the request; and R is the maximum of:  a) number of variable
   bindings in the request - N, and b)  zero.

   The receiving SNMPv2 entity produces a Response-PDU with up to the
   total number of requested variable bindings communicated by the
   request.  The request-id shall have the same value as the received
   GetBulkRequest-PDU.

   If N is greater than zero, the first through the (N)-th variable
   bindings of the Response-PDU are each produced 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



SNMPv2 Working Group        Standards Track                    [Page 14]

RFC 1905             Protocol Operations for SNMPv2         January 1996


     variable binding's name in the incoming GetBulkRequest-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 M and R are non-zero, the (N + 1)-th and subsequent variable
   bindings of the Response-PDU are each produced in a similar manner.
   For each iteration i, such that i is greater than zero and less than
   or equal to M, and for each repeated variable, r, such that r is
   greater than zero and less than or equal to R, the (N + ( (i-1) * R )
   + r)-th variable binding of the Response-PDU is produced as follows:

(1)  The variable which is in the lexicographically ordered list of the
     names of all variables which are accessible by this request and
     whose name is the (i)-th lexicographic successor of the (N + r)-th
     variable binding's name in the incoming GetBulkRequest-PDU is
     located and the variable binding's name and value fields are set to
     the name and value of the located variable.

(2)  If there is no (i)-th 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 either
     the last lexicographic successor, or if there are no lexicographic
     successors, to the (N + r)-th variable binding's name in the
     request.

   While the maximum number of variable bindings in the Response-PDU is
   bounded by N + (M * R), the response may be generated with a lesser
   number of variable bindings (possibly zero) for either of three
   reasons.

(1)  If the size of the message encapsulating the Response-PDU
     containing the requested number of variable bindings would be
     greater than either a local constraint or the maximum message size
     of the originator, then the response is generated with a lesser
     number of variable bindings.  This lesser number is the ordered set
     of variable bindings with some of the variable bindings at the end
     of the set removed, such that the size of the message encapsulating
     the Response-PDU is approximately equal to but no greater than
     either a local constraint or the maximum message size of the
     originator.  Note that the number of variable bindings removed has
     no relationship to the values of N, M, or R.



SNMPv2 Working Group        Standards Track                    [Page 15]

RFC 1905             Protocol Operations for SNMPv2         January 1996


(2)  The response may also be generated with a lesser number of variable
     bindings if for some value of iteration i, such that i is greater
     than zero and less than or equal to M, that all of the generated
     variable bindings have the value field set to the `endOfMibView'.
     In this case, the variable bindings may be truncated after the (N +
     (i * R))-th variable binding.

(3)  In the event that the processing of a request with many repetitions
     requires a significantly greater amount of processing time than a
     normal request, then an agent may terminate the request with less
     than the full number of repetitions, providing at least one
     repetition is completed.

   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 GetBulkRequest-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 variable binding in the original request which
   corresponds to 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 to zero.

   The generated Response-PDU (possibly with an empty variable-bindings
   field) 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 originator, it is transmitted to
   the originator of the GetBulkRequest-PDU.  Otherwise, the
   snmpSilentDrops [9] counter is incremented and the resultant message
   is discarded.

4.2.3.1.  Another Example of Table Traversal

   This example demonstrates how the GetBulkRequest-PDU can be used as
   an alternative to the GetNextRequest-PDU.  The same traversal of the
   IP net-to-media table as shown in Section 4.2.2.1 is achieved with
   fewer exchanges.

   The SNMPv2 entity acting in a manager role begins by sending a
   GetBulkRequest-PDU with the modest max-repetitions value of 2, and
   containing the indicated OBJECT IDENTIFIER values as the requested
   variable names:

    GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ]
                    ( sysUpTime,
                      ipNetToMediaPhysAddress,
                      ipNetToMediaType )



SNMPv2 Working Group        Standards Track                    [Page 16]

RFC 1905             Protocol Operations for SNMPv2         January 1996


   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" ),
              ( ipNetToMediaPhysAddress.1.10.0.0.51 =
                                          "000010012345" ),
              ( ipNetToMediaType.1.10.0.0.51 =  "static" ))

   The SNMPv2 entity acting in a manager role continues with:

       GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ]
                       ( 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" ),
              ( ipNetToMediaNetAddress.1.9.2.3.4 =
                                              "9.2.3.4" ),
              ( ipRoutingDiscards.0 =  "2" ))

   This response signals the end of the table to the SNMPv2 entity
   acting in a manager role.

4.2.4.  The Response-PDU

   The Response-PDU is generated by a SNMPv2 entity only upon receipt of
   a GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU,
   SetRequest-PDU, or InformRequest-PDU, as described elsewhere in this
   document.

   If the error-status field of the Response-PDU is non-zero, the value
   fields of the variable bindings in the variable binding list are
   ignored.

   If both the error-status field and the error-index field of the
   Response-PDU are non-zero, then the value of the error-index field is
   the index of the variable binding (in the variable-binding list of
   the corresponding request) for which the request failed.  The first
   variable binding in a request's variable-binding list is index one,
   the second is index two, etc.



SNMPv2 Working Group        Standards Track                    [Page 17]

RFC 1905             Protocol Operations for SNMPv2         January 1996


   A compliant SNMPv2 entity acting in a manager role must be able to
   properly receive and handle a Response-PDU with an error-status field
   equal to `noSuchName', `badValue', or `readOnly'.  (See Section 3.1.2
   of [8].)

   Upon receipt of a Response-PDU, the receiving SNMPv2 entity presents
   its contents to the SNMPv2 application which generated the request
   with the same request-id value.

4.2.5.  The SetRequest-PDU

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

   Upon receipt of a SetRequest-PDU, the receiving SNMPv2 entity
   determines the size of a message encapsulating a Response-PDU having
   the same values in its request-id and variable-bindings fields as the
   received SetRequest-PDU, and the largest possible sizes of the
   error-status and error-index fields.  If the determined message size
   is greater than either a local constraint or the maximum message size
   of the originator, then an alternate Response-PDU is generated,
   transmitted to the originator of the SetRequest-PDU, and processing
   of the SetRequest-PDU terminates immediately thereafter.  This
   alternate Response-PDU is formatted with the same values in its
   request-id field as the received SetRequest-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 originator, it is
   transmitted to the originator of the SetRequest-PDU.  Otherwise, the
   snmpSilentDrops [9] counter is incremented and the resultant message
   is discarded.  Regardless, processing of the SetRequest-PDU
   terminates.

   Otherwise, 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.

   The variable bindings are conceptually processed as a two phase
   operation.  In the first phase, each variable binding is validated;
   if all validations are successful, then each variable is altered in
   the second phase.  Of course, implementors are at liberty to
   implement either the first, or second, or both, of these conceptual
   phases as multiple implementation phases.  Indeed, such multiple
   implementation phases may be necessary in some cases to ensure
   consistency.



SNMPv2 Working Group        Standards Track                    [Page 18]