Internet Draft Distributed Management Framework Dec 1996
Distributed Management Framework
<draft-ietf-disman-framework-00.txt>
December 27, 1996
Authors:
Andy Bierman
Cisco Systems
abierman@cisco.com
Maria Greene
Ascom Nexion
greene@nexen.com
Bob Stewart
Cisco Systems
bstewart@cisco.com
Steve Waldbusser
International Network Services (INS)
waldbusser@ins.com
1. Status of this Memo
This document is an Internet-Draft. 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. Internet-Drafts may be updated, replaced, or
obsoleted by other documents at any time. It is not
appropriate to use Internet-Drafts as reference material or to
cite them other than as a ``working draft'' or ``work in
progress.''
To learn the current status of any Internet-Draft, please
Disman Team Expires June, 1997 [Page 1]
Internet Draft Distributed Management Framework Dec 1996
check the 1id-abstracts.txt listing contained in the Internet-
Drafts Shadow Directories on ds.internic.net, nic.nordu.net,
venera.isi.edu, or munnari.oz.au.
2. Abstract
This memo defines a distributed management architecture for
use with the SNMP network management architecture.
This memo does not specify a standard for the Internet
community.
Disman Team Expires June, 1997 [Page 2]
Internet Draft Distributed Management Framework Dec 1996
3. Overview
Distributed Management is the delegation of control from one
management station to another. While the SNMP Network
Management Framework does not specifically address distributed
management, this function is desired and has been implemented
and deployed in the internet using proprietary architectures.
It is desired that there be a standard upon which to promote
interoperability, as well as a common framework upon which
various systems can be built.
The goals of distributed management are:
o Scalability through Distribution
In order to build network management systems that have the
power to manage very large networks, it is important that
a system not have a single bottleneck point. Therefore,
large network management systems must be built as
distributed systems.
o Disconnected or Low-Bandwidth Operation
There are sometimes conditions when a management station
will not be in constant contact with all portions of the
managed network. This is sometimes by design in an attempt
to lower communications costs (especially when
communicating over a WAN or dialup link), or by accident
as network failures affect the communications between the
management station and portions of the managed network.
For this reason, a distributed management station will be
configured to perform network management functions, even
when communication with the management station may not be
possible or efficient. The distributed management station
may then attempt to notify the management station when an
exceptional condition occurs. Thus, even in circumstances
where communication with the distributed management
station is not continuous, network management operations
may run continuously, communicating with the management
station conveniently and efficiently, on an as-needed
basis.
o Mirroring organization boundaries and processes
Business organizations are typically set up in a
hierarchical fashion. Multiple people in the hierarchy
have different roles, responsibilites, and authority. The
Disman Team Expires June, 1997 [Page 3]
Internet Draft Distributed Management Framework Dec 1996
network management system often has to be configured to
match this organization. Distributed network managers can
be set up in a hierarchy that matches the roles of various
people in the organization.
o Promotes a modular system architecture
A modular system architecture allows flexibility and re-
usability of network management components. A distributed
network management system with well-defined interfaces
creates this modular scheme.
This document defines an architectural framework for
standards-based distributed management
4. The Network Management Framework
A distributed network management station is a management
station that receives requests from another manager and
executes those requests by performing management operations on
agents or other managers. Note that these requests may take a
long time to execute, and may be registered indefinitely.
With the addition of the distributed network management
station, the SNMP Network Management Framework consists of the
following entities:
A management system contains: several (potentially many)
nodes, each with a processing entity, termed an agent, which
has access to management instrumentation; at least one
management station; and, a management protocol, used to convey
management information between the agents and management
stations. Operations of the protocol are carried out under an
administrative framework which defines authentication,
authorization, access control, and privacy policies.
Management stations execute management applications which
monitor and control managed elements or other (distributed)
management stations. A distributed management station is a
type of management station that is controlled by another
management station. Managed elements are devices such as
hosts, routers, terminal servers, etc., which are monitored
and controlled via access to their management information.
Disman Team Expires June, 1997 [Page 4]
Internet Draft Distributed Management Framework Dec 1996
Management information is viewed as a collection of managed
objects, residing in a virtual information store, termed the
Management Information Base (MIB). Collections of related
objects are defined in MIB modules. These modules are written
using a subset of OSI's Abstract Syntax Notation One (ASN.1)
[1], termed the Structure of Management Information (SMI) [2].
The management protocol, SNMPv2 [3], provides for the exchange
of messages which convey management information between the
agents and the management stations. It is the purpose of this
document to define managed objects which describe the behavior
of a SNMPv2 entity.
5. Distributed Management Framework
The distributed management framework consists of applications
and services.
A distributed management application performs some management
function, often by monitoring and controlling managed
elements. These applications perform functions such as
threshold polling, historical data polling, or discovery. The
specifications and communications protocols of some of these
applications will be defined by standards, while others will
be enterprise specific.
Distributed management services are a collection of services
that make up the run-time environment for the distributed
management application. These services are crucial to ensuring
the usability, scalability, and efficiency of the distributed
management applications that depend on them. Some of these
services are mandatory, while others are optional. Further,
even the mandatory services allow varying depths of support,
as described further, below.
Each of these services is made available through a MIB
interface.
The purpose of these services is to provide true enterprise
management that allows distributed management functions to be
used on an enterprise-wide basis without undue amounts of
administrative difficulty. These services also make a set of
applications more efficient because the service can perform
functions or store information once for all applications on
the local system. Further, less work is required to be put
Disman Team Expires June, 1997 [Page 5]
Internet Draft Distributed Management Framework Dec 1996
into writing the application because some of the core
functions are performed elsewhere.
5.1. Known Systems
The Known Systems service provides a list of all systems which
the distributed management system knows about and is prepared
to perform management operations upon. This list may be
populated by a continuously-running auto-discovery process, it
may be populated with SNMP SET requests, or it may be a static
list dictated by the system.
This service also stores type and attribute information for
each of the known systems.
The purpose of this service is to allow a management
application to be executed on a list of systems so that true
enterprise management is possible rather than more ad-hoc
management functions. Further, the targets of management
applications can be configured separately from the
applications to reduce administrative burden as the list of
known systems changes.
An example of a known systems list is a list of all systems at
a site discovered by the autodiscovery module, along with
various addressing, type, and attribute information for each.
5.2. Management Domains
The Management Domains service provides a list of known
systems which is a subset of the entire list of known systems.
The subset is defined by a rule, or filter, which selects only
the known systems that match or those that don't match certain
criteria.
These domains are multiple, potentially overlapping, sets of
devices based on (human) organizational boundaries that define
the extents over which management operations should be
performed.
The purpose of this service is to allow a management
application to be executed on a list of known systems within a
particular domain. Further, as the domains change over time,
Disman Team Expires June, 1997 [Page 6]
Internet Draft Distributed Management Framework Dec 1996
the application will automatically be kept up to date and will
only monitor the correct systems.
An example of a management domain is the subset of all known
systems that is on the engineering LAN.
5.3. Management Operations Targets
The Management Operations Targets service provides a list of
known systems in a set of domains that match certain criteria
that indicate that it makes sense to perform a particular
management function on them.
The purpose of this service is to direct management operations
to be performance only on those systems where that operation
would make sense. Because this is described as a filter, there
are no static configuration requirements that would be
unacceptable in a dynamically changing network environment.
An example of a management operation target list is the subset
of all known routers on the engineering LAN.
5.4. Delegation Control
The Delegation Control Service provides functions that limit
the resource usage of a distributed management application
that has had control delegated to it.
Network management applications are often responsible for
adding stress on the network and causing problems. Examples
are excessive polling load on slow-speed networks or on router
CPUs. This problem will become even more dangerous when
network management functions are delegated to distributed
management stations.
Policies need to be configured that limit average and burst
polling, notification, and broadcast rates. These rates may
be defined for the sending system as a whole, per end node, or
per management application on the sending system.
It is also important to have a "Deadman's switch" so that
delegated applications will not continue indefinitely if their
"sponsor" has forgotten about them.
Disman Team Expires June, 1997 [Page 7]
Internet Draft Distributed Management Framework Dec 1996
5.5. Scheduling
The Scheduling Service allows the execution of distributed
management applications to be controlled so that they run at a
particular time, periodically, or based on the occurance of
another event.
5.6. Reliable Notification
The Reliable Notification Service provides services that
ensure that notifications are received correctly.
For example, all the information that describes an event may
not fit within a single PDU, so an eventID varbind is defined
that associates multiple PDU's as describing the same event.
It is also necessary to know if the entire notification has
been received or if more PDU's are still outstanding.
Further, a receiving management station must be given more
information so that it can distinguish duplicated inform PDU's
because events are not idempotent. No rule makes it mandatory
for the requestID to be unique for all PDUs sent from a
system.
In addition, a logging mechanism provides for retrieval of
notifications after a communications failure.
5.7. Notification Destinations
The Notification Destination Service provides services for
configuring destinations for notifications.
When management functions are delegated and MLMs are given the
autonomy to generate notifications, they need to be configured
as to where the notifications should be sent. Additionally,
retry counts and numbers need to be configured. Average and
burst notification rates need to be defined.
-- Remove hacks for Unsigned32 and BITS datatypes. I need these because
-- my version of SMIC is RFC1442 compliant, not RFC1902.
DISMAN-SERVICES-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, experimental, Integer32, zeroDotZero,
Disman Team Expires June, 1997 [Page 8]
Internet Draft Distributed Management Framework Dec 1996
NOTIFICATION-TYPE, Counter32, Gauge32, Counter64 -- , Unsigned32, BITS
FROM SNMPv2-SMI
TEXTUAL-CONVENTION, AutonomousType, DisplayString, DateAndTime,
RowStatus, TDomain, TimeStamp, TestAndIncr
FROM SNMPv2-TC
snmpUDPDomain
FROM SNMPv2-TM
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF
OwnerString
FROM RMON-MIB
;
dismanMIB MODULE-IDENTITY
LAST-UPDATED "9612221200Z"
ORGANIZATION "IETF Distributed Management Working Group"
CONTACT-INFO
"Working group mailing list: disman@nexen.com"
DESCRIPTION
"The MIB module containing SNMP variables for controlling
distributed managers."
-- Get real experimental number from IANA.
-- ::= { experimental XX }
::= { experimental 1 }
-- Hack to deal with a RFC1442 version of MIB compiler instead of
-- RFC1902.
Unsigned32 ::= Counter32
--****************************************************************
-- Textual Conventions
--****************************************************************
ElementName ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A string that uniquely identifies a management element which
may be a system or a collection of systems."
SYNTAX DisplayString (SIZE (1..64))
IANAAddrFamily ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"An address family. Values are defined in Assigned Numbers,
Disman Team Expires June, 1997 [Page 9]
Internet Draft Distributed Management Framework Dec 1996
RFC1700. Note that not all these values make sense in all
contexts where this type is used in this MIB, but they are
included for completeness."
REFERENCE
"Assigned Numbers, RFC1700, ADDRESS FAMILY NUMBERS"
SYNTAX INTEGER {
other(0),
ipV4(1),
ipV6(2),
nsap(3),
hdlc(4),
bbn1822(5),
ieee802(6),
e163(7),
e164(8),
f69(9),
x121(10),
ipx(11),
appleTalk(12),
decnetIV(13),
banyanVines(14),
e164WithNsap(15)
}
GenAddr ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The value of an address."
SYNTAX OCTET STRING (SIZE (0..60))
--****************************************************************
-- Managed Object definitions
--****************************************************************
mgmtObjects OBJECT IDENTIFIER ::= { dismanMIB 1 }
mgmtGeneralObjects OBJECT IDENTIFIER ::= { mgmtObjects 1 }
mgmtLock OBJECT-TYPE
SYNTAX TestAndIncr
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"An advisory lock for all writable objects in the entire
Distributed Management Services MIB."
Disman Team Expires June, 1997 [Page 10]
Internet Draft Distributed Management Framework Dec 1996
::= { mgmtGeneralObjects 1 }
mgmtOwner OBJECT-TYPE
SYNTAX OwnerString
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The manager entity that 'owns' this distributed manager's
configuration."
::= { mgmtGeneralObjects 2 }
mgmtAdminStatus OBJECT-TYPE
SYNTAX INTEGER {
enabled(1),
disabled(2),
disabledReset(3)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The desired status of this distributed manager. The value
'enabled(1)' indicates the distributed manager should be
active. The value 'disabled(2)' indicates that the desired
operational status is also 'disabled(2)'. A top-level manager
may disable a distributed manager in order to change its
configuration and have the changes take effect all at once or
it may keep the distributed manager disabled as a redundant or
back-up manager. The value 'disabledReset(3)' is used to
disable a distributed manager and simultaneously remove all
entries from its DISMAN MIB tables that support row
creation. This allows the top-level manager to put the
distributed manager into a known state before downloading a
new configuration."
::= { mgmtGeneralObjects 3 }
mgmtOperStatus OBJECT-TYPE
SYNTAX INTEGER {
enabled(1),
disabled(2)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The actual status of this distributed manager."
::= { mgmtGeneralObjects 4 }
Disman Team Expires June, 1997 [Page 11]
Internet Draft Distributed Management Framework Dec 1996
mgmtStatusLastChange OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime the last time mgmtOperStatus changed
value."
::= { mgmtGeneralObjects 5 }
--
-- Managed Element Services
--
-- In order for a distributed management application to use these
-- managemed element services, it must specify both a domain rule index
-- and a target rule index. For example, the trivial application below
-- would simply return the values of the systems identified by a
-- particular domain rule index and target rule index.
--
-- testAppEntry ::= SEQUENCE {
-- testAppIndex Integer32, # INDEX
-- testAppDomainIndex Integer32,
-- testAppTargetIndex Integer32,
-- testAppRowStatus RowStatus
-- }
--
-- testAppResultsEntry ::= SEQUENCE {
-- # Indexed by { testAppIndex, testAppResultsIndex }
-- testAppResultsIndex Integer32,
-- testAppResultsSystemName ElementName
-- }
--
--
-- An example distributed management system might contain:
--
-- mgmtKnownSystemTable
-- Name DateTime Algorithm ManualDomain SystemID
-- router1 ... ... ... acme5000
-- router2 ... ... ... acme3000
-- router3 ... ... ... acme5000
--
-- mgmtSysAccessTable
-- Name Index AddrType Addr SNMPPort AuthString RowStatus
-- router1 1 IP 1.1.1.1 161 ... active
-- router1 2 IP 1.1.2.1 161 ... active
-- router2 3 IP 1.1.1.5 161 ... active
Disman Team Expires June, 1997 [Page 12]
Internet Draft Distributed Management Framework Dec 1996
-- router3 4 IP 1.1.1.4 161 ... active
-- router3 5 IP 1.1.4.9 161 ... active
--
-- mgmtRuleTable
-- Index Name RowStatus
-- 1 "Finance" active
-- 2 "Acme 5000" active
--
-- mgmtRuleFilterTable
-- Index FilterIndex Type Filter RowStatus
-- 1 1 matchAddress "^1.1.2" active
-- 1 2 matchAddress "^1.1.4" active
-- # Rule 1 matches all hosts on subnet 2 and subnet 4
-- 2 3 matchSystemID "acme5000" active
--
-- testAppTable
-- Index domainIndex targetIndex RowStatus
-- 1 1 2 active
--
-- testAppResultsTable
-- Index ResultsIndex systemName
-- 1 1 "router1"
-- 1 2 "router3"
--
-- If this was a script application, the script would execute on
-- router1 and router3.
mgmtElementObjects OBJECT IDENTIFIER ::= { mgmtObjects 3 }
--
-- The Known System Table
--
mgmtKnownSystemTable OBJECT-TYPE
SYNTAX SEQUENCE OF MgmtKnownSystemEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of all known systems that are potential management
targets."
::= { mgmtElementObjects 1 }
mgmtKnownSystemEntry OBJECT-TYPE
SYNTAX MgmtKnownSystemEntry
MAX-ACCESS not-accessible
Disman Team Expires June, 1997 [Page 13]
Internet Draft Distributed Management Framework Dec 1996
STATUS current
DESCRIPTION
"Information about a single management system. While most
known systems will usually be populated by the agent, new
systems can be created using the mgmtKnownSystemRowStatus
variable."
INDEX { IMPLIED mgmtKnownSystemName }
::= { mgmtKnownSystemTable 1 }
MgmtKnownSystemEntry ::= SEQUENCE {
mgmtKnownSystemName ElementName,
mgmtKnownSystemDateTimeCreated DateAndTime,
mgmtKnownSystemAlgorithm AutonomousType,
mgmtKnownSystemManualDomain OCTET STRING,
mgmtKnownSystemID AutonomousType,
mgmtKnownSystemRowStatus RowStatus
}
mgmtKnownSystemName OBJECT-TYPE
SYNTAX ElementName
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The name of the element. If this record is created automatically
(e.g., as part of a discovery process), this name can be
algorithmically assigned using any algorithm that guarantees
uniqueness. It is recommended that this value be human readable,
and for that reason an ascii representation of the address is
often suitable in cases where more detail is not known."
::= { mgmtKnownSystemEntry 1 }
mgmtKnownSystemDateTimeCreated OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The date and time when this object was added to the distributed
managers database."
::= { mgmtKnownSystemEntry 2 }
mgmtKnownSystemAlgorithm OBJECT-TYPE
SYNTAX AutonomousType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
Disman Team Expires June, 1997 [Page 14]
Internet Draft Distributed Management Framework Dec 1996
"The method used to create this entry. The value { 0 0 } (a
NULL object identifier) indicates that the entry was added
'manually' via the table's RowStatus column. Other values may
indicate various discovery algorithms."
DEFVAL { zeroDotZero }
::= { mgmtKnownSystemEntry 3 }
mgmtKnownSystemManualDomain OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A bit mask of domains the system is a member of. Every 1 bit
in this string indicates that this system is a part of the
domain who's rule index is equal to the bit position of the
bit. The first bit in the string is equal to the rule index
of 1. If this object indicates that a system is part of a
domain, it is understood to be part of that domain no matter
what the rule set is for the domain (i.e. domain membership is
an OR function of this object and the domain rules).
This object only has an effect on rules that are used as
domains. In particular this means that if a bit is set for a
rule and that rule is used as a target, the bit will have no
effect."
::= { mgmtKnownSystemEntry 4 }
mgmtKnownSystemID OBJECT-TYPE
SYNTAX AutonomousType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The type of the system. This will typically be
the same value as the sysObjectID for the system.
The value zeroDotZero indicates an unknown type."
DEFVAL { zeroDotZero }
::= { mgmtKnownSystemEntry 5 }
mgmtKnownSystemRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The control that allows creation/deletion of system entries."
::= { mgmtKnownSystemEntry 6 }
Disman Team Expires June, 1997 [Page 15]
Internet Draft Distributed Management Framework Dec 1996
--
-- The System Management Access Table
--
mgmtSysAccessTable OBJECT-TYPE
SYNTAX SEQUENCE OF MgmtSysAccessEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of access information for the management entities
(either SNMP managers or SNMP agents) running on systems."
::= { mgmtElementObjects 2 }
mgmtSysAccessEntry OBJECT-TYPE
SYNTAX MgmtSysAccessEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information about a single management entity."
INDEX { mgmtKnownSystemName, mgmtSysAccessIndex }
::= { mgmtSysAccessTable 1 }
MgmtSysAccessEntry ::= SEQUENCE {
mgmtSysAccessIndex Integer32,
mgmtSysAccessAddrType IANAAddrFamily,
mgmtSysAccessAddr GenAddr,
mgmtSysAccessSNMPPort Integer32,
mgmtSysAccessAuthString OCTET STRING,
mgmtSysAccessRowStatus RowStatus
}
mgmtSysAccessIndex OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An index number for the access information so that the agent
can keep track of multiple managers and multiple agents
running on the same system (presumably at different transport
addresses.)"
::= { mgmtSysAccessEntry 1 }
mgmtSysAccessAddrType OBJECT-TYPE
SYNTAX IANAAddrFamily
MAX-ACCESS read-create
Disman Team Expires June, 1997 [Page 16]
Internet Draft Distributed Management Framework Dec 1996
STATUS current
DESCRIPTION
"The type of the address identified by mgmtSysAccessAddr."
DEFVAL { ipV4 }
::= { mgmtSysAccessEntry 2 }
mgmtSysAccessAddr OBJECT-TYPE
SYNTAX GenAddr
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The management address for the manager or agent. A
zero-length string indicates an unknown address."
DEFVAL { ''H }
::= { mgmtSysAccessEntry 3 }
mgmtSysAccessSNMPPort OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The port for an SNMP agent on this system."
DEFVAL { 161 }
::= { mgmtSysAccessEntry 4 }
mgmtSysAccessAuthString OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Authentication information for accessing this system at this port."
::= { mgmtSysAccessEntry 5 }
mgmtSysAccessRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A control that allows creation/deletion of system management
entity entries."
::= { mgmtSysAccessEntry 6 }
--
-- Rules
--
Disman Team Expires June, 1997 [Page 17]
Internet Draft Distributed Management Framework Dec 1996
mgmtRuleTable OBJECT-TYPE
SYNTAX SEQUENCE OF MgmtRuleEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of rules.
A rule is a set of filters by which a list of systems can be
selected from a larger list, based on a match of one or more
filters.
Rules are used in 2 contexts, to select a domain, or to
select managed operations targets. A domain defines those
systems within a particular organizational boundary within
which certain operations should be performed. A set of
management operations targets is a subset of a domain that
restricts an operation to only those systems upon which the
operation `makes sense'. Domain rules are distinguishable from
target rules only by the context in which they are
used. However, in general, it is not useful to use a filter
designed to select a target in the context of a domain, or
vice versa.
A system matches a rule if it was part of the appropriate
input set (ALL, or member of a domain), and one or more
ruleFilters evaluates to true for the system."
::= { mgmtElementObjects 3 }
mgmtRuleEntry OBJECT-TYPE
SYNTAX MgmtRuleEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information about a single rule. New rules
can be created using the mgmtRuleRowStatus variable."
INDEX { mgmtRuleIndex }
::= { mgmtRuleTable 1 }
MgmtRuleEntry ::= SEQUENCE {
mgmtRuleIndex Integer32,
mgmtRuleName DisplayString,
mgmtRuleRowStatus RowStatus
}
mgmtRuleIndex OBJECT-TYPE
Disman Team Expires June, 1997 [Page 18]
Internet Draft Distributed Management Framework Dec 1996
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A unique index for this rule."
::= { mgmtRuleEntry 1 }
mgmtRuleName OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A human readable name for this rule. This name
should describe the purpose/scope of the rule, for
example `Headquarters' or `Acme Routers'."
::= { mgmtRuleEntry 2 }
mgmtRuleRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The control that allows creation/deletion of rule entries."
::= { mgmtRuleEntry 3 }
mgmtRuleFilterTable OBJECT-TYPE
SYNTAX SEQUENCE OF MgmtRuleFilterEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of filters for a rule.
If this filter is executed in the context of a domain, it
selects a subset of all of the systems in the
mgmtKnownSystemTable. If this filter is executed in the
context of a target, it selects a subset of all systems
matched by the associated domain rule.
If a rule has multiple filters, the rule selects the union of
all systems selected by the filters."
::= { mgmtElementObjects 4 }
mgmtRuleFilterEntry OBJECT-TYPE
SYNTAX MgmtRuleFilterEntry
MAX-ACCESS not-accessible
Disman Team Expires June, 1997 [Page 19]
Internet Draft Distributed Management Framework Dec 1996
STATUS current
DESCRIPTION
"Information about a single filter. New filters
can be created using the mgmtRuleFilterRowStatus variable.
A row can only be created if it contains a value of
mgmtRuleIndex that already exists. Further, if a
mgmtRuleIndex is deleted from the mgmtRuleTable, all
associated entries shall be deleted from the
mgmtRuleFilterTable."
INDEX { mgmtRuleIndex, mgmtRuleFilterIndex }
::= { mgmtRuleFilterTable 1 }
MgmtRuleFilterEntry ::= SEQUENCE {
mgmtRuleFilterIndex Integer32,
mgmtRuleFilterType INTEGER,
mgmtRuleFilter DisplayString,
mgmtRuleFilterRowStatus RowStatus
}
mgmtRuleFilterIndex OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A unique index for this rule."
::= { mgmtRuleFilterEntry 1 }
mgmtRuleFilterType OBJECT-TYPE
SYNTAX INTEGER {
matchAddress(1),
matchDomainName(2),
matchSystemID(3)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"If this object has the value `matchAddress(1)', the ascii
representation (TBD) of each address in the mgmtSysAccessTable
will be evaluated against the regular expression in the
associated mgmtRuleFilter object. If the match succeeds, the
system associated with the mgmtSysAccessEntry matches this
filter.
If this object has the value `matchDomainName(2)', the domain
name of each address in the mgmtSysAccessTable
Disman Team Expires June, 1997 [Page 20]
Internet Draft Distributed Management Framework Dec 1996
will be evaluated against the regular expression in the
associated mgmtRuleFilter object. If the match succeeds, the
system associated with the mgmtSysAccessEntry matches this
filter.
If this object has the value `matchSystemID(1)', the ascii
representation (TBD) of each mgmtKnownSystemID
will be evaluated against the regular expression in the
associated mgmtRuleFilter object. If the match succeeds, the
system associated with the mgmtKnownSystemID matches this
filter."
::= { mgmtRuleFilterEntry 2 }
mgmtRuleFilter OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The value matched against systems for this filter."
::= { mgmtRuleFilterEntry 3 }
mgmtRuleFilterRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The control that allows creation/deletion of RuleFilter
entries."
::= { mgmtRuleFilterEntry 4 }
END
6. Acknowledgments
This document was produced by the IETF Distributed Network
Management Working Group.
7. References
[1] V. Cerf, IAB Recommendations for the Development of
Internet Network Management Standards. Internet Working
Group Request for Comments 1052. Network Information
Center, SRI International, Menlo Park, California,
Disman Team Expires June, 1997 [Page 21]
Internet Draft Distributed Management Framework Dec 1996
(April, 1988).
[2] V. Cerf, Report of the Second Ad Hoc Network Management
Review Group, Internet Working Group Request for Comments
1109. Network Information Center, SRI International,
Menlo Park, California, (August, 1989).
[3] M.T. Rose and K. McCloghrie, Structure and Identification
of Management Information for TCP/IP-based internets,
Internet Working Group Request for Comments 1155.
Network Information Center, SRI International, Menlo
Park, California, (May, 1990).
[4] K. McCloghrie and M.T. Rose, Management Information Base
for Network Management of TCP/IP-based internets: MIB-II,
Internet Working Group Request for Comments 1213 Network
Information Center, SRI International, Menlo Park,
California, (March, 1991).
[5] J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin,
Simple Network Management Protocol, Internet Working
Group Request for Comments 1157. Network Information
Center, SRI International, Menlo Park, California, (May,
1990).
[6] K. McCloghrie and F. Kastenholz, Evolution of the
Interfaces Group of MIB-II, Internet Working Group
Request for Comments 1573. Network Information Center,
SRI International, Menlo Park, California, (Jan, 1994).
[7] Information processing systems -- Open Systems
Interconnection -- Specification of Abstract Syntax
Notation One (ASN.1), International Organization for
Standardization. International Standard 8824, (December,
1987).
[8] Information processing systems -- Open Systems
Interconnection -- Specification of Basic Encoding Rules
for Abstract Notation One (ASN.1), International
Organization for Standardization. International Standard
8825, (December, 1987).
[9] M.T. Rose, K. McCloghrie, Editors, Concise MIB
Definitions, Internet Working Group Request for Comments
1212. Network Information Center, SRI International,
Disman Team Expires June, 1997 [Page 22]
Internet Draft Distributed Management Framework Dec 1996
Menlo Park, California, (March, 1991).
[10] M.T. Rose, Editor, A Convention for Defining Traps for
use with the SNMP, Internet Working Group Request for
Comments 1215. Network Information Center, SRI
International, Menlo Park, California, (March, 1991).
Disman Team Expires June, 1997 [Page 23]
Internet Draft Distributed Management Framework Dec 1996
Table of Contents
1 Status of this Memo ................................... 1
2 Abstract .............................................. 2
3 Overview .............................................. 3
4 The Network Management Framework ...................... 4
5 Distributed Management Framework ...................... 5
5.1 Known Systems ....................................... 6
5.2 Management Domains .................................. 6
5.3 Management Operations Targets ....................... 7
5.4 Delegation Control .................................. 7
5.5 Scheduling .......................................... 8
5.6 Reliable Notification ............................... 8
5.7 Notification Destinations ........................... 8
6 Acknowledgments ....................................... 21
7 References ............................................ 21
Disman Team Expires June, 1997 [Page 24]