undesired configuration changes.
Managers should also develop mechanisms to ensure that they are
synchronized with each other.
4.3. Specifying Row Modifiability
Once a RowStatus value is active(1) for a given row, the management
application should be able to determine what the semantics are for
making additional changes to a row. The RMON MIB control table
objects spell out explicitly what managed objects in a row can and
cannot be changed once a given RowStatus goes active.
As described earlier, some operations take some time to complete.
Some systems also require that they remain in a particular state for
some period before moving to another. In some cases, a change to one
value may require re-initialization of the system. In all of these
cases, the DESCRIPTION clause should contain information about
requirements of the managed system and special restrictions that
managers should observe.
4.4. Implementing Write-only Access Objects
The second version of the SNMP SMI dropped direct support for a
write-only object. It is therefore necessary to return something when
reading an object that you may have wished to have write-only
semantics. Such objects should have a DESCRIPTION clause that
details what the return values should be. However, regardless of the
approach, the value returned when reading the object instance should
be meaningful in the context of the object's semantics.
5. Designing Configuration Management Software
In this section, we describe practices that should be used when
creating and deploying management software that configures one or
more systems using SNMP. Functions all configuration management
software should provide, regardless of the method used to convey
configuration information to the managed systems are backup, fail-
over, and restoration. A management system should have the following
features:
1. A method for restoring a previous configuration to one or more
devices. Ideally this restoration should be time indexed so that
a network can be restored to a configured state as of a specific
time and date.
2. A method for saving back up versions of the configuration data in
case of hardware or software failure.
3. A method of providing fail-over to a secondary (management) system
in case of a primary failure. This capability should be deployed
in such a way that it does not cause duplicate polling of
configuration.
These three capabilities are of course important for other types of
management that are not the focus of this BCP.
5.1. Configuration Application Interactions with Managed Systems
From the point of view of the design of the management application,
there are three basic requirements to evaluate relevant to SNMP
protocol operations and configuration:
o Set and configuration activation operations
o Notifications from the device
o Data retrieval and collection
Depending on the requirements of the specific services being
configured, many other requirements may, and probably will, also be
present.
The design of the system should not assume that the objects in a
device that represent configuration data will remain unchanged over
time.
As standard MIB modules evolve and vendors add private extensions,
the specific configuration parameters for a given operation are
likely to change over time. Even in the case of a configuration
application that is designed for a single vendor, the management
application should allow for variability in the MIB objects that will
be used to configure the device for a particular purpose. The best
method to accomplish this is by separating, as much as possible, the
operational semantics of a configuration operation from the actual
data. One way that some applications achieve this is by having the
specific configuration objects that are associated with a particular
device be table driven rather than hard coded. Ideally, management
software should verify the support in the devices it is expected to
manage and report any unexpected deviations to the operator. This
approach is particularly valuable when developing applications that
are intended to support equipment or software from multiple vendors.
5.1.1. SET Operations
Management software should be mindful of the environment in which SET
operations are being deployed. The intent here is to move
configuration information as efficiently as possible to the managed
device. There are many ways to achieve efficiency and some are
specific to given devices. One general case that all management
software should employ is to reduce the number of SET PDU exchanges
between the managed device and the management software to the
smallest reasonable number. One approach to this is to verify the
largest number of variable bindings that can fit into a SET PDU for a
managed device. In some cases, the number of variable bindings to be
sent in a particular PDU will be influenced by the device, the
specific MIB objects and other factors.
Maximizing the number of variable bindings in a SET PDU also has
benefits in the area of management application transaction
initiation, as we will discuss in the following section.
There are, though, agents that may have implementation limitations on
the number and order of varbinds they can handle in a single SET PDU.
In this case, sending fewer varbinds will be necessary.
As stated at the outset of this section, the management application
software designer must be sensitive to the design of the SNMP
software in the managed device. For example, the software in the
managed device may require that all that all related configuration
information for an operation be conveyed in a single PDU because it
has no concept of a transaction beyond a single SNMP PDU. Another
example has to do with the RowStatus textual convention. Some SNMP
agents implement a subset of the features available and as such the
management application must avoid using features that may not be
supported in a specific table implementation (such as createAndWait).
5.1.2. Configuration Transactions
There are several types of configuration transactions that can be
supported by SNMP-based configuration applications. They include
transactions on a scalar object, transactions in a single table
(within and across row instances), transactions across several tables
in a managed device and transactions across many devices. The
manager's ability to support these different transactions is partly
dependent on the design of the MIB objects used in the configuration
operation.
To make use of any kind of transaction semantics effectively, SNMP
management software must be aware of the information in the MIB
modules that it is to configure so that it can effectively utilize
RowStatus objects for the control of transactions on one or more
tables. Such software must also be aware of control tables that the
device supports that are used to control the status of one or more
other tables.
To the greatest extent possible, the management application should
provide the facility to support transactions across multiple devices.
This means that if a configuration operation is desired across
multiple devices, the manager can coordinate these configuration
operations such that they become active as close to simultaneously as
possible.
Several practical means are present in the SNMP model that support
management application level transactions. One was mentioned in the
preceding section, that transactions can be optimized by including
the maximum number of SET variable bindings possible in a single PDU
sent to the agent.
There is an important refinement to this. The set of read-create row
data objects for tables should be sent in a single PDU, and only
placed across multiple PDUs if absolutely necessary. The success of
these set operations should be verified through the response(s) to
the Set PDU or subsequent polling of the row data objects. The
applicable RowStatus object(s), may be set to active only after this
verification. This is the only tractable means of affording an
opportunity for per-row rollback, particularly when the configuration
change is across table row instances on multiple managed devices.
Finally, where a MIB module exposes the kind of helpful transaction
management object types that were discussed in Section 3.3.5, it is
clearly beneficial to the integrity of the management application's
capacity to handle transactions to make use of them.
5.1.3. Tracking Configuration Changes
As previously described in Section 3.3.5 (Summary Objects and State
Tracking), agents should provide the capability for notifications to
be sent to their configured management systems whenever a
configuration operation is completed or is detected to have failed.
The management application must be prepared to accept these
notifications so that it knows the current configured state of the
devices under its control. Upon receipt of the notification, the
management application should use getBulk or getNext to retrieve the
configuration from the agent and store the relevant contents in the
management application database. The GetBulkRequest-PDU is useful
for this whenever supported by the managed device, since it is more
efficient than the GetNextRequest-PDU when retrieving large amounts
of data. For the purposes of backward compatibility, the management
station should also support and make use of the GetNextRequest-PDU
when the agent does not support the GetBulkRequest-PDU.
Management systems should also provide configuration options with
defaults for users that tend to retrieve the smallest amount of data
to achieve the particular goal of the application, to avoid
unnecessary load on managed devices for the most common retrieval
operations.
5.1.4. Scalability of Data Retrieval
The techniques for efficient data retrieval described in the
preceding sections comprise only one aspect of what application
developers should consider in this regard when developing
configuration applications. Management applications should provide
for distributed processing of the configuration operations. This
also extends to management functions that are not the focus of this
document. Techniques of distributed processing can also be used to
provide resilience in the case of network failures. An SNMP-based
configuration management system might be deployed in a distributed
fashion where three systems in different locations keep each other
synchronized. This synchronization can be accomplished without
additional polling of network devices through a variety of
techniques. In the case of a failure, a 'backup' system can take
over the configuration responsibilities from the failed manager
without having to re-synchronize with the managed elements since it
will already be up to date.
6. Deployment and Security Issues
Now that we have considered the design of SNMP MIB data for
configuration, agent implementation of its access, and management
application issues in configuration using SNMP, we turn to a variety
of operational considerations which transcend all three areas.
6.1. Basic assumptions about Configuration
The following basic assumptions are made about real world
configuration models.
1) Operations must understand and must be trained in the operation of
a given technology. No configuration system can prevent an
untrained operator from causing outages due to misconfiguration.
2) Systems undergoing configuration changes must be able to cope with
unexpected loss of communication at any time.
During configuration operations, network elements must take
appropriate measures to leave the configuration in a
consistent/recognizable state by either rolling back to a
previously valid state or changing to a well-defined or default
state.
3) Configuration exists on a scale from relatively unchanging to a
high volume, high rate of change. The former is often referred to
as "set and forget" to indicate that the configuration changes
quite infrequently. The latter, "near real-time change control"
implies a high frequency of configuration change. Design of
configuration management must take into account the rate and
volume of change expected in a given configuration subsystem.
6.2. Secure Agent Considerations
Vendors should not ship a device with a community string 'public' or
'private', and agents should not define default community strings
except when needed to bootstrap devices that do not have secondary
management interfaces. Defaults lead to security issues that have
been recognized and exploited. When using SNMPv1, supporting read-
only community strings is a common practice.
Version 3 of the SNMP represents the current standard for the
Internet Management Framework and is recommended for all network
management applications. In particular, SNMPv3 provides
authorization, authentication, and confidentiality protection and is
essential to meeting the security considerations for all management
of devices that support SNMP-based configuration.
6.3. Authentication Notifications
The default state of RFC1215 [17] Authentication notifications
should be off. One does not want to risk accidentally sending out
authentication failure information, which by itself could constitute
a security liability. Enabling authentication Notifications should
be done in the context of a management security scheme which
considers the proper recipients of this information.
There are other liabilities where authentication notifications are
generated without proper security infrastructure. When notifications
are sent in SNMPv1 trap PDUs, unsolicited packets to a device can
causes one or more trap PDUs to be created and sent to management
stations. If these traps flow on shared access media and links, the
community string from the trap may be gleaned and exploited to gain
access to the device. At the very least, this risk should be
mitigated by having the authentication trap PDU be conveyed with a
community string which is only used for authentication traps from the
agent, and would be useless for access inbound to the agent to get at
other management data.
A further liability of authentication traps can be seen when they are
being generated in the face of a Denial Of Service (DOS) attack, in
the form of a flood of PDUs with invalid community strings, on the
agent system. If it is bad enough that the system is having to
respond to and recover from the invalid agent data accesses, but the
problem will be compounded if a separate Authentication notification
PDU is sent to each recipient on the management network.
6.4. Sensitive Information Handling
Some MIB modules contain objects that may contain data for keys,
passwords and other such sensitive information and hence must be
protected from unauthorized access. MIB documents that are created
in the IETF must have a 'Security Considerations' section, which
details how sensitive information should be protected. Similarly,
MIB module designers who create MIB documents for private MIB objects
should include similar information so that users of the products
containing these objects can take appropriate precautions.
Even if a device does support DES, it should be noted that
configuration of keys for other protocols via SNMP Sets protected by
DES should not be allowed if the other keys are longer than the 56
bit DES keys protecting the SNMP transmission.
The DESCRIPTION clause for these object types and their Security
Considerations sections in the documents which define them should
make it clear how and why these specific objects are sensitive and
that a user should only make them accessible for encrypted SNMP
access. Vendors should also document sensitive objects in a similar
fashion.
Confidentiality is not a mandatory portion of the SNMPv3 management
framework [6].
Prior to SNMPv3, providing customized views of MIB module data was
difficult. This led to objects being defined such as the following
from [41].
docsDevNmAccessEntry OBJECT-TYPE
SYNTAX DocsDevNmAccessEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry describing access to SNMP objects by a
particular network management station. An entry in
this table is not readable unless the management station
has read-write permission (either implicit if the table
is empty, or explicit through an entry in this table.
Entries are ordered by docsDevNmAccessIndex. The first
matching entry (e.g., matching IP address and community
string) is used to derive access."
INDEX { docsDevNmAccessIndex }
::= { docsDevNmAccessTable 1 }
New MIB modules should capitalize on existing security capabilities
of SNMPv3 Framework. One way they can do this is by indicating the
level of security appropriate to different object types. For
example, objects that change the configuration of the system might be
protected by using the authentication mechanisms in SNMPv3.
Specifically, it is useful to design MIB module object grouping with
considerations for VACM views definition, such that users can define
and properly scope what tables are visible to a given user and view.
7. Policy-based Management
In some designs and implementations, a common practice used to move
large amounts of data involves using SNMP as a control channel in
combination with other protocols defined for transporting bulk data.
This approach is sub-optimal since it raises a number of security and
other concerns. Transferring large amounts of configuration data via
SNMP can be efficiently performed with several of the techniques
described earlier in this document. This policy section shows how
even greater efficiency can be achieved using a set of relatively new
design mechanisms. This section gives background and defines terms
that are relevant to this field and describes some deployment
approaches.
7.1. What Is the Meaning of 'Policy-based'?
In the past few years of output from standards organizations and
networking vendor marketing departments, the term 'policy' has been
heavily used, touted, and contorted in meaning. The result is that
the true meaning of 'policy' is unclear without greater qualification
where it is used.
[42] gives the term 'policy' two explicit definitions:
- A definite goal, course or method of action to guide and determine
present and future decisions. "Policies" are implemented or
executed within a particular context (such as policies defined
within a business unit).
- Policies as a set of rules to administer, manage, and control
access to network resources.
Note that these two views are not contradictory since individual
rules may be defined in support of business goals.
As it pertains to our discussion of the term 'policy-based
configuration', the meaning is significantly more specific. In this
context, we refer to a way of integrating data and the management
actions which use it in such a way that:
- there is the ability to specify "default" configuration data for a
number of instances of managed elements, where those instances can
be correlated in some data driven or algorithmic way. The engine
to do this correlation and activate instances from defaults may
reside in the agent or externally. Where the representation of
these defaults are in the MIB design itself, the object types
supporting this notion are referred to as "template objects".
- the activation of instance data derived from template object types
results from minimal activation directives from the management
application, once the instances of the template object types have
been established.
- somewhat independently, the architecture of the overall management
agent may accommodate the definition and evaluation of management
and configuration policies. The side-effects of the evaluation of
these policies typically include the activation of certain
configuration directives. Where management data design exposes
template object types, the policy-driven activation can (and
ideally, should) include the application of template object
instances to the analogous managed element instance-level values.
As it pertains to template object data, the underlying notions
implied here have been prevalent for some time in non-SNMP management
regimes. A common feature of many command line interfaces for
configuring routers is the specification of one or more access
control lists. These typically provide a set of IP prefixes, BGP
autonomous system numbers, or other such identifying constructs (see,
for example, [42]). Once these access control lists are assembled,
their application to various interfaces, routing processes, and the
like are specified typically in the configuration of what the access
control list is applied to. Consistent with the prior properties to
define our use of policy-based configuration, a) the access list is
defined independent from its point of application, and b) its
application is independent of the access list definition. For
example, changing the application of an access list from one
interface to the other does not require a change in the access list
itself. The first point just mentioned suggests what is necessary
for template-based data organization. The second suggests its
application in a policy-based manner.
Let us now examine the motivation for such a system or subsystem
(perhaps bounded at the level of a 'template-enabled' MIB module,
given the above definition). Let us explore the importance of
policy-based techniques to configuration specifically.
7.2. Organization of Data in an SNMP-Based Policy System
The number of configurable parameters and 'instances' such as
interfaces has increased as equipment has become larger and more
complex.
At the same time, there is a need to configure many of these systems
to operate in a coordinated fashion. This enables the delivery of
new specialized services that require this coordinated configuration.
Examples include delivery of virtual private networks and connections
that guarantee specific service levels.
The growth in size and complexity of configuration information has
significant implications for its organization as well as its
efficient transfer to the management agent. As an example, an agent
that implements the Bridge MIB [24] could be used to represent a
large VLAN with some 65,000 port entries. Configuring such a VLAN
would require the establishment of dot1dStpPortTable and
dot1DStaticTable entries for each such virtual port. Each table
entry would contain several parameters. A more efficient approach is
to provide default values for the creation of new entries that are
appropriate to the VLAN environment in our example. The local
management infrastructure should then iterate across the system
setting the default values to the selected ports as groups.
To date, this kind of large-scale configuration has been accomplished
with file transfer, by setting individual MIB objects, or with many
CLI commands. In each of these approaches the details for each
instance are contained in the file, CLI commands or MIB objects.
That is, they contain not only the value, and type of object, but
also the exact instance of the object to which to apply the value.
It is this property that tends to make configuration operations
explode as the number of instances (such as interfaces) grows. This
per-instance approach can work for a few machines configured by
experts, but there is a need for a more scalable solution.
Template-based data organization and policy-based management
abstracts the details above the instance level, which means that
fewer SET requests are sent to a managed device.
Realization of such a policy-driven system requires agents that can
take defaults and apply them to instances based on a rule that
defines under what conditions the defaults (policy) are to be
applied. A policy-driven configuration system which is to be
scalable needs to expose a means of layering its application of
defaults at discrete ranges of granularity. The spectrum of that
granularity might have a starting hierarchy point to apply defaults
at the breadth of a network service.
Ultimately, such a layering ends up with features to support
instance-level object instance data within the running agent.
An example of this kind of layering is implicit in the principle of
operations of a SNMPCONF Policy-Based Management MIB [36] (PM-MIB)
implementation. However, other entity management systems have been
employing these kinds of techniques end-to-end for some time, in some
cases using SNMP, in some cases using other encodings and transfer
technologies. What the PM-MIB seeks to establish, in an environment
ideal for its deployment, is an adaptation between MIB module data
which was not designed using template object types, and the ability
to allow the PM-MIB agent engine to apply instances of that data as
though it were template-based.
7.3. Information Related to Policy-based Configuration
In order for effective policy management to take place, a range of
information about the network elements is needed to avoid making poor
policy decisions. Even in those cases where policy-based
configuration is not in use, much of the information described in
this section can be useful input to the decision-making process about
what type of configuration operations to do.
For this discussion it is important to make distinctions between
distribution of policy to a system, activation of a policy in a
system, and changes/failures that take place during the time the
policy is expected to be active. For example, if an interface is
down that is included in a policy that is distributed, there may not
be an error since the policy may not be scheduled for activation
until a later time.
On the other hand, if a policy is distributed and applied to an
interface that should be operational and it is not, clearly this is a
problem, although it is not an error in the configuration policy
itself. With this as background, here are some areas to consider
that are important to making good policy configuration decisions and
establishing when a policy has 'failed'.
o The operational state of network elements that are to be
configured.
Care should be taken to determine if the sub-components to be
configured are available for use. In some cases the elements may
not be available. The policy configuration software should
determine if this is a prerequisite to policy installation or if
the condition is even acceptable. This decision is separate from
the one to be made about policy activation. Installation is when
the policy is sent from the policy manager to the managed device
and activation is turning on the policy. In those cases where
policy is distributed when the sub-component such as an interface
or disk is not available, the managed system should send a
notification to the designated management station when the policy
is to become active or if the resource is still not available.
o The capabilities of the devices in the network.
A capability can be almost any unit of work a network element can
perform. These include routing protocols supported, Web server
and OS versions, queuing mechanisms supported on each interface
that can be used to support different qualities of service, and
many others. This information can be obtained from the
capabilities table of the Policy MIB module [36].
Historically, management applications have had to obtain this type
of information by issuing get requests for objects they might want
to use. This approach is far less efficient since it requires
many get requests and is more error prone since some instances
will not exist until configured. The new capabilities table is an
improvement on the current technique.
o The capacity of the devices to perform the desired work.
Capability is an ability to perform the desired work while a
capacity is a measure of how much of that capability the system
has. The policy configuration application should, wherever
possible, evaluate the capacity of the network element to perform
the work identified by the policy. In some systems it will not be
possible to obtain the capacity of the managed elements to perform
the desired work directly, even though it may be possible to
monitor the amount of work the element performs. In these cases,
the management application may benefit from pre-configured
information about the capacity of different network elements so
that evaluations of the resources available can be done before
distributing new policies.
Utilization refers to how much capacity for a particular
capability has been consumed. For devices that have been under
policy configuration control for any period of time, a certain
percentage of the available capacity of the managed elements will
be used. Policies should not be distributed to systems that do
not have the resources to carry out the policy in a reasonable
period of time.
7.4. Schedule and Time Issues
This section applies equally to systems that are not policy-based as
well as policy-based systems, since configuration operations often
need to be synchronized across time zones. Wherever possible, the
network elements should support time information using the standard
DateAndTime TC that includes local time zone information. Policy-
based management often requires more complex time expressions than
can be conveyed with the DateAndTime TC. See the Policy-Based
Management MIB document [36] for more information. Some deployed
systems do not store complex notions of local time and thus may not
be able to process policy directives properly that contain time zone
relevant data. For this reason, policy management applications
should have the ability to ascertain the time keeping abilities of
the managed system and make adjustments to the policy for those
systems that are time-zone challenged.
7.5. Conflict Detection, Resolution and Error Reporting
Policies sent to a device may contain conflicting instructions.
Detection of such commands can occur at the device or management
level and may be resolved using any number of mechanisms (examples
are, last configuration set wins, or abort change). These unintended
conflicts should be reported. Conflicts can occur at different
levels in a chain of commands. Each 'layer' in policy management
system should be able to check for some errors and report them. This
is conceptually identical to programs raising an exception and
passing that information on to software that can do something
meaningful with it.
At the instance level, conflict detection has been performed in a
limited way for some time in software that realizes MIB objects at
this level of resolution. This detection is independent of policy.
The types of 'conflicts' usually checked for are resource
availability and validity of the set operations. In a policy enabled
system, there are no additional requirements for this software
assuming that good error detection and reporting appropriate to this
level have already been implemented.
7.5.1. Changes to Configuration Outside of the Policy System
It is essential to consider changes to configuration that are
initiated outside of the policy system. A goal of SNMP-based policy
management is to coexist with other kinds of management software that
have historically been instance based management. The best example
is the command line interface.
A notification should be sent whenever an out-of-policy control
change is made to an element that is under the control of policy.
This notification should include the policy that was affected, the
instance of the element that was changed and the object and value
that it was changed to.
Even for those systems that have no concept of policy control, the
ideas presented above make sense. That is, if SNMP co-exists with
other access methods such as a CLI, it is essential that the
management station remain synchronized with changes that might have
been made to the managed device using other methods. As a result,
the approach of sending a notification when another access method
makes a change is a good one. Of course this should be configurable
by the user.
7.6. More about Notifications in a Policy System
Notifications can be useful in determining a failure of a policy as a
result of an error in the policy or element(s) under policy control.
As with all notifications, they should be defined and controlled in
such a way that they do not create a problem by sending more than are
helpful over a specific period of time. For example, if a policy is
controlling 1,000 interfaces and fails, one notification rather than
1,000 may be the better approach. In addition, such notifications
should be defined to include as much information as possible to aid
in problem resolution.
7.7. Using Policy to Move Less Configuration Data
One of the advantages of policy-based configuration with SNMP is that
many configuration operations can be conveyed with a small amount of
data. Changing a single configuration parameter for each of 100
interfaces on a system might require 100 CLI commands or 100 SNMP
variable bindings using conventional techniques.
Using policy-based configuration with SNMP, a single SET PDU can be
sent with the policy information necessary to apply a configuration
change to 100 similar interfaces. This efficiency gain is the result
of eliminating the need to send the value for each instance to be
configured. The 'default' for each of the instances included in the
policy is sent, and the rule for selection of the instances that the
default is to be applied to can also be carried (see the Policy MIB
module [36]).
To extend the example above, assume that there are 10 parameters that
need to change. Using conventional techniques, there would now be
1,000 variable bindings, one for each instance of each new value for
each interface. Using policy-based configuration with SNMP, it is
still likely that all the information can be conveyed in one SET PDU.
The only difference in this case is that there are ten parameters
sent that will be the 'template' used to create instances on the
managed interfaces.
This efficiency gain not only applies to SET operations, but also to
those management operations that require configuration information.
Since the policy is also held in the storage for cross-instance
defaults (for example, the pmPolicyTable in [36]), an entire data set
that potentially controls hundreds of rows of information can be
retrieved in a single GET request.
A policy-friendly data organization such as this is consistent and
integrates well with MIB module objects which support "summary"
activation and activation reporting, of the kind discussed in Section
3.3.5.
8. Example MIB Module With Template-based Data
This section defines a MIB module that controls the heating and air
conditioning system for a large building. It contains both
configuration and counter objects that allow operators to see how
much cooling or heating a particular configuration has consumed.
Objects that represent the configuration information at a "default"
level (as referenced above) are also included.
These tables, in combination with the application of the tables' row
instance data as templated 'defaults', will allow operators to
configure and monitor many rooms at once, change the configuration
parameters based on time of day, and make a number of other
sophisticated decisions based on the 'policy' implied by these
defaults and their application. For this reason, these configuration
controls have their instances specified from template object types.
In our simplified Heating Ventilation and Air Conditioning (HVAC)
model we will create three tables based on a simple analysis. More
complicated systems will need more tables, but the principles will be
the same.
Step 1: As with any other MIB module design, the first step
is to determine what objects are necessary for
configuration and control operations. The first table
to be created is a fairly traditional monitoring
table. It includes indices so that we will know what
rooms the counters and status objects are for. It
includes an object that is a RowPointer to a table
that contains configuration information. The objects
for the bldgHVACTable, our first table in the HVAC
MIB module are:
Index objects that identify what floor and office we are
managing:
bldgHVACFloor
bldgHVACOffice
A single index reference to a table that 'glues' configuration
information defaults with descriptive information:
bldgHVACCfgTemplate
A set of objects that show status and units of
work (bldgHVACCoolOrHeatMins) and standard per-row
SnmpAdminString, StorageType, and RowStatus columnar
objects:
bldgHVACFanSpeed
bldgHVACCurrentTemp
bldgHVACCoolOrHeatMins
bldgHVACDiscontinuityTime
bldgHVACOwner
bldgHVACStatus
Step 2: A configuration description table. The purpose of this
table is to provide a unique string identifier for
templates. These may be driven by policies in a
network. If it were necessary to configure devices
to deliver a particular quality of service, the
index string of this table could be the name and the
description part, it could be a brief description of the
underlying motivation such as: "provides extra heat to
corner offices to counteract excessive exterior wind
chill". Standard owner and status objects may also
be helpful and are included here. The row columnar
objects are:
bldgHVACCfgTemplateInfoIndex
bldgHVACCfgTemplateInfoID
bldgHVACCfgTemplateInfoDescr
bldgHVACCfgTemplateInfoOwner
bldgHVACCfgTemplateInfoStatus
Notice that to this point we have provided no
configuration information. That will be in the next
table. Some readers may wonder why this table is not
combined with the configuration template table described
in the next step. In fact, they can be. The reason for
having a separate table is that as systems become more
complex, there may be more than one configuration table
that points to these descriptions. Another reason for
two tables is that this in not reproduced for every
template and instance, which can save some additional
data movement. Every designer will have to evaluate the
tradeoffs between number of objects and data movement
efficiency just as with other MIB modules.
Step 3: The bldgHVACCfgTemplateTable contains the specific
configuration parameters that are pointed to by the
bldgHVACConfigPtr object. Note that many rows in the
bldgHVACTable can point to an entry in this table. It
is also possible for entries to be used by 1 or 0 rows
of the bldgHVACTable. It is the property of allowing
multiple rows (instances) in the bldgHVACTable to
point to a row in this table that can produce such
efficiency gains from policy-based management with
SNMP. Also notice that the configuration data is tied
directly to the counter data so that people can see
how configurations impact behavior.
The objects in this table are all that are necessary
for configuration and connection to the other tables as
well as the usual SnmpAdminString, StorageType, and
RowStatus objects:
A simple index to the table:
bldgHVACCfgTemplateIndex
The configuration objects:
bldgHVACCfgTemplateDesiredTemp
bldgHVACCfgTemplateCoolOrHeat
Administrative objects for SnmpAdminString and
RowStatus:
bldgHVACCfgTemplateInfo
bldgHVACCfgTemplateOwner
bldgHVACCfgTemplateStorage
bldgHVACCfgTemplateStatus
8.1. MIB Module Definition
BLDG-HVAC-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, Counter32,
Gauge32, OBJECT-TYPE, Unsigned32, experimental
FROM SNMPv2-SMI
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF
TEXTUAL-CONVENTION,
TimeStamp, RowStatus, StorageType
FROM SNMPv2-TC
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB;
bldgHVACMIB MODULE-IDENTITY
LAST-UPDATED "200303270000Z"
ORGANIZATION "SNMPCONF working group
E-mail: snmpconf@snmp.com"
CONTACT-INFO
"Jon Saperia
Postal: JDS Consulting
174 Chapman Street
Watertown, MA 02472
U.S.A.
Phone: +1 617 744 1079
E-mail: saperia@jdscons.com
Wayne Tackabury
Postal: Gold Wire Technology
411 Waverley Oaks Rd.
Waltham, MA 02452
U.S.A.
Phone: +1 781 398 8800
E-mail: wayne@goldwiretech.com
Michael MacFaden
Postal: Riverstone Networks
5200 Great America Pkwy.
Santa Clara, CA 95054
U.S.A.
Phone: +1 408 878 6500
E-mail: mrm@riverstonenet.com
David Partain
Postal: Ericsson AB
P.O. Box 1248
SE-581 12 Linkoping
Sweden
E-mail: David.Partain@ericsson.com"
DESCRIPTION
"This example MIB module defines a set of management objects
for heating ventilation and air conditioning systems. It
also includes objects that can be used to create policies
that are applied to rooms. This eliminates the need to send
per-instance configuration commands to the system.
Copyright (C) The Internet Society (2003). This version of
this MIB module is part of RFC3512; see the RFCitself for
full legal notices."
REVISION "200303270000Z"
DESCRIPTION
"Initial version of BLDG-HVAC-MIB as published in RFC3512."
::= { experimental 122 }
bldgHVACObjects OBJECT IDENTIFIER ::= { bldgHVACMIB 1 }
bldgConformance OBJECT IDENTIFIER ::= { bldgHVACMIB 2 }
--
-- Textual Conventions
--
BldgHvacOperation ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Operations supported by a heating and cooling system.
A reference to underlying general systems would go here."
SYNTAX INTEGER {
heat(1),
cool(2)
}
--
-- HVAC Objects Group
--
bldgHVACTable OBJECT-TYPE
SYNTAX SEQUENCE OF BldgHVACEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table is the representation and data control
for building HVAC by each individual office.
The table has rows for, and is indexed by a specific
floor and office number. Each such row includes
HVAC statistical and current status information for
the associated office. The row also contains a
bldgHVACCfgTemplate columnar object that relates the
bldgHVACTable row to a row in the bldgHVACCfgTemplateTable.
If this value is nonzero, then the instance in the row
that has a value for how the HVAC has been configured
in the associated template (bldgHVACCfgTeplateTable row).
Hence, the bldgHVACCfgTeplateTable row contains the
specific configuration values for the offices as described
in this table."
::= { bldgHVACObjects 1 }
bldgHVACEntry OBJECT-TYPE
SYNTAX BldgHVACEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A row in the bldgHVACTable. Each row represents a particular
office in the building, qualified by its floor and office
number. A given row instance can be created or deleted by
set operations upon its bldgHVACStatus columnar
object instance."
INDEX { bldgHVACFloor, bldgHVACOffice }
::= { bldgHVACTable 1 }
BldgHVACEntry ::= SEQUENCE {
bldgHVACFloor Unsigned32,
bldgHVACOffice Unsigned32,
bldgHVACCfgTemplate Unsigned32,
bldgHVACFanSpeed Gauge32,
bldgHVACCurrentTemp Gauge32,
bldgHVACCoolOrHeatMins Counter32,
bldgHVACDiscontinuityTime TimeStamp,
bldgHVACOwner SnmpAdminString,
bldgHVACStorageType StorageType,
bldgHVACStatus RowStatus
}
bldgHVACFloor OBJECT-TYPE
SYNTAX Unsigned32 (1..1000)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This portion of the index indicates the floor of the
building. The ground floor is considered the
first floor. For the purposes of this example,
floors under the ground floor cannot be
controlled using this MIB module."
::= { bldgHVACEntry 1 }
bldgHVACOffice OBJECT-TYPE
SYNTAX Unsigned32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This second component of the index specifies the
office number."
::= { bldgHVACEntry 2 }
bldgHVACCfgTemplate OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The index (bldgHVACCfgTemplateIndex instance)
of an entry in the 'bldgHVACCfgTemplateTable'.
The bldgHVACCfgTable row instance referenced
is a pre-made configuration 'template'
that represents the configuration described
by the bldgHVACCfgTemplateInfoDescr object. Note
that not all configurations will be under a
defined template. As a result, a row in this
bldgHVACTable may point to an entry in the
bldgHVACCfgTemplateTable that does not in turn
have a reference (bldgHVACCfgTemplateInfo) to an
entry in the bldgHVACCfgTemplateInfoTable. The
benefit of this approach is that all
configuration information is available in one
table whether all elements in the system are
derived from configured templates or not.
Where the instance value for this colunmar object
is zero, this row represents data for an office
whose HVAC status can be monitored using the
read-only columnar object instances of this
row, but is not under the configuration control
of the agent."
::= { bldgHVACEntry 3 }
bldgHVACFanSpeed OBJECT-TYPE
SYNTAX Gauge32
UNITS "revolutions per minute"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Shows the revolutions per minute of the fan. Fan speed
will vary based on the difference between
bldgHVACCfgTemplateDesiredTemp and bldgHVACCurrentTemp. The
speed is measured in revolutions of the fan blade per minute."
::= { bldgHVACEntry 4 }
bldgHVACCurrentTemp OBJECT-TYPE
SYNTAX Gauge32
UNITS "degrees in celsius"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current measured temperature in the office. Should
the current temperature be measured at a value of less
than zero degrees celsius, a read of the instance
for this object will return a value of zero."
::= { bldgHVACEntry 5 }
bldgHVACCoolOrHeatMins OBJECT-TYPE
SYNTAX Counter32
UNITS "minutes"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of heating or cooling minutes that have
been consumed since the row was activated. Notice that
whether the minutes represent heating or cooling is a
function of the configuration of this row. If the system
is re-initialized from a cooling to heating function or
vice versa, then the counter would start over again. This
effect is similar to a reconfiguration of some network
interface cards. When parameters that impact
configuration are changed, the subsystem must be
re-initialized. Discontinuities in the value of this counter
can occur at re-initialization of the management system,
and at other times as indicated by the value of
bldgHVACDiscontinuityTime."
::= { bldgHVACEntry 6 }
bldgHVACDiscontinuityTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime on the most recent occasion at which
any heating or cooling operation for the office designated
by this row instance experienced a discontinuity. If
no such discontinuities have occurred since the last re-
initialization of the this row, then this object contains a
zero value."
::= { bldgHVACEntry 7 }
bldgHVACOwner OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The identity of the operator/system that
last modified this entry. When a new entry
is created, a valid SnmpAdminString must
be supplied. If, on the other hand, this