rfc1908.txt

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


RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996


2.4.  Capabilities Statements

   In the current framework, the informational document [11] uses the
   MODULE-CONFORMANCE macro to describe an agent's capabilities with
   respect to one or more MIB modules.  Converting such a description
   for use with the SNMPv2 framework requires these changes:

   (1)  Use the macro name AGENT-CAPABILITIES instead of MODULE-
        CONFORMANCE.

   (2)  The STATUS clause must be added.

   (3)  For all occurrences of the CREATION-REQUIRES clause, note the
        slight change in semantics, and omit this clause if appropriate.

   In order to ease the coexistence between SNMPv1 and SNMPv2, object
   groups defined in an SNMPv1 MIB module may be referenced by the
   INCLUDES clause of an invocation of the AGENT-CAPABILITIES macro:
   upon encountering a reference to an OBJECT IDENTIFIER subtree defined
   in an SNMPv1 MIB module, all leaf objects which are subordinate to
   the subtree and have a STATUS clause value of mandatory are deemed to
   be INCLUDEd.  (Note that this method is ambiguous when different
   revisions of a SNMPv1 MIB have different sets of mandatory objects
   under the same subtree; in such cases, the only solution is to
   rewrite the MIB using the SNMPv2 SMI in order to define the object
   groups unambiguously.)

3.  Protocol Operations

   The SNMPv2 documents which deal with protocol operations are:

     Protocol Operations for SNMPv2 [4], which defines the syntax and
     semantics of the operations conveyed by the protocol; and,

     Transport Mappings for SNMPv2 [5], which defines how the protocol
     operations are carried over different transport services.

   The following section considers two areas:  the proxy behavior
   between a SNMPv2 entity and a SNMPv1 agent; and, the behavior of
   "bi-lingual" protocol entities acting in a manager role.

3.1.  Proxy Agent Behavior

   To achieve coexistence at the protocol-level, a proxy mechanism may
   be used.  A SNMPv2 entity acting in an agent role may be implemented
   and configured to act in the role of a proxy agent.





SNMPv2 Working Group        Standards Track                     [Page 6]

RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996


3.1.1.  SNMPv2 -> SNMPv1

   When converting requests from a SNMPv2 entity acting in a manager
   role into requests sent to a SNMPv1 entity acting in an agent role:

   (1)  If a GetRequest-PDU, GetNextRequest-PDU, or SetRequest-PDU is
        received, then it is passed unaltered by the proxy agent.

   (2)  If a GetBulkRequest-PDU is received, the proxy agent sets the non-
        repeaters and max-repetitions fields to zero, and sets the tag of
        the PDU to GetNextRequest-PDU.

3.1.2.  SNMPv1 -> SNMPv2

   When converting responses received from a SNMPv1 entity acting in an
   agent role into responses sent to a SNMPv2 entity acting in a manager
   role:

(1)  If a GetResponse-PDU is received, then it is passed unaltered by
     the proxy agent.  Note that even though a SNMPv2 entity will never
     generate a Response-PDU with a error-status field having a value of
     `noSuchName', `badValue', or `readOnly', the proxy agent must not
     change this field.  This allows the SNMPv2 entity acting in a
     manager role to interpret the response correctly.

     If a GetResponse-PDU is received with an error-status field having
     a value of `tooBig', the proxy agent will remove the contents of
     the variable-bindings field before propagating the response.  Note
     that even though a SNMPv2 entity will never generate a `tooBig' in
     response to a GetBulkRequest-PDU, the proxy agent must propagate
     such a response.

(2)  If a Trap-PDU is received, then it is mapped into a SNMPv2-Trap-
     PDU.  This is done by prepending onto the variable-bindings field
     two new bindings:  sysUpTime.0 [6], which takes its value from the
     timestamp field of the Trap-PDU; and, snmpTrapOID.0 [6], which is
     calculated thusly:  if the value of generic-trap field is
     `enterpriseSpecific', then the value used is the concatenation of
     the enterprise field from the Trap-PDU with two additional sub-
     identifiers, `0', and the value of the specific-trap field;
     otherwise, the value of the corresponding trap defined in [6] is
     used.  (For example, if the value of the generic-trap field is
     `coldStart', then the coldStart trap [6] is used.)  Then, one new
     binding is appended onto the variable-bindings field:
     snmpTrapEnterprise.0 [6], which takes its value from the enterprise
     field of the Trap-PDU.  The destinations for the SNMPv2-Trap-PDU
     are determined in an implementation-dependent fashion by the proxy
     agent.



SNMPv2 Working Group        Standards Track                     [Page 7]

RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996


3.2.  Bi-lingual Manager Behavior

   To achieve coexistence at the protocol-level, a protocol entity
   acting in a manager role might support both SNMPv1 and SNMPv2.  When
   a management application needs to contact a protocol entity acting in
   an agent role, the entity acting in a manager role consults a local
   database to select the correct management protocol to use.

   In order to provide transparency to management applications, the
   entity acting in a manager role must map operations as if it were
   acting as a proxy agent.

4.  Security Considerations

   Security issues are not discussed in this memo.

5.  Editor's Address

   Keith McCloghrie
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134-1706
   US

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

6.  Acknowledgements

   This document is the result of significant work by the four major
   contributors:

   Jeffrey D. Case (SNMP Research, [e-mail])
   Keith McCloghrie (Cisco Systems, [e-mail])
   Marshall T. Rose (Dover Beach Consulting, [e-mail])
   Steven Waldbusser (International Network Services, [e-mail])

   In addition, the contributions of the SNMPv2 Working Group are
   acknowledged.  In particular, a special thanks is extended for the
   contributions of:

     Alexander I. Alten (Novell)
     Dave Arneson (Cabletron)
     Uri Blumenthal (IBM)
     Doug Book (Chipcom)
     Kim Curran (Bell-Northern Research)
     Jim Galvin (Trusted Information Systems)
     Maria Greene (Ascom Timeplex)



SNMPv2 Working Group        Standards Track                     [Page 8]

RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996


     Iain Hanson (Digital)
     Dave Harrington (Cabletron)
     Nguyen Hien (IBM)
     Jeff Johnson (Cisco Systems)
     Michael Kornegay (Object Quest)
     Deirdre Kostick (AT&T Bell Labs)
     David Levi (SNMP Research)
     Daniel Mahoney (Cabletron)
     Bob Natale (ACE*COMM)
     Brian O'Keefe (Hewlett Packard)
     Andrew Pearson (SNMP Research)
     Dave Perkins (Peer Networks)
     Randy Presuhn (Peer Networks)
     Aleksey Romanov (Quality Quorum)
     Shawn Routhier (Epilogue)
     Jon Saperia (BGS Systems)
     Bob Stewart (Cisco Systems, [e-mail]), chair
     Kaj Tesink (Bellcore)
     Glenn Waters (Bell-Northern Research)
     Bert Wijnen (IBM)

7.  References

[1]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
     S. Waldbusser, "Structure of Management Information for Version 2
     of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
     January 1996.

[2]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
     S. Waldbusser, "Textual Conventions for Version 2 of the Simple
     Network Management Protocol (SNMPv2)", RFC 1903, January 1996.

[3]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
     S. Waldbusser, "Conformance Statements for Version 2 of the Simple
     Network Management Protocol (SNMPv2)", RFC 1904, January 1996.

[4]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
     S. Waldbusser, "Protocol Operations for Version 2 of the Simple
     Network Management Protocol (SNMPv2)", RFC 1905, January 1996.

[5]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
     S. Waldbusser, "Transport Mappings for Version 2 of the Simple
     Network Management Protocol (SNMPv2)", RFC 1906, January 1996.

[6]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
     S. Waldbusser, "Management Information Base for Version 2 of the
     Simple Network Management Protocol (SNMPv2)", RFC 1907,
     January 1996.



SNMPv2 Working Group        Standards Track                     [Page 9]

RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996


[7]  Rose, M., and K. McCloghrie, "Structure and Identification of
     Management Information for TCP/IP-based internets", STD 16, RFC
     1155, May 1990.

[8]  Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16,
     RFC 1212, March 1991.

[9]  Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network
     Management Protocol", STD 15, RFC 1157, SNMP Research, Performance
     Systems International, MIT Laboratory for Computer Science, May
     1990.

[10] Information processing systems - Open Systems Interconnection -
     Specification of Abstract Syntax Notation One (ASN.1),
     International Organization for Standardization.  International
     Standard 8824, (December, 1987).

[11] McCloghrie, K., and M. Rose, "A Convention for Describing SNMP-
     based Agents", RFC 1303, Hughes LAN Systems, Dover Beach
     Consulting, Inc., February 1992.































SNMPv2 Working Group        Standards Track                    [Page 10]