summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3512.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3512.txt')
-rw-r--r--doc/rfc/rfc3512.txt4651
1 files changed, 4651 insertions, 0 deletions
diff --git a/doc/rfc/rfc3512.txt b/doc/rfc/rfc3512.txt
new file mode 100644
index 0000000..37848f2
--- /dev/null
+++ b/doc/rfc/rfc3512.txt
@@ -0,0 +1,4651 @@
+
+
+
+
+
+
+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
+ such as an individual object instance or in very large aggregations
+ that could include many object instances located in many tables on a
+ managed device. For this reason, reliance on transactional integrity
+ only at the SNMP protocol level is insufficient.
+
+2.2. Practical Requirements for Transactional Control
+
+ A well-designed and deployed configuration system should have the
+ following features with regard to transactions and transactional
+ integrity.
+
+ 1) Provide for flexible transaction control at many different levels
+ of granularity. At one extreme, an entire configuration may be
+ delivered and installed on an element, or alternately one small
+ attribute may be changed.
+
+ 2) The transaction control component should work at and understand a
+ notion of the kind of multi-level "defaulting" as described in
+ Section 7.1. The key point here is that it may make most sense to
+ configure systems at an abstract level rather than on an
+ individual instance by instance basis as has been commonly
+ practiced. In some cases it is more effective to send a
+ configuration command to a system that contains a set of
+ 'defaults' to be applied to instances that meet certain criteria.
+
+ 3) An effective configuration management system must allow
+ flexibility in the definition of a successful transaction. This
+ cannot be done at the protocol level alone, but rather must be
+ provided for throughout the application and the information that
+ is being managed. In the case of SNMP, the information would be
+ in properly defined MIB modules.
+
+ 4) A configuration management system should provide time-indexed
+ transaction control. For effective rollback control, the
+ configuration transactions and their successful or unsuccessful
+ completion status must be reported by the managed elements and
+ stored in a repository that supports such time indexing and can
+ record the user that made the change, even if the change was not
+ carried out by the system recording the change.
+
+
+
+
+
+MacFaden, et al. Informational [Page 6]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ 5) The managed system must support transactional security. This
+ means that depending on who is making the configuration request
+ and where it is being made, it may be accepted or denied based on
+ security policy that is in effect in the managed element.
+
+ Effective transactional control is a responsibility shared between
+ design, implementation, and operational practice. Transaction
+ control techniques for MIB module design are discussed in Section
+ 3.3. Transaction control considerations for the agent implementation
+ are discussed in Section 5.2.2.
+
+2.3. Practices in Configuration--Verification
+
+ Verification of expected behavior subsequent to the commitment of
+ change is an integral part of the configuration process. To reduce
+ the chance of making simple errors in configuration, many
+ organizations employ the following change management procedure:
+
+ pre-test - verify that the system is presently working properly
+
+ change - make configuration changes and wait for convergence
+ (system or network stability)
+
+ re-test - verify once again that the system is working properly
+
+ This procedure is commonly used to verify configuration changes to
+ critical systems such as the domain name system (DNS). DNS software
+ kits provide diagnostic tools that allow automatic test
+ procedures/scripts to be conducted.
+
+ A planned configuration sequence can be aborted if the pre-
+ configuration test result shows the state of the system as unstable.
+ Debugging the unintended effects of two sets of changes in large
+ systems is often more challenging than an analysis of the effects of
+ a single set after test termination.
+
+ Networks and devices under SNMP configuration readily support this
+ change management procedure since the SNMP provides integrated
+ monitoring, configuration and diagnostic capabilities. The key is
+ the sequencing of SNMP protocol operations to effect an integrated
+ change procedure like the one described above. This is usually a
+ well-bounded affair for changes within a single network element or
+ node. However, there are times when configuration of a given element
+ can impact other elements in a network. Configuring network
+ protocols such as IEEE 802.1D Spanning Tree or OSPF is especially
+ challenging since the impact of a configuration change can directly
+ affect stability (convergence) of the network the device is connected
+ to.
+
+
+
+MacFaden, et al. Informational [Page 7]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ An integrated view of configuration and monitoring provides an ideal
+ platform from which to evaluate such changes. For example, the MIB
+ module governing IEEE 802.1D Spanning Tree (RFC 1493 [24]) provides
+ the following object to monitor stability per logical bridge.
+
+ dot1dStpTopChanges OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "The total number of topology changes detected by
+ this bridge since the management entity was last
+ reset or initialized."
+ REFERENCE
+ "IEEE 802.1D-1990: Section 6.8.1.1.3"
+ ::= { dot1dStp 4 }
+
+ Likewise, the OSPF MIB module provides a similar metric for stability
+ per OSPF area.
+
+ ospfSpfRuns OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The number of times that the intra-area route
+ table has been calculated using this area's
+ link-state database. This is typically done
+ using Dijkstra's algorithm."
+ ::= { ospfAreaEntry 4 }
+
+ The above object types are good examples of a means of facilitating
+ the principles described in Section 2.3. That is, one needs to
+ understand the behavior of a subsystem before configuration change,
+ then be able to use the same means to retest and verify proper
+ operation subsequent to configuration change.
+
+ The operational effects of a given implementation often differ from
+ one to another for any given standard configuration object. The
+ impact of a change to stability of systems such as OSPF should be
+ documented in an agent-capabilities statement which is consistent
+ with "Requirements for IP Version 4 Routers" [22], Section 1.3.4:
+
+ A vendor needs to provide adequate documentation on all
+ configuration parameters, their limits and effects.
+
+
+
+
+
+
+MacFaden, et al. Informational [Page 8]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ Adherence to the above model is not fail-safe, especially when
+ configuration errors are masked by long latencies or when
+ configuration errors lead to oscillations in network stability. For
+ example, consider the situation of loading a new software version on
+ a device, which leads to small, slow, cumulative memory leaks brought
+ on by a certain traffic pattern that was not caught during vendor and
+ customer test lab trials.
+
+ In a network-based example, convergence in an autonomous system
+ cannot be guaranteed when configuration changes are made since there
+ are factors beyond the control of the operator, such as the state of
+ other network elements. Problems affecting this convergence may not
+ be detected for a significant period of time after the configuration
+ change. Even for factors within the operator's control, there is
+ often little verification done to prevent mis-configuration (as shown
+ in the following example).
+
+ Consider a change made to ospfIfHelloInterval and
+ ospfIfRtrDeadInterval [24] timers in the OSPF routing protocol such
+ that both are set to the same value. Two routers may form an
+ adjacency but then begin to cycle in and out of adjacency, and thus
+ never reach a stable (converged) state. Had the configuration
+ process described at the beginning of this section been employed,
+ this particular situation would have been discovered without
+ impacting the production network.
+
+ The important point to remember from this discussion is that
+ configuration systems should be designed and implemented with
+ verification tests in mind.
+
+3. Designing a MIB Module
+
+ Carefully considered MIB module designs are crucial to practical
+ configuration with SNMP. As we have just seen, MIB objects designed
+ for configuration can be very effective since they can be associated
+ with integrated diagnostic, monitoring, and fault objects. MIB
+ modules for configuration also scale when they expose their notion of
+ template object types. Template objects can represent information at
+ a higher level of abstraction than instance-level ones. This has the
+ benefit of reducing the amount of instance-level data to move from
+ management application to the agent on the managed element, when that
+ instance-level data is brought about by applying a template object on
+ the agent. Taken together, all of these objects can provide a robust
+ configuration subsystem.
+
+ The remainder of this section provides specific practices used in MIB
+ module design with SMIv2 and SNMPv3.
+
+
+
+
+MacFaden, et al. Informational [Page 9]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+3.1. MIB Module Design - General Issues
+
+ One of the first tasks in defining a MIB module is the creation of a
+ model that reflects the scope and organization of the management
+ information an agent will expose.
+
+ MIB modules can be thought of as logical models providing one or more
+ aspects/views of a subsystem. The objective for all MIB modules
+ should be to serve one or more operational requirements such as
+ accounting information collection, configuration of one or more parts
+ of a system, or fault identification. However, it is important to
+ include only those aspects of a subsystem that are proven to be
+ operationally useful.
+
+ In 1993, one of most widely deployed MIB modules supporting
+ configuration was published, RFC 1493, which contained the BRIDGE-
+ MIB. It defined the criteria used to develop the MIB module as
+ follows:
+
+ To be consistent with IAB directives and good engineering
+ practice, an explicit attempt was made to keep this MIB as simple
+ as possible. This was accomplished by applying the following
+ criteria to objects proposed for inclusion:
+
+ (1) Start with a small set of essential objects and add only as
+ further objects are needed.
+
+ (2) Require objects be essential for either fault or configuration
+ management.
+
+ (3) Consider evidence of current use and/or utility.
+
+ (4) Limit the total (sic) of objects.
+
+ (5) Exclude objects which are simply derivable from others in this
+ or other MIBs.
+
+ (6) Avoid causing critical sections to be heavily instrumented. The
+ guideline that was followed is one counter per critical section
+ per layer.
+
+ Over the past eight years additional experience has shown a need to
+ expand these criteria as follows:
+
+ (7) Before designing a MIB module, identify goals and objectives for
+ the MIB module. How much of the underlying system will be
+ exposed depends on these goals.
+
+
+
+
+MacFaden, et al. Informational [Page 10]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ (8) Minimizing the total number of objects is not an explicit goal,
+ but usability is. Be sure to consider deployment and usability
+ requirements.
+
+ (9) During configuration, consider supporting explicit error state,
+ capability and capacity objects.
+
+ (10) When evaluating rule (5) above, consider the impact on a
+ management application. If an object can help reduce a
+ management application's complexity, consider defining objects
+ that can be derived.
+
+3.2. Naming MIB modules and Managed Objects
+
+ Naming of MIB modules and objects informally follows a set of best
+ practices. Originally, standards track MIB modules used RFC names.
+ As the MIB modules evolved, the practice changed to using more
+ descriptive names. Presently, Standards Track MIB modules define a
+ given area of technology such as ATM-MIB, and vendors then extend
+ such MIB modules by prefixing the company name to a given MIB module
+ as in ACME-ATM-MIB.
+
+ Object descriptors (the "human readable names" assigned to object
+ identifiers [2]) defined in standard MIB modules should be unique
+ across all MIB modules. Generally, a prefix is added to each managed
+ object that can help reference the MIB module it was defined in. For
+ example, the IF-MIB uses "if" prefix for descriptors of object types
+ such as ifTable, ifStackTable and so forth.
+
+ MIB module object type descriptors can include an abbreviation for
+ the function they perform. For example the objects that control
+ configuration in the example MIB module in Section 8 include "Cfg" as
+ part of the object descriptor, as in bldgHVACCfgDesiredTemp.
+
+ This is more fully realized when the object descriptors that include
+ the fault, configuration, accounting, performance and security [33]
+ abbreviations are combined with an organized OID assignment approach.
+ For example, a vendor could create a configuration branch in their
+ private enterprises area. In some cases this might be best done on a
+ per product basis. Whatever the approach used, "Cfg" might be
+ included in every object descriptor in the configuration branch.
+ This has two operational benefits. First, for those that do look at
+ instances of MIB objects, descriptors as seen through MIB browsers or
+ other command line tools assist in conveying the meaning of the
+ object type. Secondly, management applications can be pointed at
+ specific subtrees for fault or configuration, causing a more
+ efficient retrieval of data and a simpler management application with
+ potentially better performance.
+
+
+
+MacFaden, et al. Informational [Page 11]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+3.3. Transaction Control And State Tracking
+
+ Transactions and keeping track of their state is an important
+ consideration when performing any type of configuration activity
+ regardless of the protocol. Here are a few areas to consider when
+ designing transaction support into an SNMP-based configuration
+ system.
+
+3.3.1. Conceptual Table Row Modification Practices
+
+ Any discussion of transaction control as it pertains to MIB module
+ design often begins with how the creation or modification of object
+ instances in a conceptual row in the MIB module is controlled.
+
+ RowStatus [3] is a standard textual convention for the management of
+ conceptual rows in a table. Specifically, the RowStatus textual
+ convention that is used for the SYNTAX value of a single column in a
+ table controls the creation, deletion, activation, and deactivation
+ of conceptual rows of the table. When a table has been defined with
+ a RowStatus object as one of its columns, changing an instance of the
+ object to 'active' causes the row in which that object instance
+ appears to become 'committed'.
+
+ In a multi-table scenario where the configuration data must be spread
+ over many columnar objects, a RowStatus object in one table can be
+ used to cause the entire set of data to be put in operation or stored
+ based on the definition of the objects.
+
+ In some cases, very large amounts of data may need to be 'committed'
+ all at once. In these cases, another approach is to configure all of
+ the rows in all the tables required and have an "activate" object
+ that has a set method that commits all the modified rows.
+
+ The RowStatus textual convention specifies that, when used in a
+ conceptual row, a description must define what can be modified.
+ While the description of the conceptual row and its columnar object
+ types is the correct place to derive this information on instance
+ modifiability, it is often wrongly assumed in some implementations
+ that:
+
+ 1) objects either must all be presently set or none need be set to
+ make a conceptual RowStatus object transition to active(1)
+
+ 2) objects in a conceptual row cannot be modified once a RowStatus
+ object is active(1). Restricting instance modifiability like
+ this, so that after a RowStatus object is set to active(1) is in
+ fact a reasonable limitation, since such a set of RowStatus may
+ have agent system side-effects which depend on committed columnar
+
+
+
+MacFaden, et al. Informational [Page 12]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ object instance values. However, where this restriction exists on
+ an object, it should be made clear in a DESCRIPTION clause such as
+ the following:
+
+ protocolDirDescr OBJECT-TYPE
+ SYNTAX DisplayString (SIZE (1..64))
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "A textual description of the protocol encapsulation.
+ A probe may choose to describe only a subset of the
+ entire encapsulation (e.g., only the highest layer).
+
+ This object is intended for human consumption only.
+
+ This object may not be modified if the associated
+ protocolDirStatus object is equal to active(1)."
+ ::= { protocolDirEntry 4 }
+
+ Any such restrictions on columnar object instance modification while
+ a row's RowStatus object instance is set to active(1) should appear
+ in the DESCRIPTION clause of the RowStatus columnar OBJECT-TYPE as
+ well.
+
+3.3.2. Fate sharing with multiple tables
+
+ An important principle associated with transaction control is fate
+ sharing of rows in different tables. Consider the case where a
+ relationship has been specified between two conceptual tables of a
+ MIB module (or tables in two different MIB modules). In this
+ context, fate sharing means that when a row of a table is deleted,
+ the corresponding row in the other table is also deleted. Fate
+ sharing in a transaction control context can also be used with the
+ activation of very large configuration changes. If we have two
+ tables that hold a set of configuration information, a row in one
+ table might have to be put in the 'ready' state before the second can
+ be put in the 'ready' state. When that second table can be placed in
+ the 'ready' state, then the entire transaction can be considered to
+ have been 'committed'.
+
+ Fate sharing of SNMP table data should be explicitly defined where
+ possible using the SMI index qualifier AUGMENTS. If the relationship
+ between tables cannot be defined using SMIv2 macros, then the
+ DESCRIPTION clause of the object types which particularly effect the
+ cross-table relationship should define what should happen when rows
+ in related tables are added or deleted.
+
+
+
+
+
+MacFaden, et al. Informational [Page 13]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ Consider the relationship between the dot1dBasePortTable and the
+ ifTable. These tables have a sparse relationship. If a given
+ ifEntry supports 802.1D bridging then there is a dot1dBasePortEntry
+ that has a pointer to it via dot1dBasePortIfIndex.
+
+ Now, what should happen if an ifEntry that can bridge is deleted?
+ Should the object dot1dBasePortIfIndex simply be set to 0 or should
+ the dot1dBasePortEntry be deleted as well? A number of acceptable
+ design and practice techniques can provide the answer to these
+ questions, so it is important for the MIB module designer to provide
+ the guidance to guarantee consistency and interoperability.
+
+ To this end, when two tables are related in such a way, ambiguities
+ such as this should be avoided by having the DESCRIPTION clauses of
+ the pertinent row object types define the fate sharing of entries in
+ the respective tables.
+
+3.3.3. Transaction Control MIB Objects
+
+ When a MIB module is defined that includes configuration object
+ types, consider providing transaction control objects. These objects
+ can be used to cause a large transaction to be committed. For
+ example, we might have several tables that define the configuration
+ of a portion of a system. In order to avoid churn in the operational
+ state of the system we might create a single scalar object that, when
+ set to a particular value, will cause the activation of the rows in
+ all the necessary tables. Here are some examples of further usage
+ for such object types:
+
+ o Control objects that are the 'write' or 'commit' objects.
+
+ Such objects can cause all pending transactions (change MIB object
+ values as a result of SET operations) to be committed to a
+ permanent repository or operational memory, as defined by the
+ semantics of the MIB objects.
+
+ o Control objects at different levels of configuration granularity.
+
+ One of the decisions for a MIB module designer is what are the
+ levels of granularity that make sense in practice. For example,
+ in the routing area, would changes be allowed on a per protocol
+ basis such as BGP? If allowed at the BGP level, are sub-levels
+ permitted such as per autonomous system? The design of these
+ control objects will be impacted by the underlying software
+ design. RowStatus (see Section 3.3.1) also has important
+ relevance as a general transaction control object.
+
+
+
+
+
+MacFaden, et al. Informational [Page 14]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+3.3.4. Creating And Activating New Table Rows
+
+ When designing read-create objects in a table, a MIB module designer
+ should first consider the default state of each object in the table
+ when a row is created. Should an implementation of a standard MIB
+ module vary in terms of the objects that need to be set in order to
+ create an instance of a given row, an agent capabilities statement
+ should be used to name the additional objects in that table using the
+ CREATION-REQUIRES clause.
+
+ It is useful when configuring new rows to use the notReady status to
+ indicate row activation cannot proceed.
+
+ When creating a row instance of a conceptual table, one should
+ consider the state of instances of required columnar objects in the
+ row. The DESCRIPTION clause of such a required columnar object
+ should specify it as such.
+
+ During the period of time when a management application is attempting
+ to create a row, there may be a period of time when not all of these
+ required (and non-defaultable) columnar object instances have been
+ set. Throughout this time, an agent should return a noSuchInstance
+ error for a GET of any object instance of the row until such time
+ that all of these required instance values are set. The exception is
+ the RowStatus object instance, for which a notReady(3) value should
+ be returned during this period.
+
+ One need only be concerned with the notReady value return for a
+ RowStatus object when the row under creation does not yet have all of
+ the required, non-defaultable instance values for the row. One
+ approach to simplifying in-row configuration transactions when
+ designing MIB modules is to construct table rows that have no more
+ instance data for columnar objects than will fit inside a single SET
+ PDU. In this case, the createAndWait() value for the RowStatus
+ columnar object is not required. It is possible to use createAndGo()
+ in the same SET PDU, thus simplifying transactional management.
+
+3.3.5. Summary Objects and State Tracking
+
+ Before beginning a new set of configuration transactions, a
+ management application might want to checkpoint the state of the
+ managed devices whose configuration it is about to change. There are
+ a number of techniques that a MIB module designer can provide to
+ assist in the (re-)synchronization of the managed systems. These
+ objects can also be used to verify that the management application's
+ notion of the managed system state is the same as that of the managed
+ device.
+
+
+
+
+MacFaden, et al. Informational [Page 15]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ These techniques include:
+
+ 1. Provide an object that reports the number of rows in a table
+
+ 2. Provide an object that flags when data in the table was last
+ modified.
+
+ 3. Send a notification message (InformRequests are preferable) to
+ deliver configuration change.
+
+ By providing an object containing the number of rows in a table,
+ management applications can decide how best to retrieve a given
+ table's data and may choose different retrieval strategies depending
+ on table size. Note that the availability of and application
+ monitoring of such an object is not sufficient for determining the
+ presence of table data change over a checkpointed duration since an
+ equal number of row creates and deletes over that duration would
+ reflect no change in the object instance value. Additionally, table
+ data change which does not change the number of rows in the table
+ would not be reflected through simple monitoring of such an object
+ instance.
+
+ Instead, the change in the value of any table object instance data
+ can be tracked through an object that monitors table change state as
+ a function of time. An example is found in RFC 2790, Host Resources
+ MIB:
+
+ hrSWInstalledLastUpdateTime OBJECT-TYPE
+ SYNTAX TimeTicks
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The value of sysUpTime when the hrSWInstalledTable
+ was last completely updated. Because caching of this
+ data will be a popular implementation strategy,
+ retrieval of this object allows a management station
+ to obtain a guarantee that no data in this table is
+ older than the indicated time."
+ ::= { hrSWInstalled 2 }
+
+ A similar convention found in many standards track MIB modules is the
+ "LastChange" type object.
+
+ For example, the ENTITY-MIB, RFC 2737 [34], provides the following
+ object:
+
+ entLastChangeTime OBJECT-TYPE
+ SYNTAX TimeStamp
+
+
+
+MacFaden, et al. Informational [Page 16]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The value of sysUpTime at the time a conceptual row is
+ created, modified, or deleted in any of these tables:
+ - entPhysicalTable
+ - entLogicalTable
+ - entLPMappingTable
+ - entAliasMappingTable
+ - entPhysicalContainsTable"
+ ::= { entityGeneral 1 }
+
+ This convention is not formalized. There tend to be small
+ differences in what a table's LastChanged object reflects. IF-MIB
+ (RFC 2863 [20]) defines the following:
+
+ ifTableLastChange OBJECT-TYPE
+ SYNTAX TimeTicks
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The value of sysUpTime at the time of the last
+ creation or deletion of an entry in the ifTable. If
+ the number of entries has been unchanged since the
+ last re-initialization of the local network management
+ subsystem, then this object contains a zero value."
+ ::= { ifMIBObjects 5 }
+
+ So, if an agent modifies a row with an SNMP SET on ifAdminStatus, the
+ value of ifTableLastChange will not be updated. It is important to
+ be specific about what can cause an object to update so that
+ management applications will be able to detect and more properly act
+ on these changes.
+
+ The final way to keep distributed configuration data consistent is to
+ use an event-driven model, where configuration changes are
+ communicated as they occur. When the frequency of change to
+ configuration is relatively low or polling a cache object is not
+ desired, consider defining a notification that can be used to report
+ all configuration change details.
+
+ When doing so, the option is available to an SNMPv3 (or SNMPv2c)
+ agent to deliver the notification using either a trap or an inform.
+ The decision as to which PDU to deliver to the recipient is generally
+ a matter of local configuration. Vendors should recommend the use of
+ informs over traps for NOTIFICATION-TYPE data since the agent can use
+ the presence or absence of a response to help know whether it needs
+
+
+
+
+MacFaden, et al. Informational [Page 17]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ to retransmit or not. Overall, it is preferable to use an inform
+ instead of a trap so that changes have a higher likelihood of
+ confirmed end-to-end delivery.
+
+ As a matter of MIB module design, when practical, the NOTIFICATION-
+ TYPE should include in the PDU all of the modified columnar objects
+ in a row of a table. This makes it easier for the management
+ application receiving the notification to keep track of what has
+ changed in the row of a table and perform addition analysis on the
+ state of the managed elements.
+
+ However, the use of notifications to communicate the state of a
+ rapidly changing object may not be ideal either. This leads us back
+ to the MIB module design question of what is the right level of
+ granularity to expose.
+
+ Finally, having to poll many "LastChange" objects does not scale
+ well. Consider providing a global LastChange type object to
+ represent overall configuration in a given agent implementation.
+
+3.3.6. Optimizing Configuration Data Transfer
+
+ Configuration management software should keep track of the current
+ configuration of all devices under its control. It should ensure
+ that the result is a consistent view of the configuration of the
+ network, which can help reduce inadvertent configuration errors.
+
+ In devices that have very large amounts of configuration data, it can
+ be costly to both the agent and the manager to have the manager
+ periodically poll the entire contents of these configuration tables
+ for synchronization purposes. A benefit of good synchronization
+ between the manager and the agent is that the manager can determine
+ the smallest and most effective set of data to send to managed
+ devices when configuration changes are required. Depending on the
+ table organization in the managed device and the agent
+ implementation, this practice can reduce the burden on the managed
+ device for activation of these configuration changes.
+
+ In the previous section, we discussed the "LastChange" style of
+ object. When viewed against the requirements just described, the
+ LastChange object is insufficient for large amounts of data.
+
+ There are three design options that can be used to assist with the
+ synchronization of the configuration data found in the managed device
+ with the manager:
+
+
+
+
+
+
+MacFaden, et al. Informational [Page 18]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ 1) Design multiple indices to partition the data in a table logically
+ or break a table into a set of tables to partition the data based
+ on what an application will use the table for
+
+ 2) Use a time-based indexing technique
+
+ 3) Define a control MIB module that manages a separate data delivery
+ protocol
+
+3.3.6.1. Index Design
+
+ Index design has a major impact on the amount of data that must be
+ transferred between SNMP entities and can help to mitigate scaling
+ issues with large tables.
+
+ Many tables in standard MIB modules follow one of two indexing
+ models:
+
+ - Indexing based upon increasing Integer32 or Unsigned32 values of
+ the kind one might find in an array.
+
+ - Associative indexing, which refers to the technique of using
+ potentially sparse indices based upon a "key" of the sort one
+ would use for a hash table.
+
+ When tables grow to a very large number of rows, using an associative
+ indexing scheme offers the useful ability to efficiently retrieve
+ only the rows of interest.
+
+ For example, if an SNMP entity exposes a copy of the default-free
+ Internet routing table as defined in the ipCidrRouteTable, it will
+ presently contain around 100,000 rows.
+
+ Associative indexing is used in the ipCidrRouteTable and allows one
+ to retrieve, for example, all routes for a given IPv4 destination
+ 192.0.2/24.
+
+ Yet, if the goal is to extract a copy of the table, the associative
+ indexing reduces the throughput and potentially the performance of
+ retrieval. This is because each of the index objects are appended to
+ the object identifiers for every object instance returned.
+
+ ipCidrRouteEntry OBJECT-TYPE
+ SYNTAX IpCidrRouteEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "A particular route to a particular destination,
+
+
+
+MacFaden, et al. Informational [Page 19]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ under a particular policy."
+ INDEX {
+ ipCidrRouteDest,
+ ipCidrRouteMask,
+ ipCidrRouteTos,
+ ipCidrRouteNextHop
+ }
+
+ A simple array-like index works efficiently since it minimizes the
+ index size and complexity while increasing the number of rows that
+ can be sent in a PDU. If the indexing is not sparse, concurrency can
+ be gained by sending multiple asynchronous non-overlapping collection
+ requests as is explained in RFC 2819 [32], Page 41 (in the section
+ pertaining to Host Group indexing).
+
+ Should requirements dictate new methods of access, multiple
+ indices can be defined such that both associative and simple
+ indexing can coexist to access a single logical table.
+
+ Two examples follow.
+
+ First, consider the ifStackTable found in RFC 2863 [20] and the
+ ifInvStackTable RFC 2864 [33]. They are logical equivalents with the
+ order of the auxiliary (index) objects simply reversed.
+
+ ifStackEntry OBJECT-TYPE
+ SYNTAX IfStackEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "Information on a particular relationship between
+ two sub-layers, specifying that one sub-layer runs
+ on 'top' of the other sub-layer. Each sub-layer
+ corresponds to a conceptual row in the ifTable."
+ INDEX { ifStackHigherLayer, ifStackLowerLayer }
+ ::= { ifStackTable 1 }
+
+ ifInvStackEntry OBJECT-TYPE
+ SYNTAX IfInvStackEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "Information on a particular relationship between two
+ sub-layers, specifying that one sub-layer runs underneath
+ the other sub-layer. Each sub-layer corresponds to a
+ conceptual row in the ifTable."
+ INDEX { ifStackLowerLayer, ifStackHigherLayer }
+ ::= { ifInvStackTable 1 }
+
+
+
+MacFaden, et al. Informational [Page 20]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ Second, table designs that can factor data into multiple tables with
+ well-defined relationships can help reduce overall data transfer
+ requirements. The RMON-MIB, RFC 2819 [32], demonstrates a very
+ useful technique of organizing tables into control and data
+ components. Control tables contain those objects that are configured
+ and change infrequently, and the data tables contain information to
+ be collected that can be large and may change quite frequently.
+
+ As an example, the RMON hostControlTable provides a way to specify
+ how to collect MAC addresses learned as a source or destination from
+ a given port that provides transparent bridging of Ethernet packets.
+
+ Configuration is accomplished using the hostControlTable. It is
+ indexed by a simple integer. While this may seem to be array-like,
+ it is common practice for command generators to encode the ifIndex
+ into this simple integer to provide associative lookup capability.
+
+ The RMON hostTable and hostTimeTable represent dependent tables that
+ contain the results indexed by the hostControlTable entry.
+
+ The hostTable is further indexed by the MAC address which provides
+ the ability to reasonably search for a collection, such as the
+ Organizationally Unique Identifier (OUI), the first three octets of
+ the MAC address.
+
+ The hostTimeTable is designed explicitly for fast transfer of bulk
+ RMON data. It demonstrates how to handle collecting large number of
+ rows in the face of deletions and insertions by providing
+ hostControlLastDeleteTime.
+
+ hostControlLastDeleteTime OBJECT-TYPE
+ SYNTAX TimeTicks
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The value of sysUpTime when the last entry
+ was deleted from the portion of the hostTable
+ associated with this hostControlEntry. If no
+ deletions have occurred, this value shall be zero."
+ ::= { hostControlEntry 4 }
+
+3.3.6.2. Time Based Indexing
+
+ The TimeFilter as defined in RFC 2021 [44] and used in RMON2-MIB and
+ Q-BRIDGE-MIB (RFC 2674 [26]) provides a way to obtain only those rows
+ that have changed on or after some specified period of time has
+ passed.
+
+
+
+
+MacFaden, et al. Informational [Page 21]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ One drawback to TimeFilter index tables is that a given row can
+ appear at many points in time, which artificially inflates the size
+ of the table when performing standard getNext or getBulk data
+ retrieval.
+
+3.3.6.3. Alternate Data Delivery Mechanisms
+
+ If the amount of data to transfer is larger than current SNMP design
+ restrictions permit, as in the case of OCTET STRINGS (64k minus
+ overhead of IP/UDP header plus SNMP header plus varbind list plus
+ varbind encoding), consider delivery of the data via an alternate
+ method, such as FTP and use a MIB module to control that data
+ delivery process. In many cases, this problem can be avoided via
+ effective MIB design. In other words, object types requiring this
+ kind of transfer size should be used judiciously, if at all.
+
+ There are many enterprise MIB modules that provide control of the
+ TFTP or FTP protocol. Often the SNMP part defines what to send where
+ and setting an object initiates the operation (for an example, refer
+ to the CISCO-FTP-CLIENT-MIB, discussed in [38]).
+
+ Various approaches exist for allowing a local agent process running
+ within the managed node to take a template for an object instance
+ (for example for a set of interfaces), and adapt and apply it to all
+ of the actual instances within the node. This is an architecture for
+ one form of policy-based configuration (see [36], for example). Such
+ an architecture, which must be designed into the agent and some
+ portions of the MIB module, affords the efficiency of specifying many
+ copies of instance data only once, along with the execution
+ efficiency of distributing the application of the instance data to
+ the agent.
+
+ Other work is currently underway to improve efficiency for bulk SNMP
+ transfer operations [37]. The objective of these efforts is simply
+ the conveyance of more information with less overhead.
+
+3.4. More Index Design Issues
+
+ Section 3.3.5 described considerations for table row index design as
+ it pertains to the synchronization of changes within sizable table
+ rows. This section simply considers how to specify this syntactically
+ and how to manage indices semantically.
+
+ In many respects, the design issues associated with indices in a MIB
+ module are similar to those in a database. Care must be taken during
+ the design phase to determine how often and what kind of information
+ must be set or retrieved. The next few points provide some guidance.
+
+
+
+
+MacFaden, et al. Informational [Page 22]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+3.4.1. Simple Integer Indexing
+
+ When indexing tables using simple Integer32 or Unsigned32, start with
+ one (1) and specify the maximum range of the value. Since object
+ identifiers are unsigned long values, a question that arises is why
+ not index from zero (0) instead of one(1)?
+
+ RFC 2578 [2], Section 7.7, page 28 states the following: Instances
+ identified by use of integer-valued objects should be numbered
+ starting from one (i.e., not from zero). The use of zero as a value
+ for an integer-valued index object type should be avoided, except in
+ special cases. Consider the provisions afforded by the following
+ textual convention from the Interfaces Group MIB module [33]:
+
+ InterfaceIndexOrZero ::= TEXTUAL-CONVENTION
+ DISPLAY-HINT "d"
+ STATUS current
+ DESCRIPTION
+ "This textual convention is an extension of the
+ InterfaceIndex convention. The latter defines a greater
+ than zero value used to identify an interface or interface
+ sub-layer in the managed system. This extension permits the
+ additional value of zero. the value zero is object-specific
+ and must therefore be defined as part of the description of
+ any object which uses this syntax. Examples of the usage of
+ zero might include situations where interface was unknown,
+ or when none or all interfaces need to be referenced."
+ SYNTAX Integer32 (0..2147483647)
+
+3.4.2. Indexing with Network Addresses
+
+ There are many objects that use IPv4 addresses (SYNTAX IpAddress) as
+ indexes. One such table is the ipAddrTable from RFC 2011 [14] IP-
+ MIB. This limits the usefulness of the MIB module to IPv4. To avoid
+ such limitations, use the addressing textual conventions INET-
+ ADDRESS-MIB [13] (or updates to that MIB module), which provides a
+ generic way to represent addresses for Internet Protocols. In using
+ the InetAddress textual convention in this MIB, however, pay heed to
+ the following advisory found in its description clause:
+
+ When this textual convention is used as the syntax of an index
+ object, there may be issues with the limit of 128 sub-identifiers
+ specified in SMIv2, STD 58. In this case, the OBJECT-TYPE
+ declaration MUST include a 'SIZE' clause to limit the number of
+ potential instance sub-identifiers.
+
+
+
+
+
+
+MacFaden, et al. Informational [Page 23]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ One should consider the SMI limitation on the 128 sub-identifier
+ specification when using certain kinds of network address index
+ types. The most likely practical liability encountered in practice
+ has been with DNS names, which can in fact be in excess of 128 bytes.
+ The problem can be, of course, compounded when multiple indices of
+ this type are specified for a table.
+
+3.5. Conflicting Controls
+
+ MIB module designers should avoid specifying read-write objects that
+ overlap in function partly or completely.
+
+ Consider the following situation where two read-write objects
+ partially overlap when a dot1dBasePortEntry has a corresponding
+ ifEntry.
+
+ The BRIDGE-MIB defines the following managed object:
+
+ dot1dStpPortEnable OBJECT-TYPE
+ SYNTAX INTEGER {
+ enabled(1),
+ disabled(2) }
+ ACCESS read-write
+ STATUS mandatory
+ DESCRIPTION
+ "The enabled/disabled status of the port."
+ REFERENCE
+ "IEEE 802.1D-1990: Section 4.5.5.2"
+ ::= { dot1dStpPortEntry 4 }
+
+ The IF-MIB defines a similar managed object:
+
+ ifAdminStatus OBJECT-TYPE
+ SYNTAX INTEGER {
+ up(1), -- ready to pass packets
+ down(2),
+ testing(3) -- in some test mode
+ }
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "The desired state of the interface. The testing(3)
+ state indicates that no operational packets can be
+ passed. When a managed system initializes, all
+ interfaces start with ifAdminStatus in the down(2) state.
+ As a result of either explicit management action or per
+ configuration information retained by the managed system,
+ ifAdminStatus is then changed to either the up(1) or
+
+
+
+MacFaden, et al. Informational [Page 24]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ testing(3) states (or remains in the down(2) state)."
+ ::= { ifEntry 7 }
+
+ If ifAdminStatus is set to testing(3), the value to be returned for
+ dot1dStpPortEnable is not defined. Without clarification on how
+ these two objects interact, management implementations will have to
+ monitor both objects if bridging is detected and correlate behavior.
+
+ The dot1dStpPortEnable object type could have been written with more
+ information about the behavior of this object when values of
+ ifAdminStatus which impact it change. For example, text could be
+ added that described proper return values for the dot1dStpPortEnable
+ object instance for each of the possible values of ifAdminStatus.
+
+ In those cases where overlap between objects is unavoidable, then as
+ we have just described, care should be taken in the description of
+ each of the objects to describe their possible interactions. In the
+ case of an object type defined after an incumbent object type, it is
+ necessary to include in the DESCRIPTION of this later object type the
+ details of these interactions.
+
+3.6. Textual Convention Usage
+
+ Textual conventions should be used whenever possible to create a
+ consistent semantic for an oft-recurring datatype.
+
+ MIB modules often define a binary state object such as enable/disable
+ or on/off. Current practice is to use existing Textual Conventions
+ and define the read-write object in terms of a TruthValue from
+ SNMPv2-TC [3]. For example, the Q-BRIDGE-MIB [26] defines:
+
+ dot1dTrafficClassesEnabled OBJECT-TYPE
+ SYNTAX TruthValue
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "The value true(1) indicates that Traffic Classes are
+ enabled on this bridge. When false(2), the bridge
+ operates with a single priority level for all traffic."
+ DEFVAL { true }
+ ::= { dot1dExtBase 2 }
+
+ Textual conventions that have a reasonable chance of being reused in
+ other MIB modules ideally should also be defined in a separate MIB
+ module to facilitate sharing of such object types. For example, all
+ ATM MIB modules draw on the ATM-TC-MIB [39] to reference and utilize
+ common definitions for addressing, service class values, and the
+ like.
+
+
+
+MacFaden, et al. Informational [Page 25]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ To simplify management, it is recommended that existing SNMPv2-TC
+ based definitions be used when possible. For example, consider the
+ following object definition:
+
+ acmePatioLights OBJECT-TYPE
+ SYNTAX INTEGER {
+ on(1),
+ off(2),
+ }
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "Current status of outdoor lighting."
+ ::= { acmeOutDoorElectricalEntry 3 }
+
+ This could be defined as follows using existing SNMPv2-TC TruthValue.
+
+ acmePatioLightsOn OBJECT-TYPE
+ SYNTAX TruthValue
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRI2096PTION
+ "Current status of outdoor lighting. When set to true (1),
+ this means that the lights are enabled and turned on.
+ When set to false (2), the lights are turned off."
+ ::= { acmeOutDoorElectricalEntry 3 }
+
+3.7. Persistent Configuration
+
+ Many network devices have two levels of persistence with regard to
+ configuration data. In the first case, the configuration data sent
+ to the device is persistent only until changed with a subsequent
+ configuration operation, or the system is reinitialized. The second
+ level is where the data is made persistent as an inherent part of the
+ acceptance of the configuration information. Some configuration
+ shares both these properties, that is, that on acceptance of new
+ configuration data it is saved permanently and in memory. Neither of
+ these necessarily means that the data is used by the operational
+ code. Sometimes separate objects are required to activate this new
+ configuration data for use by the operational code.
+
+ However, many SNMP agents presently implement simple persistence
+ models, which do not reflect all the relationships of the
+ configuration data to the actual persistence model as described
+ above. Some SNMP set requests against MIB objects with MAX-ACCESS
+ read-write are written automatically to a persistent store. In other
+ cases, they are not. In some of the latter cases, enterprise MIB
+
+
+
+
+MacFaden, et al. Informational [Page 26]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ objects are required in order to get standard configuration stored,
+ thus making it difficult for a generic application to have a
+ consistent effect.
+
+ There are standard conventions for saving configuration data. The
+ first method uses the Textual Convention known as StorageType [3]
+ which explicitly defines a given row's persistence requirement.
+
+ Examples include the RFC 3231 [25] definition for the schedTable row
+ object schedStorageType of syntax StorageType, as well as similar row
+ objects for virtually all of the tables of the SNMP View-based Access
+ Control Model MIB [10].
+
+ A second method for persistence simply uses the DESCRIPTION clause to
+ define how instance data should persist. RFC 2674 [26] explicitly
+ defines Dot1qVlanStaticEntry data persistence as follows:
+
+ dot1qVlanStaticTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF Dot1qVlanStaticEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "A table containing static configuration information for
+ each VLAN configured into the device by (local or
+ network) management. All entries are permanent and will
+ be restored after the device is reset."
+ ::= { dot1qVlan 3 }
+
+ The current practice is a dual persistence model where one can make
+ changes to run-time configuration as well as to a non-volatile
+ configuration read at device initialization. The DISMAN-SCHEDULE-MIB
+ module [25] provides an example of this practice. A row entry of its
+ SchedTable specifies the parameters by which an agent MIB variable
+ instance can be set to a specific value at some point in time and
+ governed by other constraints and directives. One of those is:
+
+ schedStorageType OBJECT-TYPE
+ SYNTAX StorageType
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "This object defines whether this scheduled action is kept
+ in volatile storage and lost upon reboot or if this row is
+ backed up by non-volatile or permanent storage.
+ Conceptual rows having the value `permanent' must allow
+ write access to the columnar objects schedDescr,
+ schedInterval, schedContextName, schedVariable, schedValue,
+ and schedAdminStatus. If an implementation supports the
+
+
+
+MacFaden, et al. Informational [Page 27]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ schedCalendarGroup, write access must be also allowed to
+ the columnar objects schedWeekDay, schedMonth, schedDay,
+ schedHour, schedMinute."
+ DEFVAL { volatile }
+ ::= { schedEntry 19 }
+
+ It is important, however, to reiterate that the persistence is
+ ultimately controlled by the capabilities and features (with respect
+ to the storage model of management data) of the underlying system on
+ which the MIB Module agent is being implemented. This falls into
+ very much the same kind of issue set as, for example, the situation
+ where the size of data storage in the system for a Counter object
+ type is not the same as that in the corresponding MIB Object Type.
+ To generalize, the final word on the "when" and "how" of storage of
+ persistent data is dictated by the system and the implementor of the
+ agent on the system.
+
+3.8. Configuration Sets and Activation
+
+ An essential notion for configuration of network elements with SNMP
+ is awareness of the difference between the set of one or more
+ configuration objects from the activation of those configuration
+ changes in the actual subsystem. That is, it often only makes sense
+ to activate a group of objects as a single 'transaction'.
+
+3.8.1. Operational Activation Considerations
+
+ A MIB module design must consider the implications of the preceding
+ in the context of changes that will occur throughout a subsystem when
+ changes are activated. This is particularly true for configuration
+ changes that are complex. This complexity can be in terms of
+ configuration data or the operational ramifications of the activation
+ of the changes in the managed subsystem. A practical technique to
+ accommodate this kind of activation is the partitioning of contained
+ configuration sets, as it pertains to their being activated as
+ changes. Any complex configuration should have a master on/off
+ switch (MIB object type) as well as strategically placed on/off
+ switches that partition the activation of configuration data in the
+ managed subsystem. These controls play a pivotal role during the
+ configuration process as well as during subsequent diagnostics.
+ Generally, a series of set operations should not cause an agent to
+ activate each object, causing operational instability to be
+ introduced with every changed object instance. To avoid this
+ liability, ideally a series of Set PDUs can install the configuration
+ and a final set series of PDUs can activate the changes.
+
+
+
+
+
+
+MacFaden, et al. Informational [Page 28]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ During diagnostic situations, certain on/off switches can be set to
+ localize the perceived error instead of having to remove the
+ configuration.
+
+ An example of such an object from the OSPF Version 2 MIB [29] is the
+ global ospfAdminStat:
+
+ ospfAdminStat OBJECT-TYPE
+ SYNTAX Status
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "The administrative status of OSPF in the
+ router. The value 'enabled' denotes that the
+ OSPF Process is active on at least one interface;
+ 'disabled' disables it on all interfaces."
+ ::= { ospfGeneralGroup 2 }
+
+ Elsewhere in the OSPF MIB, the semantics of setting ospfAdminStat to
+ enabled(2) are clearly spelled out.
+
+ The Scheduling MIB [25] exposes such an object on each entry in the
+ scheduled actions table, along with the corresponding stats object
+ type (with read-only ACCESS) on the scheduled actions row instance.
+
+ This reflects a recurring basic design pattern which brings about
+ semantic clarity in the object type usage. A table can expose one
+ columnar object type which is strictly for administrative control.
+ When read, an instance of this object type will reflect its last set
+ or defaulted value. A companion operational columnar object type,
+ with MAX-ACCESS of read-only, provides the current state of
+ activation or deactivation resulting from the last set of the
+ administrative columnar instance. It is fully expected that these
+ administrative and operational columnar instances may reflect
+ different values over some period of time of activation latency,
+ which is why they are separate. Further sections display some of the
+ problems which can result from attempting to combine the operational
+ and administrative row columns into a single object type.
+
+ Note that all of this is independent of the RowStatus columnar
+ object, and the notion of 'activation' as it pertains to RowStatus.
+ A defined RowStatus object type should be strictly concerned with the
+ management of the table row itself (with 'activation' indicating "the
+ conceptual row is available for use by the managed device" [3], and
+ not to be confused with any operational activation semantics).
+
+
+
+
+
+
+MacFaden, et al. Informational [Page 29]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ In the following example, schedAdminStatus controls activation of the
+ scheduled action, and schedOperStatus reports on its operational
+ status:
+
+ schedAdminStatus OBJECT-TYPE
+ SYNTAX INTEGER {
+ enabled(1),
+ disabled(2)
+ }
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The desired state of the schedule."
+ DEFVAL { disabled }
+ ::= { schedEntry 14 }
+
+ schedOperStatus OBJECT-TYPE
+ SYNTAX INTEGER {
+ enabled(1),
+ disabled(2),
+ finished(3)
+ }
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The current operational state of this schedule. The state
+ enabled(1) indicates this entry is active and that the
+ scheduler will invoke actions at appropriate times. The
+ disabled(2) state indicates that this entry is currently
+ inactive and ignored by the scheduler. The finished(3)
+ state indicates that the schedule has ended. Schedules
+ in the finished(3) state are ignored by the scheduler.
+ A one-shot schedule enters the finished(3) state when it
+ deactivates itself."
+ ::= { schedEntry 15 }
+
+3.8.2. RowStatus and Deactivation
+
+ RowStatus objects should not be used to control
+ activation/deactivation of a configuration. While RowStatus looks
+ ideally suited for such a purpose since a management application can
+ set a row to active(1), then set it to notInService(2) to disable it
+ then make it active(1) again, there is no guarantee that the agent
+ won't discard the row while it is in the notInService(2) state. RFC
+ 2579 [3], page 15 states:
+
+
+
+
+
+
+MacFaden, et al. Informational [Page 30]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ The agent must detect conceptual rows that have been in either
+ state for an abnormally long period of time and remove them. It
+ is the responsibility of the DESCRIPTION clause of the status
+ column to indicate what an abnormally long period of time would
+ be.
+
+ The DISMAN-SCHEDULE-MIB's managed object schedAdminStatus
+ demonstrates how to separate row control from row activation.
+ Setting the schedAdminStatus to disabled(2) does not cause the row to
+ be aged out/removed from the table.
+
+ Finally, a reasonable agent implementation must consider how many
+ rows will be allowed to be created in the notReady/notInService state
+ such that resources are not exhausted by an errant application.
+
+3.9. SET Operation Latency
+
+ Many standards track and enterprise MIB modules that contain read-
+ write objects assume that an agent can complete a set operation as
+ quickly as an agent can send back the status of the set operation to
+ the application.
+
+ Consider the subtle operational shortcomings in the following object.
+ It both reports the current state and allows a SET operation to
+ change to a possibly new state.
+
+wheelRotationState OBJECT-TYPE
+ SYNTAX INTEGER { unknown(0),
+ idle(1),
+ spinClockwise(2),
+ spinCounterClockwise(3)
+ }
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "The current state of a wheel."
+ ::= { XXX 2 }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+MacFaden, et al. Informational [Page 31]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+With the object defined, the following example represents one possible
+transaction.
+
+Time Command Generator --------> <--- Command Responder
+----- ----------------- -----------------
+|
+A GetPDU(wheelRotationState.1.1)
+|
+| ResponsePDU(error-index 0,
+| error-code 0)
+|
+B wheelRotationState.1.1 == spinClockwise(2)
+|
+C SetPDU(wheelRotationState.1.1 =
+| spinCounterClockwise(3)
+|
+| ResponsePDU(error-index 0,
+| error-code 0)
+|
+D wheelRotationState.1.1
+ == spinCounterClockwise(3)
+|
+E GetPDU(wheelRotationState.1.1)
+|
+F ResponsePDU(error-index 0,
+| error-code 0)
+|
+V wheelRotationState.1.1 == spinClockwise(2)
+ ....some time, perhaps seconds, later....
+|
+G GetPDU(wheelRotationState.1.1)
+|
+H ResponsePDU(error-index 0,
+| error-code 0)
+| wheelRotationState.1.1
+V == spinCounterClockwise(3)
+
+ The response to the GET request at time E will often confuse
+ management applications that assume the state of the object should be
+ spinCounterClockwise(3). In reality, the wheel is slowing down in
+ order to come to the idle state then begin spinning counter
+ clockwise.
+
+ This possibility of confusing and paradoxical interactions of
+ administrative and operational state is inevitable when a single
+ object type is used to control and report on both types of state.
+ One common practice which we have already seen is to separate out the
+
+
+
+
+MacFaden, et al. Informational [Page 32]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ desired (settable) state from current state. The objects
+ ifAdminStatus and ifOperStatus from RFC 2863 [20] provide such an
+ example of the separation of objects into desired and current state.
+
+3.9.1. Subsystem Latency, Persistence Latency, and Activation Latency
+
+ A second way latency can be introduced in SET operations is caused by
+ delay in agent implementations that must interact with loosely
+ coupled subsystems. The time it takes the instrumented system to
+ accept the new configuration information from the SNMP agent, process
+ it and 'install' the updated configuration in the system or otherwise
+ process the directives can often be longer than the SNMP response
+ timeout.
+
+ In these cases, it is desirable to provide a "current state" object
+ type which can be polled by the management application to determine
+ the state of control of the loosely coupled subsystem which was
+ affected by its configuration update.
+
+ More generally, some MIB objects may have high latencies associated
+ with changes to their values. This could be either a function of
+ saving the changed value to a persistent storage type, and/or
+ activating a subsystem that inherently has high latency as discussed
+ above. When defining such MIB objects, it might be wise to have the
+ agent process set operations in the managed subsystem as soon as the
+ Set PDU has been processed, and then update appropriate status
+ objects when the save-to- persistent storage and (if applicable)
+ activation has succeeded or is otherwise complete. Another approach
+ would be to cause a notification to be sent that indicates that the
+ operation has been completed.
+
+ When you describe an activation object, the DESCRIPTION clauses for
+ these objects should give a hint about the likely latency for the
+ completion of the operation. Keep in mind that from a management
+ software perspective (as presented in the example of schedAdminStatus
+ in Section 3.8.1), the combined latency of saving-to-persistence and
+ activation are not distinguishable when they are part of a single
+ operation.
+
+3.10. Notifications and Error Reporting
+
+ For the purpose of this section, a 'notification' is as described in
+ the SMIv2, RFC 2578 [2], by the NOTIFICATION-TYPE macro.
+ Notifications can be sent in either SNMPv2c [19] or SNMPv3 TRAP or
+ InformRequest PDUs. Given the sensitivity of configuration
+ information, it is recommended that configuration operations always
+ be performed using SNMPv3 due to its enhanced security capabilities.
+ InformRequest PDUs should be used in preference to TRAP PDUs since
+
+
+
+MacFaden, et al. Informational [Page 33]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ the recipient of the InformRequest PDUs responds with a Response PDU.
+ This acknowledgment can be used to avoid unnecessary retransmission
+ of NOTIFICATION-TYPE information when retransmissions are in fact
+ required. The use of InformRequest PDUs (as opposed to TRAPs) is not
+ at the control of the MIB module designer or agent implementor. The
+ determination as to whether or not a TRAP or InformRequest PDU is
+ sent from an SNMPv2c or SNMPv3 agent is generally a function of the
+ agent's local configuration (but can be controlled with MIB objects
+ in SNMPv3). To the extent notification timeout and retry values are
+ determined by local configuration parameters, care should be taken to
+ avoid unnecessary retransmission of InformRequest PDUs.
+
+ Configuration change and error information conveyed in InformRequest
+ PDUs can be an important part of an effective SNMP-based management
+ system. They also have the potential to be overused. This section
+ offers some guidance for effective definition of NOTIFICATION-TYPE
+ information about configuration changes that can be carried in
+ InformRequest PDUs. Notifications can also play a key role for all
+ kinds of error reporting from hardware failures to configuration and
+ general policy errors. These types of notifications should be
+ designed as described in Section 3.11 (Application Error Reporting).
+
+3.10.1. Identifying Source of Configuration Changes
+
+ A NOTIFICATION-TYPE designed to report configuration changes should
+ report the identity of the management entity initiating the
+ configuration change. Specifically, if the entity is known to be a
+ SNMP command generator, the transport address and SNMP parameters as
+ found in table snmpTargetParamsTable from RFC 3413 SNMP-TARGET-MIB
+ should be reported where possible. For reporting of configuration
+ changes outside of the SNMP domain, the applicable change mechanism
+ (for example, CLI vs. HTTP-based management client access) should be
+ reported, along with whatever notion of "user ID" of the change
+ initiator is applicable and available.
+
+3.10.2. Limiting Unnecessary Transmission of Notifications
+
+ The design of event-driven synchronization models, essential to
+ configuration management, can use notifications as an important
+ enabling technique. Proper usage of notifications allows the
+ manager's view of the managed element's configuration to be in close
+ synchronization with the actual state of the configuration of the
+ managed element.
+
+ When designing new NOTIFICATION-TYPEs, consider how to limit the
+ number of notifications PDUs that will be sent with the notification
+ information defined in the NOTIFICATION-TYPE in response to a
+ configuration change or error event.
+
+
+
+MacFaden, et al. Informational [Page 34]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ InformRequest PDUs, when compared to TRAP PDUs, have an inherent
+ advantage when the concern is the reduction of unnecessary messages
+ from the system generating the NOTIFICATION-TYPE data, when in fact
+ retransmission of this data is required. That is, an InformRequest
+ PDU is acknowledged by the receiving entity with a Response PDU. The
+ receipt of this response allows the entity which generated the
+ InformRequest PDU to verify (and record an audit entry, where such
+ facilities exist on the agent system) that the message was received.
+ As a matter of notification protocol, this receipt guarantee is not
+ available when using TRAP PDUs, and if it is required, must be
+ accomplished by the agent using some mechanism out of band to SNMP,
+ and usually requiring the penalty of polling.
+
+ Regardless of the specific PDUs used to convey them, one way to limit
+ the unnecessary generation of notifications is to include in the
+ NOTIFICATION-TYPE definition situations where it need not be sent. A
+ good example is the frDLCIStatusChange defined in FRAME-RELAY-DTE-
+ MIB, RFC 2115 [21].
+
+ frDLCIStatusChange NOTIFICATION-TYPE
+ OBJECTS { frCircuitState }
+ STATUS current
+ DESCRIPTION
+ "This trap indicates that the indicated Virtual Circuit
+ has changed state. It has either been created or
+ invalidated, or has toggled between the active and
+ inactive states. If, however, the reason for the state
+ change is due to the DLCMI going down, per-DLCI traps
+ should not be generated."
+ ::= { frameRelayTraps 1 }
+
+ There are a number of other techniques which can be used to reduce
+ the unwanted generation of NOTIFICATION-TYPE information. When
+ defining notifications, the designer can specify a number of temporal
+ limitations on the generation of specific instances of a
+ NOTIFICATION-TYPE. For example, a definition could specify that
+ messages will not be sent more frequently than once every 60 seconds
+ while the condition which led to the generation of the notification
+ persists. Alternately, a NOTIFICATION-TYPE DESCRIPTION clause could
+ provide a fixed limit on the number of messages sent over the
+ duration of the condition leading to sending the notification.
+
+ If NOTIFICATION-TYPE transmission is "aggregated" in some way -
+ bounded either temporally or by absolute system state change as
+ described above - the optimal design technique is to have the data
+ delivered with the notification reference the actual number of
+ underlying managed element transitions which brought about the
+ notification. No matter which threshold is chosen to govern the
+
+
+
+MacFaden, et al. Informational [Page 35]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ actual transmission of NOTIFICATION-TYPEs, the idea is to describe an
+ aggregated event or related set of events in as few PDUs as possible.
+
+3.10.3. Control of Notification Subsystem
+
+ There are standards track MIB modules that define objects that either
+ augment or overlap control of notifications. For instance, FRAME-
+ RELAY-DTE-MIB RFC 2115 defines frTrapMaxRate and DOCS-CABLE-DEVICE-
+ MIB defines a set of objects in docsDevEvent that provide for rate
+ limiting and filtering of notifications.
+
+ In the past, agents did not have a standard means to configure a
+ notification generator. With the availability of the SNMP-
+ NOTIFICATION-MIB module in RFC 3413 [9], it is strongly recommended
+ that the filtering functions of this MIB module be used. This MIB
+ facilitates the mapping of given NOTIFICATION-TYPEs and their
+ intended recipients.
+
+ If the mechanisms of the SNMP-NOTIFICATION-MIB are not suitable for
+ this application, a explanation of why they are not suitable should
+ be included in the DESCRIPTION clause of any replacement control
+ objects.
+
+3.11. Application Error Reporting
+
+ MIB module designers should not rely on the SNMP protocol error
+ reporting mechanisms alone to report application layer error state
+ for objects that accept SET operations.
+
+ Most MIB modules that exist today provide very little detail as to
+ why a configuration request has failed. Often the only information
+ provided is via SNMP protocol errors which generally does not provide
+ enough information about why an agent rejected a set request.
+ Typically, there is an incumbent and sizable burden on the
+ configuration application to determine if the configuration request
+ failure is the result of a resource issue, a security issue, or an
+ application error.
+
+ Ideally, when a "badValue" error occurs for a given set request, an
+ application can query the agent for more details on the error. A
+ badValue does not necessarily mean the command generator sent bad
+ data. An agent could be at fault. Additional detailed diagnostic
+ information may aid in diagnosing conditions in the integrated
+ system.
+
+
+
+
+
+
+
+MacFaden, et al. Informational [Page 36]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ Consider the requirement of conveying error information about a MIB
+ expression 'object' set within the DISMAN-EXPRESSION-MIB [40] that
+ occurs when the expression is evaluated. Clearly, none of the
+ available protocol errors are relevant when reporting an error
+ condition that occurs when an expression is evaluated. Instead, the
+ DISMAN-EXPRESSION-MIB provides objects to report such errors (the
+ expErrorTable). Instead, the expErrorTable maintains information
+ about errors that occur at evaluation time:
+
+ expErrorEntry OBJECT-TYPE
+ SYNTAX ExpErrorEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "Information about errors in processing an expression.
+ Entries appear in this table only when there is a matching
+ expExpressionEntry and then only when there has been an
+ error for that expression as reflected by the error codes
+ defined for expErrorCode."
+ INDEX { expExpressionOwner, expExpressionName }
+
+ More specifically, a MIB module can provide configuration
+ applications with information about errors on the managed device by
+ creating columnar object types in log tables that contain error
+ information particular to errors that occur on row activation.
+
+ Notifications with detailed failure information objects can also be
+ used to signal configuration failures. If this approach is used, the
+ configuration of destinations for NOTIFICATION-TYPE data generated
+ from configuration failures should be considered independently of the
+ those for other NOTIFICATION-TYPEs which are generated for other
+ operational reasons. In other words, in many management
+ environments, the network operators interested in NOTIFICATION-TYPEs
+ generated from configuration failures may not completely overlap with
+ the community of network operators interested in NOTIFICATION-TYPEs
+ generated from, for example, network interface failures.
+
+3.12. Designing MIB Modules for Multiple Managers
+
+ When designing a MIB module for configuration, there are several
+ pertinent considerations to provide support for multiple managers.
+
+ The first is to avoid any race conditions between two or more
+ authorized management applications issuing SET protocol operations
+ spanning over more than a single PDU.
+
+ The standard textual convention document [3] defines TestAndIncr,
+ often called a spinlock, which is used to avoid race conditions.
+
+
+
+MacFaden, et al. Informational [Page 37]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ A MIB module designer may explicitly define a synchronization object
+ of syntax TestAndIncr or may choose to rely on snmpSetSerialNo (a
+ global spinlock object) as defined in SNMPv2-MIB.
+
+ snmpSetSerialNo OBJECT-TYPE
+ SYNTAX TestAndIncr
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "An advisory lock used to allow several cooperating
+ command generator applications to coordinate their
+ use of the SNMP set operation.
+
+ This object is used for coarse-grain coordination.
+ To achieve fine-grain coordination, one or more similar
+ objects might be defined within each MIB group, as
+ appropriate."
+ ::= { snmpSet 1 }
+
+ Another prominent TestAndIncr example can be found in the SNMP-
+ TARGET- MIB [9], snmpTargetSpinLock.
+
+ Secondly, an agent should be able to report configuration as set by
+ different entities as distinguishable from configuration defined
+ external to the SNMP domain, such as application of a default or
+ through an alternate management interface like a command line
+ interface. Section 3.10.1 describes considerations for this practice
+ when designing NOTIFICATION-TYPEs. The OwnerString textual
+ convention from RMON-MIB RFC 2819 [32] has been used successfully for
+ this purpose. More recently, RFC 3411 [1] introduced the
+ SnmpAdminString which has been designed as a UTF8 string. This is
+ more suitable for representing names in many languages.
+
+ Experience has shown that usage of OwnerString to represent row
+ ownership can be a useful diagnostic tool as well. Specifically, the
+ use of the string "monitor" to identify configuration set by an
+ agent/local management has been prevalent and useful in applications.
+
+ Thirdly, consider whether there is a need for multiple managers to
+ configure the same set of tables. If so, an "OwnerString" may be
+ used as the first component of a table's index to allow VACM to be
+ used to protect access to subsets of rows, at least at the level of
+ securityName or groupName provided. RFC 3231 [25], Section 6
+ presents this technique in detail. This technique does add
+ complexity to the managed device and to the configuration management
+ application since the manager will need to be aware of these
+ additional columnar objects in configuration tables and act
+ appropriately to set them. Additionally, the agent must be
+
+
+
+MacFaden, et al. Informational [Page 38]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ configured to provide the appropriate instance-level restrictions on
+ the modifiability of the instances.
+
+3.13. Other MIB Module Design Issues
+
+3.13.1. Octet String Aggregations
+
+ The OCTET STRING syntax can be used as an extremely flexible and
+ useful datatype when defining managed objects that allow SET
+ operation. An octet string is capable of modeling many things and is
+ limited in size to 65535 octets by SMIv2[2].
+
+ Since OCTET STRINGS are very flexible, the need to make them useful
+ to applications requires careful definition. Otherwise, applications
+ will at most simply be able to display and set them.
+
+ Consider the following object from RFC 3418 SNMPv2-MIB [11].
+
+ sysLocation OBJECT-TYPE
+ SYNTAX DisplayString (SIZE (0..255))
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "The physical location of this node (e.g., `telephone
+ closet, 3rd floor'). If the location is unknown, the value
+ is the zero-length string."
+ ::= { system 6 }
+
+ Such informational object types have come to be colloquially known as
+ "scratch pad objects". While often useful, should an application be
+ required to do more with this information than be able to read and
+ set the value of this object, a more precise definition of the
+ contents of the OCTET STRING is needed, since the actual format of an
+ instance for such an object is unstructured. Hence, alternatively,
+ dividing the object type into several object type definitions can
+ provide the required additional structural detail.
+
+ When using OCTET STRINGS, avoid platform dependent data formats.
+ Also avoid using OCTET STRINGS where a more precise SMI syntax such
+ as SnmpAdminString or BITS would work.
+
+ There are many MIB modules that attempt to optimize the amount of
+ data sent/received in a SET/GET PDU by packing octet strings with
+ aggregate data. For example, the PortList syntax as defined in the
+ Q-BRIDGE-MIB (RFC 2674 [26]) is defined as follows:
+
+
+
+
+
+
+MacFaden, et al. Informational [Page 39]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ PortList ::= TEXTUAL-CONVENTION
+ STATUS current
+ DESCRIPTION
+ "Each octet within this value specifies a set of eight
+ ports, with the first octet specifying ports 1 through
+ 8, the second octet specifying ports 9 through 16, etc.
+ Within each octet, the most significant bit represents
+ the lowest numbered port, and the least significant bit
+ represents the highest numbered port. Thus, each port
+ of the bridge is represented by a single bit within the
+ value of this object. If that bit has a value of '1'
+ then that port is included in the set of ports; the port
+ is not included if its bit has a value of '0'."
+ SYNTAX OCTET STRING
+
+ This compact representation saves on data transfer but has some
+ limitations. Such complex instance information is difficult to
+ reference outside of the object or use as an index to a table.
+ Additionally, with this approach, if a value within the aggregate
+ requires change, the entire aggregated object instance must be
+ written.
+
+ Providing an SNMP table to represent aggregate data avoids the
+ limitations of encoding data into OCTET STRINGs and is thus the
+ better general practice.
+
+ Finally, as previously mentioned in Section 3.3.6.3, one should
+ consider the practical ramifications of instance transfer for object
+ types of SYNTAX OCTET STRING where they have typical instance data
+ requirements close to the upper boundary of SMIv2 OCTET STRING
+ instance encoding. Where such object types are truly necessary at
+ all, SNMP/UDP may not be a very scalable means of transfer and
+ alternatives should be explored.
+
+3.13.2. Supporting multiple instances of a MIB Module
+
+ When defining new MIB modules, one should consider if there could
+ ever be multiple instances of this MIB module in a single SNMP
+ entity.
+
+ MIB modules exist that assume a one to many relationship, such as
+ MIBs for routing protocols which can accommodate multiple "processes"
+ of the underlying protocol and its administrative framework.
+ However, the majority of MIB modules assume a one-to-one relationship
+ between the objects found in the MIB module and how many instances
+ will exist on a given SNMP agent. The OSPF-MIB, IP-MIB, BRIDGE-MIB
+ are all examples that are defined for a single instance of the
+ technology.
+
+
+
+MacFaden, et al. Informational [Page 40]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ It is clear that single instancing of these MIB modules limits
+ implementations that might support multiple instances of OSPF, IP
+ stacks or logical bridges.
+
+ In such cases, the ENTITY-MIB [RFC2737] can provide a means for
+ supporting the one-to-many relationship through naming scopes using
+ the entLogicalTable. Keep in mind, however, that there are some
+ drawbacks to this approach.
+
+ 1) One cannot issue a PDU request that spans naming scopes. For
+ example, given two instances of BRIDGE-MIB active in a single
+ agent, one PDU cannot contain a request for dot1dBaseNumPorts from
+ both the first and second instances.
+
+ 2) Reliance on this technique creates a dependency on the Entity MIB
+ for an application to be able to access multiple instances of
+ information.
+
+ Alternately, completely independently of the Entity MIB, multiple MIB
+ module instances can be scoped by different SNMP contexts. This
+ does, however, require the coordination of this technique with the
+ administrative establishment of contexts in the configured agent
+ system.
+
+3.13.3. Use of Special Optional Clauses
+
+ When defining integer-based objects for read-create, read-write and
+ read-only semantics, using the UNITS clause is recommended in
+ addition to specification in the DESCRIPTION clause of any particular
+ details of how UNITs are to be interpreted.
+
+ The REFERENCE clause is also recommended as a way to help an
+ implementer track down related information on a given object. By
+ adding a REFERENCE clause to the specific underlying technology
+ document, multiple separate implementations will be more likely to
+ interoperate.
+
+4. Implementing SNMP Configuration Agents
+
+4.1. Operational Consistency
+
+ Successful deployment of SNMP configuration systems depends on
+ understanding the roles of MIB module design and agent design.
+
+
+
+
+
+
+
+
+MacFaden, et al. Informational [Page 41]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ Both module and agent design need to be undertaken with an
+ understanding of how UDP/IP-based SNMP behaves. A current practice
+ in MIB design is to consider the idempotency of settable objects.
+ Idempotency basically means being able to invoke the same set
+ operation repeatedly but resulting in only a single activation.
+
+ Here is an example of the idempotency in action:
+
+Manager Agent
+-------- ------
+Set1 (Object A, Value B) ---> receives set OK and responds
+ X<-------- Response PDU(OK) is dropped by
+ network
+Manager times out
+and sends again
+Set2 (Object A, Value B) ---> receives set OK (does nothing),
+ responds
+ <-------- with a Response PDU(OK)
+Manager receives OK
+
+ Had object A been defined in a stateful way, the set operation might
+ have caused the Set2 operation to fail as a result of interaction
+ with Set1. If the agent implementation is not aware of such a
+ possible situation on the second request, the agent may behave poorly
+ by performing the set request again rather than doing nothing.
+
+ The example above shows that all of the software that runs on a
+ managed element and in managed applications should be designed in
+ concert when possible. Particular emphasis should be placed at the
+ logical boundaries of the management system components in order to
+ ensure correct operation.
+
+ 1. The first interface is between SNMP agents in managed devices and
+ the management applications themselves. The MIB document is a
+ contract between these two entities that defines expected behavior
+ - it is a type of API.
+
+ 2. The second interface is between the agent and the instrumented
+ subsystem. In some cases, the instrumented subsystem will require
+ modification to allow for the dynamic nature of SNMP-based
+ configuration, control and monitoring operations. Agent
+ implementors must also be sensitive to the operational code and
+ device in order to minimize the impact of management on the
+ primary subsystems.
+
+ Additionally, while the SNMP protocol-level and MIB module-level
+ modeling of configuration operations may be idempotent and stateless
+ from one set operation to another, it may not be that way in the
+
+
+
+MacFaden, et al. Informational [Page 42]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ underlying subsystem. It is possible that an agent may need to
+ manage this state in these subsystem architectures explicitly when it
+ has placed the underlying subsystem into an "intermediate" state at a
+ point in processing a series of SET PDUs. Alternatively, depending
+ on the underlying subsystem in question, the agent may be able to
+ buffer all of the configuration set operations prior to activating
+ them in the subsystem all at once (to accommodate the nature of the
+ subsystem).
+
+ As an example, it would be reasonable to define a MIB module to
+ control Virtual Private Network (VPN) forwarding, in which a
+ management station could set a set of ingress/egress IP addresses for
+ the VPN gateway. Perhaps the MIB module presumes that the level of
+ transactionality is the establishment of a single row in a table
+ defining the address of the ingress/egress gateway, along with some
+ prefix information to assist in routing at the VPN layer to that
+ gateway. However, it would be conceivable that in an underlying
+ Layer 2 VPN subsystem instrumentation, the requirement is that all
+ existing gateways for a VPN be deleted before a new one can be
+ defined--that, in other words, in order to add a new gateway, g(n),
+ to a VPN, gateways g(1)..g(n-1) need to be removed, and then all n
+ gateways reestablished with the VPN forwarding service. In this
+ case, one could imagine an agent which has some sort of timer to
+ establish a bounded window for receipt of SETs for new VPN gateways,
+ and to activate them in this removal-then-reestablishment of existing
+ and new gateways at the end of this window.
+
+4.2. Handling Multiple Managers
+
+ Devices are often modified by multiple management entities and with
+ different management techniques. It is sometimes the case that an
+ element is managed by different organizations such as when a device
+ sits between administrative domains.
+
+ There are a variety of approaches that management software can use to
+ ensure synchronization of information between the manager(s) and the
+ managed elements.
+
+ An agent should report configuration changes performed by different
+ entities. It should also distinguish configuration defined locally
+ such as a default or locally specified configuration made through an
+ alternate management interface such as a command line interface.
+ When a change has been made to the system via SNMP, CLI, or other
+ method, a managed element should send an notification to the
+ manager(s) configured as recipients of these applicable
+ notifications. These management applications should update their
+
+
+
+
+
+MacFaden, et al. Informational [Page 43]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ local configuration repositories and then take whatever additional
+ action is appropriate. This approach can also be an early warning of
+ undesired configuration changes.
+
+ Managers should also develop mechanisms to ensure that they are
+ synchronized with each other.
+
+4.3. Specifying Row Modifiability
+
+ Once a RowStatus value is active(1) for a given row, the management
+ application should be able to determine what the semantics are for
+ making additional changes to a row. The RMON MIB control table
+ objects spell out explicitly what managed objects in a row can and
+ cannot be changed once a given RowStatus goes active.
+
+ As described earlier, some operations take some time to complete.
+ Some systems also require that they remain in a particular state for
+ some period before moving to another. In some cases, a change to one
+ value may require re-initialization of the system. In all of these
+ cases, the DESCRIPTION clause should contain information about
+ requirements of the managed system and special restrictions that
+ managers should observe.
+
+4.4. Implementing Write-only Access Objects
+
+ The second version of the SNMP SMI dropped direct support for a
+ write-only object. It is therefore necessary to return something when
+ reading an object that you may have wished to have write-only
+ semantics. Such objects should have a DESCRIPTION clause that
+ details what the return values should be. However, regardless of the
+ approach, the value returned when reading the object instance should
+ be meaningful in the context of the object's semantics.
+
+5. Designing Configuration Management Software
+
+ In this section, we describe practices that should be used when
+ creating and deploying management software that configures one or
+ more systems using SNMP. Functions all configuration management
+ software should provide, regardless of the method used to convey
+ configuration information to the managed systems are backup, fail-
+ over, and restoration. A management system should have the following
+ features:
+
+ 1. A method for restoring a previous configuration to one or more
+ devices. Ideally this restoration should be time indexed so that
+ a network can be restored to a configured state as of a specific
+ time and date.
+
+
+
+
+MacFaden, et al. Informational [Page 44]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ 2. A method for saving back up versions of the configuration data in
+ case of hardware or software failure.
+
+ 3. A method of providing fail-over to a secondary (management) system
+ in case of a primary failure. This capability should be deployed
+ in such a way that it does not cause duplicate polling of
+ configuration.
+
+ These three capabilities are of course important for other types of
+ management that are not the focus of this BCP.
+
+5.1. Configuration Application Interactions with Managed Systems
+
+ From the point of view of the design of the management application,
+ there are three basic requirements to evaluate relevant to SNMP
+ protocol operations and configuration:
+
+ o Set and configuration activation operations
+
+ o Notifications from the device
+
+ o Data retrieval and collection
+
+ Depending on the requirements of the specific services being
+ configured, many other requirements may, and probably will, also be
+ present.
+
+ The design of the system should not assume that the objects in a
+ device that represent configuration data will remain unchanged over
+ time.
+
+ As standard MIB modules evolve and vendors add private extensions,
+ the specific configuration parameters for a given operation are
+ likely to change over time. Even in the case of a configuration
+ application that is designed for a single vendor, the management
+ application should allow for variability in the MIB objects that will
+ be used to configure the device for a particular purpose. The best
+ method to accomplish this is by separating, as much as possible, the
+ operational semantics of a configuration operation from the actual
+ data. One way that some applications achieve this is by having the
+ specific configuration objects that are associated with a particular
+ device be table driven rather than hard coded. Ideally, management
+ software should verify the support in the devices it is expected to
+ manage and report any unexpected deviations to the operator. This
+ approach is particularly valuable when developing applications that
+ are intended to support equipment or software from multiple vendors.
+
+
+
+
+
+MacFaden, et al. Informational [Page 45]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+5.1.1. SET Operations
+
+ Management software should be mindful of the environment in which SET
+ operations are being deployed. The intent here is to move
+ configuration information as efficiently as possible to the managed
+ device. There are many ways to achieve efficiency and some are
+ specific to given devices. One general case that all management
+ software should employ is to reduce the number of SET PDU exchanges
+ between the managed device and the management software to the
+ smallest reasonable number. One approach to this is to verify the
+ largest number of variable bindings that can fit into a SET PDU for a
+ managed device. In some cases, the number of variable bindings to be
+ sent in a particular PDU will be influenced by the device, the
+ specific MIB objects and other factors.
+
+ Maximizing the number of variable bindings in a SET PDU also has
+ benefits in the area of management application transaction
+ initiation, as we will discuss in the following section.
+
+ There are, though, agents that may have implementation limitations on
+ the number and order of varbinds they can handle in a single SET PDU.
+ In this case, sending fewer varbinds will be necessary.
+
+ As stated at the outset of this section, the management application
+ software designer must be sensitive to the design of the SNMP
+ software in the managed device. For example, the software in the
+ managed device may require that all that all related configuration
+ information for an operation be conveyed in a single PDU because it
+ has no concept of a transaction beyond a single SNMP PDU. Another
+ example has to do with the RowStatus textual convention. Some SNMP
+ agents implement a subset of the features available and as such the
+ management application must avoid using features that may not be
+ supported in a specific table implementation (such as createAndWait).
+
+5.1.2. Configuration Transactions
+
+ There are several types of configuration transactions that can be
+ supported by SNMP-based configuration applications. They include
+ transactions on a scalar object, transactions in a single table
+ (within and across row instances), transactions across several tables
+ in a managed device and transactions across many devices. The
+ manager's ability to support these different transactions is partly
+ dependent on the design of the MIB objects used in the configuration
+ operation.
+
+ To make use of any kind of transaction semantics effectively, SNMP
+ management software must be aware of the information in the MIB
+ modules that it is to configure so that it can effectively utilize
+
+
+
+MacFaden, et al. Informational [Page 46]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ RowStatus objects for the control of transactions on one or more
+ tables. Such software must also be aware of control tables that the
+ device supports that are used to control the status of one or more
+ other tables.
+
+ To the greatest extent possible, the management application should
+ provide the facility to support transactions across multiple devices.
+ This means that if a configuration operation is desired across
+ multiple devices, the manager can coordinate these configuration
+ operations such that they become active as close to simultaneously as
+ possible.
+
+ Several practical means are present in the SNMP model that support
+ management application level transactions. One was mentioned in the
+ preceding section, that transactions can be optimized by including
+ the maximum number of SET variable bindings possible in a single PDU
+ sent to the agent.
+
+ There is an important refinement to this. The set of read-create row
+ data objects for tables should be sent in a single PDU, and only
+ placed across multiple PDUs if absolutely necessary. The success of
+ these set operations should be verified through the response(s) to
+ the Set PDU or subsequent polling of the row data objects. The
+ applicable RowStatus object(s), may be set to active only after this
+ verification. This is the only tractable means of affording an
+ opportunity for per-row rollback, particularly when the configuration
+ change is across table row instances on multiple managed devices.
+
+ Finally, where a MIB module exposes the kind of helpful transaction
+ management object types that were discussed in Section 3.3.5, it is
+ clearly beneficial to the integrity of the management application's
+ capacity to handle transactions to make use of them.
+
+5.1.3. Tracking Configuration Changes
+
+ As previously described in Section 3.3.5 (Summary Objects and State
+ Tracking), agents should provide the capability for notifications to
+ be sent to their configured management systems whenever a
+ configuration operation is completed or is detected to have failed.
+ The management application must be prepared to accept these
+ notifications so that it knows the current configured state of the
+ devices under its control. Upon receipt of the notification, the
+ management application should use getBulk or getNext to retrieve the
+ configuration from the agent and store the relevant contents in the
+ management application database. The GetBulkRequest-PDU is useful
+ for this whenever supported by the managed device, since it is more
+ efficient than the GetNextRequest-PDU when retrieving large amounts
+
+
+
+
+MacFaden, et al. Informational [Page 47]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ of data. For the purposes of backward compatibility, the management
+ station should also support and make use of the GetNextRequest-PDU
+ when the agent does not support the GetBulkRequest-PDU.
+
+ Management systems should also provide configuration options with
+ defaults for users that tend to retrieve the smallest amount of data
+ to achieve the particular goal of the application, to avoid
+ unnecessary load on managed devices for the most common retrieval
+ operations.
+
+5.1.4. Scalability of Data Retrieval
+
+ The techniques for efficient data retrieval described in the
+ preceding sections comprise only one aspect of what application
+ developers should consider in this regard when developing
+ configuration applications. Management applications should provide
+ for distributed processing of the configuration operations. This
+ also extends to management functions that are not the focus of this
+ document. Techniques of distributed processing can also be used to
+ provide resilience in the case of network failures. An SNMP-based
+ configuration management system might be deployed in a distributed
+ fashion where three systems in different locations keep each other
+ synchronized. This synchronization can be accomplished without
+ additional polling of network devices through a variety of
+ techniques. In the case of a failure, a 'backup' system can take
+ over the configuration responsibilities from the failed manager
+ without having to re-synchronize with the managed elements since it
+ will already be up to date.
+
+6. Deployment and Security Issues
+
+ Now that we have considered the design of SNMP MIB data for
+ configuration, agent implementation of its access, and management
+ application issues in configuration using SNMP, we turn to a variety
+ of operational considerations which transcend all three areas.
+
+6.1. Basic assumptions about Configuration
+
+ The following basic assumptions are made about real world
+ configuration models.
+
+ 1) Operations must understand and must be trained in the operation of
+ a given technology. No configuration system can prevent an
+ untrained operator from causing outages due to misconfiguration.
+
+ 2) Systems undergoing configuration changes must be able to cope with
+ unexpected loss of communication at any time.
+
+
+
+
+MacFaden, et al. Informational [Page 48]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ During configuration operations, network elements must take
+ appropriate measures to leave the configuration in a
+ consistent/recognizable state by either rolling back to a
+ previously valid state or changing to a well-defined or default
+ state.
+
+ 3) Configuration exists on a scale from relatively unchanging to a
+ high volume, high rate of change. The former is often referred to
+ as "set and forget" to indicate that the configuration changes
+ quite infrequently. The latter, "near real-time change control"
+ implies a high frequency of configuration change. Design of
+ configuration management must take into account the rate and
+ volume of change expected in a given configuration subsystem.
+
+6.2. Secure Agent Considerations
+
+ Vendors should not ship a device with a community string 'public' or
+ 'private', and agents should not define default community strings
+ except when needed to bootstrap devices that do not have secondary
+ management interfaces. Defaults lead to security issues that have
+ been recognized and exploited. When using SNMPv1, supporting read-
+ only community strings is a common practice.
+
+ Version 3 of the SNMP represents the current standard for the
+ Internet Management Framework and is recommended for all network
+ management applications. In particular, SNMPv3 provides
+ authorization, authentication, and confidentiality protection and is
+ essential to meeting the security considerations for all management
+ of devices that support SNMP-based configuration.
+
+6.3. Authentication Notifications
+
+ The default state of RFC 1215 [17] Authentication notifications
+ should be off. One does not want to risk accidentally sending out
+ authentication failure information, which by itself could constitute
+ a security liability. Enabling authentication Notifications should
+ be done in the context of a management security scheme which
+ considers the proper recipients of this information.
+
+ There are other liabilities where authentication notifications are
+ generated without proper security infrastructure. When notifications
+ are sent in SNMPv1 trap PDUs, unsolicited packets to a device can
+ causes one or more trap PDUs to be created and sent to management
+ stations. If these traps flow on shared access media and links, the
+ community string from the trap may be gleaned and exploited to gain
+ access to the device. At the very least, this risk should be
+ mitigated by having the authentication trap PDU be conveyed with a
+
+
+
+
+MacFaden, et al. Informational [Page 49]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ community string which is only used for authentication traps from the
+ agent, and would be useless for access inbound to the agent to get at
+ other management data.
+
+ A further liability of authentication traps can be seen when they are
+ being generated in the face of a Denial Of Service (DOS) attack, in
+ the form of a flood of PDUs with invalid community strings, on the
+ agent system. If it is bad enough that the system is having to
+ respond to and recover from the invalid agent data accesses, but the
+ problem will be compounded if a separate Authentication notification
+ PDU is sent to each recipient on the management network.
+
+6.4. Sensitive Information Handling
+
+ Some MIB modules contain objects that may contain data for keys,
+ passwords and other such sensitive information and hence must be
+ protected from unauthorized access. MIB documents that are created
+ in the IETF must have a 'Security Considerations' section, which
+ details how sensitive information should be protected. Similarly,
+ MIB module designers who create MIB documents for private MIB objects
+ should include similar information so that users of the products
+ containing these objects can take appropriate precautions.
+
+ Even if a device does support DES, it should be noted that
+ configuration of keys for other protocols via SNMP Sets protected by
+ DES should not be allowed if the other keys are longer than the 56
+ bit DES keys protecting the SNMP transmission.
+
+ The DESCRIPTION clause for these object types and their Security
+ Considerations sections in the documents which define them should
+ make it clear how and why these specific objects are sensitive and
+ that a user should only make them accessible for encrypted SNMP
+ access. Vendors should also document sensitive objects in a similar
+ fashion.
+
+ Confidentiality is not a mandatory portion of the SNMPv3 management
+ framework [6].
+
+ Prior to SNMPv3, providing customized views of MIB module data was
+ difficult. This led to objects being defined such as the following
+ from [41].
+
+
+
+
+
+
+
+
+
+
+MacFaden, et al. Informational [Page 50]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ docsDevNmAccessEntry OBJECT-TYPE
+ SYNTAX DocsDevNmAccessEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "An entry describing access to SNMP objects by a
+ particular network management station. An entry in
+ this table is not readable unless the management station
+ has read-write permission (either implicit if the table
+ is empty, or explicit through an entry in this table.
+ Entries are ordered by docsDevNmAccessIndex. The first
+ matching entry (e.g., matching IP address and community
+ string) is used to derive access."
+ INDEX { docsDevNmAccessIndex }
+ ::= { docsDevNmAccessTable 1 }
+
+ New MIB modules should capitalize on existing security capabilities
+ of SNMPv3 Framework. One way they can do this is by indicating the
+ level of security appropriate to different object types. For
+ example, objects that change the configuration of the system might be
+ protected by using the authentication mechanisms in SNMPv3.
+ Specifically, it is useful to design MIB module object grouping with
+ considerations for VACM views definition, such that users can define
+ and properly scope what tables are visible to a given user and view.
+
+7. Policy-based Management
+
+ In some designs and implementations, a common practice used to move
+ large amounts of data involves using SNMP as a control channel in
+ combination with other protocols defined for transporting bulk data.
+ This approach is sub-optimal since it raises a number of security and
+ other concerns. Transferring large amounts of configuration data via
+ SNMP can be efficiently performed with several of the techniques
+ described earlier in this document. This policy section shows how
+ even greater efficiency can be achieved using a set of relatively new
+ design mechanisms. This section gives background and defines terms
+ that are relevant to this field and describes some deployment
+ approaches.
+
+7.1. What Is the Meaning of 'Policy-based'?
+
+ In the past few years of output from standards organizations and
+ networking vendor marketing departments, the term 'policy' has been
+ heavily used, touted, and contorted in meaning. The result is that
+ the true meaning of 'policy' is unclear without greater qualification
+ where it is used.
+
+ [42] gives the term 'policy' two explicit definitions:
+
+
+
+MacFaden, et al. Informational [Page 51]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ - A definite goal, course or method of action to guide and determine
+ present and future decisions. "Policies" are implemented or
+ executed within a particular context (such as policies defined
+ within a business unit).
+
+ - Policies as a set of rules to administer, manage, and control
+ access to network resources.
+
+ Note that these two views are not contradictory since individual
+ rules may be defined in support of business goals.
+
+ As it pertains to our discussion of the term 'policy-based
+ configuration', the meaning is significantly more specific. In this
+ context, we refer to a way of integrating data and the management
+ actions which use it in such a way that:
+
+ - there is the ability to specify "default" configuration data for a
+ number of instances of managed elements, where those instances can
+ be correlated in some data driven or algorithmic way. The engine
+ to do this correlation and activate instances from defaults may
+ reside in the agent or externally. Where the representation of
+ these defaults are in the MIB design itself, the object types
+ supporting this notion are referred to as "template objects".
+
+ - the activation of instance data derived from template object types
+ results from minimal activation directives from the management
+ application, once the instances of the template object types have
+ been established.
+
+ - somewhat independently, the architecture of the overall management
+ agent may accommodate the definition and evaluation of management
+ and configuration policies. The side-effects of the evaluation of
+ these policies typically include the activation of certain
+ configuration directives. Where management data design exposes
+ template object types, the policy-driven activation can (and
+ ideally, should) include the application of template object
+ instances to the analogous managed element instance-level values.
+
+ As it pertains to template object data, the underlying notions
+ implied here have been prevalent for some time in non-SNMP management
+ regimes. A common feature of many command line interfaces for
+ configuring routers is the specification of one or more access
+ control lists. These typically provide a set of IP prefixes, BGP
+ autonomous system numbers, or other such identifying constructs (see,
+ for example, [42]). Once these access control lists are assembled,
+ their application to various interfaces, routing processes, and the
+ like are specified typically in the configuration of what the access
+ control list is applied to. Consistent with the prior properties to
+
+
+
+MacFaden, et al. Informational [Page 52]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ define our use of policy-based configuration, a) the access list is
+ defined independent from its point of application, and b) its
+ application is independent of the access list definition. For
+ example, changing the application of an access list from one
+ interface to the other does not require a change in the access list
+ itself. The first point just mentioned suggests what is necessary
+ for template-based data organization. The second suggests its
+ application in a policy-based manner.
+
+ Let us now examine the motivation for such a system or subsystem
+ (perhaps bounded at the level of a 'template-enabled' MIB module,
+ given the above definition). Let us explore the importance of
+ policy-based techniques to configuration specifically.
+
+7.2. Organization of Data in an SNMP-Based Policy System
+
+ The number of configurable parameters and 'instances' such as
+ interfaces has increased as equipment has become larger and more
+ complex.
+
+ At the same time, there is a need to configure many of these systems
+ to operate in a coordinated fashion. This enables the delivery of
+ new specialized services that require this coordinated configuration.
+ Examples include delivery of virtual private networks and connections
+ that guarantee specific service levels.
+
+ The growth in size and complexity of configuration information has
+ significant implications for its organization as well as its
+ efficient transfer to the management agent. As an example, an agent
+ that implements the Bridge MIB [24] could be used to represent a
+ large VLAN with some 65,000 port entries. Configuring such a VLAN
+ would require the establishment of dot1dStpPortTable and
+ dot1DStaticTable entries for each such virtual port. Each table
+ entry would contain several parameters. A more efficient approach is
+ to provide default values for the creation of new entries that are
+ appropriate to the VLAN environment in our example. The local
+ management infrastructure should then iterate across the system
+ setting the default values to the selected ports as groups.
+
+ To date, this kind of large-scale configuration has been accomplished
+ with file transfer, by setting individual MIB objects, or with many
+ CLI commands. In each of these approaches the details for each
+ instance are contained in the file, CLI commands or MIB objects.
+ That is, they contain not only the value, and type of object, but
+ also the exact instance of the object to which to apply the value.
+ It is this property that tends to make configuration operations
+ explode as the number of instances (such as interfaces) grows. This
+ per-instance approach can work for a few machines configured by
+
+
+
+MacFaden, et al. Informational [Page 53]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ experts, but there is a need for a more scalable solution.
+ Template-based data organization and policy-based management
+ abstracts the details above the instance level, which means that
+ fewer SET requests are sent to a managed device.
+
+ Realization of such a policy-driven system requires agents that can
+ take defaults and apply them to instances based on a rule that
+ defines under what conditions the defaults (policy) are to be
+ applied. A policy-driven configuration system which is to be
+ scalable needs to expose a means of layering its application of
+ defaults at discrete ranges of granularity. The spectrum of that
+ granularity might have a starting hierarchy point to apply defaults
+ at the breadth of a network service.
+
+ Ultimately, such a layering ends up with features to support
+ instance-level object instance data within the running agent.
+
+ An example of this kind of layering is implicit in the principle of
+ operations of a SNMPCONF Policy-Based Management MIB [36] (PM-MIB)
+ implementation. However, other entity management systems have been
+ employing these kinds of techniques end-to-end for some time, in some
+ cases using SNMP, in some cases using other encodings and transfer
+ technologies. What the PM-MIB seeks to establish, in an environment
+ ideal for its deployment, is an adaptation between MIB module data
+ which was not designed using template object types, and the ability
+ to allow the PM-MIB agent engine to apply instances of that data as
+ though it were template-based.
+
+7.3. Information Related to Policy-based Configuration
+
+ In order for effective policy management to take place, a range of
+ information about the network elements is needed to avoid making poor
+ policy decisions. Even in those cases where policy-based
+ configuration is not in use, much of the information described in
+ this section can be useful input to the decision-making process about
+ what type of configuration operations to do.
+
+ For this discussion it is important to make distinctions between
+ distribution of policy to a system, activation of a policy in a
+ system, and changes/failures that take place during the time the
+ policy is expected to be active. For example, if an interface is
+ down that is included in a policy that is distributed, there may not
+ be an error since the policy may not be scheduled for activation
+ until a later time.
+
+ On the other hand, if a policy is distributed and applied to an
+ interface that should be operational and it is not, clearly this is a
+ problem, although it is not an error in the configuration policy
+
+
+
+MacFaden, et al. Informational [Page 54]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ itself. With this as background, here are some areas to consider
+ that are important to making good policy configuration decisions and
+ establishing when a policy has 'failed'.
+
+ o The operational state of network elements that are to be
+ configured.
+
+ Care should be taken to determine if the sub-components to be
+ configured are available for use. In some cases the elements may
+ not be available. The policy configuration software should
+ determine if this is a prerequisite to policy installation or if
+ the condition is even acceptable. This decision is separate from
+ the one to be made about policy activation. Installation is when
+ the policy is sent from the policy manager to the managed device
+ and activation is turning on the policy. In those cases where
+ policy is distributed when the sub-component such as an interface
+ or disk is not available, the managed system should send a
+ notification to the designated management station when the policy
+ is to become active or if the resource is still not available.
+
+ o The capabilities of the devices in the network.
+
+ A capability can be almost any unit of work a network element can
+ perform. These include routing protocols supported, Web server
+ and OS versions, queuing mechanisms supported on each interface
+ that can be used to support different qualities of service, and
+ many others. This information can be obtained from the
+ capabilities table of the Policy MIB module [36].
+
+ Historically, management applications have had to obtain this type
+ of information by issuing get requests for objects they might want
+ to use. This approach is far less efficient since it requires
+ many get requests and is more error prone since some instances
+ will not exist until configured. The new capabilities table is an
+ improvement on the current technique.
+
+ o The capacity of the devices to perform the desired work.
+
+ Capability is an ability to perform the desired work while a
+ capacity is a measure of how much of that capability the system
+ has. The policy configuration application should, wherever
+ possible, evaluate the capacity of the network element to perform
+ the work identified by the policy. In some systems it will not be
+ possible to obtain the capacity of the managed elements to perform
+ the desired work directly, even though it may be possible to
+ monitor the amount of work the element performs. In these cases,
+ the management application may benefit from pre-configured
+
+
+
+
+MacFaden, et al. Informational [Page 55]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ information about the capacity of different network elements so
+ that evaluations of the resources available can be done before
+ distributing new policies.
+
+ Utilization refers to how much capacity for a particular
+ capability has been consumed. For devices that have been under
+ policy configuration control for any period of time, a certain
+ percentage of the available capacity of the managed elements will
+ be used. Policies should not be distributed to systems that do
+ not have the resources to carry out the policy in a reasonable
+ period of time.
+
+7.4. Schedule and Time Issues
+
+ This section applies equally to systems that are not policy-based as
+ well as policy-based systems, since configuration operations often
+ need to be synchronized across time zones. Wherever possible, the
+ network elements should support time information using the standard
+ DateAndTime TC that includes local time zone information. Policy-
+ based management often requires more complex time expressions than
+ can be conveyed with the DateAndTime TC. See the Policy-Based
+ Management MIB document [36] for more information. Some deployed
+ systems do not store complex notions of local time and thus may not
+ be able to process policy directives properly that contain time zone
+ relevant data. For this reason, policy management applications
+ should have the ability to ascertain the time keeping abilities of
+ the managed system and make adjustments to the policy for those
+ systems that are time-zone challenged.
+
+7.5. Conflict Detection, Resolution and Error Reporting
+
+ Policies sent to a device may contain conflicting instructions.
+ Detection of such commands can occur at the device or management
+ level and may be resolved using any number of mechanisms (examples
+ are, last configuration set wins, or abort change). These unintended
+ conflicts should be reported. Conflicts can occur at different
+ levels in a chain of commands. Each 'layer' in policy management
+ system should be able to check for some errors and report them. This
+ is conceptually identical to programs raising an exception and
+ passing that information on to software that can do something
+ meaningful with it.
+
+ At the instance level, conflict detection has been performed in a
+ limited way for some time in software that realizes MIB objects at
+ this level of resolution. This detection is independent of policy.
+ The types of 'conflicts' usually checked for are resource
+ availability and validity of the set operations. In a policy enabled
+
+
+
+
+MacFaden, et al. Informational [Page 56]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ system, there are no additional requirements for this software
+ assuming that good error detection and reporting appropriate to this
+ level have already been implemented.
+
+7.5.1. Changes to Configuration Outside of the Policy System
+
+ It is essential to consider changes to configuration that are
+ initiated outside of the policy system. A goal of SNMP-based policy
+ management is to coexist with other kinds of management software that
+ have historically been instance based management. The best example
+ is the command line interface.
+
+ A notification should be sent whenever an out-of-policy control
+ change is made to an element that is under the control of policy.
+ This notification should include the policy that was affected, the
+ instance of the element that was changed and the object and value
+ that it was changed to.
+
+ Even for those systems that have no concept of policy control, the
+ ideas presented above make sense. That is, if SNMP co-exists with
+ other access methods such as a CLI, it is essential that the
+ management station remain synchronized with changes that might have
+ been made to the managed device using other methods. As a result,
+ the approach of sending a notification when another access method
+ makes a change is a good one. Of course this should be configurable
+ by the user.
+
+7.6. More about Notifications in a Policy System
+
+ Notifications can be useful in determining a failure of a policy as a
+ result of an error in the policy or element(s) under policy control.
+ As with all notifications, they should be defined and controlled in
+ such a way that they do not create a problem by sending more than are
+ helpful over a specific period of time. For example, if a policy is
+ controlling 1,000 interfaces and fails, one notification rather than
+ 1,000 may be the better approach. In addition, such notifications
+ should be defined to include as much information as possible to aid
+ in problem resolution.
+
+7.7. Using Policy to Move Less Configuration Data
+
+
+ One of the advantages of policy-based configuration with SNMP is that
+ many configuration operations can be conveyed with a small amount of
+ data. Changing a single configuration parameter for each of 100
+ interfaces on a system might require 100 CLI commands or 100 SNMP
+ variable bindings using conventional techniques.
+
+
+
+
+MacFaden, et al. Informational [Page 57]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ Using policy-based configuration with SNMP, a single SET PDU can be
+ sent with the policy information necessary to apply a configuration
+ change to 100 similar interfaces. This efficiency gain is the result
+ of eliminating the need to send the value for each instance to be
+ configured. The 'default' for each of the instances included in the
+ policy is sent, and the rule for selection of the instances that the
+ default is to be applied to can also be carried (see the Policy MIB
+ module [36]).
+
+ To extend the example above, assume that there are 10 parameters that
+ need to change. Using conventional techniques, there would now be
+ 1,000 variable bindings, one for each instance of each new value for
+ each interface. Using policy-based configuration with SNMP, it is
+ still likely that all the information can be conveyed in one SET PDU.
+ The only difference in this case is that there are ten parameters
+ sent that will be the 'template' used to create instances on the
+ managed interfaces.
+
+ This efficiency gain not only applies to SET operations, but also to
+ those management operations that require configuration information.
+ Since the policy is also held in the storage for cross-instance
+ defaults (for example, the pmPolicyTable in [36]), an entire data set
+ that potentially controls hundreds of rows of information can be
+ retrieved in a single GET request.
+
+ A policy-friendly data organization such as this is consistent and
+ integrates well with MIB module objects which support "summary"
+ activation and activation reporting, of the kind discussed in Section
+ 3.3.5.
+
+8. Example MIB Module With Template-based Data
+
+ This section defines a MIB module that controls the heating and air
+ conditioning system for a large building. It contains both
+ configuration and counter objects that allow operators to see how
+ much cooling or heating a particular configuration has consumed.
+ Objects that represent the configuration information at a "default"
+ level (as referenced above) are also included.
+
+ These tables, in combination with the application of the tables' row
+ instance data as templated 'defaults', will allow operators to
+ configure and monitor many rooms at once, change the configuration
+ parameters based on time of day, and make a number of other
+ sophisticated decisions based on the 'policy' implied by these
+ defaults and their application. For this reason, these configuration
+ controls have their instances specified from template object types.
+
+
+
+
+
+MacFaden, et al. Informational [Page 58]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ In our simplified Heating Ventilation and Air Conditioning (HVAC)
+ model we will create three tables based on a simple analysis. More
+ complicated systems will need more tables, but the principles will be
+ the same.
+
+Step 1: As with any other MIB module design, the first step
+ is to determine what objects are necessary for
+ configuration and control operations. The first table
+ to be created is a fairly traditional monitoring
+ table. It includes indices so that we will know what
+ rooms the counters and status objects are for. It
+ includes an object that is a RowPointer to a table
+ that contains configuration information. The objects
+ for the bldgHVACTable, our first table in the HVAC
+ MIB module are:
+
+Index objects that identify what floor and office we are
+managing:
+
+ bldgHVACFloor
+ bldgHVACOffice
+
+A single index reference to a table that 'glues' configuration
+information defaults with descriptive information:
+
+ bldgHVACCfgTemplate
+
+A set of objects that show status and units of
+work (bldgHVACCoolOrHeatMins) and standard per-row
+SnmpAdminString, StorageType, and RowStatus columnar
+objects:
+
+ bldgHVACFanSpeed
+ bldgHVACCurrentTemp
+ bldgHVACCoolOrHeatMins
+ bldgHVACDiscontinuityTime
+ bldgHVACOwner
+ bldgHVACStatus
+
+Step 2: A configuration description table. The purpose of this
+ table is to provide a unique string identifier for
+ templates. These may be driven by policies in a
+ network. If it were necessary to configure devices
+ to deliver a particular quality of service, the
+ index string of this table could be the name and the
+ description part, it could be a brief description of the
+ underlying motivation such as: "provides extra heat to
+ corner offices to counteract excessive exterior wind
+
+
+
+MacFaden, et al. Informational [Page 59]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ chill". Standard owner and status objects may also
+ be helpful and are included here. The row columnar
+ objects are:
+
+ bldgHVACCfgTemplateInfoIndex
+ bldgHVACCfgTemplateInfoID
+ bldgHVACCfgTemplateInfoDescr
+ bldgHVACCfgTemplateInfoOwner
+ bldgHVACCfgTemplateInfoStatus
+
+Notice that to this point we have provided no
+configuration information. That will be in the next
+table. Some readers may wonder why this table is not
+combined with the configuration template table described
+in the next step. In fact, they can be. The reason for
+having a separate table is that as systems become more
+complex, there may be more than one configuration table
+that points to these descriptions. Another reason for
+two tables is that this in not reproduced for every
+template and instance, which can save some additional
+data movement. Every designer will have to evaluate the
+tradeoffs between number of objects and data movement
+efficiency just as with other MIB modules.
+
+Step 3: The bldgHVACCfgTemplateTable contains the specific
+ configuration parameters that are pointed to by the
+ bldgHVACConfigPtr object. Note that many rows in the
+ bldgHVACTable can point to an entry in this table. It
+ is also possible for entries to be used by 1 or 0 rows
+ of the bldgHVACTable. It is the property of allowing
+ multiple rows (instances) in the bldgHVACTable to
+ point to a row in this table that can produce such
+ efficiency gains from policy-based management with
+ SNMP. Also notice that the configuration data is tied
+ directly to the counter data so that people can see
+ how configurations impact behavior.
+
+The objects in this table are all that are necessary
+for configuration and connection to the other tables as
+well as the usual SnmpAdminString, StorageType, and
+RowStatus objects:
+
+A simple index to the table:
+
+ bldgHVACCfgTemplateIndex
+
+The configuration objects:
+
+
+
+
+MacFaden, et al. Informational [Page 60]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ bldgHVACCfgTemplateDesiredTemp
+ bldgHVACCfgTemplateCoolOrHeat
+
+
+Administrative objects for SnmpAdminString and
+RowStatus:
+
+ bldgHVACCfgTemplateInfo
+ bldgHVACCfgTemplateOwner
+ bldgHVACCfgTemplateStorage
+ bldgHVACCfgTemplateStatus
+
+8.1. MIB Module Definition
+
+BLDG-HVAC-MIB DEFINITIONS ::= BEGIN
+IMPORTS
+ MODULE-IDENTITY, Counter32,
+ Gauge32, OBJECT-TYPE, Unsigned32, experimental
+ FROM SNMPv2-SMI
+ MODULE-COMPLIANCE, OBJECT-GROUP
+ FROM SNMPv2-CONF
+ TEXTUAL-CONVENTION,
+ TimeStamp, RowStatus, StorageType
+ FROM SNMPv2-TC
+ SnmpAdminString
+ FROM SNMP-FRAMEWORK-MIB;
+
+
+bldgHVACMIB MODULE-IDENTITY
+ LAST-UPDATED "200303270000Z"
+ ORGANIZATION "SNMPCONF working group
+ E-mail: snmpconf@snmp.com"
+ CONTACT-INFO
+ "Jon Saperia
+ Postal: JDS Consulting
+ 174 Chapman Street
+ Watertown, MA 02472
+ U.S.A.
+ Phone: +1 617 744 1079
+ E-mail: saperia@jdscons.com
+
+ Wayne Tackabury
+ Postal: Gold Wire Technology
+ 411 Waverley Oaks Rd.
+ Waltham, MA 02452
+ U.S.A.
+ Phone: +1 781 398 8800
+ E-mail: wayne@goldwiretech.com
+
+
+
+MacFaden, et al. Informational [Page 61]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ Michael MacFaden
+ Postal: Riverstone Networks
+ 5200 Great America Pkwy.
+ Santa Clara, CA 95054
+ U.S.A.
+ Phone: +1 408 878 6500
+ E-mail: mrm@riverstonenet.com
+
+ David Partain
+ Postal: Ericsson AB
+ P.O. Box 1248
+ SE-581 12 Linkoping
+ Sweden
+ E-mail: David.Partain@ericsson.com"
+ DESCRIPTION
+ "This example MIB module defines a set of management objects
+ for heating ventilation and air conditioning systems. It
+ also includes objects that can be used to create policies
+ that are applied to rooms. This eliminates the need to send
+ per-instance configuration commands to the system.
+
+ Copyright (C) The Internet Society (2003). This version of
+ this MIB module is part of RFC 3512; see the RFC itself for
+ full legal notices."
+
+ REVISION "200303270000Z"
+ DESCRIPTION
+ "Initial version of BLDG-HVAC-MIB as published in RFC 3512."
+ ::= { experimental 122 }
+
+bldgHVACObjects OBJECT IDENTIFIER ::= { bldgHVACMIB 1 }
+bldgConformance OBJECT IDENTIFIER ::= { bldgHVACMIB 2 }
+
+--
+-- Textual Conventions
+--
+
+BldgHvacOperation ::= TEXTUAL-CONVENTION
+ STATUS current
+ DESCRIPTION
+ "Operations supported by a heating and cooling system.
+ A reference to underlying general systems would go here."
+ SYNTAX INTEGER {
+ heat(1),
+ cool(2)
+ }
+--
+-- HVAC Objects Group
+
+
+
+MacFaden, et al. Informational [Page 62]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+--
+
+bldgHVACTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF BldgHVACEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "This table is the representation and data control
+ for building HVAC by each individual office.
+ The table has rows for, and is indexed by a specific
+ floor and office number. Each such row includes
+ HVAC statistical and current status information for
+ the associated office. The row also contains a
+ bldgHVACCfgTemplate columnar object that relates the
+ bldgHVACTable row to a row in the bldgHVACCfgTemplateTable.
+ If this value is nonzero, then the instance in the row
+ that has a value for how the HVAC has been configured
+ in the associated template (bldgHVACCfgTeplateTable row).
+ Hence, the bldgHVACCfgTeplateTable row contains the
+ specific configuration values for the offices as described
+ in this table."
+ ::= { bldgHVACObjects 1 }
+
+bldgHVACEntry OBJECT-TYPE
+ SYNTAX BldgHVACEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "A row in the bldgHVACTable. Each row represents a particular
+ office in the building, qualified by its floor and office
+ number. A given row instance can be created or deleted by
+ set operations upon its bldgHVACStatus columnar
+ object instance."
+ INDEX { bldgHVACFloor, bldgHVACOffice }
+ ::= { bldgHVACTable 1 }
+
+BldgHVACEntry ::= SEQUENCE {
+ bldgHVACFloor Unsigned32,
+ bldgHVACOffice Unsigned32,
+ bldgHVACCfgTemplate Unsigned32,
+ bldgHVACFanSpeed Gauge32,
+ bldgHVACCurrentTemp Gauge32,
+ bldgHVACCoolOrHeatMins Counter32,
+ bldgHVACDiscontinuityTime TimeStamp,
+ bldgHVACOwner SnmpAdminString,
+ bldgHVACStorageType StorageType,
+ bldgHVACStatus RowStatus
+ }
+
+
+
+MacFaden, et al. Informational [Page 63]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+bldgHVACFloor OBJECT-TYPE
+ SYNTAX Unsigned32 (1..1000)
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "This portion of the index indicates the floor of the
+ building. The ground floor is considered the
+ first floor. For the purposes of this example,
+ floors under the ground floor cannot be
+ controlled using this MIB module."
+ ::= { bldgHVACEntry 1 }
+
+bldgHVACOffice OBJECT-TYPE
+ SYNTAX Unsigned32 (1..2147483647)
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "This second component of the index specifies the
+ office number."
+ ::= { bldgHVACEntry 2 }
+
+bldgHVACCfgTemplate OBJECT-TYPE
+ SYNTAX Unsigned32
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The index (bldgHVACCfgTemplateIndex instance)
+ of an entry in the 'bldgHVACCfgTemplateTable'.
+ The bldgHVACCfgTable row instance referenced
+ is a pre-made configuration 'template'
+ that represents the configuration described
+ by the bldgHVACCfgTemplateInfoDescr object. Note
+ that not all configurations will be under a
+ defined template. As a result, a row in this
+ bldgHVACTable may point to an entry in the
+ bldgHVACCfgTemplateTable that does not in turn
+ have a reference (bldgHVACCfgTemplateInfo) to an
+ entry in the bldgHVACCfgTemplateInfoTable. The
+ benefit of this approach is that all
+ configuration information is available in one
+ table whether all elements in the system are
+ derived from configured templates or not.
+
+ Where the instance value for this colunmar object
+ is zero, this row represents data for an office
+ whose HVAC status can be monitored using the
+ read-only columnar object instances of this
+ row, but is not under the configuration control
+
+
+
+MacFaden, et al. Informational [Page 64]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ of the agent."
+ ::= { bldgHVACEntry 3 }
+
+bldgHVACFanSpeed OBJECT-TYPE
+ SYNTAX Gauge32
+ UNITS "revolutions per minute"
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Shows the revolutions per minute of the fan. Fan speed
+ will vary based on the difference between
+ bldgHVACCfgTemplateDesiredTemp and bldgHVACCurrentTemp. The
+ speed is measured in revolutions of the fan blade per minute."
+ ::= { bldgHVACEntry 4 }
+
+bldgHVACCurrentTemp OBJECT-TYPE
+ SYNTAX Gauge32
+ UNITS "degrees in celsius"
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The current measured temperature in the office. Should
+ the current temperature be measured at a value of less
+ than zero degrees celsius, a read of the instance
+ for this object will return a value of zero."
+ ::= { bldgHVACEntry 5 }
+
+bldgHVACCoolOrHeatMins OBJECT-TYPE
+ SYNTAX Counter32
+ UNITS "minutes"
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The total number of heating or cooling minutes that have
+ been consumed since the row was activated. Notice that
+ whether the minutes represent heating or cooling is a
+ function of the configuration of this row. If the system
+ is re-initialized from a cooling to heating function or
+ vice versa, then the counter would start over again. This
+ effect is similar to a reconfiguration of some network
+ interface cards. When parameters that impact
+ configuration are changed, the subsystem must be
+ re-initialized. Discontinuities in the value of this counter
+ can occur at re-initialization of the management system,
+ and at other times as indicated by the value of
+ bldgHVACDiscontinuityTime."
+ ::= { bldgHVACEntry 6 }
+
+
+
+
+MacFaden, et al. Informational [Page 65]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+bldgHVACDiscontinuityTime OBJECT-TYPE
+ SYNTAX TimeStamp
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The value of sysUpTime on the most recent occasion at which
+ any heating or cooling operation for the office designated
+ by this row instance experienced a discontinuity. If
+ no such discontinuities have occurred since the last re-
+ initialization of the this row, then this object contains a
+ zero value."
+ ::= { bldgHVACEntry 7 }
+
+bldgHVACOwner OBJECT-TYPE
+ SYNTAX SnmpAdminString
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The identity of the operator/system that
+ last modified this entry. When a new entry
+ is created, a valid SnmpAdminString must
+ be supplied. If, on the other hand, this
+ entry is populated by the agent 'discovering'
+ unconfigured rooms, the empty string is a valid
+ value for this object."
+ ::= { bldgHVACEntry 8 }
+
+bldgHVACStorageType OBJECT-TYPE
+ SYNTAX StorageType
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The persistence of this row of the table in system storage,
+ as it pertains to permanence across system resets. A columnar
+ instance of this object with value 'permanent' need not allow
+ write-access to any of the columnar object instances in the
+ containing row."
+ ::= { bldgHVACEntry 9 }
+
+bldgHVACStatus OBJECT-TYPE
+ SYNTAX RowStatus
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "Controls and reflects the creation and activation status of
+ a row in this table.
+
+ No attempt to modify a row columnar object instance value in
+
+
+
+MacFaden, et al. Informational [Page 66]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ the bldgHVACTable should be issued while the value of
+ bldgHVACStatus is active(1). Should an agent receive a SET
+ PDU attempting such a modification in this state, an
+ inconsistentValue error should be returned as a result of
+ the SET attempt."
+ ::= { bldgHVACEntry 10 }
+--
+-- HVAC Configuration Template Table
+--
+
+bldgHVACCfgTemplateInfoTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF BldgHVACCfgTemplateInfoEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "This table provides unique string identification for
+ HVAC templates in a network. If it were necessary to
+ configure rooms to deliver a particular quality of climate
+ control with regard to cooling or heating, the index string
+ of a row in this table could be the template name.
+ The bldgHVACCfgCfgTemplateInfoDescription
+ contains a brief description of the template service objective
+ such as: provides summer cooling settings for executive
+ offices. The bldgHVACCfgTemplateInfo in the
+ bldgHVACCfgTemplateTable will contain the pointer to the
+ relevant row in this table if it is intended that items
+ that point to a row in the bldgHVACCfgTemplateInfoTable be
+ identifiable as being under template control though this
+ mechanism."
+
+ ::= { bldgHVACObjects 2 }
+
+bldgHVACCfgTemplateInfoEntry OBJECT-TYPE
+ SYNTAX BldgHVACCfgTemplateInfoEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "Each row represents a particular template and
+ description. A given row instance can be created or
+ deleted by set operations upon its
+ bldgHVACCfgTemplateInfoStatus columnar object
+ instance."
+ INDEX { bldgHVACCfgTemplateInfoIndex }
+ ::= { bldgHVACCfgTemplateInfoTable 1 }
+
+BldgHVACCfgTemplateInfoEntry ::= SEQUENCE {
+ bldgHVACCfgTemplateInfoIndex Unsigned32,
+ bldgHVACCfgTemplateInfoID SnmpAdminString,
+
+
+
+MacFaden, et al. Informational [Page 67]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ bldgHVACCfgTemplateInfoDescr SnmpAdminString,
+ bldgHVACCfgTemplateInfoOwner SnmpAdminString,
+ bldgHVACCfgTemplateInfoStatus RowStatus,
+ bldgHVACCfgTemplateInfoStorType StorageType
+ }
+
+bldgHVACCfgTemplateInfoIndex OBJECT-TYPE
+ SYNTAX Unsigned32 (1..2147483647)
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The unique index to a row in this table."
+ ::= { bldgHVACCfgTemplateInfoEntry 1 }
+
+bldgHVACCfgTemplateInfoID OBJECT-TYPE
+ SYNTAX SnmpAdminString
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "Textual identifier for this table row, and, consequently
+ the template. This should be a unique name within
+ an administrative domain for a particular template so that
+ all systems in a network that are under the same template
+ can have the same 'handle' (e.g., 'Executive Offices',
+ 'Lobby Areas')."
+ ::= { bldgHVACCfgTemplateInfoEntry 2 }
+
+
+bldgHVACCfgTemplateInfoDescr OBJECT-TYPE
+ SYNTAX SnmpAdminString
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "A general description of the template. One example might
+ be - Controls the cooling for offices on higher floors
+ during the summer."
+ ::= { bldgHVACCfgTemplateInfoEntry 3 }
+
+bldgHVACCfgTemplateInfoOwner OBJECT-TYPE
+ SYNTAX SnmpAdminString
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The identity of the operator/system that last modified
+ this entry."
+ ::= { bldgHVACCfgTemplateInfoEntry 4 }
+
+bldgHVACCfgTemplateInfoStatus OBJECT-TYPE
+
+
+
+MacFaden, et al. Informational [Page 68]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ SYNTAX RowStatus
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The activation status of this row.
+
+ No attempt to modify a row columnar object instance value in
+ the bldgHVACCfgTemplateInfo Table should be issued while the
+ value of bldgHVACCfgTemplateInfoStatus is active(1).
+ Should an agent receive a SET PDU attempting such a modification
+ in this state, an inconsistentValue error should be returned as
+ a result of the SET attempt."
+ ::= { bldgHVACCfgTemplateInfoEntry 5 }
+
+bldgHVACCfgTemplateInfoStorType OBJECT-TYPE
+ SYNTAX StorageType
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The persistence of this row of the table in system storage,
+ as it pertains to permanence across system resets. A columnar
+ instance of this object with value 'permanent' need not allow
+ write-access to any of the columnar object instances in the
+ containing row."
+ ::= { bldgHVACCfgTemplateInfoEntry 6 }
+
+--
+-- HVAC Configuration Template Table
+--
+bldgHVACCfgTemplateTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF BldgHVACCfgTemplateEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "This table contains the templates, which
+ can be used to set defaults that will
+ be applied to specific offices. The application
+ of those values is accomplished by having a row
+ instance of the bldgHVACTable reference a row of
+ this table (by the value of the former's
+ bldgHVACCfgTemplate columnar instance). Identifying
+ information concerning a row instance of this table
+ can be found in the columnar data of the row instance
+ of the bldgHVACCfgTemplateInfoTable entry referenced
+ by the bldgHVACCfgTemplateInfo columnar object of
+ this table."
+ ::= { bldgHVACObjects 3 }
+
+
+
+
+MacFaden, et al. Informational [Page 69]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+bldgHVACCfgTemplateEntry OBJECT-TYPE
+ SYNTAX BldgHVACCfgTemplateEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "Each row represents a single set of template parameters
+ that can be applied to selected instances - in this case
+ offices. These policies will be turned on and off by the
+ policy module through its scheduling facilities.
+
+ A given row instance can be created or
+ deleted by set operations upon its
+ bldgHVACCfgTemplateStatus columnar object instance."
+ INDEX { bldgHVACCfgTemplateIndex }
+ ::= { bldgHVACCfgTemplateTable 1 }
+
+BldgHVACCfgTemplateEntry ::= SEQUENCE {
+ bldgHVACCfgTemplateIndex Unsigned32,
+ bldgHVACCfgTemplateDesiredTemp Gauge32,
+ bldgHVACCfgTemplateCoolOrHeat BldgHvacOperation,
+ bldgHVACCfgTemplateInfo Unsigned32,
+ bldgHVACCfgTemplateOwner SnmpAdminString,
+ bldgHVACCfgTemplateStorage StorageType,
+ bldgHVACCfgTemplateStatus RowStatus
+}
+
+bldgHVACCfgTemplateIndex OBJECT-TYPE
+ SYNTAX Unsigned32 (1..2147483647)
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "A unique value for each defined template in this
+ table. This value can be referenced as a row index
+ by any MIB module that needs access to this information.
+ The bldgHVACCfgTemplate will point to entries in this
+ table."
+ ::= { bldgHVACCfgTemplateEntry 1 }
+
+bldgHVACCfgTemplateDesiredTemp OBJECT-TYPE
+ SYNTAX Gauge32
+ UNITS "degrees in celsius"
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "This is the desired temperature setting. It might be
+ changed at different times of the day or based on
+ seasonal conditions. It is permitted to change this value
+ by first moving the row to an inactive state, making the
+
+
+
+MacFaden, et al. Informational [Page 70]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ change and then reactivating the row."
+ ::= { bldgHVACCfgTemplateEntry 2 }
+
+bldgHVACCfgTemplateCoolOrHeat OBJECT-TYPE
+ SYNTAX BldgHvacOperation
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "This controls the heating and cooling mechanism and is
+ set-able by building maintenance. It is permitted to
+ change this value by first moving the row to an inactive
+ state, making the change and then reactivating the row."
+ ::= { bldgHVACCfgTemplateEntry 3 }
+
+bldgHVACCfgTemplateInfo OBJECT-TYPE
+ SYNTAX Unsigned32
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "This object points to a row in the
+ bldgHVACCfgTemplateInfoTable. This controls the
+ heating and cooling mechanism and is set-able by
+ building maintenance. It is permissible to change
+ this value by first moving the row to an inactive
+ state, making the change and then reactivating
+ the row. A value of zero means that this entry
+ is not associated with a named template found
+ in the bldgHVACCfgTemplateInfoTable."
+ ::= { bldgHVACCfgTemplateEntry 4 }
+
+bldgHVACCfgTemplateOwner OBJECT-TYPE
+ SYNTAX SnmpAdminString
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The identity of the administrative entity
+ that created this row of the table."
+ ::= { bldgHVACCfgTemplateEntry 5 }
+
+bldgHVACCfgTemplateStorage OBJECT-TYPE
+ SYNTAX StorageType
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The persistence of this row of the table across
+ system resets. A columnar instance of this object with
+ value 'permanent' need not allow write-access to any
+ of the columnar object instances in the containing row."
+
+
+
+MacFaden, et al. Informational [Page 71]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ ::= { bldgHVACCfgTemplateEntry 6 }
+
+bldgHVACCfgTemplateStatus OBJECT-TYPE
+ SYNTAX RowStatus
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The activation status of this row of the table.
+
+ No attempt to modify a row columnar object instance value in
+ the bldgHVACCfgTemplateTable should be issued while the
+ value of bldgHVACCfgTemplateStatus is active(1).
+ Should an agent receive a SET PDU attempting such a modification
+ in this state, an inconsistentValue error should be returned as
+ a result of the SET attempt."
+ ::= { bldgHVACCfgTemplateEntry 7 }
+
+--
+-- Conformance Information
+--
+
+bldgCompliances OBJECT IDENTIFIER ::= { bldgConformance 1 }
+bldgGroups OBJECT IDENTIFIER ::= { bldgConformance 2 }
+
+-- Compliance Statements
+
+bldgCompliance MODULE-COMPLIANCE
+ STATUS current
+ DESCRIPTION
+ "The requirements for conformance to the BLDG-HVAC-MIB. The
+ bldgHVACObjects group must be implemented to conform to the
+ BLDG-HVAC-MIB."
+ MODULE -- this module
+
+ GROUP bldgHVACObjectsGroup
+ DESCRIPTION
+ "The bldgHVACObjects is mandatory for all systems that
+ support HVAC systems."
+ ::= { bldgCompliances 1 }
+
+bldgHVACObjectsGroup OBJECT-GROUP
+ OBJECTS {
+ bldgHVACCfgTemplate,
+ bldgHVACFanSpeed, bldgHVACCurrentTemp,
+ bldgHVACCoolOrHeatMins, bldgHVACDiscontinuityTime,
+ bldgHVACOwner, bldgHVACStatus,
+ bldgHVACStorageType, bldgHVACCfgTemplateInfoID,
+ bldgHVACCfgTemplateInfoDescr, bldgHVACCfgTemplateInfoOwner,
+
+
+
+MacFaden, et al. Informational [Page 72]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ bldgHVACCfgTemplateInfoStatus,
+ bldgHVACCfgTemplateInfoStorType,
+ bldgHVACCfgTemplateDesiredTemp,
+ bldgHVACCfgTemplateCoolOrHeat,
+ bldgHVACCfgTemplateInfo,
+ bldgHVACCfgTemplateOwner,bldgHVACCfgTemplateStorage,
+ bldgHVACCfgTemplateStatus
+ }
+ STATUS current
+ DESCRIPTION
+ "The bldgHVACObjects Group."
+ ::= { bldgGroups 1 }
+
+END
+
+8.2. Notes on MIB Module with Template-based Data
+
+ The primary purpose of the example "HVAC" MIB module is to show how
+ to construct a single module that includes configuration, template,
+ counter and state information in a single module. If this were a
+ 'real' module we would also have included definitions for
+ notifications for the configuration change operations as previously
+ described. We also would have included notifications for faults and
+ other counter threshold events.
+
+ Implementation and Instance Extensions:
+
+ Just as with networking technologies, vendors may wish to add
+ extensions that can distinguish their products from the competition.
+ If an HVAC vendor also wanted to support humidity control, they could
+ add that facility to their equipment and use AUGMENTS for the
+ bldgHVACTemplateTable with two objects, one that indicates the
+ desired humidity and the other, the actual. The
+ bldgHVACTemplateTable could also be extended using this same approach
+ so that HVAC policies could easily be extended to support this
+ vendor.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+MacFaden, et al. Informational [Page 73]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+8.3. Examples of Usage of the MIB
+
+ The following two examples use two templates to configure the
+ temperature in executive offices and in conference rooms. The
+ "conference rooms" template is applied to all conference rooms (which
+ happen to be office 104 on each floor), and the "executive offices"
+ template is applied to executive offices.
+
+ If offices 24, 25, and 26 on the third floor are executive offices,
+ the values in the bldgHVACTable might be:
+
+ bldgHVACCfgTemplate.3.24 = 2
+ bldgHVACFanSpeed.3.24 = 2989
+ bldgHVACCurrentTemp.3.24 = 24
+ bldgHVACCoolOrHeatMins.3.24 = 123
+ bldgHVACDiscontinuityTime.3.24 = sysUpTime + 12h + 21m
+ bldgHVACOwner.3.24 = "policy engine"
+ bldgHVACStorageType.3.24 = nonVolatile(3)
+ bldgHVACStatus.3.24 = active(1)
+
+ bldgHVACCfgTemplate.3.25 = 2
+ bldgHVACFanSpeed.3.25 = 0
+ bldgHVACCurrentTemp.3.25 = 22
+ bldgHVACCoolOrHeatMins.3.25 = 298
+ bldgHVACDiscontinuityTime.3.25 = sysUpTime + 4h + 2m
+ bldgHVACOwner.3.25 = "policy engine"
+ bldgHVACStorageType.3.25 = nonVolatile(3)
+ bldgHVACStatus.3.25 = active(1)
+
+ bldgHVACCfgTemplate.3.26 = 2
+ bldgHVACFanSpeed.3.26 = 0
+ bldgHVACCurrentTemp.3.26 = 22
+ bldgHVACCoolOrHeatMins.3.26 = 982
+ bldgHVACOwner.3.26 = "policy engine"
+ bldgHVACStorageType.3.26 = nonVolatile(3)
+ bldgHVACStatus.3.26 = active(1)
+
+ The second entry in the bldgHVACCfgTemplateTable, to which all of the
+ above point, might have the following configuration:
+
+ bldgHVACCfgTemplateDesiredTemp.2 = 22
+ bldgHVACCfgTemplateCoolOrHeat.2 = cool(2)
+ bldgHVACCfgTemplateInfo.2 = 2
+ bldgHVACCfgTemplateOwner.2 = "Senior Executive assistant"
+ bldgHVACCfgTemplateStorage.2 = nonVolatile(3)
+ bldgHVACCfgTemplateStatus.2 = active(1)
+
+
+
+
+
+MacFaden, et al. Informational [Page 74]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ and the associated template information ("executive offices") might
+ be:
+
+ bldgHVACCfgTemplateInfoID.2 = "executive offices"
+ bldgHVACCfgTemplateInfoDescr.2 = "Controls temperature for executive
+ offices"
+ bldgHVACCfgTemplateInfoOwner.2 = "Senior Executive assistant"
+ bldgHVACCfgTemplateInfoStorType.2 = nonVolatile(3)
+ bldgHVACCfgTemplateInfoStatus.2 = active(1)
+
+ The policy engine can now associate instances of executive offices
+ with the template called "executive offices" and apply the values in
+ the second entry of the bldgHVACCfgTemplateTable to each of the
+ instances of the executive offices. This will then attempt to set
+ the temperature in executive offices to 22 degrees celsius.
+
+ It is also possible that there may be an office configured for a
+ particular temperature, but without using a template. For example,
+ office 28 on the third floor might look like this:
+
+ bldgHVACCfgTemplate.3.28 = 3
+ bldgHVACFanSpeed.3.28 = 50
+ bldgHVACCurrentTemp.3.28 = 26
+ bldgHVACCoolOrHeatMins.3.28 = 0
+ bldgHVACDiscontinuityTime.3.28 = 0
+ bldgHVACOwner.3.28 = "Executive with poor circulation"
+ bldgHVACStorageType.3.28 = nonVolatile(3)
+ bldgHVACStatus.3.28 = active(1)
+
+ The entry in the bldgHVACCfgTemplateTable (to which
+ bldgHVACCfgTemplate.3.28 points) might instead look like:
+
+ bldgHVACCfgTemplateDesiredTemp.3 = 28
+ bldgHVACCfgTemplateCoolOrHeat.3 = cool(2)
+ bldgHVACCfgTemplateInfo.3 = 0.0
+ bldgHVACCfgTemplateOwner.3 = "Executive with poor circulation"
+ bldgHVACCfgTemplateStorage.3 = nonVolatile(3)
+ bldgHVACCfgTemplateStatus.3 = active(1)
+
+ Note that this entry does not point to a template.
+
+ If the executive's circulation improves so that the temperature
+ should be aligned with other executive offices, this is accomplished
+ by changing the value of bldgHVACCfgTemplate.3.28 from
+ bldgHVACCfgTemplateInfoID.3 to bldgHVACCfgTemplateInfoID.2 (shown
+ above).
+
+
+
+
+
+MacFaden, et al. Informational [Page 75]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ Finally, there might be offices for which there is no configured
+ temperature but management applications can read the current
+ temperature, fan speed, and cooling or heating minutes from the
+ bldgHVACTable. In that case, the value of bldgHVACCfgTemplate will
+ be a zero index ("null"), as will the value of bldgHVACOwner.
+
+ bldgHVACCfgTemplate.4.2 = 0
+ bldgHVACFanSpeed.3.28 = 50
+ bldgHVACCurrentTemp.3.28 = 26
+ bldgHVACCoolOrHeatMins.3.28 = 0
+ bldgHVACDiscontinuityTime.3.28 = 0
+ bldgHVACOwner.3.28 = ""
+ bldgHVACStorageType.3.28 = nonVolatile(3)
+ bldgHVACStatus.3.28 = active(1)
+
+ As a second example, the conference rooms on several floors are
+ configured using the "conference rooms" template. When the values in
+ the bldgHVACTable pertaining to conference rooms are read, it might
+ look like:
+
+ bldgHVACCfgTemplate.12.104 = bldgHVACCfgTemplateDesiredTemp.1
+ bldgHVACFanSpeed.12.104 = 1423
+ bldgHVACCurrentTemp.12.104 = 21
+ bldgHVACCoolOrHeatMins.12.104 = 2193
+ bldgHVACDiscontinuityTime.12.104 = sysUpTime + 36h + 15m
+ bldgHVACOwner.12.104 = = "Bob the Conference Guy"
+ bldgHVACStorageType.12.104 = nonVolatile(3)
+ bldgHVACStatus.12.104 = active(1)
+
+ bldgHVACCfgTemplate.14.104 = bldgHVACCfgTemplateDesiredTemp.1
+ bldgHVACFanSpeed.14.104 = 1203
+ bldgHVACCurrentTemp.14.104 = 20
+ bldgHVACCoolOrHeatMins.14.104 = 293
+ bldgHVACDiscontinuityTime.14.104 = sysUpTime + 5h + 54m
+ bldgHVACOwner.14.104 = = "Bob the Conference Guy"
+ bldgHVACStorageType.14.104 = nonVolatile(3)
+ bldgHVACStatus.14.104 = active(1)
+
+ bldgHVACCfgTemplate.15.104 = bldgHVACCfgTemplateDesiredTemp.1
+ bldgHVACFanSpeed.15.104 = 12
+ bldgHVACCurrentTemp.15.104 = 19
+ bldgHVACCoolOrHeatMins.15.104 = 1123
+ bldgHVACDiscontinuityTime.15.103 = sysUpTime + 2d + 2h + 7m
+ bldgHVACOwner.15.104 = = "Bob the Conference Guy"
+ bldgHVACStorageType.15.104 = nonVolatile(3)
+ bldgHVACStatus.15.104 = active(1)
+
+
+
+
+
+MacFaden, et al. Informational [Page 76]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ The desired temperature and whether to heat or cool is configured in
+ the first entry of the bldgHVACCfgTemplateTable, which tries to set
+ the temperature to 19 degrees celsius in conference rooms:
+
+ bldgHVACCfgTemplateDesiredTemp.1 = 19
+ bldgHVACCfgTemplateCoolOrHeat.1 = cool(2)
+ bldgHVACCfgTemplateInfo.1 = bldgHVACCfgTemplateInfoID.1
+ bldgHVACCfgTemplateOwner.1 = "Bob the Conference Guy"
+ bldgHVACCfgTemplateStorage.1 = nonVolatile(3)
+ bldgHVACCfgTemplateStatus.1 = active(1)
+
+ The associated template information would then have:
+
+ bldgHVACCfgTemplateInfoID.1 = "conference rooms"
+ bldgHVACCfgTemplateInfoDescr.1 = "Controls temperature in conference
+ rooms" bldgHVACCfgTemplateInfoOwner.1 = "Bob the Conference Guy"
+ bldgHVACCfgTemplateInfoStorType.1 = nonVolatile(3)
+ bldgHVACCfgTemplateInfoStatus.1 = active(1)
+
+ The policy system can then apply this template (cool to 19 degrees
+ Celsius) to its notion of all of the conference rooms in the
+ building.
+
+9. Security Considerations
+
+ This document discusses practices and methods for using the SNMP for
+ management and distribution of configuration information for network
+ elements. Any effective use of the SNMP in this application must
+ concern itself with issues of authentication of the management
+ entities initiating configuration change and management, in addition
+ to the integrity of the configuration data itself. Other more subtle
+ considerations also exist.
+
+ To that end, the section of this document entitled "Deployment and
+ Security Issues" covers these security considerations to the extent
+ they affect the current practices described throughout this document.
+ In particular, in the subsection entitled "Secure Agent
+ Considerations", there is a recommendation for the usage of Version 3
+ of the SNMP, and its essential presumption as a foundation for other
+ practices described throughout. With the exception of a small number
+ of cases where a mention is made to the contrary to illustrate
+ techniques for coexistence with application entities dependent upon
+ earlier versions of the SNMP, that recommendation of usage of Version
+ 3 of the SNMP is reiterated here.
+
+
+
+
+
+
+
+MacFaden, et al. Informational [Page 77]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+10. Acknowledgments
+
+ This document was produced by the SNMPCONF Working Group. In
+ particular, the editors wish to thank:
+
+ Christopher Anderson
+ Andy Bierman
+ Greg Bruell
+ Dr Jeffrey Case
+ Chris Elliott
+ Joel Halpern
+ Pablo Halpern
+ Wes Hardaker
+ David Harrington
+ Harrie Hazewinkel
+ Thippanna Hongal
+ Bob Moore
+ David T. Perkins
+ Randy Presuhn
+ Dan Romascanu
+ Shawn Routhier
+ Steve Waldbusser
+ Bert Wijnen
+
+11. Normative References
+
+ [1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for
+ Describing Simple Network Management Protocol (SNMP) Management
+ Frameworks", STD 62, RFC 3411, December 2002.
+
+ [2] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of
+ Management Information Version 2 (SMIv2)", STD 58, RFC 2578,
+ April 1999.
+
+ [3] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual
+ Conventions for SMIv2", STD 58, RFC 2579, April 1999.
+
+ [4] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance
+ Statements for SMIv2", STD 58, RFC 2580, April 1999.
+
+ [5] Presuhn, R. (Ed.), "Transport Mappings for the Simple Network
+ Management Protocol (SNMPv2)", STD 62, RFC 3417, December 2002.
+
+ [6] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message
+ Processing and Dispatching for the Simple Network Management
+ Protocol (SNMP)", STD 62, RFC 3412, December 2002.
+
+
+
+
+
+MacFaden, et al. Informational [Page 78]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ [7] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM)
+ for version 3 of the Simple Network Management Protocol
+ (SNMPv3)", STD 62, RFC 3414, December 2002.
+
+ [8] Presuhn, R. (Ed.), "Version 2 of the Protocol Operations for the
+ Simple Network Management Protocol (SNMP)", STD 62, RFC 3416,
+ December 2002.
+
+ [9] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management
+ Protocol Applications", STD 62, RFC 3413, December 2002.
+
+ [10] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access
+ Control Model (VACM) for the Simple Network Management Protocol
+ (SNMP)", STD 62, RFC 3415, December 2002.
+
+ [11] Presuhn, R. (Ed.), "Management Information Base for the Simple
+ Network Management Protocol (SNMPv2)", STD 62, RFC 3418,
+ December 2002.
+
+ [12] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction
+ and Applicability Statements for Internet-Standard Management
+ Framework", RFC 3410, December 2002.
+
+ [13] Daniele, M., Haberman, B., Routhier, S. and J. Schoenwaelder,
+ "Textual Conventions for Internet Network Addresses", RFC 3291,
+ May 2002.
+
+ [14] McCloghrie, K. (Ed.), "SNMPv2 Management Information Base for
+ the Internet Protocol using SMIv2", RFC 2011, November 1996.
+
+12. Informative References
+
+ [15] Rose, M. and K. McCloghrie, "Structure and Identification of
+ Management Information for TCP/IP-based Internets", STD 16, RFC
+ 1155, May 1990.
+
+ [16] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16,
+ RFC 1212, March 1991.
+
+ [17] Rose, M., "A Convention for Defining Traps for use with the
+ SNMP", RFC 1215, March 1991.
+
+ [18] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple
+ Network Management Protocol", STD 15, RFC 1157, May 1990.
+
+ [19] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
+ "Introduction to Community-based SNMPv2", RFC 1901, January
+ 1996.
+
+
+
+MacFaden, et al. Informational [Page 79]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ [20] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB",
+ RFC 2863, June 2000.
+
+ [21] Brown, C. and F. Baker, "Management Information Base for Frame
+ Relay DTEs Using SMIv2", RFC 2115, September 1997.
+
+ [22] Baker, F. (Ed.), "Requirements for IP Version 4 Routers", RFC
+ 1812, June 1995.
+
+ [23] Hawkinson, J. and T. Bates, "Guidelines for Creation, Selection,
+ and Registration of an Autonomous System (AS)", BCP 6, RFC 1930,
+ March 1996.
+
+ [24] Decker, E., Langille, P., Rijsinghani, A. and K. McCloghrie,
+ "Definitions of Managed Objects for Bridges", RFC 1493, July
+ 1993.
+
+ [25] Levi, D. and J. Schoenwaelder "Definitions of Managed Objects
+ for Scheduling Management Operations", RFC 3231, January 2002.
+
+ [26] Bell, E., Smith, A., Langille, P., Rijsinghani, A. and K.
+ McCloghrie, "Definitions of Managed Objects for Bridges with
+ Traffic Classes, Multicast Filtering and Virtual LAN
+ Extensions", RFC 2674, August 1999.
+
+ [27] Baker, F., "IP Forwarding Table MIB", RFC 2096, January 1997.
+
+ [28] St. Johns, M. (Ed.), "Radio Frequency (RF) Interface Management
+ Information Base for MCNS/DOCSIS compliant RF interfaces", RFC
+ 2670, August 1999.
+
+ [29] Baker, F. and R. Coltun, "OSPF Version 2 Management Information
+ Base", RFC 1850, November 1995.
+
+ [30] Blake, S., Black, D., Carlson M., Davies, E., Wang, Z. and W.
+ Weiss, "An Architecture for Differentiated Services ", RFC 2475,
+ December 1998.
+
+ [31] Willis, S., Burruss, J. and J. Chu (Ed.), "Definitions of
+ Managed Objects for the Fourth Version of the Border Gateway
+ Protocol (BGP-4) using SMIv2", RFC 1657, July 1994.
+
+ [32] Waldbusser, S., "Remote Network Monitoring Management
+ Information Base", RFC 2819, May 2000.
+
+ [33] McCloghrie, K. and G. Hanson, "The Inverted Stack Table
+ Extension to the Interfaces Group MIB", RFC 2864, June 2000.
+
+
+
+
+MacFaden, et al. Informational [Page 80]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ [34] McCloghrie, K. and A. Bierman, "Entity MIB (Version 2)", RFC
+ 2737, December 1999.
+
+ [35] ITU-T,, Recommendation M.3010., PRINCIPLES FOR A
+ TELECOMMUNICATIONS MANAGEMENT NETWORK. February, 2000.
+
+ [36] Waldbusser, S., Saperia, J., and Hongal, T., "Policy Based
+ Management MIB", Work-in-progress.
+
+ [37] Heintz, L., "SNMP Row Operations Extensions", Work-in-progress.
+
+ [38] Zeltserman, D., "A Practical Guide to Snmpv3 and Network
+ Management", Prentice Hall, 1999.
+
+ [39] Noto, M., Spiegel, E. and K. Tesink, "Definitions of Textual
+ Conventions and OBJECT-IDENTITIES for ATM Management", RFC 2514,
+ February 1999.
+
+ [40] Kassaveri, R., Editor, "Distributed Management Expression MIB",
+ RFC 2982, October 2000.
+
+ [41] St. Johns, M., "DOCSIS Cable Device MIB Cable Device Management
+ Information Base for DOCSIS compliant Cable Modems and Cable
+ Modem Termination Systems", RFC 2669, August 1999.
+
+ [42] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M.,
+ Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S.
+ Waldbusser, "Terminology for Policy-Based Management", RFC 3198,
+ November 2001.
+
+ [43] http://wwww.cisco.com/univercd/cc/td/product/software/ios113ed/
+ 11ed_cr/secur_c/scprt/scacls.pdf.
+
+ [44] Waldbusser, S., "Remote Network Monitoring Management
+ Information Base Version 2 using SMIv2", RFC 2021, January 1997.
+
+13. Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; neither does it represent that it
+ has made any effort to identify any such rights. Information on the
+ IETF's procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication and any assurances of
+ licenses to be made available, or the result of an attempt made to
+
+
+
+MacFaden, et al. Informational [Page 81]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+ obtain a general license or permission for the use of such
+ proprietary rights by implementors or users of this specification can
+ be obtained from the IETF Secretariat.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+14. Editors' Addresses
+
+ Michael R. MacFaden
+ Riverstone Networks, Inc
+ 5200 Great America Parkway
+ Santa Clara, CA 95054
+
+ EMail: mrm@riverstonenet.com
+
+
+ David Partain
+ Ericsson AB
+ P.O. Box 1248
+ SE-581 12 Linkoping
+ Sweden
+
+ EMail: David.Partain@ericsson.com
+
+
+ Jon Saperia
+ JDS Consulting
+ 174 Chapman Street
+ Watertown, MA 02472
+
+ EMail: saperia@jdscons.com
+
+
+ Wayne F. Tackabury
+ Gold Wire Technology
+ 411 Waverley Oaks Rd.
+ Waltham, MA 02452
+
+ EMail: wayne@goldwiretech.com
+
+
+
+
+
+
+
+
+MacFaden, et al. Informational [Page 82]
+
+RFC 3512 Configuring Networks and Devices with SNMP April 2003
+
+
+15. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+MacFaden, et al. Informational [Page 83]
+