--- 1/draft-ietf-ippm-reporting-mib-00.txt 2006-02-04 23:46:21.000000000 +0100 +++ 2/draft-ietf-ippm-reporting-mib-01.txt 2006-02-04 23:46:21.000000000 +0100 @@ -1,16 +1,14 @@ Network Working Group E. Stephan/J. Jewitt - Internet Draft France Telecom R&D - -Document: draft-ietf-ippm-reporting-mib-00.txt June 20, 2002 + Document: draft-ietf-ippm-reporting-mib-01.txt November 2002 IPPM reporting 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]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other @@ -32,88 +30,106 @@ designed for use with network management protocols in TCP/IP-based internets. In particular, this MIB specifies the objects used for managing the results of the IPPM metrics measures, for pushing alarms, and for reporting the measures results. Table of Contents 1. Introduction................................................3 2. The IPPM Framework..........................................3 - 3. The SNMP Management Framework...............................3 - 4. Overview....................................................5 - 4.1. Textual Conventions.........................................6 - 4.2. Structure of the MIB.......................................10 - 4.3. Row identification in an application namespace.............12 - 5. IPPM-REPORTING-MIB conceptual presentation.................14 - 5.1. IPPM-REPORTING-MIB diagram.................................14 - 5.2. Conceptual programming interface...........................15 - 5.3. SNMP mapping...............................................15 - 6. Measurement architectures..................................16 - 6.1. Proxy architecture.........................................16 - 6.2. Reporting architecture.....................................17 - 6.3. Gateway architecture.......................................19 - 6.4. Security...................................................19 - 7. Reporting mode integration with the control and test - protocols................................................20 - 7.1. Integration................................................20 - 7.2. Setup of the measure.......................................20 - 7.3. Setup of the measurement report............................21 - 7.4. Writing the measurement results in the IPPM-REPORTING - MIB......................................................21 - 7.5. Report download and upload.................................22 - 7.6. Default value..............................................22 - 8. Definition.................................................22 - 9. Security Considerations....................................58 - 9.1. Privacy....................................................58 - 9.2. Measurement aspects........................................58 - 9.3. Management aspects.........................................58 - 10. References.................................................59 - 11. Acknowledgments............................................61 - 12. Author's Addresses.........................................61 - + 3. The IPPM Framework..........................................3 + 4. The SNMP Management Framework...............................4 + 5. Overview....................................................6 + 5.1. Textual Conventions.........................................7 + 5.2. Structure of the MIB........................................9 + 5.3. Row identification in an application namespace.............11 + 5.4. Relationship of IPPM MIB tables............................12 + 6. IPPM-REPORTING-MIB conceptual presentation.................16 + 6.1. IPPM-REPORTING-MIB diagram.................................16 + 6.2. Conceptual programming interface...........................17 + 6.3. SNMP mapping...............................................17 + 7. Measurement architectures..................................18 + 7.1. Proxy architecture.........................................18 + 7.2. Reporting architecture.....................................19 + 7.3. Gateway architecture.......................................21 + 7.4. Security...................................................21 + 8. Reporting mode integration with the control and test + protocols................................................22 + 8.1. Integration................................................22 + 8.2. Setup of the measure.......................................22 + 8.3. Setup of the measurement report............................23 + 8.4. Writing the measurement results in the IPPM-REPORTING + MIB......................................................23 + 8.5. Report download and upload.................................24 + 8.6. Default value..............................................24 + 9. Definition.................................................25 + 10. Security Considerations....................................58 + 10.1. Privacy.....................................................58 + 10.2. Measurement aspects.........................................58 + 10.3. Management aspects..........................................59 + 11. Document management........................................60 + 11.1. Open issues.................................................60 + 11.2. changes since release 00....................................60 + 12. References.................................................61 + 13. Acknowledgments............................................63 + 14. Authors Addresses..........................................63 1. Introduction - - This memo defines a MIB for managing the measures using the IP + This memo defines a MIB for managing measures based upon the IP performance metrics specified by the IPPM Working Group. - It specifies the objects to manage the results of the measure of - metrics standardized by IPPM Working Group. They are built on notions + The definition of objects in the IPPM MIB are built on notions introduced and discussed in the IPPM Framework document, RFC 2330 - [2]. + [ii]. - This memo defines a Management Information Base (MIB), and as such - it is intended to be respectful of the "Boilerplate for IETF MIBs" + This memo defines a Management Information Base (MIB), and as such 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-REPORTING-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. 2. The IPPM Framework + The IPPM Framework consists of 3 major components: + + A general framework for defining performance metrics, as 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 [iii]; The One-way + Delay Metric for IPPM, RFC 2679 [iv]; The One-way Packet Loss Metric + for IPPM, RFC 2680 [v]; The Round-trip Delay Metric for IPPM, RFC + 2681 [vi]. + + Emerging metrics that are being specified in respect of this + framework. + + 3. 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 that are being specified in respect of this framework. -3. The SNMP Management Framework + 4. 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, @@ -156,295 +172,194 @@ 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 + 5. Overview Although the number of measurement devices that implement IPPM metrics is growing, there is not currently any standardized - management interface to manage remotely the results of these metrics. - This memo defines a Management Information Base for managing the - results of the measures of IPPM metrics. + management interface to manage remotely the measurement of these + metrics. This memo defines a Management Information Base for managing + the measurement of IPPM metrics. To permit metrics to be referenced by other MIBs and other protocols, the IPPM WG has defined a registry of the current metrics and a - framework for the integration of future metrics in [IPPM metrics + framework for the integration of future metrics in the [IPPM metrics registry]. As the specification of new metrics is a continuous process, this memo defines a framework for the integration of the future - standardized metrics. To address future needs Specialized tables may + standardized metrics. To address future needs specialized tables may be created, while augmenting the definition of the ippmMeasureTable. - The MIB architecture is inspired by the RMON model [23],[24] which - specifies the MIB for the monitoring of a single point of measure. - The IPPM-REPORTING-MIB differs from this model in that IPPM metrics - measurement involves several points of measures and requires common - references for time and for measure identification. The IPPM- + The MIB architecture is inspired by the RMON model [xxiii],[xxiv] + which specifies the MIB for the monitoring of a single point of + measure. The IPPM-REPORTING-MIB differs from this model in that IPPM + metrics measurement involves several points of measure and requires + common references for time and for measure identification. The IPPM- REPORTING-MIB defines an absolute timeFilter. The IPPM-REPORTING-MIB introduces a framework where each application identifies its measures in an owner namespace. Using the namespace framework, an application may grant other owners access to its - measure results for aggregated metrics computation, reporting, or + measurement 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 lists + frameworks are suitable for performing measurements. The memo lists them, while also looking for a way to integrate them with the IPPM- - REPORTING-MIB . This section is informational, but helps to specify - the relationship among the test protocol, the control protocol and - IPPM-REPORTING-MIB. + REPORTING-MIB. This section is for informational purposes only, and + is intended to help to specify the relationship among the test + protocol, the control protocol and IPPM-REPORTING-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 results for the applications. Moreover, it may be used to - reduce the number of control frameworks. - - This MIB is intended to handle multiple concurrent access by SNMP - applications. They are not in constant contact with the measurement - devices. For this reason, this MIB allows continuous measures - collection and statistics computation. + control protocols and test protocols. It addresses the need to + provide access to results for the applications. Moreover, it may be + used to reduce the number of control frameworks. - The objects defined in this document are not intended for direct - manipulation.. + This MIB is intended to handle multiple concurrent sessions by SNMP + applications. However, the SNMP requests are not necessarily to be + handled explicitly by the measurement devices, but can be sent to + middleware performing an aggregation function. This allows for + continuous collection of measurements and statistics computation. -4.1. Textual Conventions + 5.1. Textual Conventions - Five types of data are introduced as a textual convention in this - MIB document: TypeP,GMTDateAndTime, GmtTimeFilter, - IppmReportDefinition and IppmStandardMetrics. + Four types of data are introduced as a textual convention in this + document: TypeP, GMTTimeStamp, IppmStandardMetrics and + IppmReportDefinition. -4.1.1. Packet of type P + 5.1.1. Packet of type P 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 are 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 capability to finely and unambiguously configure the type P of the packets, and the parameters of the protocol suites of the type P. - RMON2 introduced the concept of protocol identifiers. The RFC2895 - [25] specifies a macro for the definition of protocol identifier. The - RFC2896 [26] defines the protocol identifiers for different protocol - encapsulation trees. + RMON2 introduced the concept of protocol identifiers. RFC2895 [xxv] + specifies a macro for the definition of protocol identifier. The + RFC2896 [xxvi] defines the protocol identifiers for different + protocol encapsulation trees. The type P implementation relies on the MACRO PROTOCOL-IDENTIFIER defined for identifying protocol suites in RMON2. It is achieved by defining the TypeP as a new syntax in SMIv2 TEXTUAL-CONVENTION. -4.1.1.1. Internet addresses + 5.1.1.1. Internet addresses The section 14 of the IPPM framework defines (for the usual 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. + format of "Src" and "Dst" and their values. The type and value of + these addresses depend on the type P of the packet, IP version 4, V6, + IP in IP... Both participate in the completion of the packet + encoding. Examples: RFC2896 defines the protocol identifiers ip and ipip4. Should there be an 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, + 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. GMTDateAndTime - - This textual convention defines the date and time, and is represented -by the following format: year, month, day, hour, minutes, seconds, -fractions of second. - -The first part is human readable. The fields year, month, day, hour, -minutes are seconds are printable characters. - -The last field is the fraction of second. The fraction step is 250 -picoseconds. - -or example, 50 ms is 200000000 times 250 picosecond which correspond to -0BEBC200'H. 0001000201090200010501000BEBC200 represent 8:15pm, 10 -econds and 50 ms GMT on 19 February 2001 and is displayed as 01-02- -9,20:15:10, 200000000. - -4.1.3. GmtTimeFilter - -GmtTimeFilter uses an absolute reference of time, and 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 -that was created at the value of ippmTimeSysTimer. - -It is intended to provide an absolute timestamp index for the results of -measures. Typically for 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 -} - -LetÆs assume there are two measure rows in the measure table -(measureIndex == 1, measureIndex == 2) which produced results -asynchronously (e.g. made at Poisson intervals or sibling) and logged -them in the result table. - -LetÆs also assume that Measure 1 produced the result 34 at time -0001000201090200010501000BEBC200 GMT, while Measure 2 produced the value -54 10ms later at time 0001000201090200010501000E4E1C00 GMT, and that -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.0001000201090200010501000BEBC200 34 - resultCounts.2.0001000201090200010501000E4E1C00 54 - resultCounts.1.00010002010902000105010016A65700 65 - resultCounts.1.0001000201090200010501000E4E1C00 57 - resultCounts.2.0001000201090200010501001312D000 48 - resultCounts.2.0001000201090200010501001443FD00 53 - resultCounts.1.00010002010902000105010101312D00 49 - resultCounts.1.00010002010902000105010104C4B400 37 - -The following get-bulk explains how an NMS retrieves the results of the -measures. + 5.1.2. GMTTimeStamp -get-bulk(nonRptrs=1, maxReps=10, resultCounts.1); -returns: - resultCounts.1. 0001000201090200010501000BEBC200 == 34 - resultCounts.1.00010002010902000105010016A65700 == 65 - resultCounts.1.0001000201090200010501000E4E1C00 == 57 - resultCounts.1.00010002010902000105010101312D00 == 49 - resultCounts.1.00010002010902000105010104C4B400 == 37 - # return lexigraphically-next two MIB instances + This textual convention defines the time at which an event occurred. + It is very similar to the NTP timestamp format except that it + represents the time elapsed since January 1st, 2000 instead of + January 1st, 1900. -get-bulk(nonRptrs=0, maxReps=2, -resultCounts.1.0001000201090200010501000E4E1C00 , -resultCounts.2.0001000201090200010501000E4E1C00 ); -returns: - resultCounts.1.00010002010902000105010016A65700 == 65 - resultCounts.2.0001000201090200010501001312D000 == 48 - resultCounts.1.0001000201090200010501000E4E1C00 == 57 - resultCounts.2.0001000201090200010501001443FD00 == 53 + 5.1.3. IppmStandardMetrics -get-bulk(nonRptrs=0, maxReps=2, -resultCounts.1.00010002010902000105010104C4B400 , -resultCounts.2.00010002010902000105010104C4B400 ); -returns: - return lexigraphically-next two MIB instances - no 'resultTable' counter values at all are returned because -neither counter has been updated since the time -00010002010902000105010104C4B400 + Each standard metric is identified in the IPPM-METRICS-REGISTRY under + the node rfc in a chronological order. To permit several metrics to + be performed in a single measure there is an need to describe in a + bit string the metrics to be performed, granted... This textual + convention defines an octet string that gathered in a bit string a + sequence of bits. The bit order corresponds to the order of the + metrics identifiers in the registry. -4.1.4. Report definition + 5.1.4. Report definition - A report consists of sending or logging a subset of results of - measure. The elaboration of the report consists of actions to perform - on the measurement results. An action is performed either: + A report consists of sending, or logging, a subset of results of + measurements that have been taken over a period of time. The report + consists of actions that are taken on the measurement results. An + action is performed either: + For each result + On the results corresponding to a measurement cycle + On the results available at the measurement completion. To preserve the scalability of the whole measurement system, it limits: + The amount of data sent to the applications + The bandwidth consumption for uploading the result + The number of alarms sent to the applications + The amount of data saved in the point of measure - - The comparison of the measure results in a metric threshold that + The comparison of the measures results in a metric threshold that identifies particular measure values and times that directly impact service availability. The comparison of the duration of repeated events with a duration threshold identifies particular measure values and times that directly affect an SLA. The combination of IPPM metric results, threshold events, and event filtering provides a very efficient mechanism to report results, events, and alarms. A report is described using the TEXTUAL-CONVENTION IppmReportDefinition. The report setup must not dramatically increase the amount of data needed by the control protocol to setup a measure: - + A basic report is defined in the object - ippmReportSetupDefinition; - + More elaborate 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. + + A basic report is defined in the object ippmReportSetupDefinition; + + More elaborate reports are described using a metric threshold to + generate alarms and events. + + Pushing of alarms and reports requires a management station + address to which the data will be sent. + + SLA alarms are described using an events duration threshold. The TEXTUAL-CONVENTION IppmReportDefinition specifies the list of events and actions that are used to create a report. -4.1.5. IppmStandardMetrics - - The TEXTUAL-CONVENTION IppmStandardMetrics defines the standardized - IPPM metrics. - -4.2. Structure of the MIB + 5.2. Structure of the MIB The MIB is arranged as follow: - - ippmOwnersGroup - ippmSystemGroup - ippmMeasureGroup - ippmHistoryGroup - ippmNetworkMeasureGroup @@ -447,130 +362,260 @@ - ippmHistoryGroup - ippmNetworkMeasureGroup - ippmAggregatedMeasureGroup - ippmReportGroup - ippmNotifications -4.2.1. The ippmOwners Group - - This group controls access to the probe. + 5.2.1. The ippmOwners Group + This group identifies an owner, or group of owners that have access + to measurements on a probe. -4.2.2. The ippmSystem Group + 5.2.2. The ippmSystem Group This group consists of a set of parameters describing the clock - synchronization over the time. + synchronization at a particular point of measure over time. - This group is Critical to the implementation of the IPPM MIB. + This group is critical to the implementation of the IPPM MIB. Section 6.3. of the IPPM Framework states 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. The implementation of this group is mandatory + reliable statistics. The implementation of this group is mandatory, whether the time synchronization is automatic or not. -4.2.3. The ippmMeasureGroup + 5.2.3. The ippmMeasureGroup This group displays all the measures configured on the measurement - entity. It consists of the ippmMetricsTable, ippmMeasureTable. + entity. It consists of the ippmMetricsTable and ippmMeasureTable. The + ippmMeasureTable holds the common part of a measure, while the + specific parameters are handled in the corresponding auxiliary table + (ippmNetworkMeasure, ippmAggregatedMeasureTable...) . The measurement entity describes in the ippmMetricsTable of the SNMP - agent the local implementation of the standardized metrics. + agent the local implementation of the standardized metrics. All + standardized metrics should be displayed in this table, with the + capability object defining whether the metric is implemented or not. The control protocol registers a description of the existing measures - in the ippmMeasureTable and in the auxiliary measure tables. - - ippmMeasureTable holds the common part of a measure, while the - specific parameters are handled in the corresponding auxiliary table - (ippmNetworkMeasure, ippmAggregatedMeasureTableà) . + in the ippmMeasureTable and in the auxiliary measure tables. The + ippmMeasureTable table is read-create, but only allows for the + creation of "aggregated" measures when defined in conjunction with + the ippmAggregatedMeasureTable. Network measures are not allowed to + be created directly by the management entity, and as such the measure + table values for these measures should be display only. - The results of the measures are logged in the ippmHistoryTable. + The results of the measurements are logged in the ippmHistoryTable. -4.2.4. The ippmNetworkMeasure Group + 5.2.4. The ippmNetworkMeasure Group The control protocol registers a description of the existing network measures in the ippmNetworkMeasureTable and in the ippmMeasureTable. This group displays the network measures defined by the control protocol. The results are saved in the ippmHistoryTable. ippmNetworkMeasureTable is an auxiliary table of ippmMeasureTable, and is responsible for the configuration of the network measure. -4.2.5. The ippmAggregatedMeasure Group + 5.2.5. The ippmAggregatedMeasure Group ippmAggregatedMeasureTable is an auxiliary table of ippmMeasureTable, and is responsible for the consolidation of the results previously measured and saved in the ippmHistoryTable. The aggregated results are saved in the ippmHistoryTable and may be used for higher aggregated measures. -4.2.6. The report Group + 5.2.6. The Report Group - This group displays the existing reports of the measures. + This group displays the existing reports of the measures collected. ippmReportSetupTable is an auxiliary table of ippmMeasureTable, and is responsible for the configuration of the reports. The reports are saved in the ippmReportTable, or sent directly to the applications. -4.2.7. The notification Group + 5.2.7. The Notification Group The Notification group specifies a list of valid notifications. They are used to push alarms or reports to the applications. -4.3. Row identification in an application namespace + 5.3. Row identification in an application namespace The control protocol or the test protocol adds rows in the namespace of the corresponding measure. 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. + objects in the clause INDEX. An object instance identifier 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 identifies the instance, begins with - the owner value, the remaining value of the index fields may be + the owner value, the remaining values of the index fields may be chosen independently from one namespace to another. This allows the user to choose arbitrary values for the remaining fields of the INDEX clause without checking that the values of these - fields exist in the MIB tables. This allows the owner to use the same - values across MIB implementations. + fields exists in the MIB tables. This allows the owner to use the + same values across MIB implementations. Thus, it avoids polling to determine the next free index. Also, as a - consequence, s 2 applications will never find the same free index + consequence, two applications will never 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. - Measurements are requested by NMS applications. An instance of an - object managed by an NMS is identified by the NMS OwnerString and the - private index provided by the NMS. + Measurements are requested by management applications. An instance of + an object managed by a management station is identified by the + management station OwnerString and the private index provided by the + MS. - As the NMS manages its private range of indices, it simply chooses - 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 - of simply sending the same copy of the measure setup to the different + As the MS manages its private range of indices, it simply chooses 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 of + simply sending the same copy of the measure setup to the different points of measures involved. -5. IPPM-REPORTING-MIB conceptual presentation + 5.4. Relationship of IPPM MIB tables -5.1. IPPM-REPORTING-MIB diagram + There is inherently a relationship between various tables in the IPPM + Mib, and as such, the data integrity must be assured. This + relationship is depicted in the following examples. + + 5.4.1. Relationship between the Owners Table and the Measure Table + + The owners table contains the list of "owners" that can create and + activate remote IPPM measurements in an agent. As the table is + "Read/Create", these users and their associated + "access" rights on metric measurements can be directly configured. It + is recommended to make use of "view based access control" in order to + restrict access to this table. For example, the + master user "acme" may be given "write" privileges on the + ippmOwnersTable, whereas all others are restricted to "read" access. + The user "acme" can then setup the list of other users that have + access to measures. + + There must be at least 1 owner in the owners table. This owner may be + either setup by default by the IPPM agent, or configured as stated + above. + An owner may have multiple corresponding entries in the measure + table. Each entry in the measure table must be associated with one, + and only one, entry in the owners table. That is to say, that a + defined measure may NOT have multiple owners. + + Thus, we have a 1:N relationship between the owners table and the + measure table. + + +---------------------+ +---------------------------+ + + ippmOwnersTable + + ippmMeasureTable + + +---------------------+ 1:N +---------------------------+ + + OwnersOwner: "Acme" +--------------+ Measure Owner: "Acme" + + + ..... + + Measure Name:"OneWayDelay"+ + + "Foo" + +...... + + + + + Measure Owner: "Foo" + + +---------------------+ + Measure Name: "PacketLoss"+ + +---------------------------+ + + 5.4.2. Relationship between the Measure Table and the Network Measure + Table/Aggregated Measure Table + + The network measure table and the aggregated measure table can be + seen as logical "extensions" to the measure table. + The measure table contains information that is common to both types + of measurements. The information found in the Network Measure Table + and the Aggregated Measure Table is specific to each type of measure. + + As the network measure table is read-only, entries in this table must + be populated by the agent upon startup. + The agent could potentially read a database that contains network + measures configured by a 3rd party proprietary management system that + directly interacts with the points of measure. An entry can not be + created in the network measure table without creating the + corresponding entry in the measure table associated to the measure. + This also implies that the "owner" of the measure be defined in the + owners table. + + The aggregated measure table allows for an "owner" to create + aggregated measures (such as average, minimum, maximum) on existing + measures that are in the measure table. If an "owner" (A) wishes to + create an aggregated measure on a measure "owned" by another + "owner" (B), then "owner" (B) must grant "owner" (A) access to his + measures. This can be done in the resultsharing table. + + Even though the Measure Table is read-create, an "owner" should only + be able to create, or modify entries in the measure table that + correspond to aggregated measure types. Should an "owner" attempt to + update an entry in the measure table that corresponds to an entry + in the network measure table, than access should be denied. + + +---------------------------+ +----------------------------------+ + + ippmMeasureTable + + ippmNetworkMeasureTable + + +---------------------------+ +----------------------------------+ + + Measure Owner: "Acme" + + MeasureSrc: "Src1" + + + Measure Name:"OneWayDelay + ---+ MeasureDst: "Dst1" + + + ....... + + ........ + + + Measure Owner: "Foo" + + MeasureSrc: "Src2" + + + Measure Name: "PacketLoss"+ + MeasureDst: "Dst2" + + + + +----------------------------------+ + + + + + + +----------------------------------+ + + + + ippmAggregatedMeasureTable + + + + +----------------------------------+ + + Measure Owner: "Acme" + + AMHistoryOwner: "Foo" + + + Measure Name: "AvgPLoss" + ---+ AMHistoryMetric: "PacketLoss" + + +---------------------------+ +----------------------------------+ + + +---------------------------------+ +--------------------------+ + + ippmResultSharingTable + + ippmHistoryTable + + + + + (ex: with OWPL values) + + +---------------------------------+ +--------------------------+ + + SharingOwner: "Foo" + + Idx: Meas. Owner"Foo " + + + SharingMeasureOwner:"PacketLoss"+ + Measure Index: 1 + + + + + Metrix Indx: 12 + + + SharingGrantedOwner: "Acme" + + + + +---------------------------------+ + HistorySqceNdx: 1 + + + GMTTimeStampValue + + + Value: 5 + + +------------------------- + + + Idx: Meas. Owner "Foo" + + + Mesure Index: 1 + + + Metric Index: 12 + + + HistorySqceNdx: 2 + + + GMTTimeStampValue + + + Value: 15 + + + Idx: Meas. "Acme" + + + Measure Index: 3 + + + Metric Index: 14 + + + HistorySqceNdx: 1 + + + GMTTimeStampValue + + + Value: 10 + + +--------------------------+ + + As the aggregated measure table essentially "inherits" from the + measure table, one can not create an entry is this table without + first creating an entry in the measure table. Likewise, one can not + delete an entry in the measure table without first deleting the + corresponding row in the aggregated measure table. This logic ensures + that there are no "orphaned" table entries in the aggregated measure + table. + + 6. IPPM-REPORTING-MIB conceptual presentation + + 6.1. IPPM-REPORTING-MIB diagram Conceptual view of objects configured using the IPPM-REPORTING-MIB +--------------------------------------------------------+ | IPPM-REPORTING-MIB entity | | | | +---------------------+ +-------------------+ | | | | | | | | | Measure scheduler | | Result storage | | | | | | | | @@ -605,75 +650,75 @@ |GetMeasureResults | |GetMeasureMetricResults | |-------------------| |------------------------| | | | owner | | owner | | privateNdx | | privateNdx | | metric | +-------------------+ +------------------------+ The managed objects of the IPPM-REPORTING-MIB are the measures and the results. -5.2. Conceptual programming interface + 6.2. Conceptual programming interface This section describes a conceptual programming interface for the integration of the IPPM-REPORTING-MIB in a point of measure. -5.2.1. Measure control + 6.2.1. Measure control A measure is created/deleted/suspended through the ControlMeasure() call. -5.2.2. Result log + 6.2.2. Result log A result of a measure is created in the IPPM-REPORTING-MIB History table using a CreateResult() call. Results belonging to a measure are managed according to the setup of the measure. -5.2.3. Reporting + 6.2.3. Reporting Results are reported using the method GetResult(), GetMeasureMetricResults() and GetMeasureResults() respectively to get a singleton result, the singleton result of a metric measure, and finally to get the singleton result of a measure. -5.2.4. Logical calls + 6.2.4. Logical calls Objects are managed using 5 main primitives: controlMeasure(); CreateResult(); GetResult(); GetMeasureMetricResults(); GetMeasureResults(). -5.3. SNMP mapping + 6.3. SNMP mapping ControlMeasure() corresponds to a SNMP set-request on a conceptual row of ippmMeasureEntry and on a conceptual row of ippmNetworkMeasureEntry. CreateResult() is a internal interface for adding measure results in the ippmHistoryTable. GetResult() corresponds to an SNMP get-request on a result. GetMeasureMetricResults() corresponds to a SNMP walk on the results of a metric measure subtree. GetMeasureResults() corresponds to a SNMP walk on the results of a measure subtree. -6. Measurement architectures + 7. Measurement architectures There are four main measurement architectures. -6.1. Proxy architecture + 7.1. Proxy architecture +----+ +----+ |NMS1| |NMS2| +----+ +----+ ^ ^ | | +----------+ +----------+ | | SNMP or Sibling | | @@ -705,25 +750,25 @@ nor on the test protocol. The entities involved in the measurement do not need to implement the IPPM-REPORTING-MIB nor SNMP. This mode allows for lightweight implementation in the point of measure, and also for heterogeneous control protocols to coexist. Finally, the proxy is a checkpoint where measurement activity may be logged, and where access to measurement setups may be tightly controlled. Thus, it provides a reliable architecture to manage the security of a measurement system. -6.2. Reporting architecture + 7.2. Reporting architecture - In this architecture the SNMP protocol is only used to read the - results of the measurements in the IPPM-REPORTING-MIB History Table, - and also to inform the NMS that an event has occurred. + In this architecture the SNMP protocol is only used to read the results + of the measurements in the IPPM-REPORTING-MIB History Table, and also to + inform the NMS that an event has occurred. +----+ +----+ |NMS1| |NMS2| +----+ +----+ ^ ^ ^ ^ | | | | SNMP| SNMP| | | | | | | | | | OWDP | OWDP @@ -765,21 +811,21 @@ table. In this mode, it is recommended to use an SNMPv2 Inform PDU to send the result because it ensures that the entire block of the result is received. There is no control using SNMP Trap PDU. Also, in this mode, it is recommended to implement the IPPM-REPORTING- MIB Measure table in read only in order to allow an NMS to read the status of their measures. -6.3. Gateway architecture + 7.3. Gateway architecture The gateway architecture combines the proxy mode and the reporting mode. +-------+ +------+ | NMS1 | | NMS2 | +-------+ +------+ ^ ^ | | SNMP SNMP | | @@ -806,39 +852,39 @@ +-------------+---------+ +--------+-------------+ | IPPM- | Packets | |Packets | IPPM | |REPORTING-MIB| Sender | |Receiver|REPORTING-MIB| | agent | |-OWDP-Test->| | agent | +-------------+---------+ +--------+-------------+ The NMS measurement queries are registered in the IPPM-REPORTING-MIB scheduler and performed by the control and the test protocol. The NMS directly consults the result in the corresponding points of measure. -6.4. Security + 7.4. Security The proxy mode provides flexibility and control of the access to the points of measure, while allowing 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 domains. The reporting mode has 2 security domains: +The control of the measurement setups relies on the control and the test protocol security mechanisms. + The control of access to the results depends on the SNMP security mechanisms. The gateway mode security relies on the security of the proxy mode and of the reporting mode. -7. Reporting mode integration with the control and test protocols + 8. Reporting mode integration with the control and test protocols The IPPM-REPORTING-MIB standardizes the parameters that: + Define the configuration of the IPPM metrics measures; + Define the format of the results of the measure; + Define the report of the IPPM metric measures results. It introduces the concept of owner namespace to allow for fast configuration and reporting across multiple points of measurement. @@ -849,59 +895,59 @@ negotiation between the NMS and the points of measure before activating the measure. A measure is primarily defined by its identifier, the metrics to measure, the description of the end point 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. -7.1. Integration + 8.1. Integration The control protocol, test protocol and the IPPM-REPORTING-MIB share the same semantic. The integration of the IPPM-REPORTING-MIB, and the test and control protocols, relies on the use of the conceptual programming interface described in section 6. It consists in pushing the measure setup/teardown parameters and the result values from the measurement software to the IPPM-REPORTING-MIB agent. -7.2. Setup of the measure + 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 provides the parameters of the measure to manage, may be the control protocol of the test protocol. Different frameworks may be used to setup a measure. -7.2.1. Synchronous setup + 8.2.1. Synchronous setup The control protocol sets up the measure both in the sender and the receiver before the measurement. -7.2.2. Asynchronous setup + 8.2.2. Asynchronous setup The control protocol sets up the measure only in the sender. In this case, the receiver has a service already activated (or pending )for the typeP of the measurement. 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, it must not be used for performing metrics measurement. -7.3. Setup of the measurement report + 8.3. Setup of the measurement report 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 an 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: @@ -912,97 +958,103 @@ 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 raises 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 are sent at each measure cycle or when the measure completes. -7.4. Writing the measurement results in the IPPM-REPORTING-MIB + 8.4. Writing the measurement results in the IPPM-REPORTING-MIB Results have to be written by the measurement task in the agent implementing the IPPM MIB. Adding the results of a measurement consists in the transfer of the result from the measurement software to the agent. The protocol that provides the result may be the control protocol, or the test protocol. Writing a result is done using the CreateResult(). -7.5. Report download and upload + 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. -7.6. Default value + 8.6. Default value The default values correspond to Ipv4 best effort. -8. Definition + 9. Definition IPPM-REPORTING-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, NOTIFICATION-TYPE, OBJECT-TYPE, Integer32, - Counter32, - experimental + Counter32 FROM SNMPv2-SMI + ippm + FROM IPPM-REGISTRY OwnerString FROM RMON-MIB - protocolDir - FROM RMON2-MIB - DisplayString, + InetAddressType, + InetAddress + FROM INET-ADDRESS-MIB + SnmpAdminString + FROM SNMP-FRAMEWORK-MIB TimeStamp, - DateAndTime, TruthValue, RowStatus, StorageType, TEXTUAL-CONVENTION FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF; ippmReportingMib MODULE-IDENTITY - LAST-UPDATED "200202011200Z" -- March 17, 2002 + LAST-UPDATED "200203171200Z" -- March 17, 2002 ORGANIZATION "France Telecom - R&D" CONTACT-INFO "Mail : 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 Jessie Jewitt - France Telecom - - R&D + France Telecom - R&D 801 Gateway Blvd. Suit 500 South San Francisco, CA 94080 Tel : 1 650 875-1524 E-mail : jessie.jewitt@rd.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 specifies the objects used for managing - the results of the IPPM metrics measurements, alarms and reporting - the measures results. + " 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 specifies + the objects used for managing the results of the IPPM metrics measurements, alarms and + reporting the measures results. " + + REVISION "200210181200Z" -- 18 October 2002 + DESCRIPTION + "General cleanup + Change 5 tables to read write" + ::= { ippm 2 } -- -- TEXTUAL-CONVENTION -- TimeUnit ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A list of time units." SYNTAX INTEGER { @@ -1011,984 +1063,982 @@ 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 "d-d-d,d:d:d,4d" + IppmStandardMetrics ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION - "A date-time specification. + " Each standard metric is identified in the IPPM-METRICS- + REGISTRY under the node rfc in a chronological order. To permit + several metrics to be performed in a single measure there is an need + to describe in a bit string the metrics to be performed, granted... + This textual convention defines an octet string that gathered in a + bit string a sequence of bits. The bit order corresponds to the order + of the metrics identifiers in the registry. + The first bit of the string is not used. + + Example: + One-way-Delay(6) is identified as the leaf number 6 of the node rfc of the + registry. One-way-Packet-Loss(12) is identified as the leaf number 12 of the node + rfc of the registry. A network measure performing both One-way-Delay(6) and One- + way-Packet-Loss(12) will be described as '0000001000001000'b, '0208'B. - field octets contents range - ----- ------ -------- ----- - 1 1-2 year* 0..99 - 2 3-4 month 1..12 - 3 5-6 day 1..31 - 4 7-8 hour 0..23 - 5 9-10 minutes 0..59 - 6 11-12 seconds 0..59 - 7 13-16 250 picoseconds 0..2^32-1 " - SYNTAX OCTET STRING (SIZE (16)) + SYNTAX OCTET STRING - GmtTimeFilter ::= TEXTUAL-CONVENTION + GMTTimeStamp ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION - "GmtTimeFilter TC is inspired by the TimeFilter defined - in RMON2. The reference for the time of TimeFilter is - the local value of sysUptime, while GmtTimeFilter uses - an absolute reference of time.Æ Æ + "The value of the ippmSystemTime object at which a specific occurrence + happened. The specific occurrence must be defined in the description of any object + defined using this type. - SYNTAX GMTDateAndTime + field octets contents range + ----- ------ -------- ----- + 1 1-4 second since 1 Jan 2000 0H00* 0..2^31 - 1 + 2 5-8 fractional part of the second* 0..2^32 - 1 + * the value is in network-byte order + + The timestamp format is directly inspired from the NTP timestamp format. + It differs because it counts the second since 1 Jan 2000 0H00 instead of 1 Jan 1900 + 0H00. The most significant bit of the part that represents the second is reserved. It + will wrap in year 2068 (The NTP timestamp will wrap in year 2036). + + This bit is set to indicate if the fractional part of the second contains a precision + field and a synchronization field as initially proposed in the OWAMP draft. + + When this bit is not set the resolution is maximal. + + The maximal resolution is close to 250 picoseconds. + + The precision of the timestamp must be provided in another field. + " + SYNTAX OCTET STRING (SIZE (8)) TypeP ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d." STATUS current DESCRIPTION - "This textual convention is used to describe the - protocol encapsulation list of a packet, and is used as - the value of the SYNTAX clause for the type of the Src - and Dst of an IPPM measure. The RFC2895 specifies a - macro for the definition of protocol identifiers while - its companion document, the RFC2896 defines a set of - protocol identifiers. + "This textual convention is used to describe the protocol encapsulation list of a + packet, and is used as the value of the SYNTAX clause for the type of the Src and Dst + of an IPPM measure. The RFC2895 specifies a macro for the definition of protocol + identifiers while its companion document, the RFC2896 defines a set of protocol + identifiers. - Notes: An IPPM TypeP does not differ from RMON2 Protocol - 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. + Notes: An IPPM TypeP does not differ from RMON2 Protocol 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)." + '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 describing the - report resulting from a measurement. By default, all the results of a - measure belong to the report of this measure. + "IppmReportDefinition is intended to be used for describing the report + resulting from a measurement. By default, all the results of a measure belong to the + report of this measure. - The first step of the report definition sets up triggers on the - value of the measure, and on the distribution over time of the events - generated by these triggers. + The first step of the report definition sets up triggers on the value of the + measure, and on the distribution over time of the events generated by these triggers. - The resulting measures corresponding to an event are reported - periodically, or sent in alarms as soon as the event occurs. + The resulting measures corresponding to an event are reported periodically, + or sent in alarms as soon as the event occurs. The end of the description describes housekeeping tasks. - An action if performed if the corresponding bit is set to 1. + An action is performed if the corresponding bit is set to 1. onSingleton(1): - The actions are performed each time a new result of the - measure occurs. + 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. + 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. + The actions are performed on the results of the measure at the end of the measure. reportOnlyUptoDownMetricResults(4): - Report the contiguous results that are on opposite sides - of the metric threshold. + Report the contiguous results that are on opposite sides of the metric threshold. reportOnlyExceededEventsDuration(5): - Report the current result of a series of contiguous - results that exceed the metric threshold when the - duration of the series is over the events duration - threshold seconds. + Report the current result of a series of contiguous results that exceed the metric + threshold when the duration of the series 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. + Remove all the results corresponding to this measure from the ippmHistoryTable. clearReport(13): - Remove all the results corresponding to this measure - from the ippmReportTable. + Remove all the results corresponding to this measure from the ippmReportTable. " SYNTAX BITS { none(0), -- reserved 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 + -- IPPM Mib objects definitions + + ippmCompliances OBJECT IDENTIFIER ::= { ippmReportingMib 2 } + ippmSystemGroup OBJECT IDENTIFIER ::= { ippmReportingMib 3 } + ippmOwnersGroup OBJECT IDENTIFIER ::= { ippmReportingMib 4 } + ippmMeasureGroup OBJECT IDENTIFIER ::= { ippmReportingMib 5 } + ippmHistoryGroup OBJECT IDENTIFIER ::= { ippmReportingMib 6 } + ippmNetworkMeasureGroup OBJECT IDENTIFIER ::= { ippmReportingMib 7 } + ippmAggregatedMeasureGroup OBJECT IDENTIFIER ::= { ippmReportingMib 8 } + ippmReportGroup OBJECT IDENTIFIER ::= { ippmReportingMib 9 } + ippmNotifications OBJECT IDENTIFIER ::= { ippmReportingMib 10 } + + -- + -- ippmSystemGroup + -- + -- + + ippmSystemTime OBJECT-TYPE + SYNTAX GMTTimeStamp + MAX-ACCESS read-only 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 identifier. + "The current time of the measurement system." + ::= { ippmSystemGroup 1 } + + ippmSystemSynchronizationType OBJECT-TYPE + SYNTAX INTEGER { + other(0), + ntp(1), + gps(2), + cdma(4) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "ippmSystemSynchronizationType describes the mechanism + used to synchronize the system. + + Other(0) + The synchronization process must be defined + in the ippmSystemSynchonizationDescription. + + Ntp(1) + The system is synchronized using the network + time protocol. The NTP synchronization must be described + in the ippmSystemSynchonizationDescription. + + Gps (2) + The system is synchronized using the GPS clocks. + + Cdma(4) + The system is synchronized using the CDMA clocks. " - 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) + ::= { ippmSystemGroup 2 } + + ippmSystemSynchronizationDescription OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The description of the synchronization process." + ::= { ippmSystemGroup 3 } + + 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 the picosecond. 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. So its resolution + is 100000 picosecond and the value of ippmSystemClockResolution is 100000." + ::= { ippmSystemGroup 4 } + + ippmSystemCurrentSynchronization OBJECT-TYPE + SYNTAX Integer32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The index on the last synchronization event in the ippmSynchronizationTable." + + ::= { ippmSystemGroup 5 } + + ippmSynchronizationTable OBJECT-TYPE + SYNTAX SEQUENCE OF IppmSynchronizationEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table registers the event related to the synchronization of the point of + measure. Each event is described in an ippmSynchronizationEntry. + + ippmSynchronizationTable is mandatory. + ippmSynchronizationTable content is read only. + " + ::= { ippmMeasureGroup 6 } + + ippmSynchronizationEntry OBJECT-TYPE + SYNTAX IppmSynchronizationEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry describes a modification of the synchronization status. " + INDEX { ippmSynchronizationIndex } + ::= { ippmSynchronizationTable 1 } + + IppmSynchronizationEntry ::= + SEQUENCE { + ippmSynchronizationIndex Integer32, + ippmSynchronizationTime GMTTimeStamp, + ippmSynchronizationStratum Integer32 } - -- IPPM Mib objects definitions - ippmCompliances OBJECT IDENTIFIER ::= { ippmMib 2 } - ippmOwnersGroup OBJECT IDENTIFIER ::= { ippmMib 3 } - 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 } + ippmSynchronizationIndex OBJECT-TYPE + SYNTAX Integer32 (1..1000) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An index that identifies the synchronization events in chronological order." + ::= { ippmSynchronizationEntry 1 } + + ippmSynchronizationTime OBJECT-TYPE + SYNTAX GMTTimeStamp + + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The time when the synchronization event occurs." + ::= { ippmSynchronizationEntry 2 } + + ippmSynchronizationStratum OBJECT-TYPE + SYNTAX Integer32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The stratum level of the clock computed when the synchronization event occurs." + ::= { ippmSynchronizationEntry 3 } + + ippmPointOfMeasureTable OBJECT-TYPE + SYNTAX SEQUENCE OF IppmPointOfMeasureEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + " A lookup table that identifies the management software in charge of the point of + measures. + + ippmPointOfMeasureTable content is read only. It means that the measurement software + handles the table internally + + ippmPointOfMeasureTable is mandatory. + " + + ::= { ippmSystemGroup 6 } + + ippmPointOfMeasureEntry OBJECT-TYPE + SYNTAX IppmPointOfMeasureEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + " An entry may be the management address of a middleware in charge of the management + of a set of probes. It may the management address of a probe that contains several + line cards. + + An entry describes the capability of a point of measure. The description may make the + use of wildcards to define multiple capabilities. + " + INDEX { ippmPointOfMeasureIndex } + ::= { ippmPointOfMeasureTable 1 } + + IppmPointOfMeasureEntry ::= + SEQUENCE { + ippmPointOfMeasureIndex Integer32, + ippmPointOfMeasureMgmtAddress SnmpAdminString, + ippmPointOfMeasureTypePAddress TypeP, + ippmPointOfMeasureAddress OCTET STRING + } + ippmPointOfMeasureIndex OBJECT-TYPE + SYNTAX Integer32 (1.. 65535) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The index of the entry." + ::= { ippmPointOfMeasureEntry 1 } + + ippmPointOfMeasureMgmtAddress OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-only + STATUS current + DESCRIPTION + " + The management software in charge of this point of measure." + ::= { ippmPointOfMeasureEntry 2 } + + ippmPointOfMeasureTypePAddress OBJECT-TYPE + SYNTAX TypeP + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Defines the type P of the address of the point of measure." + DEFVAL { '04000080001000'H } -- ->ip: 4.0.0.8.0.1.0 + ::= { ippmPointOfMeasureEntry 3 } + + ippmPointOfMeasureAddress OBJECT-TYPE + SYNTAX OCTET STRING + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Specifies the address of the point of measure. + + It is represented as an octet string with specific semantics and length as identified + by the ippmPointOfMeasureTypePAddress. + + For example, if the ippmPointOfMeasureTypePAddress 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 + ::= { ippmPointOfMeasureEntry 4} -- -- ippmOwnersGroup -- -- The ippmOwnersGroup objects are responsible for managing -- the owners access to the measurements. -- -- ippmOwnersTable OBJECT-TYPE SYNTAX SEQUENCE OF IppmOwnersEntry 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 ippmOwnersTable. + "A management entity wishing to create and activate remote Ippm measurements in an + agent must previously be registered in the ippmOwnersTable. - ippmOwnersTable content is read only. + ippmOwnersTable content is read-create. - ippmOwnersTable is mandatory. It contains at least the - owner 'monitor'. + ippmOwnersTable contains at least the owner 'monitor'. + + ippmOwnersTable is mandatory, excepted if the VACM framework is used. " ::= { ippmOwnersGroup 1 } ippmOwnersEntry OBJECT-TYPE SYNTAX IppmOwnersEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION - "The description of the resources the agent granted to a - SNMP application. + "The description of the resources granted to an SNMP application. - For example, an instance of ippmOwnersOwner with an - OwnerString 'acme', which represents the 14th owner - created in ippmOwnersTable would be named + For example, an instance of ippmOwnersOwner with an OwnerString 'acme', which + represents the 14th owner created in ippmOwnersTable would be named ippmOwnersEntryOwner.14. Notes: - The ippmOwnersIndex value is a local index managed - directly by the agent. It is not used in anyway in the - other IPPM tables." + The ippmOwnersIndex value is a local index managed directly by the agent. The + management application must poll to get the next available index value. + It is not used in anyway in the other IPPM tables." INDEX { ippmOwnersIndex } ::= { ippmOwnersTable 1 } IppmOwnersEntry ::= SEQUENCE { - ippmOwnersOwner OwnerString, + ippmOwnersOwner SnmpAdminString, ippmOwnersIndex Integer32, ippmOwnersGrantedMetrics IppmStandardMetrics, ippmOwnersGrantedRules BITS, - ippmOwnersIpAddress DisplayString, - ippmOwnersEmail DisplayString, - ippmOwnersSMS DisplayString, + ippmOwnersIpAddress InetAddressType, + ippmOwnersEmail SnmpAdminString, + ippmOwnersSMS SnmpAdminString, ippmOwnersStatus OwnerString } ippmOwnersIndex OBJECT-TYPE SYNTAX Integer32 (1.. 65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION - "An arbitrary index that identifies an entry in this - table" + "An arbitrary index that identifies an entry in this table" ::= { ippmOwnersEntry 1 } - ippmOwnersOwner OBJECT-TYPE - SYNTAX OwnerString - MAX-ACCESS read-only + SYNTAX SnmpAdminString + MAX-ACCESS read-create STATUS current DESCRIPTION "The owner described by this entry." ::= { ippmOwnersEntry 2 } ippmOwnersGrantedMetrics OBJECT-TYPE SYNTAX IppmStandardMetrics - MAX-ACCESS read-only + MAX-ACCESS read-create STATUS current DESCRIPTION " Defines the metrics granted to an owner." ::= { ippmOwnersEntry 3 } ippmOwnersGrantedRules OBJECT-TYPE SYNTAX BITS { all(0), readonly(1), permanent(2), - sender(2), - receive(3), - report(4), - alarm(5) + sender(3), + receive(4), + report(5), + alarm(6) } - MAX-ACCESS read-only + MAX-ACCESS read-create STATUS current DESCRIPTION - "Defines the rules this owner may act on in the current IPPM MIB - instance. + "Defines the rules this owner may act on in the current IPPM MIB instance. all(0): The owner is granted all the rules. readonly(1): - The measures (not only the metrics) that this owner may - access 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. + The measures (not only the metrics) that this owner may access 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) that this owner may - access 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 whose access is read-write. - Typically this allows the owner to suspend the measures, - to change the beginning and end of the measures. + The measures (not only the metrics) that this owner may access 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 whose access is read-write. + Typically this allows the owner to suspend the measures, to change the beginning and + end of the measures. sender(3): - The owner may only activate measures for those 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. + The owner may only activate measures for those 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 those 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. + + The owner may only activate measures for those 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. + 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. + 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 } ::= { ippmOwnersEntry 4 } ippmOwnersIpAddress OBJECT-TYPE - SYNTAX DisplayString - MAX-ACCESS read-only + SYNTAX InetAddressType + 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." + "The IP address of the management entity corresponding to this + owner. The address is human readable and is represented using the dot format." ::= { ippmOwnersEntry 5 } ippmOwnersEmail OBJECT-TYPE - SYNTAX DisplayString - MAX-ACCESS read-only + SYNTAX SnmpAdminString + MAX-ACCESS read-create STATUS current DESCRIPTION - "The email address of the NMS corresponding to this + "The email address of the management entity corresponding to this owner." ::= { ippmOwnersEntry 6 } ippmOwnersSMS OBJECT-TYPE - SYNTAX DisplayString - MAX-ACCESS read-only + SYNTAX SnmpAdminString + MAX-ACCESS read-create STATUS current DESCRIPTION - "The SMS phone number of the NMS corresponding to this - owner." + "The SMS phone number of the management entity corresponding to + this owner." ::= { ippmOwnersEntry 7 } ippmOwnersStatus OBJECT-TYPE SYNTAX RowStatus - MAX-ACCESS read-only + MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this table entry." ::= { ippmOwnersEntry 8 } -- -- ippmResultSharingTable -- ippmResultSharingTable OBJECT-TYPE SYNTAX SEQUENCE OF IppmResultSharingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION - " The ippmResultSharingTable controls the access of an - owner to the measure results of other owners. An owner - may grant another access to read the result of its - measure. + " The ippmResultSharingTable controls the access of an owner to the measure results of + other owners. An owner may grant another access to read the result of its measure. - Entries may exist in ippmResultSharingTable even if 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. + Entries may exist in ippmResultSharingTable even if 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. - IppmResultSharingTable content is read only. + IppmResultSharingTable content is read-create. - If this table is not implemented then the owner has only - access to its measure results." + If this table is not implemented then the owner has only access to its own measurement + 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. + "An entry allows an owner to read the results of a measure owned by another owner. It permits 2 typical usages: 1) Creating derived measurements on these results - 2) Reading the results from a remote NMS. + 2) Reading the results from a remote management station. - Example: if acme.12 is a One-way-Delay(6) measure - Acme may allow Peter to make derived metrics - on the results of this measure. + Example: if acme.12 is a One-way-Delay(6) measure, Acme may allow 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-only + MAX-ACCESS not-accessible STATUS current DESCRIPTION - " The owner of this result control entry. Typically the - owner who created this conceptual row." + " The owner of this result control entry. Typically the owner who + created this conceptual row." ::= { ippmResultSharingEntry 1 } ippmResultSharingIndex OBJECT-TYPE SYNTAX Integer32 (1.. 65535) - MAX-ACCESS read-only + MAX-ACCESS not-accessible 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." + " 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-only + MAX-ACCESS read-create STATUS current DESCRIPTION "The owner of the measure to be shared. The couple - ippmResultSharingMeasureOwner, ippmResultSharingMeasureIndex - identifies absolutely a measure" + ippmResultSharingMeasureOwner, ippmResultSharingMeasureIndex identifies absolutely a + measure" ::= { ippmResultSharingEntry 3 } ippmResultSharingMeasureIndex OBJECT-TYPE SYNTAX Integer32 (1.. 65535) - MAX-ACCESS read-only + 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 + MAX-ACCESS read-create STATUS current DESCRIPTION - "The owner who is granted access to the result of the - measure described by the couple ippmResultSharingMeasureOwner, - ippmResultSharingMeasureIndex." + "The owner who is granted access to the result of the measure + described by the couple ippmResultSharingMeasureOwner, ippmResultSharingMeasureIndex." ::= { ippmResultSharingEntry 5 } ippmResultSharingStatus OBJECT-TYPE SYNTAX RowStatus - MAX-ACCESS read-only + MAX-ACCESS read-create STATUS current DESCRIPTION - " The status of this table entry. Once the entry status - is set to active." + " The status of this table entry. Once the entry status is set to + active." ::= { ippmResultSharingEntry 6 } -- - -- ippmSystemGroup - -- - -- - - 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 synchronize the system. - - Other(0) - The synchronization process must be defined - in the ippmSystemSynchonizationDescription. - - Ntp(1) - The system is synchronized using the network - time protocol. The NTP synchronization must be described - in the ippmSystemSynchonizationDescription. - - Gps (2) - The system is synchronized using the GPS clocks. - - Cdma(4) - The system is synchronized 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 } - - 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 the last synchronization of the clock - occured. The last synchronization must be set even if - the synchronization 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 computed even if the synchronization 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 computed even if the - synchronization is not automatic." - ::= { ippmSystemGroup 7 } - - ippmSystemPrevClockAccuracy OBJECT-TYPE - SYNTAX Integer32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The previous accuracy of the clock measured. The - ippmSystemPrevClockAccuracy must be computed even if the - synchronization 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 } - ippmSystemSynchonizationOperStatus OBJECT-TYPE - SYNTAX INTEGER { - other(0), - unsynchronized(1), - initializing(2), - synchronized(4) - } - MAX-ACCESS read-only - STATUS current - DESCRIPTION - " ippmSystemSynchonizationOperStatus describes the - operational status of the clock synchronization. - - Other(0) - The status of the synchronization is unknown. - - unsynchronized(1) - The system is not synchronized. - - initializing(2) - The system is receiving synchronization - information but is not yet synchronized. - - synchronized(4) - The system is synchronized. - " - ::= { ippmSystemGroup 10 } - - -- -- -- -- ippmMeasureGroup -- -- -- - ippmMetricTable OBJECT-TYPE - SYNTAX SEQUENCE OF IppmMetricEntry + ippmMetricsTable OBJECT-TYPE + SYNTAX SEQUENCE OF IppmMetricsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION - "This table describes the current implementation and 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 measure software handles - the table internally. - - ippmMetricTable is mandatory. - ippmMetricTable content is read only. + "This table describes the current implementation and is mandatory. Each IPPM + standardized metric identified in the IPPM-METRICS-REGISTRY must be described in the + table. The index of the metric corresponds to the node number of the metric in the rfc + subtree of the IPPM-METRICS-REGISTRY. That provides a metric with the same index value + in any IPPM REPORTING MIB implementations. + ippmMetricsTable is mandatory. + ippmMetricsTable content is read only. " ::= { ippmMeasureGroup 1 } - ippmMetricEntry OBJECT-TYPE - SYNTAX IppmMetricEntry + ippmMetricsEntry OBJECT-TYPE + SYNTAX IppmMetricsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION - "An entry describes the static capabilities of a metric - implementation." - INDEX { ippmMetricIndex } - ::= { ippmMetricTable 1 } + "An entry describes the static capabilities of a metric implementation." + INDEX { ippmMetricsIndex } + ::= { ippmMetricsTable 1 } - IppmMetricEntry ::= + IppmMetricsEntry ::= SEQUENCE { - ippmMetricIndex Integer32, - ippmMetricCapabilities INTEGER, + ippmMetricsIndex Integer32, + ippmMetricsCapabilities INTEGER, ippmMetricUnit INTEGER, - ippmMetricDescription DisplayString, - ippmMetricMaxHistorySize Integer32 + ippmMetricsDescription SnmpAdminString, + ippmMetricsMaxHistorySize Integer32 } - ippmMetricIndex OBJECT-TYPE + ippmMetricsIndex OBJECT-TYPE SYNTAX Integer32 (1.. 65535) - MAX-ACCESS read-only + MAX-ACCESS not-accessible 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-REPORTING-MIB metrics registry + "ippmMetricsIndex defines an unambiguous index for each standardized metric. Its value + is the value of the node of the metric in the IPPM-REPORTING-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 calculated between the - IPPM-REPORTING-MIB entities involved in the measure. + Each metric registered in the standard registry must be present in this table. + This index is used to identify the metric calculated between the IPPM-REPORTING-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 } + The index of the metric onewayPacketLossAverage which is registered as + ippmMib.metrics.rfc.onewayPacketLossAverage will always have the value 14." + ::= { ippmMetricsEntry 1 } - ippmMetricCapabilities OBJECT-TYPE + ippmMetricsCapabilities 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 } + ::= { ippmMetricsEntry 2 } ippmMetricUnit OBJECT-TYPE SYNTAX INTEGER { noUnit(0), second(1), ms(2), us(3), ns(4), percentage(5), packets(6), - byte(6), - kbyte(7), - megabyte(8) + byte(7), + kbyte(8), + megabyte(9) } MAX-ACCESS read-only STATUS current DESCRIPTION - "The unit used in the current entity for the results of - the measurement of this metric." - ::= { ippmMetricEntry 3 } + "The unit used in the current entity for the results of the measurement of this + metric." + ::= { ippmMetricsEntry 3 } - ippmMetricDescription OBJECT-TYPE - SYNTAX DisplayString + ippmMetricsDescription OBJECT-TYPE + SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A textual description of the metric implementation." - ::= { ippmMetricEntry 4 } + ::= { ippmMetricsEntry 4 } - ippmMetricMaxHistorySize OBJECT-TYPE + ippmMetricsMaxHistorySize OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION - "Specifies the maximum number of results that a metric - measure can save in the ippmHistoryTable." - ::= { ippmMetricEntry 5 } + "Specifies the maximum number of results that a metric measure can + save in the ippmHistoryTable." + DEFVAL { 200 } + ::= { ippmMetricsEntry 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 all be active. + "The table of all the IPPM measures which are running in the device. They may not all + be active. - A measure consists of 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. + A measure consists of 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 maximum number of MIB objects to be collected in the - portion of ippmHistoryTable associated with this metric - depends on the value of the ippmMetricMaxHistorySize. + The maximum number of MIB objects to be collected in the portion of ippmHistoryTable + associated with this metric depends on the value of the ippmMetricMaxHistorySize. - The value of each metric ippmMeasureHystorySize must not - be over the value of ippmMetricMaxHistorySize - corresponding to this metric in the ippmMetricTable. + The value of each metric ippmMeasureHystorySize must not be over the value of + ippmMetricMaxHistorySize corresponding to this metric in the ippmMetricTable. The ippmMeasureTable is mandatory. - ippmMeasureTable content is read only. It means that the - table is handled internally by the measurement - software. + ippmMeasureTable content is read-create. The table is handled internally by the + measurement software for network measures. + + The setup of network is not permitted through the IPPM REPORTING MIB. OWAP provides a + setup protocol to enable and teardown networks measures. " ::= { ippmMeasureGroup 2 } ippmMeasureEntry OBJECT-TYPE SYNTAX IppmMeasureEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION - "The measure entries are created/deleted internally by - the measurement software. + "The measure entries are created/deleted internally by the measurement software. " INDEX { ippmMeasureOwner, ippmMeasureIndex } ::= { ippmMeasureTable 1 } IppmMeasureEntry ::= SEQUENCE { ippmMeasureOwner OwnerString, ippmMeasureIndex Integer32, - ippmMeasureName DisplayString, + ippmMeasureName SnmpAdminString, ippmMeasureMetrics IppmStandardMetrics, - ippmMeasureBeginTime GMTDateAndTime, + ippmMeasureBeginTime GMTTimeStamp, ippmMeasureClockPeriodUnit TimeUnit, ippmMeasureClockPeriod Integer32, ippmMeasureDurationUnit TimeUnit, ippmMeasureDuration Integer32, ippmMeasureHystorySize Integer32, ippmMeasureStorageType StorageType, ippmMeasureStatus RowStatus } ippmMeasureOwner OBJECT-TYPE SYNTAX OwnerString - MAX-ACCESS read-only + MAX-ACCESS not-accessible STATUS current DESCRIPTION "The owner who has configured this entry." DEFVAL { "acme" } ::= { ippmMeasureEntry 1 } ippmMeasureIndex OBJECT-TYPE SYNTAX Integer32 (1.. 65535) - MAX-ACCESS read-only + MAX-ACCESS not-accessible STATUS current DESCRIPTION - "The owner index of the measure. The value is managed by - the owner." + "The owner index of the measure. The value is managed by the owner." ::= { ippmMeasureEntry 2 } ippmMeasureName OBJECT-TYPE - SYNTAX DisplayString - MAX-ACCESS read-only + SYNTAX SnmpAdminString + 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. + "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-only + 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 - metric singletons to be archived 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. + "Defines the metrics to compute within this measure. A measure may be configured for + the result of different metric singletons to be archived in the ippmHistoryTable. The + ippmMetricsIndex of the created result has the value of the bit index of the + corresponding ippmMeasureMetrics as explained above in the IppmMetricsEntry + 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." + 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 IppmMetricsIndex of 6 while the created + singletons for the One-way-Packet-Loss measure have a value of IppmMetricsIndex of + 12." DEFVAL { { one-way-Delay, one-way-Packet-Loss } } ::= { ippmMeasureEntry 4 } ippmMeasureBeginTime OBJECT-TYPE - SYNTAX GMTDateAndTime - MAX-ACCESS read-only + SYNTAX GMTTimeStamp + 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-only + 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-only + MAX-ACCESS read-create STATUS current DESCRIPTION - "Specifies the amount of time between 2 measurement - action intervals. The action is specific to the semantic - of the measure. + "Specifies the amount of time between 2 measurement action intervals. The action is + specific to the semantic of the measure. Network metrics: - The ippmNetworkMeasureClockPattern transforms the flow - of periodical instants as a flow of unpredictable - instants of measurement packet emission. + The ippmNetworkMeasureClockPattern transforms the flow of periodical instants as a + flow of unpredictable instants of measurement packet emission. - As the source and the sink share the definition of the - clock of the measure, as the sending timestamp is part - of the measurement packet, the sink have the information - to verify that the stream of packets generated by the - source respects the clock law. + As the source and the sink share the definition of the clock of the measure, as the + sending timestamp is part of the measurement packet, the sink have the information to + verify that the stream of packets generated by the source respects the clock law. Aggregated metrics: - They are performed periodically on a sequence of results - of other measures. The period corresponds to the - interval between two successive computations of the - metric. The ippmHistoryTimeMark result value of the - metric computed corresponds to the ippmHistoryTimeMark - value of the last metric result of the sequence used in - the computation." + They are performed periodically on a sequence of results of other measures. The period + corresponds to the interval between two successive computations of the metric. The + value of ippmHistoryTimestamp result of a aggregated metric computed corresponds to + the value of the ippmHistoryTimestamp of the last metric result of the sequence used + in to compute the aggregated metric." DEFVAL { 60 } ::= { ippmMeasureEntry 7 } ippmMeasureDurationUnit OBJECT-TYPE SYNTAX TimeUnit - MAX-ACCESS read-only + 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-only + MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the duration of the measure." DEFVAL { 120 } ::= { ippmMeasureEntry 9 } ippmMeasureHystorySize OBJECT-TYPE SYNTAX Integer32 - MAX-ACCESS read-only + 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 - overwrites the oldest one when the history granted to - this metric measure is full. + "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 overwrites + 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. + 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-only + 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)" + 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-only + 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 } + "The status of this table entry. Once the entry status is set to active, the associate + entry cannot be modified." ::= { ippmMeasureEntry 12 } -- -- ippmHistoryGroup -- -- -- -- ippmHistoryTable -- @@ -2001,97 +2051,84 @@ "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 results of a - measure identified by the index members ippmMeasureOwner - and ippmMeasureIndex. + "An ippmHistoryEntry entry is one of the results of a 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. + + ippmMeasureOwner and ippmMeasureIndex identify the ippmMeasureEntry on + whose behalf this entry was created + + IppmMetricsIndex identifies the ippmMetricsEntry of the metric to measure + + ippmHistorySqceNdx 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. + The ippmHistoryTimestamp value is the absolute time when the ippmHistoryValue was + performed. - IppmHistoryValue is the value of the metric measured at - the time ippmHistoryTimeMark. + IppmHistoryValue is the value of the metric measured at the time ippmHistoryTimestamp. - 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 50ms is 23. - The result is identified as the singleton - ippmHistoryValue.acme.1.6.0001000201090200010501000BEBC2 - 00 and stored with value 23. + 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 first result of the one way delay measured for acme on the day 15 of + June at 8h20mn 10s 50ms is 23. The result is identified as the singleton + ippmHistoryValue.acme.1.6.1 and stored with value 23. - Its value may be retrieved using a get- - next(ippmHistoryValue.acme.1.6.0001000201090200010501000 - 0000000) which returns - (ippmHistoryValue.acme.1.6.0001000201090200010501000BEBC - 200 == 23). The ippmMetricIndex value of '6' corresponds - to the 6th metric of ippmMetricTable which is Type-P- - One-way-Delay. + Its value may be retrieved using a get-next(ippmHistoryValue.acme.1.6) which returns + (ippmHistoryValue.acme.1.6.1 == 23). The IppmMetricsIndex value of '6' corresponds to + the 6th metric of ippmMetricsTable which is Type-P-One-way-Delay. " - INDEX { ippmMeasureOwner, ippmMeasureIndex, ippmMetricIndex, - ippmHistoryTimeMark } + INDEX { ippmMeasureOwner, ippmMeasureIndex, ippmMetricsIndex, + ippmHistorySqceNdx } ::= { ippmHistoryTable 1 } IppmHistoryEntry ::= SEQUENCE { - ippmHistoryTimeMark GMTDateAndTime, ippmHistorySqceNdx Integer32, + ippmHistoryTimestamp GMTTimeStamp, ippmHistoryValue Integer32 } - ippmHistoryTimeMark OBJECT-TYPE - SYNTAX GMTDateAndTime - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The instant of the measure of the result." - ::= { ippmHistoryEntry 1 } - ippmHistorySqceNdx OBJECT-TYPE - SYNTAX Integer32 - MAX-ACCESS read-only + SYNTAX Integer32 (0..65536) + MAX-ACCESS not-accessible STATUS current DESCRIPTION - " ippmHistorySqceNdx is the sequence index of the - measurement results of the measure of a metric. + " ippmHistorySqceNdx is the sequence index of the measurement + results of the measure of a metric. Network metrics: - It's the sequence index of a measurement packet. Typically, it - identifies the order of the packet in the stream of packets sends by - the source. + It's the sequence index of a measurement packet. Typically, it identifies the order of + the packet in the stream of packets sends by the source. Aggregated metrics: - It is the sequence index of the aggregated metric results - computed. + It is the sequence index of the aggregated metric results computed. " + ::= { ippmHistoryEntry 1 } + + ippmHistoryTimestamp OBJECT-TYPE + SYNTAX GMTTimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The instant of the measure of the result." ::= { ippmHistoryEntry 2 } ippmHistoryValue OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the measure." ::= { ippmHistoryEntry 3 } @@ -2104,607 +2141,607 @@ -- -- ippmNetworkMeasureTable -- -- 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. + "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. + This table extends the ippmMeasureTable. A network measure is a specific measure. - It performs several metric measurements 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." + It performs several metric measurements 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 - " Typically the configuration operation sets both the - values of the new ippmMeasureEntry and of the new - IppmNetworkMeasureEntry. + " Typically the configuration operation sets both the values of the new + ippmMeasureEntry and of the new IppmNetworkMeasureEntry. IppmNetworkMeasureTable is mandatory. - IppmNetworkMeasureTable content is read only. It means - that the measurement software handles the table - internally. + IppmNetworkMeasureTable content is read only. It means that the measurement software + handles the table internally. The setup of network is not permitted through the IPPM + REPORTING MIB. OWAP provides a setup protocol to enable and teardown networks + measures. - The ippmMeasureMetrics is set to a list of metrics to be - computed from the same raw packet exchange. Each step of - measurement delivers a singleton per chosen metric. - Results are timestamped and saved in the - ippmHistoryTable." + The ippmMeasureMetrics is set to a list of metrics to be computed from the same raw + packet exchange. Each step of measurement delivers a singleton per chosen metric. + Results are timestamped and saved in the ippmHistoryTable. + + The ippmNetworkMeasureTable typical usage consists is providing network measure + indexes to permits aggregated measure to perform aggregation on the results of network + measures. + An obvious usage of the ippmNetworkMeasureTable consists in the verification of the + network measures states." 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 } ippmNetworkMeasureSrcTypeP OBJECT-TYPE SYNTAX TypeP MAX-ACCESS read-only STATUS current DESCRIPTION - "Defines the type P of the source address of the packets - sent by the measure." + "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-only 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. + 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." + 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-only STATUS current DESCRIPTION - "Defines the type P of the destination address of the - packets sent by the measure." + "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-only STATUS current DESCRIPTION - "Specifies the address of the destination of the - measure. + "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. + It is represented as an octet string with specific semantics and length as identified + by the ippmNetworkMeasureDstTypeP. - 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." + 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-only STATUS current DESCRIPTION - "This cyclic clock shapes the profile of the instants of - measurement action provided by ippmMeasureClockPeriod - according to an arbitrary distribution law. The clock - resolution is ippmMeasureClockPeriod. The bits of the - clock pattern set to the value 1 determine the valid - instants of measurement action. 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 time - sampling law such as periodic, pseudo random or Poisson. + "This cyclic clock shapes the profile of the instants of measurement action provided + by ippmMeasureClockPeriod according to an arbitrary distribution law. The clock + resolution is ippmMeasureClockPeriod. The bits of the clock pattern set to the value 1 + determine the valid instants of measurement action. 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 time sampling law such as periodic, pseudo random or Poisson. - The source of the measure sends the stream of - measurement packets synchronously with the stream of - instants selected by the clock pattern sampling. + The source of the measure sends the stream of measurement packets synchronously with + the stream of instants selected by the clock pattern sampling. " DEFVAL { 11111111} -- 100% periodic ::= { ippmNetworkMeasureEntry 5 } ippmNetworkMeasureTimeoutDelay OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current -- UNITS "Milliseconds" DESCRIPTION - "Specifies the delay after which the packet is - considered lost by the sink." + "Specifies the delay after which the packet is considered lost by + the sink." DEFVAL { 1 } ::= { ippmNetworkMeasureEntry 6 } ippmNetworkMeasureL3PacketSize OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION - "Specifies the size of the packets sent at the last - network layer in regards to the TypeP definition." + "Specifies the size of the packets sent at the last network layer in regards to the + TypeP definition." DEFVAL { 64 } ::= { ippmNetworkMeasureEntry 7 } ippmNetworkMeasureDataPattern OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION - "The current field defines the round robin pattern used - to fill the packet." + "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. - An aggregated measure summarizes the results of previous - network or aggregated measures. The results may be saved - in the ippmHistoryTable. + An aggregated measure summarizes the results of previous network or aggregated + measures. The results may be saved in the ippmHistoryTable. - Each step of the calculation for the measure produces a - singleton result per metric." + Each step of the calculation for the measure produces a singleton result per metric." ::= { ippmAggregatedMeasureGroup 1 } ippmAggregatedMeasureEntry OBJECT-TYPE SYNTAX IppmAggregatedMeasureEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION - "Typically the configuration operation sets both the values of - the new ippmMeasureEntry and of the new - IppmAggregatedMeasureEntry. + "Typically the configuration operation sets both the values of the new + ippmMeasureEntry and of the new IppmAggregatedMeasureEntry. ippmAggregatedMeasureTable is mandatory. - ippmAggregatedMeasureTable content is read only. It means that - the measure software handles the table internally. + ippmAggregatedMeasureTable content is read only. It means that the measure software + handles the table internally. The ippmMeasureMetrics defines the metric to compute. - The results of the measure to summarize are identified - by: + The results of the measure to summarize are identified by: + ippmAggregatedMeasureHistoryOwner, + ippmAggregatedMeasureHistoryOwnerIndex and + ippmAggregatedMeasureHistoryMetric - The aggregated task starts at ippmMeasureBeginTime and ends - after ippmMeasureDuration. An aggregated result is performed and - saved in the ippmHistoryTable for each ippmMeasureClockPeriod - tick. + The aggregated task starts at ippmMeasureBeginTime and ends after ippmMeasureDuration. + An aggregated result is performed and saved in the ippmHistoryTable for each + ippmMeasureClockPeriod tick. " INDEX { ippmMeasureOwner, ippmMeasureIndex } ::= { ippmAggregatedMeasureTable 1 } IppmAggregatedMeasureEntry ::= SEQUENCE { ippmAggregatedMeasureHistoryOwner OwnerString, ippmAggregatedMeasureHistoryOwnerIndex Integer32, - ippmAggregatedMeasureHistoryMetric Integer32 + ippmAggregatedMeasureHistoryMetric Integer32, + ippmAggregatedMeasureStatus RowStatus } ippmAggregatedMeasureHistoryOwner OBJECT-TYPE SYNTAX OwnerString - MAX-ACCESS read-only + 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-only + 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-only + MAX-ACCESS read-create STATUS current DESCRIPTION "The metric of the measure to summarize. " ::= { ippmAggregatedMeasureEntry 3 } + ippmAggregatedMeasureStatus 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." + ::= { ippmAggregatedMeasureEntry 4 } -- -- ippmReportGroup -- -- -- -- ippmReportSetupTable -- -- 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 that are to - be reported. 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 intended to be 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. + "The ippmReportSetupTable is a list of definition of reports. It defines the results + of a network or aggregated measures that are to be reported. 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 intended to be 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 a measure - may include the definition of a report." + It extends the definition of a measure: the definition of a 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 to the results of the measure which is extended - by the current report definition. + "The report applies to the results of the measure which is extended by the current + report definition. - Typically the creation of 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." + Typically the creation of 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 + ippmReportSetupNMS SnmpAdminString, + ippmReportSetupStatus RowStatus } ippmReportSetupDefinition OBJECT-TYPE SYNTAX IppmReportDefinition - MAX-ACCESS read-only + MAX-ACCESS read-create STATUS current DESCRIPTION - "The description of the events and actions that are used in the - definition of the report. - Send the report using the type of message selected by the bits 8 - to 12. The report consists of 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 description of the events and actions that are used in the definition of + the report. + Send the report using the type of message selected by the bits 8 to 12. The + report consists of 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: + 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 durations 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 + + Singleton events are sent using the notification ippmSingletonAlarm + + Exceeded events durations 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: + 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: + 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 - : + 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 : ippmReportSetupDefinition { onMeasureCycle(2), inInformRequestPDU(10), clearHistory(13) } " - DEFVAL { { onMeasureCycle, inInformRequestPDU, clearHistory } } - ::= { ippmReportSetupEntry 1 } + DEFVAL { { onMeasureCycle, inInformRequestPDU, clearHistory } } ::= { + ippmReportSetupEntry 1 } ippmReportSetupMetricThreshold OBJECT-TYPE SYNTAX Integer32 - MAX-ACCESS read-only + 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. + "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 ippmMetricUnit of this metric entry in the ippmMetricTable. " ::= { ippmReportSetupEntry 2 } ippmReportSetupEventsDurationThreshold OBJECT-TYPE SYNTAX Integer32 UNITS "Seconds" - MAX-ACCESS read-only + MAX-ACCESS read-create STATUS current DESCRIPTION - "An event is generated when the duration of a series of results, - which are continuously over the metric threshold, cross over the - duration of the ippmReportSetupEventsDurationThreshold. + "An event is generated when the duration of a series 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-only + SYNTAX SnmpAdminString + 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. + "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. + The type of ippmReportSetupNMS is not InetAddress because the report may be sent using + SMS or fax. " ::= { ippmReportSetupEntry 4 } + ippmReportSetupStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The status of this table entry. " + ::= { ippmReportSetupEntry 5 } + -- -- ippmReportTable -- 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 of a subset of the results of a measure as - described in the report definition. The activation of an up and down - filtering in the report definition limits the results logged to those - corresponding to major events. Otherwise, the ippmReportTable is + "The ippmReportTable logs the results of the reports. The results + consist of a subset of the results of a measure as described in the report definition. + The activation of an up and down filtering in the report definition limits the results + logged to those corresponding to major events. Otherwise, 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 a measure to - report. The measure and the report definition are identified by the - index members ippmMeasureOwner and ippmMeasureIndex. + "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 a 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 + + 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. + + IppmMetricsIndex identifies the ippmMetricsEntry of the metric measured + + ippmHistorySqceNdx value is the absolute time when the result of the metric was + computed. - The ippmReportTimeMark value is the absolute time when the - ippmHistoryValue was performed. - IppmHistoryValue is the value of the metric measured at the time - ippmReportTimeMark. + The ippmReportTimestamp value is the absolute time when the ippmHistoryValue + was performed. + IppmHistoryValue is the value of the metric measured at the timef + ippmReportTimestamp. " - INDEX { ippmMeasureOwner, ippmMeasureIndex, ippmMetricIndex, - ippmReportTimeMark } + INDEX { ippmMeasureOwner, ippmMeasureIndex, ippmMetricsIndex, + ippmReportSqceNdx} ::= { ippmReportTable 1 } IppmReportEntry ::= SEQUENCE { - ippmReportTimeMark GMTDateAndTime, + ippmReportSqceNdx Integer32, + ippmReportTimestamp GMTTimeStamp, ippmReportValue Integer32 } - ippmReportTimeMark OBJECT-TYPE - SYNTAX GMTDateAndTime + ippmReportSqceNdx OBJECT-TYPE + SYNTAX Integer32 (1..65536) MAX-ACCESS read-only STATUS current DESCRIPTION - "The instant of the measure of the result." + + " ippmReportSqceNdx is the sequence index of the measurement + results of the measure of a metric. + + Network metrics: + + It's the sequence index of a measurement packet. Typically, it identifies the order of + the packet in the stream of packets sends by the source. + + Aggregated metrics: + + It is the sequence index of the aggregated metric results computed. + " ::= { ippmReportEntry 1 } + ippmReportTimestamp OBJECT-TYPE + SYNTAX GMTTimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The instant of the measure of the result." + ::= { ippmReportEntry 2 } + ippmReportValue OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value." - ::= { ippmReportEntry 2 } + ::= { ippmReportEntry 3 } -- -- 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. + "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 that exceeded the threshold. The - ippmHistoryTimeMark of the index identifies the time the - event occurred. + The notification contains the instances of the ippmReportValue object that exceeded + the threshold. The ippmHistoryTimestamp of the index identifies the time the event + occurred. " ::= { ippmNotifications 1 } 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. + "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. + The notification contains the instances of the ippmReportValue objects saved in the + ippmReportTable for this report. The ippmHistoryTimestamp 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 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 + The notification contains the instances of the ippmReportValue objects saved in the + ippmReportTable for this measure cycle. The ippmHistoryTimestamp of the index identifies the time the measures where performed. " ::= { ippmNotifications 3 } ippmCompletedMeasureReport NOTIFICATION-TYPE OBJECTS { 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 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 + The notification contains the instances of the ippmReportValue objects saved in the + ippmReportTable for this measure cycle. The ippmHistoryTimestamp 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" + "The compliance statement for SNMP entities which implement the IPPM MIB" MODULE -- this module MANDATORY-GROUPS { ippmSystemGroup, ippmMeasureGroup, ippmNetworkMeasureGroup, ippmHistoryGroup } ::= { ippmCompliances 1 } END -9. Security Considerations + 10. Security Considerations -9.1. Privacy + 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. -9.2. Measurement aspects + 10.2. Measurement aspects 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 that 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 @@ -2722,21 +2759,21 @@ 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. -9.3. Management aspects + 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-only. 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 @@ -2747,21 +2784,72 @@ 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. 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. -10. References + 11. Document management + + 11.1. Open issues + + Describe incompatible bit combinations in IPPMreport and granted + metric + + Run SMIlint. + + Discussion on the management of the history size. + + 11.2. changes since release 00 + + Put in a description of the relationship of certain tables, + particularly the measure/network measure/aggregated measure table. + + The TC GMTTimeStamp is the common type to define timestamp objects. + + ippmHisoryTable index simplified: ippmHistoryTimestamp replaced with + ippmHistorySqceNdx in the index. + + The MIB has been compiled using net-snmp. + + Snmpadminstring replaces Displaystring. + + IP addresses defined using INETaddresstype. + + Sharing table is optional to permit the VACM framework to be used. + + The description of the network measure table emphases that the set up + of network measure is not permitted using SNMP. + + The TC StandardMetrics is removed and replaced with the table + ippmMetricsTable. + + The table pointOfMeasureTable is added to describe multiples + interfaces devices + + 5 tables have been changed to read/create: ippmOwnersTable, + ippmMeasureTable, ippmAggregatedMeasureTable, ippmResultSharingTable, + and ippmReportSetupTable. + + IppmHistoryTable and ippmReportTable index reviews: + IppmHistorySqceNdx field added in the ippmHistoryTable. + INDEX modified. IppmHistorySqceNdx replaces IppmHistoryTimemark. + + IppmSystem group refurbished: + IppmSystemTimer renamed ippmSystemTime. + Current and last synch event concept generalized in the + ippmSynchronizationTable. + + 12. 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. @@ -2825,38 +2913,25 @@ 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. - - [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. - -11. Acknowledgments + 13. Acknowledgments A Kerbe. -12. Author's Addresses + 14. Authors 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 Jessie Jewitt France Telecom R & D