home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1908 < prev    next >
Text File  |  1996-01-22  |  21KB  |  564 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                               SNMPv2 Working Group
  8. Request for Comments: 1908                                       J. Case
  9. Obsoletes: 1452                                      SNMP Research, Inc.
  10. Category: Standards Track                                  K. McCloghrie
  11.                                                      Cisco Systems, Inc.
  12.                                                                  M. Rose
  13.                                             Dover Beach Consulting, Inc.
  14.                                                            S. Waldbusser
  15.                                           International Network Services
  16.                                                             January 1996
  17.  
  18.  
  19.            Coexistence between Version 1 and Version 2 of the
  20.              Internet-standard Network Management Framework
  21.  
  22. Status of this Memo
  23.  
  24.    This document specifies an Internet standards track protocol for the
  25.    Internet community, and requests discussion and suggestions for
  26.    improvements.  Please refer to the current edition of the "Internet
  27.    Official Protocol Standards" (STD 1) for the standardization state
  28.    and status of this protocol.  Distribution of this memo is unlimited.
  29.  
  30. Table of Contents
  31.  
  32.    1. Introduction ................................................    2
  33.    2. Management Information ......................................    2
  34.    2.1 Object Definitions .........................................    3
  35.    2.2 Trap Definitions ...........................................    5
  36.    2.3 Compliance Statements ......................................    5
  37.    2.4 Capabilities Statements ....................................    6
  38.    3 Protocol Operations ..........................................    6
  39.    3.1 Proxy Agent Behavior .......................................    6
  40.    3.1.1 SNMPv2 -> SNMPv1 .........................................    7
  41.    3.1.2 SNMPv1 -> SNMPv2 .........................................    7
  42.    3.2 Bi-lingual Manager Behavior ................................    8
  43.    4. Security Considerations .....................................    8
  44.    5. Editor's Address ............................................    8
  45.    6. Acknowledgements ............................................    8
  46.    7. References ..................................................    9
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. SNMPv2 Working Group        Standards Track                     [Page 1]
  59.  
  60. RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996
  61.  
  62.  
  63. 1.  Introduction
  64.  
  65.    The purpose of this document is to describe coexistence between
  66.    version 2 of the Internet-standard Network Management Framework [1-
  67.    6], termed the SNMP version 2 framework (SNMPv2), and the original
  68.    Internet-standard Network Management Framework (SNMPv1), which
  69.    consists of these three documents:
  70.  
  71.       STD 16, RFC 1155 [7] which defines the Structure of Management
  72.       Information (SMI), the mechanisms used for describing and naming
  73.       objects for the purpose of management.
  74.  
  75.       STD 16, RFC 1212 [8] which defines a more concise description
  76.       mechanism, which is wholly consistent with the SMI.
  77.  
  78.       STD 15, RFC 1157 [9] which defines the Simple Network Management
  79.       Protocol (SNMP), the protocol used for network access to managed
  80.       objects.
  81.  
  82. 2.  Management Information
  83.  
  84.    The SNMPv2 approach towards describing collections of managed objects
  85.    is nearly a proper superset of the approach defined in the Internet-
  86.    standard Network Management Framework.  For example, both approaches
  87.    use ASN.1 [10] as the basis for a formal descriptive notation.
  88.    Indeed, one might note that the SNMPv2 approach largely codifies the
  89.    existing practice for defining MIB modules, based on extensive
  90.    experience with the current framework.
  91.  
  92.    The SNMPv2 documents which deal with information modules are:
  93.  
  94.      Structure of Management Information for SNMPv2 [1], which defines
  95.      concise notations for describing information modules, managed
  96.      objects and notifications;
  97.  
  98.      Textual Conventions for SNMPv2 [2], which defines a concise
  99.      notation for describing textual conventions, and also defines some
  100.      initial conventions; and,
  101.  
  102.      Conformance Statements for SNMPv2 [3], which defines concise
  103.      notation for describing compliance and capabilities statements.
  104.  
  105.    The following sections consider the three areas:  MIB modules,
  106.    compliance statements, and capabilities statements.
  107.  
  108.    MIB modules defined using the current framework may continue to be
  109.    used with the SNMPv2 protocol.  However, for the MIB modules to
  110.    conform to the SNMPv2 framework, the following changes are required:
  111.  
  112.  
  113.  
  114. SNMPv2 Working Group        Standards Track                     [Page 2]
  115.  
  116. RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996
  117.  
  118.  
  119. 2.1.  Object Definitions
  120.  
  121.    In general, conversion of a MIB module does not require the
  122.    deprecation of the objects contained therein.  Only if the semantics
  123.    of an object truly changes should deprecation be performed.
  124.  
  125. (1)  The IMPORTS statement must reference SNMPv2-SMI, instead of
  126.      RFC1155-SMI and RFC-1212.
  127.  
  128. (2)  The MODULE-IDENTITY macro must be invoked immediately after any
  129.      IMPORTs statement.
  130.  
  131. (3)  For any descriptor which contains the hyphen character, the hyphen
  132.      character is removed.
  133.  
  134. (4)  For any label for a named-number enumeration which contains the
  135.      hyphen character, the hyphen character is removed.
  136.  
  137. (5)  For any object with an integer-valued SYNTAX clause, in which the
  138.      corresponding INTEGER does not have a range restriction (i.e., the
  139.      INTEGER has neither a defined set of named-number enumerations nor
  140.      an assignment of lower- and upper-bounds on its value), the object
  141.      must have the value of its SYNTAX clause changed to Integer32.
  142.  
  143. (6)  For any object with a SYNTAX clause value of an enumerated INTEGER,
  144.      the hyphen character is removed from any named-number labels which
  145.      contain the hyphen character.
  146.  
  147. (7)  For any object with a SYNTAX clause value of Counter, the object
  148.      must have the value of its SYNTAX clause changed to Counter32.
  149.  
  150. (8)  For any object with a SYNTAX clause value of Gauge, the object must
  151.      have the value of its SYNTAX clause changed to Gauge32.
  152.  
  153. (9)  For all objects, the ACCESS clause must be replaced by a MAX-ACCESS
  154.      clause.  The value of the MAX-ACCESS clause is the same as that of
  155.      the ACCESS clause unless some other value makes "protocol sense" as
  156.      the maximal level of access for the object.  In particular, object
  157.      types for which instances can be explicitly created by a protocol
  158.      set operation, will have a MAX-ACCESS clause of "read-create".  If
  159.      the value of the ACCESS clause is "write-only", then the value of
  160.      the MAX-ACCESS clause is "read-write", and the DESCRIPTION clause
  161.      notes that reading this object will result implementation-specific
  162.      results.
  163.  
  164. (10) For all objects, if the value of the STATUS clause is "mandatory",
  165.      the value must be replaced with "current".
  166.  
  167.  
  168.  
  169.  
  170. SNMPv2 Working Group        Standards Track                     [Page 3]
  171.  
  172. RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996
  173.  
  174.  
  175. (11) For all objects, if the value of the STATUS clause is "optional",
  176.      the value must be replaced with "obsolete".
  177.  
  178. (12) For any object not containing a DESCRIPTION clause, the object must
  179.      have a DESCRIPTION clause defined.
  180.  
  181. (13) For any object corresponding to a conceptual row which does not
  182.      have an INDEX clause, the object must have either an INDEX clause
  183.      or an AUGMENTS clause defined.
  184.  
  185. (14) For any object with an INDEX clause that references an object with
  186.      a syntax of NetworkAddress, the value of the STATUS clause of both
  187.      objects is changed to "obsolete".
  188.  
  189. (15) For any object containing a DEFVAL clause with an OBJECT IDENTIFIER
  190.      value which is expressed as a collection of sub-identifiers, change
  191.      the value to reference a single ASN.1 identifier.
  192.  
  193. Other changes are desirable, but not necessary:
  194.  
  195. (1)  Creation and deletion of conceptual rows is inconsistent using the
  196.      current framework.  The SNMPv2 framework corrects this.  As such,
  197.      if the MIB module undergoes review early in its lifetime, and it
  198.      contains conceptual tables which allow creation and deletion of
  199.      conceptual rows, then it may be worthwhile to deprecate the objects
  200.      relating to those tables and replace them with objects defined
  201.      using the new approach.
  202.  
  203. (2)  For any object with a string-valued SYNTAX clause, in which the
  204.      corresponding OCTET STRING does not have a size restriction (i.e.,
  205.      the OCTET STRING has no assignment of lower- and upper-bounds on
  206.      its length), one might consider defining the bounds for the size of
  207.      the object.
  208.  
  209. (3)  For all textual conventions informally defined in the MIB module,
  210.      one might consider redefining those conventions using the TEXTUAL-
  211.      CONVENTION macro.  Such a change would not necessitate deprecating
  212.      objects previously defined using an informal textual convention.
  213.  
  214. (4)  For any object which represents a measurement in some kind of
  215.      units, one might consider adding a UNITS clause to the definition
  216.      of that object.
  217.  
  218. (5)  For any conceptual row which is an extension of another conceptual
  219.      row, i.e., for which subordinate columnar objects both exist and
  220.      are identified via the same semantics as the other conceptual row,
  221.      one might consider using an AUGMENTS clause in place of the INDEX
  222.      clause for the object corresponding to the conceptual row which is
  223.  
  224.  
  225.  
  226. SNMPv2 Working Group        Standards Track                     [Page 4]
  227.  
  228. RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996
  229.  
  230.  
  231.      an extension.
  232.  
  233. Finally, when encountering common errors in SNMPv1 MIB modules:
  234.  
  235. (1)  For any non-columnar object that is instanced as if it were
  236.      immediately subordinate to a conceptual row, the value of the
  237.      STATUS clause of that object is changed to "obsolete".
  238.  
  239. (2)  For any conceptual row object that is not contained immediately
  240.      subordinate to a conceptual table, the value of the STATUS clause
  241.      of that object (and all subordinate objects) is changed to
  242.      "obsolete".
  243.  
  244. 2.2.  Trap Definitions
  245.  
  246.    If a MIB module is changed to conform to the SNMPv2 framework, then
  247.    each occurrence of the TRAP-TYPE macro must be changed to a
  248.    corresponding invocation of the NOTIFICATION-TYPE macro:
  249.  
  250.    (1)  The IMPORTS statement must not reference RFC-1215.
  251.  
  252.    (2)  The ENTERPRISES clause must be removed.
  253.  
  254.    (3)  The VARIABLES clause must be renamed to the OBJECTS clause.
  255.  
  256.    (4)  The STATUS clause must be added.
  257.  
  258.    (5)  The value of an invocation of the NOTIFICATION-TYPE macro is an
  259.         OBJECT IDENTIFIER, not an INTEGER, and must be changed accordingly.
  260.         Specifically, if the value of the ENTERPRISE clause is not 'snmp'
  261.         then the value of the invocation is the value of the ENTERPRISE
  262.         clause extended with two sub-identifiers, the first of which has
  263.         the value 0, and the second has the value of the invocation of the
  264.         TRAP-TYPE.
  265.  
  266. 2.3.  Compliance Statements
  267.  
  268.    For those information modules which are "standard", a corresponding
  269.    invocation of the MODULE-COMPLIANCE macro must be included within the
  270.    information module (or in a companion information module), and any
  271.    commentary text in the information module which relates to compliance
  272.    must be removed.  Typically this editing can occur when the
  273.    information module undergoes review.
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. SNMPv2 Working Group        Standards Track                     [Page 5]
  283.  
  284. RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996
  285.  
  286.  
  287. 2.4.  Capabilities Statements
  288.  
  289.    In the current framework, the informational document [11] uses the
  290.    MODULE-CONFORMANCE macro to describe an agent's capabilities with
  291.    respect to one or more MIB modules.  Converting such a description
  292.    for use with the SNMPv2 framework requires these changes:
  293.  
  294.    (1)  Use the macro name AGENT-CAPABILITIES instead of MODULE-
  295.         CONFORMANCE.
  296.  
  297.    (2)  The STATUS clause must be added.
  298.  
  299.    (3)  For all occurrences of the CREATION-REQUIRES clause, note the
  300.         slight change in semantics, and omit this clause if appropriate.
  301.  
  302.    In order to ease the coexistence between SNMPv1 and SNMPv2, object
  303.    groups defined in an SNMPv1 MIB module may be referenced by the
  304.    INCLUDES clause of an invocation of the AGENT-CAPABILITIES macro:
  305.    upon encountering a reference to an OBJECT IDENTIFIER subtree defined
  306.    in an SNMPv1 MIB module, all leaf objects which are subordinate to
  307.    the subtree and have a STATUS clause value of mandatory are deemed to
  308.    be INCLUDEd.  (Note that this method is ambiguous when different
  309.    revisions of a SNMPv1 MIB have different sets of mandatory objects
  310.    under the same subtree; in such cases, the only solution is to
  311.    rewrite the MIB using the SNMPv2 SMI in order to define the object
  312.    groups unambiguously.)
  313.  
  314. 3.  Protocol Operations
  315.  
  316.    The SNMPv2 documents which deal with protocol operations are:
  317.  
  318.      Protocol Operations for SNMPv2 [4], which defines the syntax and
  319.      semantics of the operations conveyed by the protocol; and,
  320.  
  321.      Transport Mappings for SNMPv2 [5], which defines how the protocol
  322.      operations are carried over different transport services.
  323.  
  324.    The following section considers two areas:  the proxy behavior
  325.    between a SNMPv2 entity and a SNMPv1 agent; and, the behavior of
  326.    "bi-lingual" protocol entities acting in a manager role.
  327.  
  328. 3.1.  Proxy Agent Behavior
  329.  
  330.    To achieve coexistence at the protocol-level, a proxy mechanism may
  331.    be used.  A SNMPv2 entity acting in an agent role may be implemented
  332.    and configured to act in the role of a proxy agent.
  333.  
  334.  
  335.  
  336.  
  337.  
  338. SNMPv2 Working Group        Standards Track                     [Page 6]
  339.  
  340. RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996
  341.  
  342.  
  343. 3.1.1.  SNMPv2 -> SNMPv1
  344.  
  345.    When converting requests from a SNMPv2 entity acting in a manager
  346.    role into requests sent to a SNMPv1 entity acting in an agent role:
  347.  
  348.    (1)  If a GetRequest-PDU, GetNextRequest-PDU, or SetRequest-PDU is
  349.         received, then it is passed unaltered by the proxy agent.
  350.  
  351.    (2)  If a GetBulkRequest-PDU is received, the proxy agent sets the non-
  352.         repeaters and max-repetitions fields to zero, and sets the tag of
  353.         the PDU to GetNextRequest-PDU.
  354.  
  355. 3.1.2.  SNMPv1 -> SNMPv2
  356.  
  357.    When converting responses received from a SNMPv1 entity acting in an
  358.    agent role into responses sent to a SNMPv2 entity acting in a manager
  359.    role:
  360.  
  361. (1)  If a GetResponse-PDU is received, then it is passed unaltered by
  362.      the proxy agent.  Note that even though a SNMPv2 entity will never
  363.      generate a Response-PDU with a error-status field having a value of
  364.      `noSuchName', `badValue', or `readOnly', the proxy agent must not
  365.      change this field.  This allows the SNMPv2 entity acting in a
  366.      manager role to interpret the response correctly.
  367.  
  368.      If a GetResponse-PDU is received with an error-status field having
  369.      a value of `tooBig', the proxy agent will remove the contents of
  370.      the variable-bindings field before propagating the response.  Note
  371.      that even though a SNMPv2 entity will never generate a `tooBig' in
  372.      response to a GetBulkRequest-PDU, the proxy agent must propagate
  373.      such a response.
  374.  
  375. (2)  If a Trap-PDU is received, then it is mapped into a SNMPv2-Trap-
  376.      PDU.  This is done by prepending onto the variable-bindings field
  377.      two new bindings:  sysUpTime.0 [6], which takes its value from the
  378.      timestamp field of the Trap-PDU; and, snmpTrapOID.0 [6], which is
  379.      calculated thusly:  if the value of generic-trap field is
  380.      `enterpriseSpecific', then the value used is the concatenation of
  381.      the enterprise field from the Trap-PDU with two additional sub-
  382.      identifiers, `0', and the value of the specific-trap field;
  383.      otherwise, the value of the corresponding trap defined in [6] is
  384.      used.  (For example, if the value of the generic-trap field is
  385.      `coldStart', then the coldStart trap [6] is used.)  Then, one new
  386.      binding is appended onto the variable-bindings field:
  387.      snmpTrapEnterprise.0 [6], which takes its value from the enterprise
  388.      field of the Trap-PDU.  The destinations for the SNMPv2-Trap-PDU
  389.      are determined in an implementation-dependent fashion by the proxy
  390.      agent.
  391.  
  392.  
  393.  
  394. SNMPv2 Working Group        Standards Track                     [Page 7]
  395.  
  396. RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996
  397.  
  398.  
  399. 3.2.  Bi-lingual Manager Behavior
  400.  
  401.    To achieve coexistence at the protocol-level, a protocol entity
  402.    acting in a manager role might support both SNMPv1 and SNMPv2.  When
  403.    a management application needs to contact a protocol entity acting in
  404.    an agent role, the entity acting in a manager role consults a local
  405.    database to select the correct management protocol to use.
  406.  
  407.    In order to provide transparency to management applications, the
  408.    entity acting in a manager role must map operations as if it were
  409.    acting as a proxy agent.
  410.  
  411. 4.  Security Considerations
  412.  
  413.    Security issues are not discussed in this memo.
  414.  
  415. 5.  Editor's Address
  416.  
  417.    Keith McCloghrie
  418.    Cisco Systems, Inc.
  419.    170 West Tasman Drive
  420.    San Jose, CA  95134-1706
  421.    US
  422.  
  423.    Phone: +1 408 526 5260
  424.    EMail: kzm@cisco.com
  425.  
  426. 6.  Acknowledgements
  427.  
  428.    This document is the result of significant work by the four major
  429.    contributors:
  430.  
  431.    Jeffrey D. Case (SNMP Research, case@snmp.com)
  432.    Keith McCloghrie (Cisco Systems, kzm@cisco.com)
  433.    Marshall T. Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us)
  434.    Steven Waldbusser (International Network Services, stevew@uni.ins.com)
  435.  
  436.    In addition, the contributions of the SNMPv2 Working Group are
  437.    acknowledged.  In particular, a special thanks is extended for the
  438.    contributions of:
  439.  
  440.      Alexander I. Alten (Novell)
  441.      Dave Arneson (Cabletron)
  442.      Uri Blumenthal (IBM)
  443.      Doug Book (Chipcom)
  444.      Kim Curran (Bell-Northern Research)
  445.      Jim Galvin (Trusted Information Systems)
  446.      Maria Greene (Ascom Timeplex)
  447.  
  448.  
  449.  
  450. SNMPv2 Working Group        Standards Track                     [Page 8]
  451.  
  452. RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996
  453.  
  454.  
  455.      Iain Hanson (Digital)
  456.      Dave Harrington (Cabletron)
  457.      Nguyen Hien (IBM)
  458.      Jeff Johnson (Cisco Systems)
  459.      Michael Kornegay (Object Quest)
  460.      Deirdre Kostick (AT&T Bell Labs)
  461.      David Levi (SNMP Research)
  462.      Daniel Mahoney (Cabletron)
  463.      Bob Natale (ACE*COMM)
  464.      Brian O'Keefe (Hewlett Packard)
  465.      Andrew Pearson (SNMP Research)
  466.      Dave Perkins (Peer Networks)
  467.      Randy Presuhn (Peer Networks)
  468.      Aleksey Romanov (Quality Quorum)
  469.      Shawn Routhier (Epilogue)
  470.      Jon Saperia (BGS Systems)
  471.      Bob Stewart (Cisco Systems, bstewart@cisco.com), chair
  472.      Kaj Tesink (Bellcore)
  473.      Glenn Waters (Bell-Northern Research)
  474.      Bert Wijnen (IBM)
  475.  
  476. 7.  References
  477.  
  478. [1]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
  479.      S. Waldbusser, "Structure of Management Information for Version 2
  480.      of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
  481.      January 1996.
  482.  
  483. [2]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
  484.      S. Waldbusser, "Textual Conventions for Version 2 of the Simple
  485.      Network Management Protocol (SNMPv2)", RFC 1903, January 1996.
  486.  
  487. [3]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
  488.      S. Waldbusser, "Conformance Statements for Version 2 of the Simple
  489.      Network Management Protocol (SNMPv2)", RFC 1904, January 1996.
  490.  
  491. [4]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
  492.      S. Waldbusser, "Protocol Operations for Version 2 of the Simple
  493.      Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
  494.  
  495. [5]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
  496.      S. Waldbusser, "Transport Mappings for Version 2 of the Simple
  497.      Network Management Protocol (SNMPv2)", RFC 1906, January 1996.
  498.  
  499. [6]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
  500.      S. Waldbusser, "Management Information Base for Version 2 of the
  501.      Simple Network Management Protocol (SNMPv2)", RFC 1907,
  502.      January 1996.
  503.  
  504.  
  505.  
  506. SNMPv2 Working Group        Standards Track                     [Page 9]
  507.  
  508. RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996
  509.  
  510.  
  511. [7]  Rose, M., and K. McCloghrie, "Structure and Identification of
  512.      Management Information for TCP/IP-based internets", STD 16, RFC
  513.      1155, May 1990.
  514.  
  515. [8]  Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16,
  516.      RFC 1212, March 1991.
  517.  
  518. [9]  Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network
  519.      Management Protocol", STD 15, RFC 1157, SNMP Research, Performance
  520.      Systems International, MIT Laboratory for Computer Science, May
  521.      1990.
  522.  
  523. [10] Information processing systems - Open Systems Interconnection -
  524.      Specification of Abstract Syntax Notation One (ASN.1),
  525.      International Organization for Standardization.  International
  526.      Standard 8824, (December, 1987).
  527.  
  528. [11] McCloghrie, K., and M. Rose, "A Convention for Describing SNMP-
  529.      based Agents", RFC 1303, Hughes LAN Systems, Dover Beach
  530.      Consulting, Inc., February 1992.
  531.  
  532.  
  533.  
  534.  
  535.  
  536.  
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. SNMPv2 Working Group        Standards Track                    [Page 10]
  563.  
  564.