rfc2089.txt

开发snmp的开发包有两个开放的SNMP开发库


RFC 2089                         V2toV1                     January 1997


     3.  If there are no such varBinds, then:

         a.  Set the error-status to noError

         b.  Set the error-index to zero

         c.  Compose the varBindList of the response, using the data as
             it is returned by the instrumentation code.

3.2  Processing an SNMPv1 GETNEXT request

   First, the request is converted into a call to the underlying
   instrumentation. This is implementation specific.  There may be
   repetitive calls to (possibly different pieces of) instrumentation
   code to try to find the first object which lexicographically follows
   each of the objects in the request.  Again, this is implementation
   specific.

   When the instrumentation finally returns response data using SNMPv2
   syntax and error-status values, then:

     1.  If the error-status is anything other than noError,

         a.  The error status is translated to an SNMPv1 error-status
             using the table from 2.1, "Mapping SNMPv2 error-status into
             SNMPv1 error-status" on page 2

         b.  The error-index is set to the position (in the original
             request) of the varBind that caused the error-status.

         c.  The varBindList of the response PDU is made exactly the
             same as the varBindList that was received in the original
             request.

     2.  If the error-status is noError, then:

         a.  If there are any varBinds containing an SNMPv2 syntax of
             Counter64, then consider these varBinds to be not in view
             and repeat the call to the instrumentation code as often as
             needed till a value other than Counter64 is returned.

         b.  Find any varBind that contains an SNMPv2 exception
             endOfMibView.  (Note that if there are more than one, the
             agent may choose any such varBind.)  If there are any such
             varBinds, then for the one chosen:

             1)  Set the error-status to noSuchName




Wijnen & Levi                Informational                      [Page 7]

RFC 2089                         V2toV1                     January 1997


             2)  Set the error-index to the position (in the varBindList
                 of the original request) of the varBind that returned
                 such an SNMPv2 exception.

             3)  Make the varBindList of the response PDU exactly the
                 same as the varBindList that was received in the
                 original request.

         c.  If there are no such varBinds, then:

             1)  Set the error-status to noError

             2)  Set the error-index to zero

             3)  Compose the varBindList of the response, using the data
                 as it is returned by the instrumentation code.

3.3  Processing an outgoing SNMPv2 TRAP

   If SNMPv2 compliant instrumentation presents an SNMPv2 trap to the
   SNMP engine and such a trap passes all regular checking and then is
   to be sent to an SNMPv1 destination, then the following steps must be
   followed to convert such a trap to an SNMPv1 trap.  This is basically
   the reverse of the SNMPv1 to SNMPv2 mapping as described in RFC1908
   [3].

     1.  If any of the varBinds in the varBindList has an SNMPv2 syntax
         of Counter64, then such varBinds are implicitly considered to
         be not in view, and so they are removed from the varBindList to
         be sent with the SNMPv1 trap.

     2.  The 3 special varBinds in the varBindList of an SNMPv2 trap
         (sysUpTime.0 (TimeTicks), snmpTrapOID.0 (OBJECT IDENTIFIER) and
         optionally snmpTrapEnterprise.0 (OBJECT IDENTIFIER)) are
         removed from the varBindList to be sent with the SNMPv1 trap.
         These 2 (or 3) varBinds are used to decide how to set other
         fields in the SNMPv1 trap PDU as follows:

         a.  The value of sysUpTime.0 is copied into the timestamp field
             of the SNMPv1 trap.











Wijnen & Levi                Informational                      [Page 8]

RFC 2089                         V2toV1                     January 1997


         b.  If the snmpTrapOID.0 value is one of the standard traps the
             specific-trap field is set to zero and the generic trap
             field is set according to this mapping:

                value of snmpTrapOID.0                generic-trap
                ===============================       ============
                1.3.6.1.6.3.1.1.5.1 (coldStart)                  0
                1.3.6.1.6.3.1.1.5.2 (warmStart)                  1
                1.3.6.1.6.3.1.1.5.3 (linkDown)                   2
                1.3.6.1.6.3.1.1.5.4 (linkUp)                     3
                1.3.6.1.6.3.1.1.5.5 (authenticationFailure)      4
                1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss)            5

             The enterprise field is set to the value of
             snmpTrapEnterprise.0 if this varBind is present, otherwise
             it is set to the value snmpTraps as defined in RFC1907 [4].

         c.  If the snmpTrapOID.0 value is not one of the standard
             traps, then the generic-trap field is set to 6 and the
             specific-trap field is set to the last subid of the
             snmpTrapOID.0 value.

             o   If the next to last subid of snmpTrapOID.0 is zero,
                 then the enterprise field is set to snmpTrapOID.0 value
                 and the last 2 subids are truncated from that value.
             o   If the next to last subid of snmpTrapOID.0 is not zero,
                 then the enterprise field is set to snmpTrapOID.0 value
                 and the last 1 subid is truncated from that value.

             In any event, the snmpTrapEnterprise.0 varBind (if present)
             is ignored in this case.

     3.  The agent-addr field is set with the appropriate address of the
         the sending SNMP entity, which is the IP address of the sending
         entity of the trap goes out over UDP; otherwise the agent-addr
         field is set to address 0.0.0.0.















Wijnen & Levi                Informational                      [Page 9]

RFC 2089                         V2toV1                     January 1997


4.0  Acknowledgements

   The authors wish to thank the contributions of the SNMPv2 Working
   Group in general.  Special thanks for their detailed review and
   comments goes to these individuals:

       Mike Daniele (DEC)
       Dave Harrington (Cabletron)
       Brian O'Keefe (Hewlett Packard)
       Keith McCloghrie (Cisco Systems)
       Dave Perkins (independent)
       Shawn Routhier (Epilogue)
       Juergen Schoenwaelder (University of Twente)

5.0  References

     [1]  Jeffrey  D. Case, Mark Fedor, Martin Lee Schoffstall and James
          R. Davin, Simple  Network  Management  Protocol  (SNMP),  SNMP
          Research,  Performance  Systems  International, MIT Laboratory
          for Computer Science, RFC 1157, May 1990.

     [2]  Jeffrey D. Case, Keith McCloghrie, Marshall T. Rose and Steven
          Waldbusser, Structure of Managment Information for  Version  2
          of  the  Simple  Network  Management  Protocol  (SNMPv2), SNMP
          Research Inc, Cisco Systems Inc, Dover Beach  Consulting  Inc,
          International Network Services, RFC1902, January 1996.

     [3]  Jeffrey D. Case, Keith McCloghrie, Marshall T. Rose and Steven
          Waldbusser, Coexistence between Version 1 and Version 2 of the
          Internet-standard  Network Management Framework, SNMP Research
          Inc,  Cisco  Systems  Inc,   Dover   Beach   Consulting   Inc,
          International Network Services, RFC1908, January 1996.

     [4]  Jeffrey D. Case, Keith McCloghrie, Marshall T. Rose and Steven
          Waldbusser,  Management  Information Base for Version 2 of the
          Simple Network Management  Protocol  (SNMPv2),  SNMP  Research
          Inc,   Cisco   Systems   Inc,   Dover  Beach  Consulting  Inc,
          International Network Services, RFC1907, January 1996.

6.0  Security Considerations

   Security considerations are not discussed in this memo.









Wijnen & Levi                Informational                     [Page 10]

RFC 2089                         V2toV1                     January 1997


7.0  Authors' Addresses

          Bert Wijnen
          IBM International Operations
          Watsonweg 2
          1423 ND Uithoorn
          The Netherlands

          Phone: [phone]
          E-mail: [e-mail]


          David Levi
          SNMP Research, Inc
          3001 Kimberlin Heights Rd.
          Knoxville, TN 37920-9716
          USA

          Phone: [phone]
          E-mail: [e-mail]































Wijnen & Levi                Informational                     [Page 11]

RFC 2089                         V2toV1                     January 1997


APPENDIX A.  Background Information

   Here follows some reasoning as to why some choices were made.

   A.1  Mapping of error-status values

   The mapping of SNMPv2 error-status values to SNMPv1 error-status
   values is based on the common interpretation of how an SNMPv1 entity
   should create an error-status value based on the elements of
   procedure defined in RFC1157 [1].

   There was a suggestion to map wrongEncoding into genErr, because it
   could be caused by an ASN.1 parsing error.  Such maybe true, but in
   most cases when we detect the ASN.1 parsing error, we do not yet know
   about the PDU data yet.  Most people who responded to our queries
   have implemented the mapping to a badValue. So we "agreed" on the
   mapping to badValue.


   A.2  SNMPv1 Traps without Counter64 varBinds.

   RFC1448 says that if one of the objects in the varBindList is not
   included in the view, then the trap is NOT sent.  Current SNMPv2u and
   SNMPv2* documents make the same statement.  However, the "rough
   consensus" is that it is better to send partial information than no
   information at all. Besides:

     o   RFC1448 does not allow for a TRAP to be sent with the varBinds
         that are not included in the view removed, so it is an all or
         nothing decision.

     o   We do NOT include the Counter64 varBinds... so the "not in
         view" varBinds are not sent to the trap destination.

     o   The Counter64 objects are "implicit" not in view.  If any
         objects are explicit not in view, then this is checked before
         we do the conversion from an SNMPv2 trap to an SNMPv1 trap, and
         so the trap is not sent at all.













Wijnen & Levi                Informational                     [Page 12]