Network Working Group E. Stephan Internet Draft France Telecom R&D Document: draft-stephan-ippm-mib-02.txt February 01, 2002 Category: Informational IPPM measurement MIB Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1] except that the right to produce derivative works is not granted. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, It defines a registry of the IPPM working group metrics and specifies the objects used for managing IPPM metrics measures, for pushing alarms and for reporting the measures results. Table of Contents 1. Introduction................................................2 2. The IPPM Framework..........................................3 3. The SNMP Management Framework...............................3 4. Overview....................................................4 4.1. Textual Conventions.........................................5 4.2. Structure of MIB............................................7 4.3. Row addition in an application namespace....................9 4.4. Control of Remote Measurement Devices......................10 4.5. Resource Sharing Among Multiple Management Stations........10 Stephan Informational - Expires August 2002 [Page 1] Internet Draft IPPM MIB February 2002 4.6. Row Addition Among Multiple Management Stations............11 5. IPPM-MIB metrics registry..................................11 5.1. registry framework.........................................11 5.2. IPPM RFC...................................................11 5.3. IPPM draft.................................................12 5.4. I-D draft..................................................12 6. IPPM-MIB conceptual presentation...........................13 6.1. IPPM-MIB diagram...........................................13 6.2. conceptual programming interface...........................14 6.3. SNMP mapping...............................................14 7. measurement architectures..................................15 7.1. Proxy architecture.........................................15 7.2. probe architecture.........................................16 7.3. Reporting architecture.....................................17 7.4. gateway architecture.......................................18 7.5. Security...................................................19 8. Reporting mode integration with the control and test protocols................................................20 8.1. Integration................................................20 8.2. Setup of the measure.......................................20 8.3. Setup of the report of a measure...........................21 8.4. writing the measure results in the IPPM-MIB................21 8.5. report download and upload.................................21 8.6. Default value..............................................22 9. Definition.................................................22 10. Security Considerations....................................59 10.1. Privacy.....................................................59 10.2. Measurement aspects.........................................59 10.3. Management aspects..........................................60 11. References.................................................61 12. Acknowledgments............................................63 13. Author's Addresses.........................................63 1. Introduction This memo defines a MIB for managing the measures using the IP performance metrics specified by the IPPM Working Group. It specifies the objects to manage the measure of performance metrics standardized by IPPM Working Group. There are built on notions introduced and discussed in the IPPM Framework document, RFC 2330 [2]. This memo defines a Management Information Base (MIB) so it is intended to be respectful of the "Boilerplate for IETF MIBs" defined in http://www.ops.ietf.org/mib-boilerplate.html. There are companion documents to the IPPM MIB both in the Transport Area (See section 2) and in the Operations and Management Area (See section 3). The reader should be familiar with these documents. Stephan Informational - Expires August 2002 [Page 2] Internet Draft IPPM MIB February 2002 2. The IPPM Framework The IPPM Framework consists in 3 major components: A general framework for defining performance metrics, described in the Framework for IP Performance Metrics, RFC 2330 [2]; A set of standardized metrics which conform to this framework. The IPPM Metrics for Measuring Connectivity, RFC 2678 [3]. The One- way Delay Metric for IPPM, RFC 2679 [4]. The One-way Packet Loss Metric for IPPM, RFC 2680 [5]. The Round-trip Delay Metric for IPPM, RFC 2681 [6]; Emerging metrics which are being specified in respect of this framework; 3. The SNMP Management Framework The SNMP Management Framework consists of five major components: An overall architecture, described in RFC 2571 [7]. Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [8], STD 16, RFC 1212 [9] and RFC 1215 [10]. The second version, called SMIv2, is described in STD 58, RFC 2578 [11], STD 58, RFC 2579 [12] and STD 58, RFC 2580 [13]. Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [14]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [15] and RFC 1906 [16]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [16], RFC 2572 [17] and RFC 2574 [18]. Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [14]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [19]. A set of fundamental applications described in RFC 2573 [20] and the view-based access control mechanism described in RFC 2575 [21]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [22]. Stephan Informational - Expires August 2002 [Page 3] Internet Draft IPPM MIB February 2002 Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. In particular, each object type is named by an OBJECT IDENTIFIER, an administratively assigned name. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the descriptor, to refer to the object type. 4. Overview Although the number of measurements devices that implement the IPPM metrics is growing there is not currently any standardized management interface to manage remotely these metrics. This memo defines a Management Information Base for managing the measures of IPPM metrics. To permit metrics to be referenced by other MIBs and other protocols the IPPM-MIB defines a registry of the current metrics and a framework for the integration of the future metrics in the registry. As the specification of new metrics is a continuous process this memo defines a framework for the integration of the future standardized metric. Specialized tables may augment the measure table to address future needs. The MIB architecture is inspired by the RMON model [23],[24] which specify the MIB for the monitoring of a single point of measure. The IPPM-MIB differs from this model because IPPM metrics measurements involve several point of measures and need common references for time and for measure identification. The IPPM-MIB defines an absolute timeFilter and introduces a framework where each application manages its measures in an owner namespace and may grant other owner to Stephan Informational - Expires August 2002 [Page 4] Internet Draft IPPM MIB February 2002 access its measure results for aggregated metrics computation, reporting or alarming. Different architectures may be used to perform metric measurements using a control protocol and a test protocol. Different control frameworks are suitable for performing a measure. The memo list them while looking for how to integrate them together with the IPPM-MIB. This section is informational but helps to specify the relationship among the test protocol, the control protocol and IPPM-MIB. Special care has been taken to provide a reporting mode suitable for control protocol and test protocol. It addresses the need to provide access to result for the applications. Moreover it may be used to reduce the number of control frameworks. This MIB is intended to handle multiple concurrent SNMP applications access. They are not in constant contact with the measurement devices. For this reason, this MIB allows continuous measures collection and statistics computation. The objects defined in this document are not intended for direct manipulation by humans. 4.1. Textual Conventions Four type of data are introduced as a textual convention in this MIB document, TypeP and GMTDateAndTime, GmtTimeFilter IppmReportDefinition and IppmStandardMetrics. 4.1.1. Packet of type P The section 13 of the IPPM framework [2] introduces the generic notion of a "packet of type P" because in some contexts the metric's value depends on the type of the packets involved in the metric. In the definition of a metric the type P will be explicitly defined, partially defined or left generic. Measurement of metrics defined with generic type P made specific when performing actual measurements. This naming convention serves as an important reminder that one must be conscious of the exact type of traffic being measured. The standardization of the management of the IPPM measures relies on the capability to configure finely and unambiguously the type P of the packets and the parameters of the protocols suites of the type P. RMON2 introduced the concept of protocols identifiers. The RFC2895 [25] specifies a macro for the definition of protocol identifier. The RFC2896 [26] defines the protocols identifiers for different protocols encapsulation trees. Stephan Informational - Expires August 2002 [Page 5] Internet Draft IPPM MIB February 2002 The type P implementation relies on the MACRO PROTOCOL-IDENTIFIER defined for identifying protocols suite in the RMON2. It is achieved by defining the TypeP as new syntax in a SMIv2 TEXTUAL-CONVENTION. 4.1.1.1. Internet addresses The section 14 of the IPPM framework defines for the common case of a unidirectional path through the Internet the term "Src" and "Dst". "Src" denotes the IP address of the beginning of the path, and "Dst" denotes the IP address of the end. The section 3 of the RMON PI Reference specifies the Protocol Identifier Encoding rules which consists briefly in a recursive length value format. "Src" and "Dst" are protocol identifier parameters. Their values are encoded in separated fields using the protocol identifier encoding rule but without trailing parameters. The packet encapsulation defined in an instance of TypeP embeds the format of "Src" and "Dst" and their values. These addresses type and value depend on the type P of the packet, IP version 4, V6, IP in IP... Both participate to the completion of the packet encoding. Examples: RFC2896 defines the protocols identifiers ip and ipip4. Should there be a Internet tunnel end-point of the IP address 192.168.1.1 in the tunnel 128.2.6.7. The TypeP of the source address of the tunnel, Src, is 8.0.0.8.0.0.0.0.17.2.0.0 (ip.ipip4). The trailer 2.0.0 in the TypeP indicates that there are 2 parameters. In the IPPM context these 2 parameters are provided in Src which has the value 10.4.192.168.1.1.4.128.2.6.7. 4.1.2. Report definition A report consists in sending or logging a subset of results of measure. The elaboration of the report consist in actions to do on the measure results. A action is performed either: + for each result; + on the results corresponding to a measure cycle; + on the results available at the measure completion. To preserve the scalability of the whole measurement system it limits: + the among of data sent to the applications; + The bandwidth consumption for uploading the result; + The number of alarms sent to the applications; + The among of data saved in the point of measure; Stephan Informational - Expires August 2002 [Page 6] Internet Draft IPPM MIB February 2002 The comparison of the measure results with a metric threshold identifies particular measures value and time that concern directly services availability. The comparison of the duration of repeated events with a duration threshold identifies particular measure value and time that concern directly SLA. The combination of IPPM metrics results, threshold events and event filtering provide a very efficient solution to report results, events and alarms. A report is described using The using the TEXTUAL-CONVENTION IppmReportDefinition. The report setup must not increase dramatically the size of the control protocol measure setup: + A basic report is defined in the object ippmReportSetupDefinition; + More elaborated reports are described using a metric threshold to generate alarms and events. + Pushing of alarms and reports requires an NMS address. + SLA alarms are described using an events duration threshold. The TEXTUAL-CONVENTION IppmReportDefinition specifies the list of events and actions which are used to elaborate a report. 4.1.3. IppmStandardMetrics The TEXTUAL-CONVENTION IppmStandardMetrics defines the standardized IPPM metrics. 4.2. Structure of MIB The MIB is arranged as follow: - Ippm metrics registry - ippmOwnersGroup - ippmSystemGroup - ippmMeasureGroup - ippmHistoryGroup - ippmNetworkMeasureGroup - ippmAggregatedMeasureGroup - ippmReportGroup Stephan Informational - Expires August 2002 [Page 7] Internet Draft IPPM MIB February 2002 - ippmNotifications 4.2.1. The registry of the metrics This group associates an OBJECT IDENTIFIER to each metrics. 4.2.2. The ippmOwners Group This group controls the SNMP applications which are granted to manage the measurement device. 4.2.3. The ippmSystem Group This group consists of a set of parameters describing the clock synchronization over the time. This group is the most important part of the memo. Section 6.3. of the IPPM Framework said that "Those who develop such measurement methodologies should strive to: + minimize their uncertainties/errors, + understand and document the sources of uncertainty/error, and + quantify the amounts of uncertainty/error." The aim of this group is to have these values available to compute reliable statistics. Then the implementation of this group is mandatory either the time synchronization is automatic or not. 4.2.4. The ippmMeasureGroup This group controls all the measures. It consists of the ippmMetricsTable, ippmMeasureTable. The SNMP agent describes in the ippmMetricsTable the local implementation of the standardized metrics. The customers of the agent manage their measures in the ippmMeasureTable and in the auxiliaries measures tables. ippmMeasureTable holds the management part of a measure while the technical parameters are handled in the corresponding auxiliary table. The results of the measures are logged in the ippmHistoryTable. 4.2.5. The ippmNetworkMeasure Group This group controls the network measures defined by the customers. The results are saved in the ippmHistoryTable. Stephan Informational - Expires August 2002 [Page 8] Internet Draft IPPM MIB February 2002 ippmNetworkMeasureTable is an auxiliary table of ippmMeasureTable in charge of the configuration of the network measure. 4.2.6. The ippmAggregatedMeasure Group ippmAggregatedMeasureTable is an auxiliary table of ippmMeasureTable in charge of the consolidation of the results previously performed and saved in the ippmHistoryTable. The aggregated results are saved in the ippmHistoryTable and may be used for higher aggregated measures. 4.2.7. The report Group This group controls the report of the measures. ippmReportSetupTable is an auxiliary table of ippmMeasureTable in charge of the configuration of the reports. The reports are saved in the ippmReportTable or sent directly to applications. 4.2.8. The notification Group The Notification grop is a list of notifications. They are used to push alarms or reports to the applications. 4.3. Row addition in an application namespace The dynamic rows created by an owner are identified in its namespace. An identifier of an instance of an object is defined as a list of objects in the clause INDEX. An identifier of an instance of an object in an owner namespace is defined as a list of objects in the clause INDEX where the first object type is OwnerString As the OBJECT IDENTIFIER which identify the instance begins with the owner value the remaining fields value of the index may be chosen independently from a namespace to another. it allows the user to choose arbitrary values for the remaining fields of the INDEX clause without checking for these fields values existence in the MIB tables. It permits to the owner to use the same fields values across MIBs implementation. It avoids polling to be done to determine the next free index. It avoids 2 applications to find the same free index value. The usage of owner namespace increases the speed of the management operations while reducing bandwidth consumption and CPU load in the agents and applications. Stephan Informational - Expires August 2002 [Page 9] Internet Draft IPPM MIB February 2002 Measures are requested by NMSs. An instance of an object managed by a NMS is identified by the NMS OwnerString and the private index provided by the NMS. As the NMS manages its private range of index, it simply choose one when it wishes to create a new control entry. For the same reason the setup of a measure on several points of measures consists simply in sending the same copy of the measure setup to the different points of measures involved. 4.4. Control of Remote Measurement Devices Due to the complex nature of the available functions in these devices, the functions often need user configuration. In many cases, the function requires parameters to be set up for a data collection operation. The operation can proceed only after these parameters are fully set up. Functional groups in this MIB have one or more tables in which to set up control parameters, and one or more data tables in which to place the results of the operation. The control tables are typically read/write in nature, while the data tables are typically read/only. Because the parameters in the control table often describe resulting data in the data table, many of the parameters can be modified only when the control entry is not active. Thus, the method for modifying these parameters is to de-activate the entry, perform the SNMP Set operations to modify the entry, and then re-activate the entry. Deleting the control entry causes the deletion of any associated data entries. 4.5. Resource Sharing Among Multiple Management Stations When multiple user applications wish to use functions that compete for a finite amount of resources on a device, a method to facilitate this sharing of resources is required. An owner namespace is provided for each application which initiate function in this MIB to avoid these conflicts and to help resolve them when they occur. Each function has a label identifying the initiator (owner) of the function. This label is set by the initiator to provide for the following possibilities: + A application recognizes resources it owns and no longer needs. A application may grant another one to use or manage part of its resources. The agent administrator can identify the application that owns the resource and negotiate for it to be freed. The agent administrator may decide to unilaterally free resources a application has reserved. Stephan Informational - Expires August 2002 [Page 10] Internet Draft IPPM MIB February 2002 The resources owned by the device itself or by the agent administrator is set to a string starting with 'monitor'. 4.6. Row Addition Among Multiple Management Stations Each application is associated with an owner namespace. The indexes of the rows which belong to an application start with this Ownerstring value. The addition of new rows is achieved using the RowStatus method described in RFC 1903 [2] . In this MIB, rows are often added to a table in order to configure a function. This configuration usually involves parameters that control the operation of the function. The agent must check these parameters to make sure their are appropriate given restrictions defined in this MIB as well as any implementation specific restrictions such as lack of resources. 5. IPPM-MIB metrics registry The previous IPPM-MIB [27] includes an IPPM metrics registry in the table ippmMetricTable using constant integer. That is not suitable for cross reference inter MIBs. So the new version of the registry use OBJECT IDENTIFIER to identify the metrics. The registry includes a node to register the metrics included in WG draft. That will permit interoperability verification during the standardization process. The registry includes a node to register the metrics included in ID draft. That will permit easy software integration of specific metrics. The implicit registration framework avoid to wait for the registry set up. 5.1. registry framework The structure of the registry has three branches. The node rfc(1) registers the identifiers of metrics specified in a RFC. The node draft(2) registers the identifiers of metrics specified in a IPPM WG draft. The node id(3) registers the identifiers of metrics specified in an I-D draft. The location of the memo fixes the node of the metric (rfc, draft or id). An identification rule determines the sub identifier of each metric in this node. 5.2. IPPM RFC Stephan Informational - Expires August 2002 [Page 11] Internet Draft IPPM MIB February 2002 Metrics specified in a WG RFC are registered in the node rfc(1). 5.2.1. Identification rules The chronological order of standardization of the metrics in the IPPM WG determines each metric sub identifier. The RFC number determines the chronological order of the RFCs. There are several metrics defined in a document. The sequential order of the metrics definitions is considered as the chronological order. 5.2.2. Integration of a new WG RFC As metric specification is a continuous process this memo defines a framework for the integration of the new RFCs. The metrics defined in a new IPPM RFC are registered using the rules defined in the section named " Identification rules " and a new version of the registry is published. 5.2.3. Implicit integration of metrics defined in a new WG RFC When a new RFC appears the identifiers of the corresponding metrics may be determined by the rules defined in the section named " Identification rules" without waiting the new version of the registry to be published. 5.3. IPPM draft Metrics specified in an IPPM draft are registered in the node draft(2). 5.3.1. Identification rules The chronological order of the draft is the order of the memos in the internet draft list. There are several metrics defined in a document. The sequential order of the metrics definitions is considered as the chronological order. 5.3.2. Integration of new WG drafts Generally metrics are implemented during the specification process. At this step the metric is not identified as an IPPM metric. There is a need to provide temporary metrics identifiers to facilitate software integration and to permit interoperability measurement among different implementations. Otherwise implementers will choose arbitrary identifiers and interoperability verification will be impossible. 5.4. I-D draft Metrics specified in a I-D draft that concern IPPM WG may be associated with temporary identifier in the subtree id(3). Stephan Informational - Expires August 2002 [Page 12] Internet Draft IPPM MIB February 2002 6. IPPM-MIB conceptual presentation 6.1. IPPM-MIB diagram Conceptual view of objects configured using the IPPM-MIB. +--------------------------------------------------------+ | IPPM-MIB entity | | | | +---------------------+ +-------------------+ | | | | | | | | | Measure scheduler | | Result storage | | | | | | | | | | ^ | | ^ ^^^ | | | | | | | | ||| | | | | | | | | ||| | | | +----------|----------+ +-|---|||-----------+ | | | | ||| | | +----------|--------------|---|||-----------+ | | | | owner | ||| | | | | | Acces | ||| | | | | | Control | ||| | | | | | | ||| | | | +----------|--------------|---|||-----------+ | | | | ||| | +------------------|--------------|---|||----------------+ | | ||| | | ||| +----------------+ | +----------+-+ ||| +-------------+ | ControlMeasure | | | GetResult | ||| | CreateResult| |----------------+-+ |------------| ||+--+-------------| | | | | || | | | owner | | owner | || | owner | | privateNdx | | privateNdx | || | privateNdx | | metrics | | metric | || | metrics | | scheduler | | timestamp | || | timestamp | | addresses | +------------+ || | value | | status | || +-------------+ +----------------+ || || +---------------------------+| | | +---------+---------+ +------+-----------------+ |GetMeasureResults | |GetMeasureMetricResults | |-------------------| |------------------------| | | | | | owner | | owner | | privateNdx | | privateNdx | +-------------------+ | metric | +------------------------+ Stephan Informational - Expires August 2002 [Page 13] Internet Draft IPPM MIB February 2002 The managed objects of the IPPM-MIB are the measures and the results. 6.2. conceptual programming interface This section describes a conceptual programming interface for the integration of the IPPM-MIB in a point of measure. 6.2.1. Measure control A measure is created/deleted/suspended through the ControlMeasure() call. 6.2.2. Result log A result of a measure is created in the IPPM-MIB History table using a CreateResult() call. Results belong to a measure and are managed according to the setup of the measure. 6.2.3. reporting Results are reported using the method GetResult(), GetMeasureMetricResults() and GetMeasureResults() respectively to get a singleton result, the singletons result of a metric measure and finally to get the singletons result of a measure. 6.2.4. logical calls Objects are managed using 5 main primitives: controlMeasure(); CreateResult(); GetResult(); GetMeasureMetricResults(); GetMeasureResults(). 6.3. SNMP mapping ControlMeasure() corresponds to a SNMP set-request on a conceptual row of ippmMeasureEntry and on a conceptual row ippmNetworkMeasureEntry. CreateResult() is a internal interface for adding measure results in the ippmHistoryTable. GetResult() corresponds to a SNMP get-request on a result. GetMeasureMetricResults() corresponds to a SNMP walk on the results of a metric measure subtree. Stephan Informational - Expires August 2002 [Page 14] Internet Draft IPPM MIB February 2002 GetMeasureResults() corresponds to a SNMP walk on the results of a measure subtree. 7. measurement architectures There are four main measurement architectures. 7.1. Proxy architecture +----+ +----+ |NMS1| |NMS2| +----+ +----+ ^ ^ | | +----------+ +----------+ | | SNMP or Sibling | | v v +----------------+ |IPPM-MIB entity | +----------------+ ^ ^ | | OWDP-Control | | +----------+ +----------+ | | v v +----------------+ +------------------+ | Packets-Sender |--OWDP-Test-->| Packets-Receiver | +----------------+ +------------------+ In this architecture the different NMS access the IPPM-MIB entity to query for measurements. The IPPM-MIB controls that the NMS is granted to perform the measure asked. Each NMS access the results of its measurements in the IPPM-MIB statistics table. The measurements setup/teardown and the data collection are done using the control protocol and the test protocol. In this mode the NMS does not depend nor on the control protocol nor on the test protocol. The entities involved in the measure do not need to implement the IPPM-MIB nor SNMP. This mode permits lightweight implementation in the point of measures and heterogeneous control protocols to coexist. Finally the proxy is a check point where measure activity may be logged and where access to measure setups may be controlled finely. Stephan Informational - Expires August 2002 [Page 15] Internet Draft IPPM MIB February 2002 That provide a reliable architecture to manage the security of a measurement system. 7.2. probe architecture In this architecture the IPPM-MIB is implemented directly in each point of measure. +----+ +----+ |NMS1| |NMS2| +----+ +----+ ^ ^ | | | | SNMP SNMP | | | +------------------------+ | | | +------------------------+ | | | | | | | | | | | | | v v v v +----------------+ +------------------+ |IPPM-MIB entity | |IPPM-MIB entity | +----------------+ +------------------+ | Packets-Sender |--OWDP-Test-->| Packets-Receiver | +----------------+ +------------------+ The measurements setup/teardown are done directly using the SNMP protocol. Each NMS access directly the results of the measurement in the IPPM-MIB history group. Each IPPM-MIB controls that the NMS is granted to perform the measure asked. In this mode there is no need for a control protocol while the implementation of the IPPM-MIB and SNMP increases the complexity of the point of measure. It increases the complexity of the probes management because the network manager has to configure all the probes each time there is a modification in the system of measurement. Stephan Informational - Expires August 2002 [Page 16] Internet Draft IPPM MIB February 2002 7.3. Reporting architecture In this architecture the protocol SNMP is only used to read the results of the measures in the IPPM-MIB History Table and to inform the NMS that an event has occurs. +----+ +----+ |NMS1| |NMS2| +----+ +----+ ^ ^ ^ ^ | | | | SNMP| SNMP| | | | | | | | | | OWDP | OWDP |Control |Control | | | | | | +------------------------------+ | | | | | | | +--|---------------------------+ | | | | | | | | +--|--|------------------------+ | | | | | | | | | +--------+---------------------+ | | | | | | | | | | | | | | | | | | v v v v v v v v +------------------+ +------------------+ |IPPM-MIB reporting| |IPPM-MIB reporting| | entity | | entity | +------------------+ +------------------+ | Packets-Sender |--OWDP-Test-->| Packets-Receiver | +------------------+ +------------------+ The activation of a measure by the control protocol or the test protocol creates a measure in the IPPM-MIB Measure table. That table may be not accessible by SNMP. In this case a list of the measures identifiers (owner,index) is handled by the measure software. Each timestamped result of the measure is logged on the fly in the IPPM- MIB History table to permit read access to the NMSs and event handling. On completion the measure results are managed according the measure setup: The results may be sent to a NMS entity using a SNMP Trap Pdu or a SNMP Inform PDU. The NMS may be the sender entity or the control entity; They may be dropped from the IPPM-MIB History table. Stephan Informational - Expires August 2002 [Page 17] Internet Draft IPPM MIB February 2002 In this mode it is recommended to use a SNMPv2 Inform PDU to send the result because it controls that the block of result is received. There is no control using SNMP Trap PDU. In this mode it is recommended to implement the IPPM-MIB Measure table in read only to permit NMS to read the status of their measures. 7.4. gateway architecture The gateway architecture combines the proxy mode and the reporting mode. +-------+ +------+ | NMS1 | | NMS2 | +-------+ +------+ ^ ^ | | SNMP SNMP | | | +----------------------------------------+ | | | +-------------+ +------------------+ | | | | | +----------------------------------------+ | | | | | | | | | v v | | | | +---------------------+ | | | | | IPPM-MIB scheduler | | | | | | entity | | | | | +---------------------+ | | | | | control server | | | | | +---------------------+ | | | | ^ ^ | | | | | | | | | | OWDP-Control protocol | | | | | | | | | | +-----+ +-------+ | | | | | | | | v v v v v v +---------+---------+ +----------+---------+ |IPPM-MIB | Packets | | Packets |IPPM-MIB | |reporting| Sender | | Receiver |reporting| | entity | |--OWDP-Test-->| | entity | +---------+---------+ +----------+---------+ The NMS measurement queries are registered in the IPPM-MIB scheduler and performed by the control and the test protocol. NMS consult directly the result in the corresponding points of measure. Stephan Informational - Expires August 2002 [Page 18] Internet Draft IPPM MIB February 2002 7.5. Security The proxy mode provides flexibility and a fine control of the access to the points of measure while permitting lightweight control protocol and test protocol implementations in the points of measure. Different security rules may be applied to the NMS domain and to measurement system domain. The probe mode security relies on SNMP security. SNMP provides different levels of security according to the version used and to the option chosen. SNMPv3 provides a high level of security. The reporting mode has 2 security domains. The control of the measures setup relies on the control and the test protocol security mechanisms. The control of the access to the result depends on the SNMP security mechanisms. The gateway mode security relies on the security of the proxy mode and of the reporting mode. Stephan Informational - Expires August 2002 [Page 19] Internet Draft IPPM MIB February 2002 8. Reporting mode integration with the control and test protocols The IPPM-MIB standardizes the parameters for configuring IPPM metrics measures and for reporting the results. It introduces the concept of owner namespace to permit fast configuration and reporting across multiple points of measures. A measure is a distributed object describing a task to be performed by the control and the test protocols. An measure is identified by its owner and its owner index. This identifier is the same in all the points of measure. As it is chosen by the owner there is no need for negotiation between the NMS and the points of measure before activating the measure. A measure is mainly defined by its identifier, the metrics to measure, the description of the end points addresses and the description of the scheduling of the measure. The description of the measure is distributed to the points of measure involved. The distribution may not be synchronized. 8.1. Integration Control protocol, test protocol and the IPPM-MIB share the same semantic. The parameters used are sibling. The integration of the IPPM-MIB, the test and control protocols relies on the use of the conceptual programming interface described in the section 6. It consists basically in pushing the measure setup/teardown parameters and the results values from the measure software to the IPPM- MIB. 8.2. Setup of the measure The creation of the measure consists only in transferring the measure description from the measurement software to the MIB. The management of the measure is done using the ControlMeasure(). The protocol which provide the parameters of the measure to manage may be the control protocol of the test protocol. Different framework may be used to setup a measure. 8.2.1. synchronous setup The control protocol setups the measure both in the sender and the receiver before the measure. 8.2.2. asynchronous setup Stephan Informational - Expires August 2002 [Page 20] Internet Draft IPPM MIB February 2002 The control protocol setups the measure only in the sender. In this case the receiver has a service already activated (or pending )for the typeP of the measure. As the first test packet includes the description of the measure it may differ from regular test packets. If the first test packet is not consistent with the regular test packets is must not be used for performing metrics measures. 8.3. Setup of the report of a measure The report description is an extension to the definition of a measure. It describes the event and the data to include in the report. A report is read by a NMS in the ippmReportTable, or pushed to a NMS using a SNMP Trap PDU, a SNMP Inform PDU, an email or a SMS. The control protocol or the test protocol includes the description of the report in the setup of the measure. Different types of reports may be combined: + A trivial report defines the results to be saved in the ippmReportTable; + A basic report defines the host to which the results are pushed on completion of the measure; + An alarm report defines a threshold on the results of the measure. A message is sent to a host when the result raise or fall the threshold; + An SLA report defines a threshold on the results of the measure. The events are filtered using a staircase method. The report consists in the results of the measure (time and value) of the filtered events. The reports is sent at each measure cycle or when the measure completes. 8.4. writing the measure results in the IPPM-MIB Results have to be pushed from the measure task to the MIB. Adding result of a measure consists only in transferring the result from the measurement software to the MIB. The protocol which provides the result may be the control protocol or the test protocol. Writing a result is done using the CreateResult(). 8.5. report download and upload A report is read in the ippmReportTable using SNMP, or pushed by the IPPM_MIB agent using a SNMP Trap PDU, a SNMP Inform PDU, an email or a SMS. Stephan Informational - Expires August 2002 [Page 21] Internet Draft IPPM MIB February 2002 8.6. Default value The default values correspond to Ipv4 best effort. 9. Definition IPPM-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, NOTIFICATION-TYPE, OBJECT-TYPE, Integer32, Counter32, experimental FROM SNMPv2-SMI OwnerString FROM RMON-MIB protocolDir FROM RMON2-MIB DisplayString, TimeStamp, DateAndTime, TruthValue, RowStatus, StorageType, TEXTUAL-CONVENTION FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF; ippmMib MODULE-IDENTITY LAST-UPDATED "200202011200Z" -- Feb 1, 2002 ORGANIZATION "France Telecom - R&D" CONTACT-INFO "Postal : Emile Stephan France Telecom - R&D, Dpt. CPN 2, Avenue Pierre Marzin Technopole Anticipa 22307 Lannion Cedex FRANCE Tel: + 33 2 96 05 36 10 E-mail: emile.stephan@francetelecom.com" DESCRIPTION " This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, It defines a registry of the IPPM working Stephan Informational - Expires August 2002 [Page 22] Internet Draft IPPM MIB February 2002 group metrics and specifies the objects used for managing IPPM metrics measures, pushing alarms and reporting the measures results. " REVISION "200107051500Z" -- July 2001 DESCRIPTION "The creation of the IPPM-MIB corresponds to the draft- stephan-ippm-mib-00.txt posted in July 2001. The IPPM-MIB was partially presented during the IPPM WG meeting of London. Two main issues were identified during the 52 th IETF meetings in SLC: + There is a need for a common IPPM metric registry; + There is a short term need for the reporting part of the IPPM- MIB; " REVISION "200201051500Z" -- Jan 2002 DESCRIPTION "This release corresponds to draft-stephan-ippm-mib-01.txt posted in January 2002. This draft added sections which presents: + The different measurement architectures; + The integration of the IPPM-MIB in a measurement software; + The use of the IPPM-MIB for reporting. The new items created in this release are: + Fields in the ippmOwnersTable to control the access of an owner to the measures. + The table ippmResultSharingTable to manage the access of an owner to the results of the measure. All the control tables are optional or read only in reporting mode. " REVISION "200202011200Z" -- Feb 2002 DESCRIPTION "The current release corresponds to draft-stephan-ippm-mib- 02.txt posted in February 2002. It added a section to present the IPPM metrics registry. The new items created in this release are: + TC IppmReportDefinition and IppmStandardMetrics; + The registry of the IPPM metrics; + The ippmReportSetupTable and the ippmReportTable; + The notification tree. " -- Stephan Informational - Expires August 2002 [Page 23] Internet Draft IPPM MIB February 2002 -- to be assigned by IANA -- ::= { experimental 10000 } -- -- registry -- metrics OBJECT IDENTIFIER ::= { ippmMib 1 } rfc OBJECT IDENTIFIER ::= { metrics 1 } draft OBJECT IDENTIFIER ::= { metrics 2 } id OBJECT IDENTIFIER ::= { metrics 3 } -- -- metrics registry from RFC of the IPPM WG -- instantaneousUnidirectionalConnectivity OBJECT IDENTIFIER::={rfc 1} instantaneousBidirectionalConnectivity OBJECT IDENTIFIER ::={rfc 2} intervalUnidirectionalConnectivity OBJECT IDENTIFIER ::= { rfc 3 } intervalBidirectionalConnectivity OBJECT IDENTIFIER ::= { rfc 4 } intervalTemporalConnectivity OBJECT IDENTIFIER ::= { rfc 5 } onewayDelay OBJECT IDENTIFIER ::= { rfc 6 } onewayDelayPoissonStream OBJECT IDENTIFIER ::= { rfc 7 } onewayDelayPercentile OBJECT IDENTIFIER ::= { rfc 8 } onewayDelayMedian OBJECT IDENTIFIER ::= { rfc 9 } onewayDelayMinimum OBJECT IDENTIFIER ::= { rfc 10 } onewayDelayInversePercentile OBJECT IDENTIFIER ::= { rfc 11 } onewayPacketLoss OBJECT IDENTIFIER ::= { rfc 12 } onewayPacketLossPoissonStream OBJECT IDENTIFIER ::= { rfc 13 } onewayPacketLossAverage OBJECT IDENTIFIER ::= { rfc 14 } roundtripDelay OBJECT IDENTIFIER ::= { rfc 15 } roundtripDelayPoissonStream OBJECT IDENTIFIER ::= { rfc 16 } roundtripDelayPercentile OBJECT IDENTIFIER ::= { rfc 17 } roundtripDelayMedian OBJECT IDENTIFIER ::= { rfc 18 } roundtripDelayMinimum OBJECT IDENTIFIER ::= { rfc 19 } roundtripDelayInversePercentile OBJECT IDENTIFIER ::= { rfc 20 } -- -- metrics registry from draft of the IPPM WG -- -- -- metrics registry from individual draft -- -- -- TEXTUAL-CONVENTION -- Stephan Informational - Expires August 2002 [Page 24] Internet Draft IPPM MIB February 2002 TimeUnit ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A list of time units." SYNTAX INTEGER { year(1), month(2), week(3), day(4), hour(5), second(6), ms(7), us(8), ns(9) } -- -- -- A absolute, GMT timer using UTC like convention. -- -- GMTDateAndTime ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d-1d-1d,1d:1d:1d,2d" STATUS current DESCRIPTION "A date-time specification. field octets contents range ----- ------ -------- ----- 1 1 year* 0..255 2 2 month 1..12 3 3 day 1..31 4 4 hour 0..23 5 5 minutes 0..59 6 6 seconds 0..59 7 7-8 1/10 milliseconds 0..9999 *Notes: 0 stands for year 2000. For example, '0102192015100500' represent 8:15pm, 10 seconds and 50 ms GMT on 19 February 2001 and is displayed as 01-02-19,20:15:10,0500" SYNTAX OCTET STRING (SIZE (8)) GmtTimeFilter ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION Stephan Informational - Expires August 2002 [Page 25] Internet Draft IPPM MIB February 2002 "GmtTimeFilter TC is inspired by the TimeFilter defined in the RMON2. The reference of the time of TimeFilter is the local value of sysUptime while GmtTimeFilter uses a absolute reference of time. GmtTimeFilter is intended to be used for the index of a table. It allows an application to download only those rows changed since a particular time. A row is considered changed if the value of any object in the row changes or if the row is created or deleted. Each new conceptual row will be associated with the timeMark instance which was created at the value of ippmTimeSysTimer. It is intended to provide an absolute timestamp index for the result of measures. Typically to each singleton produced by an IPPM measure is associated the timemark corresponding to the moment of the measure. illustrations: Consider the 2 tables measureTable and resultTable measureTable OBJECT-TYPE SYNTAX SEQUENCE OF MeasureEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION '' ::= { fooMib 1 } INDEX { measureIndex } resultTable OBJECT-TYPE SYNTAX SEQUENCE OF ResultEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION '' ::= { fooMib 2 } INDEX { measureIndex, resultTimeMark } ResultEntry { resultTimeMark TimeFilter, resultCounts Counter } Should there be two measure rows in the measure table (measureIndex == 1, measureIndex == 2) which produced results asynchronously (e.g. made at Poisson intervals or sibling) and log them in the result table. Stephan Informational - Expires August 2002 [Page 26] Internet Draft IPPM MIB February 2002 Measure 1 produced the result 34 at time 0102192015100500 GMT, while row 2 produced the value 54 most recently (10ms later) at time 0102192015100600 GMT, and both rows are updated on several later occasions such that the current values are 37 and 53 respectively. Then the following resultCounts instances would exist. resultCounts.1.0102192015100500 34 resultCounts.2.0102192015100600 54 resultCounts.1.0102192015100950 65 resultCounts.1.0102192015100600 57 resultCounts.2.0102192015100800 48 resultCounts.2.0102192015100850 53 resultCounts.1.0102192015110050 49 resultCounts.1.0102192015110200 37 The following get-bulk explains how a NMS retrieves the results of the measures. get-bulk(nonRptrs=1, maxReps=10, resultCounts.1); returns: resultCounts.1.0102192015100500 == 34 resultCounts.1.0102192015100950 == 65 resultCounts.1.0102192015100600 == 57 resultCounts.1.0102192015110050 == 49 resultCounts.1.0102192015110200 == 37 # return lexigraphically-next two MIB instances get-bulk(nonRptrs=0, maxReps=2, resultCounts.1.0102192015100600, resultCounts.2.0102192015100600); returns: resultCounts.1.0102192015100950 == 65 resultCounts.2.0102192015100800 == 48 resultCounts.1.0102192015100600 == 57 resultCounts.2.0102192015100850 == 53 get-bulk(nonRptrs=0, maxReps=2, resultCounts.1.0102192015110200, resultCounts.2.0102192015110200); returns: return lexigraphically-next two MIB instances no 'resultTable' counter values at all are returned because neither counter has been updated since time 0102192015110200 " SYNTAX GMTDateAndTime Stephan Informational - Expires August 2002 [Page 27] Internet Draft IPPM MIB February 2002 TypeP ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d." STATUS current DESCRIPTION "This textual convention is used to describe the protocols encapsulation list of a packet, and is used as the value of the SYNTAX clause for the type of the Src and Dst of a IPPM measure. The RFC2895 specifies a macro for the definition of protocols identifiers while its companion document, the RFC2896 defines a set of protocols identifiers. Notes: An IPPM TypeP does not differ from RMON2 Protocols identifiers but TypeP usage in IPPM MIB differs from Protocol identifier usage in RMON2. A IPPM measure is active so generally TypeP does not describe the link layer (i.e. ether2...). Valid Internet packets are sent from Src to Dst. Then the choice of the link layer relies on the Internet stack. For example, the RFC2896 defines the protocol identifier '16.0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.23.3.0.0.0' which represents ether2.ip.tcp.telnet and the protocol identifier 16.0.0.0.1.0.0.8.0.0.0.0.4.0.0.0.17.3.0.0.0 which stands for ether2.ip.ipip4.udp. The corresponding TypeP are '12.0.0.8.0.0.0.0.6.0.0.0.23.3.0.0.0' (ip.tcp.telnet) and 12.0.0.8.0.0.0.0.4.0.0.0.17.3.0.0.0 (ip.ipip4.udp)." SYNTAX OCTET STRING IppmReportDefinition ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "IppmReportDefinition is intended to be used for the description of a report of results of a measure. By default all the results of a measure belong to the report of this measure. The first step of the report elaboration set up triggers on the value of the measure and on the distribution over time of the events generated by these triggers. The measure results corresponding to an event are reported periodically or sent in alarms as soon as the event appears. The end of description describe housekeeping tasks. An action if performed if the corresponding bit is set to 1. Stephan Informational - Expires August 2002 [Page 28] Internet Draft IPPM MIB February 2002 onSingleton(1): The actions are performed each time a new result of the measure occurs. onMeasureCycle(2): The actions are performed on the results of the measure at the end of each cycle of measure. onMeasureCompletion(3): The actions are performed on the results of the measure at the end of the measure. reportOnlyUptoDownMetricResults(4): Report the contiguous results which are on opposite sides of the metric threshold. reportOnlyExceededEventsDuration(5): Report the current result of a serie of contiguous results which exceed the metric threshold when the duration of the serie is over the events duration threshold seconds. inIppmReportTable(6): store the report in the local ippmReportTable. inSNMPTrapPDU(7): Send the report using a SNMP-Trap-PDU. inSNMPv2TrapPDU(8): Send the report using a SNMPv2-Trap-PDU. inInformRequestPDU(9): Send the report using a SNMP InformRequest-PDU. inEmail(10): Send the report using an email. inSMS(11): Send the report using a SMS. clearHistory(12): Remove all the results corresponding to this measure from the ippmHistoryTable. clearReport(13): Remove all the results corresponding to this measure from the ippmReportTable. " SYNTAX BITS { none(0), -- reserved Stephan Informational - Expires August 2002 [Page 29] Internet Draft IPPM MIB February 2002 onSingleton(1), onMeasureCycle(2), onMeasureCompletion(3), reportOnlyUptoDownMetricResults(4), reportOnlyExceededEventsDuration(5), inIppmReportTable(6), inSNMPTrapPDU(7), inSNMPv2TrapPDU(8), inInformRequestPDU(9), inEmail(10), inSMS(11), clearHistory(12), clearReport(13) } IppmStandardMetrics ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The definition of the standardized IPPM metrics. if the draftMetrics bit is set then the other bits describe a WG draft metric identifiers. " SYNTAX BITS { draftMetrics(0), instantaneousUnidirectionalConnectivity(1), instantaneousBidirectionalConnectivity(2), intervalUnidirectionalConnectivity(3), intervalBidirectionalConnectivity(4), intervalTemporalConnectivity(5), onewayDelay(6), onewayDelayPoissonStream(7), onewayDelayPercentile(8), onewayDelayMedian(9), onewayDelayMinimum(10), onewayDelayInversePercentile(11), onewayPacketLoss(12), onewayPacketLossPoissonStream(13), onewayPacketLossAverage(14), roundtripDelay(15), roundtripDelayPoissonStream(16), roundtripDelayPercentile(17), roundtripDelayMedian(18), roundtripDelayMinimum(19), roundtripDelayInversePercentile(20) } -- IPPM Mib objects definitions ippmCompliances OBJECT IDENTIFIER ::= { ippmMib 2 } ippmOwnersGroup OBJECT IDENTIFIER ::= { ippmMib 3 } Stephan Informational - Expires August 2002 [Page 30] Internet Draft IPPM MIB February 2002 ippmSystemGroup OBJECT IDENTIFIER ::= { ippmMib 4 } ippmMeasureGroup OBJECT IDENTIFIER ::= { ippmMib 5 } ippmHistoryGroup OBJECT IDENTIFIER ::= { ippmMib 6 } ippmNetworkMeasureGroup OBJECT IDENTIFIER ::= { ippmMib 7 } ippmAggregatedMeasureGroup OBJECT IDENTIFIER ::= { ippmMib 8 } ippmReportGroup OBJECT IDENTIFIER ::= { ippmMib 9 } ippmNotifications OBJECT IDENTIFIER ::= { ippmMib 10 } -- -- ippmOwnersGroup -- -- The ippmOwnersGroup objects are in charge of the management -- of the access of the owners to the measurements. -- -- ippmOwnersControlTable OBJECT-TYPE SYNTAX SEQUENCE OF IppmOwnersControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A NMS entity wishing to create and activate remote Ippm measurements in an agent must previously be registered in the ippmOwnersControlTable using the conceptual row mechanism described in the RMON2. The control of the access to the results of the measures is managed in the table ippmResultSharing. " ::= { ippmOwnersGroup 1 } ippmOwnersControlEntry OBJECT-TYPE SYNTAX IppmOwnersControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The description of the resources the agent granted to a SNMP application. For example, an instance of ippmOwnersControlOwner with an OwnerString 'acme', which represents the 14th owner created in ippmOwnersControlTable would be named ippmOwnersControlEntryOwner.14. Notes: The ippmOwnersControlIndex value is a local index managed directly by the agent. It is not used in anyway in the other IPPM tables." INDEX { ippmOwnersControlIndex } Stephan Informational - Expires August 2002 [Page 31] Internet Draft IPPM MIB February 2002 ::= { ippmOwnersControlTable 1 } IppmOwnersControlEntry ::= SEQUENCE { ippmOwnersControlOwner OwnerString, ippmOwnersControlIndex Integer32, ippmOwnersControlGrantedMetrics IppmStandardMetrics, ippmOwnersControlGrantedRules BITS, ippmOwnersControlIpAddress DisplayString, ippmOwnersControlEmail DisplayString, ippmOwnersControlSMS DisplayString, ippmOwnersControlStatus OwnerString } ippmOwnersControlIndex OBJECT-TYPE SYNTAX Integer32 (1.. 65535) MAX-ACCESS read-create STATUS current DESCRIPTION "An arbitrary index that only identify an entry in this table" ::= { ippmOwnersControlEntry 1 } ippmOwnersControlOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The owner described by this entry." ::= { ippmOwnersControlEntry 2 } ippmOwnersControlGrantedMetrics OBJECT-TYPE SYNTAX IppmStandardMetrics MAX-ACCESS read-create STATUS current DESCRIPTION " Defines the metrics granted to an owner." ::= { ippmOwnersControlEntry 3 } ippmOwnersControlGrantedRules OBJECT-TYPE SYNTAX BITS { all(0), readonly(1), permanent(2), sender(2), receive(3), report(4), alarm(5) } MAX-ACCESS read-create STATUS current Stephan Informational - Expires August 2002 [Page 32] Internet Draft IPPM MIB February 2002 DESCRIPTION "Defines the rules this owner may act as in the current IPPM MIB instance. all(0): The owner is granted with all the rules. readonly(1): The measures (not only the metrics) allowed to this owner are setup by the manager of the point of measure. The owner can not add new measures for these metrics. The creation and the configuration of the measures corresponding to these metrics are managed by the manager of the point of measure. permanent(2): The measures (not only the metrics) allowed to this owner are determined by the manager of the point of measure. The owner can not add new measures for these metrics. The creation and the first configuration of the measures corresponding to these metrics are managed by the manager of the point of measure. The owner may modify the measures parameters of the entries of the corresponding ippmMeasureEntry which access is read-write. Typically that permits the owner to suspend the measures, to change the begin and end of the measures. sender(3): The owner may only activate measures for theses metrics that send packets from the current point of measure. This flag is only suitable for network measures. It shall be ignored for derived metrics. receiver(2): The owner may only activate measures for theses metrics that receive packets on the current point of measure. This flag is only suitable for network measures. It shall be ignored for derived metrics. Such control increases the security. The owner may not generate packets from the probe. report(4): The owner may setup aggregated metrics on the measures corresponding to these metrics. alarm(5): The owner may setup alarms on the results of the measures metrics. e.g.: if the owner Acme is granted with the metric Instantaneous- Unidirectional-Connectivity as a Receiver in the current point of measure, then Acme can not setup a Instantaneous-Unidirectional- Connectivity to another point of measure. " DEFVAL { 1 } ::= { ippmOwnersControlEntry 4 } Stephan Informational - Expires August 2002 [Page 33] Internet Draft IPPM MIB February 2002 ippmOwnersControlIpAddress OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-create STATUS current DESCRIPTION "The IP address of the NMS corresponding to this owner. The address is human readable and is represented using the dot format." ::= { ippmOwnersControlEntry 5 } ippmOwnersControlEmail OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-create STATUS current DESCRIPTION "The email address of the NMS corresponding to this owner." ::= { ippmOwnersControlEntry 6 } ippmOwnersControlSMS OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-create STATUS current DESCRIPTION "The SMS phone number of the NMS corresponding to this owner." ::= { ippmOwnersControlEntry 7 } ippmOwnersControlStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this table entry." ::= { ippmOwnersControlEntry 8 } -- -- ippmResultSharingTable -- ippmResultSharingTable OBJECT-TYPE SYNTAX SEQUENCE OF IppmResultSharingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION " ippmResultSharingTable controls finely the access of an owner to the measure results of other owners. An owner may grant another to read the result of its measure. Stephan Informational - Expires August 2002 [Page 34] Internet Draft IPPM MIB February 2002 Entries may exist in ippmResultSharingTable even is the measures to be shared are not yet defined. Deleting a measure entry in the ippmMeasureTable does not delete the entries corresponding to this measure in the ippmResultSharingTable. IppmResultSharingTable is optional. If this table is not implemented then the owner has only access to its measure results." ::= { ippmOwnersGroup 2 } ippmResultSharingEntry OBJECT-TYPE SYNTAX IppmResultSharingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry allows an owner to read the results of a measure owned by another owner. It permits 2 typical usages: creating derived measurements on these results; reading the results from a remote NMS. Example: if acme.12 is a One-way-Delay(6) measure Acme may allows Peter to make derived metrics On the results of this measure. " INDEX { ippmResultSharingOwner, ippmResultSharingIndex} ::= { ippmResultSharingTable 1 } IppmResultSharingEntry ::= SEQUENCE { ippmResultSharingOwner OwnerString, ippmResultSharingIndex Integer32, ippmResultSharingMeasureOwner OwnerString, ippmResultSharingMeasureIndex Integer32, ippmResultSharingGrantedOwner OwnerString, ippmResultSharingStatus RowStatus } ippmResultSharingOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION " The owner of this result control entry. Typically the owner which created this conceptual row." ::= { ippmResultSharingEntry 1 } ippmResultSharingIndex OBJECT-TYPE Stephan Informational - Expires August 2002 [Page 35] Internet Draft IPPM MIB February 2002 SYNTAX Integer32 (1.. 65535) MAX-ACCESS read-create STATUS current DESCRIPTION " The index of this result control entry. The value is managed by the owner. On creation a SNMP error 'inconsistentValue' is returned if this value is already in use by this owner." ::= { ippmResultSharingEntry 2 } ippmResultSharingMeasureOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The owner of the measure to be shared. The couple ippmResultSharingMeasureOwner, ippmResultSharingMeasureIndex identifies absolutely a measure" ::= { ippmResultSharingEntry 3 } ippmResultSharingMeasureIndex OBJECT-TYPE SYNTAX Integer32 (1.. 65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The index of the measure to be shared." ::= { ippmResultSharingEntry 4 } ippmResultSharingGrantedOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-only STATUS current DESCRIPTION "The owner which is granted to access to the result of the measure described by the couple ippmResultSharingMeasureOwner, ippmResultSharingMeasureIndex." ::= { ippmResultSharingEntry 5 } ippmResultSharingStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-only STATUS current DESCRIPTION " The status of this table entry. Once the entry status is set to active." ::= { ippmResultSharingEntry 6 } -- -- ippmSystemGroup Stephan Informational - Expires August 2002 [Page 36] Internet Draft IPPM MIB February 2002 -- -- ippmSystemTimer OBJECT-TYPE SYNTAX GMTDateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The current time of the system." ::= { ippmSystemGroup 1 } ippmSystemSynchonizationType OBJECT-TYPE SYNTAX INTEGER { other(0), ntp(1), gps(2), cdma(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "ippmSystemSynchonizationType describes the mechanism used to synchronise the system. other The synchronisation process must be defined extensively in the ippmSystemSynchonizationDescription. ntp The system is synchronised using the network time protocol. The NTP synchronisation must be described finely in the ippmSystemSynchonizationDescription. gps The system is synchronised using the GPS clocks. cdma The system is synchronised using the CDMA clocks. " ::= { ippmSystemGroup 2 } ippmSystemSynchonizationDescription OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "The description of the synchronization process." ::= { ippmSystemGroup 3 } Stephan Informational - Expires August 2002 [Page 37] Internet Draft IPPM MIB February 2002 ippmSystemClockResolution OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "ippmSystemClockResolution provides the precision of the clock used for the measures. The unit is 1/10 of millisecond. For example, the clock on an old Unix host might advance only once every 10 msec, and thus have a resolution of only 10 msec." ::= { ippmSystemGroup 4 } ippmSystemSynchronisationTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The time when occurs the last synchronisation of the clock. The last synchronisation must be set even if the synchronisation is not automatic." ::= { ippmSystemGroup 5 } ippmSystemClockAccuracy OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The most recent accuracy of the clock computed. The accuracy must be compute even if the synchronisation is not automatic." ::= { ippmSystemGroup 6 } ippmSystemClockSkew OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The most recent skew of the clock computed. The ippmSystemSkew must be compute even if the synchronisation is not automatic." ::= { ippmSystemGroup 7 } ippmSystemPrevClockAccuracy OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION Stephan Informational - Expires August 2002 [Page 38] Internet Draft IPPM MIB February 2002 "The previous accuracy of the clock measured. The ippmSystemPrevClockAccuracy must be computed even if the synchronisation is not automatic." ::= { ippmSystemGroup 8 } ippmSystemPrevClockSkew OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The previous skew of the clock measured. The ippmSystemPrevClockSkew must be computed even if the synchronisation is not automatic." ::= { ippmSystemGroup 9 } -- -- -- -- ippmMeasureGroup -- -- -- ippmMetricTable OBJECT-TYPE SYNTAX SEQUENCE OF IppmMetricEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the current implementation. This table is mandatory. Each IPPM standardized metric must be described in the table. In reporting mode the entries of this table may be not accessible. It means that the table is handle internally by the measure software. " ::= { ippmMeasureGroup 1 } ippmMetricEntry OBJECT-TYPE SYNTAX IppmMetricEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describes the static capabilities of a metric implementation." INDEX { ippmMetricIndex } ::= { ippmMetricTable 1 } IppmMetricEntry ::= SEQUENCE { Stephan Informational - Expires August 2002 [Page 39] Internet Draft IPPM MIB February 2002 ippmMetricIndex Integer32, ippmMetricCapabilities INTEGER, ippmMetricUnit INTEGER, ippmMetricDescription DisplayString, ippmMetricMaxHistorySize Integer32 } ippmMetricIndex OBJECT-TYPE SYNTAX Integer32 (1.. 65535) MAX-ACCESS read-only STATUS current DESCRIPTION "ippmMetricIndex defines an unambiguous index for each standardized metric. Its value is the value of the node of the metric in the IPPM-MIB metrics registry ippmMib.metrics.rfc. Each metric registered in the standard registry must be present in this table. This index is used to identify the metric performed among the IPPM-MIB entities involved in the measure. Example: The index of the metric onewayPacketLossAverage which is registered as ippmMib.metrics.rfc.onewayPacketLossAverage will always have the value 14." ::= { ippmMetricEntry 1 } ippmMetricCapabilities OBJECT-TYPE SYNTAX INTEGER { notImplemented(0), implemented(1) } MAX-ACCESS read-only STATUS current DESCRIPTION "notImplemented the metric is not implemented. implemented the metric is implemented." DEFVAL { implemented } ::= { ippmMetricEntry 2 } ippmMetricUnit OBJECT-TYPE SYNTAX INTEGER { noUnit(0), second(1), ms(2), us(3), ns(4), percentage(5), packets(6), byte(6), Stephan Informational - Expires August 2002 [Page 40] Internet Draft IPPM MIB February 2002 kbyte(7), megabyte(8) } MAX-ACCESS read-only STATUS current DESCRIPTION "The unit used in the current entity for the results of the measure of this metric." ::= { ippmMetricEntry 3 } ippmMetricDescription OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "A textual description of the metric implementation." ::= { ippmMetricEntry 4 } ippmMetricMaxHistorySize OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the maximal number of results that a metric measure can save in the ippmHistoryTable." ::= { ippmMetricEntry 5 } -- -- ippmMeasureTable -- -- ippmMeasureTable OBJECT-TYPE SYNTAX SEQUENCE OF IppmMeasureEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of all the IPPM measures which are running in the device. They may not be active. a measure consists in a subset of metrics to compute. The results of the measure may be saved in the ippmHistoryTable. The configuration of the measure sets the size of the history requested in ippmMeasureHystorySize. The maximal number of MIB objects to be collected in the portion of ippmHistoryTable associated with this metric depends the value of the ippmMetricMaxHistorySize. Stephan Informational - Expires August 2002 [Page 41] Internet Draft IPPM MIB February 2002 The value of each metric ippmMeasureHystorySize must not be over the value of ippmMetricMaxHistorySize corresponding to this metric in ippmMetricTable. In reporting mode the entries of this table may be not accessible. It means that the table is handle internally by the measure software. " ::= { ippmMeasureGroup 2 } ippmMeasureEntry OBJECT-TYPE SYNTAX IppmMeasureEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A SNMP entity wishing to create and activate a measurement adds a new entry in the ippmMeasureTable. Typically the configuration operation set the values of the conceptual row parameters using an unused owner index and sets the status of the row to createAndGo. An SNMP error 'inconsistentValue' is returned if the owner index is out of range." INDEX { ippmMeasureOwner, ippmMeasureIndex } ::= { ippmMeasureTable 1 } IppmMeasureEntry ::= SEQUENCE { ippmMeasureOwner OwnerString, ippmMeasureIndex Integer32, ippmMeasureName DisplayString, ippmMeasureMetrics IppmStandardMetrics, ippmMeasureBeginTime GMTDateAndTime, ippmMeasureClockPeriodUnit TimeUnit, ippmMeasureClockPeriod Integer32, ippmMeasureDurationUnit TimeUnit, ippmMeasureDuration Integer32, ippmMeasureHystorySize Integer32, ippmMeasureStorageType StorageType, ippmMeasureStatus RowStatus } ippmMeasureOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The owner who has configured this entry." DEFVAL { "acme" } Stephan Informational - Expires August 2002 [Page 42] Internet Draft IPPM MIB February 2002 ::= { ippmMeasureEntry 1 } ippmMeasureIndex OBJECT-TYPE SYNTAX Integer32 (1.. 65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The owner index of the measure. The value is managed by the owner. An SNMP error 'inconsistentValue' is returned if this value is already in use by this owner." ::= { ippmMeasureEntry 2 } ippmMeasureName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-create STATUS current DESCRIPTION "The name of the instance of the metric. It illustrates the specificity of the metric and includes the metric and the typeP. example: IP-port-HTTP-connectivity" ::= { ippmMeasureEntry 3 } ippmMeasureMetrics OBJECT-TYPE SYNTAX IppmStandardMetrics MAX-ACCESS read-create STATUS current DESCRIPTION "Defines the metrics to compute within this measure. A measure may be configured for the result of different metrics singletons to be archive in the ippmHistoryTable. The ippmMetricIndex of the created result has the value of the bit index of the corresponding ippmMeasureMetrics as explained above in the ippmMetricIndex definition. Example: A measure asking for One-way-Delay(6) and One-way- Packet-Loss(12) generated a flow of singletons which are logged in the ippmHistoryTable. The singletons created for the One-way-Delay measure have a value of ippmMetricIndex of 6 while the created singletons for the One-way-Packet-Loss measure have a value of ippmMetricIndex of 12." DEFVAL { { one-way-Delay, one-way-Packet-Loss } } ::= { ippmMeasureEntry 4 } Stephan Informational - Expires August 2002 [Page 43] Internet Draft IPPM MIB February 2002 ippmMeasureBeginTime OBJECT-TYPE SYNTAX GMTDateAndTime MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the time at which the measure starts." ::= { ippmMeasureEntry 5 } ippmMeasureClockPeriodUnit OBJECT-TYPE SYNTAX TimeUnit MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the unit of the measure period." DEFVAL { second } ::= { ippmMeasureEntry 6 } ippmMeasureClockPeriod OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the among of time between 2 sampling intervals. Notes: This interval generates a flow of periodical instants which may be transformed as a flow of unpredictable instants of measure by the ippmNetworkMeasureClockPattern." DEFVAL { 60 } ::= { ippmMeasureEntry 7 } ippmMeasureDurationUnit OBJECT-TYPE SYNTAX TimeUnit MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the unit of the measure duration." DEFVAL { second } ::= { ippmMeasureEntry 8 } ippmMeasureDuration OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the duration of the measure." Stephan Informational - Expires August 2002 [Page 44] Internet Draft IPPM MIB February 2002 DEFVAL { 120 } ::= { ippmMeasureEntry 9 } ippmMeasureHystorySize OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the maximum number of results saved for each metric of this measure. The history of each metric is managed as a circular table. The newest result overwrite the oldest one when the history granted to this metric measure is full. The management of the results may be optimized if synchronized with the reports steps of this measure. " DEFVAL { 120 } ::= { ippmMeasureEntry 10 } ippmMeasureStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "This object defines whether this row and the measure controlled by this row are kept in volatile storage and lost upon reboot or if this row is backed up by non-volatile or permanent storage. Possible values are: other(1), volatile(2), nonVolatile(3), permanent(4), readOnly(5)" DEFVAL { nonVolatile } ::= { ippmMeasureEntry 11 } ippmMeasureStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this table entry. Once the entry status is set to active, the associate entry cannot be modified." DEFVAL { createAndGo } ::= { ippmMeasureEntry 12 } -- -- ippmHistoryGroup -- -- Stephan Informational - Expires August 2002 [Page 45] Internet Draft IPPM MIB February 2002 -- -- ippmHistoryTable -- ippmHistoryTable OBJECT-TYPE SYNTAX SEQUENCE OF IppmHistoryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of the results of the measures." ::= { ippmHistoryGroup 1 } ippmHistoryEntry OBJECT-TYPE SYNTAX IppmHistoryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An ippmHistoryEntry entry is one of the result of an measure identified by the index members ippmMeasureOwner and ippmMeasureIndex. In the index : + ippmMeasureOwner and ippmMeasureIndex identify the ippmMeasureEntry on whose behalf this entry was created; + ippmMetricIndex identifies the ippmMetricEntry of the metric to measure; + ippmLogTimeMark value is the absolute time when the result of the metric was measured. The ippmHistoryTimeMark value is the absolute time when the ippmHistoryValue was performed. IppmHistoryValue is the value of the metric measured at the time ippmHistoryTimeMark. Example: A one way delay measure is created by the entity 'acme' using the owner index 1 and setting the 6th bit (corresponding to One-way-Delay) of ippmMeasureMetrics to 1. Consider that the result of the one way delay measured for acme on the day 15 of June at 8h20mn 10s 10ms is 23. The result is identified as the singleton Stephan Informational - Expires August 2002 [Page 46] Internet Draft IPPM MIB February 2002 ippmHistoryValue.acme.1.6.0106150820100100 and stored with value 23. Its value may be retrieved using a get- next(ippmHistoryValue.acme.1.6.0106150820100099) which returns (ippmHistoryValue.acme.1.6.0106150820100100 == 23). The ippmMetricIndex value of '6' corresponds to the 6th metric of ippmMetricTable which is Type-P-One-way- Delay. " INDEX { ippmMeasureOwner, ippmMeasureIndex, ippmMetricIndex, ippmHistoryTimeMark } ::= { ippmHistoryTable 1 } IppmHistoryEntry ::= SEQUENCE { ippmHistoryTimeMark GMTDateAndTime, ippmHistoryValue Integer32 } ippmHistoryTimeMark OBJECT-TYPE SYNTAX GMTDateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The instant of the measure of the result." ::= { ippmHistoryEntry 1 } ippmHistoryValue OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the measure." ::= { ippmHistoryEntry 2 } -- -- ippmNetworkMeasureGroup -- -- -- -- ippmNetworkMeasureTable -- -- Stephan Informational - Expires August 2002 [Page 47] Internet Draft IPPM MIB February 2002 ippmNetworkMeasureTable OBJECT-TYPE SYNTAX SEQUENCE OF IppmNetworkMeasureEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A entry is a measure which performs network measures and provides a flow of results. This table extends the ippmMeasureTable. A network measure is a specific measure. It performs several metrics measure per packet exchange. Each step of a measure produces a singleton result per metric. The time of the measure and the value of the metric are saved in the ippmHistoryTable." ::= { ippmNetworkMeasureGroup 1 } ippmNetworkMeasureEntry OBJECT-TYPE SYNTAX IppmNetworkMeasureEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A SNMP entity wishing to create and activate a network measure adds a new entry in the ippmMeasureTable and in IppmNetworkMeasureTable. Typically the configuration operation set both the values of the new ippmMeasureEntry and of the new IppmNetworkMeasureEntry and sets the status of the row to createAndGo. An SNMP error 'inconsistentValue' is returned if the index is out of range. The ippmMeasureMetrics is set to a list of metrics to be computed from the same raw packet exchange. Each step of measure delivers a singleton per chosen metric. Results are timestamped and saved in the ippmHistoryTable." INDEX { ippmMeasureOwner, ippmMeasureIndex } ::= { ippmNetworkMeasureTable 1 } IppmNetworkMeasureEntry ::= SEQUENCE { ippmNetworkMeasureSrcTypeP TypeP, ippmNetworkMeasureSrc OCTET STRING, ippmNetworkMeasureDstTypeP TypeP, ippmNetworkMeasureDst OCTET STRING, ippmNetworkMeasureClockPattern OCTET STRING, ippmNetworkMeasureTimeoutDelay Integer32, ippmNetworkMeasureL3PacketSize Integer32, ippmNetworkMeasureDataPattern OCTET STRING Stephan Informational - Expires August 2002 [Page 48] Internet Draft IPPM MIB February 2002 } ippmNetworkMeasureSrcTypeP OBJECT-TYPE SYNTAX TypeP MAX-ACCESS read-create STATUS current DESCRIPTION "Defines the type P of the source address of the packets sent by the measure." DEFVAL { '04000080001000'H } -- ->ip: 4.0.0.8.0.1.0 ::= { ippmNetworkMeasureEntry 1 } ippmNetworkMeasureSrc OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the address of the source of the measure. It is represented as an octet string with specific semantics and length as identified by the ippmNetworkMeasureSrcTypeP. For example, if the ippmNetworkMeasureSrcTypeP indicates an encapsulation of 'ip', this object length is 4, followed by the 4 octets of the IP address, in network byte order." DEFVAL { '04C0210415'H } -- -> ip: 192.33.4.21 ::= { ippmNetworkMeasureEntry 2} ippmNetworkMeasureDstTypeP OBJECT-TYPE SYNTAX TypeP MAX-ACCESS read-create STATUS current DESCRIPTION "Defines the type P of the destination address of the packets sent by the measure." DEFVAL { '04000080001000'H } -- ->ip: 4.0.0.8.0.1.0 ::= { ippmNetworkMeasureEntry 3 } ippmNetworkMeasureDst OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the address of the destination of the measure. It is represented as an octet string with specific semantics and length as identified by the ippmNetworkMeasureDstTypeP. Stephan Informational - Expires August 2002 [Page 49] Internet Draft IPPM MIB February 2002 For example, if the ippmNetworkMeasureDstTypeP indicates an encapsulation of 'ip', this object length is 4, followed by the 4 octets of the IP address, in network byte order." DEFVAL { '04C0220414'H } -- -> ip: 192.34.4.20 ::= { ippmNetworkMeasureEntry 4 } ippmNetworkMeasureClockPattern OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-create STATUS current DESCRIPTION "This cyclic clock shapes the profile of the instants of measurement according to an arbitrary distribution law. The clock resolution is ippmMeasureClockPeriod. The bits of the clock set to the value 1 determine the valid instants of measurement. A measure is to be processed if and only if the current bit value is 1. This pseudo-random clock pattern allows the configuration by the NMS of numerous kind of sampling law such as periodic or Poisson." DEFVAL { 11111111} -- 100% periodic ::= { ippmNetworkMeasureEntry 5 } ippmNetworkMeasureTimeoutDelay OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current -- UNITS "Milliseconds" DESCRIPTION "Specifies the delay after which the packet is considered lost." DEFVAL { 1 } ::= { ippmNetworkMeasureEntry 6 } ippmNetworkMeasureL3PacketSize OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the size of the packets send at the last network layer in the sense of the TypeP definition." DEFVAL { 64 } ::= { ippmNetworkMeasureEntry 7 } ippmNetworkMeasureDataPattern OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-create STATUS current DESCRIPTION Stephan Informational - Expires August 2002 [Page 50] Internet Draft IPPM MIB February 2002 "The current field defines the round robin pattern used to fill the packet." DEFVAL { 'FF'H } ::= { ippmNetworkMeasureEntry 8 } -- -- -- ippmAggregatedMeasureGroup -- -- -- -- -- ippmAggregatedMeasureTable -- -- ippmAggregatedMeasureTable OBJECT-TYPE SYNTAX SEQUENCE OF IppmAggregatedMeasureEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION " This table extends the ippmMeasureTable. A aggregated measure summarizes the results of previous network or aggregated measures. The results may saved in the ippmHistoryTable. Each step of the measure computation produces a singleton result per metric." ::= { ippmAggregatedMeasureGroup 1 } ippmAggregatedMeasureEntry OBJECT-TYPE SYNTAX IppmAggregatedMeasureEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A SNMP entity wishing to create and activate a statistic measure adds a new entry in the ippmMeasureTable and in ippmAggregatedMeasureTable. Typically the configuration operation sets both the values of the new ippmMeasureEntry and of the new IppmAggregatedMeasureEntry and sets the status of the row to createAndGo. The ippmMeasureMetrics defines the metric to compute. The results of the measure to summarize are identified by ippmAggregatedMeasureHistoryOwner, IppmAggregatedMeasureHistoryOwnerIndex and ippmAggregatedMeasureHistoryMetric Stephan Informational - Expires August 2002 [Page 51] Internet Draft IPPM MIB February 2002 The aggregated task starts at ippmMeasureBeginTime and end after ippmMeasureDuration. A aggregated result is performed and saved in the ippmHistoryTable for each ippmMeasureClockPeriod. " INDEX { ippmMeasureOwner, ippmMeasureIndex } ::= { ippmAggregatedMeasureTable 1 } IppmAggregatedMeasureEntry ::= SEQUENCE { ippmAggregatedMeasureHistoryOwner OwnerString, ippmAggregatedMeasureHistoryOwnerIndex Integer32, ippmAggregatedMeasureHistoryMetric Integer32 } ippmAggregatedMeasureHistoryOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The owner of the measure to summarize. " ::= { ippmAggregatedMeasureEntry 1 } ippmAggregatedMeasureHistoryOwnerIndex OBJECT-TYPE SYNTAX Integer32 (1.. 65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The owner index of the measure to summarize. " ::= { ippmAggregatedMeasureEntry 2 } ippmAggregatedMeasureHistoryMetric OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The metric of the measure to summarize. " ::= { ippmAggregatedMeasureEntry 3 } -- -- ippmReportGroup -- -- -- -- ippmReportSetupTable -- -- Stephan Informational - Expires August 2002 [Page 52] Internet Draft IPPM MIB February 2002 ippmReportSetupTable OBJECT-TYPE SYNTAX SEQUENCE OF IppmReportSetupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ippmReportSetupTable is a list of definition of reports. It defines the results of a network or aggregated measures which are to report. A report is saved in the ippmReportTable or sent to an application using a SNMP Trap, a SNMP inform PDU, an email or a SMS. The reporting task is not a batch action processed at the end of the measure. It is coupled with threshold detections and event filtering to deliver application level events and data while preserving scalability. It extends the definition of a measure: the definition of an measure may include the definition of a report." ::= { ippmReportGroup 1 } ippmReportSetupEntry OBJECT-TYPE SYNTAX IppmReportSetupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The report applies on the results of the measure which is extended by the current report definition. Typically the creation or a report sets both the values of the new measure and those of the new IppmReportSetupEntry. The ippmReportSetupDefinition describes the data and the events to include in the report. The definition consists in a list of tasks to perform on the results of the measure." INDEX { ippmMeasureOwner, ippmMeasureIndex } ::= { ippmReportSetupTable 1 } IppmReportSetupEntry ::= SEQUENCE { ippmReportSetupDefinition IppmReportDefinition, ippmReportSetupMetricThreshold Integer32, ippmReportSetupEventsDurationThreshold Integer32, ippmReportSetupNMS DisplayString } ippmReportSetupDefinition OBJECT-TYPE SYNTAX IppmReportDefinition MAX-ACCESS read-create STATUS current DESCRIPTION Stephan Informational - Expires August 2002 [Page 53] Internet Draft IPPM MIB February 2002 "The description of the events and actions which participate to the elaboration of the report. Send the report using the type of message selected by the bits 8 to 12. The report consists in the results of the measure which have been saved in the ippmReportTable. If the onEventSendReport(7) bit is unset the report is not saved. The message sent is a notification defined in the ippmNotifications node. The notification sent depends on the step of the measure: + Singleton events are sent using the notification ippmSingletonAlarm; + Exceeded events duration are sent using the notification ippmEventsDurationExceededAlarm; + A report of a cycle of measure is sent using the notification ippmCycleOfMeasureReport; + A report of a complete measure is sent using the notification ippmCompletedMeasureReport; Example 1: The setup of an alarm to be sent to the owner in a SNMP Trap each time the staircase crosses the metric threshold value of 5: ippmReportSetupMetricThreshold 5 ippmReportSetupDefinition { onSingleton(1), reportOnlyUptoDownMetricResults(4), inSNMPTrapPDU(8) } Example 2: The setup of a report to be sent to the owner in a SNMP informRequestPDU per measure cycle. It reports the staircase values corresponding to a metric threshold of 5: ippmReportSetupMetricThreshold 5 ippmReportSetupDefinition { onMeasureCycle(2), reportOnlyUptoDownMetricResults(4), inInformRequestPDU(10), clearHistory(13) } Default report: The default report provides the control protocol with an implicit mechanism to forward the result of a cycle of measure to the owner of the measure while deleting the results from the ippmHistoryTable on reception of the response to the InformRequestPDU : Stephan Informational - Expires August 2002 [Page 54] Internet Draft IPPM MIB February 2002 ippmReportSetupDefinition { onMeasureCycle(2), inInformRequestPDU(10), clearHistory(13) } " DEFVAL { { onMeasureCycle, inInformRequestPDU, clearHistory } } ::= { ippmReportSetupEntry 1 } ippmReportSetupMetricThreshold OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "An event is generated when the result of the measure exceeds the value of ippmReportSetupMetricThreshold. The threshold has the same unit as the metric. The metric unit is recorded in the object ippmMetricsUnit of this metric entry in the ippmMetricTable. " ::= { ippmReportSetupEntry 2 } ippmReportSetupEventsDurationThreshold OBJECT-TYPE SYNTAX Integer32 UNITS "Seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "An event is generated when the duration of a serie of results which are continuously over the metric threshold cross over the duration of the ippmReportSetupEventsDurationThreshold. " DEFVAL { 15 } ::= { ippmReportSetupEntry 3 } ippmReportSetupNMS OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-create STATUS current DESCRIPTION "The recipient of the report may be provided in the setup. By default the recipient of the report is the owner of the measure. Its addresses are recorded in the ippmOwnersTable. " ::= { ippmReportSetupEntry 4 } -- -- ippmReportTable -- Stephan Informational - Expires August 2002 [Page 55] Internet Draft IPPM MIB February 2002 ippmReportTable OBJECT-TYPE SYNTAX SEQUENCE OF IppmReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ippmReportTable logs the results of the reports. The results consist in a subset of the results of a measure as described in the report definition. The activation of a up and down filtering in the report definition limits the results logged to those corresponding to major events. Excepted these points the ippmReportTable is identical to the ippmHistoryTable. " ::= { ippmReportGroup 2 } ippmReportEntry OBJECT-TYPE SYNTAX IppmReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A report is a list of results of a measure. This sample is associated with the ippmReportSetupEntry which has set up the report. An ippmReportEntry entry is one of the results of an measure to report. The measure and the report definition are identified by the index members ippmMeasureOwner and ippmMeasureIndex. in the index : + ippmMeasureOwner and ippmMeasureIndex identify the ippmMeasureEntry and the ippmReportSetupEntry on whose behalf this report was created; + ippmMetricIndex identifies the ippmMetricEntry of the metric measured; + ippmReportTimeMark value is the absolute time when the value of the metric was measured. The ippmReportTimeMark value is the absolute time when the ippmHistoryValue was performed. IppmHistoryValue is the value of the metric measured at the time ippmReportTimeMark. " INDEX { ippmMeasureOwner, ippmMeasureIndex, ippmMetricIndex, ippmReportTimeMark } ::= { ippmReportTable 1 } IppmReportEntry ::= SEQUENCE { Stephan Informational - Expires August 2002 [Page 56] Internet Draft IPPM MIB February 2002 ippmReportTimeMark GMTDateAndTime, ippmReportValue Integer32 } ippmReportTimeMark OBJECT-TYPE SYNTAX GMTDateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The instant of the measure of the result." ::= { ippmReportEntry 1 } ippmReportValue OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value." ::= { ippmReportEntry 2 } -- -- ippmNotifications -- ippmSingletonAlarm NOTIFICATION-TYPE OBJECTS { ippmReportSetupDefinition, ippmReportSetupMetricThreshold, ippmMetricUnit, ippmHistoryValue } STATUS current DESCRIPTION "A notification sent because 2 contiguous results are on opposite sides of the metric threshold value. The index of the included ippmReportSetupMetricThreshold object identifies the ippmMeasureEntry and the ippmResultSetupEntry that specified the threshold. The notification contains the instances of the ippmReportValue object which raised the threshold. The ippmHistoryTimeMark of the index identifies the time the event occurs. " ::= { ippmNotifications 1 } Stephan Informational - Expires August 2002 [Page 57] Internet Draft IPPM MIB February 2002 ippmEventsDurationExceededAlarm NOTIFICATION-TYPE OBJECTS { ippmReportSetupDefinition, ippmReportSetupEventsDurationThreshold, ippmMetricUnit, ippmHistoryValue } STATUS current DESCRIPTION "A notification sent when the duration of contiguous raising ippmReportSetupMetricThreshold exceeds the ippmReportSetupEventsDurationThreshold value. The index of the included ippmReportSetupDefinition object identifies the ippmMeasureEntry and the ippmResultSetupEntry that specified the report. The notification contains the instances of the ippmReportValue objects saved in the ippmReportTable for this report. The ippmHistoryTimeMark of the index identifies the time theses measures results where performed. " ::= { ippmNotifications 2 } ippmCycleOfMeasureReport NOTIFICATION-TYPE OBJECTS { ippmReportSetupDefinition, ippmMetricUnit, ippmHistoryValue } STATUS current DESCRIPTION "A notification sent when a measure cycle completes. The index of the included ippmReportSetupDefinition object identifies the ippmMeasureEntry and the ippmResultSetupEntry that specified the report. The notification contains the instances of the ippmReportValue objects saved in the ippmReportTable for this measure cycle. The ippmHistoryTimeMark of the index identifies the time the measures where performed. " ::= { ippmNotifications 3 } ippmCompletedMeasureReport NOTIFICATION-TYPE OBJECTS { Stephan Informational - Expires August 2002 [Page 58] Internet Draft IPPM MIB February 2002 ippmReportSetupDefinition, ippmMetricUnit, ippmHistoryValue } STATUS current DESCRIPTION "A notification sent when a measure completes. The index of the included ippmReportSetupDefinition object identifies the ippmMeasureEntry and the ippmResultSetupEntry that specified the report. The notification contains the instances of the ippmReportValue objects saved in the ippmReportTable for this measure cycle. The ippmHistoryTimeMark of the index identifies the time the measures where performed. " ::= { ippmNotifications 4 } -- -- Compliance statements -- ippmCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which implement the IPPM MIB" MODULE -- this module MANDATORY-GROUPS { ippmSystemGroup, ippmMeasureGroup, ippmNetworkMeasureGroup, ippmHistoryGroup } ::= { ippmCompliances 1 } END 10. Security Considerations 10.1. Privacy The privacy concerns of network measurement are intrinsically limited by the active measurements. Unlike passive measurements, there can be no release of existing user data. 10.2. Measurement aspects Stephan Informational - Expires August 2002 [Page 59] Internet Draft IPPM MIB February 2002 Conducting Internet measurements raises both security and privacy concerns. This memo does not specify an implementation of the metrics, so it does not directly affect the security of the Internet nor of applications which run on the Internet. However, implementations of these metrics must be mindful of security and privacy concerns. There are two types of security concerns: potential harm caused by the measurements, and potential harm to the measurements. The measurements could cause harm because they are active, and inject packets into the network. The measurement parameters MUST be carefully selected so that the measurements inject trivial amounts of additional traffic into the networks they measure. If they inject "too much" traffic, they can skew the results of the measurement, and in extreme cases cause congestion and denial of service. The measurements themselves could be harmed by routers giving measurement traffic a different priority than "normal" traffic, or by an attacker injecting artificial measurement traffic. If routers can recognize measurement traffic and treat it separately, the measurements will not reflect actual user traffic. If an attacker injects artificial traffic that is accepted as legitimate, the loss rate will be artificially lowered. Therefore, the measurement methodologies SHOULD include appropriate techniques to reduce the probability measurement traffic can be distinguished from "normal" traffic. Authentication techniques, such as digital signatures, may be used where appropriate to guard against injected traffic attacks. 10.3. Management aspects There are a number of management objects defined in this MIB that have 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. SNMPv1 by itself is not a secure environment. 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. It is recommended that the implementors consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [18] and the View-based Access Control Model RFC 2575 [21] is recommended. Stephan Informational - Expires August 2002 [Page 60] Internet Draft IPPM MIB February 2002 It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, 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. 11. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2]Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998. [3] Mahdavi J. and V. Paxson, "IPPM Metrics for Measuring Connectivity", RFC 2678, September 1999. [4] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999. [5] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999. [6]Almes, G., Kalidindi, S. and M. Zekauskas, "A Round-trip Delay Metric for IPPM.", RFC 2681, September 1999. [7] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [8] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [9] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [10] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [11] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. Stephan Informational - Expires August 2002 [Page 61] Internet Draft IPPM MIB February 2002 [12] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [13] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [14] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [15] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [16] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [17]Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [18] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [19] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [20] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [21] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-basedAccess Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [22] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [23] Waldbusser, S., "Remote Network Monitoring MIB", STD 59, RFC 2819, Lucent Technologies, May 2000 [24] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2 using SMIv2", RFC 2021, International Network Services, January 1997. Stephan Informational - Expires August 2002 [Page 62] Internet Draft IPPM MIB February 2002 [25] Remote Network Monitoring MIB Protocol Identifier Reference. A. Bierman, C. Bucci, R. Iddon. RFC RFC2895 ,August 2000. [26] Remote Network Monitoring MIB Protocol Identifier Macros. A. Bierman, C. Bucci, R. Iddon. RFC RFC2896, August 2000. [27] E. Stephan, "IPPM MIB", draft-stephan-ippm-mib-01.txt, January 2002. 12. Acknowledgments A Kerbe. 13. Author's Addresses Emile STEPHAN France Telecom R & D 2 avenue Pierre Marzin F-22307 Lannion cedex Phone: (+ 33) 2 96 05 11 11 Email: emile.stephan@francetelecom.com Full Copyright Statement "Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Stephan Informational - Expires August 2002 [Page 63] Internet Draft IPPM MIB February 2002 Stephan Informational - Expires August 2002 [Page 64]