Internet-Draft Schedule MIB December 1997
Definitions of Managed Objects for
Scheduling Management Operations
December 30, 1997
<draft-ietf-disman-schedule-mib-00.txt>
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]
