rfc3512.txt

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

Network Working Group                                        M. MacFaden
Request for Comments: 3512                     Riverstone Networks, Inc.
Category: Informational                                       D. Partain
                                                                Ericsson
                                                              J. Saperia
                                                    JDS Consulting, Inc.
                                                            W. Tackabury
                                              Gold Wire Technology, Inc.
                                                              April 2003


                 Configuring Networks and Devices with
               Simple Network Management Protocol (SNMP)

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

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

Abstract

   This document is written for readers interested in the Internet
   Standard Management Framework and its protocol, the Simple Network
   Management Protocol (SNMP).  In particular, it offers guidance in the
   effective use of SNMP for configuration management.  This information
   is relevant to vendors that build network elements, management
   application developers, and those that acquire and deploy this
   technology in their networks.

Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .   3
      1.1. The Internet Standard Management Framework. . . . . . . .   3
      1.2. Configuration and the Internet Standard Management
           Frame-work. . . . . . . . . . . . . . . . . . . . . . . .   4
   2. Using SNMP as a Configuration Mechanism. . . . . . . . . . . .   5
      2.1. Transactions and SNMP . . . . . . . . . . . . . . . . . .   6
      2.2. Practical Requirements for Transactional Control. . . . .   6
      2.3. Practices in Configuration--Verification. . . . . . . . .   7
   3. Designing a MIB Module . . . . . . . . . . . . . . . . . . . .   9
      3.1. MIB Module Design - General Issues. . . . . . . . . . . .  10
      3.2. Naming MIB modules and Managed Objects. . . . . . . . . .  11
      3.3. Transaction Control And State Tracking. . . . . . . . . .  12



MacFaden, et al.             Informational                      [Page 1]

RFC 3512       Configuring Networks and Devices with SNMP     April 2003


           3.3.1. Conceptual Table Row Modification Practices. . . .  12
           3.3.2. Fate sharing with multiple tables. . . . . . . . .  13
           3.3.3. Transaction Control MIB Objects. . . . . . . . . .  14
           3.3.4. Creating And Activating New Table Rows . . . . . .  15
           3.3.5. Summary Objects and State Tracking . . . . . . . .  15
           3.3.6. Optimizing Configuration Data Transfer . . . . . .  18
      3.4. More Index Design Issues. . . . . . . . . . . . . . . . .  22
           3.4.1. Simple Integer Indexing. . . . . . . . . . . . . .  23
           3.4.2. Indexing with Network Addresses. . . . . . . . . .  23
      3.5. Conflicting Controls. . . . . . . . . . . . . . . . . . .  24
      3.6. Textual Convention Usage. . . . . . . . . . . . . . . . .  25
      3.7. Persistent Configuration. . . . . . . . . . . . . . . . .  26
      3.8. Configuration Sets and Activation . . . . . . . . . . . .  28
           3.8.1. Operational Activation Considerations. . . . . . .  28
           3.8.2. RowStatus and Deactivation . . . . . . . . . . . .  30
      3.9. SET Operation Latency . . . . . . . . . . . . . . . . . .  31
           3.9.1. Subsystem Latency, Persistence Latency,
                  and Activation Latency . . . . . . . . . . . . . .  33
      3.10. Notifications and Error Reporting. . . . . . . . . . . .  33
           3.10.1. Identifying Source of Configuration Changes . . .  34
           3.10.2. Limiting Unnecessary Transmission of
                   Notifications . . . . . . . . . . . . . . . . . .  34
           3.10.3. Control of Notification Subsystem . . . . . . . .  36
      3.11 Application Error Reporting . . . . . . . . . . . . . . .  36
      3.12 Designing MIB Modules for Multiple Managers . . . . . . .  37
      3.13 Other MIB Module Design Issues. . . . . . . . . . . . . .  39
           3.13.1. Octet String Aggregations . . . . . . . . . . . .  39
           3.13.2 Supporting multiple instances of a MIB Module. . .  40
           3.13.3 Use of Special Optional Clauses. . . . . . . . . .  41
   4. Implementing SNMP Configuration Agents . . . . . . . . . . . .  41
      4.1. Operational Consistency . . . . . . . . . . . . . . . . .  41
      4.2. Handling Multiple Managers. . . . . . . . . . . . . . . .  43
      4.3. Specifying Row Modifiability. . . . . . . . . . . . . . .  44
      4.4. Implementing Write-only Access Objects. . . . . . . . . .  44
   5. Designing Configuration Management Software. . . . . . . . . .  44
      5.1. Configuration Application Interactions
           with Managed Systems. . . . . . . . . . . . . . . . . . .  45
           5.1.1. SET Operations . . . . . . . . . . . . . . . . . .  46
           5.1.2. Configuration Transactions . . . . . . . . . . . .  46
           5.1.3. Tracking Configuration Changes . . . . . . . . . .  47
           5.1.4. Scalability of Data Retrieval. . . . . . . . . . .  48
   6. Deployment and Security Issues . . . . . . . . . . . . . . . .  48
      6.1. Basic assumptions about Configuration . . . . . . . . . .  48
      6.2. Secure Agent Considerations . . . . . . . . . . . . . . .  49
      6.3. Authentication Notifications. . . . . . . . . . . . . . .  49
      6.4. Sensitive Information Handling. . . . . . . . . . . . . .  50
   7. Policy-based Management. . . . . . . . . . . . . . . . . . . .  51
      7.1. What Is the Meaning of 'Policy-based' . . . . . . . . . .  51



MacFaden, et al.             Informational                      [Page 2]

RFC 3512       Configuring Networks and Devices with SNMP     April 2003


      7.2. Organization of Data in an SNMP-Based Policy System . . .  53
      7.3. Information Related to Policy-based Configuration . . . .  54
      7.4. Schedule and Time Issues. . . . . . . . . . . . . . . . .  56
      7.5. Conflict Detection, Resolution and Error Reporting. . . .  56
           7.5.1. Changes to Configuration Outside of the
                  Policy System. . . . . . . . . . . . . . . . . . .  57
      7.6. More about Notifications in a Policy System . . . . . . .  57
      7.7. Using Policy to Move Less Configuration Data. . . . . . .  57
   8. Example MIB Module With Template-based Data. . . . . . . . . .  58
      8.1. MIB Module Definition. . . . . . . .  . . . . . . . . . .  61
      8.2. Notes on MIB Module with Template-based Data. . . . . . .  73
      8.3. Examples of Usage of the MIB . . . . . . .. . . . . . . .  74
   9. Security Considerations . . . . . . . . . . .. . . . . . . . .  77
   10. Acknowledgments. . . . . . . . . . . . . . .  . . . . . . . .  78
   11. Normative References. . . . . . . . . . . . . . . . . . . . .  78
   12. Informative References. . . . . . . . . . . . . . . . . . . .  79
   13. Intellectual Property . . . . . . . . . . . . . . . . . . . .  81
   14. Editors' Addresses. . . . . . . . . . . . . . . . . . . . . .  82
   15. Full Copyright Statement. . . . . . . . . . . . . . . . . . .  83

1.  Introduction

1.1.  The Internet Standard Management Framework

   The Internet Standard Management Framework has many components.  The
   purpose of this document is to describe effective ways of applying
   those components to the problems of configuration management.

   For reference purposes, the Internet Standard Management Framework
   presently consists of five major components:

   o  An overall architecture, described in RFC 3411 [1].

   o  Mechanisms for describing and naming objects and events for the
      purpose of management.  The first version of this Structure of
      Management Information (SMI) is called SMIv1 and described in STD
      16, RFC 1155 [15], STD 16, RFC 1212 [16] and RFC 1215 [17].  The
      second version, called SMIv2, is described in STD 58, RFC 2578
      [2], STD 58, RFC 2579 [3] and STD 58, RFC 2580 [4].

   o  Message protocols for transferring management information.  The
      first version of the SNMP message protocol is called SNMPv1 and
      described in STD 15, RFC 1157 [18].  A second version of the SNMP
      message protocol, which is not an Internet standards track
      protocol, is called SNMPv2c and described in RFC 1901 [19].  The
      third version of the message protocol is called SNMPv3 and
      described in RFC 3417 [5], RFC 3412 [6] and RFC 3414 [7].




MacFaden, et al.             Informational                      [Page 3]

RFC 3512       Configuring Networks and Devices with SNMP     April 2003


   o  Protocol operations for accessing management information.  The
      first set of protocol operations and associated PDU formats is
      described in STD 15, RFC 1157 [18].  A second set of protocol
      operations and associated PDU formats is described in RFC 3416
      [8].

   o  A set of fundamental applications described in RFC 3413 [9] and
      the view-based access control mechanism described in RFC 3415
      [10].

   A more detailed introduction to the current SNMP Management Framework
   can be found in RFC 3410 [12].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Objects in the MIB are
   defined using the mechanisms defined in the SMI.

1.2.  Configuration and the Internet Standard Management Framework

   Data networks have grown significantly over the past decade.  This
   growth can be seen in terms of:

   Scale - Networks have more network elements, and the network
      elements are larger and place more demands on the systems managing
      them.  For example, consider a typical number and speed of
      interfaces in a modern core network element.  A managed
      metropolitan area network switch can have a port density much
      greater than the port density built into the expectations of the
      management systems that predated it.  There are also many more
      interrelationships within and between devices and device
      functions.

   Functionality - network devices perform more functions.
      More protocols and network layers are required for the successful
      deployment of network services which depend on them.

   Rate of Change - the nature of modern network services
      causes updates, additions, and deletions of device configuration
      information more often than in the past.  No longer can it be
      assumed that a configuration will be specified once and then be
      updated rarely.  On the contrary, the trend has been towards much
      more frequent changes of configuration information.

   Correct configuration of network elements that make up data networks
   is a prerequisite to the successful deployment of the services on
   them.  The growth in size and complexity of modern networks increases
   the need for a standard configuration mechanism that is tightly
   integrated with performance and fault management systems.



MacFaden, et al.             Informational                      [Page 4]

RFC 3512       Configuring Networks and Devices with SNMP     April 2003


   The Internet Standard Management Framework has been used successfully
   to develop configuration management systems for a broad range of
   devices and networks.  A standard configuration mechanism that
   tightly integrates with performance and fault systems is needed not
   only to help reduce the complexity of management, but also to enable
   verification of configuration activities that create revenue-
   producing services.

   This document describes Current Practices that have been used when
   designing effective configuration management systems using the
   Internet Standard Management Framework (colloquially known as SNMP).
   It covers many basic practices as well as more complex agent and
   manager design issues that are raised by configuration management.
   We are not endeavoring to present a comprehensive how-to document for
   generalized SNMP agent, MIB module, or management application design
   and development.  We will, however, cover points of generalized SNMP
   software design and implementation practice, where the practice has
   been seen to benefit configuration management software.  So, for
   example, the requirement for management applications to be aware of
   agent limitations is discussed in the context of configuration
   operations, but many issues that a management application developer
   should consider with regard to manager-agent interactions are left
   for other documents and resources.

   Significant experience has been gained over the past ten years in
   configuring public and private data networks with SNMP.  During this
   time, networks have grown significantly as described above.  A
   response to this explosive growth has been the development of
   policy-based configuration management.  Policy-Based Configuration
   Management is a methodology wherein configuration information is
   derived from rules and network-wide objectives, and is distributed to
   potentially many network elements with the goal of achieving
   consistent network behavior throughout an administrative domain.

   This document presents lessons learned from these experiences and
   applies them to both conventional and policy-based configuration
   systems based on SNMP.

2.  Using SNMP as a Configuration Mechanism

   Configuration activity causes one or more state changes in an
   element.  While it often takes an arbitrary number of commands and
   amount of data to make up configuration change, it is critical that
   the configuration system treat the overall change operation
   atomically so that the number of states into which an element
   transitions is minimized.  The goal is for a change request either to
   be completely executed or not at all.  This is called transactional
   integrity.  Transactional integrity makes it possible to develop



MacFaden, et al.             Informational                      [Page 5]

RFC 3512       Configuring Networks and Devices with SNMP     April 2003


   reliable configuration systems that can invoke transactions and keep
   track of an element's overall state and work in the presence of error
   states.

2.1.  Transactions and SNMP

   Transactions can logically take place at very fine-grained levels