SNMPCONF Working Group M. MacFaden Category: Best Current Practice Riverstone Networks, Inc J. Saperia JDS Consulting, Inc W. Tackabury Gold Wire Technology, Inc Configuring Networks and Devices With SNMP draft-ietf-snmpconf-bcp-07.txt November 20, 2001 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference mate- rial or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document is for a variety of readers interested in the Internet Standard Management Framework, the Simple Network Management Protocol (SNMP). In particular, it offers guidance in the effective use of SNMP in configuration management. This information is relevant to vendors that build network elements, management application develop- ers, and those that acquire and deploy this technology in their Various Authors [Page 1] RFC DRAFT Expires May 2002 November 2001 networks. 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, here is a description of this internet standard management framework. The SNMP Management Framework presently consists of five major compo- nents: o An overall architecture, described in RFC 2571 [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 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in STD 58, RFC 2578 [5], STD 58, RFC 2579 [6] and STD 58, RFC 2580 [7]. 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 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906, RFC 2572 [11] and RFC 2574 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2573 [14] and the view-based access control mechanism described in RFC 2575 [15]. A more detailed introduction to the Various Authors [Page 2] RFC DRAFT Expires May 2002 November 2001 current SNMP Management Framework can be found in RFC 2570 [18]. 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. Consider a typical number and speed of interfaces in a modern core network element. For example, 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 a wide array of the network services which they are used to implement. Rate of Change - the nature of modern network services cause updates, adds, 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 a much more frequent change 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 per- formance and fault management systems. The Internet Standard Management Framework, SNMP, is used successfully to develop configuration management systems for a broad range of devices and networks. A standard configuration mechanism that tightly inte- grates with performance and fault systems is needed not only to help reduce the complexity of management, but to enable verification of con- figuration activities that create revenue-producing services. This document describes Best Current Practices that have been used when designing effective configuration management systems using the Internet Various Authors [Page 3] RFC DRAFT Expires May 2002 November 2001 Standard Management Framework (colloquially, SNMP). It covers many basic practices as well as more complex agent and manager design issues that are raised in configuration management. We are not endeavoring to pre- sent a comprehensive how-to document for generalized SNMP agent, MIB module, or management application design and development. We will, how- ever, cover points of generalized SNMP software design and implementa- tion 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 con- text 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 con- figuring 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 configu- ration management. Policy Based Configuration Management, is a methodol- ogy where configuration information 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 the number of states into which an element ostensibly transitions is minimized. The goal is that a change request is either completely executed or not at all. This is called transactional integrity. Transactional integrity makes it possible to develop 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 Various Authors [Page 4] RFC DRAFT Expires May 2002 November 2001 the SNMP protocol level is insufficient. 2.2. Practical Requirements for Transactional Control A well designed and deployed configuration system should have the fol- lowing 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 deliv- ered and installed on an element, or alternately one small attribute may be changed. In the latter case, very granular changes should invoke behavior according to the change being made. 2) The transaction control component should work at and understand a notion of the kind of multi-level "defaulting" as described in Sec- tion 7.1. The key point here is that it may make most sense to con- figure 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 sys- tem that contains a set of 'defaults' to be applied to instances that meet certain criteria. 3) An effective configuration management system must allow flexibil- ity 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 configura- tion 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. 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 pol- icy 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 Sec. 3.3. Transaction control considerations for the agent implementation are discussed in Various Authors [Page 5] RFC DRAFT Expires May 2002 November 2001 Sec. 5.2.2. 2.3. Best 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/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 crit- ical systems such as the domain name system (DNS). DNS software kits provide diagnostic tools that facilitate automatic test proce- dures/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 a post-mortem analysis on the effects of a single set. Networks and devices under SNMP configuration readily support this change management procedure since the SNMP provides integrated monitor- ing, configuration and diagnostic capabilities. The key is the sequenc- ing 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 configura- tion change can directly affect stability (convergence) of the network the device is connected to. An integrated view of configuration and monitoring provides an ideal platform from which to evaluate such changes. For example, the MIB mod- ule governing, IEEE 802.1D Spanning Tree (as specified in RFC 1493 [22]) provides the following object to monitor stability per logical bridge. Various Authors [Page 6] RFC DRAFT Expires May 2002 November 2001 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" [20], section 1.3.4: A vendor needs to provide adequate documentation on all configuration parameters, their limits and effects. Adherence to the above model is not fail safe, especially when configu- ration 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. Various Authors [Page 7] RFC DRAFT Expires May 2002 November 2001 In a network based example, convergence in an autonomous system cannot be guaranteed when configuration changes are made since there are fac- tors beyond 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 verifica- tion done to prevent mis-configuration such as in the following example. Consider a change made to ospfIfHelloInterval and ospfIfRtrDeadInterval [22] 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 impact on the production network. The important point to remember from this discussion is that configura- tion systems should be designed and implemented with verification tests in mind. 3. DESIGNING A MIB MODULE Well-considered MIB module designs are crucial for practical configura- tion with SNMP. As we have just seen, MIB objects designed for configu- ration can be very effective since they can be associated with inte- grated diagnostic, monitoring, and fault object types. 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 application of a template object activa- tion 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. 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 infor- mation 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 Various Authors [Page 8] RFC DRAFT Expires May 2002 November 2001 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 configura- tion 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 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: 1. Before MIB Module design, identify goals and objectives for the MIB module. How much of the underlying system will be exposed depends on goals set. 2. Minimizing the total number of objects is not explicit goal, but usability is. Be sure to consider deployment and usability requirements. 3. During configuration, consider supporting explicit error state, capability and capacity objects. 4. 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. Various Authors [Page 9] RFC DRAFT Expires May 2002 November 2001 3.2. Naming MIB modules and Managed Objects Naming of MIB modules and objects informally follows a set of best prac- tices. 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 iden- tifiers [5]) 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 configura- tion 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 [34] abbrevi- ations are combined with an organized OID assignment approach. For exam- ple a vendor could create a configuration branch in their private enter- prises area. In some cases this might be best done on a per product basis. Whichever approach is 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 configura- tion, causing a more efficient retrieval of data and a simpler manage- ment application with potentially better performance. 3.3. Transaction Control And State Tracking Transactions and keeping track of the state of them is an important con- sideration when performing any type of configuration activity regardless of the protocol. Here are a few areas to consider when designing trans- action 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 Various Authors [Page 10] RFC DRAFT Expires May 2002 November 2001 instances in a conceptual row in the MIB module is controlled. RowStatus is a standard textual convention for the management of concep- tual 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 coneptual rows of the table. When a table has been defined with a RowStatus object, moving 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 amount of 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 concep- tual row, a description must define what can be modified. In fact, it is often wrongly assumed in implementations that objects: 1) either must all be presently set or none need be to make a conceptual RowStatus object transition to active(1) 2) that objects in a conceptual row cannot be modified once a RowStatus object is active(1). Where this restriction exists on an object, it should be made clear in the DESCRIPTION clause as follows: 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 } Various Authors [Page 11] RFC DRAFT Expires May 2002 November 2001 3.3.2. Fate sharing with multiple tables An important principle associated with transaction control is fate shar- ing among rows between tables. Consider the case where a relationship has been specified between two conceptual tables of a MIB module (or, tables of 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 infor- mation 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 pos- sible using SMI macros such as 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 relation- ship should define what should happen when rows in related tables are added or deleted. 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? When two tables are related, 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 sys- tem we might create a single scalar object that when set to a particular value not only cause the activation of the rows in all the tables neces- sary. Here are some examples of further usage for such object types: Various Authors [Page 12] RFC DRAFT Expires May 2002 November 2001 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 Sec. 3.3.1) also has important relevance as a general transaction control object. 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 duration when not all of these required (and non-defaultable) columnar object instances have been set. Through- out this duration, 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. This is with the exception of the RowStatus object instance, whose retrieval should yield a notReady(3) value during this period. One need only be concerned with the notReady value return for a Various Authors [Page 13] RFC DRAFT Expires May 2002 November 2001 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 mod- ules 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 tech- niques that a MIB module designer can provide to assist in the (re-)syn- chronization 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. 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 (informs are preferable) to deliver configuration change. By providing an object containing the number of rows in a table, manage- ment 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 and application monitoring of such an object is not sufficient to determine 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 also 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 func- tion of time. An example is found in RFC 2790, Host Resources MIB: Various Authors [Page 14] RFC DRAFT Expires May 2002 November 2001 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 [33], provides the following object: .sp entLastChangeTime OBJECT-TYPE SYNTAX TimeStamp 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, RFC2863, [31] 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 } Various Authors [Page 15] RFC DRAFT Expires May 2002 November 2001 So, if an agent performs a row modification via an SNMP SET on ifAdmin- Status, the value of ifTableLastChange will not be updated. Be specific in what causes your 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 rela- tively 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 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 configu- ration. Vendors should recommend the use of informs over traps for NOTIFICATION-TYPE data since the agent can use this to help know whether it needs 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 columnar objects in a row of a table which have had any modification. 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 analyses 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 reason- ably. 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 con- figuration in each of the devices whose configuration they 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 periodi- cally poll the entire contents of these configuration tables for Various Authors [Page 16] RFC DRAFT Expires May 2002 November 2001 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 configura- tion 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 choices that can be used to assist with the syn- chronization of the configuration data found in the managed device with the manager 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 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: - The first is indexing based upon increasing INTEGER32 or Unsigned32 values, of the kind on might find in an array. - The second is associative indexing. This 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 get to a very large number of rows, using an associative indexing scheme offers a useful ability to efficiently retrieve only the rows of interest. For example, if an SNMP entity exposes a copy of the default-free Inter- net routing table as defined in the ipCidrRouteTable, it will presently Various Authors [Page 17] RFC DRAFT Expires May 2002 November 2001 contain around 100,000 rows. Associative indexing is used in ipCidrRouteTable 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 index- ing 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 destina- tion, 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 Page 41 ( the section on 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 [31] and the ifInvS- tackTable RFC 2864 [32]. They are logical equivalents with the order of the auxiliary (index) objects simply reversed. Various Authors [Page 18] RFC DRAFT Expires May 2002 November 2001 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 } 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, demonstrates a very useful tech- nique 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 use for command generators to encode the ifIndex into this simple inte- ger to provide associative lookup capability. The RMON hostTable and hostTimeTable represent dependent tables that contains the results indexed by the hostControlTable entry. The hostTable table is further indexed by the MAC address which provides the ability to reasonably search a collection such as the Organization- ally Unique Identifier (OUI) which is the first three octets of the MAC Various Authors [Page 19] RFC DRAFT Expires May 2002 November 2001 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 hostControlLastDelete- Time. 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 } 2) Time Based Indexing The TimeFilter as defined in RFC 2021 and used in RMON2-MIB and Q- BRIDGE-MIB (RFC2674) provide a way to obtain only those rows that have changed on or after some specified period of time has passed. 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 a standard getNext or getBulk data retrieval. 3) Divide the Work If the amount of data to transfer is larger than current SNMP design restrictions permit as in the case of OCTET STRINGS (64k less overhead of IP/UDP header plus SNMP header plus varbind list plus varbind encod- ing), 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 exist many enterprise MIB modules that provide control over the TFTP or FTP protocol. Often the SNMP part defines what to send where and then performs a set of an object to make the operation occur (for an example, refer to the CISCO-FTP-CLIENT-MIB, discussed in [37]). 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 Various Authors [Page 20] RFC DRAFT Expires May 2002 November 2001 of policy-based configuration (see [35], for example). Such an archi- tecture, 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 [36]. 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. The present section simply considers how to syntactically specify and semantically manage indices. 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. 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 iden- tifiers are unsigned long values, a question that arises is why not index from zero (0) instead of one(1)? RFC 2578, Section 7.7, page 28 states the following: Instances identi- fied 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 IPv6 textual convention MIB module [40]: Various Authors [Page 21] RFC DRAFT Expires May 2002 November 2001 Ipv6IfIndexOrZero ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "This textual convention is an extension of the Ipv6IfIndex convention. The latter defines a greater than zero value used to identify an IPv6 interface 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) Indexing tables from one(1) makes implementations consistent with exist- ing widely-practiced conventions. Reserving the value zero(0) for the purposes such as the one described above allows for consistent future expansion of sparse dependent tables. 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 IP-MIB. This limits the usefulness of the MIB module to IPv4. To avoid such limita- tions, use the INET-ADDRESS-MIB [41], 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 advi- sory 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. The maximum SIZE value to be used for an index in this application is generally not a limitation for practical purposes, since the InetAddress accmodates a maximum size DNS name. Most MIB module tables do not require this as an index. Various Authors [Page 22] RFC DRAFT Expires May 2002 November 2001 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 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. Various Authors [Page 23] RFC DRAFT Expires May 2002 November 2001 The dot1dStpPortEnable object type could have been written with more information about the behavior of this object when values of ifAdminSta- tus which impact it change. For example, text could be added that described proper returns for the dot1dStpPortEnable object instance for each of the possible values of ifAdminStatus. In those instances 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 consis- tent semantic for an oft-recurring datatype. MIB modules often define a binary state object such as enable/disable or on/off. Best current practice is to use existing Textual Conventions and define the read-write object in terms of a TruthValue from SNMPv2-TC [RFC2579]. For example, the Q-BRIDGE-MIB [RFC2674] 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 mod- ule to facilitate sharing of such object types. For example, all ATM MIB modules draw on the ATM-TC-MIB [38] to reference and utilize common definitions for addressing, service class values, and the like. To simplify management, it is recommended that existing SNMPv2-TC based definitions be used when possible. For example, consider the following object definition: Various Authors [Page 24] RFC DRAFT Expires May 2002 November 2001 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. AcmePatioLightsEnabledOn OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Current status of outdoor lighting. When set to true (1), this means that the lights are enabled and activated. When set to false (2), the lights are turned off and thus disabled." ::= { acmeOutDoorElectricalEntry 3 } 3.7. Persistent Configuration Many network devices have two levels of persistence with regard to con- figuration 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 proper- ties, 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 opera- tional 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 objects are required in order to get stan- dard configuration stored, thus making it difficult for a generic appli- cation to have a consistent effect. There are standard conventions for saving configuration data. The first method uses the Textual Convention known as StorageType [6] which Various Authors [Page 25] RFC DRAFT Expires May 2002 November 2001 explicitly defines a given row's persistence requirement. Examples include the RFC 2591 [23] 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 [15]. A second method for persistence simply uses the DESCRIPTION clause to define how instance data should persist. RFC 2674 [24] defines explic- itly 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 } Best current practice is a dual persistence model where one can make changes to run time configuration as well as to a non-volatile configu- ration read at device initialization. The DISMAN-SCHEDULE-MIB module [23] 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 gov- erned 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 schedCalendarGroup, write access must be also allowed to the columnar objects schedWeekDay, schedMonth, schedDay, schedHour, schedMinute." DEFVAL { volatile } ::= { schedEntry 19 } Various Authors [Page 26] RFC DRAFT Expires May 2002 November 2001 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 with configuration changes that are complex. This complexity can be in terms of configura- tion data or the operational ramifications of the activation of the changes in the managed subsystem. A practical technique to accomodate 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 activa- tion of configuration data in the managed subsystem. These controls play a pivotal role during the configuration process as well as during subse- quent 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 lia- bility, ideally a series of Set PDUs can install the configuration and a final set series of PDUs can activate the changes. During diagnostic situations, certain on/off switches can be set to localize the perceived error instead of having to remove the configura- tion. An example of such an object from the OSPF Version 2 MIB [27] 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 inter- face; 'disabled' disables it on all inter- faces." ::= { ospfGeneralGroup 2 } Various Authors [Page 27] RFC DRAFT Expires May 2002 November 2001 Elsewhere in the OSPF MIB, the semantics of setting ospfAdminStat to enabled(2) are clearly spelled out. The Scheduling MIB [23] exposes such an object on each entry in the scheduled actions table, along with the corresponding read status object on the entry status. In the following example, schedAdminStatus con- trols activation of the scheduled action, and schedAdminStatus 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, Various Authors [Page 28] RFC DRAFT Expires May 2002 November 2001 there is no guarantee that the agent won't discard the row while it is in the notInService(2) state. RFC 2579, page 15 states: 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 schedAd- minStatus 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 applica- tion. Consider the following object that both reports the current state as well as 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 } With the object defined, the following example represents one possible transaction. Time Command Generator --------> <--- Command Responder ----- ----------------- ----------------- | A GetPDU(wheelRotationState.1.1) Various Authors [Page 29] RFC DRAFT Expires May 2002 November 2001 | | 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 == spinCounterClockwise(3) V The response to the GET request at time E will often confuse management applications that assume the state of the object should be spinCounter- Clockwise(3). In reality, the wheel is slowing down in order to come to the idle state then begin spinning counter clockwise. One common practice is to separate out desired (settable) state from current state. The objects ifAdminStatus and ifOperStatus from RFC 2863 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 their directives can often be longer than the SNMP response timeout. Various Authors [Page 30] RFC DRAFT Expires May 2002 November 2001 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 in their values. This could be either a function of saving the changed value to a persistent storage type, and/or activating a subsys- tem that inherently has high latency as discussed above. When defining such MIB objects, it might be wise to have the agent respond to the set operation 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 com- pletion of the operation. Keep in mind that from a management software perspective (as presented in the example of schedAdminStatus in Sec. 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 [5], by the NOTIFICATION-TYPE macro. Notifications can be sent in either SNMPv2c [9] 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 InformRequest PDUs are responded to by the receiving entity with a REPORT PDU. This acknowledgement can be used to avoid unneccessary retransmission of NOTIFICATION-TYPE informa- tion. The use of InformRequest PDUs (as opposed to TRAPs) is not at the control of the MIB module designer or agent implementor. The determina- tion as to whether or not a TRAP or InformRequest PDU is sent from a SNMPv3 agent is generally a function of the agent's local configuration. To the extent notification timeout and retry values are determined by local configuration parameters, care should be taken to avoid unneces- sary retransmission of InformRequest PDUs. Configuration change and error information conveyed in InformRequest PDUs can be an important part of an effective SNMP-based management sys- tem. They have the potential to be overused. This section offers some guidance for effective definition of NOTIFICATION-TYPE information about Various Authors [Page 31] RFC DRAFT Expires May 2002 November 2001 configuration changes that can be carried in InformRequest PDUs. Noti- fications 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 must be designed in as shown in the section on 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 configura- tion change. Specifically, if the entity is known to be a SNMP command generator, the transport address and SNMP context 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 With SNMPv2c and SNMPv3, informs allow the design of event-driven syn- chronization models essential to configuration management. Their proper usage allows the manager's view of the managed element's configuration to be in close synchronization with the actual state of that configura- tion on the managed element. When designing new NOTIFICATION-TYPES, consider how to limit the number of InformRequests that will be sent with the notification information defined in the NOTIFCATION-TYPE in response to a configuration change or error event. INFORM PDUs, as opposed to TRAP PDUs, have an inherent advantage when the concern is the reduction of unneccessary messages from the system generating the NOTIFICATION-TYPE data. That is, an InformRequest PDU is acknowledged by the receiving entity with a Response PDU. The receipt of this response closes the loop, meaning that the entity which generated the InformRequest PDU has verification that the message was received. One way to limit the unnecessary generation of TRAP or InformRequest PDUs 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 [19]. Various Authors [Page 32] RFC DRAFT Expires May 2002 November 2001 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 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 NOTIFICA- TION-TYPE DESCRIPTION clause could provide a fixed limit on the number of messages sent over the duration of the condition leading to the rais- ing of the NOTIFICATION. If NOTIFICATION-TYPE transmission is "aggregated" in a 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 ele- ment transitions which brought about the notification. No matter which threshold is chosen to govern the 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 fil- tering of notifications. In the past, agents did not have a standard means to configure a notifi- cation generator. With the availability of the SNMP-NOTIFICATION-MIB Module in RFC 2573, it is strongly recommended that the filtering func- tions of this MIB module be used. This MIB facilitates the mapping of given NOTIFICATION-TYPEs and their intended recipients. If the mechanisms of this MIB module tables are not suitable for this Various Authors [Page 33] RFC DRAFT Expires May 2002 November 2001 application, then a justification of why it is not necessary or suitable should be made clear in the MIB module 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 report- ing 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 is generally not enough information as to why a agent rejected a set request. Typically, there is an incumbent and sizable burden on the configuration application to determine if the con- figuration 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 detail on the error to report on. A badValue does not necessarily mean the command generator sent bad data. An agent could be at fault. Additional detailed diagnostic infor- mation may aid in diagnosing conditions in the integrated system. Consider the requirements to convey error information about a MIB expression 'object' set within the DISMAN-EXPRESSION-MIB [39], at the time such an expression is evaluated. Clearly, no protocol error is relevant or useful in the set of any of the columnar object instances of the expExpressionTable at the time of the expression creation. Instead, the expErrorTable is defined to maintain entries on per- evalu- ate-time errors encountered: 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 Various Authors [Page 34] RFC DRAFT Expires May 2002 November 2001 object types in configuration tables that contain error information par- ticular to errors that occur on row activation. Notifications can also be used to signal configuration failures with detailed failure information objects. If this approach is used, the con- figuration 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, it is most likely that a known configuration data source will be the most useful recipient of the NOTIFICATION-TYPE data. 3.12. Designing MIB Modules for Multiple Managers When designing a MIB Module for configuration, there are several perti- nent 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 [6] defines TestAndIncr, often called a spinlock, which is used to avoid race conditions. 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 SNMPv2 entities, all acting in a manager role, to coordinate their use of the SNMPv2 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 snmpTargetSpinLock. Second, an agent should be able to report configuration as set by dif- ferent entities as distinguishable from configuration defined external Various Authors [Page 35] RFC DRAFT Expires May 2002 November 2001 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 NOTIFI- CATION-TYPEs. The OwnerString textual convention from RMON-MIB RFC 2819 [30] has been used successfully for this purpose. More recently, RFC 2271 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 owner- ship 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. Third, consider whether there is a need for multiple managers to config- ure 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 per manager. RFC 2591, 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 configura- tion tables and act appropriately to set them. Additionally, the agent must be configured to provide the appropriate instance-level restric- tions on the modifiability of the instances. 3.13. Other MIB Module Design Issues 3.13.1. Octet String Aggregations The OCTET STRING syntax affords the use of 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[5]. 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 1907 SNMPv2-MIB [16]. Various Authors [Page 36] RFC DRAFT Expires May 2002 November 2001 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 } These 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 Snm- pAdminString 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) is defined as follows: 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 limita- tions. Such complex instance information is difficult to reference out- side of the object or use as an indesx to a table. Additionally, with this approach, if a value within the aggregate requires change, the entire aggregated object instance must be reset. Various Authors [Page 37] RFC DRAFT Expires May 2002 November 2001 Providing a SNMP Table to represent aggregate data does avoid the limi- tations of encoding data into OCTET STRINGS and is thus the better gen- eral practice. Finally, as previously mentioned in sec. 3.3.6, one should avoid design of OCTET STRING object types which have typical instance data require- ments anywhere near the upper boundary of SMIv2 OCTET STRING instance encoding. 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. There exist MIB modules that assume a one to many relationship, such as MIBs for routing protocols which can accomodate 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. It is clear that single instancing of these MIB modules limits implemen- tations that might support multiple instances of OSPF, IP Stack or logi- cal bridges. In such cases, the ENTITY-MIB [RFC2737] can provide a means for support- ing the one-to-many relationship through naming scopes using the entLog- icalTable. 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 instance information. Alternately, multiple MIB module instances can be scoped by different SNMP contexts, although this requires the coordination of this technique with the administrative establishment of contexts in the configured agent system. Various Authors [Page 38] RFC DRAFT Expires May 2002 November 2001 3.13.3. Use of special optional clauses When defining integer based objects for both read-write and read-only semantics, using the UNITS clause is recommended in addition to specifi- cation in the DESCRIPTION clause of any particular details of how UNITs are to be interpreted. The REFERENCE clause is also recommended 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 imple- mentations will be more likely to interoperate. 4. IMPLEMENTING SNMP CONFIGURATION AGENTS 4.1. Operational Consistency Successful deployment of SNMP configuration systems depends on under- standing the roles of MIB module design and agent design. Both components must have been designed with an understanding of how UDP/IP based SNMP behaves. A best current practice in MIB design is to consider the idempotency of settable objects. Idempotency basically means being able to invoke the same set repeatedly with the effect of it resulting in an activation only once. 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 stateful way, the set operation might have caused the Set2 operation to fail owing to interactions with the opera- tion from Set1. If the implementation of the agent on the second request is not aware of such a situation, the agent may behave poorly by actu- ally re-implementing the set request instead of doing nothing. The example above shows that all the software that runs on a managed element and in managed applications should be designed and thought out together where possible. Particular emphasis should be placed at the Various Authors [Page 39] RFC DRAFT Expires May 2002 November 2001 logical boundaries of the management system components in order to ensure correct operation. 1. The first interface is between the SNMP agents in the managed devices and the management systems themselves. The MIB document is a contract between these two entities that defines expected behaviors - 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 approaches that minimize the management impact on those operational elements. Additionally, while the SNMP protocol-level and MIB Module-level model- ing of activation and configuration set may be idempotent and stateless from set to set, it may not be that way in the underlying subsystem. It is possible that an agent may need to explicitly manage this state in these subsystem architectures when it has placed the underlying subsys- tem into an "intermediate" state as a result of a series of SET PDUs. Depending on the underlying subsystem, the agent may be able to buffer all of the configuration sets up to activate them in the subsystem all at once (to accomodate the nature of the subsystem). Another way of looking at this point is to examine once again the prin- ciples of transactionality we have discussed at detail to this point, only to examine it from the agent perspective. When the MIB module designer models transactionality into the MIB module for the protocol or service being configured, a certain boundary of transactional scope is implied. Not all subsystem architectures for which a controlling agent is implemented for that protocol or service will have within them the same notion of transactional boundary that the MIB module models. When the subsystem defines the boundary more broadly, it is left to the agent to manage the difference in the transactional boundary. In many cases, the agent must implement a "best effort" to internally manage the point for the commitment or rollback of the broader subsystem transaction, in whatever ways the agent interface to the subsystem allows. 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 conceiv- able that in an underlying Layer 2 VPN subsystem, the requirement is Various Authors [Page 40] RFC DRAFT Expires May 2002 November 2001 that all existing gateways for a VPN be deleted before a new one can be defined--that, in other words, to add a new gateway g(n) to a VPN, gate- ways g(1)..g(n-1) need to be removed, and then all n gateways reestab- lished 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. In this way, the agent is establishing (in a time-based fashion), the mapping of the MIB module transactional boundary to a greater transactional boundary in the managed subsystem. 4.2. Handling Multiple Managers Devices are often modified by multiple management entities and with dif- ferent 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 set by different entities. It should also distinguish configuration defined locally such as a default or locally specified configuration made through an alternate management interface like command line interface. When a change has been made to the system via SNMP, CLI, or other method, a managed element should send an inform to the manager(s) configured as recipients of the applicable notification messages. These management applications should update their 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 synchro- nized 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 mak- ing 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 Various Authors [Page 41] RFC DRAFT Expires May 2002 November 2001 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. Order of varbinds in a SET PDU The particular objects to a SET PDU may be sent in any order. A con- forming SNMP command receiver (Agent) should be able to process them in any order. In reality, there exist systems that are not conformant and order does matter to these non-conformant implementations. As such, where viable, a management system should try issuing a SET with alter- nate varbind orderings or breaking up the SET into smaller PDUs before giving on the configuration operation. 4.5. 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 on a read of 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. But, regardless of the approach, the return of the read of such an object instance should be meaningful in the context of the object type 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 with SNMP. Functions all configuration management software should pro- vide, regardless of the method used to convey configuration information to the managed systems are: backup, fail-over, and restoration. A man- agement 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. 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 Various Authors [Page 42] RFC DRAFT Expires May 2002 November 2001 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 man- agement that are not the focus of this BCP. 5.1. Designing Configuration Management Software In considering SNMP based applications that configure one or more net- work elements, some consideration should be given to what has come to be known as policy-based management with SNMP (we will speak more of the underlying characteristics of policy-based configuration in Section 7). This is because it is one of the more effective ways of thinking about doing configuration of large number of elements, and to achive certain overall system design objectives in doing that configuration. The objectives we speak of here transcend anything specific to SNMP. Effec- tive software for the configuration of one or many network elements requires thoughtful design before starting implementation. This is true regardless of the technology used to represent and transfer the configu- ration information. Two general principles in management application design are: - Ensure minimum movement of data - Transaction control should be synchronized with remote system 5.2. Protocol Operations >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, be present as well. 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 Various Authors [Page 43] RFC DRAFT Expires May 2002 November 2001 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 con- figuration operation from the actual data. One way that some applica- tions 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 intended 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. 5.2.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 to the managed device as possible. 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 man- agement 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 SET variable bindings within a PDU has beneficial implica- tions in the area of management application transaction initiation, as well, as we will discuss in the following section. Yet there are agents that may have implementation limitations on the number and order of varbinds it can handle in a single SET PDU. In this case, sending fewer varbinds will be necessary. As we 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 SMMP PDU. Another example has to do with the RowStatus textual convention. Some SNMP agents implement a subset of the features available and so the management application must avoid using features that may not be supported in a specific table implementa- tion, such as createAndWait. Various Authors [Page 44] RFC DRAFT Expires May 2002 November 2001 5.2.2. Configuration Transactions There are several types of configuration transactions that can be sup- ported by SNMP-based configuration applications. They include transac- tions on a scalar object, 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 within the scope of the configuration operation. To make use of any kind of transaction semantics effectively, SNMP man- agement software must be aware of the information in the MIB modules that it is to configure so that it can effectively utilize 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 pro- vide 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 man- agement application level transactions. One was mentioned in the pre- ceding section. 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 to 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 man- agement object types which 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. Various Authors [Page 45] RFC DRAFT Expires May 2002 November 2001 5.2.3. Notifications As described throughout the section on Agent Software Development, agents should provide the capability for notifications to be sent to their configured management systems whenever a configuration operation is attempted or completed. The management application must be prepared to accept these notifications so that it knows the current configured state of the devices it has been deployed to control. Some configura- tion management applications may consume data from the managed devices that reflect configuration, operational and utilization state informa- tion. The GetBulkRequest-PDU is useful here whenever supported by the managed device. For the purposes of backward compatibility, the manage- ment station should also support and make use of the GetNextRequest-PDU in these cases. 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. 5.2.4. Scalability of Data Retrieval Efficient data retrieval described above is only part of the dimension of scale that application developers should consider when developing configuration applications. Management applications should provide for distributed processing of the configuration operations. This also extends to other management functions not the focus of this document. This capability can also be used to provide resilience in the case of network failures as well. An SNMP-based configuration management system might be deployed in a distributed fashion where three systems in dif- ferent locations keep each other synchronized. This synchronization can be accomplished without additional polling of network devices through a variety of techniques between each of the three managers. In the case of a failure, a 'backup' system can take over the configuration responsi- bilities of 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 configura- tion, agent implementation of its access, and management application issues in configuration using SNMP, we turn to operational considera- tions which transcend all three areas. Various Authors [Page 46] RFC DRAFT Expires May 2002 November 2001 6.1. Basic assumptions about Configuration The following basic assumptions are made about real world configuration models. One, 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. Two, systems undergoing configuration changes must be able to cope with unexpected loss of communication at any time. Network elements in conjunction with the configuration mechanism must take appropriate measures to leave the configuration in a consis- tent/recognizable state by either rolling back to a previously valid state or changing to a well-defined or default state. Three, configuration exists on a scale from relatively unchanging to a high volume, high rate of configuration 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 con- trol" 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 where to bootstrap devices that do not have secondary management inter- faces. Defaults lead to security issues, that have been recognized and exploited. When using SNMPv1, supporting read-only community strings is a common practice. SNMPv3 provides authentication and privacy protection and is recommended for all devices that support SNMP-based configuration. 6.3. Authentication Traps The default state of RFC 1215 [4] Authentication traps should be off. One does not want to risk accidentally sending out authentication fail- ure information, which by itself could constitute a security liability. Enabling of authentication traps should be done in the context of a man- agement security scheme which considers the proper recipients of this information. Various Authors [Page 47] RFC DRAFT Expires May 2002 November 2001 In the "Notification" section of this document's discussion on MIB agent design, issues and recommendations on throttling traps were raised. Where notifications are sent in SNMPv1 trap PDUs, unsolicited packets to a device can causes one ore 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. 6.4. Sensitive Information Handling Some MIB modules contain objects that may contain data for keys, pass- words 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. In these sections, con- siderations about sensitive information and how it should be protected is detailed. Similarly, those that create MIB documents for private MIB objects should contain 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 Consid- erations sections in the MIB RFCs 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. As noted in the section on Designing Configuration Objects, when writing standards track MIB modules, one must implement those objects that are part of the various standards-track specifications. Confidentiality is not a must implement portion of the SNMPv3 management framework [11]. Prior to SNMPv3, providing customized views of MIB module data was dif- ficult. This led to objects being defined such as the following from [42]. Various Authors [Page 48] RFC DRAFT Expires May 2002 November 2001 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 organize your objects into groups such that VACM views can be defined to properly scope what tables are visible to a given user and view. 7. POLICY BASED MANAGEMENT A common practice used to move large amounts of data that some vendors employ 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 effi- ciently 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 sec- tion 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 net- working vendor marketing departments, the term 'policy' has been so fre- quently used, touted, and contorted in meaning that its true meaning is unclear without greater qualification where it is used. Various Authors [Page 49] RFC DRAFT Expires May 2002 November 2001 [43] gives the term 'policy' two explicit definitions: - 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 in the term 'policy-based configura- tion', 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 accomodate the definition and evaluation of management and configuration policies. The side-effects of the evaluation of these policies typically includes 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 typi- cally provide a set of IP prefixes, BGP autonomous system numbers, or Various Authors [Page 50] RFC DRAFT Expires May 2002 November 2001 other such identifying constructs (see, for example, [44]). Once these access control lists are assembled, their application to various inter- faces, routing processes, and the like are specified typically in the configuration for what the access control list is applied to. Consis- tent with the prior properties to define our use of policy-based config- uration, 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 examine now the motivation for such a system or subsystem (per- haps bounded at the level of a 'template-enabled' MIB module, given the above definition). Let us explore the importance of policy-based tech- niques 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 spe- cialized services that require this coordinated configuration. Examples include delivery of virtual private networks, and connections that guar- antee specific service levels. The growth in size and complexity of configuration information has sig- nificant implications for its organization as well as its efficient transfer to the management agent. As an example, an agent that imple- ments the Bridge MIB [22] could be used to represent a large VLAN with some 65,000 port entries. To configure such a VLAN, it 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 sys- tem 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 con- tain 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 Various Authors [Page 51] RFC DRAFT Expires May 2002 November 2001 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 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) is 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. It could then allow refinement of these defaults across the domains of network control to realize the network service, the specific network protocol and algo- rithmic mechanisms encompassed within those domains, and so forth. 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 [35] (PM-MIB) implementation. But, 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 tech- nologies. 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 a useful input to the decision-making process about what type of config- uration operations to do. For this discussion it is important to make distinctions between distri- bution 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 Various Authors [Page 52] RFC DRAFT Expires May 2002 November 2001 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 itself. With this as back- ground, 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 config- ured. Care should be taken to determine if the sub-components to be con- figured 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 dis- tributed 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. o The capacity of the devices to perform the desired work. Capability is an ability to perform the desired work while a capac- ity is a measure of how much of that capability the system has. The policy configuration application should, wherever possible, evalu- ate the capacity of the network element to perform the work identi- fied by the policy. In some systems it will not be possible to directly obtain the capacity of the managed elements to perform the desired work, even though it may be possible to monitor the amount of work the element performs. In these cases, the management appli- cation may benefit from pre-configured information about the capac- ity of different network elements so that evaluations of the resources available can be made before distributing new policies. Various Authors [Page 53] RFC DRAFT Expires May 2002 November 2001 Utilization refers to how much capacity for a particular capability has been consumed. For devices that have been under policy configu- ration 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 for more information. Some deployed systems do not store complex notions of local time and thus may not be able to properly process policy direc- tives that contain time zone relevant data. For this reason, policy man- agement applications should have the ability to ascertain the time keep- ing 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. Detec- tion of such commands can occur at the device or management level and may be resolved using any number of mechanisms (examples are, last con- figuration 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 and 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 lim- ited 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 evaluated are for resource availability and validity of the set operations. In a policy enabled system, there are no additional requirements for this software assuming that good error detection and reporting appropriate to this level have already been implemented. Various Authors [Page 54] RFC DRAFT Expires May 2002 November 2001 For software that realizes MIB module objects at the protocol/data han- dling mechanism and/or implementation level thereof, failures should be reported such that the specific policy that has been impacted can be related with the specific element that failed. Beyond this basic report- ing which is does not perform any policy conflict detection, there need be no requirements. See the Policy MIB Module document [35] for addi- tional information on and example handling of policy precedence and con- flict detection. 7.5.1. Changes to Configuration Outside of the Policy System It is essential to consider changes to configuration outside of the pol- icy system. A goal of SNMP-based policy management is to coexist with other forms of management software that has historically been instance based management. The best example is command line interface. Here are some guidelines for handling these changes. 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 notifi- cation should include the policy that was changed, the instance of the element that was changed and the object and value that it was changed to. An element under the control of policy that has been changed remains a member of the policy group until the attributes in the Role table that caused it to match the policy in the first place are modified. An ele- ment that has been modified by a an out of policy mechanism, while remaining a member of the policy does not get overridden by a policy until its value is made the same as the extant policy with the highest precedence for this element, and by implication then returned to policy control. A notification should be sent when this action is taken. 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 add to 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 it 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. Various Authors [Page 55] RFC DRAFT Expires May 2002 November 2001 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 inter- faces on a system might require 100 CLI commands or 100 SNMP variable bindings using conventional techniques. 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 eliminat- ing 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 can also be carried (see the Policy MIB Module). To extend the example above, let's say 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 [35]), an entire data set that poten- tially 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 inte- grates well with MIB module objects which support "summary" activation and activation reporting, of the kind we discussed in Sec. 3.3.5. 8. Example MIB Module With Template-based Data In this section, we define a MIB Module that controls the heating and air conditioning 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 the application of the tables' row instance data as templated 'defaults' will allow operators to configure Various Authors [Page 56] RFC DRAFT Expires May 2002 November 2001 and monitor many rooms all 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 spec- ified from template object types. 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 pointer to a table that 'glues' configuration information defaults with descriptive information: bldgHVACCfgTemplatePtr A set of objects that show status and units of work (bldgHVACCoolOrHeatMins) and standard SnmpAdminString and RowStatus objects: bldgHVACFanSpeed bldgHVACCurrentTemp bldgHVACCoolOrHeatMins 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, could be a brief description of the underlying motivation such as: "provides high quality packet forwarding for Voice over IP customers". The details are: Various Authors [Page 57] RFC DRAFT Expires May 2002 November 2001 bldgHVACCfgTemplateIndex bldgHVACCfgTemplateDescription bldgHVACCfgTemplateOwner bldgHVACCfgTemplateStatus Standard owner and status objects may also be helpful and so are included here. 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 of number of objects and data movement efficiency just as with other MIB modules. Step 3: This is the bldgHVACCfgTemplateTable. It contains the specific configuration parameters that are pointed to by the bldgHVACConfigPtr object. Note that many 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 in Policy 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 of those necessary for configuration and connection to the other tables as well as the usual SnmpAdminString and RowStatus objects: A simple index to the table: bldgHVACCfgTemplateIndex The configuration objects: bldgHVACCfgTemplateDesiredTemp bldgHVACCfgTemplateCoolOrHeat Administrative objects for SnmpAdminString and RowStatus: Various Authors [Page 58] RFC DRAFT Expires May 2002 November 2001 bldgHVACCfgTemplateDescrPtr bldgHVACCfgTemplateOwner bldgHVACCfgTemplateStorage bldgHVACCfgTemplateStatus 8.1. MIB Module Definitions BLDG-HVAC-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, Counter32, Gauge32, OBJECT-TYPE, Integer32, Unsigned32, experimental FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF TEXTUAL-CONVENTION, RowStatus, RowPointer, StorageType, DisplayString FROM SNMPv2-TC SnmpAdminString FROM SNMP-FRAMEWORK-MIB; bldgHVACMIB MODULE-IDENTITY LAST-UPDATED "200007090000Z" ORGANIZATION "SNMPCONF working group" CONTACT-INFO " Someone Some place phone number email address, web site" 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 which eliminates the need to send per instance configuration commands to the system. Note that before this MIB Module will successfully compile an assignment from IANA would be needed to replace the XXX below." REVISION "200105101230Z" DESCRIPTION "Initial version of BLDG-HVAC-MIB." ::= { experimental XXX } bldgHVACObjects OBJECT IDENTIFIER ::= { bldgHVACMIB 1 } bldgConformance OBJECT IDENTIFIER ::= { bldgHVACMIB 2 } -- Various Authors [Page 59] RFC DRAFT Expires May 2002 November 2001 -- Textual Conventions -- HvacOperation ::= 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 -- bldgHVACTable OBJECT-TYPE SYNTAX SEQUENCE OF BldgHVACEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This simple table is an example of objects that are at the instance level of specificity. That is, they are indexed by a specific floor and office number. These objects include general counter and status information. This table includes the bldgHVACCfgTemplatePtr that points to a row in the bldgHVACCfgTemplateTable. If this value is not null, then the instance in the row that has a value for this object is being configured using templates and this is where the configuration information for the HVAC operation will be installed." ::= { bldgHVACObjects 1 } bldgHVACEntry OBJECT-TYPE SYNTAX BldgHVACEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each row represents a particular office, a pointer to the desired HVAC configuration settings and usage information for that location since this setting was initialized." INDEX { bldgHVACFloor, bldgHVACOffice } ::= { bldgHVACTable 1 } BldgHVACEntry ::= SEQUENCE { bldgHVACFloor Integer32, bldgHVACOffice Integer32, bldgHVACCfgTemplatePtr RowPointer, Various Authors [Page 60] RFC DRAFT Expires May 2002 November 2001 bldgHVACFanSpeed Gauge32, bldgHVACCurrentTemp Gauge32, bldgHVACCoolOrHeatMins Counter32, bldgHVACOwner SnmpAdminString, bldgHVACStatus RowStatus } bldgHVACFloor OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This portion of the index indicates the floor of the building." ::= { bldgHVACEntry 1 } bldgHVACOffice OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This second component of the index specifies the office number." ::= { bldgHVACEntry 2 } bldgHVACCfgTemplatePtr OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-write STATUS current DESCRIPTION "The pointer to an entry in the 'bldgHVACCfgTemplateTable'. The entry pointed to is a pre-made configuration that represents the configuration described by the bldgHVACCfgDescription 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 pointer to an entry in the bldgHVACCfgTemplateTable. The benefit of this approach is that all configuration information is available in one table whether all elements in the system are derived from templates or not." ::= { bldgHVACEntry 3 } bldgHVACFanSpeed OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current Various Authors [Page 61] RFC DRAFT Expires May 2002 November 2001 DESCRIPTION "Shows the revolutions per minute of the fan. Fan speed will vary based on the difference between bldgHVACDesiredTemp and bldgHVACurrentTemp." ::= { bldgHVACEntry 4 } bldgHVACCurrentTemp OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The current measured temperature in the office." ::= { bldgHVACEntry 5 } bldgHVACCoolOrHeatMins OBJECT-TYPE SYNTAX Counter32 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 some parameters that impact configuration are changed, the subsystem must be re-initialized." ::= { bldgHVACEntry 6 } bldgHVACOwner OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "The identity of the operator/system that last modified this entry." ::= { bldgHVACEntry 7 } bldgHVACStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row." ::= { bldgHVACEntry 8 } -- Various Authors [Page 62] RFC DRAFT Expires May 2002 November 2001 -- HVAC Configuration Template Table -- bldgHVACCfgTemplateInfoTable OBJECT-TYPE SYNTAX SEQUENCE OF BldgHVACCfgTemplateInfoEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides a unique string identifier for HVAC 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 template name. The bldgHVACCfgCfgTemplateInfoDescription contains a brief description of the template service objective such as: provides high quality packet forwarding for Voice over IP customers. The bldgHVACCfgTemplateInfoPtr 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 policy 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." INDEX { bldgHVACCfgTemplateInfoIndex } ::= { bldgHVACCfgTemplateInfoTable 1 } BldgHVACCfgTemplateInfoEntry ::= SEQUENCE { bldgHVACCfgTemplateInfoIndex DisplayString, bldgHVACCfgTemplateInfoDescr DisplayString, bldgHVACCfgTemplateInfoOwner SnmpAdminString, bldgHVACCfgTemplateInfoStatus RowStatus } bldgHVACCfgTemplateInfoIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "The index to this table. 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 Various Authors [Page 63] RFC DRAFT Expires May 2002 November 2001 template can have the same 'handle'." ::= { bldgHVACCfgTemplateInfoEntry 1 } bldgHVACCfgTemplateInfoDescr OBJECT-TYPE SYNTAX Integer32 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 2 } bldgHVACCfgTemplateInfoOwner OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "The identity of the operator/system that last modified this entry." ::= { bldgHVACCfgTemplateInfoEntry 3 } bldgHVACCfgTemplateInfoStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row." ::= { bldgHVACCfgTemplateInfoEntry 4 } -- -- HVAC Configuration Template Table -- bldgHVACCfgTemplateTable OBJECT-TYPE SYNTAX SEQUENCE OF BldgHVACCfgTemplateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table can be used to set defaults that will be placed on the specific offices that match the pmPolicyFilter in [35] or other analogous template storage." ::= { bldgHVACObjects 3 } bldgHVACCfgTemplateEntry OBJECT-TYPE SYNTAX BldgHVACCfgTemplateEntry MAX-ACCESS not-accessible STATUS current Various Authors [Page 64] RFC DRAFT Expires May 2002 November 2001 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." INDEX { bldgHVACCfgTemplateIndex } ::= { bldgHVACCfgTemplateTable 1 } BldgHVACCfgTemplateEntry ::= SEQUENCE { bldgHVACCfgTemplateIndex Unsigned32, bldgHVACCfgTemplateDesiredTemp Gauge32, bldgHVACCfgTemplateCoolOrHeat HvacOperation, bldgHVACCfgTemplateInfoPtr RowPointer, bldgHVACCfgTemplateOwner SnmpAdminString, bldgHVACCfgTemplateStorage StorageType, bldgHVACCfgTemplateStatus RowStatus } bldgHVACCfgTemplateIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "A unique value for each defined template in this table. This value can be pointed to from any MIB Module that needs access to this information. The bldgHVACCfgTemplatePtr will point to entries in this table." ::= { bldgHVACCfgTemplateEntry 1 } bldgHVACCfgTemplateDesiredTemp OBJECT-TYPE SYNTAX Gauge32 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 change and then reactivating the row." ::= { bldgHVACCfgTemplateEntry 2 } bldgHVACCfgTemplateCoolOrHeat OBJECT-TYPE SYNTAX HvacOperation MAX-ACCESS read-create STATUS current DESCRIPTION "This controls the heating and cooling mechanism and is Various Authors [Page 65] RFC DRAFT Expires May 2002 November 2001 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 } bldgHVACCfgTemplateInfoPtr OBJECT-TYPE SYNTAX RowPointer 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 4 } bldgHVACCfgTemplateOwner OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "The identity 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." ::= { bldgHVACCfgTemplateEntry 6 } bldgHVACCfgTemplateStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row of the table." ::= { bldgHVACCfgTemplateEntry 7 } -- -- Conformance Information -- bldgCompliances OBJECT IDENTIFIER ::= { bldgConformance 1 } bldgGroups OBJECT IDENTIFIER ::= { bldgConformance 2 } Various Authors [Page 66] RFC DRAFT Expires May 2002 November 2001 -- 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 { bldgHVACFloor, bldgHVACOffice, bldgHVACCfgTemplatePtr, bldgHVACFanSpeed, bldgHVACCurrentTemp, bldgHVACCoolOrHeatMins, bldgHVACOwner, bldgHVACStatus, bldgHVACCfgTemplateInfoIndex, bldgHVACCfgTemplateInfoDescr, bldgHVACCfgTemplateInfoOwner, bldgHVACCfgTemplateInfoStatus, bldgHVACCfgTemplateIndex, bldgHVACCfgTemplateDesiredTemp, bldgHVACCfgTemplateCoolOrHeat, bldgHVACCfgTemplateInfoPtr, bldgHVACCfgTemplateOwner,bldgHVACCfgTemplateStorage, bldgHVACCfgTemplateStatus } STATUS current DESCRIPTION "The bldgHVACObjects Group." ::= { bldgGroups 1 } END .fi 8.2. NOTES ON MIB MODULE WITH TEMPLATE-BASED DATA The primary purpose to the sample 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. Various Authors [Page 67] RFC DRAFT Expires May 2002 November 2001 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 bldgHVACTem- plateTable 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. 9. 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 Partain David T. Perkins Randy Preshun Dan Romanescu Shawn Routhier Steve Waldbusser Various Authors [Page 68] RFC DRAFT Expires May 2002 November 2001 10. REFERENCES [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [2] Rose, M., and K. McCloghrie, "Structure and Identification of Man- agement Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduc- tion to Community-based SNMPv2", RFC 1901, January 1996. [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Pro- cessing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol Various Authors [Page 69] RFC DRAFT Expires May 2002 November 2001 (SNMPv2)", RFC 1905, January 1996. [14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Con- trol Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [16] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, q(Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2) q, RFC 1907, January 1996. [17] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB using SMIv2", RFC 2233, Cisco Systems, FTP Software, November 1997. [18] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [19] Brown, C., and F. Baker, "Management Information Base for Frame Relay DTEs Using SMIv2", RFC 2115, September 1997. [20] Baker, F, "Requirements for IP Version 4 Routers", RFC 1812, June 1995. [21] Hawkinson, J., and T. Bates, "Guidelines for Creation, Selection, and Registration of an Autonomous System (AS)", RFC 1930, March 1996. [22] Decker, E., Langille, P., Rijsinghani, A., and K. McCloghrie, "Def- initions of Managed Objects for Bridges", RFC 1493, July 1993. [23] Levi, D., and J. Schoenwaelder "Definitions of Managed Objects for Scheduling Management Operations", RFC 2591, May 1999. [24] Bell, E., Smith, A., Langille, P., Rijsinghani, A., and K. McCloghrie, "Definitions of Managed Objects for Bridges with Traf- fic Classes, Multicast Filtering and Virtual LAN Extensions, RFC 2674, August 1999. [25] Baker, F., "IP Forwarding Table MIB", RFC 2096, January 1997. [26] St. Johns, M., "Radio Frequency (RF) Interface Management Informa- tion Base for MCNS/DOCSIS compliant RF interfaces", RFC 2670, August 1999. [27] Baker, F., and R. Coltun, "OSPF Version 2 Management Information Various Authors [Page 70] RFC DRAFT Expires May 2002 November 2001 Base", RFC 1850, November 1995. [28] Blake, S. Black, D., Carlson M., Davies E. Wang Z., Weiss W., "An Architecture for Differentiated Services ", RFC 2475, December 1998. [29] Willis, S. and J. Chu., "Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2", RFC 1657, July 1994. [30] Waldbusser, S."Remote Network Monitoring Management Information Base", RFC 2819, May 2000. [31] McCloghrie, K., and Kastenholz, F., "The Interfaces Group MIB", RFC 2863, June 2000. [32] McCloghrie, K., and Hanson, G., "The Inverted Stack Table Extension to the Interfaces Group MIB", RFC 2864, June 2000. [33] McCloghrie, K. and Bierman, A., "Entity MIB (Version 2)", RFC 2737, December, 1999. [34] ITU-T,, Recommendation M.3010., PRINCIPLES FOR A TELECOMMUNICATIONS MANAGEMENT NETWORK. February, 2000. [35] Waldbusser, S., Saperia, J., and Hongal, T., "Policy Based Manage- ment MIB", Work-in-progress. [36] Heintz, L., "SNMP Row Operations Extensions", Work-in-progress. [37] Zeltserman, D., "A Practical Guide to Snmpv3 and Network Manage- ment", Prentice Hall, 1999. [38] Noto, M., Spiegel, E., and Tesink, K., "Definitions of Textual Con- ventions and OBJECT-IDENTITIES for ATM Management", RFC 2514, February, 1999. [39] Kassaveri, R., and Stewart, B., "Distributed Management Expression MIB", RFC 2982, October, 2000. [40] Haskin, D., and Onishi, S., "Management Information Base for IP Version 6: Textual Conventions and General Group", RFC 2465, Decem- ber 1998. [41] Daniele, M., Haberman, B., Routhier, S., and Schoenwaelder, J., "Textual Conventions for Internet Network Addresses", RFC 2851, June 2000. Various Authors [Page 71] RFC DRAFT Expires May 2002 November 2001 [42] 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. [43] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J., and Wald- busser, S., "Terminology for Policy-Based Management", work-in- progress, July, 2001. [44] http://wwww.cisco.com/univercd/cc/td/product/software/ios113ed/ 11ed_cr/secur_c/scprt/scacls.pdf. 11. EDITORS' ADDRESSES Michael R. MacFaden Riverstone Networks, Inc 5200 Great America Parkway Santa Clara, CA 95054 email - mrm@riverstonenet.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 12. INTELLECTUAL PROPERTY The IETF takes no position regarding the validity or scope of any intel- lectual 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 Various Authors [Page 72] RFC DRAFT Expires May 2002 November 2001 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 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 stan- dard. Please address the information to the IETF Executive Director. 13. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to oth- ers, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and dis- tributed, 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 ref- erences 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 FIT- NESS FOR A PARTICULAR PURPOSE. Various Authors [Page 73] RFC DRAFT Expires May 2002 November 2001 Table of Contents 1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. THE INTERNET STANDARD MANAGEMENT FRAMEWORK . . . . . . . . . . 2 1.2. CONFIGURATION AND THE INTERNET STANDARD MANAGEMENT FRAME- WORK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. USING SNMP AS A CONFIGURATION MECHANISM . . . . . . . . . . . . . 4 2.1. Transactions and SNMP . . . . . . . . . . . . . . . . . . . . . 4 2.2. Practical Requirements for Transactional Control . . . . . . . 5 2.3. Best Practices in Configuration--Verification . . . . . . . . . 6 3. DESIGNING A MIB MODULE . . . . . . . . . . . . . . . . . . . . . 8 3.1. MIB Module Design - General Issues . . . . . . . . . . . . . . 8 3.2. Naming MIB modules and Managed Objects . . . . . . . . . . . . 10 3.3. Transaction Control And State Tracking . . . . . . . . . . . . 10 3.3.1. Conceptual Table Row Modification Practices . . . . . . . . . 10 3.3.2. Fate sharing with multiple tables . . . . . . . . . . . . . . 12 3.3.3. Transaction Control MIB Objects . . . . . . . . . . . . . . . 12 3.3.4. Creating And Activating New Table Rows . . . . . . . . . . . 13 3.3.5. Summary Objects and State Tracking . . . . . . . . . . . . . 14 3.3.6. Optimizing Configuration Data Transfer . . . . . . . . . . . 16 3.4. More Index Design Issues . . . . . . . . . . . . . . . . . . . 21 3.4.1. Simple Integer Indexing . . . . . . . . . . . . . . . . . . . 21 3.4.2. Indexing with Network Addresses . . . . . . . . . . . . . . . 22 3.5. Conflicting Controls . . . . . . . . . . . . . . . . . . . . . 23 3.6. Textual Convention Usage . . . . . . . . . . . . . . . . . . . 24 3.7. Persistent Configuration . . . . . . . . . . . . . . . . . . . 25 3.8. Configuration Sets and Activation . . . . . . . . . . . . . . . 27 3.8.1. Operational Activation Considerations . . . . . . . . . . . . 27 3.8.2. RowStatus and Deactivation . . . . . . . . . . . . . . . . . 28 3.9. SET operation Latency . . . . . . . . . . . . . . . . . . . . . 29 3.9.1. Subsystem Latency, Persistence Latency, and Activation Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.10. Notifications and Error Reporting . . . . . . . . . . . . . . 31 3.10.1. Identifying Source of Configuration Changes . . . . . . . . 32 3.10.2. Limiting Unnecessary Transmission of Notifications . . . . . 32 3.10.3. Control of Notification Subsystem . . . . . . . . . . . . . 33 3.11. Application Error Reporting . . . . . . . . . . . . . . . . . 34 3.12. Designing MIB Modules for Multiple Managers . . . . . . . . . 35 3.13. Other MIB Module Design Issues . . . . . . . . . . . . . . . . 36 3.13.1. Octet String Aggregations . . . . . . . . . . . . . . . . . 36 3.13.2. Supporting multiple instances of a MIB Module . . . . . . . 38 3.13.3. Use of special optional clauses . . . . . . . . . . . . . . 39 4. IMPLEMENTING SNMP CONFIGURATION AGENTS . . . . . . . . . . . . . 39 4.1. Operational Consistency . . . . . . . . . . . . . . . . . . . . 39 4.2. Handling Multiple Managers . . . . . . . . . . . . . . . . . . 41 4.3. Specifying Row Modifiability . . . . . . . . . . . . . . . . . 41 4.4. Order of varbinds in a SET PDU . . . . . . . . . . . . . . . . 42 Various Authors [Page 74] RFC DRAFT Expires May 2002 November 2001 4.5. Implementing write-only access objects . . . . . . . . . . . . 42 5. DESIGNING CONFIGURATION MANAGEMENT SOFTWARE . . . . . . . . . . . 42 5.1. Designing Configuration Management Software . . . . . . . . . . 43 5.2. Protocol Operations . . . . . . . . . . . . . . . . . . . . . . 43 5.2.1. SET Operations . . . . . . . . . . . . . . . . . . . . . . . 44 5.2.2. Configuration Transactions . . . . . . . . . . . . . . . . . 45 5.2.3. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 46 5.2.4. Scalability of Data Retrieval . . . . . . . . . . . . . . . . 46 6. DEPLOYMENT AND SECURITY ISSUES . . . . . . . . . . . . . . . . . 46 6.1. Basic assumptions about Configuration . . . . . . . . . . . . . 47 6.2. Secure Agent Considerations . . . . . . . . . . . . . . . . . . 47 6.3. Authentication Traps . . . . . . . . . . . . . . . . . . . . . 47 6.4. Sensitive Information Handling . . . . . . . . . . . . . . . . 48 7. POLICY BASED MANAGEMENT . . . . . . . . . . . . . . . . . . . . . 49 7.1. What Is the Meaning of 'Policy-based'? . . . . . . . . . . . . 49 7.2. Organization of Data in an SNMP-Based Policy System . . . . . . 51 7.3. Information Related to Policy Based Configuration . . . . . . . 52 7.4. Schedule and Time Issues . . . . . . . . . . . . . . . . . . . 54 7.5. Conflict Detection, Resolution and Error Reporting . . . . . . 54 7.5.1. Changes to Configuration Outside of the Policy System . . . . 55 7.6. More about Notifications in a Policy System . . . . . . . . . . 55 7.7. Using Policy to Move Less Configuration Data . . . . . . . . . 56 8. Example MIB Module With Template-based Data . . . . . . . . . . . 56 8.1. MIB Module Definitions . . . . . . . . . . . . . . . . . . . . 59 8.2. NOTES ON MIB MODULE WITH TEMPLATE-BASED DATA . . . . . . . . . 67 9. ACKNOWLEDGMENTS . . . . . . . . . . . . . . . . . . . . . . . . . 68 10. REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 11. EDITORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 72 12. INTELLECTUAL PROPERTY . . . . . . . . . . . . . . . . . . . . . 72 13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 73 Various Authors [Page 75]