rfc3584.txt

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

Network Working Group                                            R. Frye
Request for Comments: 3584                             Vibrant Solutions
BCP: 74                                                          D. Levi
Obsoletes: 2576                                          Nortel Networks
Category: Best Current Practice                              S. Routhier
                                                Wind River Systems, Inc.
                                                               B. Wijnen
                                                     Lucent Technologies
                                                             August 2003


        Coexistence between Version 1, Version 2, and Version 3
         of the Internet-standard Network Management Framework

Status of this Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   The purpose of this document is to describe coexistence between
   version 3 of the Internet-standard Network Management Framework,
   (SNMPv3), version 2 of the Internet-standard Network Management
   Framework (SNMPv2), and the original Internet-standard Network
   Management Framework (SNMPv1).  This document also describes how to
   convert MIB modules from SMIv1 format to SMIv2 format.  This document
   obsoletes RFC 2576.


















Frye, et al.             Best Current Practice                  [Page 1]

RFC 3584           Coexistence between SNMP versions         August 2003


Table Of Contents

   1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . .    3
       1.1.  SNMPv1 . . . . . . . . . . . . . . . . . . . . . . . .    4
       1.2.  SNMPv2 . . . . . . . . . . . . . . . . . . . . . . . .    4
       1.3.  SNMPv3 . . . . . . . . . . . . . . . . . . . . . . . .    5
   2.  SMI and Management Information Mappings. . . . . . . . . . .    5
       2.1.  MIB Modules. . . . . . . . . . . . . . . . . . . . . .    6
             2.1.1.  Object Definitions . . . . . . . . . . . . . .    6
             2.1.2.  Trap and Notification Definitions  . . . . . .    8
       2.2.  Compliance Statements. . . . . . . . . . . . . . . . .    9
       2.3.  Capabilities Statements. . . . . . . . . . . . . . . .    9
   3.  Translating Notification Parameters. . . . . . . . . . . . .   10
       3.1.  Translating  SNMPv1  Notification  Parameters  to
             SNMPv2 Notification Parameters . . . . . . . . . . . .   11
       3.2.  Translating  SNMPv2  Notification  Parameters  to
             SNMPv1 Notification Parameters . . . . . . . . . . . .   12
   4.  Approaches to Coexistence in a Multi-lingual Network . . . .   14
       4.1.  SNMPv1 and SNMPv2 Access to MIB Data . . . . . . . . .   14
       4.2.  Multi-lingual implementations. . . . . . . . . . . . .   15
             4.2.1.  Command Generator. . . . . . . . . . . . . . .   15
             4.2.2.  Command Responder. . . . . . . . . . . . . . .   16
                     4.2.2.1.  Handling Counter64 . . . . . . . . .   16
                     4.2.2.2.  Mapping SNMPv2 Exceptions. . . . . .   17
                               4.2.2.2.1. Mapping noSuchObject
                                          and noSuchInstance. . . .   18
                               4.2.2.2.2. Mapping endOfMibView. . .   18
                     4.2.2.3.  Processing An SNMPv1 GetReques . . .   18
                     4.2.2.4.  Processing An SNMPv1 GetNextRequest.   19
                     4.2.2.5.  Processing An SNMPv1 SetRequest. . .   20
             4.2.3.  Notification Originator. . . . . . . . . . . .   21
             4.2.4.  Notification Receiver. . . . . . . . . . . . .   21
       4.3.  Proxy Implementations. . . . . . . . . . . . . . . . .   22
             4.3.1.  Upstream Version Greater Than Downstream
                     Version. . . . . . . . . . . . . . . . . . . .   22
             4.3.2.  Upstream Version Less Than Downstream Version.   23
       4.4.  Error Status Mappings. . . . . . . . . . . . . . . . .   25
   5.  Message Processing Models and Security Models. . . . . . . .   26
       5.1.  Mappings . . . . . . . . . . . . . . . . . . . . . . .   26
       5.2.  The SNMPv1 MP Model and SNMPv1  Community-based
             Security Model . . . . . . . . . . . . . . . . . . . .   26
             5.2.1.  Processing An Incoming Request . . . . . . . .   27
             5.2.2.  Generating An Outgoing Response. . . . . . . .   29
             5.2.3.  Generating An Outgoing Notification. . . . . .   29
             5.2.4.  Proxy Forwarding Of Requests . . . . . . . . .   30
       5.3.  The SNMP Community MIB Module. . . . . . . . . . . . .   30
   6.  Intellectual Property Statement. . . . . . . . . . . . . . .   42
   7.  Acknowledgments. . . . . . . . . . . . . . . . . . . . . . .   43



Frye, et al.             Best Current Practice                  [Page 2]

RFC 3584           Coexistence between SNMP versions         August 2003


   8.  Security Considerations. . . . . . . . . . . . . . . . . . .   43
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . .   44
       9.1.  Normative References . . . . . . . . . . . . . . . . .   44
       9.2.  Informative References . . . . . . . . . . . . . . . .   46
   Appendix A.  Change Log. . . . . . . . . . . . . . . . . . . . .   47
       A.1. Changes From RFC 2576 . . . . . . . . . . . . . . . . .   47
       A.2. Changes Between RFC 1908 and RFC 2576 . . . . . . . . .   49
   Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . .   50
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . .   51

1.  Overview

   The purpose of this document is to describe coexistence between
   version 3 of the Internet-standard Network Management Framework,
   termed the SNMP version 3 framework (SNMPv3), version 2 of the
   Internet-standard Network Management Framework, termed the SNMP
   version 2 framework (SNMPv2), and the original Internet-standard
   Network Management Framework (SNMPv1).

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   There are four general aspects of coexistence described in this
   document.  Each of these is described in a separate section:

   -  Conversion of MIB documents between SMIv1 and SMIv2 formats is
      documented in section 2.

   -  Mapping of notification parameters is documented in section 3.

   -  Approaches to coexistence between entities which support the
      various versions of SNMP in a multi-lingual network is documented
      in section 4.  This section addresses the processing of protocol
      operations in multi-lingual implementations, as well as behaviour
      of proxy implementations.

   -  The SNMPv1 Message Processing Model and Community-Based Security
      Model, which provides mechanisms for adapting SNMPv1 into the
      View-Based Access Control Model (VACM) [20], is documented in
      section 5 (this section also addresses the SNMPv2c Message
      Processing Model and Community-Based Security Model).









Frye, et al.             Best Current Practice                  [Page 3]

RFC 3584           Coexistence between SNMP versions         August 2003


1.1.  SNMPv1

   SNMPv1 is defined by these documents:

   -  STD 15, RFC 1157 [RFC1157] which defines the Simple Network
      Management Protocol (SNMPv1), the protocol used for network access
      to managed objects.

   -  STD 16, RFC 1155 [RFC1155] which defines the Structure of
      Management Information (SMIv1), the mechanisms used for describing
      and naming objects for the purpose of management.

   -  STD 16, RFC 1212 [RFC1212] which defines a more concise
      description mechanism, which is wholly consistent with the SMIv1.

   -  RFC 1215 [RFC1215] which defines a convention for defining Traps
      for use with the SMIv1.

   Note that throughout this document, the term 'SMIv1' is used.  This
   term generally refers to the information presented in RFC 1155, RFC
   1212, and RFC 1215.

1.2.  SNMPv2

   SNMPv2 is defined by these documents:

   -  STD 58, RFC 2578 which defines Version 2 of the Structure of
      Management Information (SMIv2) [RFC2578].

   -  STD 58, RFC 2579 which defines common MIB "Textual Conventions"
      [RFC2579].

   -  STD 58, RFC 2580 which defines Conformance Statements and
      requirements for defining agent and manager capabilities
      [RFC2580].

   -  STD 62, RFC 3416 which defines the Protocol Operations used in
      processing [RFC3416].

   -  STD 62, RFC 3417 which defines the Transport Mappings used "on the
      wire" [RFC3417].

   -  STD 62, RFC 3418 which defines the basic Management Information
      Base for monitoring and controlling some basic common functions of
      SNMP entities [RFC3418].

   Note that SMIv2 as used throughout this document refers to the first
   three documents listed above (RFCs 2578, 2579, and 2580).



Frye, et al.             Best Current Practice                  [Page 4]

RFC 3584           Coexistence between SNMP versions         August 2003


   The following document augments the definition of SNMPv2:

   -  RFC 1901 [RFC1901] is an Experimental definition for using SNMPv2
      PDUs within a community-based message wrapper.  This is referred
      to throughout this document as SNMPv2c.

1.3.  SNMPv3

   SNMPv3 is defined by these documents:

   -  STD 62, RFC 3411 which defines an Architecture for Describing SNMP
      Management Frameworks [RFC3411].

   -  STD 62, RFC 3412 which defines Message Processing and Dispatching
      [RFC3412].

   -  STD 62, RFC 3413 which defines various SNMP Applications
      [RFC3413].

   -  STD 62, RFC 3414 which defines the User-based Security Model
      (USM), providing for both Authenticated and Private (encrypted)
      SNMP messages [RFC3414].

   -  STD 62, RFC 3415 which defines the View-based Access Control Model
      (VACM), providing the ability to limit access to different MIB
      objects on a per-user basis [RFC3415].

   SNMPv3 also uses the SNMPv2 definitions of RFCs 3416 through 3418 and
   the SMIv2 definitions of 2578 through 2580 described above.  Note
   that text throughout this document that refers to SNMPv2 PDU types
   and protocol operations applies to both SNMPv2c and SNMPv3.

2.  SMI and Management Information Mappings

   The SMIv2 approach towards describing collections of managed objects
   is nearly a proper superset of the approach defined in the SMIv1.
   For example, both approaches use an adapted subset of ASN.1 [ASN1] as
   the basis for a formal descriptive notation.  Indeed, one might note
   that the SMIv2 approach largely codifies the existing practice for
   defining MIB modules, based on extensive experience with the SMIv1.

   The following sections consider the three areas:  MIB modules,
   compliance statements, and capabilities statements.








Frye, et al.             Best Current Practice                  [Page 5]

RFC 3584           Coexistence between SNMP versions         August 2003


2.1.  MIB Modules

   MIB modules defined using the SMIv1 may continue to be used with
   protocol versions which use SNMPv2 PDUs.  However, for SMIv1 MIB
   modules to conform to the SMIv2, the following changes SHALL be made:

2.1.1.  Object Definitions

   In general, conversion of a MIB module does not require the
   deprecation of the objects contained therein.  If the definition of
   an object is truly inadequate for its intended purpose, the object
   SHALL be deprecated or obsoleted, otherwise deprecation is not
   required.

   (1)  The IMPORTS statement MUST reference SNMPv2-SMI, instead of
        RFC1155-SMI and RFC-1212.