]> US Army CERDEC

6010 Frankford Road Aberdeen Proving Ground Maryland 21005 USA +1 443 395 8744 robert.g.cole@us.army.mil http://www.cs.jhu.edu/~rgcole/

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 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.

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). 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. For the collection of sampled data, the REPORT-SAMPLED-MIB draws directly from the usrHistoryGroup from RMON 2 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.

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 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.

This section describes the management model for the REPORT-SAMPLED-MIB process. 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.

||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. ]]>

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 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.

The following definitions apply throughout this document: Control - Objects defined within this document which set the parameters for specific reports to be generated offline on the the remote managed device. Data - Objects which hold the sampled report data.

This section presents the structure of the REPORT-SAMPLED-MIB module. The objects are arranged into the following groups: reportSampledMIBNotifications - defines the notifications associated with the REPORT-SAMPLED-MIB. 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): Sampled Group - This group contains the objects which support the generation (collection) of reports exposing sampled data values. reportSampledMIBConformance - Defines a variety of conformance of implementations of this REPORT-SAMPLED-MIB.

No textual conventions are used in the REPORT-SAMPLED-MIB.

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 . The Sampled Group is composed of: reportSampledControlTable - allows for the setting of the parameters of the report. 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. reportSampledDataTable - contains the reports.

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.

The REPORT-SAMPLED-MIB module contains a number of tables which record data related to: the control and generation of remote performance reports, the storage of remote performance reports, and the notification of remote report completion. The REPORT-SAMPLED-MIB module's tables are indexed via the following constructs: usrHistoryControlIndex - from the RMON2-MIB , an index that uniquely identifies an entry in the usrHistoryControlTable. Each such entry defines a set of samples at a particular interval for a specified set of MIB instances available from the managed system. usrHistoryObjectIndex - from the RMON2-MIB, an index used to uniquely identify an entry in the usrHistoryObject table from the RMON2-MIB. Each such entry defines a MIB instance to be collected periodically. reportSampledReportIndex - an index that uniquely identifies the particular report an entry is associated with among the set of reports requested through the reportSampledControlNumber in the reportSampledControlEntry. reportSampledSampleIndex - an index that uniquely identifies the particular sample this entry represents among all samples associated with the same reportSampledControlEntry. These tables and their indexing are: reportSampledControlTable - this table contains a list of data-collection configuration entries defining aspects of the reports. These include, e.g., number of reports, their start and stop times, etc. This table 'AUGMENTS { usrHistoryControlEntry }'. reportSampledObjectTable - this table contains a list of data-collection configuration entries which identify specific MIB entries on other devices to monitor. This table 'AUGMENTS { usrHistoryObjectEntry }'. reportSampledTable - this table contains a list of historical samples collected for the report. This table has 'INDEX { usrHistoryControlIndex, reportSampledReportIndex, reportSampledSampleIndex, usrHistoryObjectIndex }'.

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 REPORT-SAMPLED-MIB does not duplicate those objects.

The REPORT-SAMPLED-MIB is closely related to the RMON2-MIB 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.

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 REPORT-SAMPLED-MIB module IMPORTS objects from SNMPv2-SMI , SNMPv2-TC , SNMPv2-CONF , IF-MIB , and INET-ADDRESS-MIB . Significantly, the REPORT-SAMPLED-MIB module also IMPORTS objects from the RMON2-MIB module .

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. 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: 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. 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. 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. 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. usrHistoryControlStatus - this is the RowStatus object controlling the configuration of this table row. 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: 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. reportSampledObjectIpAddrType - this object identifies the address type associated with the address of the agent whose OID data is being collected for the report. 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. usrHistoryObjectSampleType - this object identifies the the way in which data values are to be stored within the reports. 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 close device. This MIB module, denoted REPORT-SAMPLED-MIB, also reports performance information and notifications. The REPORT-SAMPLED-MIB 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 listed where this MIB module is useful, i.e., For Mobile vehicles with Low Bandwidth Satellite Link to a Fixed 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 REPORT-SAMPLED-MIB 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 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; &rfc2863; &rfc3418; &rfc2119; &rfc2578; &rfc2579; &rfc2580; &rfc4001; &rfc3410;

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 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. 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 REPORT-SAMPLED-MIB. Restructured the MIB to account for the inclusion of the reportSampledGroup. Dropped the reportCurReportsTable as this did not make sense within the context of the REPORT-SAMPLED-MIB. 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. 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 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. Identify all objects requiring non-volatile storage in their DESCRIPTION clauses.