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-05.txt
May 11, 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
material 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
developers, and those that acquire and deploy this technology in
Various Authors [Page 1]
RFC DRAFT Expires November 2001 May 2001
their networks.
1. INTRODUCTION
Data networks have grown significantly over the past decade. This
growth can be seen in terms of:
Scale - Data networks have grown in many dimensions:
they have more network elements, and the network elements are
larger. For example the number and speed of interfaces. There are
also many more interrelationships
within and between devices.
Functionality - network devices perform more functions.
More protocols and network layers are
required for the successful deployment of a wide array
of network services.
Time - changes to devices occur more often than in the
past. The need for dynamic configuration has grown faster than
the traditional set-and-forget style configuration.
Correct configuration of network elements that make up data networks
is a prerequisite to the successful deployment of services of them.
The growth in size and complexity of modern networks increases the
need for a standard configuration mechanism that is tightly
integrated with performance and fault management systems.
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 integrates with performance and fault systems is needed
not only to help reduce the complexity of management, but to enable
verification of configuration activities that create bill-able
services.
This document describes Best Current Practices that have been used
when designing effective configuration management systems using the
Internet Standard Management Framework (or, more colloquially, SNMP).
It covers many basic practices as well as more complex agent and
manager design issues that are raised in configuration management.
Significant experience has been gained over the past ten years in
configuring public and private data networks with SNMP. Policy Based
Configuration Management, is a methodology where configuration
information is distributed to potentially many network elements with
the goal of achieving consistent network behavior throughout an
Various Authors [Page 2]
RFC DRAFT Expires November 2001 May 2001
administrative domain.
This document presents lessons learned from these experiences and
applies them to both conventional and policy based configuration
systems based on SNMP.
1.1. Document Organization
This document is divided into eight sections:
Section 1 - Introduction and document organization
Section 2 - Using SNMP as a configuration mechanism
Section 3 - Designing a MIB Module
Section 4 - Implementing SNMP configuration agents
Section 5 - Designing configuration management
software
Section 6 - Deployment and Security Issues
Section 7 - Policy Management
Section 8 - Example MIB Module for configuration
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 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 elements 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 or in very large aggregations such as an
entire configuration file. For this reason, reliance on transactional
integrity only at the protocol level is insufficient.
MIB Module design plays a significant role in how well SNMP
transaction integrity will work. For example, The Structure of
Management Information Version 2 (SMIv2), RFC 2579, defines textual
conventions that help support configuration. The RowStatus object
which defines a standard object for the management of conceptual rows
in a table is one example.
Various Authors [Page 3]
RFC DRAFT Expires November 2001 May 2001
A RowStatus object can be used in many ways to help with transaction
control. The case where a single row activation is equivalent to a
level of a transaction is an example. When a RowStatus object is
moved to the active state, the entire row is '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.
A well designed SNMP-based management system addresses all the issues
described above effectively.
2.2. Practical Requirements for Transactional Control
A well designed and deployed configuration system should have the
following features with regard to transactions and transactional
integrity.
1) Provide for flexible transaction control at many different levels
of granularity. At one extreme, an entire configuration may be
delivered and installed on an element or one small attribute may be
changed. Very granular changes should invoke behavior according to
the change being made. This is often termed "no surprises."
2) The transaction control component should work at any of the levels
of abstraction defined in section 7.2. The key point here is that it
may make most sense to configure systems at an abstract level rather
than on an individual instance by instance basis as has been commonly
practiced. In some cases it is more effective to send a configuration
command to a system that contains a set of 'defaults' to be applied
to instances that meet certain criteria.
3) An effective configuration management system must allow
flexibility in the definition of a successful transaction. This
cannot be done at the protocol level alone, but rather must be
provided for throughout the application and the information that is
being managed. In the case of SNMP, the information would be in
properly defined MIB modules.
4) A configuration management system should provide time-indexed
transaction control. For effective rollback control, the
Various Authors [Page 4]
RFC DRAFT Expires November 2001 May 2001
configuration transactions and their successful or unsuccessful
completion status must be reported by the managed elements and stored
in a repository that supports such time indexing and can record the
user that made the change, even if the change was not carried out the
system recording the change.
5) The managed system must support transactional security. This means
that depending on where and who is making the configuration request,
it may be accepted or denied based on security policy that is in
effect in the managed element.
2.3. Best Practices in Configuration
Debugging 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
critical systems such as the domain name system (DNS). DNS software
kits provide diagnostic tools that facilitate automatic test
procedures/scripts to be defined. Strict adherence to this procedure
ensures service remains intact since any failure of the test detected
after the change can be rolled back to the prior state.
Likewise, a planned configuration sequence can be aborted if pre-
configuration test results show the state of the system as unstable.
Debugging two sets of changes in large systems is often more
challenging than one.
Networks and devices under SNMP configuration readily support this
change management procedure since the SNMP provides integrated
monitoring, configuration and diagnostic capabilities. For example,
the EtherLike-MIB, RFC 2665, defines diagnostic tests as follows:
Various Authors [Page 5]
RFC DRAFT Expires November 2001 May 2001
dot3TestLoopBack OBJECT-IDENTITY
STATUS current
DESCRIPTION "This test configures the MAC chip and executes
an internal loopback test of memory, data paths,
and the MAC chip logic. This loopback test can
only be executed if the interface is offline.
Once the test has completed, the MAC chip should
be reinitialized for network operation, but it
should remain offline.
If an error occurs during a test, the
appropriate test result object will be set
to indicate a failure. The two OBJECT
IDENTIFIER values dot3ErrorInitError and
dot3ErrorLoopbackError may be used to provided
more information as values for an appropriate
test result code object."
::= { dot3Tests 2 }
There are times when configuration of a given element can impact
other network elements in a network. Configuring network protocols
such as IEEE 802.1D Spanning Tree or OSPF is especially challenging
since the impact of a configuration change can directly affect
stability (convergence) of the network the device is connected to.
An integrated view of configuration and monitoring provides an ideal
platform from which to evaluate such changes. For IEEE 802.1D
Spanning Tree, RFC 1493 provides the following object to monitor
stability per logical bridge.
dot1dStpTopChanges OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of topology changes detected by
this bridge since the management entity was last
reset or initialized."
REFERENCE
"IEEE 802.1D-1990: Section 6.8.1.1.3"
::= { dot1dStp 4 }
Likewise, the OSPF MIB module provides a similar metric for stability
per OSPF area.
Various Authors [Page 6]
RFC DRAFT Expires November 2001 May 2001
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 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.
The above model is not fail safe, especially when configuration
errors are masked by long latencies or when configuration errors lead
to oscillations in network stability. For example, consider the
situation where loading a new software version on a device leads to a
small, slow memory leak brought on by a certain traffic pattern that
went uncaught during vendor and customer test lab trials.
In a network based example; convergence in an autonomous system
cannot be guaranteed when configuration changes are made since there
are factors beyond control of the operator such as the state of other
network elements. Even for factors within the operator's control,
there is often little verification 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 defined above 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
configuration systems should be designed and implemented with
verification tests in mind.
Various Authors [Page 7]
RFC DRAFT Expires November 2001 May 2001
3. DESIGNING A MIB MODULE
Well-thought out MIB module designs are crucial for practical
configuration with SNMP. MIB Modules for configuration can be very
effective since they can be integrated with diagnostic, monitoring
and fault objects. MIB Modules for configuration also scale when
integrated policy objects. Policy objects represent information at
an or higher level of abstraction, than instance level ones. 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
information an agent will expose.
MIB modules can be thought of as logical models providing one or more
aspects/views of a subsystem. The objective for all MIB modules
should be to serve one or more operational requirements such as
accounting information collection, configuration of one or more parts
of a system, or fault identification.
Include only those aspects of a subsystem that are proven to be
operationally useful.
In 1993, one of most widely deployed MIB modules supporting
configuration was published, RFC 1493 containing 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.
Various Authors [Page 8]
RFC DRAFT Expires November 2001 May 2001
(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.
3.2. Naming MIB modules and Managed Objects
Naming of MIB modules and objects generally follows a set of best
practices. Originally, standards track MIB modules used RFC names. As
the MIB modules evolved, the practice changed to using more
descriptive names. Presently, Standards Track MIB modules define a
given area of technology such as ATM-MIB, and vendors then extend
such MIB modules by prefixing the company name to a given MIB Module
as in ACME-ATM-MIB.
Object descriptors (the "human readable names" assigned to object
identifiers) defined in standard MIB modules should be unique across
all MIB modules. However, MIB Modules do not define a naming scope.
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 objects such as ifTable, ifStackTable and so
forth.
The names for MIB objects can include an abbreviation for the
function they perform. For example the objects that control
configuration in the example MIB Module in section 8 include "Cfg" as
part of the name as in: bldgHVACCfgDesiredTemp.
The power of this approach is more fully realized when the names that
include the fault, configuration, accounting, performance and
Various Authors [Page 9]
RFC DRAFT Expires November 2001 May 2001
security [34] abbreviations are combined with an organized OID
assignment approach. For example a vendor could create a
configuration branch in their private enterprises area. In some cases
this might be best done on a per product basis. Which ever approach
is used, Cfg might be included in every object in the configuration
branch. This has two operational benefits. First for those that do
look at MIB Object names through MIB Browsers or other simple command
line tools, the name can more completely convey the meaning of that
object. Secondly, management applications can be pointed at specific
sub trees for fault or configuration, causing a more efficient
retrieval of data and a simpler management application with
potentially better performance.
3.3. Transaction Control And State Tracking
Transactions and keeping track of the state of them is an important
consideration when performing any type of configuration activity
regardless of the protocol. SNMP is no example. Here are a few areas
to consider when designing transaction support into an SNMP-based
configuration system.
3.3.1. Fate sharing with multiple tables
Fate sharing of SNMP tables should be explicitly defined where
possible using SMI macros such as AUGMENTS. If the relationship
between tables cannot be defined using SMIv2 macros, then the
DESCRIPTION clause should define what should happen when rows in
related tables are added or deleted.
Consider the relationship between the dot1dBasePortTable and the
ifTable, which 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, the DESCRIPTION clauses should define
the fate sharing of entries in the respective tables.
3.3.2. Transaction Control MIB Objects
When a standard MIB module is defined that includes configuration
operations, consider providing transaction control objects in places
Various Authors [Page 10]
RFC DRAFT Expires November 2001 May 2001
where they can help reduce churn in the underlying systems being
configured. Here are some examples:
Control objects that are the 'write' or 'commit' objects.
Such objects will 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.
Control objects at different levels of configuration granularity.
One of the decisions for a MIB module designer is what levels of
granularity that make sense. 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 also has important relevance
as a general transaction control object.
3.3.3. Usage of Row notReady Status
It is useful when configuring new rows to use the notReady status to
indicate row activation cannot proceed.
When designing read-create objects in a table containing a RowStatus
object, a MIB module designer should first consider the default state
of each object in the table when a row is created via one simple
createAndWait(5) PDU. If no default state is applicable but the
object must be set to some value, the DESCRIPTION clause should
specify this object as mandatory. In addition, an SNMP get of such an
object then should return a noSuchInstance error if the object has
not yet been set. A read of the RowStatus columnar object should
return notReady(3) until all such mandatory and non-defaultable
objects have been set with acceptable values.
Should a given implementation vary from a standard MIB module 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. Not implementing the above may result in a
management application being misled that a transition to active(1)
state will succeed without further action by only polling the
RowStatus object and receiving the notInService(2) value from an
agent.
Various Authors [Page 11]
RFC DRAFT Expires November 2001 May 2001
3.3.4. Summary Objects and State Tracking
Prior to making a configuration change, management software generally
will synchronize with agents and backup existing configuration.
The three factors that influence this process are:
1. Amount of configuration data to transfer
2. Frequency of change to the data
3. Accessibility of the data
To make this process simple and efficient, consider using the
following techniques in a MIB module.
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 (inform) to deliver configuration change.
(See example in Section 7.2)
By providing an object containing the number of rows in a table,
management applications can decide how best to retrieve a given
table's data and may choose different access strategies depending on
table size.
Once a table has been synchronized, keeping it synchronized requires
an object to monitor table state. An example is found in RFC 2790,
Host Resources MIB:
hrSWInstalledLastUpdateTime OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime when the hrSWInstalledTable
was last completely updated. Because caching of this
data will be a popular implementation strategy,
retrieval of this object allows a management station
to obtain a guarantee that no data in this table is
older than the indicated time."
::= { hrSWInstalled 2 }
A similar convention found in many standards track MIB modules is the
"LastChange" type object.
For example, the ENTITY-MIB RFC2737 provides the following object:
Various Authors [Page 12]
RFC DRAFT Expires November 2001 May 2001
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, and 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 }
So, if an agent performs a row modification via an SNMP SET on
ifAdminStatus, the value of ifTableLastChange will not be updated.
Be specific in what causes your object to update so caching will
work.
The final way to keep distributed configuration data consistent is to
use an event-driven model, where configuration changes are
communicated as they occur. When the frequency of change to
configuration is relatively low or polling a cache object is not
desired, consider defining a notification that will report all
configuration change details.
Use an inform instead of a trap notification pdu so that changes are
reliably communicated.
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
Various Authors [Page 13]
RFC DRAFT Expires November 2001 May 2001
to expose.
Finally, having to poll many "LastChange" objects does not scale
reasonably. Consider providing a global LastChange type object to
represent overall configuration in a given agent implementation.
3.3.5. Advanced Synchronization Considerations
For very large tables or for tables whose data changes frequently, a
row count and LastChange style object as described in the previous
section for caching a whole table's contents in a management
application may not work.
There are three design choices to consider:
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.
Most tables in standard MIB modules follow one of two indexing
models: associative indexing or positional/array-like indexing that
starts from one (1) or greater value.
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
Internet routing table as defined in the ipCidrRouteTable, it will
presently contain around 100,000 rows.
Associative indexing is used in ipCidrRouteTable allows one to
retrieve say all routes for a given IPv4 destination 192.0.2/24.
Yet if the goal is to extract a copy of the table the associative
indexing reduces the throughput and potentially the performance of
retrieval. This is because each of the index objects are appended to
Various Authors [Page 14]
RFC DRAFT Expires November 2001 May 2001
the object identifiers for every object 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 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
ifInvStackTable RFC 2864 [32]. They are logical equivalents with the
order of the auxiliary (index) objects simply reversed.
ifStackEntry OBJECT-TYPE
SYNTAX IfStackEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information on a particular relationship between
two sub-layers, specifying that one sub-layer runs
on 'top' of the other sub-layer. Each sub-layer
corresponds to a conceptual row in the ifTable."
INDEX { ifStackHigherLayer, ifStackLowerLayer }
::= { ifStackTable 1 }
Various Authors [Page 15]
RFC DRAFT Expires November 2001 May 2001
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
technique of organizing tables into control and data components.
Control tables contain those objects that are configured and change
infrequently and the data tables contain information to be collected
that can be large and may change quite frequently.
As an example, the RMON hostControlTable provides a way to specify
how to collect MAC addresses learned as a source or destination from
a given port that provides transparent bridging of ethernet packets.
Configuration is accomplished using the hostControlTable. It is
indexed by a simple integer. While this may seem to be array-like, it
is common use for command generators to encode the ifIndex into this
simple integer to provide associative lookup capability.
The RMON hostTable and hostTimeTable represent dependent tables that
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
Organizationally Unique Identifier (OUI) which is the first three
octets of the MAC address.
The hostTimeTable is designed explicitly for fast transfer of bulk
RMON data. It demonstrates how to handle collecting large number of
rows in the face of deletions and insertions by providing
hostControlLastDeleteTime.
Various Authors [Page 16]
RFC DRAFT Expires November 2001 May 2001
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 encoding), consider delivery of the data via an alternate
method such as FTP and use a MIB module to control that data delivery
process. In many cases this problem can be avoided via effective MIB
design.
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.
This style can be found in the REMOPS-MIB module as well.
The SNMPCONF work directly address the amount of configuration and
other data can be carried via SNMP. Other work is currently underway
to improve efficiency for all SNMP operations. This means much more
information will be conveyed with less overhead.
3.3.6. Conceptual Table Modification Practices
The RowStatus textual convention specifies that when used, in a
conceptual row, a description must define what can be modified. In
fact, it is often wrongly assumed in implementations that objects:
Various Authors [Page 17]
RFC DRAFT Expires November 2001 May 2001
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).
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 }
3.4. Index Design Issues
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
identifiers 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
identified by use of integer-valued objects should be numbered
starting from one (i.e., not from zero). The use of zero as a value
for an integer-valued index object should be avoided, except in
special cases.
Indexing tables starting from one(1) simplifies implementation as
well as allows for protocol expansion as to what .0 means for non-
scalar objects. Agent implementations that contain tables that have
simple integer indexes starting from zero(0) require the agent to
disambiguate a varbinds instance information in more detail than it
Various Authors [Page 18]
RFC DRAFT Expires November 2001 May 2001
otherwise might have. For example, a getnext ifInOctets from getnext
ifInOctets.0 becomes necessary.
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
limitations, use the INET-ADDRESS-MIB, which provides a generic way
to represent addresses for Internet Protocols.
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:
Various Authors [Page 19]
RFC DRAFT Expires November 2001 May 2001
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.
When this situation has been corrected, one of the two objects should
have the STATUS set to deprecated.
3.6. Textual Convention Usage
Textual conventions should be used whenever possible to create a
consistent semantic for an oft-recurring datatype.
Often, MIB modules 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 }
Various Authors [Page 20]
RFC DRAFT Expires November 2001 May 2001
Textual conventions that have a reasonable chance of being reused in
other MIB modules ideally should also be defined in a separate MIB
module to facilitate sharing of such objects. For example, all ATM
MIB modules draw on the ATM-TC-MIB to define common definitions.
To simplify management, it is recommended that existing SNMPv2-TC
based definitions be used when possible. For example, consider the
following object definition:
acmePatioLights OBJECT-TYPE
SYNTAX INTEGER {
on(1),
off(2),
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Current status of outdoor lighting."
::= { acmeOutDoorElectricalEntry 3 }
This could be defined as follows using existing SNMPv2-TC TruthValue.
AcmePatioLightsEnabledOn OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Current status of outdoor lighting."
::= { acmeOutDoorElectricalEntry 3 }
3.7. Persistent Configuration
Many SNMP agents presently implement simple persistence models. SNMP
set requests against MIB objects with MAX-ACCESS read-write are
typically written automatically to a persistent store. In other
cases, enterprise MIB objects are required in order to get standard
configuration stored thus making it difficult for a generic
application to have a consistent effect.
There are standard conventions for saving configuration data. The
first method uses the Textual Convention known as StorageType [6]
which 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].
Various Authors [Page 21]
RFC DRAFT Expires November 2001 May 2001
A second method for persistence simply uses the DESCRIPTION clause to
define how instance data should persist. RFC 2674 [24] defines
explicitly 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
configuration read at device initialization. The DISMAN-SCHEDULE-MIB
module provides an example of this practice.
3.8. Configuration Sets and Activation
An essential notion for configuration of network elements 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.
The document "Requirements for IP Version 4 Routers" [20], section
1.3.4 states:
A vendor needs to provide adequate documentation on all
configuration parameters, their limits and effects.
Any complex configuration should have a master on/off switch as well
as strategically placed on/off switches to control the sectional
employment of configuration data. These controls play a pivotal role
during the configuration process as well as during subsequent
diagnostics. Generally a series of set operations should not cause an
agent to act on each object causing convergence/stability possibly to
be lost on each and every set. Ideally a series of Set PDUs would
install the configuration and a final set series of PDUs would
activate the changes.
During diagnostic situations, certain on/off switches can be set to
localize the perceived error instead of having to remove the
configuration.
An example of such an object from the OSPF Version 2 MIB [27] is the
Various Authors [Page 22]
RFC DRAFT Expires November 2001 May 2001
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 }
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:
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 }
Various Authors [Page 23]
RFC DRAFT Expires November 2001 May 2001
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 }
RowStatus objects should not be used to control
activation/deactivation of a configuration. While RowStatus looks
ideally suited for such a purpose since a management application can
set a row to active(1), then set it to notInService(2) to disable it
then make it active(1) again, there is no guarantee that the agent
won't discard the row while it is in the notInService(2) state. RFC
2579, page 15 which 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 schedAdminStatus to disabled(2) does not cause the row to
be aged out/removed from the table.
Lastly, 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-
Various Authors [Page 24]
RFC DRAFT Expires November 2001 May 2001
write objects assume that an agent can complete a set operation as
quickly as an agent can send back the status of the set operation to
the application.
Consider the 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)
|
| 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....
|
Various Authors [Page 25]
RFC DRAFT Expires November 2001 May 2001
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
spinCounterClockwise(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.
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 commands in the system can often be longer than
the SNMP response timeout.
3.10. Notifications and Error Reporting
Notifications can be an important part of an effective SNMP-based
management system. They can often be over-used. This section offers
some guidance for effective notification generation. Notifications
can also play a key role for all kinds of error reporting from
hardware failures to configuration and general policy errors. These
types of notifications must be designed in as shown in the section on
Application Error Reporting.
3.10.1. Designing Notifications
Notifications can play an important role in configuration. With
SNMPv2c and SNMPv3, informs allow the design of reliable, event-
driven synchronization models that can aid configuration.
When designing new notifications, consider how to limit the number of
notifications (traps or informs) that can be sent in response to an
Various Authors [Page 26]
RFC DRAFT Expires November 2001 May 2001
event. RMON I[30] defines a generic trap capability in the alarmTable
and provides one of many ways to prevent the quantity of
notifications from overwhelming a management system.
Another way to limit the volume of a particular notification is to
define situations where it need not be sent. A good example is the
frDLCIStatusChange defined in FRAME-RELAY-DTE-MIB, RFC 2115 [19].
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 }
3.10.2. Control of Notification Subsystem
There are standards track MIB modules that define objects that either
augment or overlap control of notifications. For instance, FRAME-
RELAY-DTE-MIB RFC 2115 defines frTrapMaxRate and DOCS-CABLE-DEVICE-
MIB defines a set of objects in docsDevEvent that provide for rate
limiting and filtering of notifications.
In the past, agents did not have a standard means to configure a
notification generator. With the availability of the SNMP-
NOTIFICATION-MIB Module in RFC 2573, it is strongly recommended that
the filtering functions of this MIB module be used. If not, 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.10.3. Application Error Reporting
MIB Module designers should not rely on the SNMP protocol error
reporting mechanisms alone to report application layer error state
for objects that accept SET operations.
Most MIB modules that exist today provide very little detail as to
why a configuration request has failed. Often the only information
provided is via SNMP protocol errors which is generally not enough
information as to why a agent rejected a set request. The burden on
Various Authors [Page 27]
RFC DRAFT Expires November 2001 May 2001
the configuration application to determine if there is a resource
issue, a security issue, or application error issue is large.
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 information may aid in debugging the integrated system.
As an example of tracking errors, consider the hrPrinterTable from
the HOST-RESOURCES-MIB, RFC 2790:
Various Authors [Page 28]
RFC DRAFT Expires November 2001 May 2001
hrPrinterDetectedErrorState OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object represents any error conditions detected
by the printer. The error conditions are encoded as
bits in an octet string, with the following
definitions:
Condition Bit #
lowPaper 0
noPaper 1
lowToner 2
noToner 3
doorOpen 4
jammed 5
offline 6
serviceRequested 7
inputTrayMissing 8
outputTrayMissing 9
markerSupplyMissing 10
outputNearFull 11
outputFull 12
inputTrayEmpty 13
overduePreventMaint 14
Bits are numbered starting with the most significant
bit of the first byte being bit 0, the least
significant bit of the first byte being bit 7, the
most significant bit of the second byte being bit 8,
and so on. A one bit encodes that the condition was
detected, while a zero bit encodes that the condition
was not detected.
This object is useful for alerting an operator to
specific warning or error conditions that may occur,
especially those requiring human intervention."
::= { hrPrinterEntry 2 }
Notifications can also be used to signal configuration failures with
detailed failure information objects.
3.11. Other MIB Module Design Issues
Various Authors [Page 29]
RFC DRAFT Expires November 2001 May 2001
3.11.1. Octet String Aggregations
The OCTET STRING syntax is 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.
For example:
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 }
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.
When using OCTET STRINGS, avoid platform dependent data formats.
Also avoid using OCTET STRINGS where a more precise SMI syntax such
as SnmpAdminString or BITS would work.
There are many MIB modules that attempt to optimize the amount of
data sent/received in a SET/GET PDU by packing octet strings with
aggregate data. For example, the PortList syntax as defined in the
Q-BRIDGE-MIB (RFC 2674) 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
Various Authors [Page 30]
RFC DRAFT Expires November 2001 May 2001
value of this object. If that bit has a value of '1'
then that port is included in the set of ports; the port
is not included if its bit has a value of '0'."
SYNTAX OCTET STRING
This compact representation saves on data transfer but has some
limitations. Such complex instance information is difficult to
reference outside of the object or use as an index a table.
Providing an SNMP Table to represent aggregate data does avoids the
limitations of encoding data into OCTET STRINGS and is thus the
better general practice.
3.11.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 the SYSAPPL-MIB [RFC2287]. 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
implementations that might support multiple instances of OSPF, IP
Stack or logical bridges.
In such cases, the ENTITY-MIB [RFC2737] can provide a means for
supporting the one-to-many relationship through naming scopes using
the entLogicalTable. There are some drawbacks to this approach.
1) One cannot issue PDU request that span naming scopes
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) It creates a dependency on the Entity MIB for
an application to be able to access multiple
instance information.
3.11.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
Various Authors [Page 31]
RFC DRAFT Expires November 2001 May 2001
specification in the DESCRIPTION clause of any particular details.
The REFERENCE clause is also recommended to help an implementer track
down related information on a given object.
4. IMPLEMENTING SNMP CONFIGURATION AGENTS
4.1. Operational Consistency
Successful deployment of SNMP configuration systems depends on
understanding the roles of MIB module design and agent design.
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 may
cause Set2 operation to fail owing to interactions with the operation
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
actually 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 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 -
Various Authors [Page 32]
RFC DRAFT Expires November 2001 May 2001
it is a type of API.
2. 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.
4.2. Handling Multiple Managers
Devices are often modified by multiple management entities and with
different management techniques. It is sometimes the case that an
element is managed by different organizations such as when a device
sits between administrative domains.
There are a variety of approaches that management software can use to
ensure synchronization of information between the manager(s) and the
managed elements.
An agent should report configuration changes 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) to which it
has been assigned. The managers 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
synchronized with each other.
4.3. Designing MIB Modules for Multiple Managers
When designing a MIB Module for configuration, consider the following
to provide support for multiple managers.
The first consideration 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 [RFC2579] defines
TestAndIncr, often called a spinlock, which is used to avoid race
Various Authors [Page 33]
RFC DRAFT Expires November 2001 May 2001
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 example can be found in the SNMP-TARGET-MIB
snmpTargetSpinLock.
Second, an agent should be able to report configuration as set by
different entities as well as distinguish configuration defined
locally such as a default or locally specified configuration made
through an alternate management interfaces like a command line
interface. 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
ownership can be a useful diagnostic tool as well. Specifically, the
use of the string "monitor" to identify configuration set by an
agent/local management has been useful in applications.
Third, consider whether there is a need for multiple managers to
configure the same set of tables. If so, an "OwnerString" may be used
as the first component of a table's index to allow VACM to be used to
protect access to subsets of rows per manager. RFC 2591 section 6
presents this technique in detail.
Various Authors [Page 34]
RFC DRAFT Expires November 2001 May 2001
4.4. Specifying Row Modifiability
Once a RowStatus value is active(1) for a given row, the management
application should be able to determine what the semantics are for
making additional changes to a row. RMON I MIB control table objects
spell out explicitly what managed objects in a row can and cannot be
changed once a given RowStatus goes active.
As described earlier, some operations take some time to complete.
Some systems also require that they remain in a particular state for
some period before moving to another. In some cases a change to one
value may require re-initialization of the system. In all of these
cases, the DESCRIPTION clause should contain information about
requirements of the managed system and special restrictions that
managers should observed.
4.5. Order of varbinds in a SET PDU
When a given SET PDU contains multiple varbinds, agents conforming to
the SNMP should be able to process the varbinds in any given order.
In practice, it is often preferable that management applications send
the varbinds in the order they are defined in the MIB module.
4.6. 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.
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 provide, regardless of the method used to convey
configuration information to the managed systems are: backup, fail-
over, and restoration. A management system should have the following
features:
1. A method for restoring a previous configuration to one or
more devices. Ideally this restoration should be time indexed
so that a network can be restored to a configured state as of
Various Authors [Page 35]
RFC DRAFT Expires November 2001 May 2001
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
deployed in such a way that it does not cause duplicate
polling of configuration.
These three capabilities are of course important for other types of
management that are not the focus of this BCP.
5.1. Designing Configuration Management Software
This section focuses on general issues related to the development of
SNMP based applications (command generators) that configure one or
more network elements. Special consideration is given to what has
come to be known as policy-based management with SNMP. Effective
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
configuration 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
There are three basic areas 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
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,
Various Authors [Page 36]
RFC DRAFT Expires November 2001 May 2001
the specific configuration parameters for a given operation are
likely to change over time. Even in the case of a configuration
application that is designed for a single vendor, the management
application should allow for variability in the MIB objects that will
be used to configure the device for a particular purpose. The best
method to accomplish this is by separating, as much as possible, the
operational semantics of a configuration operation from the actual
data. One way that some applications achieve this is by having the
specific configuration objects that are associated with a particular
device be table driven rather than hard coded. Ideally, management
software should verify the support in the devices it is 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.3. 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 management software to the
smallest reasonable number. One approach to this is to verify the
largest number of variable bindings that can fit into a SET PDU for a
managed device. In some cases, the number of variable bindings to be
sent in a particular PDU will be influenced by the device, the
specific MIB objects and other factors.
Maximizing SET variable bindings within a PDU has beneficial
implications 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.
5.4. Configuration Transactions
There are several types of configuration transactions that can be
supported by SNMP-based configuration applications. They include
transactions on a scalar object, a single table, 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
Various Authors [Page 37]
RFC DRAFT Expires November 2001 May 2001
within the scope of the configuration operation.
To make use of any kind of transaction semantics effectively, SNMP
management software must be aware of the information in the MIB
modules that it is to configure so that it can effectively utilize
RowStatus objects for the control of transactions on one or more
tables. Such software must also be aware of control tables that the
device supports that are used to control the status of one or more
other tables.
To the greatest extent possible, the management application should
provide the facility to support transactions across multiple devices.
This means that if a configuration operation is desired across
multiple devices, the manager can coordinate these configuration
operations such that they become active as close to simultaneously as
possible.
Several practical means are present in the SNMP model that support
management application level transactions. One was mentioned in the
preceding section. 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 or set of PDUs
if 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 effective
means of affording an opportunity for per-row rollback, particularly
when the configuration change is across table row instances on
multiple managed devices.
5.5. 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 configuration management applications may consume data
from the managed devices that reflect configuration, operational and
utilization state information. The GetBulkRequest-PDU is useful here
whenever supported by the managed device. For the purposes of
backward compatibility, the management station should also support
and make use of the GetNextRequest-PDU in these cases.
Various Authors [Page 38]
RFC DRAFT Expires November 2001 May 2001
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.6. Scale of the Management Software
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 different 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 responsibilities 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
Network devices are configured using many mechanisms, however two
methods remain the most common: SNMP and Command Line Interface
(CLI).
Effective use of these mechanisms involves an operational methodology
for deploying changes to networks in a cautious and incremental
manner with well-documented procedures. The collective intent of
these procedures is to guarantee that a configuration change to the
network has the intended effect on the affected network elements.
Here is one such procedural model in detail:
Network Scope Input Procedural Step Output
------------------ ----- --------------- ------
Lab isolated from (1) Stage configuration Verify reliability
main network change with test of config change
device set and
(SNMP action: interoperability
determine distribution with prior system
of CLI and SNMP versions and
set actions for backwards
configuration change) compatibility
Various Authors [Page 39]
RFC DRAFT Expires November 2001 May 2001
with prior
configuration
(2) Plan noncritical/ Fall back strategy
off hour window in case of change
(SNMP action: none) failure
Segmented edge of (1),(2) (3) Apply change to CLI Verified device
main network of network segment accept of
network elements configuration
(SNMP action: none) change
(1),(3) (4) Observation of Verified device
devices/networks over and network
time after change stability, proper
(SNMP action: effect of changes
monitor status of
SNMP read-only objects
which are companions
to SNMP set objects
for configuration
change)
(4) (5) Save changes to Verify integrity
persistent storage of changes after
of devices device restart
(SNMP action: SET
on controls to move
running config to
restart/persistent)
Expanded network (1),(2),(5) (6) Deploy changes, Verification of
segments, iterative using CLI and SNMP. safety from any
to complete network Keep prior unanticipated
configuration on some SNMP defaulting
devices to allow behavior in mixed
fallback in case environment
of failure
(SNMP action: SET
on SNMP objects
determined in (1))
(4),(6) (7) Continue to Checkpointed
Various Authors [Page 40]
RFC DRAFT Expires November 2001 May 2001
observe devices and verification
network for of anticipated
behavioral/service behavior
anomalies
(SNMP action:
same as (4) across
devices of expanded
network)
(7) (8) Expand deployment Checkpointed
and iteration to (6) verification
as called for of anticipated
(SNMP action: behavior
same as (6) across
expanded network)
Network revision (8) Update archived Change deployment
control system configurations, complete.
change log.
(SNMP action: none)
Procedures such as those above bring about a form of operational
transactionality, which works alongside (and employs) SNMP
transactionality. The key goals throughout are
o Transactionality of configuration change deployment
o Persistence of configuration change which can be verified for
resulting stability, convergence, and realization of intended
effect of change.
Considerations for bringing about this verification are
discussed in the following section.
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.
Various Authors [Page 41]
RFC DRAFT Expires November 2001 May 2001
Network elements in conjunction with the configuration mechanism must
take appropriate measures to leave the configuration in a
consistent/recognizable state by either rolling back to a previously
valid state or changing to a well-defined or default state.
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" and the later "near real-time change
control." 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 interfaces. 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.
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,
passwords and other such sensitive information and hence must be
protected from unauthorized access.
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
Various Authors [Page 42]
RFC DRAFT Expires November 2001 May 2001
bit DES keys protecting the SNMP transmission.
The DESCRIPTION clause for these and their defining MIB RFC Security
Considerations section 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
difficult. This led to objects being defined such as the following.
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.
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.
See the prior section "Naming MIB modules and Managed Objects "
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
Various Authors [Page 43]
RFC DRAFT Expires November 2001 May 2001
SNMP can be efficiently performed with several of the techniques
described earlier in this document. This policy section shows how
even greater efficiency can be achieved using the new SNMPCONF
technology. This section gives background and defines terms that are
relevant to this field and describes some deployment approaches.
7.1. Organization of Data in an SNMP-Based Policy System
The number of configurable parameters and 'instances' such as
interfaces has increased as equipment has become larger and more
complex. At the same time, there is a need to configure many of these
systems to operate in a coordinated fashion. This enables the
delivery of new specialized services that require this coordinated
configuration. Examples include: delivery of virtual private
networks and connections that guarantee specific service levels.
The growth in size and complexity of configuration information has
significant implications for its organization as well as its
efficient transfer to the management agent. As an example, an agent
that implements the Bridge MIB [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 system
setting the default values to the selected ports.
To date, that configuration has been accomplished to now is with file
transfer, by setting individual MIB objects, or with many CLI
commands. In each of these approaches the details for each instance
are contained in the file, CLI commands or MIB Objects. That is, they
contain not only the value, and type of object, but also the exact
instance of the object to which to apply the value. It is this
property that tends to make configuration operations explode as the
number of instances such as interfaces grows. This [instance-
specific approach] can work for a few machines configured by experts,
but there is a need for a more scalable solution. 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
Various Authors [Page 44]
RFC DRAFT Expires November 2001 May 2001
defines under what conditions the defaults (policy) is to be applied.
In short, we need to layer the information so that simple commands
can be sent to devices which then are expanded to produce the
increased (instance level) information that devices require for
operation.
7.2. Conceptual Layering
In order to present the principles of policy based management with
SNMP, we will create a MIB Module called the Building Heating
Ventilation and Air Conditioning (HVAC) MIB Module. This allows the
discussion to focus on the new principles as opposed to a specific
area of technology. Note that while the focus of this discussion is
on configuration, the abstractions discussed in this section could
equally apply to fault, performance, accounting or security objects.
Instance-Specific
Instance-specific information refers to values associated with a
specific instance in a managed element. One example would be the
number of octets that were received on a particular interface,
ifInOctets. In our example MIB Module, we will have fan and
temperature settings for every control panel in the building. Imagine
how many there would be in a 50-story office building or multi-acre
office park. Network operators have a similar problem, in all of the
parameters for the many routers and the interfaces they contain.
Each interface will have an ever increasing number of values that
must be configured to deliver specialized services such as
Differentiated Services.
Mechanism-Specific
The first layer of abstraction above the familiar instance-specific
level is called "mechanism-specific". This is the level that contains
the defaults that would be used to assign values to instance-specific
objects.
A "mechanism" is a specific way to realize a function. For example,
in the area of routing, BGP has a number of mechanisms that are used
to realize specific behavior. As a result, there are many parameters
that apply specifically to BGP and its associated mechanisms that it
uses to accomplish it's routing task such as time-out values etc.,
that BGP uses to accomplish its routing task.
Various Authors [Page 45]
RFC DRAFT Expires November 2001 May 2001
MIB objects that are mechanism-specific are the defaults used for
instance-specific MIB object creation or modification. They are the
defaults for standard instance-specific MIB objects when used in an
SNMP-based policy system. In our HVAC example, we have several
mechanisms that are used in the standard MIB module to control how
fast a fan is to turn and what position a switch is to be in for
heating or cooling.
Mechanisms have on additional attribute that distinguishes them. They
are technologies defined in standards that are used within a
particular domain as in our routing example. Mechanism-specific MIB
Objects then, are a layer of abstraction above standards-based
instance-specific MIB objects.
Implementation-Specific
Vendors often add special capabilities to standards as a way of
meeting special customer requirements or differentiating themselves
from competitors. Implementation-Specific MIB objects have the same
properties as mechanism-specific ones except they have been created
as abstractions for vendor created instance-specific MIB objects.
These special capabilities are often a result of the implementation
approach that a vendor has used for the product, which is the reason
for the term "implementation-specific". In our HVAC example, some
vendors might extend the standard to include features that
distinguish their products from their competition. In our example MIB
module, the system is a sophisticated one and allows for the control
of the humidity, which is not part of the HVAC standard MIB Module
and as such there would be no mechanism-specific MIB objects for
humidity.
In summary, implementation and mechanism specific MIB objects occupy
the same level of abstraction in our hierarchy. The only difference
is that mechanism-specific MIB Objects are defined in a standards
body, while implementation-specific objects are defined by vendors in
the same way that vendors define their extensions today.
Higher Levels of Abstraction
If the world consisted of only of MIB and protocol experts, the
abstractions described above would be sufficient. They enable the
efficient transfer of information from management systems to managed
devices. The fact is that many people who know nothing about the
Various Authors [Page 46]
RFC DRAFT Expires November 2001 May 2001
protocol details need to use systems that manage SNMP-based
configuration data that know nothing about the protocol details.
There are vendor and model differences that make the addition of two
layers above the mechanism and implementation-specific layer helpful.
The higher levels of abstraction that are defined next help achieve
some important operational goals and make it possible to write better
management software. Here are some of benefits for organizing SNMP-
based information into higher levels of abstraction:
1. Abstract the details of the differences in technology away
from the users. This is a common principle in
programming. The user of a service should not have to know
the details of how the service is implemented. OSPF and BGP
are both routing protocols but have different "knobs". If you
want to add a new system to the network today, you must have
an expert in both if you use both technologies. Different
implementations of WEB servers have different "knobs". To
change a configuration or add a new service to each, you need
a person who knows the individual knobs. A solution to this
is to write software that abstracts above this level.
2. Abstract the differences from one vendor to another. Even
when standard technologies are implemented, vendors will have
variations. In a multi-vendor environment this means that not
only do you require technology experts, but you have to have
experts who know the differences in the knobs for each
technology for each vendor. In the case of SNMP, these knobs
are MIB Objects.
Domain-Specific
A useful way to abstract information above that which is exposed in
instance-specific,implementation or mechanism-specific MIB Objects is
at the level of "domain'.
A domain is a short-hand way of referring to all mechanisms used for
a common task or provisioning of a particular technology.. In the
routing examples we have been using, BGP would be one domain that
contains many mechanisms. This is also true for OSPF. The same is
true in the area of Quality of Service, there are many areas of
technology (domains) that could be used to deliver quality of
service. Differentiated Services or 802.1p are two examples that have
very different mechanisms. Our HVAC MIB module has a single knob for
the mechanism that is used to control the climate inside a building.
Various Authors [Page 47]
RFC DRAFT Expires November 2001 May 2001
In our case, the desired temperature is the knob which causes fan
speed to change. It is possible to imagine a very different set of
technology that instead of using fans, controlled exposure of solar
cells to change the temperature. The SNMP infrastructure gives us a
number of convenient ways to reference domains though the mapping is
not always perfect. These handles include the base OID of a MIB
Module or the tables in a MIB Module.
Since the OIDs are not necessarily contiguous, several of them may be
used to specify a domain. In the future IANA could become a registry
for such identifiers.
The Services Layer
Some management applications may find it helpful to present one layer
of abstraction above the domain level: services. At this layer we no
longer refer to specific technologies such as BGP, OSPF, or
Differentiated Services. We refer to routing or Quality of Service.
This is the layer that many business operate at. One example is that
they sell Web or Name services without referencing the specific
technology domain that will be used to realize the service. For
example, n most circumstances they, will certainly not reference the
mechanisms used to realize the Web Services.
7.2.1. Conceptual Layering Diagrams
The following diagrams illustrate the layers just described. Notice
that there are two boxes. The first represents a management
application that could be running anywhere in the network, including
inside a managed device. The more common location for such an
application would be on a dedicated management platform. The second
box illustrates a policy-enabled network element such as a router
using SNMPCONF technology. The SNMPCONF Policy Engine in the diagram
refers to the Policy Based Management MIB. It shows how the Policy
Engine can access data in a managed device at the mechanism,
implementation or instance specific levels.
Just as the SNMPCONF Policy Engine may contain and control management
information at several layers of abstraction, so too can the
management application. As a general rule, the management application
will have access to information at all layers of abstraction, both in
its internal data store and in each of the network elements that it
has been assigned to manage.
It is also likely that such a policy management system will also have
Various Authors [Page 48]
RFC DRAFT Expires November 2001 May 2001
access to and leverage the significant SNMP-based range of available
information in the areas of fault, performance, accounting and
security. This information can be valuable in making correct
decisions about what policies to install in a managed device.
A Policy Management Application
---------------------------------------------------------------
| Applications with access to information at all layers of |
| abstraction: Service, Domain, Mechanism/Implementation and |
| instance. |
---------------------------------------------------------------
| Policy Installation ^ Installation Results
| (information at any | State and Status
| level of abstraction) | Information - also
| | at any level of
v | abstraction
--------------------------------------------------------------
| SNMPCONF Policy |
| Engine |
| ^ ^ |
| | |-------------------------- |
| | | | |
| | v v |
| | Mechanism-specific Implementation-specific |
| | MIB objects MIB objects |
| | (e.g., defaults ^ |
| | for DiffServ or | |
| | IPsec) | |
| | ^ | |
| | | | |
| |----------------------------------- | |
| | | | | |
| | | | | |
| v v v v |
| Instance-specific Instance-specific |
|standard MIB objects vendor-specific MIB objects |
| (e.g., interface |
| settings, BGP |
| settings, IPsec |
| settings) |
--------------------------------------------------------------
Conceptual view of objects configured using the PM-MIB
Appendix A has an example of the interaction between the Policy Agent
and the rest of the system for OSPF.
Various Authors [Page 49]
RFC DRAFT Expires November 2001 May 2001
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 configuration operations to do.
For this discussion it is important to make distinctions between
distribution of policy to a system, activation of a policy in a
system, and changes/failures that take place during the time it is
expected to be active. For example, if an interface is down that is
included in a policy that is distributed, there may not be an error
since the policy may not be scheduled for activation until a later
time. On the other hand if a policy is distributed and applied to an
interface that should be operational and it is not, clearly this is a
problem. With this as background, here are some areas to consider
that are important to making good policy configuration decisions and
establishing when a policy has 'failed'.
o The operational state of network elements that are to be
configured.
Care should be taken to determine if the sub-components to be
configured are available for use. In some cases the elements may
not be available. The policy configuration software should
determine if this is a prerequisite to policy installation or if
the condition is even acceptable. This decision is separate from
the one to be made about policy activation. Installation is when
the policy is sent from the policy manager to the managed device
and activation is turning on the policy. In those cases where
policy is distributed when the sub-component such as an
interface or disk is not available, the managed system should
send a notification to the designated management station when
the policy is to become active or if the resource is still not
available.
o The capabilities of the devices in the network.
A capability can be almost any unit of work a network element
can perform. These include, routing protocols supported, Web
Server and OS versions, queuing mechanisms supported on each
interface that can be used to support different qualities of
service, and many others. this information can be obtained from
the capabilities table of the Policy MIB module.
Various Authors [Page 50]
RFC DRAFT Expires November 2001 May 2001
o The capacity of the devices to perform the desired work.
Capability is an ability to perform the desired work while a
capacity is a measure of how much of that capability the system
has. The policy configuration application should, wherever
possible, evaluate the capacity of the network element to
perform the work identified by the policy. In some systems it
will not be possible to 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 application may benefit from
pre-configured information about the capacity of different
network elements so that evaluations of the resources available
can be made before distributing new policies. Utilization
refers to how much capacity for a particular capability has been
consumed. For devices that have been under policy configuration
control for any period of time, a certain percentage of the
available capacity of the managed elements will be used.
Policies should not be distributed to systems that do not have
the resources to carry out the policy in a reasonable period of
time.
7.4. Policy, Mechanism/Implementation and Instance Specific Modules
A agent could implement the policy module without any mechanism or
implementation-specific modules. For complicated configuration areas
such as Differentiated Services, Web servers, routing protocols,
etc., mechanism and frequently implementation-specific MIB modules
will be required.
If a vendor implements a standard set of instance-specific MIB
objects and an RFC has not yet been defined for a mechanism-specific
set of objects to control the policy based configuration of these
instance-specific objects, the vendor should create such a module
allowing for the fact that an RFC might be issued later for the
mechanism-specific module. To the extent a vendor creates instance-
specific extensions to standard instance-specific MIB modules, they
should also create implementation-specific MIB modules if the intend
the box to be most effectively configured with policy-based
management. Many vendors create proprietary functions and the
instrumentation to manage them. To enable these features to be
integrated into an SNMP-based policy management system, both instance
and implementation-specific MIB objects should be created.
Various Authors [Page 51]
RFC DRAFT Expires November 2001 May 2001
7.5. 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 directives that contain time zone relevant
data. For this reason, policy management applications should have the
ability to ascertain the time keeping abilities of the managed system
and make adjustments to the policy for those systems that are time-
zone challenged.
7.6. Conflict Detection, Resolution and Error Reporting
Policies sent to a device may contain conflicting instructions.
Detection of such commands can occur at the device or management
level and may be resolved using any number of mechanisms (last one
wins, 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.
The responsibilities for each layer are: Instance-specific: Conflict
detection has been performed in a limited way for some time in
software that realizes instance- specific MIB objects. 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.
Mechanism and implementation-specific: For software that realizes
mechanism and/or implementation-specific objects, 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
reporting which is does not perform any policy conflict detection,
there are no requirements. See the Policy MIB Module document for
additional information on policy precedence and conflict detection.
Various Authors [Page 52]
RFC DRAFT Expires November 2001 May 2001
Changes to configuration outside of the policy 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 notification 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 element 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.7. 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.
7.8. Using Policy to Move Less Configuration Data
One of the advantages of policy-based configuration with SNMP is that
many configuration operations can be conveyed with a small amount of
data. Changing a single configuration parameter for each of 100
interfaces on a system might require 100 CLI commands or 100 SNMP
variable bindings using conventional techniques.
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
Various Authors [Page 53]
RFC DRAFT Expires November 2001 May 2001
of eliminating the need to send the value for each instance to be
configured. The 'default' for each of the instances included in the
policy is sent and the rule for selection of the instances that the
default is to be applied 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 pmPolicyTable, and entire policy
that potentially controls hundreds of rows of information can be
retrieved in a single GET request.
8. Example MIB Module For Policy-Based Management
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 mechanism specific level
are also included.
These tables in combination with the policy MIB Module will allow
operators to configure 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 policy.
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,
Various Authors [Page 54]
RFC DRAFT Expires November 2001 May 2001
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 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 policy such as: "provides high quality packet
forwarding for Voice over IP customers". The details are:
bldgHVACCfgPolicyIndex
bldgHVACCfgPolicyDescription
bldgHVACCfgPolicyOwner
bldgHVACCfgPolicyStatus
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 policy and
instance which can save some additional data movement. Every
Various Authors [Page 55]
RFC DRAFT Expires November 2001 May 2001
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:
bldgHVACCfgTemplateDescrPtr
bldgHVACCfgTemplateOwner
bldgHVACCfgTemplateStorage
bldgHVACCfgTemplateStatus
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
Various Authors [Page 56]
RFC DRAFT Expires November 2001 May 2001
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 9999 }
bldgHVACObjects OBJECT IDENTIFIER ::= { bldgHVACMIB 1 }
bldgConformance OBJECT IDENTIFIER ::= { bldgHVACMIB 2 }
--
-- 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
Various Authors [Page 57]
RFC DRAFT Expires November 2001 May 2001
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 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,
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)
Various Authors [Page 58]
RFC DRAFT Expires November 2001 May 2001
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 policy. 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
bldgHVACCfgPolicyTable. The benefit of this approach is
that all configuration information is available in one
table whether all elements in the system are under policy
control or not."
::= { bldgHVACEntry 3 }
bldgHVACFanSpeed OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
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
Various Authors [Page 59]
RFC DRAFT Expires November 2001 May 2001
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 }
--
-- HVAC Configuration Policy Table
--
bldgHVACCfgPolicyTable OBJECT-TYPE
SYNTAX SEQUENCE OF BldgHVACCfgPolicyEntry
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 policyname. The
bldgHVACCfgCfgPolicyDescription contains a brief
description of the policy such as: provides high quality
packet forwarding for Voice over IP customers. The
bldgHVACCfgDescrPolicyPtr 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
Various Authors [Page 60]
RFC DRAFT Expires November 2001 May 2001
the bldgHVACCfgTemplateTable be identifiable as being
under policy control though this mechanism."
::= { bldgHVACObjects 2 }
bldgHVACCfgPolicyEntry OBJECT-TYPE
SYNTAX BldgHVACCfgPolicyEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each row represents a particular policy and description."
INDEX { bldgHVACCfgPolicyIndex }
::= { bldgHVACCfgPolicyTable 1 }
BldgHVACCfgPolicyEntry ::= SEQUENCE {
bldgHVACCfgPolicyIndex DisplayString,
bldgHVACCfgPolicyDescription DisplayString,
bldgHVACCfgPolicyOwner SnmpAdminString,
bldgHVACCfgPolicyStatus RowStatus
}
bldgHVACCfgPolicyIndex 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 policy
so that all systems in a network that are under the same
policy can have the same 'handle'."
::= { bldgHVACCfgPolicyEntry 1 }
bldgHVACCfgPolicyDescription OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A general description of the policy. One example might be -
Controls the cooling policy for offices on higher floors
during the summer."
::= { bldgHVACCfgPolicyEntry 2 }
bldgHVACCfgPolicyOwner OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The identity of the operator/system that last modified
this entry."
Various Authors [Page 61]
RFC DRAFT Expires November 2001 May 2001
::= { bldgHVACCfgPolicyEntry 3 }
bldgHVACCfgPolicyStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this row."
::= { bldgHVACCfgPolicyEntry 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 policy defaults that will be
placed on the specific offices that match the
pmPolicyFilter. See the policy MIB Module for more
information."
::= { bldgHVACObjects 3 }
bldgHVACCfgTemplateEntry OBJECT-TYPE
SYNTAX BldgHVACCfgTemplateEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each row represents a single set of policy 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,
bldgHVACCfgTemplateDescrPtr RowPointer,
bldgHVACCfgTemplateOwner SnmpAdminString,
bldgHVACCfgTemplateStorage StorageType,
bldgHVACCfgTemplateStatus RowStatus
}
bldgHVACCfgTemplateIndex OBJECT-TYPE
Various Authors [Page 62]
RFC DRAFT Expires November 2001 May 2001
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A unique value for each defined template in this
table. This value be 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
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 }
bldgHVACCfgTemplateDescrPtr 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
Various Authors [Page 63]
RFC DRAFT Expires November 2001 May 2001
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 }
-- 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 bldgHVACObjects
DESCRIPTION
"The bldgHVACObjects is mandatory for all systems that
support HVAC systems."
::= { bldgCompliances 1 }
bldgHVACObjectsGroup OBJECT-GROUP
OBJECTS {
bldgHVACFloor, bldgHVACOffice, bldgHVACCfgTemplatePtr,
Various Authors [Page 64]
RFC DRAFT Expires November 2001 May 2001
bldgHVACFanSpeed, bldgHVACCurrentTemp,
bldgHVACCoolOrHeatMins, bldgHVACOwner, bldgHVACStatus,
bldgHVACCfgPolicyIndex, bldgHVACCfgPolicyDescription,
bldgHVACCfgPolicyOwner, bldgHVACCfgPolicyStatus,
bldgHVACCfgTemplateIndex, bldgHVACCfgTemplateDesiredTemp,
bldgHVACCfgTemplateCoolOrHeat,
bldgHVACCfgTemplateDescrPtr,
bldgHVACCfgTemplateOwner,bldgHVACCfgTemplateStorage,
bldgHVACCfgTemplateStatus
}
STATUS current
DESCRIPTION
"The bldgHVACObjects Group."
::= { bldgGroups 1 }
END
8.1. NOTES ON MIB MODULE FOR POLICY-BASED MANAGEMENT
The primary purpose to the sample MIB module is to show how to
construct a single module that includes configuration, policy,
counter and state information in a single module. If this were a
'real' module we would also have included definitions for
notifications for the configuration change operations as previously
described. We also would have included notifications for faults and
other counter threshold events.
Implementation and Instance Extensions:
Just as with networking technologies, vendors may wish to add
extensions that can distinguish their products from the competition.
If an HVAC vendor also wanted to support humidity control, they could
add that facility to their equipment and use AUGMENTS for the
bldgHVACPolicyTable with two objects, one that indicates the desired
humidity and the other, the actual. The bldgHVACPolicyTable could
also be extended using this same approach so that HVAC policies could
easily be extended to support this vendor.
Fate Sharing
A property of two Internet protocol resources or management data
control objects wherein there is a dependency between their
individual state transitions. If the relationship between them
becomes inoperable or invalidated, there will be a predictable
Various Authors [Page 65]
RFC DRAFT Expires November 2001 May 2001
behavior for the removal of the relationship (and possibly, one or
both of its parties in their entirety).
Persistence
A property of management data that defines its permanence.
Specifically, for the purposes of this document, persistence defines
whether a change in configuration on a managed element will have that
change reflected across power cycles (and associated operational
configuration data store re-initialization) of the managed element.
Time-indexed
For this document, this refers to data (and in particular, data
describing events of configuration set or notification), which is
tagged with the agent or management station time of event occurrence.
This is often used in SNMP management systems to correlate events
over an elapsed indexed time sequence with each other for purposes of
transactional grouping.
TimeStamp
A textual convention containing a managed element sysUpTime value,
generally to reflect the element-relative time of the occurrence of a
given associated event.
Transaction
A finite group of changes that when taken as a whole can be applied
or rolled back in one operation. For example, a single SNMP SET PDU
represents a transaction for which the state before the set is
restored when any individual element in the variable-bindings list
fail to be applied thus returning the device to exactly the same
state before the SET was executed.
9. APPENDIX A - Policy Example
OSPF, is a common routing protocol. RFC 1850 contains the OSPF
Version 2 MIB Module. In that module are a number of configuration
parameters, two have been selected for policy control in this
example; the Hello and Dead interval timers.
This example depicts how the policyScript can be used to maintain
common Hello and Dead interval Across different subnets in an OSPF
routing domain.
Various Authors [Page 66]
RFC DRAFT Expires November 2001 May 2001
The 'ospfIfHelloInterval' is the length of time, in seconds, between
the Hello packets that the router sends on the interface. This value
must be same for all routers attached to a common network. The
packets have not been seen before its neighbors declare the router
down. This value must be the same for all routers attached to a
common network.
A policy to maintain common Hello and Dead interval across different
sub-net can be expressed as:
If network is 10.50.5.0/24
set ospfIfHelloInterval = 15 and ospfIfRtrDeadInterval = 60
else /* default value */
set ospfIfHelloInterval = 10 and ospfIfRtrDeadInterval = 40
The picture below depicts realization of this policy using
policyScript.
+--------------------------------+
|pmElementTypeRegTable |
|index=1 //ospfIfEntry |
|oid=1.3.6.1.2.1.14.7.1 |
|Name = ospfIfEntry |
+--------------------------------+
+--------------+
|pmPolicyTable |
|Filter=1 -----+----+
|Action=2 -----+----|-----------------------+
+--------------+ | |
| |
+------------V-----+ +--------V----------+
|pmPolicyCodeTable | |pmPolicyCodeTable |
|Index =1 | |Index=2 |
|Segment=1 | |Segment=1 |
+--------+---------+ +-----------------+-+
| |
| |
+---------------V------------------------------+ |
| | |
| if(insubtree(elementName(),"ospfIfEntry")&&| |
| (getvar("ospfIfStatus")==1) && | |
| (inSubNet(getvar("ospfIfIpAddress.$0"), | |
| "10.50.5.0/24")= 0)) | |
| return 0; | |
| else | |
| return 1; | |
+----------------------------------------------+ |
|
Various Authors [Page 67]
RFC DRAFT Expires November 2001 May 2001
+----------------------------------------------------V---------+
| var pdu; |
| int HELLO_INTERVAL1=15; /* 15 seconds */ |
| int RTRDEAD_INTERVAL1=60; /* 60 seconds */ |
| var = newPDU(); |
| writeVar(pdu,0, " ospfIfHelloInterval",iv(0), |
| HELLO_INTERVAL1); |
| writeVar(pdu,0, " ospfIfRtrDeadInterval",iv(0), |
| RTRDEAD_INTERVAL1);|
| snmpsend(pdu,2,OP_SET); |
+--------------------------------------------------------------+
10. ACKNOWLEDGMENTS
This document was produced by the SNMPCONF Working Group. In
particular, the editors wish to thank:
Christopher Anderson
Andy Bierman
Dr Jeffrey Case
Chris Elliott
Joel Halpern
Pablo Halpern
Wes Hardaker
David Harrington
Thippanna Hongal
Harrie Hazewinkel
Art Mellor
Bob Moore
David Partain
Randy Preshun
Dan Romanescu
Shawn Routhier
Robin Whitworth
11. 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
Management Information for TCP/IP-based Internets", STD 16, RFC
1155, May 1990.
Various Authors [Page 68]
RFC DRAFT Expires November 2001 May 2001
[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,
"Introduction 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
Processing 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 (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
Control Model (VACM) for the Simple Network Management Protocol
(SNMP)", RFC 2575, April 1999.
Various Authors [Page 69]
RFC DRAFT Expires November 2001 May 2001
[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,
"Definitions 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
Traffic 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
Information Base for MCNS/DOCSIS compliant RF interfaces", RFC
2670, August 1999.
[27] Baker, F., and R. Coltun, "OSPF Version 2 Management Information
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
Various Authors [Page 70]
RFC DRAFT Expires November 2001 May 2001
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.
12. 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 Tackabury
Gold Wire Technology
411 Waverley Oaks Rd.
Waltham, MA 02452
email - wayne@goldwiretech.com
13. INTELLECTUAL PROPERTY
The IETF takes no position regarding the validity or scope of
any intellectual property or other rights that might be claimed
to pertain to the implementation or use of the technology
Various Authors [Page 71]
RFC DRAFT Expires November 2001 May 2001
described in this document or the extent to which any license
under such rights might or might not be available; neither does
it represent that it has made any effort to identify any such
rights. Information on the IETF's procedures with respect to
rights in standards-track and standards-related documentation
can be found in BCP-11. Copies of claims of rights made
available for publication and any assurances of licenses to be
made available, or the result of an attempt made to obtain a
general license or permission for the use of such proprietary
rights by implementors or users of this specification can be
obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights which may cover technology that may be
required to practice this standard. Please address the
information to the IETF Executive Director.
14. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright
notice and this paragraph are included on all such copies and
derivative works. However, this document itself may not be
modified in any way, such as by removing the copyright notice or
references to the Internet Society or other Internet
organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or
as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns.
Various Authors [Page 72]
RFC DRAFT Expires November 2001 May 2001
This document and the information contained herein is provided
on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
TTTTaaaabbbblllleeee ooooffff CCCCoooonnnntttteeeennnnttttssss
1. INTRODUCTION ................................................ 2
1.1. Document Organization ..................................... 3
2. USING SNMP AS A CONFIGURATION MECHANISM ..................... 3
2.1. Transactions and SNMP ..................................... 3
2.2. Practical Requirements for Transactional Control .......... 4
2.3. Best Practices in Configuration ........................... 5
3. DESIGNING A MIB MODULE ...................................... 8
3.1. MIB Module Design - General Issues ........................ 8
3.2. Naming MIB modules and Managed Objects .................... 9
3.3. Transaction Control And State Tracking .................... 10
3.3.1. Fate sharing with multiple tables ....................... 10
3.3.2. Transaction Control MIB Objects ......................... 10
3.3.3. Usage of Row notReady Status ............................ 11
3.3.4. Summary Objects and State Tracking ...................... 12
3.3.5. Advanced Synchronization Considerations ................. 14
3.3.6. Conceptual Table Modification Practices ................. 17
3.4. Index Design Issues ....................................... 18
3.4.1. Simple Integer Indexing ................................. 18
3.4.2. Indexing with Network Addresses ......................... 19
3.5. Conflicting Controls ...................................... 19
3.6. Textual Convention Usage .................................. 20
3.7. Persistent Configuration .................................. 21
3.8. Configuration Sets and Activation ......................... 22
3.9. SET operation Latency ..................................... 24
3.10. Notifications and Error Reporting ........................ 26
3.10.1. Designing Notifications ................................ 26
3.10.2. Control of Notification Subsystem ...................... 27
3.10.3. Application Error Reporting ............................ 27
3.11. Other MIB Module Design Issues ........................... 29
3.11.1. Octet String Aggregations .............................. 30
3.11.2. Supporting multiple instances of a MIB Module .......... 31
3.11.3. Use of special optional clauses ........................ 31
4. IMPLEMENTING SNMP CONFIGURATION AGENTS ...................... 32
Various Authors [Page 73]
RFC DRAFT Expires November 2001 May 2001
4.1. Operational Consistency ................................... 32
4.2. Handling Multiple Managers ................................ 33
4.3. Designing MIB Modules for Multiple Managers ............... 33
4.4. Specifying Row Modifiability .............................. 35
4.5. Order of varbinds in a SET PDU ............................ 35
4.6. Implementing write-only access objects .................... 35
5. DESIGNING CONFIGURATION MANAGEMENT SOFTWARE ................. 35
5.1. Designing Configuration Management Software ............... 36
5.2. Protocol Operations ....................................... 36
5.3. SET Operations ............................................ 37
5.4. Configuration Transactions ................................ 37
5.5. Notifications ............................................. 38
5.6. Scale of the Management Software .......................... 39
6. DEPLOYMENT AND SECURITY ISSUES .............................. 39
6.1. Basic assumptions about Configuration ..................... 41
6.2. Secure Agent Considerations ............................... 42
6.3. Authentication Traps ...................................... 42
6.4. Sensitive Information Handling ............................ 42
7. POLICY BASED MANAGEMENT ..................................... 43
7.1. Organization of Data in an SNMP-Based Policy System ....... 44
7.2. Conceptual Layering ....................................... 45
7.2.1. Conceptual Layering Diagrams ............................ 48
7.3. Information Related to Policy Based Configuration ......... 50
7.4. Policy, Mechanism/Implementation and Instance Specific
Modules ........................................................ 51
7.5. Schedule and Time Issues .................................. 52
7.6. Conflict Detection, Resolution and Error Reporting ........ 52
7.7. Notifications in a Policy System .......................... 53
7.8. Using Policy to Move Less Configuration Data .............. 53
8. Example MIB Module For Policy-Based Management .............. 54
8.1. NOTES ON MIB MODULE FOR POLICY-BASED MANAGEMENT ........... 65
9. APPENDIX A - Policy Example ................................. 66
10. ACKNOWLEDGMENTS ............................................ 68
11. REFERENCES ................................................. 68
Various Authors [Page 74]
