Internet-Draft Schedule MIB December 1997 Definitions of Managed Objects for Scheduling Management Operations December 30, 1997 David B. Levi SNMP Research, Inc. levi@snmp.com Juergen Schoenwaelder TU Braunschweig schoenw@ibr.cs.tu-bs.de 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 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Copyright Notice Copyright (C) The Internet Society (1997). All Rights Reserved. Expires June 1998 [Page 1] Internet-Draft Schedule MIB December 1997 1. Abstract This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to schedule management operations periodically or at specified dates and times. This memo does not specify a standard for the Internet community. 2. The SNMPv2 Network Management Framework The SNMP Network Management Framework presently consists of three major components. They are: o the SMI, described in RFC 1902 [1] - the mechanisms used for describing and naming objects for the purpose of management. o the MIB-II, STD 17, RFC 1213 [2] - the core set of managed objects for the Internet suite of protocols. o the protocol, RFC 1157 [3] and/or RFC 1905 [4], - the protocol for accessing managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 2.1. Object Definitions Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI[1]. In particular, each object type is named by an OBJECT IDENTIFIER, an administratively assigned name. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the object descriptor, to refer to the object type. Expires June 1998 [Page 2] Internet-Draft Schedule MIB December 1997 3. Overview The MIB defined in this memo allows to schedule actions periodically or at specified dates and times. The actions can be used to realize on-duty / off-duty schedules or to trigger management functions in a DISMAN application. 3.1. Periodic Schedules Periodic schedules are based on fixed time periods between scheduled actions. A periodic schedule triggers the scheduled action at regular time intervals. Periodic schedules are therefore defined by specifying the number of seconds between two triggered actions. Schedules can be enabled or disabled by modifying a control object. This allows to have pre-configured schedules available that are activated or de-activated by some other management functions. 3.2. Calendar Schedules Calendar schedules trigger scheduled actions at specified dates and times. Calendar schedules are therefore aware of the notion of months, days, weekdays, hours and minutes. It is possible to specify multiple values for each calendar item. This allows to define a schedule which for example triggers the scheduled action every 15 minutes on a given weekday. 3.3. Actions Scheduled actions are modeled by SNMP set operations on local MIB objects. Scheduled actions described in this MIB are further restricted to objects of type INTEGER. This simplification allows to realize on-duty / off-duty schedules for resources that have a status MIB object (e.g. ifAdminStatus). More complex actions can be realized by triggering a management script which is responsible to perform complex state transitions. A management script can also be used to perform SNMP set operations on remote SNMP engines. Expires June 1998 [Page 3] Internet-Draft Schedule MIB December 1997 4. Definitions SCHEDULE-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, NOTIFICATION-TYPE, BITS, Integer32, Unsigned32, Counter32, experimental FROM SNMPv2-SMI TimeInterval, TimeStamp, RowStatus, StorageType, VariablePointer FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF Utf8String FROM SYSAPPL-MIB SnmpAdminString FROM SNMP-FRAMEWORK-MIB; schedMIB MODULE-IDENTITY LAST-UPDATED "9712300000Z" ORGANIZATION "IETF DISMAN Working Group" CONTACT-INFO "David B. Levi SNMP Research, Inc. 3001 Kimberlin Heights Road Knoxville, TN 37920-9716 U.S.A. Tel: +1 423 573 1434 E-mail: levi@snmp.com Juergen Schoenwaelder TU Braunschweig Expires June 1998 [Page 4] Internet-Draft Schedule MIB December 1997 Bueltenweg 74/75 38106 Braunschweig Germany Tel: +49-531-391-3283 E-mail: schoenw@ibr.cs.tu-bs.de" DESCRIPTION "This MIB module defines a MIB which provides mechanisms to schedule SNMP set operations periodically or at a specified point in time." -- Get real registration number from IANA. -- ::= { mib-2 XXXX } ::= { experimental 6789 } -- -- The various groups defined within this MIB definition: -- schedMIBObjects OBJECT IDENTIFIER ::= { schedMIB 1 } schedMibNotifications OBJECT IDENTIFIER ::= { schedMIB 2 } schedMIBConformance OBJECT IDENTIFIER ::= { schedMIB 3 } -- -- The schedule table which controls the scheduler. -- schedTable OBJECT-TYPE SYNTAX SEQUENCE OF SchedEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table defines actions that are to be scheduled based on a calendar." ::= { schedMIBObjects 2 } schedEntry OBJECT-TYPE SYNTAX SchedEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular scheduled action." INDEX { schedOwner, schedIndex } ::= { schedTable 1 } SchedEntry ::= SEQUENCE { schedOwner SnmpAdminString, schedIndex Unsigned32, schedDescr Utf8String, Expires June 1998 [Page 5] Internet-Draft Schedule MIB December 1997 schedInterval TimeInterval, schedWeekDay BITS, schedMonth BITS, schedDay BITS, schedHour BITS, schedMinute BITS, schedVariable VariablePointer, schedValue Integer32, schedAdminStatus INTEGER, schedOperStatus INTEGER, schedFailures Counter32, schedLastFailure INTEGER, schedLastFailed TimeStamp, schedStorageType StorageType, schedRowStatus RowStatus } schedOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The owner of this scheduling entry. The exact semantics of this string a subject to the security policy defined by the security administrator." ::= { schedEntry 1 } schedIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The locally arbitrary, but unique identifier associated with this scheduler entry." ::= { schedEntry 2 } schedDescr OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-create STATUS current DESCRIPTION "The human readable description of the purpose of this scheduling entry." ::= { schedEntry 3 } schedInterval OBJECT-TYPE SYNTAX TimeInterval Expires June 1998 [Page 6] Internet-Draft Schedule MIB December 1997 MAX-ACCESS read-create STATUS current DESCRIPTION "The number of seconds between two action invocations of a periodic scheduler. An implementation should try to ensure that the invocation of the action happens in the time interval specified by this object. A scheduled management function should however not rely on the accuracy provided by the scheduler implementation." ::= { schedEntry 4 } schedWeekDay OBJECT-TYPE SYNTAX BITS { sunday(0), monday(1), tuesday(2), wednesday(3), thursday(4), friday(5), saturday(6) } MAX-ACCESS read-create STATUS current DESCRIPTION "The set of weekdays the scheduled action should take place. The action is scheduled for every weekday if no bit is set." ::= { schedEntry 5 } schedMonth OBJECT-TYPE SYNTAX BITS { january(0), february(1), march(2), april(3), may(4), june(5), july(6), august(7), september(8), october(9), november(10), december(11) } MAX-ACCESS read-create STATUS current DESCRIPTION "The set of months the scheduled action should take place. The Expires June 1998 [Page 7] Internet-Draft Schedule MIB December 1997 action is scheduled for every month if no bit is set." ::= { schedEntry 6 } schedDay OBJECT-TYPE SYNTAX BITS { d0(0), d1(1), d2(2), d3(3), d4(4), d5(5), d6(6), d7(7), d8(8), d9(9), d10(10), d11(11), d12(12), d13(13), d14(14), d15(15), d16(16), d17(17), d18(18), d19(19), d20(20), d21(21), d22(22), d23(23), d24(24), d25(25), d26(26), d27(27), d28(28), d29(29), d30(30), d31(31) } MAX-ACCESS read-create STATUS current DESCRIPTION "The set of days in a month at which a scheduled action should take place. The first day of the month has the number d0(0). The action is scheduled for every day of a month if no bit is set." ::= { schedEntry 7 } schedHour OBJECT-TYPE SYNTAX BITS { h0(0), h1(1), h2(2), h3(3), h4(4), h5(5), h6(6), h7(7), h8(8), h9(9), h10(10), h11(11), h12(12), h13(13), h14(14), h15(15), h16(16), h17(17), h18(18), h19(19), h20(20), h21(21), h22(22), h23(23) } MAX-ACCESS read-create STATUS current DESCRIPTION "The set of hours within a day the scheduled action should take place. The action is scheduled for every hour of a day if no bit is set." ::= { schedEntry 8 } schedMinute OBJECT-TYPE SYNTAX BITS { m0(0), m1(1), m2(2), m3(3), m4(4), m5(5), m6(6), m7(7), m8(8), m9(9), m10(10), m11(11), m12(12), m13(13), m14(14), m15(15), m16(16), m17(17), m18(18), m19(19), m20(20), m21(21), m22(22), m23(23), m24(24), m25(25), m26(26), m27(27), m28(28), m29(29), m30(30), m31(31), m32(32), m33(33), m34(34), Expires June 1998 [Page 8] Internet-Draft Schedule MIB December 1997 m35(35), m36(36), m37(37), m38(38), m39(39), m40(40), m41(41), m42(42), m43(43), m44(44), m45(45), m46(46), m47(47), m48(48), m49(49), m50(50), m51(51), m52(52), m53(53), m54(54), m55(55), m56(56), m57(57), m58(58), m59(59) } MAX-ACCESS read-create STATUS current DESCRIPTION "The set of minutes within a day the scheduled action should take place.The action is scheduled for every minute within an hour if no bit is set." ::= { schedEntry 9 } schedVariable OBJECT-TYPE SYNTAX VariablePointer MAX-ACCESS read-create STATUS current DESCRIPTION "An object identifier pointing to a local MIB object. The object pointed to must be of syntax INTEGER." ::= { schedEntry 10 } schedValue OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The value which is written to the MIB object pointed to by schedVariable when the scheduler invokes an action. The implementation has to enforce that access control rules are used when performing the set operation on schedVariable." ::= { schedEntry 11 } schedAdminStatus OBJECT-TYPE SYNTAX INTEGER { periodic(1), calendar(2), disabled(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The desired state of the schedule. The periodic(1) state indicates this entry specifies a periodic schedule. The calendar(2) state indicates that this entry describes a Expires June 1998 [Page 9] Internet-Draft Schedule MIB December 1997 calendar schedule. The disabled(2) state indicates that this entry is currently inactive." ::= { schedEntry 12 } schedOperStatus OBJECT-TYPE SYNTAX INTEGER { periodic(1), calendar(2), disabled(3), enabling(4), disabling(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current operational state of this schedule. The periodic(1) state indicates that the periodic schedule is active and the calendar(2) state indicates that the calendar schedule is active. The disabled(3) state indicates that the schedule is currently not active. The enabling(4) state is used to indicate that the schedAdminStatus has been set to periodic(1) or calendar(2), but the scheduler implementation did not yet finish to activate the schedule. The disabling(5) state indicates that the schedAdminStatus object has been set to disabled(3) and the scheduler implementation did not yet finish to de-activate the active schedule." ::= { schedEntry 13 } schedFailures OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of failures while performing actions." ::= { schedEntry 14 } schedLastFailure OBJECT-TYPE SYNTAX INTEGER { noError(0), genErr(5), noAccess(6), wrongType(7), wrongLength(8), wrongValue(10), noCreation(11), inconsistentValue(12), Expires June 1998 [Page 10] Internet-Draft Schedule MIB December 1997 resourceUnavailable(13), commitFailed(14), undoFailed(15), authorizationError(16), notWritable(17), inconsistentName(18) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the most recent error that occured during a scheduled action. The value noError(0) is returned if no error happend so far. The failure codes have the meaning as defined in RFC 1905." ::= { schedEntry 15 } schedLastFailed OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the last failure occured. The value 0 is returned if the last failure occured before the last re-initialization of sysUpTime." ::= { schedEntry 16 } schedStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "This object defines whether this scheduled action is kept in volatile storage and lost upon reboot or if this row is backed up by non-volatile or permanent storage." ::= { schedEntry 17 } schedRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this scheduled action. A control that allows entries to be added and removed from this table." ::= { schedEntry 18 } -- -- Notifications that are emitted to indicate failures. Expires June 1998 [Page 11] Internet-Draft Schedule MIB December 1997 -- schedActionFailure NOTIFICATION-TYPE OBJECTS { schedLastFailure } STATUS current DESCRIPTION "This notification is generated whenever a scheduled action fails." ::= { schedMibNotifications 1 } -- conformance information schedCompliances OBJECT IDENTIFIER ::= { schedMIBConformance 1 } schedGroups OBJECT IDENTIFIER ::= { schedMIBConformance 2 } -- compliance statements schedCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which implement the scheduling MIB." MODULE -- this module MANDATORY-GROUPS { schedGroup } ::= { schedCompliances 1 } schedGroup OBJECT-GROUP OBJECTS { schedDescr, schedInterval, schedWeekDay, schedMonth, schedDay, schedHour, schedMinute, schedVariable, schedValue, schedAdminStatus, schedOperStatus, schedFailures, schedLastFailure, schedLastFailed, schedStorageType, schedRowStatus } Expires June 1998 [Page 12] Internet-Draft Schedule MIB December 1997 STATUS current DESCRIPTION "A collection of objects providing scheduling capabilities." ::= { schedGroups 1 } END 5. Security Considerations Scheduled SNMP set operations must use the security credentials that were present when the corresponding row in the scheduler was created. An implementation must therefore record and maintain the credentials for every schedule. An implementation must also ensure that access control rules are applied when doing the set operation. This MIB limits scheduled actions to objects in the local MIB. This avoids some security problems with delegated access rights. However, it might be possible that a user of this MIB owns some schedules that might trigger far in the future. This can cause security risks if the security administrator did not properly update the access control lists when a user is withdrawn from an SNMP engine. It is therefore suggested to cleanup entries in the schedTable whenever a user is withdrawn from an SNMP engine. The MIB is structured according to the guidelines defined in the DISMAN framework. These guidelines allow to define access control rules that separate multiple users of this MIB from each other. 6. Acknowledgments This document was produced by the IETF Distributed Management (DISMAN) working group. 7. Editor's Address David B. Levi Email: levi@snmp.com SNMP Research, Inc. Tel: +1 423 573 1434 3001 Kimberlin Heights Road Knoxville, TN 37920-9716 U.S.A. Expires June 1998 [Page 13] Internet-Draft Schedule MIB December 1997 Juergen Schoenwaelder Email: schoenw@ibr.cs.tu-bs.de TU Braunschweig Tel: +49 531 391-3283 Bueltenweg 74/75 38106 Braunschweig Germany 8. References [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC1902, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [2] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems, Performance Systems International, March 1991. [3] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC1905, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC1903, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [10] F. Yergeau, "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996. 9. Open Issues Expires June 1998 [Page 14] Internet-Draft Schedule MIB December 1997 o Do we need a resolution of minutes, or is a resolution of 5 minutes more appropriate? o Do we need to synchronize periodic schedules to a particular starting point? o Groups and conformance definitions are still incomplete. o Add conformance statements to allow implementations that don't use the calendar objects? 10. Full Copyright Statement Copyright (C) The Internet Society (1997). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. 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. Expires June 1998 [Page 15] Internet-Draft Schedule MIB December 1997 Table of Contents 1 Abstract ..................................................... 2 2 The SNMPv2 Network Management Framework ...................... 2 2.1 Object Definitions ......................................... 2 3 Overview ..................................................... 3 3.1 Periodic Schedules ......................................... 3 3.2 Calendar Schedules ......................................... 3 3.3 Actions .................................................... 3 4 Definitions .................................................. 4 5 Security Considerations ...................................... 13 6 Acknowledgments .............................................. 13 7 Editor's Address ............................................. 13 8 References ................................................... 14 9 Open Issues .................................................. 14 10 Full Copyright Statement .................................... 15 Expires June 1998 [Page 16]