]> US Army CERDEC

6010 Frankford Road Aberdeen Proving Ground Maryland 21005 USA +1 443 395 8744 robert.g.cole@us.army.mil

Naval Research Laboratory

Washington D.C. 20375 USA macker@itd.nrl.navy.mil

YumaWorks, Inc.

Redwood City CA 94065 andy@yumaworks.com

Operations and Management Internet Engineering Task Force Network Management Management Information Base MIB SMIv2 Reporting MANET 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 objects that resolve to type Integer32 (i.e., Integer32, Counter, Gauge, or TimeTicks). to be used for performance monitoring. This allows a management station to instruct a device to build off-line reports to be collected either through notifications to the management station or queried asynchronously by the management station. Hence, this capability allows network operators to reduce the SNMP polling traffic burden on Mobile Ad-Hoc and Disruption Tolerant Networks which is problematic of SNMP performance management applications.

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 reportSampledMIB module allows for the report generation to occur on the same device as containing 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 reportSampledMIB module is useful for devices managed over some Mobile Ad-Hoc Networks (MANETs) or Disruption Tolerant Networks (DTNs). This version of the reportSampledMIB module offers one type of off-line reporting. The MIB offers a means to collect sampled measurements related to defined MIB objects. This type of reporting is contained in the reportSampledMibObjects. Other types of report data are possible, including statistical 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 off line reporting capability. The reportSampledMIB module relies upon the dismanEventMIB module RFC 2981 to monitor the progress of reports being developed within the reportSampledMIB module and to trigger an events, i.e., notifications containing reports, at the appropriate times. This is discussed below in more detail in the section entitled 'Relationship to the DISMAN-EVENT-MIB'. Further, more sophisticated performance objects for monitoring from the reportSampledMIB module can be defined through the dismanExpressionMIB module RFC 2982

For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 . 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 , STD 58, RFC 2579 and STD 58, RFC 2580 .

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 .

The reportSampledMIB module references performance objects in other MIBs and generates off-line performance reports related to those referenced objects. The reportSampledMIB module can be coincident with the other MIB modules on the same device containing the referenced performance related object.

This section describes the management model for the reportSampledMIB module process. The reportSampledMIB module objects are primarily contained within four tables. These are: reportSampledControlTable - this is the control table within the reportSampledMIB module. This identifies the OIDs to be monitored which define the core of the Reports. The control table sets the sampling frequency for the Measurements and the number of Measurements that will define each Report. reportSampledCurrentReportsStatusTable - This table tracks the status, i.e., the current number of collected Measurements per each Study. This information can be used by the dismanEventMIB module to determine when to trigger a notification to the Report owner containing the Measurements and associated data comprising the just completed Report. reportSampledCurrentReportsTable - This table holds the Measurements for the Reports which are in current development. reportSampledHistoricalReportsTable - This table holds the completed Reports for each Study for archival purposes, i.e., the Study owners can perform table walks to retrieve archived Reports or Studies. The below figure illustrates the four main tables within the reportSampledMIB module. Further, if the dismanEventMIB module is so configured to generate triggered notifications, the below figure highlights the 'boolean trigger' and the notification generation. The figure further illustrates the movement of completed Reports from the reportSampledCurrentReportsTable to the reportSampledHistoricalReportsTable upon Report Completion.

----+ +---------------------------------------------------+ | (boolean +---------------------------------------------------+ trigger)->--+ | reportSampledCurrentReportsStatusEntry | | | | { reportSampledStudyStudyIndex } | | | | | | | | | | | | reportSampledNumberOfMeasurementsForCurrentReport--->---+ | +---------------------------------------------------+ | V +---------------------------------------------------+ | | reportSampledCurrentReportsEntry | | | { reportSampledStudyStudyIndex, |---->--------+ | reportSampledCurrentMeasurementIndex } | | | |-->---+ | +---------------------------------------------------+ | | (move) | +---------------------------------------------------+ | | | reportSampledHistoricalReportsEntry | | | | { reportSampledStudyStudyIndex, | | | | reportSampledHistoricalReportIndex, |<--+ | | reportSampledHistoricalMeasurementIndex } | | | | | +---------------------------------------------------+ | V (notifications) ]]>

The following definitions apply throughout this document: Sampled - periodic measurement of target OIDs. Measurement - a single instance of a sampling event. Report - a collection of consecutive Measurements on the same Sampled target OID. Study - a series of Reports on the same Sampled target OID. Current Report - a Report which is in the process of being developed. A Completed Report - contains a pre-defined number of Sampled Measurements. Historical Report - a Report which has previously Completed, and is being stored locally for archival purposes.

This section presents the structure of the reportSampledMIB module. The objects are arranged into the following groups: reportSampledMibNotifications - defines the notifications associated with the reportSampledMIB module. These objects define notifications which track the behavior of the reportSampledMib module. A single notification is defined in the reportSampledMIB module which reports a series of failed measurement attempts in the process of building a Report. Associated with this notification is a control object which defines a threshold of failures which would initiate the notification. These notifications do not cover the triggered notifications which carry the performance Reports generated by the reportSampledMib module. These triggered notifications are defined through the use of the dismanEventMIB module. reportSampledMibObjects - defines the objects forming the basis for the reportSampledMIB module. These objects are basically divided up by function into the following four tables: reportSampledControlTable - This group contains the objects which support the generation (collection) of Studies comprising of Reports exposing sampled Measurement values. reportSampledCurrentReportsStatusTable - This group contains the objects which track the collection of Measurements for current (in-progress) Reports. This table allows the dismanEventMIB module to set triggers for Completed Reports which it can then send to the report owner through triggered notifications. reportSampledCurrentReportsTable - This group contains the objects which represent the Measurement data associated with Current (in-progress) Reports. Once the Report completes, it is moved to the reportSampledHistoricalReportsTable for archival purposes. reportSampledHistoricalReportsTable - This group contains the objects which represent archived Completed Reports. This allows the report owners to asynchronously retrieve Reports via table walks if so desired. reportSampledMibConformance - Defines a single basic conformance of implementations of this reportSampledMIB module.

No textual conventions are defined in the reportSampledMIB module.

The reportSampledMIB module contains four tables which control and record data related to the creation, notification and storage of Reports. Specifically: the control and generation of remote performance Reports, i.e., reportSampledControlTable the status of the Current Reports' development, i.e., reportSampledCurrentReportsStatusTable, the Current Reports development and interim data, i.e., reportSampledCurrentReportsTable, and the historical storage of remote performance Reports, i.e. reportSampledHistoricalReportsTable. The reportSampledMIB module's tables are indexed via the following constructs: reportSampledStudyIndex - an index that uniquely identifies a particular Study. The Study is comprised of multiple Reports, the number of Reports being stored is defined by the reportSampledStudyMaximumNumberOfHistoricalReports object. reportSampledCurrentMeasurementIndex - an index that uniquely identifies an atomic Measurement associated with a Report. reportSampledHistoricalReportIndex - an index that uniquely identifies an archived Completed Report resident within the reportSampledHistoricalReportsTable. reportSampledHistoricalMeasurementIndex - an index that uniquely identifies an atomic Measurement comprising an archived Completed Report. These tables and their indexing are: reportSampledControlTable - this table contains a list of data-collection configuration entries defining aspects of the studies and their reports to be generated. These include, e.g., number of reports per study, the number Reports to be archived, etc. This table has 'INDEX { reportSampledStudyIndex }'. reportSampledCurrentReportsStatusTable - this table contains objects which track the development of current Reports, e.g., the number of current Measurements collected for each Report under development. This table has 'INDEX { reportSampledStudyIndex }'. For each (active) Study, there exists only one Current Report under development. reportSampledCurrentReportsTable - this table contains the Measurements which are developing the Current Reports. This table has 'INDEX { reportSampledStudyIndex, reportSampledCurrentMeasurementIndex }'. reportSampledHistoricalReportsTable - this table contains the Reports which have completed. This table has 'INDEX { reportSampledStudyIndex, reportSampledHistoricalReportIndex, reportSampledHistoricalMeasurementIndex }'.

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.

The 'system' group in the SNMPv2-MIB 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 reportSampledMIB module does not duplicate those objects.

The reportSampledMIB module is closely related to and was inspired by the the RMON2-MIB module usrHistoryGroup. The use of control tables to establish the periodic collection of measurement data for creation of performance reports was pulled from earlier work on the RMON2-MIB module.

The reportSampledMIB module was developed to fundamentally work with the dismanEventMIB module RFC 2981 in order to offer a complete and efficient off-line reporting capability for bandwidth challenged networks such as Mobile Ad-Hoc Networks (MANETs). This is accomplished through defining trigger test and associated notification actions indexed by mteOwner, mteTriggerName, mteObjectsName and mteEventName within the dismanEventMIB module. Specifically (within the dismanEventMIB module): In the mteTriggerTable and specifically by setting 'mteTriggerTest == boolean(1)', 'mteTriggerSampleType == absoluteValue(1)', 'mteTriggerValueID == reportSampledNumberOfMeasurementsForCurrentReport', 'mteTriggerValueIDWildcard == false(1)', 'mteTriggerFrequency == 0.5*reportSampledStudySamplingInterval', and 'mteTriggerEnabled == true'. In the mteTriggerBooleanTable and specifically by setting 'mteTriggerBooleanComparison == equal(2)', 'mteTriggerBooleanValue == value of reportSampledStudyNumberReportMeasurements', and 'mteTriggerBooleanStartup == false'. In the mteObjectsTable and specifically by setting 'mteObjectsID == reportSampledCurrentMeasurementValue' and reportSampledCurrentMeasurementTime' and reportSampledCurrentMeasurementStatus' with 'mteObjectsIDWildcard == true' // for each. In the mteEventTable and specifically by setting 'mteEventActions == notification(0)' and 'mteEventEnabled == true' // for each. In the mteEventNotificationTable and specifically by setting 'mteEventNotification == mteTriggerFired' and the appropriate names for the 'mteEventNotificationObjectOwner == mteOwner' and 'mteEventNotificationObjects == mteObjectsName'. These settings within the dismanEventMIB module will result in notifications generated by the dismanEventMIB module which will carry the recently completed reportSampledMIB module reports. Set up properly, the dismanEventMIB module will trigger a notification each time the reportSampledCurrentTable contains a completed Report. This Report will be sent in a notification containing three columns of the reportSampledCurrentTable, i.e., the Value, the Time and the Status, due to the use of wildcarding within the dismanEventMIB module. Simultaneously, the reportSampledMIB module will move the completed Current Report into the reportSampledHistoricalReportsTable and restart collection for the next Report within the reportSampledCurrentReportsTable.

In conjunction with the dismanExpressionMIB module RFC 2982 , the reportSampledMIB module can be used to develop reports on relatively sophisticated object expressions.

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. The reportSampledMIB module IMPORTS objects from SNMPv2-SMI , SNMPv2-TC , SNMPv2-CONF , SNMP-FRAMEWORK-MIB , and SNMPv2-MIB .

This reportSampledMIB module defines a capability where the local device may poll other MIB modules on the device to collect performance data. These capabilities defined within the reportSampledMIB module are control-able by a network management application through SNMP. As such, a network management application could potentially use the reportSampledMIB module as a mechanism to implement a limited Distributed Denial-of-Service (DDoS) attack against remote devices by overloading their SNMP processing. Care should be taken to secure access to the reportSampledMIB module 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. 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. These are the tables and objects and their sensitivity/vulnerability: 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: reportSampledStudyOwner - this object is an administrative string which identifies the the owner of the Study. reportSampledStudyName - this object is an administrative string which gives a name to the Study defined by the objects in this table. reportSampledStudyOid - this object identifies the the Object ID from another MIB module resident on this local device which forms the measurement basis for the Study. Depending upon the object and the associated process responsible for its maintenance, polling this object too frequently may place an undo burden on the process resulting in diminishing its overall ability to perform its operation. reportSampledStudySamplingInterval - 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 form of Denial-of-Service (DoS) attack. reportSampledStudyNumberReportsMeasurements - this object identifies the requested number of measurements (and associated storage/memory) for each identified object for each Study 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 reject this value when requested by returning the .... to protect itself against memory overruns. reportSampledStudyMaximumNumberOfHistoricalReports - this object identifies the requested number of Reports for each identified object for each Study 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 reject this value when requested by returning the .... to protect itself against memory overruns. reportSampledStudyEntryStatus - this is the RowStatus object controlling the configuration of this table row. The reportSampledCurrentReportsStatusTable is a read-only table containing state information. The information in this Table relates to performance measurements on the underlying Mobile Ad-Hoc Network (MANET). As such, some of this information may be deemed sensitive to the overall performance of the MANET and to the organization to which the MANET belongs. The reportSampledCurrentReportsTable is a read-only table containing state information. The information in this Table relates to performance measurements on the underlying Mobile Ad-Hoc Network (MANET). As such, some of this information may be deemed sensitive to the overall performance of the MANET and to the organization to which the MANET belongs. The reportSampledHistoricalReportsStatusTable is a read-only table containing state information. The information in this Table relates to performance measurements on the underlying Mobile Ad-Hoc Network (MANET). As such, some of this information may be deemed sensitive to the overall performance of the MANET and to the organization to which the MANET belongs. The reportSampledDataCollectionFailure notification object reports information regarding the inability of the reportSampledMIB module from completing its configured reporting mission, including the specific information that the module is failing to collect. To some organizations this information may be deemed sensitive to its mission and may want to protect this information through encryption mechanisms. The reportSampledDataCollectionFailureThreshold object controls the ability of the device to report information regarding the inability of the reportSampledMIB module from completing its configured reporting mission. If set to low, notifications may be produced too frequently causing processor burdens to the agent and the collecting manager, and generating too much management traffic for a bandwidth constrained MANET to support. If set too high, notifications may not be produced frequently enough for the collecting manager to properly track the MANET system performance. 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. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see , section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). 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.

This document describes objects for configuring parameters of the remote report generation process on a router or other device. This MIB module, denoted reportSampledMIB module, also reports performance information and notifications. The reportSampledMIB module provides for the remote control, collection and notification of performance reports on devices. As such, it eliminates the need for periodic polling for counters from remote management stations as a means for generating performance reports. This is hoped to greatly reduce management overhead on the MANET. This sections provides some examples of how this MIB module can be used in MANET network deployments. A fuller discussion of MANET network management use cases and challenges will be provided elsewhere. In the following, two scenarios are identified where this MIB module is useful. This list is not complete and other scenarios are possible. For Mobile vehicles with Low Bandwidth Satellite Link to a Fixed Network Operations Center (NOC) - Here the vehicles carrying the MANET routers carry multiple wireless interfaces, one of which is a relatively low-bandwidth on-the-move satellite connection which interconnects a fix NOC to the nodes of the MANET. Standards-based methods for monitoring and fault management from the fixed NOC are necessary for this deployment option. However, to reduce polling overhead over the low bandwidth communications links, the reportSampledMIB module can be deployed the remote MANET nodes for the remote generation of performance reports. For Fixed NOC and Mobile Local Manager in Larger Vehicles - for larger vehicles, a hierarchical network management arrangement is useful. Centralized network management is performed from a fixed NOC while local management, as provided by this reportSampledMIB module is performed locally from within the vehicles. Standards-based methods for configuration, monitoring, fault and performance management are necessary for this deployment option.

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.

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.

&rfc2021; &rfc2119; &rfc2578; &rfc2579; &rfc2580; &rfc2981; &rfc2982; &rfc3411; &rfc3418; &rfc3410;

Changes from draft-ietf-manet-report-mib-03 to draft-ietf-manet-report-mib-04 draft. This version 04 of the reportSampledMIB module represents a fairly significant restructuring of the MIB module. This restructuring was necessary in order to align the remote distributed reporting capabilities of this MIB module with the prior DISMAN Working Group (WG) efforts at the IETF. The reportSampledCurrentReportsStatusTable was added to allow a network manager to automate notifications of completed reports from this MIB module using the dismanEventMIB module. The notifications in this reportSampledMIB module were reduced to only notifications related to the operation of the data collections and no longer addressing the reporting of the performance data itself. This later data is now carried in notifications under the control of the dismanEventMIB module. Changes from draft-ietf-manet-report-mib-01 to draft-ietf-manet-report-mib-02 draft. Stripped the Statistical and the Historical Reports from this draft in order to greatly simplify the initial development and experiments of this MIB module. Changed the RFC category to Experimental. Completed the Security section. Relied upon the AUGMENTS statement to simplify further this MIB definition. Changes from draft-ietf-manet-report-mib-00 to draft-ietf-manet-report-mib-01 draft. Proposed additions to the statsReports in order to potentially simplify data transmission to management applications. Added some Notification definitions and their relationship to the three reports' structure, i.e., statsReports, sampledReports, and historyReports. 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. Ran MIB through smilint checker and cleaned up all errors and most warnings. A few warnings remain to be addressed. Cleaned up textual material. Changes from draft-cole-manet-report-mib-02 to draft-ietf-manet-report-mib-00 draft. Major change was the incorporation of the IP address objects associated with all objects of type 'OBJECT IDENTIFIER'. This allows the reportSampledMIB module to exist as a proxy report generation capability on a device separate but in close proximity to the device monitoring the referenced object. Cleaned up the up front text, reducing the repetition with the object descriptions in the MIB. Worked on and added sections discussing the relationship to other MIBs. Changes from draft-cole-manet-report-mib-01 to draft-cole-manet-report-mib-02 draft. 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. Renamed the usrHistoryGroup and elements to samplingGroup. This is in line with its actual capabilities. Added a new historyGroup which provides a history of change events. Updated the4 Conformance section to reflect the above changes and additions. But did not yet run smilint to check MIB syntax. Changes from draft-cole-manet-report-mib-00 to draft-cole-manet-report-mib-01 draft. Added (copied) the usrHistory group from RMON2 into the reportSampledMIB module. Restructured the MIB to account for the inclusion of the reportSampledMibObjects. Dropped the reportCurReportsTable as this did not make sense within the context of the reportSampledMIB module. Added the Compliance and Conformance material. Defined several Compliance Groups to all for base implementations of the reportSampledMIB module 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. Ran the MIB through the smilint checker and in the process corrected numerous typos, omissions, TEXTUAL CONVENTIONS, IMPORTS, etc. Updated main text to reflect changes.

This section contains the set of open issues related to the development and design of the reportSampledMIB module. 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. Provide references within the REFERENCE clauses in the MIB module. Identify all objects requiring non-volatile storage in their DESCRIPTION clauses. Request an initial review of this MIB module by a MIB Doctor familiar with the work of the DISMAN WG, preferably an author of the dismanEventMIB module.