One document matched: draft-ietf-manet-report-mib-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2021 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2021.xml">
<!ENTITY rfc2863 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2863.xml">
<!ENTITY rfc3418 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3418.xml">
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2578 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2578.xml">
<!ENTITY rfc2579 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2579.xml">
<!ENTITY rfc2580 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2580.xml">
<!ENTITY rfc3410 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3410.xml">
<!ENTITY rfc4001 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4001.xml">
]>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<rfc category="exp" docName="draft-ietf-manet-report-mib-02" ipr="trust200902">
<front>
<title abbrev="The REPORT-SAMPLED-MIB">Definition of Managed Objects for
Performance Reporting</title>
<author fullname="Robert G. Cole" initials="R.G." surname="Cole">
<organization>US Army CERDEC</organization>
<address>
<postal>
<street>6010 Frankford Road</street>
<city>Aberdeen Proving Ground</city>
<region>Maryland</region>
<code>21005</code>
<country>USA</country>
</postal>
<phone>+1 443 395 8744</phone>
<email>robert.g.cole@us.army.mil</email>
<uri>http://www.cs.jhu.edu/~rgcole/</uri>
</address>
</author>
<author fullname="Joseph Macker" initials="J.M." surname="Macker">
<organization>Naval Research Laboratory</organization>
<address>
<postal>
<street></street>
<city>Washington</city>
<region>D.C.</region>
<code>20375</code>
<country>USA</country>
</postal>
<email>macker@itd.nrl.navy.mil</email>
</address>
</author>
<author fullname="Andy Bierman" initials="A." surname="Bierman">
<organization>Brocade</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>andy.bierman@brocade.com</email>
</address>
</author>
<date />
<area>Operations and Management</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>Network Management</keyword>
<keyword>Management Information Base</keyword>
<keyword>MIB</keyword>
<keyword>SMIv2</keyword>
<keyword>Reporting</keyword>
<keyword>MANET</keyword>
<abstract>
<t>This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community. In
particular, it describes objects for configuring autonomous
report generation on any device that supports MIBs containing
counter and gauge objects for performance monitoring.
This allows a management station
to instruct a device to build off-line reports
to be collected asynchronously by
the management station. Further, this REPORT-SAMPLED-MIB can be configured in a
proxy configuration where the report generation is performed on a device
in close network proximity to the device containing the referenced counter
objects. Hence, this capability allows network operators to reduce
the SNMP polling traffic burden on Mobile Ad-Hoc and Disruption Tolerant
Networks which is typical of SNMP performance management applications.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community. In
particular, it describes objects for configuring autonomous, off-line report
generation for performance monitoring on any device supporting
MIBs containing variables that resolve to type Integer32
(i.e., Integer32, Counter, Gauge, or TimeTicks). This REPORT-SAMPLED-MIB
allows for the report generation to occur on the same device as containing the
referenced counter object or on a device in close network proximity
to the device with the referenced counter object.
This should be useful to devices or networks where efficient use
of bandwidth is of concern or where intermittent connectivity
is common. Hence, the REPORT-SAMPLED-MIB is useful for devices managed over
some Mobile Ad-Hoc Networks (MANETs) or Disruption Tolerant Networks (DTNs).</t>
<t>This version of the REPORT-SAMPLED-MIB offers one type of off-line reporting.
The MIB offers a means to collect sampled data related to defined
MIB objects. This type of reporting is contained in
the reportSampledGroup. Other types of report data are possible, including
statistical data and historical data. However, it was felt wise to
focus on a more limited scope off-line reporting capability and
gain experimental use and application prior to expending energy
developing a more extensive capability.</t>
<t>For the collection of sampled data, the REPORT-SAMPLED-MIB
draws directly from the usrHistoryGroup from RMON 2
<xref target="RFC2021"></xref> through application of the
'AUGMENTS' clause.
.
Here the reportSampledControlTable allows the user to
define aspects of the report for sampled data, including
the number of MIB objects to be sampled and the nature of the
sampling frequency and overall report duration. This
group uses the notion of buckets, which contain sampled data
from a set of identified MIB objects sampled at the same time point.
The report consists of the buckets,
each containing sets of sampled
data from the selected MIB objects but at
the specific sampling times.
The reportSampledObjectTable allows the user to identify
the multiple MIB objects to be sampled. The reportSampledDataTable
contains the storage of the reported sampled data contained within
buckets, one bucket for each time sampling instance.</t>
</section>
<section title="The Internet-Standard Management Framework">
<t>For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of RFC
3410 <xref target="RFC3410"></xref>.</t>
<t>Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP). Objects
in the MIB are defined using the mechanisms defined in the Structure of
Management Information (SMI). This memo specifies a MIB module that is
compliant to the SMIv2, which is described in STD 58, RFC 2578 <xref
target="RFC2578"></xref>, STD 58, RFC 2579 <xref
target="RFC2579"></xref> and STD 58, RFC 2580 <xref
target="RFC2580"></xref>.</t>
</section>
<section title="Conventions">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 <xref
target="RFC2119"></xref>.</t>
</section>
<section title="Overview">
<t>The REPORT-SAMPLED-MIB references performance objects in other MIBs
(and in other devices) and
generates off-line performance reports related to those referenced objects.
The REPORT-SAMPLED-MIB can be coincident with the other MIB or can reside
on another device in close network proximity to the device
containing the referenced performance related object.</t>
<section title="REPORT-SAMPLED-MIB Management Model">
<t>This section describes the management model for the
REPORT-SAMPLED-MIB process.
</t>
<t>Figure 1 illustrates a potential use of the REPORT-SAMPLED-MIB
for the generation of off-line, remotely generated reports.
The management station on the left hand side of the illustration
instructs the remote device to create reports through manipulation
of the ReportCntrl Objects in the REPORT-SAMPLED-MIB resident on the
remote device. The reports instruct the device to monitor the
status of specified counters (on other MIBs and potentially
on other devices in close network proximity) periodically.
The reports are stored locally
until the management station decides to pull them off the
device. The figure shows a case where the REPORT-SAMPLED-MIB generates
a notification that Report_2 has completed, prompting the management
station to pull Report_2 from the device.</t>
<figure>
<preamble />
<artwork><![CDATA[
Mgmt Device
Station
REPORT-SAMPLED-MIB MIB_1
+---------+ +-----+
| | | |
Build_Rep_1 |+-------+| +--+ |
+----------------->||cntrl_1||<------>|PC| |
|+-------+|<-+ +--+--+
| | |
| | | MIB_2
| | | +-----+
| | | |
| | | +--+ |
| | +---->|PC| |
Build_Rep_2 |+-------+| +-->+--+--+
+----------------->||cntrl_2||<---+
|+-------+|
| |
| |
Build_Rep_3 |+-------+|
+----------------->||cntrl_3||<---+ MIB_n
|+-------+| | +-----+
| | | | |
|+-----+ | | +--+ |
||Rep_1| | +-->|PC| |
|+-----+ | +--+--+
| |
|+-----+ |
<------------------||Rep_2| |
Notf_Rep_2 |+-----+ |
| |
|+-----+ |
||Rep_3| |
|+-----+ |
Get_Rep_2 | |
+----------------->| |
| |
<-----------------+| |
Send_Rep_2 +---------+
Figure 1: REPORT-SAMPLED-MIB front-end report generation process.
]]></artwork>
<postamble />
</figure>
<t>This version of the REPORT-SAMPLED-MIB provides for the collection of sampled data
instead of statistical data. It does this by augmenting
the usrHistory group from RMON2
<xref target="RFC2021"></xref> which allows for the
generation of reports collecting the sampled object values binned
for the purpose of aggregation and efficiency of collection.
These are defined within the reportSampledGroup. The model
used for this type of report generation is based upon three
tables. The reportSampledControlTable defines aspects of the
report generation related to duration of the reporting interval,
the bin (or bucket) sizes for the report, and the number of object
values collected for each bucket. The reportUsrHistoryObjectTable
identifies the specific MIB objects whose values are binned
within the report. And the reportSampledDataTable contains
the binned data values collected for the report.</t>
</section>
<section title="Terms">
<t>The following definitions apply throughout this document:</t>
<t><list style="symbols">
<t>Control - Objects defined within this document which set the
parameters for specific reports to be generated offline on the
the remote managed device.</t>
<t>Data - Objects which hold the sampled report data.</t>
</list></t>
</section>
</section>
<section title="Structure of the MIB Module">
<t>This section presents the structure of the REPORT-SAMPLED-MIB module. The
objects are arranged into the following groups:</t>
<t><list style="symbols">
<t>reportSampledMIBNotifications - defines the notifications associated with the
REPORT-SAMPLED-MIB.</t>
<t>reportSampledMIBObjects - defines the objects forming the basis for the
REPORT-SAMPLED-MIB. These objects are divided up by function into the following
groups (currently only one group is defined):</t>
<t><list style="symbols">
<t>Sampled Group - This group contains the objects which
support the generation (collection) of reports exposing
sampled data values.</t>
</list></t>
<t>reportSampledMIBConformance - Defines a variety of conformance of
implementations of this REPORT-SAMPLED-MIB.</t>
</list></t>
<section title="Textual Conventions">
<!--Generic and Common Textual Conventions
can be found summarized at
http://www.ops.ietf.org/mib-common-tcs.html-->
<t>No textual conventions are used in the REPORT-SAMPLED-MIB.</t>
</section>
<section title="The Sampled Group">
<t>The Sampled Group contains tables which allows for the development
of reports based upon sampling the referenced counter objects
at specified intervals. The development of this group within the
REPORT-SAMPLED-MIB which augments the User History group
from the RMON 2 MIB <xref target="RFC2021"></xref>.
The Sampled Group is composed of:</t>
<t><list style="symbols">
<t>reportSampledControlTable - allows for the setting of the parameters
of the report.</t>
<t>reportSampledObjectTable - sets the referenced objects to be sampled
during the test. With this capability, the management application
can reference multiple objects, all of which are sampled during the
test and reported out through the reportSampledData Table.</t>
<t>reportSampledDataTable - contains the reports.</t>
</list></t>
</section>
<section title="The Notifications Group">
<t>The Notifications Sub-tree contains the list of notifications
supported within the REPORT-SAMPLED-MIB and their intended purpose or utility.
The single notification defined within this MIB module is the
'reportSampledNewDataReport'. This notification is sent by the
agent upon completion of a given report on the device. The notification
contains the following objects:
'usrHistoryControlOwner', the entity that configured this report entry,
and the 'reportSampledReportIndex', the index of the data table
for this report. Collectively, these objects allow the management
application to pull the completed report from the agent.
</t>
</section>
</section>
<section title="Relationship to Other MIB Modules">
<t>The text of this section specifies the relationship of the
MIB modules contained in this document to other standards, particularly
to standards containing other MIB modules. Definitions imported from
other MIB modules and other MIB modules that SHOULD be implemented in
conjunction with the MIB module contained within this document are
identified in this section.</t>
<section title="Relationship to the SNMPv2-MIB">
<t>The 'system' group in the SNMPv2-MIB <xref target="RFC3418"></xref>
is defined as being mandatory for all systems, and the objects apply
to the entity as a whole. The 'system' group provides identification
of the management entity and certain other system-wide data. The
REPORT-SAMPLED-MIB does not duplicate those objects.</t>
</section>
<section title="Relationship to the RMON2-MIB">
<t>The REPORT-SAMPLED-MIB is closely related to the RMON2-MIB
<xref target="RFC2021"></xref> usrHistoryGroup.
Specifically, the reportSampledGroup is a direct copy of the RMON2
User History Group, with the names changed to comply with the
naming conventions within the REPORT-SAMPLED-MIB.
Further, the design and use of the control tables within the
REPORT-SAMPLED-MIB draw exactly from the definition of these table structures
in the earlier RMON MIBs through the use of the 'AUGMENTS' clause
within the 'reportSampledControlTable' and the
'reportSampledTable' in this MIB module.</t>
</section>
<section title="MIB modules required for IMPORTS">
<t>Citations are not permitted within a MIB module, but any
module mentioned in an IMPORTS clause or document mentioned in a
REFERENCE clause is a Normative reference, and must be cited someplace
within the narrative sections. Therefore, the imported items in this MIB
module, such as Textual Conventions, that are not already cited, are
cited in this section. Since relationships to other MIB modules
should be described in the narrative text, this section will
cite modules from which Textual Conventions are imported.</t>
<t>The REPORT-SAMPLED-MIB module IMPORTS objects from
SNMPv2-SMI <xref target="RFC2578"></xref>,
SNMPv2-TC <xref target="RFC2579"></xref>,
SNMPv2-CONF <xref target="RFC2580"></xref>,
IF-MIB <xref target="RFC2863"></xref>, and
INET-ADDRESS-MIB <xref target="RFC4001"></xref>.
Significantly, the REPORT-SAMPLED-MIB module also IMPORTS objects
from the RMON2-MIB module <xref target="RFC2021"></xref>.</t>
</section>
</section>
<!-- Definitions section -->
<!-- This section contains the MIB module(s) defined by the specification.
These MIB modules MUST be written in SMIv2 [RFC2578] [RFC2579]
[RFC2580].
See Section 4 of RFC 4181 for guidelines on SMIv2 usage.
See Appendix C of RFC 4181 for suggested naming conventions
A list of tools that can help automate the process of
checking mib definitions can be found at
http://www.ops.ietf.org/mib-review-tools.html
-->
<section title="Definitions">
<t></t>
<figure>
<artwork><![CDATA[
REPORT-SAMPLED-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
Gauge32, Integer32, experimental
FROM SNMPv2-SMI -- [RFC2578]
TimeStamp
FROM SNMPv2-TC -- [RFC2579]
MODULE-COMPLIANCE, OBJECT-GROUP,
NOTIFICATION-GROUP
FROM SNMPv2-CONF -- [RFC2580]
usrHistoryControlEntry, usrHistoryObjectEntry,
usrHistoryControlIndex, usrHistoryControlOwner,
usrHistoryObjectIndex
-- usrHistoryControlObjects, usrHistoryControlBucketsRequested,
-- usrHistoryControlBucketsGranted, usrHistoryControlInterval,
-- usrHistoryControlStatus,
-- usrHistoryObjectVariable, usrHistoryObjectSampleType
FROM RMON2-MIB -- [RFC2021]
InetAddress, InetAddressType
FROM INET-ADDRESS-MIB -- [RFC4001]
;
reportSampledMIB MODULE-IDENTITY
LAST-UPDATED "201201311300Z" -- January 31, 2012
ORGANIZATION "IETF MANET Working Group"
CONTACT-INFO
"WG E-Mail: manet@ietf.org
WG Chairs: ian.chakeres@gmail.com
jmacker@nrl.navy.mil
Editors: Robert G. Cole
US Army CERDEC
6010 Frankford Road
Aberdeen Proving Ground, MD 21005
USA
+1 443 395-8744
robert.g.cole@us.army.mil
Joseph Macker
Naval Research Laboratory
Washington, D.C. 20375
USA
macker@itd.nrl.navy.mil
Andy Bierman
Brocade
andy.bierman@brocade.com"
DESCRIPTION
"This MIB module contains managed object definitions for
the autonmous reporting of performance object counters.
Copyright (C) The IETF Trust (2009). This version
of this MIB module is part of RFC xxxx; see the RFC
itself for full legal notices."
-- Revision History
REVISION "201201311300Z" -- January 31, 2012
DESCRIPTION
"The sixth draft of this MIB module published as
draft-ietf-manet-report-mib-02.txt.
Revisions to this draft include
a) Pulled the statistical and historical reporting
from the MIB module and left only the sampled
reporting, in order to greatly simplify the
first instance of this reporting MIB module.
b) Renamed the module, the REPORT-SAMPLED-MIB
module.
c) Leveraged the RMON2-MIB module more effectively
through the use of the AUGMENTS clause.
d) Changed the module to 'experimental'.
"
REVISION "201102171300Z" -- February 17, 2011
DESCRIPTION
"The fifth draft of this MIB module published as
draft-ietf-manet-report-mib-01.txt. This document
has been promoted to a MANET Working Group
draft.
Revisions to this draft include
a) Proposed changes to the statsReport table to
simplify communications between device and
mgmt application,
b) Added Notifications,
c) Changed the reporting structure of the
Sampled and the History reporting
to align with the structure of the
Statistics reports for the purpose of
allowing for efficient notification and
collection of data reports.
d) Ran through smilint to clean up all errors
and most warning. A few still remain.
"
REVISION "201007051300Z" -- July 05, 2010
DESCRIPTION
"The fourth draft of this MIB module published as
draft-ietf-manet-report-mib-00.txt. This document
has been promoted to a MANET Working Group
draft.
Significant revisions to this draft include
a) added support for proxy configurations through
the addition of address objects associated with
the referenced counter objects associated with the
performance reports."
REVISION "201003021300Z" -- March 02, 2010
DESCRIPTION
"The third draft of this MIB module published as
draft-cole-manet-report-mib-02.txt. Significant
revisions to this draft include a) changed naming
of usrHistoryGroup to sampledGroup and b) added
a historyGroup."
REVISION "200910251300Z" -- October 25, 2009
DESCRIPTION
"The second draft of this MIB module published as
draft-cole-manet-report-mib-01.txt. Significant
revisions to this draft include a) the inclusion of
raw data collection borrow blatently from the
usrHistory Group within RMON2, b) the deletion of
the CurrentHistoryTable from version -00,
c) modifications to the overall structure of the
MIB, and d) the definition of various Compliance
options for implementations related to this MIB."
REVISION "200904281300Z" -- April 28, 2009
DESCRIPTION
"Initial draft of this MIB module published as
draft-cole-manet-report-mib-00.txt."
-- RFC-Editor assigns XXXX
::= { experimental 998 } -- to be assigned by IANA
-- TEXTUAL CONVENTIONs
-- None
--
-- Top-Level Object Identifier Assignments
--
reportSampledMIBNotifications OBJECT IDENTIFIER
::= { reportSampledMIB 0 }
reportSampledMIBObjects OBJECT IDENTIFIER
::= { reportSampledMIB 1 }
reportSampledMIBConformance OBJECT IDENTIFIER
::= { reportSampledMIB 2 }
reportSampledGroup OBJECT IDENTIFIER
::= { reportSampledMIBObjects 1 }
-- Then, the reportSampledGroup assignments are :
-- reportSampledControlTable - 1
-- reportSampledObjectTable - 2
-- reportSampledDataTable - 3
reportSampledControlTable OBJECT-TYPE
SYNTAX SEQUENCE OF SampledControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of data-collection configuration entries."
::= { reportSampledGroup 1 }
reportSampledControlEntry OBJECT-TYPE
SYNTAX SampledControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of parameters that set up a group of user-defined
MIB objects to be sampled periodically (called a
bucket-group).
For example, an instance of reportSampledControlInterval
might be named reportSampledControlInterval.1"
AUGMENTS { usrHistoryControlEntry }
::= { reportSampledControlTable 1 }
SampledControlEntry ::= SEQUENCE {
reportSampledControlRequestedNumber Integer32,
reportSampledControlReportNumber Integer32
}
reportSampledControlRequestedNumber OBJECT-TYPE
SYNTAX Integer32 (1..127)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The number of reports to be generated and stored by this
agent for this report request.
This object may not be modified if the associated
reportSampledControlStatus object is equal to active(1)."
DEFVAL { 1 }
::= { reportSampledControlEntry 1 }
reportSampledControlReportNumber OBJECT-TYPE
SYNTAX Integer32 (1..127)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of the current report in progress. The first
report is assigned a number equal to '1'. Each successive
report number is incremented by unity. When the last report
is completed, this value is set to
reportSampledControlRequestedNumber + 1."
::= { reportSampledControlEntry 2 }
-- Object table
reportSampledObjectTable OBJECT-TYPE
SYNTAX SEQUENCE OF SampledObjectEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of data-collection configuration entries."
::= { reportSampledGroup 2 }
reportSampledObjectEntry OBJECT-TYPE
SYNTAX SampledObjectEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of MIB instances to be sampled periodically.
Entries in this table are created when an associated
reportSampledControlObjects object is created.
The usrHistoryControlIndex value in the index is
that of the associated reportSampledControlEntry.
For example, an instance of reportSampledObjectVariable
might be reportSampledObjectVariable.1.3"
AUGMENTS { usrHistoryObjectEntry }
::= { reportSampledObjectTable 1 }
SampledObjectEntry ::= SEQUENCE {
reportSampledObjectIpAddrType InetAddressType,
reportSampledObjectIPAddress InetAddress
}
reportSampledObjectIpAddrType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This identifies the IP address type
of the IP address associated with the
secondary counter object to be
monitored within this report.
This object may not be modified if the associated
reportStatsControlStatus object is equal to active(1)."
::= { reportSampledObjectEntry 1 }
reportSampledObjectIPAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This identifies the IP addree of the
secondary counter object to be
monitored within this report.
This object may not be modified if the associated
reportStatsControlStatus object is equal to active(1)."
::= { reportSampledObjectEntry 2 }
-- data table
reportSampledTable OBJECT-TYPE
SYNTAX SEQUENCE OF SampledEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of user defined history entries."
::= { reportSampledGroup 3 }
reportSampledEntry OBJECT-TYPE
SYNTAX SampledEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A historical sample of user-defined variables. This sample
is associated with the reportSampledControlEntry which set
up the parameters for a regular collection of these samples.
The usrHistoryControlIndex value in the index identifies
the reportSampledControlEntry on whose behalf this entry
was created.
The usrHistoryObjectIndex value in the index identifies
the reportSampledObjectEntry on whose behalf this entry
was created.
For example, an instance of reportSampledAbsValue, which
represents the 14th sample of a variable collected as
specified by reportSampledControlEntry.1 and
reportSampledObjectEntry.1.5, would be named
reportSampledAbsValue.1.14.5"
INDEX { usrHistoryControlIndex, reportSampledReportIndex,
reportSampledSampleIndex, usrHistoryObjectIndex }
::= { reportSampledTable 1 }
SampledEntry ::= SEQUENCE {
reportSampledReportIndex Integer32,
reportSampledSampleIndex Integer32,
reportSampledIntervalStart TimeStamp,
reportSampledIntervalEnd TimeStamp,
reportSampledAbsValue Gauge32,
reportSampledValStatus INTEGER
}
reportSampledReportIndex OBJECT-TYPE
SYNTAX Integer32 (1..127)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An index that uniquely identifies the particular report
this entry is associated with among the set of reports
requested through the reportSampledControlNumber in the
reportSampledControlEntry. This index starts at 1 and
increases by one as each new report is generated."
::= { reportSampledEntry 1 }
reportSampledSampleIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An index that uniquely identifies the particular sample this
entry represents among all samples associated with the same
reportSampledControlEntry. This index starts at 1 and
increases by one as each new sample is taken."
::= { reportSampledEntry 2 }
reportSampledIntervalStart OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the start of the interval over
which this sample was measured. If the probe keeps track of
the time of day, it should start the first sample of the
history at a time such that when the next hour of the day
begins, a sample is started at that instant.
Note that following this rule may require the probe to delay
collecting the first sample of the history, as each sample
must be of the same interval. Also note that the sample which
is currently being collected is not accessible in this table
until the end of its interval."
::= { reportSampledEntry 3 }
reportSampledIntervalEnd OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the end of the interval over which
this sample was measured."
::= { reportSampledEntry 4 }
reportSampledAbsValue OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The absolute value (i.e. unsigned value) of the
user-specified statistic during the last sampling period. The
value during the current sampling period is not made available
until the period is completed.
To obtain the true value for this sampling interval, the
associated instance of reportSampledValStatus must
be checked, and reportSampledAbsValue adjusted as necessary.
If the MIB instance could not be accessed during the sampling
interval, then this object will have a value of zero and the
associated instance of reportSampledValStatus will be set to
'valueNotAvailable(1)'."
::= { reportSampledEntry 5 }
reportSampledValStatus OBJECT-TYPE
SYNTAX INTEGER {
valueNotAvailable(1),
valuePositive(2),
valueNegative(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the validity and sign of the data in
the associated instance of reportSampledAbsValue.
If the MIB instance could not be accessed during the sampling
interval, then 'valueNotAvailable(1)' will be returned.
If the sample is valid and actual value of the sample is
greater than or equal to zero then 'valuePositive(2)' is
returned.
If the sample is valid and the actual value of the sample is
less than zero, 'valueNegative(3)' will be returned. The
associated instance of reportSampledAbsValue should be
multiplied by -1 to obtain the true sample value."
::= { reportSampledEntry 6 }
--
-- Notifications
--
reportSampledNotificationObjects OBJECT IDENTIFIER
::= {reportSampledMIBNotifications 1}
-- reportSampledNotificationObjects
reportSampledNewDataReport NOTIFICATION-TYPE
OBJECTS { usrHistoryControlOwner, -- The entity that
-- configured this entry
reportSampledReportIndex -- The index of the
-- data table for this report
}
STATUS current
DESCRIPTION
"reportSampledNewDataReport is a notification sent
when a new report is completed from the
reportSampledControlTable. The notification carries
the index from the control table that established
this report and the index from the data table that
holds this report. Indication of the new report
is when the reportSampledControlReportNumber
is incremented."
::= { reportSampledNotificationObjects 1 }
--
-- Compliance Statements
--
-- Mandatory for Sampled will include all.
reportSampledCompliances OBJECT IDENTIFIER
::= { reportSampledMIBConformance 1 }
reportSampledMIBGroups OBJECT IDENTIFIER
::= { reportSampledMIBConformance 2 }
reportSampledCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION "The Sampled basic implementation requirements for
managed network entities that implement
the REPORT Sampled process."
MODULE -- this module
MANDATORY-GROUPS { reportSampledLocalGroup }
::= { reportSampledCompliances 1 }
reportSampledNotificationCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION "The Sampled Notification implementation
requirements for managed network entities
that implement the REPORT process."
MODULE -- this module
MANDATORY-GROUPS { reportSampledNotificationObjectGroup }
::= { reportSampledCompliances 2 }
-- Units of Conformance
reportSampledLocalGroup OBJECT-GROUP
OBJECTS {
reportSampledControlRequestedNumber,
reportSampledControlReportNumber,
reportSampledObjectIpAddrType,
reportSampledObjectIPAddress,
reportSampledReportIndex,
reportSampledIntervalStart,
reportSampledIntervalEnd,
reportSampledAbsValue,
reportSampledValStatus
}
STATUS current
DESCRIPTION
"Set of REPORT state objects implemented
in this module."
::= { reportSampledMIBGroups 1 }
--reportSampledImportedGroup OBJECT-GROUP
-- OBJECTS {
-- usrHistoryControlObjects,
-- usrHistoryControlBucketsRequested,
-- usrHistoryControlBucketsGranted,
-- usrHistoryControlInterval,
-- usrHistoryControlOwner,
-- usrHistoryControlStatus,
-- usrHistoryObjectVariable,
-- usrHistoryObjectSampleType
-- }
-- STATUS current
-- DESCRIPTION
-- "Set of REPORT state objects implemented
-- in this module."
--::= { reportSampledMIBGroups 2 }
reportSampledNotificationObjectGroup NOTIFICATION-GROUP
NOTIFICATIONS {
reportSampledNewDataReport
}
STATUS current
DESCRIPTION
"Set of REPORT notifications implemented
in this module for the Sampled reports."
::= { reportSampledMIBGroups 3 }
END
]]></artwork>
</figure>
</section>
<section title="Security Considerations">
<t>This REPORT-SAMPLED-MIB defines a capability where the local device
may poll other remote devices to collect performance data
accessible through other MIB modules on the remote devices.
These capabilities defined within the REPORT-SAMPLED-MIB are control-able
by a network management application through SNMP. As such,
a network management application could potentially use the REPORT-SAMPLED-MIB
as a mechanism to implement a Distributed Denial-of-Service (DDoS)
attack against remote devices. Care should be taken to secure access
to the REPORT-SAMPLED-MIB agent. Specifically, access control mechanisms
and authentication mechanisms (via SNMPv3) should always be used
for SNMP SET operations. Further, some objects may contain data
deemed sensitive and authentication and encryption mechanisms
(via SNMPv3) should be used for SNMP GET operations.
</t>
<t>There are a number of management objects defined in this MIB module
with a MAX-ACCESS clause of read-write and/or read-create. Such objects
may be considered sensitive or vulnerable in some network environments.
The support for SET operations in a non-secure environment without
proper protection can have a negative effect on network operations.</t>
<t>These are the tables and objects and their
sensitivity/vulnerability:</t>
<t><list style="symbols">
<t>The reportSampledControlTable is a writable table
whose columnar objects are read-create. The following
objects with MAX ACCESS of read-create and their security
sensitivities are:</t>
<t><list style="symbols">
<t>usrHistoryControlBucketRequested - this object identifies the
requested number of buckets (or intervals) requested for each
identified object for each report instance. As such, this related
to the total device memory necessary to hold the collected
data for the identified reports. The device must determine
whether it has the necessary storage. If not, the device can
indicate the available storage through the
usrHistoryControlBucketGranted object within this table.
The device to protect itself against memory overruns.</t>
<t>usrHistoryControlInterval - this object identifies the
time interval being sampling events. If set too low, the
device may not be able to sample the object on remote
devices fast enough to satisfy the requested interval. Further,
setting this value too low could be used to overwhelm
the processing capabilities of the remote agent, resulting
in a Denial-of-Service (DoS) attack.</t>
<t>reportSampledControlRequestedNumber - this object identifies
the requested number of consecutive reports of this type to
be generated and stored in this device. When, the value of this
object should be considered in the local device's estimates of
memory consumption related to this control table row.</t>
<t>usrHistoryControlOwner - this objects provides a name
associated with the presumed identity of the application
configuring this report. If the local device or management applications
attribute any authority to the values contained in this object, then
it is critical to secure access to setting or modifying the
value of this object.</t>
<t>usrHistoryControlStatus - this is the RowStatus object controlling
the configuration of this table row.</t>
</list></t>
<t>The reportSampledObjectTable is a writable table
whose columnar objects are read-create. The following
objects with MAX ACCESS of read-create and their security
sensitivities are:</t>
<t><list style="symbols">
<t>usrHistoryObjectVariable - this object identifies the specific
OID on a (potentially) remote agent whose counter or gauge
values are to be collected for the reports. If, for whatever
reason, the values of this OID collected within the report
is deemed sensitive, then the SNMP GET operations issued
to collect these values should use SNMPv3 authentication and
encryption mechanisms to protect.</t>
<t>reportSampledObjectIpAddrType - this object identifies the
address type associated with the address of the agent whose
OID data is being collected for the report.</t>
<t>reportSampledObjectIpAddress - this object identifies the
address associated with the address of the agent whose
OID data is being collected for the report. If the address
of the remote devices is deemed sensitive, then the SNMP SETs
which write or the SNMP GET which collect this information
should be protected using SNMPv3 authentication and encryption
mechanisms.</t>
<t>usrHistoryObjectSampleType - this object identifies the
the way in which data values are to be stored within the
reports.</t>
</list></t>
</list></t>
<t>SNMP versions prior to SNMPv3 did not include adequate security. Even
if the network itself is secure (for example by using IPSec), even then,
there is no control as to who on the secure network is allowed to access
and GET/SET (read/change/create/delete) the objects in this MIB
module.</t>
<t>It is RECOMMENDED that implementers consider the security features as
provided by the SNMPv3 framework (see <xref target="RFC3410"></xref>,
section 8), including full support for the SNMPv3 cryptographic
mechanisms (for authentication and privacy).</t>
<t>Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable
cryptographic security. It is then a customer/operator responsibility to
ensure that the SNMP entity giving access to an instance of this MIB
module is properly configured to give access to the objects only to
those principals (users) that have legitimate rights to indeed GET or
SET (change/create/delete) them.</t>
</section>
<section title="IANA Considerations">
<figure>
<preamble></preamble>
<artwork><![CDATA[
The MIB module in this document uses the following IANA-assigned
OBJECT IDENTIFIER values recorded in the SMI Numbers registry:
Descriptor OBJECT IDENTIFIER value
---------- -----------------------
reportSampledMIB { experimental XXX }
]]></artwork>
<postamble></postamble>
</figure>
<t></t>
</section>
<!-- The Author's Addresses section will be generated
automatically by XML2RFC from the front information -->
<section title="Contributors">
<t>This MIB document uses the template authored by D. Harrington which
is based on contributions from the MIB Doctors, especially Juergen
Schoenwaelder, Dave Perkins, C.M.Heard and Randy Presuhn.</t>
<t><!--[TODO] Change this section to mention contributors to your
MIB module document.--></t>
</section>
<section title="Acknowledgements">
<t>We would like to thank Bert Wijnen for
pointing out the existence of the usrHistory group within
RMON2 and in answering our numerous
questions on the usrHistory group. Further, we wish to
thank U. Herberg for promoting additions to this MIB through
his thoughtful consideration of performance monitoring
requirements for other MIBs within the MANET WG, e.g.,
NHDP and OLSR MIBs.</t>
</section>
</middle>
<back>
<!-- References Section -->
<!-- Section 4.7f of [RFC2223bis] specifies the requirements for the
references sections. In particular, there MUST be separate lists of
normative and informative references, each in a separate section.
The style SHOULD follow that of recently published RFCs.
The standard MIB boilerplate available at
http://www.ops.ietf.org/mib-boilerplate.html includes lists of
normative and informative references that MUST appear in all IETF
specifications that contain MIB modules. If items from other MIB
modules appear in an IMPORTS statement in the Definitions section,
then the specifications containing those MIB modules MUST be included
in the list of normative references. When items are imported from an
IANA-maintained MIB module the corresponding normative reference
SHALL point to the on-line version of that MIB module. It is the
policy of the RFC Editor that all references must be cited in the
text; such citations MUST appear in the overview section where
documents containing imported definitions (other those already
mentioned in the MIB boilerplate) are required to be mentioned (cf.
Section 3.2).
In general, each normative reference SHOULD point to the most recent
version of the specification in question.
-->
<references title="Normative References">
&rfc2863;
&rfc3418;
&rfc2119;
&rfc2578;
&rfc2579;
&rfc2580;
&rfc4001;
</references>
<references title="Informative References">
<!-- <t>[TODO] RFC3410 is required to support the boilerplate text.</t>-->
&rfc3410;
&rfc2021;
</references>
<!--
<section anchor="appendix" title="Appendix A">
<t>You can add appendices just as regular sections, the only
difference is that they go under "back" element, and get letters
instead of numbers</t>
</section>
-->
<section title="Change Log ">
<t>Changes from draft-ietf-manet-report-mib-01 to
draft-ietf-manet-report-mib-02 draft.</t>
<t><list style="numbers">
<t>Stripped the Statistical and the Historical
Reports from this draft in order to greatly
simplify the initial development and experiments
of this MIB module.</t>
<t>Changed the RFC category to Experimental.</t>
<t>Completed the Security section. </t>
<t>Relied upon the AUGMENTS statement to simplify
further this MIB definition.</t>
</list></t>
<t>Changes from draft-ietf-manet-report-mib-00 to
draft-ietf-manet-report-mib-01 draft.</t>
<t><list style="numbers">
<t>Proposed additions to the statsReports in order
to potentially simplify data transmission to
management applications.</t>
<t>Added some Notification definitions
and their relationship to the three reports'
structure, i.e., statsReports, sampledReports,
and historyReports.</t>
<t>In the process of adding notifications for the
Sampled and the History reports, decided to restructure
the reports from their previously rolling storage
model to the fixed interval reporting used all along
in the Statistics reporting. This allows the agent to
notify the management application that a report has
completed and that it is ready to be pulled from the
agent storage.</t>
<t>Ran MIB through smilint checker and cleaned up
all errors and most warnings. A few warnings remain
to be addressed.</t>
<t>Cleaned up textual material.</t>
</list></t>
<t>Changes from draft-cole-manet-report-mib-02 to
draft-ietf-manet-report-mib-00 draft.</t>
<t><list style="numbers">
<t>Major change was the incorporation of the
IP address objects associated with all objects
of type 'OBJECT IDENTIFIER'. This allows the
REPORT-SAMPLED-MIB to exist as a proxy report generation
capability on a device separate but in close
proximity to the device monitoring the
referenced object.</t>
<t>Cleaned up the up front text, reducing the
repetition with the object descriptions in the
MIB.</t>
<t>Worked on and added sections discussing the
relationship to other MIBs.</t>
</list></t>
<t>Changes from draft-cole-manet-report-mib-01 to
draft-cole-manet-report-mib-02 draft.</t>
<t><list style="numbers">
<t>Restructured the MIB somewhat to now offer the three
reporting capabilities in increasing order of detail:
a) statistical reports, b) sampled reports, and
c) historical reports.</t>
<t>Renamed the usrHistoryGroup and elements to
samplingGroup. This is in line with its actual capabilities.</t>
<t>Added a new historyGroup which provides a history of change events.</t>
<t>Updated the4 Conformance section to reflect the above changes and
additions. But did not yet run smilint to check MIB syntax.</t>
</list></t>
<t>Changes from draft-cole-manet-report-mib-00 to
draft-cole-manet-report-mib-01 draft.</t>
<t><list style="numbers">
<t>Added (copied) the usrHistory group from RMON2 into the REPORT-SAMPLED-MIB.</t>
<t>Restructured the MIB to account for the inclusion of the
reportSampledGroup.</t>
<t>Dropped the reportCurReportsTable as this did not make sense within the
context of the REPORT-SAMPLED-MIB.</t>
<t>Added the Compliance and Conformance material. Defined several Compliance
Groups to all for base implementations of the REPORT-SAMPLED-MIB for only statistical
reports, for only historical reports or for both. Allow for enhanced
implementations to address higher capacity issues and
extension to metric reporting for statistical reporting.</t>
<t>Ran the MIB through the smilint checker and in the process corrected numerous
typos, omissions, TEXTUAL CONVENTIONS, IMPORTS, etc.</t>
<t>Updated main text to reflect changes.</t>
</list></t>
</section>
<section title="Open Issues">
<t>This section contains the set of open issues related to the
development and design of the REPORT-SAMPLED-MIB. This section will not be present
in the final version of the MIB and will be removed once all the open
issues have been resolved.</t>
<t><list style="numbers">
<t>Identify all objects requiring non-volatile storage in their
DESCRIPTION clauses.</t>
</list></t>
</section>
<section title="">
<figure>
<preamble />
<artwork><![CDATA[
***************************************************************
* Note to the RFC Editor (to be removed prior to publication) *
* *
* 1) The reference to RFCXXXX within the DESCRIPTION clauses *
* of the MIB module point to this draft and are to be *
* assigned by the RFC Editor. *
* *
* 2) The reference to RFCXXX2 throughout this document point *
* to the current draft-ietf-manet-report-xx.txt. This *
* need to be replaced with the XXX RFC number. *
* *
***************************************************************
]]></artwork>
<postamble></postamble>
</figure>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:52:23 |