Internet Draft Distributed Management Framework Dec 1997 Distributed Management Framework December 15, 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, 1998 [Page 1] Internet Draft Distributed Management Framework Dec 1997 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, 1998 [Page 2] Internet Draft Distributed Management Framework Dec 1997 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 to reduce bottlenecks in the management system. Therefore, a distributed systems approach is often helpful when building large management systems. A distributed approach is often very effective at reducing load on the central management station, and may be effective at reducing the load that the central management station places on backbone networks. However, a distributed approach usually has no benefit in reducing load on remote networks and has no benefit in reducing load on management agents. Further, in a distributed data collection architecture, if all data collected is eventually forwarded to the central management station (without aggregation or compression), then no benefit in backbone load or central management station load should be expected (except perhaps to time- shift this load to a time of excess capacity, at the expense of a lack of timeliness of data. 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 Disman Team Expires June, 1998 [Page 3] Internet Draft Distributed Management Framework Dec 1997 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 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. This also enables a multi-vendor approach to building management systems. 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 Disman Team Expires June, 1998 [Page 4] Internet Draft Distributed Management Framework Dec 1997 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. 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, Disman Team Expires June, 1998 [Page 5] Internet Draft Distributed Management Framework Dec 1997 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 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. Disman Team Expires June, 1998 [Page 6] Internet Draft Distributed Management Framework Dec 1997 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, 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. Credential Delegation The Credential Delegation Service allows credentials of a network management user to be delegated to a distributed management application so that it can perform secure Disman Team Expires June, 1998 [Page 7] Internet Draft Distributed Management Framework Dec 1997 operations on behalf of that user. Fundamental to this distributed management architecture is the notion that distributed management operations must not run with the credentials of the distributed manager. To do so would require that the authorization of these credentials (or subsets of this authorization) would need to be apportioned to users of that distributed manager in a pre-defined and secure way. This would require the creation of a access control architecture mirroring the SNMP View-Based Access Control architecture that would control what subsets of authority are available to what users. The existing View-Based Access Control mechanism was not designed for this task and is not appropriate. Further, it would require that the distributed manager be configured in a way that was consistent with the access control policy embodied in the managed systems. This would be extremely problematic because: 1. This would require a massive amount of configuration to be replicated on the distribute manager 2. If any part of this configuration on the distribute manager is inconsistent with that on the managed systems, a security hole could be exposed. Because it is assumed that the distributed manager adds no credentials to management operations, when a manager wishes to configure a distributed manager to perform secure transactions on its behalf, it must download to the distributed manager the appropriate credentials to be placed in secure SNMP messages, identifying them as the manager. A credential contains at least the securityModel, securityName, securityLevel, authentication and privacy keys, and an indication of which management targets the credential should be used for. 5.4.1. Definitions ----------- --------------- -------------- | | | | | | | Manager |---------->| Distributed |------------->| Management | | | Disman | Manager | Target | Target | | | User | | User | | | | | | Identity | | | | | | | | ----------- --------------- -------------- Disman Team Expires June, 1998 [Page 8] Internet Draft Distributed Management Framework Dec 1997 1. Disman User - The user whose credentials are used to configure the distribute manager for an operation and to download credentials for that operation. There is no relationship implied between the disman user and the user(s) who's credentials are installed (in other words, "joe" can install credentials for "ops-center-east" as well as "joe"). 2. Target User Identity - The user identity used in SNMP messages between the distributed manager and management targets. 3. Credential - The set of secrets that are transferred to the distributed manager giving it the authority to act as an identity. 4. Owner - The disman user who sets up a distributed management function, including the credentials for the function. 5. Invoker - The user who invokes a previously setup distributed management function. The owner may choose to allow others to invoke a function, potentially allowing that function to operate with the owner's credentials (of course the owner would want to tightly constrain what the function was configured to perform). 6. Invokation Identity - The identity of the credentials a function is operating with. These may be of the owner, of the invoker, or possibly the union of both credentials. Because multiple Disman Users will have access to a Distributed Manager, the Credential Delegation Service will be responsible for ensuring that credentials are only used by authorized users. The Credential Delegation Service will include: 1. Credential Store - a MIB in which to transfer and store credentials 2. MIB prototype - a prototype MIB fragment that will be added to disman functions that wish to use the Credential Disman Team Expires June, 1998 [Page 9] Internet Draft Distributed Management Framework Dec 1997 Store 3. Access Control Policy - a policy for configuration of the VACM MIB for use with the Credential Delegation Service. This will limit access to the credential store. 5.5. 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. 5.6. 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.7. 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 Disman Team Expires June, 1998 [Page 10] Internet Draft Distributed Management Framework Dec 1997 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.8. 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, 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" Disman Team Expires June, 1998 [Page 11] Internet Draft Distributed Management Framework Dec 1997 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, 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), Disman Team Expires June, 1998 [Page 12] Internet Draft Distributed Management Framework Dec 1997 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." ::= { 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) Disman Team Expires June, 1998 [Page 13] Internet Draft Distributed Management Framework Dec 1997 } 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 } 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 Disman Team Expires June, 1998 [Page 14] Internet Draft Distributed Management Framework Dec 1997 -- 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 -- 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 -- Disman Team Expires June, 1998 [Page 15] Internet Draft Distributed Management Framework Dec 1997 -- 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 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, Disman Team Expires June, 1998 [Page 16] Internet Draft Distributed Management Framework Dec 1997 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 "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 Disman Team Expires June, 1998 [Page 17] Internet Draft Distributed Management Framework Dec 1997 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 } -- -- 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 Disman Team Expires June, 1998 [Page 18] Internet Draft Distributed Management Framework Dec 1997 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 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 } Disman Team Expires June, 1998 [Page 19] Internet Draft Distributed Management Framework Dec 1997 ::= { 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 -- 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 Disman Team Expires June, 1998 [Page 20] Internet Draft Distributed Management Framework Dec 1997 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 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 Disman Team Expires June, 1998 [Page 21] Internet Draft Distributed Management Framework Dec 1997 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 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, Disman Team Expires June, 1998 [Page 22] Internet Draft Distributed Management Framework Dec 1997 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 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 Disman Team Expires June, 1998 [Page 23] Internet Draft Distributed Management Framework Dec 1997 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, (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). Disman Team Expires June, 1998 [Page 24] Internet Draft Distributed Management Framework Dec 1997 [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, 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, 1998 [Page 25] Internet Draft Distributed Management Framework Dec 1997 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 .................................. 7 5.3 Management Operations Targets ....................... 7 5.4 Credential Delegation ............................... 7 5.4.1 Definitions ....................................... 8 5.5 Delegation Control .................................. 10 5.6 Scheduling .......................................... 10 5.7 Reliable Notification ............................... 10 5.8 Notification Destinations ........................... 11 6 Acknowledgments ....................................... 24 7 References ............................................ 24 Disman Team Expires June, 1998 [Page 26]