Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals
Standard conventions for tracking device performance in regular intervals.
Tesink, K., Ed., "Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals", RFC 2493, DOI 10.17487/RFC2493, January 1999, <https://www.rfc-editor.org/info/rfc2493>.
@misc{rfc2493,
series = {Request for Comments},
number = 2493,
howpublished = {RFC 2493},
publisher = {RFC Editor},
doi = {10.17487/RFC2493},
url = {https://www.rfc-editor.org/info/rfc2493},
author = {K. Tesink},
title = {{Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals}},
pagetotal = 9,
year = 1999,
month = jan,
} RFC text
Contents
Network Working Group K. Tesink, Editor
Request for Comments: 2493 Bellcore
Category: Standards Track January 1999
Textual Conventions for MIB Modules Using Performance History
Based on 15 Minute Intervals
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
This document defines a set of Textual Conventions for MIB modules
which make use of performance history data based on 15 minute
intervals.
1. Table of Contents
1 Table of Contents ..................................... 1
2 Introduction .......................................... 1
3 Note on Invalid Data and Proxy ........................ 2
4 Note on xyzTimeElapsed ................................ 3
5 Note on xyzValidIntervals ............................. 3
6 Definitions ........................................... 3
7 Acknowledgments ....................................... 7
8 References ............................................ 7
9 Security Considerations ............................... 8
10 IANA Considerations .................................. 8
11 Author's Address ..................................... 8
12 Intellectual Property ................................ 8
13 Full Copyright Statement ............................. 9
2. Introduction
In cases where a manager must obtain performance history data about
the behavior of equipment it manages several strategies can be
followed in the design of a MIB that represents the managed
equipment, including:
0 The agent counts events on a continuous basis and,
whenever desired, the manager obtains the value of the event
counter and adjusts its understanding of the history of events
at the agent.
0 The agent allocates events to 'buckets' where each bucket
represents an interval of time.
Telecommunications equipment often makes use of the latter strategy.
See [3][4][5] for examples. In particular, for this equipment it is
common that history data is maintained by the agent in terms of
fifteen minute intervals.
This memo does not attempt to compare the relative merits of
different strategies to obtain history data. Differences may include
polling policy, the amount of management traffic between manager and
agent, agent simplicity, and 'data currentness' of the data obtained
by the manager. MIB designers should consider these aspects when
choosing a particular strategy in a MIB design. Instead, this memo
provides definitions that can be used in MIB modules that require
history data based on fifteen minute intervals.
When designing a MIB module, it is often useful to define new types
similar to those defined in the SMI [2]. In comparison to a type
defined in the SMI, each of these new types has a different name, a
similar syntax, but a more precise semantics. These newly defined
types are termed textual conventions, and are used for the
convenience of humans reading the MIB module. This is done through
Textual Conventions as defined in RFC1903[1]. It is the purpose of
this document to define the set of textual conventions to be used
when performance history based on 15 minute intervals is kept. See
for example the Trunk MIB modules [3][4][5].
3. Note on Invalid Data and Proxy
In this document, the word proxy is meant to indicate an application
which receives SNMP messages and replies to them on behalf of the
devices where the actual implementation resides, e.g., DS3/E3
interfaces. The proxy will have already collected the information
about the DS3/E3 interfaces into its local database and may not
necessarily forward requests to the actual DS3/E3 interface. It is
expected in such an application that there are periods of time where
the proxy is not communicating with the DS3/E3 interfaces. In these
instances the proxy will not necessarily have up-to-date
configuration information and will most likely have missed the
collection of some data. Missed data collection may result in some
intervals in the interval table being unavailable.
4. Note on xyzTimeElapsed
While xyzTimeElapsed is defined as having a maximum there may be
cases (e.g., an adjustment in the system's time-of-day clock) where
the actual value of the current interval would exceed this maximum
value.
Suppose that an agent which aligns its 15-minute measurement
intervals to 15-minute time-of-day ("wall clock") boundaries has a
time-of-day clock that systematically gains time, and that a manager
periodically corrects the clock by setting it back.
It is assumed that the agent's time-of-day clock is reasonably
accurate, say within a few seconds per day. Thus, the manager's
periodic clock adjustments will normally be small, and if done
frequently enough, need not ever exceed 10 seconds. In this case all
interval durations will be within the allowed tolerance and none need
be marked invalid, _if_ the ANSI procedure of ending measurement
intervals at 15-minute time-of-day boundaries is followed [6].
If the time-of-day clock is systematically adjusted in small
increments, then always ending measurement intervals at 15-minute
time-of-day boundaries will result in the long term in the correct
number of intervals with the correct average duration, irrespective
of whether the clock is moved ahead or moved back. Thus, if, for
some reason, such as an adjustment in the system's time-of-day clock,
the current interval exceeds the maximum value, it is considered
acceptable that the agent will return the maximum value.
5. Note on xyzValidIntervals
The overall constraint on <n> is 1 =< n =< 96. Any additional
constraints on n must be defined in the DESCRIPTION clause (e.g., see
[5]).
6. Definitions
PerfHist-TC-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY,
Gauge32, mib-2
FROM SNMPv2-SMI
TEXTUAL-CONVENTION
FROM SNMPv2-TC;
perfHistTCMIB MODULE-IDENTITY
LAST-UPDATED "9811071100Z"
ORGANIZATION "IETF AToMMIB and TrunkMIB WGs"
CONTACT-INFO
"Kaj Tesink
Postal: Bellcore
331 Newman Springs Road
Red Bank, NJ 07701
USA
Tel: +1 732 758 5254
Fax: +1 732 758 2269
E-mail: kaj@bellcore.com"
DESCRIPTION
"This MIB Module provides Textual Conventions
to be used by systems supporting 15 minute
based performance history counts."
::= { mib-2 58 }
-- The Textual Conventions defined below are organized
-- alphabetically
-- Use of these TCs assumes the following:
-- 0 The agent supports 15 minute based history
-- counters.
-- 0 The agent is capable of keeping a history of n
-- intervals of 15 minute performance data. The
-- value of n is defined by the specific MIB
-- module but shall be 0 < n =< 96.
-- 0 The agent may optionally support performance
-- data aggregating the history intervals.
-- 0 The agent will keep separate tables for the
-- current interval, the history intervals, and
-- the total aggregates.
-- 0 The agent will keep the following objects.
-- If performance data is kept for multiple instances
-- of a measured entity, then
-- these objects are applied to each instance of
-- the measured entity (e.g., interfaces).
--
-- xyzTimeElapsed OBJECT-TYPE
-- SYNTAX INTEGER (0..899)
-- MAX-ACCESS read-only
-- STATUS current
-- DESCRIPTION
-- "The number of seconds that have elapsed since
-- the beginning of the current measurement period.
-- If, for some reason, such as an adjustment in the
-- system's time-of-day clock, the current interval
-- exceeds the maximum value, the agent will return
-- the maximum value."
-- ::= { xxx }
-- xyzValidIntervals OBJECT-TYPE
-- SYNTAX INTEGER (0..<n>)
-- MAX-ACCESS read-only
-- STATUS current
-- DESCRIPTION
-- "The number of previous near end intervals
-- for which data was collected.
-- [ The overall constraint on <n> is 1 =< n =< 96; ]
-- [ Define any additional constraints on <n> here. ]
-- The value will be <n> unless the measurement was
-- (re-)started within the last (<n>*15) minutes, in which
-- case the value will be the number of complete 15
-- minute intervals for which the agent has at least
-- some data. In certain cases (e.g., in the case
-- where the agent is a proxy) it is possible that some
-- intervals are unavailable. In this case, this
-- interval is the maximum interval number for
-- which data is available."
-- ::= { xxx }
-- xyzInvalidIntervals OBJECT-TYPE
-- SYNTAX INTEGER (0..<n>)
-- MAX-ACCESS read-only
-- STATUS current
-- DESCRIPTION
-- "The number of intervals in the range from
-- 0 to xyzValidIntervals for which no
-- data is available. This object will typically
-- be zero except in cases where the data for some
-- intervals are not available (e.g., in proxy
-- situations)."
-- ::= { xxx }
PerfCurrentCount ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A counter associated with a
performance measurement in a current 15
minute measurement interval. The value
of this counter starts from zero and is
increased when associated events occur,
until the end of the 15 minute interval.
At that time the value of the counter is
stored in the first 15 minute history
interval, and the CurrentCount is
restarted at zero. In the
case where the agent has no valid data
available for the current interval the
corresponding object instance is not
available and upon a retrieval request
a corresponding error message shall be
returned to indicate that this instance
does not exist (for example, a noSuchName
error for SNMPv1 and a noSuchInstance for
SNMPv2 GET operation)."
SYNTAX Gauge32
PerfIntervalCount ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A counter associated with a
performance measurement in a previous
15 minute measurement interval. In the
case where the agent has no valid data
available for a particular interval the
corresponding object instance is not
available and upon a retrieval request
a corresponding error message shall be
returned to indicate that this instance
does not exist (for example, a noSuchName
error for SNMPv1 and a noSuchInstance for
SNMPv2 GET operation).
In a system supporting
a history of n intervals with
IntervalCount(1) and IntervalCount(n) the
most and least recent intervals
respectively, the following applies at
the end of a 15 minute interval:
- discard the value of IntervalCount(n)
- the value of IntervalCount(i) becomes that
of IntervalCount(i-1) for n >= i > 1
- the value of IntervalCount(1) becomes that
of CurrentCount
- the TotalCount, if supported, is adjusted."
SYNTAX Gauge32
PerfTotalCount ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A counter associated with a
performance measurements aggregating the
previous valid 15 minute measurement
intervals. (Intervals for which no valid
data was available are not counted)"
SYNTAX Gauge32
END
7. Acknowledgments
This document is a product of the AToMMIB and TrunkMIB Working
Groups.
8. References
[1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"Textual Conventions for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1903, January 1996.
[2] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"Structure of Management Information for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1902, January 1996.
[3] Fowler, D., "Definitions of Managed Objects for the DS1, E1, DS2
and E2 Interface Types", RFC 2495, January 1999.
[4] Fowler, D., "Definitions of Managed Objects for the DS3/E3
Interface Type", RFC 2496, January 1999.
[5] Tesink, K., "Definitions of Managed Objects for the SONET/SDH
Interface Type", Work in Progress.
[6] American National Standard for Telecommunications - Digital
Hierarchy - Layer 1 In-Service Digital Transmission Performance
Monitoring, ANSI T1.231-1997, September 1997.
9. Security Considerations
This memo defines textual conventions for use in other MIB modules.
Security issues for these MIB modules are addressed in the memos
defining those modules.
10. IANA Considerations
Prior to publication of this memo as an RFC, IANA is requested to
make a suitable OBJECT IDENTIFIER assignment.
11. Author's Address
Kaj Tesink
Bellcore
331 Newman Springs Road
P.O. Box 7020
Red Bank, NJ 07701-7020
Phone: (732) 758-5254
EMail: kaj@bellcore.com
12. Intellectual Property
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
13. Full Copyright Statement
Copyright (C) The Internet Society (1999). 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.
AI ELI5
On this page
§1Introduction
RFC 2493 defines a set of textual conventions for MIB modules that need to record performance history using 15-minute intervals. In network management, performance history is commonly tracked in two ways: an agent can count events continuously and the manager can calculate history, or the agent can bucket events into fixed time periods.
Telecommunications equipment often uses the bucket method with 15-minute intervals. This RFC provides standard definitions that any MIB module can reuse instead of defining its own. These textual conventions make MIB modules easier to write and read by providing standardized, named types with clear semantics.
Different network boxes all keep track of what happened every 15 minutes. Instead of each one making up its own numbers and names, this says what everybody should call them and what they mean.
§2The Three Performance Counters
The RFC defines three textual conventions for performance measurement counters:
PerfCurrentCount tracks a measurement during the current 15-minute interval. It starts at zero and increments as events occur. When the interval ends, this value is stored in history and the counter resets.
PerfIntervalCount stores measurements from completed 15-minute intervals. A system keeps a history of n intervals (where 1 ≤ n ≤ 96). When a new interval completes, the oldest interval is discarded and all others shift back one position, with the current count becoming the most recent history entry.
PerfTotalCount aggregates measurements across all previous valid intervals, providing a sum of completed interval counts. This is optional but useful for getting cumulative statistics.
The current counter keeps track right now. The history counters keep track of the past few hours. The total counter adds everything up for you.
§3Design Assumptions
The RFC assumes that an agent supporting these conventions will:
- Maintain a 15-minute based history with n intervals of data (n can be 1 to 96)
- Keep separate tables for the current interval, historical intervals, and total aggregates
- Handle cases where valid data is unavailable (for example, when a proxy manager loses connection to the actual device)
- Provide related objects to track elapsed time in the current interval and the number of valid historical intervals available
These assumptions let managers query performance data in a standard way across different types of equipment without needing to understand device-specific implementations.
Every device keeps maybe the last 96 fifteen-minute scores, plus a running total. If the device can't talk to the real thing, it marks those scores as missing.
§4Notes on Time and Interval Counting
The xyzTimeElapsed counter tracks seconds into the current 15-minute interval (maximum 899 seconds). If the agent's time-of-day clock adjusts, this value may occasionally exceed the maximum, in which case the agent returns the maximum value.
The xyzValidIntervals counter tracks how many historical intervals contain valid data, constrained by the total number n. When the system first starts or when the agent cannot reach the actual device, this count may be less than n.
The xyzInvalidIntervals counter records the number of intervals within the valid range that have no data available, typically seen in proxy situations where communication is temporarily lost.
If the device's clock gets bumped by a second or two, we just cap the current counter at its max. If some past 15-minute chunks are missing, we remember which ones.