One document matched: draft-ietf-snmpconf-bcp-03.txt
Differences from draft-ietf-snmpconf-bcp-02.txt
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-03.txt
November 21, 2000
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 (2000). All Rights Reserved.
Abstract
This document is for a variety of readers interested in the
Internet Standard Management Framework for the Simple Network
MacFaden et al Expires May 2001 [Page 1]
Internet Draft SNMP Configuration November 2000
Management Protocol[SNMP]. In particular, it offers guidance
in the SNMP usage for effective configuration management. This
information is relevant to vendors that build network elements,
third party application developers, and those that acquire and
deploy this technology in their networks.
This document is still very much a work in progress. Community
input is solicited.
1. INTRODUCTION
Data networks have grown greatly in size and complexity over the
past decade. Configuration of network elements is an essential
prerequisite to the deployment of services on those networks.
Such configuration requirements have grown more complex over time
as a result of serveral dynamics:
Scale - Data networks have scaled in many dimenstions:
they have more network elements, the network elements are
larger and they have many more interrelationships.
Functionality - network devices perform more functions.
More protocols and network layers are
required for the successful deployment of a wide array
of network services.
The Internet Standard Management Framework is used successfully to
develop configuration management systems for a broad range of
devices. This document describes Best Current Practices [BCP] that
should be used when designing an effective SNMP-based management
system that includes configuration operations.
In addition to individual element management, the SNMP can be used
to configure groups of devices based on a set of rules or desired
states, what has come be know as policy management. A great deal of
attention has been placed on policy based configuration management
over the past few months as a result of the factors described above.
This document also includes recommendations for policy based
configuration. Policy Based Configuration Management can be defined
as a configuration operations distributed to
potentially many network elements with the goal of achieving
consistent network behavior throughout a given autonomous system
AS[21].
MacFaden et al Expires May 2001 [Page 2]
Internet Draft SNMP Configuration November 2000
This document draws on experience provisioning public and private
data networks over the deployment history of SNMP. Over that same
time-period, significant experience has been gained in the
development and deployment of SNMP based management software,
some of which also performs configuration functions.
1.1. Document Organization
The next section describes a typical procedural model for how
experienced operations staff generally practice configuration
of TCP/IP networks.
Section 3 describes a reference model for how management data is
modeled and presented particularly for the benefit of the application
or manager performing the configuration.
Section 4 describes required background issues in using SNMP
for configuration, particularly with respect to transactional
control.
Section 5 discusses known practices in using SNMP for
configuration, where these practices show up in MIB module design
and interpretation (5.1) and in management application design (5.2).
Section 6 describes the current state of the art in policy-based
management, and how that concept affects SNMP-based configuration.
Section 7 provides the complete specification of an example MIB module
used throughout section 5.
2. CONFIGURATION REFERENCE MODEL
A goal of management data modeling is to represent
configuration and management information at the appropriate level of
abstraction to make it easier for operators to configure elements
without necessarily knowing the details of each device.
Lower (more detailed) level detail can facilitate fault
resolution and performance management.
Part of the function of the management station software as well as
software that executes inside the network elements is to
transform these different levels of abstraction into a form
the equipment can use. The following terms define the
dimensions of abstraction in a configuration model. This model,
MacFaden et al Expires May 2001 [Page 3]
Internet Draft SNMP Configuration November 2000
and its related abstraction level, will be referenced
throughout the remainder of this document.
Domain-Specific
A domain is a general area of technology such as service quality
or security. Services, or service level agreements, may span
several domains, each of them potentially including many policies.
As a general rule, people will not discuss these domains in the
abstract. They will most often be discussed with technology or
application-specific examples. Examples of technical domains
include, IPSec and Differentiated Services. When expressed in
terms specific to a particular domain, a policy is said to be at
the Domain Specific level of detail.
Mechanism-Specific
Mechanisms are technologies used within a particular domain.
For example, in the differentiated services domain, RED (Random
Early Detection) or WRED (Weighted Random Early Detection)
might be used as one of the mechanisms that devices employ
to realize a traffic conditioner called a Dropper in
differentiated services DS[28] and the applications on which
they rely. Policy descriptions that include the details
associated with a particular mechanism, are said to be
mechanism-specific.
Implementation-Specific
Implementation-specific details are those parameters that a
particular vendor might use in an implementation that augment
a standard set of mechanism-specific parameters. Vendors
often add special capabilities to basic mechanisms as a way of
meeting special customer requirements or differentiating themselves
from their competitors.
These special capabilities are often a result of the
implementation approach that a vendor has used for the product,
thus the term "implementation-specific". For example, if a
router vendor implemented a particular routing protocol, they
would have the mechanism-specific parameters that control the
behavior of that software. The vendor might have chosen to run
several instances of that routing protocol, perhaps on
different processors, for performance reasons. The parameters
that are used to control the distribution of work on the
different processors for that protocol would be implementation-
MacFaden et al Expires May 2001 [Page 4]
Internet Draft SNMP Configuration November 2000
specific.
Instance-Specific
Network operators are most familiar and comfortable with information
of this instance-specific type. Instance-specific information refers
to parameter values that have been associated with a specific
instance in a managed element.
For example, The Border Gateway Protocol is a exterior routing
protocol that has a number of parameters that describe
information about a particular routers view of other routers
that it is sharing information with, peer routers. One such
parameter defined in the BGP MIB module BGPMIB[29] is the desired
connection retry interval for a peer, bgpPeerConnectRetryInterval.
An example value would be 120 (seconds). When expressed with this
level of specificity, one would say that this is mechanism-specific
data. If we were to see a value of
bgpPeerConnectRetryInterval.192.0.2.1 = 120 we would be looking
at the retry interval of the peer router found at IP address
192.0.2.1. The value for this instance is 120 seconds,
instance-specific data.
3. CONSIDERATIONS FOR SNMP USAGE
3.1. Transactions and SNMP
Over the years there has been considerable discussion about
SNMP and its historical lack of an explicit transaction control
mechanism beyond the PDU and variable binding processing rules
of the protocol. While the SNMP SMIv2 added the row status textual
convention, many implementations have not made good use of
it. Material is presented in this document that provides
guidance on how to best make use of the row status textual
convention that can be effectively used to provide a wide
variety of transaction level controls. That said, a debate
about transaction level control at the protocol level often
misses the important distinction between information integrity
and transaction control. The property of informational
integrity [REF] is important and well handled by the
SNMP. Informational integrity ensures that the data that is
received by an entity is what was sent.
Transactional integrity is a crucial component to any aspect
MacFaden et al Expires May 2001 [Page 5]
Internet Draft SNMP Configuration November 2000
of the control of the configuration of network elements. This
is the property of ensuring that a range of configuration
commands are treated as an integral unit and that all or none
are carried out. To this point, most systems have used the
configuration file as the unit of transaction integrity since
that was the easiest to control and understand, however; this
approach suffers from a number of deficiencies. These include:
Poor control for changes that are finer grained than the file
level and lack of ability to coordinate changes among several
machines as would be desired in a policy-based system.
3.1.1. Practical Requirements for Transactional Control
A properly designed and deployed configuration management system
should have the following features with regard to transactions and
transactional integrity.
First, provide for flexible transaction control at many different
levels of granularity, within a mechanisim specific (system) and
domain specific (group of systems or network).
This means whole system updates or any portion thereof.
Whole configuration files can be used to achieve some
of this but are inefficient, both in terms of the amount of
data transmitted as well as in terms of processing overhead on
the managed elements. Even where partial configuration files
are used, they often cause extra material to be added to the
configuration file and thus suffer from some of the same
difficulties of whole configuration file updates.
The transaction control component should work at any of the
levels of abstraction. There is an inherent difficulty in
translating the individual changes in files to a form that is
usefully represented in a database that would allow for easy
incremental rollback or roll-forward operations on a single
machine or among many.
Allow flexibility in the definition of a successful
transaction. This can not be done at the protocol level alone,
but 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.
Expose time-indexed transaction control - For effective rollback
control, the configuration transactions and their successful
or unsuccessful completion status must be reported by the
MacFaden et al Expires May 2001 [Page 6]
Internet Draft SNMP Configuration November 2000
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 made on the system recording the change.
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 represented in the managed element.
It is possible for an SNMP-based management system to effectively
address all of these issues. Transactional control is an essential
property of a configuration management system consistent with what
is presented in this document. Areas in this document that describe
how to successfully design, implement and deploy such a system are:
Requirement Section
----------- -------
Flexible Transaction Control Transaction Control MIB objects
Flexible Transaction Control Configuration Transactions (5.3)
Time-indexed Transaction Control Management Station Time
4. OPERATIONAL FUNDAMENTALS
4.1. A Process for Deploying Configuration
Data 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 the 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
MacFaden et al Expires May 2001 [Page 7]
Internet Draft SNMP Configuration November 2000
interoperability
with prior system
versions and
backwards
compatibility
with prior
configuration
(2) Plan noncritical/ Fall back strategy
off hour window in case of change
failure
Segmented edge of (1),(2) (3) Apply change to CLI Verified device
main network of network segment accept of
network elements configuration
change
(3) (4) Observation of Verified device
devices/networks over and network
time after change stability, proper
effect of changes
(4) (5) Save changes to Verify integrity
persistent storage of changes after
of devices device restart
Expanded network (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
(6) (7) Continue to Checkpointed
observe devices and verification
network for of anticipated
behavioral/service behavior
anomalies
MacFaden et al Expires May 2001 [Page 8]
Internet Draft SNMP Configuration November 2000
(7) (8) Expand deployment Checkpointed
and iteration to (6) verification
as called for of anticipated
behavior
Network revision (8) Update archived Change deployment
control system configurations, complete.
change log.
Procedures such as those above bring about a form of operational
transactionality, which works along side (and employs) the SNMP
transactionality as outlined in [SNMPTRANS]. 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.
4.2. Configuration Change Coherency and Verification
There are implicit assumptions made about the
environement in which configuration changes are made.
One common assumption is that a "mere mortal" on
the operations staff trained in a given technology
should be able to understand a device's state or
some logical view of that state.
Now surrounding any given subsystem is
the configuration mechanism. Training with this
component can also impact configuration.
Also, both components interact. A classic example,
is the operator that becomes concerned at the cpu utilization
on a network element as that system is pounded for queries as to the
state of cpu utilization is increasingly common.
If the configuration mechanism is more complex
MacFaden et al Expires May 2001 [Page 9]
Internet Draft SNMP Configuration November 2000
than what is generally being configured, it can often
obscure what the operator wanted to change.
To assist in the verification requirements called for above,
a diagnostic mode is often present to deal with specific
implementation issues above and beyond the standard set of
instrumentation capabilities on affected devices.
To verify a configuration change, an operator should have an
integrated view of configuration, device status, and diagnostic
information. That information would be available both before and
after configuration change, regardless of latency involved.
Ideally there are a series of tests the operator
runs before and after a change is made to an operational
network to ensure service remains intact. For example, when
configuring a DNS system, the tool nslookup is often used with a
script to verify key database entries are present and return the
expected values. Configuration change may not be made if
pre-configration test results show the change can not be verified.
Another example: A change is made to the network and initial review
shows that change appears to be successfully implemented, but at
some later time, problems begine to occur. Verification of
the cause change with SNMP is integrated in that MIB objects
not directly used in configuration can be checked to verify
configuration.
It is extremely important to note that achieving convergence
(network stability) in an autonomous system is not
guaranteed when configuration changes are made. For
example, if changes are 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: lose adjacency, form
adjacency and so on never reach a converged (stable) state.
Managed systems under configuration control should be able
to cope with unexpected loss communications with a centralized
management system.
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.
Here then are requirements for a modern configuration protocol.
MacFaden et al Expires May 2001 [Page 10]
Internet Draft SNMP Configuration November 2000
4.3. Configuration Change Diagnostics
Debugging is an integral part of the configuration process.
Subsystems should provide self-tests that verify internal
state as well as tests to verify external states.
When possible the results of a diagnostic test should
be exposed through one or more MIB objects.
Availability of debug/diagnostic tests that are exposed through
MIB modules should be identified and exploited to identify
configuration errors. For example, the test/set/test sequence
is commonly employed for configuration changes in a production
environment. The SNMP is ideal for obtaining status from a
change event, including objects not part of the configuation
action.
Ideally, impact of configuration change on convergence of an existing
network whould be specified in the configuration MIB module in a
description clause. For example, when changing the cost of
of a port via OSPF or STP, does such a change cause the network
to destabilize while the change is implemented and protocol updates
are sent to other devices.
For MIB modules that do not define such attributes, the
agent-capabilities MIB could be used to add additional implementation
notations. Reporting on the impact of a change via configuration
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.
5. CONFIGURATION PRACTICE AND SNMP
5.1. Agent Software Development
This section describes a number of best current
practices by drawing upon a fictional MIB module called
ACME-HOUSECTRL-MIB. This MIB can control familiar facilities
found in a modern home and is defined in Section 8.0 along with
a sample agent capabilities definition. Our discussion need also
account for the role of key capabilities in the SNMP such as
protocol transactions, security, and error handling in the
context of configuration.
MacFaden et al Expires May 2001 [Page 11]
Internet Draft SNMP Configuration November 2000
What emerges from analysis of the usage of existing and possible
MIB modules for which the ACME-HOUSECTRL-MIB can be used as an
abstraction
are a number of discrete objectives and considerations for MIB module
designers. This discussion organizes them around greater
containment criteria.
5.1.1. Consistency in Modeling
One of the first tasks in defining a MIB module
is the creation of a model which reflects the domain-specific or
mechanism-specific scope of the management information involved.
MIB modules may expose configuration capabilities to
a significant degree. There are a variety of considerations in
the specification of management objects and specification of how
they are accessed, which have proved important in operational
experience.
5.1.1.1. Designing Configuration Objects
The goal for all MIB modules should be to serve operational
purposes. MIB modules can be thought of a models upon some
aspect of a subsystem. Chosing those aspects of a subsystem to
that are operationally useful.
What is operationally useful?
Objects that directly control behavior. A given the housecontrol
mib, something that performs an operation intended by the user
of the system, such as turning on and off a light.
What is the right level of granularity?
An example of an object that is not or marginally operationally
useful might be manipulating voltage and current to the light.
If a MIB module used for configuration contains "too many" objects to
provision a given facility, then it is likely an abstraction
problem. If there are overlapping
objects with similar capabilities, then the abstraction may be
to blame as well. For example, consider the house control MIB
module configuration request to turn on all lights in a house. There
may be tens of light circuits in a given single family
MacFaden et al Expires May 2001 [Page 12]
Internet Draft SNMP Configuration November 2000
home. The MIB module designer might be tempted to create a table with
an instance for each lighting group controlled by one more
switches and have an object to turn that light group on/off.
Yet in considering the request, this would force the
application developer to issue sets with an inordinately large
number of objects. The MIB module designer might solve this in at
least two ways. The first would be to specify an enumeration with
specific operations:
acmeGlobalHouseOperations OBJECT-TYPE
SYNTAX INTEGER {
turnOffAllLights (1),
turnOnAllLights(2)
dimAllLights(3)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Actions to apply to all Lights in a house."
::= { acmeLightGlobals 2 }
However, the ease of adding such an object has the drawback
that the relations to other read-create tables for which
individual lights suddenly become more complicated. What should
happen to read-write objects when all lights are turned using
the above object is not clearly spelled out. Exception cases
are then created and an application would have to poll all
objects correctly to obtain the current state of lights.
The second approach is to make the general command more
powerful.
acmeLightGlobalHouseAction OBJECT-TYPE
SYNTAX INTEGER {
turnOn(1),
turnOff(2),
dim(3)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Actions to apply to the lights enumerated in
acmeLightGlobalHouseArgument."
::= { acmeLightEntry 2 }
MacFaden et al Expires May 2001 [Page 13]
Internet Draft SNMP Configuration November 2000
acmeLightGlobalHouseArgument OBJECT-TYPE
SYNTAX OCTET STRING
ACCESS read-write
STATUS mandatory
DESCRIPTION
"A bitwise encoding of indices into the
light Table for which a given Action
will be applied to."
::= { acmeLightEntry 3 }
This solution makes interpreting what the original request
was much easier, but not what the current state of all the
light-groups currently are. If a history is needed of what
commands were sent, this table can record this aspect as well.
As a practical matter for most deployed MIB modules, retrieving
a consistent configuration remains problematic from most
SNMP agents that implement those MIBs.
The protocol framework provides no way to retrieve a
configuration with out knowing in advance which objects to get. A
solution that records every object using the get-next
operator reaches a point of diminishing returns scaling to large
numbers of objects and instances in an agent.
5.1.1.2. Summary Objects and State Tracking
It is generally important to track changes to a device and
to synchronize the changes with some specific configuration
repository. Availability of summary status objects (or "dummy
lights") provides simple and quick means to determine overall
configuration-state of a subsystem.
For example, checksums or configuration version ids could
be computed over a configuration so that an application
can reasonably identify an entire configuration instead of
having to poll many "LastChange" objects or have to use
TimeFilter style indexing to achieve highly efficient polling
of large tables as found in RFC 2674 and RFC 2021.
The ACME-HOUSECTL-MIB contains the following definitions:
AcmeCfgVersion ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
MacFaden et al Expires May 2001 [Page 14]
Internet Draft SNMP Configuration November 2000
"A value that starts at 0 and increases
monotonically until the max value is reached
at which point the value returns to 0."
SYNTAX Gauge32
acmeSysActiveConfigId OBJECT-TYPE
SYNTAX AcmeCfgVersion
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Current value of configuration information. This value
remains persistent across reboots and increases when
configuration changes are made to any object in this MIB."
::= { acmeHouseGlobals 3 }
If defined managed objects have state which changes on the order of
seconds the abstraction for configuration is not ideal.
Notifications to communicate the state of a rapid changing object
also would not be ideal.
5.1.1.3. Object Semantic Overlap Avoidance
MIB module designers should generally avoid specifying read-write
objects that overlap or activate potentially a similar
instance in another MIB module. Such interdependencies can lead to
potential ambiguity.
Yet defining managed objects that overlap may appear as a
convenience, such as enabling different indexing schemes, the side
effects may from the usage of the two overlapping object may not be
easily discernible. For example, in the ACME-HOUSECTL-MIB, a designer
might have designed the following two objects at different
times:
acmeWaterHeaterPilot OBJECT-TYPE
SYNTAX INTEGER {
off(1),
on(2)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The current state of the pilot light."
::= { acmeWaterHeaderEntry 4 }
MacFaden et al Expires May 2001 [Page 15]
Internet Draft SNMP Configuration November 2000
Assume the above object appeared in one table indexed by instances of
water heaters in a house. Further suppose the appearance of the
following, and its "third" state, in another section of another MIB
module:
acmeGasPilotsStatus OBJECT-TYPE
SYNTAX INTEGER {
enabled(1),
disabled(2),
primed(3)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Gas Pilots have three states, initial state is disabled, then
primed which properly heats thermocouple and activates safety
valves, then enabled."
::= { acmeGasPilotsEntry 7 }
If a port is set to primed(3) via the
acmeGasPilotsStatus, what should be reported in reported in
acmeWaterHeaterPilot for the same conceptual instance?
If one is required to overlap configuration objects, then identify
and reference the duplicated object in the DESCRIPTION clause of
the added object. Future updates to either object must be considered
in sequnce so that certain states available in one configuration object
can also be represented in another object.
Another example can be found between the IF-MIB and the BRIDGE-MIB [22].
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 }
MacFaden et al Expires May 2001 [Page 16]
Internet Draft SNMP Configuration November 2000
and the IF-MIB defines a very similar managed object:
ifAdminStatus OBJECT-TYPE
SYNTAX INTEGER {
up(1), -- ready to pass packets
down(2),
testing(3) -- in some test mode
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The desired state of the interface. The testing(3) state
indicates that no operational packets can be passed. When a
managed system initializes, all interfaces start with
ifAdminStatus in the down(2) state. As a result of either
explicit management action or per configuration information
retained by the managed system, ifAdminStatus is then
changed to either the up(1) or testing(3) states (or remains
in the down(2) state)."
::= { ifEntry 7 }
dot1dStpPortEnable can not properly display the state of a port that
is set to testing(3) via the ifAdminStatus.
In additon, these objects can be directly related by using the managed
object:
dot1dBasePortIfIndex OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of the instance of the ifIndex object,
defined in MIB-II, for the interface corresponding
to this port."
::= { dot1dBasePortEntry 2 }
Fate sharing of SNMP tables should be explicitly defined where
possible using SMI constructs such as AUGMENTS. If the
relationship between tables can not be defined using SMIv2
macros, then the DESCRIPTION clause should define what should
happen.
Since the dot1dBasePortTable is indexed by dot1dBasePort and each row
in the dot1dBasePortTable references a row in the ifTable via
the above managed object, it is not well defined how fate sharing
of two related rows should be handled.
MacFaden et al Expires May 2001 [Page 17]
Internet Draft SNMP Configuration November 2000
5.1.1.4. Configuration Data Persistence Ambiguity
Many SNMP agents implement simple persistence models. SNMP set requests
against MIB objects with MAX-ACCESS read-write are typically
written automatically to a peristent store.
There now exist new methods to support explicit storage of
configuration data. textual 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] definion for the schedTable row
object schedStorageType of syntax StorageType, as well as similar
row objects for virtually all of the tables of the SNMPv2 View-based
Access Control Model MIB [15].
A second method for persistence simply uses the DESCRIPTION macros
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 in internet deployed network elements is a dual
persistence model where: 1) a volatile memory configuration can
be retrieved/updated and 2) persistent boot configuration.
Single persistence systems suffer the ability to rollback
changes that cause lost connectivity and hence are not often
found in backbone wide area networks operated over remote
connections.
MacFaden et al Expires May 2001 [Page 18]
Internet Draft SNMP Configuration November 2000
5.1.1.5. Data Architecture Independence
Do not use OCTET STRINGS to transport data whose interpretation will
differ by management station memory architecture. If an OCTET
STRING encoding is useful within the context of the MIB module, a well-
specified generic model should be used such as the RFC 2674 VLAN
Bridge [24] PortList TEXTUAL-CONVENTION.
5.1.2. Administrative Consistency
A MIB module which has MIB objects that are ambiguous with regard to
a devices behavior when configuration is made should be avoided.
5.1.2.1. 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.
Any complex configuration should have a master on/off switch
as well as strategically placed on/off switches to control the
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
to be possibly 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
global ospfAdminStat:
ospfAdminStat OBJECT-TYPE
SYNTAX Status
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The administrative status of OSPF in the
MacFaden et al Expires May 2001 [Page 19]
Internet Draft SNMP Configuration November 2000
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 the set of the
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 }
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
MacFaden et al Expires May 2001 [Page 20]
Internet Draft SNMP Configuration November 2000
deactivates itself."
::= { schedEntry 15 }
The above example of a writeState/readStatus object pair does
bring up one operational complication in their usage as a
pair. Consider the relationship between ifAdminStatus and
ifOperStatus. It is clear that, assuming no errors get in the way, a
management application can set an interface whose ifOperStatus is
down(2) to the point of having its ifOperStatus report up(1) by
setting the ifAdminStatus on the interface to up(1), and polling
ifOperStatus until it reaches the desired state. An application
cannot detect, however, whether an interface whose ifOperStatus
reports down(2) will reach the state of reporting up(1)
independent of that application's own operation on the interface
(i.e., through another management application or system
initialization complete). In the case where an object is known to be
in the process of being made enabled or up and the writable
administrative object is set to 'enable' or 'bringUp', it is hoped that
the agent will be able to silently discard the "redundant" request.
Finally, a MIB module designer should not overload RowStatus objects 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.
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.
5.1.2.2. Activation Latency in MIB modules
It is important for MIB module desinters to design in features
to accomodate considerations for activation latency in the
structure of their read-write objects as well.
Many MIB module designs make the mistake of assuming an agent
can activate a set operation as quickly as the agent can reply to
the manager for a given set PDU result. The RF MIB [26]
is a useful example. The docsIfDownstreamChannelTable contains
the following managed object:
MacFaden et al Expires May 2001 [Page 21]
Internet Draft SNMP Configuration November 2000
docsIfDownChannelFrequency OBJECT-TYPE
SYNTAX Integer32 (0..1000000000)
UNITS "hertz"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The center of the downstream frequency associated with
this channel. This object will return the current tuner
frequency. If a CMTS provides IF output, this object
will return 0, unless this CMTS is in control of the
final downstream RF frequency. See the associated
compliance object for a description of valid frequencies
that may be written to this object."
REFERENCE
"DOCSIS Radio Frequency Interface Specification,
Section 4.3.3."
::= { docsIfDownstreamChannelEntry 2 }
When there is anticipated latency in activating the results of a set
operation, it would be best if a MIB module designer either
o define a form of state machine to support the intermediate states and
necessary objects to model it
o Separate out read state of the management data (in a separate
object) from its read-write state object.
For example, if the ACME-HOUSECTL-MIB had implemented the
garage door with a single object as follows:
acmePortGarageDoor OBJECT-TYPE
SYNTAX INTEGER { unknown(0), closed(1), open(2)}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The current state of the garage door.
Most garage doors open completely within 12 seconds."
::= { acmePortGarageEntry 2 }
MacFaden et al Expires May 2001 [Page 22]
Internet Draft SNMP Configuration November 2000
T(0) Manager--------> <--------------Agent
|
GetPDU(acmePortGarageDoor.1.1)
|
ResponsePDU(error-index 0,
| error-code 0)
| acmePortGarageDoor.1.1 == open(2)
| SetPDU(acmePortGarageDoor.1.1 =
closed(1))
|
ResponsePDU(error-index 0,
| error-code 0)
| acmePortGarageDoor.1.1 == closed(1)
| GetPDU(acmePortGarageDoor.1.1)
| ResponsePDU(error-index 0,
error-code 0)
|
V acmePortGarageDoor.1.1 == open(2)
. . .
(some seconds later...)
|
GetPDU(acmePortGarageDoor.1.1)
| ResponsePDU(error-index 0,
error-code 0)
| acmePortGarageDoor.1.1 = closed(1)
V
But the Manager expected the value of closed(1) since it had
just set that value! Repeated polling of the object will
eventually return the state value of closed(1) assuming nothing
prevented the door from returning to the open state.
Another consideration related to latency concerns the granularity
of updates. Many management application environments may be
able to poll agents much more quickly than the the agents are
reporting values of can be updated in the agent. This is the reason
it is useful for the agent in the agent capability MIB for the device
what the minimum polling interval is.
MacFaden et al Expires May 2001 [Page 23]
Internet Draft SNMP Configuration November 2000
5.1.2.3. Application Error Reporting
Applications should not rely on the SNMP protocol error mechanisms
themselves to report application layer errors for SET operations.
It is far better in configuration-capable MIB module design to use
objects to track application level state. Management
applications to date do not handle errors gracefully from the SNMP.
Even if the management station SNMP will catch a "badValue" error, the
application should report additional application level error-state that
an application or manager can obtain from an agent and decode. Failure
to provide detailed diagnostic information leads to management
applications that end up reporting insufficient and misleading error
information.
acmeSysDeviceLastErr OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"A description of the last error that occurred in
this MIB due to configuration errors or status error
presentable to user interface."
::= { acmeHouseGlobals 7 }
In addtion, a notification might be used to signal configuration
failures.
5.1.2.4. Notification Hysteresis Avoidance
When designing notifications, keep in minde an upper limit on the
number of notifications (or traps) that can be sent in response to a
given event. RMON I[30] defines a generic trap capability in alarmTable
and experience shows that such design is indeed needed.
The greater the frequency of an event which causes a notification to
be sent, the greater the need for either internal aggregation and
redesign of the notification and/or throttling in the agent.
Also, there can be cases where it is not useful to send notifications
for a given notification. It is useful to include in the DESCRIPTION
clause when the notification should not be sent.
A good example is the frDLCIStatusChange defined in RFC 2115[19].
MacFaden et al Expires May 2001 [Page 24]
Internet Draft SNMP Configuration November 2000
In the case when interfaces are taken down administratively, no
frDLCIStatusChange is sent. Otherwise, notifications are sent at
no greater a rate than frTrapMaxRate seconds, with the option of delay
or discard of more frequently generated trap conditions at the agent's
discretion.
Alternatively, one can define trap aggregation objects. Here is
another example of defining two different traps over the same
event which allows the implementor to gracefully indicate to
a manager an event that may have occured many times.
acmeHouseCtlDeviceLost NOTIFICATION-TYPE
OBJECTS { acmeHouseInvenDevice, acmeHouseInvenKey,
acmeHouseInvenAdminStatus,
acmeHouseInvenOperStatus}
STATUS current
DESCRIPTION
"This notification is generated whenever
the invocation of a scheduled action fails.
If there is a failure of many devices
such that sending single notifications would be
resource and time prohibitive,
send the acmeHouseCtrlManyDevicesLost
notification."
::= { acmeHouseCtlGlobalErrs 1 }
acmeHouseCtlManyDevicesLost NOTIFICATION-TYPE
OBJECTS { acmeSysDevicesLastFailed, acmeSysDeviceErrors }
STATUS current
DESCRIPTION
"This notification is generated whenever
the invocation of a
scheduled action fails. If there is a failure
of many devices such that sending single
notifications would be resource and time
prohibitive, send acmeHouseCtrlManyDevicesLost
notification."
::= { acmeHouseCtlGlobalErrs 2 }
5.1.2.5. Transaction Control MIB Objects
Consistent with the considerations in [SNMPTRANS], when a standard
MIB module is defined that include configuration operations, thought
should be given to providing transaction control objects in places
MacFaden et al Expires May 2001 [Page 25]
Internet Draft SNMP Configuration November 2000
where they may have value. Here are some examples:
o Control objects that are the 'write' or 'commit' objects.
Such objects will cause the all pending transactions (change MIB
object values as a result of SET operations) to be committed to
a permanent repository or operational memory as defined by the
semantics of the MIB objects.
o Control objects at different levels of configuration
granularity.
One of the decisions for a MIB module designer is
what are the meaningful levels of granularity that make
sense. For example, in the routing area, would changes be
allowed on a per protocol basis only or by protocol area such
as BGP? If allowed at the BGP level, are sub-levels permitted
such as per autonomous system? Obviously these control will be
impacted by the underlying software design.
Row-status also has important relevance as a general transaction
control object. See discussions on row-status elsewhere in this
document for additional details.
5.1.3. Consistency with SNMPv3 Standards
The current version of SNMP and its management framework call for a
number of objects to be present in table rows. For the benefit of
SNMP-based configuration, the proper usage of those objects (as called
for in [7] and [14] and as further refined in SNMPv3 usage) is
necessary for operational consistency.
5.1.3.1. Enumerating Capabilities
Distinguishing which capabilities an agent can and must support
can be done in an Agent Capability MIB or by simply designing
placing an object into the MIB module to indicate required basic
capabilities, using a bitmask or other form of multi-selection
data element.
For example, the use of capability bits in RFC 2674 [24]
dot1dDeviceCapabilities can define some preset levels of
agent capability:
MacFaden et al Expires May 2001 [Page 26]
Internet Draft SNMP Configuration November 2000
dot1dDeviceCapabilities OBJECT-TYPE
SYNTAX BITS {
dot1dExtendedFilteringServices(0),
-- can perform filtering of
-- individual multicast addresses
-- controlled by GMRP.
dot1dTrafficClasses(1),
-- can map user priority to
-- multiple traffic classes.
dot1qStaticEntryIndividualPort(2),
-- dot1qStaticUnicastReceivePort &
-- dot1qStaticMulticastReceivePort
-- can represent non-zero entries.
dot1qIVLCapable(3), -- Independent VLAN Learning.
dot1qSVLCapable(4), -- Shared VLAN Learning.
dot1qHybridCapable(5),
-- both IVL & SVL simultaneously.
dot1qConfigurablePvidTagging(6),
-- whether the implementation
-- supports the ability to
-- override the default PVID
-- setting and its egress status
-- (VLAN-Tagged or Untagged) on
-- each port.
dot1dLocalVlanCapable(7)
-- can support multiple local
-- bridges, outside of the scope
-- of 802.1Q defined VLANs.
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Indicates the optional parts of IEEE 802.1D and 802.1Q
that are implemented by this device and are manageable
through this MIB. Capabilities that are allowed on a
per-port basis are indicated in dot1dPortCapabilities."
REFERENCE
"ISO/IEC 15802-3 Section 5.2,
IEEE 802.1Q/D11 Section 5.2, 12.10.1.1.3/b/2"
::= { dot1dExtBase 1 }
For configuration ability specifically, one can extend this
notion to exposing a different set of ad-hoc set capabilities.
MacFaden et al Expires May 2001 [Page 27]
Internet Draft SNMP Configuration November 2000
5.1.3.2. Usage of Row notReady Status
It is useful when configuring new rows to use the notReady status
to indicate row activation can not 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 addtion, an snmp get of
such an object then should return a noSuchName 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 require more objects to be set
than what is specified in a MIB module, an Agent capabilities MIB
module can be used to define the additional objects 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.
5.1.3.3. Exposure of Row Object Modifiability
Once a rowStatus value is active(1) for a given row, the
management application should be able to determine the semantics are
for making addtional changes to a row. RMON I MIB control table
objects spell out explicitly what managed objects in a row
can and can not be changed once a given rowStatus goes active.
Some operations and states may require an extended period of time to
run with given set of parameters. Where change of those parameters
under given conditions would necessitate the restarting of the whole
greater operation, that constraint should be specified in the
DESCRIPTION clause of the modifiable row object.
5.1.3.4. Octet String Aggregations
Octet strings should not be used to aggregate management data
which logically reside in multiple objects. Instead, separate objects
MacFaden et al Expires May 2001 [Page 28]
Internet Draft SNMP Configuration November 2000
should be specified in separate MIB objects or instances.
Additionally, an octet string is by definition limited to 65535 bytes
per SMIv2[5]. If the object being modeled is larger than this size, one
should abstract the information or reorganize the data to fit within
this size boundary which helps keep configuration working in the face
of abnormally behaving networks not to mention fragmenting packets
and the ensuing bad performance.
5.1.4. MIB Object and Practice Reuse
Independent of other considerations for pure consistency with the
current required standards in deployment and application usage of SNMP
as described in [SNMP3CONS], the evolution of SNMP usage has provided a
number of highly useful objects, conventions, and practices. While
these objects and practices may not be MIB requirements, experience has
shown a number to have specific value for SNMP MIB modules exposing
configurability.
5.1.4.1. Textual Convention Usage
Textual conventions should be used whenever possible to create a
consistent semantic for an oft recurring practice.
Textual conventions that have even the slightest 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, the state of an object can often be described
using a TruthValue textual convention [6] instead of inventing yet
another Boolean condition enumeration with potentially conflicting
semantics and values from many other enumerations just like it. Hence,
acmePatioLights OBJECT-TYPE
SYNTAX INTEGER {
on(1),
off(2),
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Current status of outdoor lighting."
MacFaden et al Expires May 2001 [Page 29]
Internet Draft SNMP Configuration November 2000
::= { acmeOutDoorElectricalEntry 3 }
Would better expressed as follows:
AcmePatioLightsEnabled OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Current status of outdoor lighting."
::= { acmeOutDoorElectricalEntry 3 }
5.1.4.2. Usage of Extension Capability of Standard Notification Objects
Vendor extensions to existing standard notifications are not
explicitly disallowed or allowed in SMIv2[5]. Exploiting this
resulting capability provides powerful opportunities for notification
reuse. For example, linkUp and linkDown traps are defined as follows
in [17]:
linkDown NOTIFICATION-TYPE
OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
STATUS current
DESCRIPTION
"A linkDown trap signifies that the SNMPv2 entity,
acting in an agent role, has detected that the
ifOperStatus object for one of its communication
links is about to enter the down state from some
other state (but not from the notPresent state).
This other state is indicated by the included
value of ifOperStatus."
::= { snmpTraps 3 }
An implementation could add additional varbind objects to
standard notifications to, for example, provide vendor-specific
objects pertinent to administrative disabling of a link. If an
implementation is to do this, however, it is best if it not enable
these extensions by default and require explicit enabling of them.
An implementation which does this should append to the
varbind list any extensions after those specified for the standard
notification.
Note, however, that this approach has problems when a standards body
MacFaden et al Expires May 2001 [Page 30]
Internet Draft SNMP Configuration November 2000
working group updates a trap in the future. One problem arises when
the standards update includes the same object but not in the same
sequence. Applications which rely on position of varbinds can
fail unexpectedly in these circumstances.
Hence, the conservative approach is to use private notifications if
possible.
5.1.4.3. OwnerString Usage
Experience has shown that usage of OwnerString to represent row
ownership can be a useful diagnostic tool. Specifically, the use of
the string "monitor" to identify configuration set by an agent/local
management has been useful in application.
5.1.4.4. TimeStamp Diagnostics
Adding a TimeStamp object to read-create tables to show when it was
activated is a useful diagnostic tool in the detection of
configuration errors.
Examples include the following objects from the IP Forwarding
MIB [25] ipCidrRouteTable and RF MIB [26] docsIfCmtsCmStatusTable
respectively:
ipCidrRouteAge OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of seconds since this route was
last updated or otherwise determined to be
correct. Note that no semantics of `too old'
can be implied except through knowledge of the
routing protocol by which the route was
learned."
DEFVAL { 0 }
::= { ipCidrRouteEntry 8 }
docsIfCmtsServiceCreateTime OBJECT-TYPE
SYNTAX TimeTicks
SYNTAX TimeStamp
MacFaden et al Expires May 2001 [Page 31]
Internet Draft SNMP Configuration November 2000
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime when this entry was created."
::= { docsIfCmtsServiceEntry 5 }
Note that one example above is relative to the time of last
update, and the other is relative to sysUpTime.
5.1.4.5. Expressing Agent Capacity
Managed systems often would prefer to know how many rows
might be created in a given table. Failiure to activate a row
due to capacity should be able explicitly discernable.
All implementations have limits on how many rows of a given
resource can be created. Solutions used include runtime objects
that provide current resource left, limiting the number of rows
in notReady or notInService state, as a description in the
Agent Capabilities.
5.1.5. Secure Agent Considerations
5.1.5.1. SNMPv1 Community String Defaulting
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, which have been recognized
and exploited. When using SNMPv1, supporting read only
community strings is a common practice.
5.1.5.2. Authentication Traps
The default state of RFC 1215 [4] Authentication traps should be
off.
In the "Notification Hysteresis Avoidance" section of this document,
issues and recommendations on throttling traps were raised. Where
notifications are sent in SNMPv1 trap PDUs, unsolicited
MacFaden et al Expires May 2001 [Page 32]
Internet Draft SNMP Configuration November 2000
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.
5.1.5.3. Specification of 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.
The DESCRIPTION clause for the 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.
If an implementation does not support DES, then the customer
should not allow access to these objects, which is easy to
specify in VACM [15].
When writing standards track MIB modules, one must operate on the basis
of the "must implement" properties are of the various standards-track
specifications. Confidentiality is not a must-implement portion of the
SNMPv3 management framework [11].
5.1.5.4. Consider large volumes
The issue of transferring large amounts of configuration data
via SNMP remains difficult. A common practice used to move
large amounts of data involved using SNMP in combination with
other protocols defined for transporting bulk data.
5.2. Management Software Development
This section focuses on general issues related to the
development of SNMP based applications that configure one or
more network elements. Special considerations for what has
come to be known as policy-based management with SNMP are
discussed in a following section. Effective software for the
configuration of one or many network elements requires some up
MacFaden et al Expires May 2001 [Page 33]
Internet Draft SNMP Configuration November 2000
front design work before starting implementation. This is true
regardless of the technology used to represent and transfer the
configuration information.
5.2.1. 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,
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 designer
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.2.2. SET Operations
Management software should adapt its SET operations to the
type of device and specific MIB objects included in the SET
PDU. The specific intent here is to attempt to move the
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 example that all
management software should employ is to reduce to the smallest
reasonable number, the number of SET PDU exchanges between the
MacFaden et al Expires May 2001 [Page 34]
Internet Draft SNMP Configuration November 2000
managed device and the management software. 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.
5.2.3. Configuration Transactions
There are several types of configuration transactions that
can be supported by SNMP-based configuration applications. They
include transactions on a single table, transactions across
several tables in a managed device and transactions across many
devices. The managers ability to support these different
transactions is partly dependent on the design of the MIB
objects within the scope of the configuration operation.
To effectively make use of any kind of transaction semantics,
SNMP management software must be aware of the information in the MIB
modules that it is to configure so that it can effectively utilize row
status 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 to effect
this management application transactional support. One was mentioned
in the preceding section. A transactional effect is optimized when the
maximum number of SET variable bindings are conveyed in a single
processed PDU on the agent.
There is an important refinement to this, however, for set of table row
data objects. The set of read-create row data objects for the table
should be set in a single PDU or set of PDUs, and the verification of
MacFaden et al Expires May 2001 [Page 35]
Internet Draft SNMP Configuration November 2000
their successful set (through the response to the Set PDU or the
subsequent polling of the row data objects to verify their setting in
the desired state) should be done. Only at the point of that
verification should the set on the applicable RowStatus object(s), to
set the rows to active, be done. 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.2.4. 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 reflects 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.
Management systems should also provide configuration options with
defaults for users that tend
to retrieve the smallest amount of data to achieve the
particular goal of the application.
5.2.5. 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 resiliency in the case of network
failures as well.
MacFaden et al Expires May 2001 [Page 36]
Internet Draft SNMP Configuration November 2000
5.3. Handling Multiple Managers
Devices are often modified by multiple management entities.
These management entities may be in the same organization or
may be in different organizations interior or exterior to a
given autonomous system.
There are many aspects to view this model from. First,
the changes between two or more management applications issuing SET
protocol operations need be coordinated. Race conditions
should be easily detectable when two entities provision exactly
the same object or within a transaction a group of objects.
Second, A device 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 command line interface.
The SMIv2 defines the Textual convention TestAndIncr often
called a SpinLock to solve race conditions. As with much of the
SNMP framework detail, much flexibility is left to the implementors to
"do the right thing."
Unless a MIB module explicitly defines the use mandatory use of
synchronization primitives, an agent cannot enforce their
use. Where used, an object of syntax TestAndIncr should be well
defined as to what it is being covered. However the use of a general
all encompassing lock can be used, such as the RFC 1907 snmpSetSerialNo
object [16].
An application should use this object if there is no specific
TestAndIncr object.
5.4. Management Station Time
SNMP-based management systems have had to deal with
time-based data since they were first deployed. The best
example of this is the performance data collection area where
total work performed is calculated on an interface over some
period of time. This information is then stored and used later
in the production of reports. Similarly, configuration
information must also be saved in a time-coherent fashion. This
means that all configuration transactions should be logged to
MacFaden et al Expires May 2001 [Page 37]
Internet Draft SNMP Configuration November 2000
permanent storage so that they too can be reported. Of equal
importance is the ability to restore the managed elements in an
network to a 'known' state in the past. Often this will mean
the (re)configuration of devices in different countries and
time zones. Management software must also be able to deal with
this. There are many commercial database systems that have this
property. There are also a number of proprietary approached
that have been created to provide this function.
See the Schedule and Time issues in the Policy section of
this document for discussion of related issues.
6. POLICY BASED MANAGEMENT
Since policy based management with SNMP is a relatively new
concept, this section does not document established practice
with regard to policy-enabled SNMP management systems. It gives
some background and defines terms that are relevant to this
field and describes recommended deployment approaches.
Issues that one should consider when deploying an
SNMP-enabled policy management system are also discussed.
6.1. Information Related to Policy 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. An effective policy
management system will include the following information about
each network element before sending policies for execution:
o The operational state of network elements that are to be
configured.
In particular, 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 download or if the condition is
acceptable. 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 if the
MacFaden et al Expires May 2001 [Page 38]
Internet Draft SNMP Configuration November 2000
resource is still not available.
o The capabilities of the devices in the network.
A capability can be almost any unit of work a network element can
perform. These include, routing protocols supported, Web Server
and OS versions, queuing mechanisms supported on each interface
that can be used to support different qualities of service, and
many others. this information can be obtained from the
capabilities table of the Policy MIB module.
o The capacity of the devices to perform the desired
work.
Capability is an ability to perform the desired work
while a 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 for a
reasonable period of time.
6.2. Policy, Mechanism/Implementation and Instance Specific Modules
A conformant system could implement the policy module
without any mechanism or implementation-specific modules though
it is thought that will not be a likely scenario. 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
MacFaden et al Expires May 2001 [Page 39]
Internet Draft SNMP Configuration November 2000
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 they intent the box to
be 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.
6.3. Schedule and Time Issues
In large networks it may be necessary to coordinate the
application of policies across time zones. Wherever possible,
the network elements should support time information that
includes local time zone 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.
6.4. Conflict Detection, Resolution and Error Reporting
Sophisticated conflict detection and resolution is not
realistically achievable in the short-term. Using a
hierarchical approach to this problem can achieve significant
benefits. Each 'layer' policy management system should be able
to check for some errors and report them. 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
however. They types of 'conflicts' that are usually processed
related are to resource availability and validity of the set
operations. In a policy enabled system, there are not
additional requirements for this software assuming that good
error detection and reporting appropriate to this level had
MacFaden et al Expires May 2001 [Page 40]
Internet Draft SNMP Configuration November 2000
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 not requirements.
Mechanism and implementation-independent: The software that
implements the mechanism and implementation-independent
function will most often be a realization of the policy
module. This software does assume some limited role in conflict
detection. Specifically this software should verify that no two
policies with the same precedence are allowed on the
system. The policy system should also report events where one
policy overrides another or when an element under policy
control has been modified outside the policy system as would be
the case of CLI modifications to elements under policy control.
6.5. Policy Precedence and Grouping
TBD
6.6. Changes to configuration outside of the policy system
A goal of SNMP-based policy management is to coexist with
other forms what have 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.
More on contexts TBD.
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
MacFaden et al Expires May 2001 [Page 41]
Internet Draft SNMP Configuration November 2000
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.
6.6.1. Use of Contexts
TBD
6.6.2. Policy distribution applications
TBD
6.6.3. Notifications in a Policy System
TBD
7. EXAMPLE MIB MODULES
ACME-HOUSECTL-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-IDENTITY, Counter32, Gauge32,
OBJECT-TYPE, TimeTicks, Integer32, NOTIFICATION-TYPE
FROM SNMPv2-SMI
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF
TruthValue, TEXTUAL-CONVENTION, TimeStamp
FROM SNMPv2-TC
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB;
acmeHouseCtlMIB MODULE-IDENTITY
LAST-UPDATED "200007090000Z"
ORGANIZATION "Acme, Inc"
CONTACT-INFO
"Acme, Inc
1 Main Street
Anytown, Anywhere"
DESCRIPTION
MacFaden et al Expires May 2001 [Page 42]
Internet Draft SNMP Configuration November 2000
"This mib module defines a sample mib module
that contains status/inventory, configuration and
diagnostic
management objects for items in a single family home."
REVISION "200007090000Z"
DESCRIPTION
"Initial version of ACME-HOUSECTRL-MIB."
::= { XXX 55 }
--
-- Textual Conventions
--
AcmeCfgVersion ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A value that starts at 0 and increases monotonically
until the Max value is reached at which point the value
returns to 0."
SYNTAX Gauge32
AcmeDeviceAdminStatus ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The operational state of a device. Setting a device to
testing invokes diagnostic routines which may or may not
bring a device out of service."
SYNTAX INTEGER {
up(1),
down(2),
testing(3)
}
AcmeDeviceOperStatus ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The current general state of the device. A failed state
indicates the device is not responding to management
control"
SYNTAX INTEGER {
up(1),
down(2),
testing(3),
failed(4)
}
MacFaden et al Expires May 2001 [Page 43]
Internet Draft SNMP Configuration November 2000
--
-- Top level delegations
--
acmeHouseInventory OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Inventory of the controls in the home over which
operations can be made."
::= { acmeHouseCtlMIB 1 }
acmeHouseGlobals OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Objects of global scope over a given home."
::= { acmeHouseCtlMIB 2 }
acmeHouseConfig OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Configuration of devices managed by this MIB
or subsidiary MIB modules."
::= { acmeHouseCtlMIB 3 }
acmeHouseCtlExceptions OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Exceptions of global scope to this mib defined here."
::= { acmeHouseCtlMIB 9 }
acmeHouseCtlConformance OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Conformance details kept here for this MIB."
::= { acmeHouseCtlMIB 10 }
--
-- Inventory Group
--
acmeHouseInvenLastUpdated OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Timestamp when inventory report was last updated. A value of
zero indicates never."
MacFaden et al Expires May 2001 [Page 44]
Internet Draft SNMP Configuration November 2000
::= { acmeHouseInventory 1 }
acmeHouseInvenNumber OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of rows in acmeHouseInvenTable."
::= { acmeHouseInventory 2 }
acmeHouseInvenTable OBJECT-TYPE
SYNTAX SEQUENCE OF AcmeHouseInvenEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table presents a list of devices found
in a given home.
Rows are added and deleted by the agent as discovered."
::= { acmeHouseInventory 3 }
acmeHouseInvenEntry OBJECT-TYPE
SYNTAX AcmeHouseInvenEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each row represents a particular device managed
by this agent."
INDEX { acmeHouseInvenId }
::= { acmeHouseInvenTable 1 }
AcmeHouseInvenEntry ::= SEQUENCE {
acmeHouseInvenId SnmpAdminString,
acmeHouseInvenDevice OBJECT IDENTIFIER,
acmeHouseInvenKey Integer32,
acmeHouseInvenAdminStatus AcmeDeviceAdminStatus,
acmeHouseInvenOperStatus AcmeDeviceOperStatus,
acmeHouseInvenLastContact TimeStamp
}
acmeHouseInvenId OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
MacFaden et al Expires May 2001 [Page 45]
Internet Draft SNMP Configuration November 2000
"A persistent identifier that identifies
a device uniquely within a single domain."
::= { acmeHouseInvenEntry 1 }
acmeHouseInvenDevice OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The object identifier that uniquely identifies
the type of device. A registration mib maintains
the mappings to text. A vaue of 0.0 represents
an unknown or unmanageable device."
::= { acmeHouseInvenEntry 2 }
acmeHouseInvenKey OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A unique value within a given set of device
with the same acmeHouseInvenDevice object identifier.
Can be used for a short-hand indexing
to other tables and notifications."
::= { acmeHouseInvenEntry 3 }
acmeHouseInvenAdminStatus OBJECT-TYPE
SYNTAX AcmeDeviceAdminStatus
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The desired administrative status of this device.
Setting the value to down(2) has the effect of
changing acmeHouseInvenOperStatus to down(2) as well."
::= { acmeHouseInvenEntry 4 }
acmeHouseInvenOperStatus OBJECT-TYPE
SYNTAX AcmeDeviceOperStatus
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The curent operational state of the device."
::= { acmeHouseInvenEntry 5 }
MacFaden et al Expires May 2001 [Page 46]
Internet Draft SNMP Configuration November 2000
acmeHouseInvenLastContact OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime when the device last responded
to any management request or last poll."
::= { acmeHouseInvenEntry 6 }
--
-- Configuration Globals Group
--
acmeHouseGlobalSysActive OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"State of house control system. A value of true(1) represents
the system is actively monitoring state and will
accept valid configuration requests. A value of false(2)
indicates this the master system is not maintaining
state of systems found in the inventory component."
::= { acmeHouseGlobals 1 }
acmeSysActiveLastChanged OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"sysUpTime when acmeHouseGlobalSysActive last changed state."
::= { acmeHouseGlobals 2 }
acmeSysActiveConfigId OBJECT-TYPE
SYNTAX AcmeCfgVersion
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Current value of configuration information. This value remains
persistent across reboots and increases when configuration
changes are made to any object in this MIB."
::= { acmeHouseGlobals 3 }
acmeSysDevicesActive OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
MacFaden et al Expires May 2001 [Page 47]
Internet Draft SNMP Configuration November 2000
STATUS current
DESCRIPTION
"Number of active devices in the system according to last poll."
::= { acmeHouseGlobals 4 }
acmeSysDevicesLastFailed OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"sysUpTime when last device failed poll or admin request."
::= { acmeHouseGlobals 5 }
acmeSysDeviceErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of devices that this manager lost contact, timed out
with."
::= { acmeHouseGlobals 6 }
acmeSysDeviceLastErr OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A description of the last error that occured in this mib due
to configuration errors or status error presentable to user
interface."
::= { acmeHouseGlobals 7 }
--
-- Notification Section
--
acmeHouseCtlGlobalErrs OBJECT IDENTIFIER
::= { acmeHouseCtlExceptions 0 }
acmeHouseCtlDeviceLost NOTIFICATION-TYPE
OBJECTS { acmeHouseInvenDevice, acmeHouseInvenKey,
acmeHouseInvenAdminStatus,
acmeHouseInvenOperStatus}
STATUS current
DESCRIPTION
MacFaden et al Expires May 2001 [Page 48]
Internet Draft SNMP Configuration November 2000
"This notification is generated whenever the invocation
of a scheduled action fails. If there is a failure of
many devices such that sending single notifications
would be resource and time prohibitive, send the
acmeHouseCtrlManyDevicesLost notification."
::= { acmeHouseCtlGlobalErrs 1 }
acmeHouseCtlManyDevicesLost NOTIFICATION-TYPE
OBJECTS { acmeSysDevicesLastFailed, acmeSysDeviceErrors }
STATUS current
DESCRIPTION
"This notification is generated whenever the invocation
of a scheduled action fails. If there is a failure of
many devices such that sending single notifications
would be resource and time prohibitive, send the
acmeHouseCtrlManyDevicesLost notification."
::= { acmeHouseCtlGlobalErrs 2 }
--
-- Compliance Section
--
acmeHouseCtlGroups OBJECT IDENTIFIER
::= { acmeHouseCtlConformance 1 }
acmeHouseCtlCompliances OBJECT IDENTIFIER
::= { acmeHouseCtlConformance 2 }
acmeHouseInventoryGroup OBJECT-GROUP
OBJECTS {
acmeHouseInvenLastUpdated,
acmeHouseInvenNumber,
acmeHouseInvenDevice,
acmeHouseInvenKey,
acmeHouseInvenAdminStatus,
acmeHouseInvenOperStatus,
acmeHouseInvenLastContact
}
STATUS current
DESCRIPTION
"A collection of objects providing
inventory and general status of all home objects controlled
by this MIB module."
MacFaden et al Expires May 2001 [Page 49]
Internet Draft SNMP Configuration November 2000
::= { acmeHouseCtlGroups 1 }
acmeHouseGlobalsGroup OBJECT-GROUP
OBJECTS {
acmeHouseGlobalSysActive,
acmeSysActiveLastChanged,
acmeSysActiveConfigId,
acmeSysDevicesActive,
acmeSysDevicesLastFailed,
acmeSysDeviceErrors,
acmeSysDeviceLastErr
}
STATUS current
DESCRIPTION
"A collection of objects providing
overall feature configuration state status."
::= { acmeHouseCtlGroups 2 }
acmeHouseCtlNotificationGroup NOTIFICATION-GROUP
NOTIFICATIONS {
acmeHouseCtlDeviceLost,
acmeHouseCtlManyDevicesLost
}
STATUS current
DESCRIPTION
"The notifications used by this MIB module to denote
exceptional conditions."
::= { acmeHouseCtlGroups 3 }
acmeHouseCtrlMibCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The set of groups that make up the mandatory
and optional groups
required for MIB module implementation."
MODULE
MANDATORY-GROUPS { acmeHouseInventoryGroup,
acmeHouseGlobalsGroup }
::= { acmeHouseCtlCompliances 1 }
END
ACME-AGENTCAP-MIB DEFINITIONS ::= BEGIN
MacFaden et al Expires May 2001 [Page 50]
Internet Draft SNMP Configuration November 2000
IMPORTS
MODULE-IDENTITY
FROM SNMPv2-SMI
AGENT-CAPABILITIES
FROM SNMPv2-CONF
acmeHouseCtlMIB
FROM ACME-HOUSECTL-MIB;
acmeAgentCapabilityMIB MODULE-IDENTITY
LAST-UPDATED "200011010000Z" -- November 1, 2000
ORGANIZATION
"Acme, Inc."
CONTACT-INFO
"Acme, Inc
1 Main Street
Anytown, Anywhere"
DESCRIPTION
"This MIB Module contains a fictional agent capabilities for the
ACME-HOUSECTRL-MIB."
REVISION "200011010000Z"
DESCRIPTION
"A fictional deployment of a system implementing the ACME-
HOUSECTRL-MIB."
::= { XXX 56 }
system10 AGENT-CAPABILITIES
PRODUCT-RELEASE
"1.0"
STATUS current
DESCRIPTION
"This fictional system was deployed with these conditions."
REFERENCE
"Possibly a URL"
SUPPORTS ACME-HOUSECTL-MIB
INCLUDES { acmeHouseInventoryGroup,
acmeHouseGlobalsGroup
}
VARIATION acmeHouseInvenAdminStatus
ACCESS read-only
DESCRIPTION "First implementation does not allow updates to status."
::= { XXX 57 }
END
MacFaden et al Expires May 2001 [Page 51]
Internet Draft SNMP Configuration November 2000
MacFaden et al Expires May 2001 [Page 52]
Internet Draft SNMP Configuration November 2000
8. GLOSSARY
+++wayne this needs significant expansion+++
Transaction
A finite group of changes that 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 returned should 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.
Device-Local Configuration
Device-local configuration data is specific to a particular
network device. This is the finest level of granularity for
configuring network devices.
Network-Wide Configuration
Network-wide configuration data is not specific to any
particular network device and from which multiple device-local
configurations can be derived. Network-wide configuration
provides a level of abstraction above device-local
configurations.
Configuration Data Translator
A function that transforms Configuration Management Data
(high-level policies) or Network-wide configuration data
(middle-level policies) into device local configurations
(low-level policies) based on the generic capabilities of
network devices. This function can be performed either by
devices themselves or by some intermediate entity.
Denial of Service (DOS)
Any situation where access to resources by authorized
consumers is diminished by overt or inadvertent abuse of
network layer mechanisms
9. REFERENCES
[1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for
Describing SNMP Management Frameworks", RFC 2571, April 1999.
MacFaden et al Expires May 2001 [Page 53]
Internet Draft SNMP Configuration November 2000
[2] Rose, M., and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based Internets", STD 16, RFC 1155,
May 1990.
[3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC
1212, March 1991.
[4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC
1215, March 1991.
[5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.,
and S. Waldbusser, "Structure of Management Information Version 2
(SMIv2)", STD 58, RFC 2578, April 1999.
[6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.,
and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579,
April 1999.
[7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.,
and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC
2580, April 1999.
[8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network
Management Protocol", STD 15, RFC 1157, May 1990.
[9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "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.
MacFaden et al Expires May 2001 [Page 54]
Internet Draft SNMP Configuration November 2000
[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.
[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.
MacFaden et al Expires May 2001 [Page 55]
Internet Draft SNMP Configuration November 2000
[29] Willis, S. and J. Chu., "Definitions of Managed Objects for the Fourth
Version of the Border Gateway Protocol (BGP-4) using SMIv2", RFC 1657,
July 1994.
[30] Waldbusser, S."DRemote Network Monitoring Management Information
Base", RFC 2819, May 2000.
10. OUTSTANDING ISSUES
1. Section Introduction
do we really mean "Autonomous System" that rigidly? The
reference is specifically to RFC1930/BCP6, which gives guidance
on selecting and registering a BGP AS-ID.
2. Glossary still under development
11. INTELLECTUAL PROPERTY
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain to
the implementation or use of the technology described in this document or
the extent to which any license under such rights might or might not be
available; neither does it represent that it has made any effort to
identify any such rights. Information on the IETF's procedures with
respect to rights in standards-track and standards-related documentation
can be found in BCP-11. Copies of claims of rights made available for
publication and any assurances of licenses to be made available, or the
result of an attempt made to 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.
MacFaden et al Expires May 2001 [Page 56]
Internet Draft SNMP Configuration November 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@mediaone.net
Wayne Tackabury
Gold Wire Technology
411 Waverley Oaks Rd.
Waltham, MA 02452
email - wayne@goldwiretech.com
13. 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
MacFaden et al Expires May 2001 [Page 57]
Internet Draft SNMP Configuration November 2000
Society or other Internet organizations, except as needed for the purpose
of developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be followed, or
as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked
by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
MacFaden et al Expires May 2001 [Page 58]
| PAFTECH AB 2003-2026 | 2026-04-24 04:46:56 |