idnits 2.17.1 draft-ietf-ippm-reporting-mib-01.txt: -(802): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 34 longer pages, the longest (page 27) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 64 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 10. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 283 instances of too long lines in the document, the longest one being 47 characters in excess of 72. ** There are 1623 instances of lines with control characters in the document. ** The abstract seems to contain references ([20], [15], [2], [21], [16], [3], [22], [17], [4], [18], [5], [19], [6], [7], [8], [9], [10], [11], [12], [13], [1], [14]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 2754: '...rk. The measurement parameters MUST be...' RFC 2119 keyword, line 2767: '... methodologies SHOULD include approp...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 1103 has weird spacing: '... field octet...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2002) is 7827 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 2852 looks like a reference -- Missing reference section? '2' on line 2855 looks like a reference -- Missing reference section? '3' on line 2858 looks like a reference -- Missing reference section? '4' on line 2861 looks like a reference -- Missing reference section? '5' on line 2864 looks like a reference -- Missing reference section? '6' on line 120 looks like a reference -- Missing reference section? '7' on line 2870 looks like a reference -- Missing reference section? '8' on line 2873 looks like a reference -- Missing reference section? '9' on line 2877 looks like a reference -- Missing reference section? '10' on line 2880 looks like a reference -- Missing reference section? '11' on line 2883 looks like a reference -- Missing reference section? '12' on line 2887 looks like a reference -- Missing reference section? '13' on line 2891 looks like a reference -- Missing reference section? '14' on line 2895 looks like a reference -- Missing reference section? '15' on line 2898 looks like a reference -- Missing reference section? '16' on line 2901 looks like a reference -- Missing reference section? '17' on line 144 looks like a reference -- Missing reference section? '18' on line 2909 looks like a reference -- Missing reference section? '19' on line 2913 looks like a reference -- Missing reference section? '20' on line 2917 looks like a reference -- Missing reference section? '21' on line 2920 looks like a reference -- Missing reference section? '22' on line 2924 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 24 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Stephan/J. Jewitt 3 Internet Draft France Telecom R&D 4 Document: draft-ietf-ippm-reporting-mib-01.txt November 2002 6 IPPM reporting MIB 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026 [1]. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or made obsolete by other documents at 18 any time. It is inappropriate to use Internet- Drafts as reference 19 material or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt. 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Abstract 29 This memo defines a portion of the Management Information Base (MIB) 30 designed for use with network management protocols in TCP/IP-based 31 internets. 32 In particular, this MIB specifies the objects used for managing the 33 results of the IPPM metrics measures, for pushing alarms, and for 34 reporting the measures results. 36 Table of Contents 38 1. Introduction................................................3 39 2. The IPPM Framework..........................................3 40 3. The IPPM Framework..........................................3 41 4. The SNMP Management Framework...............................4 42 5. Overview....................................................6 43 5.1. Textual Conventions.........................................7 44 5.2. Structure of the MIB........................................9 45 5.3. Row identification in an application namespace.............11 46 5.4. Relationship of IPPM MIB tables............................12 47 6. IPPM-REPORTING-MIB conceptual presentation.................16 48 6.1. IPPM-REPORTING-MIB diagram.................................16 49 6.2. Conceptual programming interface...........................17 50 6.3. SNMP mapping...............................................17 51 7. Measurement architectures..................................18 52 7.1. Proxy architecture.........................................18 53 7.2. Reporting architecture.....................................19 54 7.3. Gateway architecture.......................................21 55 7.4. Security...................................................21 56 8. Reporting mode integration with the control and test 57 protocols................................................22 58 8.1. Integration................................................22 59 8.2. Setup of the measure.......................................22 60 8.3. Setup of the measurement report............................23 61 8.4. Writing the measurement results in the IPPM-REPORTING 62 MIB......................................................23 63 8.5. Report download and upload.................................24 64 8.6. Default value..............................................24 65 9. Definition.................................................25 66 10. Security Considerations....................................58 67 10.1. Privacy.....................................................58 68 10.2. Measurement aspects.........................................58 69 10.3. Management aspects..........................................59 70 11. Document management........................................60 71 11.1. Open issues.................................................60 72 11.2. changes since release 00....................................60 73 12. References.................................................61 74 13. Acknowledgments............................................63 75 14. Authors Addresses..........................................63 76 1. Introduction 77 This memo defines a MIB for managing measures based upon the IP 78 performance metrics specified by the IPPM Working Group. 80 The definition of objects in the IPPM MIB are built on notions 81 introduced and discussed in the IPPM Framework document, RFC 2330 82 [ii]. 84 This memo defines a Management Information Base (MIB), and as such it 85 is intended to be respectful of the "Boilerplate for IETF MIBs" 86 defined in http://www.ops.ietf.org/mib-boilerplate.html. 88 There are companion documents to the IPPM-REPORTING-MIB both in the 89 Transport Area (See section 2), and in the Operations and Management 90 Area (See section 3). The reader should be familiar with these 91 documents. 93 2. The IPPM Framework 95 The IPPM Framework consists of 3 major components: 97 A general framework for defining performance metrics, as described in 98 the Framework for IP Performance Metrics, RFC 2330 [2]; 100 A set of standardized metrics which conform to this framework: The 101 IPPM Metrics for Measuring Connectivity, RFC 2678 [iii]; The One-way 102 Delay Metric for IPPM, RFC 2679 [iv]; The One-way Packet Loss Metric 103 for IPPM, RFC 2680 [v]; The Round-trip Delay Metric for IPPM, RFC 104 2681 [vi]. 106 Emerging metrics that are being specified in respect of this 107 framework. 109 3. The IPPM Framework 111 The IPPM Framework consists in 3 major components: 113 A general framework for defining performance metrics, described 114 in the Framework for IP Performance Metrics, RFC 2330 [2]; 116 A set of standardized metrics which conform to this framework: 117 The IPPM Metrics for Measuring Connectivity, RFC 2678 [3]; The One- 118 way Delay Metric for IPPM, RFC 2679 [4]; The One-way Packet Loss 119 Metric for IPPM, RFC 2680 [5]; The Round-trip Delay Metric for IPPM, 120 RFC 2681 [6]. 122 Emerging metrics that are being specified in respect of this 123 framework. 125 4. The SNMP Management Framework 127 The SNMP Management Framework consists of five major components: 129 An overall architecture, described in RFC 2571 [7]. 131 Mechanisms for describing and naming objects and events for the 132 purpose of management. The first version of this Structure of 133 Management Information (SMI) is called SMIv1 and described in STD 16, 134 RFC 1155 [8], STD 16, RFC 1212 [9] and RFC 1215 [10]. The second 135 version, called SMIv2, is described in STD 58, RFC 2578 [11], STD 58, 136 RFC 2579 [12] and STD 58, RFC 2580 [13]. 138 Message protocols for transferring management information. The 139 first version of the SNMP message protocol is called SNMPv1 and 140 described in STD 15, RFC 1157 [14]. A second version of the SNMP 141 message protocol, which is not an Internet standards track protocol, 142 is called SNMPv2c and described in RFC 1901 [15] and RFC 1906 [16]. 143 The third version of the message protocol is called SNMPv3 and 144 described in RFC 1906 [16], RFC 2572 [17] and RFC 2574 [18]. 146 Protocol operations for accessing management information. The 147 first set of protocol operations and associated PDU formats is 148 described in STD 15, RFC 1157 [14]. A second set of protocol 149 operations and associated PDU formats is described in RFC 1905 [19]. 151 A set of fundamental applications described in RFC 2573 [20] and 152 the view-based access control mechanism described in RFC 2575 [21]. 154 A more detailed introduction to the current SNMP Management Framework 155 can be found in RFC 2570 [22]. 157 Managed objects are accessed via a virtual information store, termed 158 the Management Information Base or MIB. Objects in the MIB are 159 defined using the mechanisms defined in the SMI. 161 This memo specifies a MIB module that is compliant to the SMIv2. A 162 MIB conforming to the SMIv1 can be produced through the appropriate 163 translations. The resulting translated MIB must be semantically 164 equivalent, except where objects or events are omitted because no 165 translation is possible (use of Counter64). Some machine readable 166 information in SMIv2 will be converted into textual descriptions in 167 SMIv1 during the translation process. However, this loss of machine 168 readable information is not considered to change the semantics of the 169 MIB. 171 Managed objects are accessed via a virtual information store, termed 172 the Management Information Base or MIB. Objects in the MIB are 173 defined using the subset of Abstract Syntax Notation One (ASN.1) 174 defined in the SMI. In particular, each object type is named by an 175 OBJECT IDENTIFIER, an administratively assigned name. 177 The object type together with an object instance serves to uniquely 178 identify a specific instantiation of the object. For human 179 convenience, we often use a textual string, termed the descriptor, to 180 refer to the object type. 182 5. Overview 184 Although the number of measurement devices that implement IPPM 185 metrics is growing, there is not currently any standardized 186 management interface to manage remotely the measurement of these 187 metrics. This memo defines a Management Information Base for managing 188 the measurement of IPPM metrics. 190 To permit metrics to be referenced by other MIBs and other protocols, 191 the IPPM WG has defined a registry of the current metrics and a 192 framework for the integration of future metrics in the [IPPM metrics 193 registry]. 195 As the specification of new metrics is a continuous process, this 196 memo defines a framework for the integration of the future 197 standardized metrics. To address future needs specialized tables may 198 be created, while augmenting the definition of the ippmMeasureTable. 200 The MIB architecture is inspired by the RMON model [xxiii],[xxiv] 201 which specifies the MIB for the monitoring of a single point of 202 measure. The IPPM-REPORTING-MIB differs from this model in that IPPM 203 metrics measurement involves several points of measure and requires 204 common references for time and for measure identification. The IPPM- 205 REPORTING-MIB defines an absolute timeFilter. 207 The IPPM-REPORTING-MIB introduces a framework where each application 208 identifies its measures in an owner namespace. Using the namespace 209 framework, an application may grant other owners access to its 210 measurement results for aggregated metrics computation, reporting, or 211 alarming. 213 Different architectures may be used to perform metric measurements, 214 using a control protocol and a test protocol. Different control 215 frameworks are suitable for performing measurements. The memo lists 216 them, while also looking for a way to integrate them with the IPPM- 217 REPORTING-MIB. This section is for informational purposes only, and 218 is intended to help to specify the relationship among the test 219 protocol, the control protocol and IPPM-REPORTING-MIB. 221 Special care has been taken to provide a reporting mode suitable for 222 control protocols and test protocols. It addresses the need to 223 provide access to results for the applications. Moreover, it may be 224 used to reduce the number of control frameworks. 226 This MIB is intended to handle multiple concurrent sessions by SNMP 227 applications. However, the SNMP requests are not necessarily to be 228 handled explicitly by the measurement devices, but can be sent to 229 middleware performing an aggregation function. This allows for 230 continuous collection of measurements and statistics computation. 232 5.1. Textual Conventions 234 Four types of data are introduced as a textual convention in this 235 document: TypeP, GMTTimeStamp, IppmStandardMetrics and 236 IppmReportDefinition. 238 5.1.1. Packet of type P 240 Section 13 of the IPPM framework [2] introduces the generic notion of 241 a "packet of type P" because in some contexts the metric's value 242 depends on the type of the packets involved in the metric. In the 243 definition of a metric, the type P will be explicitly defined, 244 partially defined, or left generic. Measurement of metrics defined 245 with generic type P are made specific when performing actual 246 measurements. This naming convention serves as an important reminder 247 that one must be conscious of the exact type of traffic being 248 measured. 250 The standardization of the management of the IPPM measures relies on 251 the capability to finely and unambiguously configure the type P of 252 the packets, and the parameters of the protocol suites of the type P. 254 RMON2 introduced the concept of protocol identifiers. RFC2895 [xxv] 255 specifies a macro for the definition of protocol identifier. The 256 RFC2896 [xxvi] defines the protocol identifiers for different 257 protocol encapsulation trees. 259 The type P implementation relies on the MACRO PROTOCOL-IDENTIFIER 260 defined for identifying protocol suites in RMON2. It is achieved by 261 defining the TypeP as a new syntax in SMIv2 TEXTUAL-CONVENTION. 263 5.1.1.1. Internet addresses 265 The section 14 of the IPPM framework defines (for the usual case of a 266 unidirectional path through the Internet) the term "Src" and "Dst". 267 "Src" denotes the IP address of the beginning of the path, and "Dst" 268 denotes the IP address of the end. 270 The section 3 of the RMON PI Reference specifies the Protocol 271 Identifier Encoding rules which consists briefly in a recursive 272 length value format. "Src" and "Dst" are protocol identifier 273 parameters. Their values are encoded in separated fields using the 274 protocol identifier encoding rule, but without trailing parameters. 276 The packet encapsulation defined in an instance of TypeP embeds the 277 format of "Src" and "Dst" and their values. The type and value of 278 these addresses depend on the type P of the packet, IP version 4, V6, 279 IP in IP... Both participate in the completion of the packet 280 encoding. 282 Examples: 284 RFC2896 defines the protocol identifiers ip and ipip4. Should there 285 be an Internet tunnel end-point of the IP address 192.168.1.1 in the 286 tunnel 128.2.6.7. the TypeP of the source address of the tunnel, Src, 287 is 8.0.0.8.0.0.0.0.17.2.0.0 (ip.ipip4). The trailer 2.0.0 in the 288 TypeP indicates that there are 2 parameters. In the IPPM context 289 these 2 parameters are provided in Src, which has the value 290 10.4.192.168.1.1.4.128.2.6.7. 292 5.1.2. GMTTimeStamp 294 This textual convention defines the time at which an event occurred. 295 It is very similar to the NTP timestamp format except that it 296 represents the time elapsed since January 1st, 2000 instead of 297 January 1st, 1900. 299 5.1.3. IppmStandardMetrics 301 Each standard metric is identified in the IPPM-METRICS-REGISTRY under 302 the node rfc in a chronological order. To permit several metrics to 303 be performed in a single measure there is an need to describe in a 304 bit string the metrics to be performed, granted... This textual 305 convention defines an octet string that gathered in a bit string a 306 sequence of bits. The bit order corresponds to the order of the 307 metrics identifiers in the registry. 309 5.1.4. Report definition 311 A report consists of sending, or logging, a subset of results of 312 measurements that have been taken over a period of time. The report 313 consists of actions that are taken on the measurement results. An 314 action is performed either: 316 + For each result 317 + On the results corresponding to a measurement cycle 318 + On the results available at the measurement completion. 320 To preserve the scalability of the whole measurement system, it 321 limits: 323 + The amount of data sent to the applications 324 + The bandwidth consumption for uploading the result 325 + The number of alarms sent to the applications 326 + The amount of data saved in the point of measure 327 The comparison of the measures results in a metric threshold that 328 identifies particular measure values and times that directly impact 329 service availability. 331 The comparison of the duration of repeated events with a duration 332 threshold identifies particular measure values and times that 333 directly affect an SLA. 335 The combination of IPPM metric results, threshold events, and event 336 filtering provides a very efficient mechanism to report results, 337 events, and alarms. 339 A report is described using the TEXTUAL-CONVENTION 340 IppmReportDefinition. The report setup must not dramatically increase 341 the amount of data needed by the control protocol to setup a measure: 343 + A basic report is defined in the object ippmReportSetupDefinition; 344 + More elaborate reports are described using a metric threshold to 345 generate alarms and events. 346 + Pushing of alarms and reports requires a management station 347 address to which the data will be sent. 348 + SLA alarms are described using an events duration threshold. 350 The TEXTUAL-CONVENTION IppmReportDefinition specifies the list of 351 events and actions that are used to create a report. 353 5.2. Structure of the MIB 355 The MIB is arranged as follow: 356 - ippmOwnersGroup 358 - ippmSystemGroup 360 - ippmMeasureGroup 362 - ippmHistoryGroup 364 - ippmNetworkMeasureGroup 366 - ippmAggregatedMeasureGroup 368 - ippmReportGroup 370 - ippmNotifications 372 5.2.1. The ippmOwners Group 374 This group identifies an owner, or group of owners that have access 375 to measurements on a probe. 377 5.2.2. The ippmSystem Group 379 This group consists of a set of parameters describing the clock 380 synchronization at a particular point of measure over time. 382 This group is critical to the implementation of the IPPM MIB. 384 Section 6.3. of the IPPM Framework states that 385 "Those who develop such measurement methodologies should strive to: 386 + Minimize their uncertainties/errors, 387 + Understand and document the sources of uncertainty/error, and 388 + Quantify the amounts of uncertainty/error." 390 The aim of this group is to have these values available to compute 391 reliable statistics. The implementation of this group is mandatory, 392 whether the time synchronization is automatic or not. 394 5.2.3. The ippmMeasureGroup 396 This group displays all the measures configured on the measurement 397 entity. It consists of the ippmMetricsTable and ippmMeasureTable. The 398 ippmMeasureTable holds the common part of a measure, while the 399 specific parameters are handled in the corresponding auxiliary table 400 (ippmNetworkMeasure, ippmAggregatedMeasureTable...) . 402 The measurement entity describes in the ippmMetricsTable of the SNMP 403 agent the local implementation of the standardized metrics. All 404 standardized metrics should be displayed in this table, with the 405 capability object defining whether the metric is implemented or not. 407 The control protocol registers a description of the existing measures 408 in the ippmMeasureTable and in the auxiliary measure tables. The 409 ippmMeasureTable table is read-create, but only allows for the 410 creation of "aggregated" measures when defined in conjunction with 411 the ippmAggregatedMeasureTable. Network measures are not allowed to 412 be created directly by the management entity, and as such the measure 413 table values for these measures should be display only. 415 The results of the measurements are logged in the ippmHistoryTable. 417 5.2.4. The ippmNetworkMeasure Group 419 The control protocol registers a description of the existing network 420 measures in the ippmNetworkMeasureTable and in the ippmMeasureTable. 422 This group displays the network measures defined by the control 423 protocol. The results are saved in the ippmHistoryTable. 425 ippmNetworkMeasureTable is an auxiliary table of ippmMeasureTable, 426 and is responsible for the configuration of the network measure. 428 5.2.5. The ippmAggregatedMeasure Group 430 ippmAggregatedMeasureTable is an auxiliary table of ippmMeasureTable, 431 and is responsible for the consolidation of the results previously 432 measured and saved in the ippmHistoryTable. The aggregated results 433 are saved in the ippmHistoryTable and may be used for higher 434 aggregated measures. 436 5.2.6. The Report Group 438 This group displays the existing reports of the measures collected. 439 ippmReportSetupTable is an auxiliary table of ippmMeasureTable, and 440 is responsible for the configuration of the reports. 441 The reports are saved in the ippmReportTable, or sent directly to the 442 applications. 444 5.2.7. The Notification Group 446 The Notification group specifies a list of valid notifications. They 447 are used to push alarms or reports to the applications. 449 5.3. Row identification in an application namespace 451 The control protocol or the test protocol adds rows in the namespace 452 of the corresponding measure. 454 An identifier of an instance of an object is defined as a list of 455 objects in the clause INDEX. An object instance identifier in an 456 owner namespace is defined as a list of objects in the clause INDEX 457 where the first object type is OwnerString. 459 As the OBJECT IDENTIFIER, which identifies the instance, begins with 460 the owner value, the remaining values of the index fields may be 461 chosen independently from one namespace to another. 463 This allows the user to choose arbitrary values for the remaining 464 fields of the INDEX clause without checking that the values of these 465 fields exists in the MIB tables. This allows the owner to use the 466 same values across MIB implementations. 468 Thus, it avoids polling to determine the next free index. Also, as a 469 consequence, two applications will never find the same free index 470 value. 472 The usage of owner namespace increases the speed of the management 473 operations while reducing bandwidth consumption and CPU load in the 474 agents and applications. 476 Measurements are requested by management applications. An instance of 477 an object managed by a management station is identified by the 478 management station OwnerString and the private index provided by the 479 MS. 481 As the MS manages its private range of indices, it simply chooses one 482 when it wishes to create a new control entry. For the same reason, 483 the setup of a measure on several points of measures consists of 484 simply sending the same copy of the measure setup to the different 485 points of measures involved. 487 5.4. Relationship of IPPM MIB tables 489 There is inherently a relationship between various tables in the IPPM 490 Mib, and as such, the data integrity must be assured. This 491 relationship is depicted in the following examples. 493 5.4.1. Relationship between the Owners Table and the Measure Table 495 The owners table contains the list of "owners" that can create and 496 activate remote IPPM measurements in an agent. As the table is 497 "Read/Create", these users and their associated 498 "access" rights on metric measurements can be directly configured. It 499 is recommended to make use of "view based access control" in order to 500 restrict access to this table. For example, the 501 master user "acme" may be given "write" privileges on the 502 ippmOwnersTable, whereas all others are restricted to "read" access. 503 The user "acme" can then setup the list of other users that have 504 access to measures. 506 There must be at least 1 owner in the owners table. This owner may be 507 either setup by default by the IPPM agent, or configured as stated 508 above. 509 An owner may have multiple corresponding entries in the measure 510 table. Each entry in the measure table must be associated with one, 511 and only one, entry in the owners table. That is to say, that a 512 defined measure may NOT have multiple owners. 514 Thus, we have a 1:N relationship between the owners table and the 515 measure table. 517 +---------------------+ +---------------------------+ 518 + ippmOwnersTable + + ippmMeasureTable + 519 +---------------------+ 1:N +---------------------------+ 520 + OwnersOwner: "Acme" +--------------+ Measure Owner: "Acme" + 521 + ..... + + Measure Name:"OneWayDelay"+ 522 + "Foo" + +...... + 523 + + + Measure Owner: "Foo" + 524 +---------------------+ + Measure Name: "PacketLoss"+ 525 +---------------------------+ 527 5.4.2. Relationship between the Measure Table and the Network Measure 528 Table/Aggregated Measure Table 530 The network measure table and the aggregated measure table can be 531 seen as logical "extensions" to the measure table. 532 The measure table contains information that is common to both types 533 of measurements. The information found in the Network Measure Table 534 and the Aggregated Measure Table is specific to each type of measure. 536 As the network measure table is read-only, entries in this table must 537 be populated by the agent upon startup. 538 The agent could potentially read a database that contains network 539 measures configured by a 3rd party proprietary management system that 540 directly interacts with the points of measure. An entry can not be 541 created in the network measure table without creating the 542 corresponding entry in the measure table associated to the measure. 543 This also implies that the "owner" of the measure be defined in the 544 owners table. 546 The aggregated measure table allows for an "owner" to create 547 aggregated measures (such as average, minimum, maximum) on existing 548 measures that are in the measure table. If an "owner" (A) wishes to 549 create an aggregated measure on a measure "owned" by another 550 "owner" (B), then "owner" (B) must grant "owner" (A) access to his 551 measures. This can be done in the resultsharing table. 553 Even though the Measure Table is read-create, an "owner" should only 554 be able to create, or modify entries in the measure table that 555 correspond to aggregated measure types. Should an "owner" attempt to 556 update an entry in the measure table that corresponds to an entry 557 in the network measure table, than access should be denied. 559 +---------------------------+ +----------------------------------+ 560 + ippmMeasureTable + + ippmNetworkMeasureTable + 561 +---------------------------+ +----------------------------------+ 562 + Measure Owner: "Acme" + + MeasureSrc: "Src1" + 563 + Measure Name:"OneWayDelay + ---+ MeasureDst: "Dst1" + 564 + ....... + + ........ + 565 + Measure Owner: "Foo" + + MeasureSrc: "Src2" + 566 + Measure Name: "PacketLoss"+ + MeasureDst: "Dst2" + 567 + + +----------------------------------+ 568 + + 569 + + +----------------------------------+ 570 + + + ippmAggregatedMeasureTable + 571 + + +----------------------------------+ 572 + Measure Owner: "Acme" + + AMHistoryOwner: "Foo" + 573 + Measure Name: "AvgPLoss" + ---+ AMHistoryMetric: "PacketLoss" + 574 +---------------------------+ +----------------------------------+ 576 +---------------------------------+ +--------------------------+ 577 + ippmResultSharingTable + + ippmHistoryTable + 578 + + + (ex: with OWPL values) + 579 +---------------------------------+ +--------------------------+ 580 + SharingOwner: "Foo" + + Idx: Meas. Owner"Foo " + 581 + SharingMeasureOwner:"PacketLoss"+ + Measure Index: 1 + 582 + + + Metrix Indx: 12 + 583 + SharingGrantedOwner: "Acme" + + + 584 +---------------------------------+ + HistorySqceNdx: 1 + 585 + GMTTimeStampValue + 586 + Value: 5 + 587 +------------------------- + 588 + Idx: Meas. Owner "Foo" + 589 + Mesure Index: 1 + 590 + Metric Index: 12 + 591 + HistorySqceNdx: 2 + 592 + GMTTimeStampValue + 593 + Value: 15 + 594 + Idx: Meas. "Acme" + 595 + Measure Index: 3 + 596 + Metric Index: 14 + 597 + HistorySqceNdx: 1 + 598 + GMTTimeStampValue + 599 + Value: 10 + 600 +--------------------------+ 602 As the aggregated measure table essentially "inherits" from the 603 measure table, one can not create an entry is this table without 604 first creating an entry in the measure table. Likewise, one can not 605 delete an entry in the measure table without first deleting the 606 corresponding row in the aggregated measure table. This logic ensures 607 that there are no "orphaned" table entries in the aggregated measure 608 table. 610 6. IPPM-REPORTING-MIB conceptual presentation 612 6.1. IPPM-REPORTING-MIB diagram 614 Conceptual view of objects configured using the IPPM-REPORTING-MIB 616 +--------------------------------------------------------+ 617 | IPPM-REPORTING-MIB entity | 618 | | 619 | +---------------------+ +-------------------+ | 620 | | | | | | 621 | | Measure scheduler | | Result storage | | 622 | | | | | | 623 | | ^ | | ^ ^^^ | | 624 | | | | | | ||| | | 625 | +----------|----------+ +-|---|||-----------+ | 626 | | | ||| | 627 | +----------|--------------|---|||-----------+ | 628 | | | owner | ||| | | 629 | | | Acces | ||| | | 630 | | | Control | ||| | | 631 | +----------|--------------|---|||-----------+ | 632 | | | ||| | 633 +------------------|--------------|---|||----------------+ 634 | | ||| 635 | | ||| 636 +----------------+ | +----------+-+ ||| +-------------+ 637 | ControlMeasure | | | GetResult | ||| | CreateResult| 638 |----------------+-+ |------------| ||+--+-------------| 639 | | | | || | | 640 | owner | | owner | || | owner | 641 | privateNdx | | privateNdx | || | privateNdx | 642 | metrics | | metric | || | metrics | 643 | scheduler | | timestamp | || | timestamp | 644 | addresses | +------------+ || | value | 645 | status | || +-------------+ 646 +----------------+ || 647 || 648 +---------------------------+| 649 | | 650 +---------+---------+ +------+-----------------+ 651 |GetMeasureResults | |GetMeasureMetricResults | 652 |-------------------| |------------------------| 653 | | | owner | 654 | owner | | privateNdx | 655 | privateNdx | | metric | 656 +-------------------+ +------------------------+ 658 The managed objects of the IPPM-REPORTING-MIB are the measures and 659 the results. 661 6.2. Conceptual programming interface 663 This section describes a conceptual programming interface for the 664 integration of the IPPM-REPORTING-MIB in a point of measure. 666 6.2.1. Measure control 668 A measure is created/deleted/suspended through the ControlMeasure() 669 call. 671 6.2.2. Result log 673 A result of a measure is created in the IPPM-REPORTING-MIB History 674 table using a CreateResult() call. Results belonging to a measure are 675 managed according to the setup of the measure. 677 6.2.3. Reporting 679 Results are reported using the method GetResult(), 680 GetMeasureMetricResults() and GetMeasureResults() respectively to get 681 a singleton result, the singleton result of a metric measure, and 682 finally to get the singleton result of a measure. 684 6.2.4. Logical calls 686 Objects are managed using 5 main primitives: 688 controlMeasure(); 689 CreateResult(); 690 GetResult(); 691 GetMeasureMetricResults(); 692 GetMeasureResults(). 694 6.3. SNMP mapping 696 ControlMeasure() corresponds to a SNMP set-request on a conceptual 697 row of ippmMeasureEntry and on a conceptual row of 698 ippmNetworkMeasureEntry. 700 CreateResult() is a internal interface for adding measure results in 701 the ippmHistoryTable. 703 GetResult() corresponds to an SNMP get-request on a result. 705 GetMeasureMetricResults() corresponds to a SNMP walk on the results 706 of a metric measure subtree. 708 GetMeasureResults() corresponds to a SNMP walk on the results of a 709 measure subtree. 711 7. Measurement architectures 713 There are four main measurement architectures. 715 7.1. Proxy architecture 717 +----+ +----+ 718 |NMS1| |NMS2| 719 +----+ +----+ 720 ^ ^ 721 | | 722 +----------+ +----------+ 723 | | 724 SNMP or Sibling 725 | | 726 v v 727 +--------------------------+ 728 | IPPM-REPORTING-MIB agent | 729 +--------------------------+ 730 ^ ^ 731 | | 732 OWDP-Control 733 | | 734 +----------+ +----------+ 735 | | 736 v v 737 +----------------+ +------------------+ 738 | Packets-Sender |--OWDP-Test-->| Packets-Receiver | 739 +----------------+ +------------------+ 741 In this architecture, the different NMS�s query the IPPM-REPORTING- 742 MIB agent for measurements. The agent controls whether the NMS is 743 granted access to perform the measure requested. Each NMS accesses 744 the results of its measurements in the IPPM-REPORTING-MIB statistics 745 table. 747 The measurement setup/teardown and the data collection are done using 748 the control protocol and the test protocol. 750 In this mode the NMS does not depend either on the control protocol 751 nor on the test protocol. The entities involved in the measurement do 752 not need to implement the IPPM-REPORTING-MIB nor SNMP. This mode 753 allows for lightweight implementation in the point of measure, and 754 also for heterogeneous control protocols to coexist. 756 Finally, the proxy is a checkpoint where measurement activity may be 757 logged, and where access to measurement setups may be tightly 758 controlled. Thus, it provides a reliable architecture to manage the 759 security of a measurement system. 761 7.2. Reporting architecture 763 In this architecture the SNMP protocol is only used to read the results 764 of the measurements in the IPPM-REPORTING-MIB History Table, and also to 765 inform the NMS that an event has occurred. 767 +----+ +----+ 768 |NMS1| |NMS2| 769 +----+ +----+ 770 ^ ^ ^ ^ 771 | | | | 772 SNMP| SNMP| 773 | | | | 774 | | | | 775 | OWDP | OWDP 776 |Control |Control 777 | | | | 778 | | +------------------------------+ 779 | | | | | 780 | | +--|---------------------------+ | 781 | | | | | | 782 | +--|--|------------------------+ | | 783 | | | | | | | 784 +--------+---------------------+ | | 785 | | | | | | | | 786 | | | | | | | | 787 v v v v v v v v 788 +------------------+ +------------------+ 789 |IPPM-REPORTING-MIB| |IPPM-REPORTING-MIB| 790 | agent | | agent | 791 +------------------+ +------------------+ 792 | Packets-Sender |--OWDP-Test-->| Packets-Receiver | 793 +------------------+ +------------------+ 795 The activation of a measure by the control protocol or the test protocol 796 creates a measure in the IPPM-REPORTING-MIB Measure table. The table in 797 question may be not accessible by SNMP. In this case, a list of the 798 measure identifiers (owner, index) is handled by the measurement 799 software. 801 Each timestamped result of the measure is logged on the fly in the IPPM- 802 REPORTING-MIB History table in order to allow read access to the NMS�s 803 and event handling. 805 On completion, the measurement results are managed according to the 806 measure setup: 808 + The results may be sent to an NMS using a SNMP Trap PDU or 809 a SNMP Inform PDU. The NMS may be the sender entity or the 810 control entity; 811 + They may be dropped from the IPPM-REPORTING-MIB History 812 table. 814 In this mode, it is recommended to use an SNMPv2 Inform PDU to send the 815 result because it ensures that the entire block of the result is 816 received. There is no control using SNMP Trap PDU. 818 Also, in this mode, it is recommended to implement the IPPM-REPORTING- 819 MIB Measure table in read only in order to allow an NMS to read the 820 status of their measures. 822 7.3. Gateway architecture 824 The gateway architecture combines the proxy mode and the reporting mode. 826 +-------+ +------+ 827 | NMS1 | | NMS2 | 828 +-------+ +------+ 829 ^ ^ 830 | | 831 SNMP SNMP 832 | | 833 | +----------------------------------------+ 834 | | | 835 +-------------+ +------------------+ 836 | | | | | 837 +----------------------------------------+ | 838 | | | | | | 839 | | v v | | 840 | | +------------------------+ | | 841 | | | IPPM-REPORTING-MIB | | | 842 | | | scheduler | | | 843 | | +------------------------+ | | 844 | | | control server | | | 845 | | +------------------------+ | | 846 | | ^ ^ | | 847 | | | | | | 848 | | OWDP-Control protocol | | 849 | | | | | | 850 | | +-----+ +-------+ | | 851 | | | | | | 852 v v v v v v 853 +-------------+---------+ +--------+-------------+ 854 | IPPM- | Packets | |Packets | IPPM | 855 |REPORTING-MIB| Sender | |Receiver|REPORTING-MIB| 856 | agent | |-OWDP-Test->| | agent | 857 +-------------+---------+ +--------+-------------+ 859 The NMS measurement queries are registered in the IPPM-REPORTING-MIB 860 scheduler and performed by the control and the test protocol. The NMS 861 directly consults the result in the corresponding points of measure. 863 7.4. Security 865 The proxy mode provides flexibility and control of the access to the 866 points of measure, while allowing lightweight control protocol and test 867 protocol implementations in the points of measure. Different security 868 rules may be applied to the NMS domain and to measurement system 869 domains. 871 The reporting mode has 2 security domains: 873 +The control of the measurement setups relies on the control and the 874 test protocol security mechanisms. 875 + The control of access to the results depends on the SNMP security 876 mechanisms. 878 The gateway mode security relies on the security of the proxy mode and 879 of the reporting mode. 881 8. Reporting mode integration with the control and test protocols 883 The IPPM-REPORTING-MIB standardizes the parameters that: 885 + Define the configuration of the IPPM metrics measures; 886 + Define the format of the results of the measure; 887 + Define the report of the IPPM metric measures results. 889 It introduces the concept of owner namespace to allow for fast 890 configuration and reporting across multiple points of measurement. 892 A measure is a distributed object describing a task to be performed by 893 the control and the test protocols. A measure is identified by its owner 894 and its owner index. This identifier is the same in all the points of 895 measure. As the owner chooses the index, there is no need for 896 negotiation between the NMS and the points of measure before activating 897 the measure. 899 A measure is primarily defined by its identifier, the metrics to 900 measure, the description of the end point addresses and the description 901 of the scheduling of the measure. 903 The description of the measure is distributed to the points of measure 904 involved. The distribution may not be synchronized. 906 8.1. Integration 908 The control protocol, test protocol and the IPPM-REPORTING-MIB share the 909 same semantic. 911 The integration of the IPPM-REPORTING-MIB, and the test and control 912 protocols, relies on the use of the conceptual programming interface 913 described in section 6. It consists in pushing the measure 914 setup/teardown parameters and the result values from the measurement 915 software to the IPPM-REPORTING-MIB agent. 917 8.2. Setup of the measure 919 The creation of the measure consists only in transferring the measure 920 description from the measurement software to the MIB. The management of 921 the measure is done using the ControlMeasure(). 923 The protocol, which provides the parameters of the measure to manage, 924 may be the control protocol of the test protocol. 926 Different frameworks may be used to setup a measure. 928 8.2.1. Synchronous setup 930 The control protocol sets up the measure both in the sender and the 931 receiver before the measurement. 933 8.2.2. Asynchronous setup 935 The control protocol sets up the measure only in the sender. In this 936 case, the receiver has a service already activated (or pending )for the 937 typeP of the measurement. 939 As the first test packet includes the description of the measure, it may 940 differ from regular test packets. If the first test packet is not 941 consistent with the regular test packets, it must not be used for 942 performing metrics measurement. 944 8.3. Setup of the measurement report 946 The report description is an extension to the definition of a measure. 947 It describes the event and the data to include in the report. A report 948 is read by an NMS in the ippmReportTable, or pushed to a NMS using a 949 SNMP Trap PDU, a SNMP Inform PDU, an email, or a SMS. 951 The control protocol, or the test protocol, includes the description of 952 the report in the setup of the measure. 954 Different types of reports may be combined: 956 + A trivial report defines the results to be saved in the 957 ippmReportTable; 958 + A basic report defines the host to which the results are 959 pushed on completion of the measure; 960 + An alarm report defines a threshold on the results of the 961 measure. A message is sent to a host when the result raises 962 or fall the threshold; 963 + An SLA report defines a threshold on the results of the 964 measure. The events are filtered using a staircase method. 965 The report consists in the results of the measure (time and 966 value) of the filtered events. The reports are sent at each 967 measure cycle or when the measure completes. 969 8.4. Writing the measurement results in the IPPM-REPORTING-MIB 971 Results have to be written by the measurement task in the agent 972 implementing the IPPM MIB. 974 Adding the results of a measurement consists in the transfer of the 975 result from the measurement software to the agent. The protocol that 976 provides the result may be the control protocol, or the test protocol. 978 Writing a result is done using the CreateResult(). 980 8.5. Report download and upload 982 A report is read in the ippmReportTable using SNMP, or pushed by the 983 IPPM_MIB agent using a SNMP Trap PDU, a SNMP Inform PDU, an email or a 984 SMS. 986 8.6. Default value 988 The default values correspond to Ipv4 best effort. 990 9. Definition 992 IPPM-REPORTING-MIB DEFINITIONS ::= BEGIN 994 IMPORTS 995 MODULE-IDENTITY, 996 NOTIFICATION-TYPE, 997 OBJECT-TYPE, 998 Integer32, 999 Counter32 1000 FROM SNMPv2-SMI 1001 ippm 1002 FROM IPPM-REGISTRY 1003 OwnerString 1004 FROM RMON-MIB 1005 InetAddressType, 1006 InetAddress 1007 FROM INET-ADDRESS-MIB 1008 SnmpAdminString 1009 FROM SNMP-FRAMEWORK-MIB 1010 TimeStamp, 1011 TruthValue, 1012 RowStatus, 1013 StorageType, 1014 TEXTUAL-CONVENTION 1015 FROM SNMPv2-TC 1016 MODULE-COMPLIANCE, 1017 OBJECT-GROUP, 1018 NOTIFICATION-GROUP 1019 FROM SNMPv2-CONF; 1021 ippmReportingMib MODULE-IDENTITY 1022 LAST-UPDATED "200203171200Z" -- March 17, 2002 1023 ORGANIZATION "France Telecom - R&D" 1024 CONTACT-INFO 1025 "Mail : Emile Stephan 1026 France Telecom - R&D, Dpt. CPN 1027 2, Avenue Pierre Marzin 1028 Technopole Anticipa 1029 22307 Lannion Cedex 1030 FRANCE 1031 Tel: + 33 2 96 05 36 10 1032 E-mail: emile.stephan@francetelecom.com 1034 Jessie Jewitt 1035 France Telecom - R&D 1036 801 Gateway Blvd. Suit 500 1037 South San Francisco, CA 94080 1038 Tel : 1 650 875-1524 1039 E-mail : jessie.jewitt@rd.francetelecom.com" 1040 DESCRIPTION 1041 " This memo defines a portion of the Management Information Base (MIB) for use with 1042 network management protocols in TCP/IP-based internets. In particular, it specifies 1043 the objects used for managing the results of the IPPM metrics measurements, alarms and 1044 reporting the measures results. 1045 " 1047 REVISION "200210181200Z" -- 18 October 2002 1048 DESCRIPTION 1049 "General cleanup 1050 Change 5 tables to read write" 1052 ::= { ippm 2 } 1053 -- 1054 -- TEXTUAL-CONVENTION 1055 -- 1057 TimeUnit ::= TEXTUAL-CONVENTION 1058 STATUS current 1059 DESCRIPTION 1060 "A list of time units." 1061 SYNTAX INTEGER { 1062 year(1), 1063 month(2), 1064 week(3), 1065 day(4), 1066 hour(5), 1067 second(6), 1068 ms(7), 1069 us(8), 1070 ns(9) 1071 } 1072 -- 1073 -- 1075 IppmStandardMetrics ::= TEXTUAL-CONVENTION 1076 STATUS current 1077 DESCRIPTION 1078 " Each standard metric is identified in the IPPM-METRICS- 1079 REGISTRY under the node rfc in a chronological order. To permit 1080 several metrics to be performed in a single measure there is an need 1081 to describe in a bit string the metrics to be performed, granted... 1082 This textual convention defines an octet string that gathered in a 1083 bit string a sequence of bits. The bit order corresponds to the order 1084 of the metrics identifiers in the registry. 1085 The first bit of the string is not used. 1087 Example: 1088 One-way-Delay(6) is identified as the leaf number 6 of the node rfc of the 1089 registry. One-way-Packet-Loss(12) is identified as the leaf number 12 of the node 1090 rfc of the registry. A network measure performing both One-way-Delay(6) and One- 1091 way-Packet-Loss(12) will be described as '0000001000001000'b, '0208'B. 1093 " 1094 SYNTAX OCTET STRING 1096 GMTTimeStamp ::= TEXTUAL-CONVENTION 1097 STATUS current 1098 DESCRIPTION 1099 "The value of the ippmSystemTime object at which a specific occurrence 1100 happened. The specific occurrence must be defined in the description of any object 1101 defined using this type. 1103 field octets contents range 1104 ----- ------ -------- ----- 1105 1 1-4 second since 1 Jan 2000 0H00* 0..2^31 - 1 1106 2 5-8 fractional part of the second* 0..2^32 - 1 1107 * the value is in network-byte order 1109 The timestamp format is directly inspired from the NTP timestamp format. 1110 It differs because it counts the second since 1 Jan 2000 0H00 instead of 1 Jan 1900 1111 0H00. The most significant bit of the part that represents the second is reserved. It 1112 will wrap in year 2068 (The NTP timestamp will wrap in year 2036). 1114 This bit is set to indicate if the fractional part of the second contains a precision 1115 field and a synchronization field as initially proposed in the OWAMP draft. 1117 When this bit is not set the resolution is maximal. 1119 The maximal resolution is close to 250 picoseconds. 1121 The precision of the timestamp must be provided in another field. 1122 " 1123 SYNTAX OCTET STRING (SIZE (8)) 1125 TypeP ::= TEXTUAL-CONVENTION 1126 DISPLAY-HINT "1d." 1127 STATUS current 1128 DESCRIPTION 1129 "This textual convention is used to describe the protocol encapsulation list of a 1130 packet, and is used as the value of the SYNTAX clause for the type of the Src and Dst 1131 of an IPPM measure. The RFC2895 specifies a macro for the definition of protocol 1132 identifiers while its companion document, the RFC2896 defines a set of protocol 1133 identifiers. 1135 Notes: An IPPM TypeP does not differ from RMON2 Protocol identifiers, but TypeP usage 1136 in IPPM MIB differs from Protocol identifier usage in RMON2. A IPPM measure is active, 1137 so generally TypeP does not describe the link layer (i.e. ether2...). Valid Internet 1138 packets are sent from Src to Dst. Then the choice of the link layer relies on the 1139 Internet stack. 1141 For example, the RFC2896 defines the protocol identifier 1142 '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 1143 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 1144 for ether2.ip.ipip4.udp. The corresponding TypeP are 1145 '12.0.0.8.0.0.0.0.6.0.0.0.23.3.0.0.0' (ip.tcp.telnet) and 1146 12.0.0.8.0.0.0.0.4.0.0.0.17.3.0.0.0 (ip.ipip4.udp)." 1147 SYNTAX OCTET STRING 1149 IppmReportDefinition ::= TEXTUAL-CONVENTION 1150 STATUS current 1151 DESCRIPTION 1152 "IppmReportDefinition is intended to be used for describing the report 1153 resulting from a measurement. By default, all the results of a measure belong to the 1154 report of this measure. 1156 The first step of the report definition sets up triggers on the value of the 1157 measure, and on the distribution over time of the events generated by these triggers. 1159 The resulting measures corresponding to an event are reported periodically, 1160 or sent in alarms as soon as the event occurs. 1162 The end of the description describes housekeeping tasks. 1164 An action is performed if the corresponding bit is set to 1. 1166 onSingleton(1): 1167 The actions are performed each time a new result of the measure occurs. 1169 onMeasureCycle(2): 1170 The actions are performed on the results of the measure at the end of each cycle of 1171 measure. 1173 onMeasureCompletion(3): 1174 The actions are performed on the results of the measure at the end of the measure. 1176 reportOnlyUptoDownMetricResults(4): 1177 Report the contiguous results that are on opposite sides of the metric threshold. 1179 reportOnlyExceededEventsDuration(5): 1180 Report the current result of a series of contiguous results that exceed the metric 1181 threshold when the duration of the series is over the events duration threshold 1182 seconds. 1184 inIppmReportTable(6): 1185 Store the report in the local ippmReportTable. 1187 inSNMPTrapPDU(7): 1188 Send the report using a SNMP-Trap-PDU. 1190 inSNMPv2TrapPDU(8): 1191 Send the report using a SNMPv2-Trap-PDU. 1193 inInformRequestPDU(9): 1194 Send the report using a SNMP InformRequest-PDU. 1196 inEmail(10): 1197 Send the report using an email. 1199 inSMS(11): 1200 Send the report using a SMS. 1202 clearHistory(12): 1203 Remove all the results corresponding to this measure from the ippmHistoryTable. 1205 clearReport(13): 1206 Remove all the results corresponding to this measure from the ippmReportTable. 1207 " 1209 SYNTAX BITS { 1210 none(0), -- reserved 1211 onSingleton(1), 1212 onMeasureCycle(2), 1213 onMeasureCompletion(3), 1214 reportOnlyUptoDownMetricResults(4), 1215 reportOnlyExceededEventsDuration(5), 1216 inIppmReportTable(6), 1217 inSNMPTrapPDU(7), 1218 inSNMPv2TrapPDU(8), 1219 inInformRequestPDU(9), 1220 inEmail(10), 1221 inSMS(11), 1222 clearHistory(12), 1223 clearReport(13) 1224 } 1226 -- IPPM Mib objects definitions 1228 ippmCompliances OBJECT IDENTIFIER ::= { ippmReportingMib 2 } 1229 ippmSystemGroup OBJECT IDENTIFIER ::= { ippmReportingMib 3 } 1230 ippmOwnersGroup OBJECT IDENTIFIER ::= { ippmReportingMib 4 } 1231 ippmMeasureGroup OBJECT IDENTIFIER ::= { ippmReportingMib 5 } 1232 ippmHistoryGroup OBJECT IDENTIFIER ::= { ippmReportingMib 6 } 1233 ippmNetworkMeasureGroup OBJECT IDENTIFIER ::= { ippmReportingMib 7 } 1234 ippmAggregatedMeasureGroup OBJECT IDENTIFIER ::= { ippmReportingMib 8 } 1235 ippmReportGroup OBJECT IDENTIFIER ::= { ippmReportingMib 9 } 1236 ippmNotifications OBJECT IDENTIFIER ::= { ippmReportingMib 10 } 1238 -- 1239 -- ippmSystemGroup 1240 -- 1241 -- 1243 ippmSystemTime OBJECT-TYPE 1244 SYNTAX GMTTimeStamp 1245 MAX-ACCESS read-only 1246 STATUS current 1247 DESCRIPTION 1248 "The current time of the measurement system." 1249 ::= { ippmSystemGroup 1 } 1251 ippmSystemSynchronizationType OBJECT-TYPE 1252 SYNTAX INTEGER { 1253 other(0), 1254 ntp(1), 1255 gps(2), 1256 cdma(4) 1257 } 1258 MAX-ACCESS read-only 1259 STATUS current 1260 DESCRIPTION 1261 "ippmSystemSynchronizationType describes the mechanism 1262 used to synchronize the system. 1264 Other(0) 1265 The synchronization process must be defined 1266 in the ippmSystemSynchonizationDescription. 1268 Ntp(1) 1269 The system is synchronized using the network 1270 time protocol. The NTP synchronization must be described 1271 in the ippmSystemSynchonizationDescription. 1273 Gps (2) 1274 The system is synchronized using the GPS clocks. 1276 Cdma(4) 1277 The system is synchronized using the CDMA clocks. 1278 " 1279 ::= { ippmSystemGroup 2 } 1281 ippmSystemSynchronizationDescription OBJECT-TYPE 1282 SYNTAX SnmpAdminString 1283 MAX-ACCESS read-only 1284 STATUS current 1285 DESCRIPTION 1286 "The description of the synchronization process." 1287 ::= { ippmSystemGroup 3 } 1289 ippmSystemClockResolution OBJECT-TYPE 1290 SYNTAX Integer32 1291 MAX-ACCESS read-only 1292 STATUS current 1293 DESCRIPTION 1294 "ippmSystemClockResolution provides the precision of the clock used for the measures. 1295 The unit is the picosecond. For example, the clock on an old Unix host might advance 1296 only once every 10 msec, and thus have a resolution of only 10 msec. So its resolution 1297 is 100000 picosecond and the value of ippmSystemClockResolution is 100000." 1299 ::= { ippmSystemGroup 4 } 1301 ippmSystemCurrentSynchronization OBJECT-TYPE 1302 SYNTAX Integer32 1303 MAX-ACCESS read-only 1304 STATUS current 1305 DESCRIPTION 1306 "The index on the last synchronization event in the ippmSynchronizationTable." 1308 ::= { ippmSystemGroup 5 } 1310 ippmSynchronizationTable OBJECT-TYPE 1311 SYNTAX SEQUENCE OF IppmSynchronizationEntry 1312 MAX-ACCESS not-accessible 1313 STATUS current 1314 DESCRIPTION 1315 "This table registers the event related to the synchronization of the point of 1316 measure. Each event is described in an ippmSynchronizationEntry. 1318 ippmSynchronizationTable is mandatory. 1319 ippmSynchronizationTable content is read only. 1320 " 1321 ::= { ippmMeasureGroup 6 } 1323 ippmSynchronizationEntry OBJECT-TYPE 1324 SYNTAX IppmSynchronizationEntry 1325 MAX-ACCESS not-accessible 1326 STATUS current 1327 DESCRIPTION 1328 "An entry describes a modification of the synchronization status. " 1329 INDEX { ippmSynchronizationIndex } 1330 ::= { ippmSynchronizationTable 1 } 1332 IppmSynchronizationEntry ::= 1333 SEQUENCE { 1334 ippmSynchronizationIndex Integer32, 1335 ippmSynchronizationTime GMTTimeStamp, 1336 ippmSynchronizationStratum Integer32 1337 } 1339 ippmSynchronizationIndex OBJECT-TYPE 1340 SYNTAX Integer32 (1..1000) 1341 MAX-ACCESS not-accessible 1342 STATUS current 1343 DESCRIPTION 1344 "An index that identifies the synchronization events in chronological order." 1345 ::= { ippmSynchronizationEntry 1 } 1347 ippmSynchronizationTime OBJECT-TYPE 1348 SYNTAX GMTTimeStamp 1350 MAX-ACCESS read-only 1351 STATUS current 1352 DESCRIPTION 1353 "The time when the synchronization event occurs." 1354 ::= { ippmSynchronizationEntry 2 } 1356 ippmSynchronizationStratum OBJECT-TYPE 1357 SYNTAX Integer32 1358 MAX-ACCESS read-only 1359 STATUS current 1360 DESCRIPTION 1361 "The stratum level of the clock computed when the synchronization event occurs." 1362 ::= { ippmSynchronizationEntry 3 } 1364 ippmPointOfMeasureTable OBJECT-TYPE 1365 SYNTAX SEQUENCE OF IppmPointOfMeasureEntry 1366 MAX-ACCESS not-accessible 1367 STATUS current 1368 DESCRIPTION 1369 " A lookup table that identifies the management software in charge of the point of 1370 measures. 1372 ippmPointOfMeasureTable content is read only. It means that the measurement software 1373 handles the table internally 1375 ippmPointOfMeasureTable is mandatory. 1376 " 1378 ::= { ippmSystemGroup 6 } 1380 ippmPointOfMeasureEntry OBJECT-TYPE 1381 SYNTAX IppmPointOfMeasureEntry 1382 MAX-ACCESS not-accessible 1383 STATUS current 1384 DESCRIPTION 1385 " An entry may be the management address of a middleware in charge of the management 1386 of a set of probes. It may the management address of a probe that contains several 1387 line cards. 1389 An entry describes the capability of a point of measure. The description may make the 1390 use of wildcards to define multiple capabilities. 1391 " 1392 INDEX { ippmPointOfMeasureIndex } 1393 ::= { ippmPointOfMeasureTable 1 } 1395 IppmPointOfMeasureEntry ::= 1396 SEQUENCE { 1397 ippmPointOfMeasureIndex Integer32, 1398 ippmPointOfMeasureMgmtAddress SnmpAdminString, 1399 ippmPointOfMeasureTypePAddress TypeP, 1400 ippmPointOfMeasureAddress OCTET STRING 1401 } 1402 ippmPointOfMeasureIndex OBJECT-TYPE 1403 SYNTAX Integer32 (1.. 65535) 1404 MAX-ACCESS not-accessible 1405 STATUS current 1406 DESCRIPTION 1407 "The index of the entry." 1408 ::= { ippmPointOfMeasureEntry 1 } 1410 ippmPointOfMeasureMgmtAddress OBJECT-TYPE 1411 SYNTAX SnmpAdminString 1412 MAX-ACCESS read-only 1413 STATUS current 1414 DESCRIPTION 1415 " 1416 The management software in charge of this point of measure." 1417 ::= { ippmPointOfMeasureEntry 2 } 1419 ippmPointOfMeasureTypePAddress OBJECT-TYPE 1420 SYNTAX TypeP 1421 MAX-ACCESS read-only 1422 STATUS current 1423 DESCRIPTION 1424 "Defines the type P of the address of the point of measure." 1425 DEFVAL { '04000080001000'H } -- ->ip: 4.0.0.8.0.1.0 1426 ::= { ippmPointOfMeasureEntry 3 } 1428 ippmPointOfMeasureAddress OBJECT-TYPE 1429 SYNTAX OCTET STRING 1430 MAX-ACCESS read-only 1431 STATUS current 1432 DESCRIPTION 1433 "Specifies the address of the point of measure. 1435 It is represented as an octet string with specific semantics and length as identified 1436 by the ippmPointOfMeasureTypePAddress. 1438 For example, if the ippmPointOfMeasureTypePAddress indicates an encapsulation of 'ip', 1439 this object length is 4, followed by the 4 octets of the IP address, in network byte 1440 order." 1441 DEFVAL { '04C0210415'H } -- -> ip: 192.33.4.21 1442 ::= { ippmPointOfMeasureEntry 4} 1444 -- 1445 -- ippmOwnersGroup 1446 -- 1447 -- The ippmOwnersGroup objects are responsible for managing 1448 -- the owners access to the measurements. 1449 -- 1450 -- 1451 ippmOwnersTable OBJECT-TYPE 1452 SYNTAX SEQUENCE OF IppmOwnersEntry 1453 MAX-ACCESS not-accessible 1454 STATUS current 1455 DESCRIPTION 1456 "A management entity wishing to create and activate remote Ippm measurements in an 1457 agent must previously be registered in the ippmOwnersTable. 1459 ippmOwnersTable content is read-create. 1461 ippmOwnersTable contains at least the owner 'monitor'. 1463 ippmOwnersTable is mandatory, excepted if the VACM framework is used. 1464 " 1466 ::= { ippmOwnersGroup 1 } 1468 ippmOwnersEntry OBJECT-TYPE 1469 SYNTAX IppmOwnersEntry 1470 MAX-ACCESS not-accessible 1471 STATUS current 1472 DESCRIPTION 1473 "The description of the resources granted to an SNMP application. 1475 For example, an instance of ippmOwnersOwner with an OwnerString 'acme', which 1476 represents the 14th owner created in ippmOwnersTable would be named 1477 ippmOwnersEntryOwner.14. 1479 Notes: 1481 The ippmOwnersIndex value is a local index managed directly by the agent. The 1482 management application must poll to get the next available index value. 1483 It is not used in anyway in the other IPPM tables." 1485 INDEX { ippmOwnersIndex } 1486 ::= { ippmOwnersTable 1 } 1488 IppmOwnersEntry ::= SEQUENCE { 1489 ippmOwnersOwner SnmpAdminString, 1490 ippmOwnersIndex Integer32, 1491 ippmOwnersGrantedMetrics IppmStandardMetrics, 1492 ippmOwnersGrantedRules BITS, 1493 ippmOwnersIpAddress InetAddressType, 1494 ippmOwnersEmail SnmpAdminString, 1495 ippmOwnersSMS SnmpAdminString, 1496 ippmOwnersStatus OwnerString 1497 } 1499 ippmOwnersIndex OBJECT-TYPE 1500 SYNTAX Integer32 (1.. 65535) 1501 MAX-ACCESS not-accessible 1502 STATUS current 1503 DESCRIPTION 1504 "An arbitrary index that identifies an entry in this table" 1505 ::= { ippmOwnersEntry 1 } 1506 ippmOwnersOwner OBJECT-TYPE 1507 SYNTAX SnmpAdminString 1508 MAX-ACCESS read-create 1509 STATUS current 1510 DESCRIPTION 1511 "The owner described by this entry." 1512 ::= { ippmOwnersEntry 2 } 1514 ippmOwnersGrantedMetrics OBJECT-TYPE 1515 SYNTAX IppmStandardMetrics 1516 MAX-ACCESS read-create 1517 STATUS current 1518 DESCRIPTION 1519 " Defines the metrics granted to an owner." 1520 ::= { ippmOwnersEntry 3 } 1522 ippmOwnersGrantedRules OBJECT-TYPE 1523 SYNTAX BITS { 1524 all(0), 1525 readonly(1), 1526 permanent(2), 1527 sender(3), 1528 receive(4), 1529 report(5), 1530 alarm(6) 1531 } 1532 MAX-ACCESS read-create 1533 STATUS current 1534 DESCRIPTION 1535 "Defines the rules this owner may act on in the current IPPM MIB instance. 1536 all(0): 1537 The owner is granted all the rules. 1538 readonly(1): 1539 The measures (not only the metrics) that this owner may access are 1540 setup by the manager of the point of measure. The owner can not add new measures for 1541 these metrics. The creation and the configuration of the measures corresponding to 1542 these metrics are managed by the manager of the point of measure. 1543 permanent(2): 1544 The measures (not only the metrics) that this owner may access are 1545 determined by the manager of the point of measure. The owner can not add new measures 1546 for these metrics. The creation and the first configuration of the measures 1547 corresponding to these metrics are managed by the manager of the point of measure. The 1548 owner may modify the measures parameters of the entries of the corresponding 1549 ippmMeasureEntry whose access is read-write. 1550 Typically this allows the owner to suspend the measures, to change the beginning and 1551 end of the measures. 1553 sender(3): 1554 The owner may only activate measures for those metrics that send 1555 packets from the current point of measure. This flag is only suitable for network 1556 measures. It shall be ignored for derived metrics. 1557 receiver(2): 1559 The owner may only activate measures for those metrics that receive 1560 packets on the current point of measure. This flag is only suitable for network 1561 measures. It shall be ignored for derived metrics. Such control increases the 1562 security. The owner may not generate packets from the probe. 1564 report(4): 1565 The owner may setup aggregated metrics on the measures 1566 corresponding to these metrics. 1568 alarm(5): 1569 The owner may setup alarms on the results of the measures metrics. 1571 e.g.: 1572 if the owner Acme is granted with the metric Instantaneous-Unidirectional-Connectivity 1573 as a Receiver in the current point of measure, then Acme can not setup a 1574 Instantaneous-Unidirectional-Connectivity to another point of measure. 1575 " 1576 DEFVAL { 1 } 1577 ::= { ippmOwnersEntry 4 } 1579 ippmOwnersIpAddress OBJECT-TYPE 1580 SYNTAX InetAddressType 1581 MAX-ACCESS read-create 1582 STATUS current 1583 DESCRIPTION 1584 "The IP address of the management entity corresponding to this 1585 owner. The address is human readable and is represented using the dot format." 1586 ::= { ippmOwnersEntry 5 } 1588 ippmOwnersEmail OBJECT-TYPE 1589 SYNTAX SnmpAdminString 1590 MAX-ACCESS read-create 1591 STATUS current 1592 DESCRIPTION 1593 "The email address of the management entity corresponding to this 1594 owner." 1595 ::= { ippmOwnersEntry 6 } 1597 ippmOwnersSMS OBJECT-TYPE 1598 SYNTAX SnmpAdminString 1599 MAX-ACCESS read-create 1600 STATUS current 1601 DESCRIPTION 1602 "The SMS phone number of the management entity corresponding to 1603 this owner." 1604 ::= { ippmOwnersEntry 7 } 1606 ippmOwnersStatus OBJECT-TYPE 1607 SYNTAX RowStatus 1608 MAX-ACCESS read-create 1609 STATUS current 1610 DESCRIPTION 1611 "The status of this table entry." 1612 ::= { ippmOwnersEntry 8 } 1614 -- 1615 -- ippmResultSharingTable 1616 -- 1618 ippmResultSharingTable OBJECT-TYPE 1619 SYNTAX SEQUENCE OF IppmResultSharingEntry 1620 MAX-ACCESS not-accessible 1621 STATUS current 1622 DESCRIPTION 1623 " The ippmResultSharingTable controls the access of an owner to the measure results of 1624 other owners. An owner may grant another access to read the result of its measure. 1626 Entries may exist in ippmResultSharingTable even if the measures to be shared are not 1627 yet defined. Deleting a measure entry in the ippmMeasureTable does not delete the 1628 entries corresponding to this measure in the ippmResultSharingTable. 1630 IppmResultSharingTable is optional. 1631 IppmResultSharingTable content is read-create. 1633 If this table is not implemented then the owner has only access to its own measurement 1634 results." 1636 ::= { ippmOwnersGroup 2 } 1638 ippmResultSharingEntry OBJECT-TYPE 1639 SYNTAX IppmResultSharingEntry 1640 MAX-ACCESS not-accessible 1641 STATUS current 1642 DESCRIPTION 1643 "An entry allows an owner to read the results of a measure owned by another owner. 1644 It permits 2 typical usages: 1645 1) Creating derived measurements on these results 1646 2) Reading the results from a remote management station. 1648 Example: if acme.12 is a One-way-Delay(6) measure, Acme may allow Peter to make 1649 derived metrics on the results of this measure. 1650 " 1652 INDEX { ippmResultSharingOwner, ippmResultSharingIndex} 1653 ::= { ippmResultSharingTable 1 } 1655 IppmResultSharingEntry ::= SEQUENCE { 1656 ippmResultSharingOwner OwnerString, 1657 ippmResultSharingIndex Integer32, 1658 ippmResultSharingMeasureOwner OwnerString, 1659 ippmResultSharingMeasureIndex Integer32, 1660 ippmResultSharingGrantedOwner OwnerString, 1661 ippmResultSharingStatus RowStatus 1662 } 1663 ippmResultSharingOwner OBJECT-TYPE 1665 SYNTAX OwnerString 1666 MAX-ACCESS not-accessible 1667 STATUS current 1668 DESCRIPTION 1669 " The owner of this result control entry. Typically the owner who 1670 created this conceptual row." 1671 ::= { ippmResultSharingEntry 1 } 1673 ippmResultSharingIndex OBJECT-TYPE 1674 SYNTAX Integer32 (1.. 65535) 1675 MAX-ACCESS not-accessible 1676 STATUS current 1677 DESCRIPTION 1678 " The index of this result control entry. The value is managed by 1679 the owner. On creation a SNMP error 'inconsistentValue' is returned if this value is 1680 already in use by this owner." 1681 ::= { ippmResultSharingEntry 2 } 1683 ippmResultSharingMeasureOwner OBJECT-TYPE 1684 SYNTAX OwnerString 1685 MAX-ACCESS read-create 1686 STATUS current 1687 DESCRIPTION 1688 "The owner of the measure to be shared. The couple 1689 ippmResultSharingMeasureOwner, ippmResultSharingMeasureIndex identifies absolutely a 1690 measure" 1691 ::= { ippmResultSharingEntry 3 } 1693 ippmResultSharingMeasureIndex OBJECT-TYPE 1694 SYNTAX Integer32 (1.. 65535) 1695 MAX-ACCESS read-create 1696 STATUS current 1697 DESCRIPTION 1698 "The index of the measure to be shared." 1699 ::= { ippmResultSharingEntry 4 } 1701 ippmResultSharingGrantedOwner OBJECT-TYPE 1702 SYNTAX OwnerString 1703 MAX-ACCESS read-create 1704 STATUS current 1705 DESCRIPTION 1707 "The owner who is granted access to the result of the measure 1708 described by the couple ippmResultSharingMeasureOwner, ippmResultSharingMeasureIndex." 1709 ::= { ippmResultSharingEntry 5 } 1711 ippmResultSharingStatus OBJECT-TYPE 1712 SYNTAX RowStatus 1713 MAX-ACCESS read-create 1714 STATUS current 1715 DESCRIPTION 1716 " The status of this table entry. Once the entry status is set to 1717 active." 1718 ::= { ippmResultSharingEntry 6 } 1720 -- 1722 -- 1723 -- 1724 -- ippmMeasureGroup 1725 -- 1726 -- 1727 -- 1729 ippmMetricsTable OBJECT-TYPE 1730 SYNTAX SEQUENCE OF IppmMetricsEntry 1731 MAX-ACCESS not-accessible 1732 STATUS current 1733 DESCRIPTION 1734 "This table describes the current implementation and is mandatory. Each IPPM 1735 standardized metric identified in the IPPM-METRICS-REGISTRY must be described in the 1736 table. The index of the metric corresponds to the node number of the metric in the rfc 1737 subtree of the IPPM-METRICS-REGISTRY. That provides a metric with the same index value 1738 in any IPPM REPORTING MIB implementations. 1740 ippmMetricsTable is mandatory. 1741 ippmMetricsTable content is read only. 1742 " 1743 ::= { ippmMeasureGroup 1 } 1745 ippmMetricsEntry OBJECT-TYPE 1746 SYNTAX IppmMetricsEntry 1747 MAX-ACCESS not-accessible 1748 STATUS current 1749 DESCRIPTION 1750 "An entry describes the static capabilities of a metric implementation." 1751 INDEX { ippmMetricsIndex } 1752 ::= { ippmMetricsTable 1 } 1754 IppmMetricsEntry ::= 1755 SEQUENCE { 1756 ippmMetricsIndex Integer32, 1757 ippmMetricsCapabilities INTEGER, 1758 ippmMetricUnit INTEGER, 1759 ippmMetricsDescription SnmpAdminString, 1760 ippmMetricsMaxHistorySize Integer32 1761 } 1763 ippmMetricsIndex OBJECT-TYPE 1764 SYNTAX Integer32 (1.. 65535) 1765 MAX-ACCESS not-accessible 1766 STATUS current 1767 DESCRIPTION 1768 "ippmMetricsIndex defines an unambiguous index for each standardized metric. Its value 1769 is the value of the node of the metric in the IPPM-REPORTING-MIB metrics registry 1770 ippmMib.metrics.rfc. 1771 Each metric registered in the standard registry must be present in this table. 1772 This index is used to identify the metric calculated between the IPPM-REPORTING-MIB 1773 entities involved in the measure. 1774 Example: 1775 The index of the metric onewayPacketLossAverage which is registered as 1776 ippmMib.metrics.rfc.onewayPacketLossAverage will always have the value 14." 1777 ::= { ippmMetricsEntry 1 } 1779 ippmMetricsCapabilities OBJECT-TYPE 1780 SYNTAX INTEGER { 1781 notImplemented(0), 1782 implemented(1) 1783 } 1784 MAX-ACCESS read-only 1785 STATUS current 1786 DESCRIPTION 1787 "notImplemented 1788 the metric is not implemented. 1789 implemented 1790 the metric is implemented." 1791 DEFVAL { implemented } 1792 ::= { ippmMetricsEntry 2 } 1794 ippmMetricUnit OBJECT-TYPE 1795 SYNTAX INTEGER { 1796 noUnit(0), 1797 second(1), 1798 ms(2), 1799 us(3), 1800 ns(4), 1801 percentage(5), 1802 packets(6), 1803 byte(7), 1804 kbyte(8), 1805 megabyte(9) 1806 } 1807 MAX-ACCESS read-only 1808 STATUS current 1809 DESCRIPTION 1810 "The unit used in the current entity for the results of the measurement of this 1811 metric." 1812 ::= { ippmMetricsEntry 3 } 1814 ippmMetricsDescription OBJECT-TYPE 1815 SYNTAX SnmpAdminString 1816 MAX-ACCESS read-only 1817 STATUS current 1818 DESCRIPTION 1819 "A textual description of the metric implementation." 1820 ::= { ippmMetricsEntry 4 } 1822 ippmMetricsMaxHistorySize OBJECT-TYPE 1823 SYNTAX Integer32 1824 MAX-ACCESS read-only 1825 STATUS current 1826 DESCRIPTION 1827 "Specifies the maximum number of results that a metric measure can 1828 save in the ippmHistoryTable." 1829 DEFVAL { 200 } 1830 ::= { ippmMetricsEntry 5 } 1832 -- 1833 -- ippmMeasureTable 1834 -- 1835 -- 1837 ippmMeasureTable OBJECT-TYPE 1838 SYNTAX SEQUENCE OF IppmMeasureEntry 1839 MAX-ACCESS not-accessible 1840 STATUS current 1841 DESCRIPTION 1842 "The table of all the IPPM measures which are running in the device. They may not all 1843 be active. 1845 A measure consists of a subset of metrics to compute. The results of the measure may 1846 be saved in the ippmHistoryTable. The configuration of the measure sets the size of 1847 the history requested in ippmMeasureHystorySize. 1849 The maximum number of MIB objects to be collected in the portion of ippmHistoryTable 1850 associated with this metric depends on the value of the ippmMetricMaxHistorySize. 1852 The value of each metric ippmMeasureHystorySize must not be over the value of 1853 ippmMetricMaxHistorySize corresponding to this metric in the ippmMetricTable. 1855 The ippmMeasureTable is mandatory. 1857 ippmMeasureTable content is read-create. The table is handled internally by the 1858 measurement software for network measures. 1860 The setup of network is not permitted through the IPPM REPORTING MIB. OWAP provides a 1861 setup protocol to enable and teardown networks measures. 1862 " 1863 ::= { ippmMeasureGroup 2 } 1865 ippmMeasureEntry OBJECT-TYPE 1866 SYNTAX IppmMeasureEntry 1867 MAX-ACCESS not-accessible 1868 STATUS current 1869 DESCRIPTION 1870 "The measure entries are created/deleted internally by the measurement software. 1872 " 1873 INDEX { ippmMeasureOwner, ippmMeasureIndex } 1874 ::= { ippmMeasureTable 1 } 1876 IppmMeasureEntry ::= 1877 SEQUENCE { 1878 ippmMeasureOwner OwnerString, 1879 ippmMeasureIndex Integer32, 1880 ippmMeasureName SnmpAdminString, 1881 ippmMeasureMetrics IppmStandardMetrics, 1882 ippmMeasureBeginTime GMTTimeStamp, 1883 ippmMeasureClockPeriodUnit TimeUnit, 1884 ippmMeasureClockPeriod Integer32, 1885 ippmMeasureDurationUnit TimeUnit, 1886 ippmMeasureDuration Integer32, 1887 ippmMeasureHystorySize Integer32, 1888 ippmMeasureStorageType StorageType, 1889 ippmMeasureStatus RowStatus 1890 } 1892 ippmMeasureOwner OBJECT-TYPE 1893 SYNTAX OwnerString 1894 MAX-ACCESS not-accessible 1895 STATUS current 1896 DESCRIPTION 1897 "The owner who has configured this entry." 1898 DEFVAL { "acme" } 1899 ::= { ippmMeasureEntry 1 } 1901 ippmMeasureIndex OBJECT-TYPE 1902 SYNTAX Integer32 (1.. 65535) 1903 MAX-ACCESS not-accessible 1904 STATUS current 1905 DESCRIPTION 1906 "The owner index of the measure. The value is managed by the owner." 1907 ::= { ippmMeasureEntry 2 } 1909 ippmMeasureName OBJECT-TYPE 1910 SYNTAX SnmpAdminString 1911 MAX-ACCESS read-create 1912 STATUS current 1913 DESCRIPTION 1914 "The name of the instance of the metric. It illustrates the specificity of the metric 1915 and includes the metric and the typeP. 1917 example: IP-port-HTTP-connectivity" 1918 ::= { ippmMeasureEntry 3 } 1920 ippmMeasureMetrics OBJECT-TYPE 1921 SYNTAX IppmStandardMetrics 1922 MAX-ACCESS read-create 1923 STATUS current 1924 DESCRIPTION 1925 "Defines the metrics to compute within this measure. A measure may be configured for 1926 the result of different metric singletons to be archived in the ippmHistoryTable. The 1927 ippmMetricsIndex of the created result has the value of the bit index of the 1928 corresponding ippmMeasureMetrics as explained above in the IppmMetricsEntry 1929 definition. 1931 Example: 1932 A measure asking for One-way-Delay(6) and One-way-Packet-Loss(12) generated a flow of 1933 singletons which are logged in the ippmHistoryTable. The singletons created for the 1934 One-way-Delay measure have a value of IppmMetricsIndex of 6 while the created 1935 singletons for the One-way-Packet-Loss measure have a value of IppmMetricsIndex of 1936 12." 1937 DEFVAL { { one-way-Delay, one-way-Packet-Loss } } 1938 ::= { ippmMeasureEntry 4 } 1940 ippmMeasureBeginTime OBJECT-TYPE 1941 SYNTAX GMTTimeStamp 1942 MAX-ACCESS read-create 1943 STATUS current 1944 DESCRIPTION 1945 "Specifies the time at which the measure starts." 1946 ::= { ippmMeasureEntry 5 } 1948 ippmMeasureClockPeriodUnit OBJECT-TYPE 1949 SYNTAX TimeUnit 1950 MAX-ACCESS read-create 1951 STATUS current 1952 DESCRIPTION 1953 "Specifies the unit of the measure period." 1954 DEFVAL { second } 1955 ::= { ippmMeasureEntry 6 } 1957 ippmMeasureClockPeriod OBJECT-TYPE 1958 SYNTAX Integer32 1959 MAX-ACCESS read-create 1960 STATUS current 1961 DESCRIPTION 1962 "Specifies the amount of time between 2 measurement action intervals. The action is 1963 specific to the semantic of the measure. 1965 Network metrics: 1967 The ippmNetworkMeasureClockPattern transforms the flow of periodical instants as a 1968 flow of unpredictable instants of measurement packet emission. 1970 As the source and the sink share the definition of the clock of the measure, as the 1971 sending timestamp is part of the measurement packet, the sink have the information to 1972 verify that the stream of packets generated by the source respects the clock law. 1974 Aggregated metrics: 1976 They are performed periodically on a sequence of results of other measures. The period 1977 corresponds to the interval between two successive computations of the metric. The 1978 value of ippmHistoryTimestamp result of a aggregated metric computed corresponds to 1979 the value of the ippmHistoryTimestamp of the last metric result of the sequence used 1980 in to compute the aggregated metric." 1981 DEFVAL { 60 } 1982 ::= { ippmMeasureEntry 7 } 1984 ippmMeasureDurationUnit OBJECT-TYPE 1985 SYNTAX TimeUnit 1987 MAX-ACCESS read-create 1988 STATUS current 1989 DESCRIPTION 1990 "Specifies the unit of the measure duration." 1991 DEFVAL { second } 1992 ::= { ippmMeasureEntry 8 } 1994 ippmMeasureDuration OBJECT-TYPE 1995 SYNTAX Integer32 1996 MAX-ACCESS read-create 1997 STATUS current 1998 DESCRIPTION 1999 "Specifies the duration of the measure." 2000 DEFVAL { 120 } 2001 ::= { ippmMeasureEntry 9 } 2003 ippmMeasureHystorySize OBJECT-TYPE 2004 SYNTAX Integer32 2005 MAX-ACCESS read-create 2006 STATUS current 2007 DESCRIPTION 2008 "Specifies the maximum number of results saved for each metric of this measure. The 2009 history of each metric is managed as a circular table. The newest result overwrites 2010 the oldest one when the history granted to this metric measure is full. 2012 The management of the results may be optimized if synchronized with the reports steps 2013 of this measure. 2014 " 2015 DEFVAL { 120 } 2016 ::= { ippmMeasureEntry 10 } 2018 ippmMeasureStorageType OBJECT-TYPE 2019 SYNTAX StorageType 2020 MAX-ACCESS read-create 2021 STATUS current 2022 DESCRIPTION 2023 "This object defines whether this row and the measure 2024 controlled by this row are kept in volatile storage and 2025 lost upon reboot or if this row is backed up by 2026 non-volatile or permanent storage. 2027 Possible values are: other(1), volatile(2), nonVolatile(3), permanent(4), readOnly(5)" 2029 DEFVAL { nonVolatile } 2030 ::= { ippmMeasureEntry 11 } 2032 ippmMeasureStatus OBJECT-TYPE 2033 SYNTAX RowStatus 2034 MAX-ACCESS read-create 2035 STATUS current 2036 DESCRIPTION 2037 "The status of this table entry. Once the entry status is set to active, the associate 2038 entry cannot be modified." 2039 ::= { ippmMeasureEntry 12 } 2041 -- 2042 -- ippmHistoryGroup 2043 -- 2044 -- 2046 -- 2047 -- ippmHistoryTable 2048 -- 2050 ippmHistoryTable OBJECT-TYPE 2051 SYNTAX SEQUENCE OF IppmHistoryEntry 2052 MAX-ACCESS not-accessible 2053 STATUS current 2054 DESCRIPTION 2055 "The table of the results of the measures." 2057 ::= { ippmHistoryGroup 1 } 2059 ippmHistoryEntry OBJECT-TYPE 2060 SYNTAX IppmHistoryEntry 2061 MAX-ACCESS not-accessible 2062 STATUS current 2063 DESCRIPTION 2065 "An ippmHistoryEntry entry is one of the results of a measure identified by the index 2066 members ippmMeasureOwner and ippmMeasureIndex. 2068 In the index : 2070 + ippmMeasureOwner and ippmMeasureIndex identify the ippmMeasureEntry on 2071 whose behalf this entry was created 2072 + IppmMetricsIndex identifies the ippmMetricsEntry of the metric to measure 2073 + ippmHistorySqceNdx value is the absolute time when the result of the metric 2074 was measured. 2076 The ippmHistoryTimestamp value is the absolute time when the ippmHistoryValue was 2077 performed. 2079 IppmHistoryValue is the value of the metric measured at the time ippmHistoryTimestamp. 2081 Example: 2083 A one way delay measure is created by the entity 'acme' using the owner index 1 and 2084 setting the 6th bit (corresponding to One-way-Delay) of ippmMeasureMetrics to 1. 2085 Consider that the first result of the one way delay measured for acme on the day 15 of 2086 June at 8h20mn 10s 50ms is 23. The result is identified as the singleton 2087 ippmHistoryValue.acme.1.6.1 and stored with value 23. 2089 Its value may be retrieved using a get-next(ippmHistoryValue.acme.1.6) which returns 2090 (ippmHistoryValue.acme.1.6.1 == 23). The IppmMetricsIndex value of '6' corresponds to 2091 the 6th metric of ippmMetricsTable which is Type-P-One-way-Delay. 2092 " 2093 INDEX { ippmMeasureOwner, ippmMeasureIndex, ippmMetricsIndex, 2094 ippmHistorySqceNdx } 2095 ::= { ippmHistoryTable 1 } 2097 IppmHistoryEntry ::= 2098 SEQUENCE { 2099 ippmHistorySqceNdx Integer32, 2100 ippmHistoryTimestamp GMTTimeStamp, 2101 ippmHistoryValue Integer32 2102 } 2103 ippmHistorySqceNdx OBJECT-TYPE 2104 SYNTAX Integer32 (0..65536) 2105 MAX-ACCESS not-accessible 2106 STATUS current 2107 DESCRIPTION 2109 " ippmHistorySqceNdx is the sequence index of the measurement 2110 results of the measure of a metric. 2112 Network metrics: 2114 It's the sequence index of a measurement packet. Typically, it identifies the order of 2115 the packet in the stream of packets sends by the source. 2117 Aggregated metrics: 2119 It is the sequence index of the aggregated metric results computed. 2120 " 2121 ::= { ippmHistoryEntry 1 } 2123 ippmHistoryTimestamp OBJECT-TYPE 2124 SYNTAX GMTTimeStamp 2125 MAX-ACCESS read-only 2126 STATUS current 2127 DESCRIPTION 2128 "The instant of the measure of the result." 2129 ::= { ippmHistoryEntry 2 } 2131 ippmHistoryValue OBJECT-TYPE 2132 SYNTAX Integer32 2133 MAX-ACCESS read-only 2134 STATUS current 2135 DESCRIPTION 2137 "The value of the measure." 2138 ::= { ippmHistoryEntry 3 } 2140 -- 2141 -- ippmNetworkMeasureGroup 2142 -- 2144 -- 2145 -- 2146 -- ippmNetworkMeasureTable 2147 -- 2148 -- 2150 ippmNetworkMeasureTable OBJECT-TYPE 2151 SYNTAX SEQUENCE OF IppmNetworkMeasureEntry 2152 MAX-ACCESS not-accessible 2153 STATUS current 2154 DESCRIPTION 2155 "A entry is a measure which performs network measures and provides a flow of results. 2157 This table extends the ippmMeasureTable. A network measure is a specific measure. 2159 It performs several metric measurements per packet exchange. Each step of a measure 2160 produces a singleton result per metric. The time of the measure and the value of the 2161 metric are saved in the ippmHistoryTable." 2162 ::= { ippmNetworkMeasureGroup 1 } 2164 ippmNetworkMeasureEntry OBJECT-TYPE 2165 SYNTAX IppmNetworkMeasureEntry 2166 MAX-ACCESS not-accessible 2167 STATUS current 2168 DESCRIPTION 2169 " Typically the configuration operation sets both the values of the new 2170 ippmMeasureEntry and of the new IppmNetworkMeasureEntry. 2172 IppmNetworkMeasureTable is mandatory. 2174 IppmNetworkMeasureTable content is read only. It means that the measurement software 2175 handles the table internally. The setup of network is not permitted through the IPPM 2176 REPORTING MIB. OWAP provides a setup protocol to enable and teardown networks 2177 measures. 2179 The ippmMeasureMetrics is set to a list of metrics to be computed from the same raw 2180 packet exchange. Each step of measurement delivers a singleton per chosen metric. 2181 Results are timestamped and saved in the ippmHistoryTable. 2183 The ippmNetworkMeasureTable typical usage consists is providing network measure 2184 indexes to permits aggregated measure to perform aggregation on the results of network 2185 measures. 2186 An obvious usage of the ippmNetworkMeasureTable consists in the verification of the 2187 network measures states." 2188 INDEX { ippmMeasureOwner, ippmMeasureIndex } 2189 ::= { ippmNetworkMeasureTable 1 } 2191 IppmNetworkMeasureEntry ::= 2192 SEQUENCE { 2193 ippmNetworkMeasureSrcTypeP TypeP, 2194 ippmNetworkMeasureSrc OCTET STRING, 2195 ippmNetworkMeasureDstTypeP TypeP, 2196 ippmNetworkMeasureDst OCTET STRING, 2197 ippmNetworkMeasureClockPattern OCTET STRING, 2198 ippmNetworkMeasureTimeoutDelay Integer32, 2199 ippmNetworkMeasureL3PacketSize Integer32, 2200 ippmNetworkMeasureDataPattern OCTET STRING 2201 } 2203 ippmNetworkMeasureSrcTypeP OBJECT-TYPE 2204 SYNTAX TypeP 2205 MAX-ACCESS read-only 2206 STATUS current 2207 DESCRIPTION 2208 "Defines the type P of the source address of the packets sent by the measure." 2209 DEFVAL { '04000080001000'H } -- ->ip: 4.0.0.8.0.1.0 2210 ::= { ippmNetworkMeasureEntry 1 } 2212 ippmNetworkMeasureSrc OBJECT-TYPE 2213 SYNTAX OCTET STRING 2214 MAX-ACCESS read-only 2215 STATUS current 2216 DESCRIPTION 2217 "Specifies the address of the source of the measure. 2219 It is represented as an octet string with specific semantics and length as identified 2220 by the ippmNetworkMeasureSrcTypeP. 2222 For example, if the ippmNetworkMeasureSrcTypeP indicates an encapsulation of 'ip', 2223 this object length is 4, followed by the 4 octets of the IP address, in network byte 2224 order." 2225 DEFVAL { '04C0210415'H } -- -> ip: 192.33.4.21 2226 ::= { ippmNetworkMeasureEntry 2} 2228 ippmNetworkMeasureDstTypeP OBJECT-TYPE 2229 SYNTAX TypeP 2230 MAX-ACCESS read-only 2231 STATUS current 2232 DESCRIPTION 2233 "Defines the type P of the destination address of the packets sent 2234 by the measure." 2235 DEFVAL { '04000080001000'H } -- ->ip: 4.0.0.8.0.1.0 2236 ::= { ippmNetworkMeasureEntry 3 } 2237 ippmNetworkMeasureDst OBJECT-TYPE 2238 SYNTAX OCTET STRING 2239 MAX-ACCESS read-only 2240 STATUS current 2241 DESCRIPTION 2242 "Specifies the address of the destination of the measure. 2244 It is represented as an octet string with specific semantics and length as identified 2245 by the ippmNetworkMeasureDstTypeP. 2247 For example, if the ippmNetworkMeasureDstTypeP indicates an encapsulation of 'ip', 2248 this object length is 4, followed by the 4 octets of the IP address, in network byte 2249 order." 2250 DEFVAL { '04C0220414'H } -- -> ip: 192.34.4.20 2251 ::= { ippmNetworkMeasureEntry 4 } 2253 ippmNetworkMeasureClockPattern OBJECT-TYPE 2254 SYNTAX OCTET STRING 2255 MAX-ACCESS read-only 2256 STATUS current 2257 DESCRIPTION 2258 "This cyclic clock shapes the profile of the instants of measurement action provided 2259 by ippmMeasureClockPeriod according to an arbitrary distribution law. The clock 2260 resolution is ippmMeasureClockPeriod. The bits of the clock pattern set to the value 1 2261 determine the valid instants of measurement action. A measure is to be processed if 2262 and only if the current bit value is 1. 2263 This pseudo-random clock pattern allows the configuration by the NMS of numerous kind 2264 of time sampling law such as periodic, pseudo random or Poisson. 2266 The source of the measure sends the stream of measurement packets synchronously with 2267 the stream of instants selected by the clock pattern sampling. 2268 " 2269 DEFVAL { 11111111} -- 100% periodic 2270 ::= { ippmNetworkMeasureEntry 5 } 2272 ippmNetworkMeasureTimeoutDelay OBJECT-TYPE 2273 SYNTAX Integer32 2274 MAX-ACCESS read-only 2275 STATUS current 2276 -- UNITS "Milliseconds" 2277 DESCRIPTION 2278 "Specifies the delay after which the packet is considered lost by 2279 the sink." 2280 DEFVAL { 1 } 2281 ::= { ippmNetworkMeasureEntry 6 } 2283 ippmNetworkMeasureL3PacketSize OBJECT-TYPE 2284 SYNTAX Integer32 2285 MAX-ACCESS read-only 2286 STATUS current 2287 DESCRIPTION 2288 "Specifies the size of the packets sent at the last network layer in regards to the 2289 TypeP definition." 2291 DEFVAL { 64 } 2292 ::= { ippmNetworkMeasureEntry 7 } 2294 ippmNetworkMeasureDataPattern OBJECT-TYPE 2295 SYNTAX OCTET STRING 2296 MAX-ACCESS read-only 2297 STATUS current 2298 DESCRIPTION 2299 "The current field defines the round robin pattern used to fill the packet." 2300 DEFVAL { 'FF'H } 2301 ::= { ippmNetworkMeasureEntry 8 } 2303 -- 2304 -- 2305 -- ippmAggregatedMeasureGroup 2306 -- 2307 -- 2308 -- 2309 -- 2310 -- ippmAggregatedMeasureTable 2311 -- 2312 -- 2314 ippmAggregatedMeasureTable OBJECT-TYPE 2315 SYNTAX SEQUENCE OF IppmAggregatedMeasureEntry 2316 MAX-ACCESS not-accessible 2317 STATUS current 2318 DESCRIPTION 2319 " This table extends the ippmMeasureTable. 2320 An aggregated measure summarizes the results of previous network or aggregated 2321 measures. The results may be saved in the ippmHistoryTable. 2323 Each step of the calculation for the measure produces a singleton result per metric." 2324 ::= { ippmAggregatedMeasureGroup 1 } 2326 ippmAggregatedMeasureEntry OBJECT-TYPE 2327 SYNTAX IppmAggregatedMeasureEntry 2328 MAX-ACCESS not-accessible 2329 STATUS current 2330 DESCRIPTION 2331 "Typically the configuration operation sets both the values of the new 2332 ippmMeasureEntry and of the new IppmAggregatedMeasureEntry. 2334 ippmAggregatedMeasureTable is mandatory. 2336 ippmAggregatedMeasureTable content is read only. It means that the measure software 2337 handles the table internally. 2339 The ippmMeasureMetrics defines the metric to compute. 2340 The results of the measure to summarize are identified by: 2341 + ippmAggregatedMeasureHistoryOwner, 2342 + ippmAggregatedMeasureHistoryOwnerIndex and 2343 + ippmAggregatedMeasureHistoryMetric 2345 The aggregated task starts at ippmMeasureBeginTime and ends after ippmMeasureDuration. 2346 An aggregated result is performed and saved in the ippmHistoryTable for each 2347 ippmMeasureClockPeriod tick. 2348 " 2349 INDEX { ippmMeasureOwner, ippmMeasureIndex } 2350 ::= { ippmAggregatedMeasureTable 1 } 2352 IppmAggregatedMeasureEntry ::= 2353 SEQUENCE { 2354 ippmAggregatedMeasureHistoryOwner OwnerString, 2355 ippmAggregatedMeasureHistoryOwnerIndex Integer32, 2356 ippmAggregatedMeasureHistoryMetric Integer32, 2357 ippmAggregatedMeasureStatus RowStatus 2358 } 2360 ippmAggregatedMeasureHistoryOwner OBJECT-TYPE 2361 SYNTAX OwnerString 2362 MAX-ACCESS read-create 2363 STATUS current 2364 DESCRIPTION 2365 "The owner of the measure to summarize. " 2366 ::= { ippmAggregatedMeasureEntry 1 } 2368 ippmAggregatedMeasureHistoryOwnerIndex OBJECT-TYPE 2369 SYNTAX Integer32 (1.. 65535) 2370 MAX-ACCESS read-create 2371 STATUS current 2372 DESCRIPTION 2373 "The owner index of the measure to summarize. " 2374 ::= { ippmAggregatedMeasureEntry 2 } 2376 ippmAggregatedMeasureHistoryMetric OBJECT-TYPE 2377 SYNTAX Integer32 2378 MAX-ACCESS read-create 2379 STATUS current 2380 DESCRIPTION 2381 "The metric of the measure to summarize. " 2382 ::= { ippmAggregatedMeasureEntry 3 } 2384 ippmAggregatedMeasureStatus OBJECT-TYPE 2385 SYNTAX RowStatus 2386 MAX-ACCESS read-create 2387 STATUS current 2388 DESCRIPTION 2389 "The status of this table entry. Once the entry status is set to active, the associate 2390 entry cannot be modified." 2391 ::= { ippmAggregatedMeasureEntry 4 } 2392 -- 2393 -- ippmReportGroup 2394 -- 2396 -- 2397 -- 2398 -- ippmReportSetupTable 2399 -- 2400 -- 2402 ippmReportSetupTable OBJECT-TYPE 2403 SYNTAX SEQUENCE OF IppmReportSetupEntry 2404 MAX-ACCESS not-accessible 2405 STATUS current 2406 DESCRIPTION 2407 "The ippmReportSetupTable is a list of definition of reports. It defines the results 2408 of a network or aggregated measures that are to be reported. A report is saved in the 2409 ippmReportTable, or sent to an application using a SNMP Trap, a SNMP inform PDU, an 2410 email or a SMS. The reporting task is not intended to be a batch action processed at 2411 the end of the measure. It is coupled with threshold detections and event filtering to 2412 deliver application level events and data, while preserving scalability. 2414 It extends the definition of a measure: the definition of a measure may include the 2415 definition of a report." 2416 ::= { ippmReportGroup 1 } 2418 ippmReportSetupEntry OBJECT-TYPE 2419 SYNTAX IppmReportSetupEntry 2420 MAX-ACCESS not-accessible 2421 STATUS current 2422 DESCRIPTION 2423 "The report applies to the results of the measure which is extended by the current 2424 report definition. 2426 Typically the creation of a report sets both the values of the new measure and those 2427 of the new IppmReportSetupEntry. 2428 The ippmReportSetupDefinition describes the data and the events to include in the 2429 report. The definition consists in a list of tasks to perform on the results of the 2430 measure." 2431 INDEX { ippmMeasureOwner, ippmMeasureIndex } 2432 ::= { ippmReportSetupTable 1 } 2434 IppmReportSetupEntry ::= 2435 SEQUENCE { 2436 ippmReportSetupDefinition IppmReportDefinition, 2437 ippmReportSetupMetricThreshold Integer32, 2438 ippmReportSetupEventsDurationThreshold Integer32, 2439 ippmReportSetupNMS SnmpAdminString, 2440 ippmReportSetupStatus RowStatus 2441 } 2443 ippmReportSetupDefinition OBJECT-TYPE 2444 SYNTAX IppmReportDefinition 2445 MAX-ACCESS read-create 2446 STATUS current 2447 DESCRIPTION 2448 "The description of the events and actions that are used in the definition of 2449 the report. 2450 Send the report using the type of message selected by the bits 8 to 12. The 2451 report consists of the results of the measure which have been saved in the 2452 ippmReportTable. If the onEventSendReport(7) bit is unset, the report is not saved. 2454 The message sent is a notification defined in the ippmNotifications node. The 2455 notification sent depends on the step of the measure: 2457 + Singleton events are sent using the notification ippmSingletonAlarm 2458 + Exceeded events durations are sent using the notification 2459 ippmEventsDurationExceededAlarm 2460 + A report of a cycle of measure is sent using the notification 2461 ippmCycleOfMeasureReport 2462 + A report of a complete measure is sent using the notification 2463 ippmCompletedMeasureReport 2465 Example 1: 2466 The setup of an alarm to be sent to the owner in a SNMP Trap each time the 2467 staircase crosses the metric threshold value of 5: 2469 ippmReportSetupMetricThreshold 5 2470 ippmReportSetupDefinition { 2471 onSingleton(1), 2472 reportOnlyUptoDownMetricResults(4), 2473 inSNMPTrapPDU(8) 2474 } 2476 Example 2: 2477 The setup of a report to be sent to the owner in a SNMP informRequestPDU per 2478 measure cycle. It reports the staircase values corresponding to a metric threshold of 2479 5: 2481 ippmReportSetupMetricThreshold 5 2482 ippmReportSetupDefinition { 2483 onMeasureCycle(2), 2484 reportOnlyUptoDownMetricResults(4), 2485 inInformRequestPDU(10), 2486 clearHistory(13) 2487 } 2489 Default report: 2490 The default report provides the control protocol with an implicit mechanism 2491 to forward the result of a cycle of measure to the owner of the measure while deleting 2492 the results from the ippmHistoryTable on reception of the response to the 2493 InformRequestPDU : 2495 ippmReportSetupDefinition { 2496 onMeasureCycle(2), 2497 inInformRequestPDU(10), 2498 clearHistory(13) 2499 } 2500 " 2501 DEFVAL { { onMeasureCycle, inInformRequestPDU, clearHistory } } ::= { 2502 ippmReportSetupEntry 1 } 2504 ippmReportSetupMetricThreshold OBJECT-TYPE 2505 SYNTAX Integer32 2506 MAX-ACCESS read-create 2507 STATUS current 2508 DESCRIPTION 2509 "An event is generated when the result of the measure exceeds the value of 2510 ippmReportSetupMetricThreshold. 2511 The threshold has the same unit as the metric. The metric unit is recorded in 2512 the object ippmMetricUnit of this metric entry in the ippmMetricTable. 2513 " 2514 ::= { ippmReportSetupEntry 2 } 2516 ippmReportSetupEventsDurationThreshold OBJECT-TYPE 2517 SYNTAX Integer32 2518 UNITS "Seconds" 2519 MAX-ACCESS read-create 2520 STATUS current 2521 DESCRIPTION 2522 "An event is generated when the duration of a series of results, which are 2523 continuously over the metric threshold, cross over the duration of the 2524 ippmReportSetupEventsDurationThreshold. 2525 " 2526 DEFVAL { 15 } 2527 ::= { ippmReportSetupEntry 3 } 2529 ippmReportSetupNMS OBJECT-TYPE 2530 SYNTAX SnmpAdminString 2531 MAX-ACCESS read-create 2532 STATUS current 2533 DESCRIPTION 2534 "The recipient of the report may be provided in the setup. By default the 2535 recipient of the report is the owner of the measure. Its addresses are recorded in the 2536 ippmOwnersTable. 2537 The type of ippmReportSetupNMS is not InetAddress because the report may be sent using 2538 SMS or fax. 2539 " 2540 ::= { ippmReportSetupEntry 4 } 2542 ippmReportSetupStatus OBJECT-TYPE 2543 SYNTAX RowStatus 2544 MAX-ACCESS read-create 2545 STATUS current 2546 DESCRIPTION 2547 "The status of this table entry. " 2548 ::= { ippmReportSetupEntry 5 } 2550 -- 2551 -- ippmReportTable 2552 -- 2554 ippmReportTable OBJECT-TYPE 2555 SYNTAX SEQUENCE OF IppmReportEntry 2556 MAX-ACCESS not-accessible 2557 STATUS current 2558 DESCRIPTION 2559 "The ippmReportTable logs the results of the reports. The results 2560 consist of a subset of the results of a measure as described in the report definition. 2561 The activation of an up and down filtering in the report definition limits the results 2562 logged to those corresponding to major events. Otherwise, the ippmReportTable is 2563 identical to the ippmHistoryTable. 2564 " 2566 ::= { ippmReportGroup 2 } 2568 ippmReportEntry OBJECT-TYPE 2569 SYNTAX IppmReportEntry 2570 MAX-ACCESS not-accessible 2571 STATUS current 2572 DESCRIPTION 2573 "A report is a list of results of a measure. This sample is associated with the 2574 ippmReportSetupEntry which has set up the report. An ippmReportEntry entry is one of 2575 the results of a measure to report. The measure and the report definition are 2576 identified by the index members ippmMeasureOwner and ippmMeasureIndex. 2578 In the index : 2580 + ippmMeasureOwner and ippmMeasureIndex identify the ippmMeasureEntry and the 2581 ippmReportSetupEntry on whose behalf this report was created 2583 + IppmMetricsIndex identifies the ippmMetricsEntry of the metric measured 2584 + ippmHistorySqceNdx value is the absolute time when the result of the metric was 2585 computed. 2587 The ippmReportTimestamp value is the absolute time when the ippmHistoryValue 2588 was performed. 2589 IppmHistoryValue is the value of the metric measured at the timef 2590 ippmReportTimestamp. 2591 " 2592 INDEX { ippmMeasureOwner, ippmMeasureIndex, ippmMetricsIndex, 2593 ippmReportSqceNdx} 2594 ::= { ippmReportTable 1 } 2596 IppmReportEntry ::= 2597 SEQUENCE { 2598 ippmReportSqceNdx Integer32, 2599 ippmReportTimestamp GMTTimeStamp, 2600 ippmReportValue Integer32 2601 } 2602 ippmReportSqceNdx OBJECT-TYPE 2603 SYNTAX Integer32 (1..65536) 2604 MAX-ACCESS read-only 2605 STATUS current 2606 DESCRIPTION 2608 " ippmReportSqceNdx is the sequence index of the measurement 2609 results of the measure of a metric. 2611 Network metrics: 2613 It's the sequence index of a measurement packet. Typically, it identifies the order of 2614 the packet in the stream of packets sends by the source. 2616 Aggregated metrics: 2618 It is the sequence index of the aggregated metric results computed. 2619 " 2620 ::= { ippmReportEntry 1 } 2622 ippmReportTimestamp OBJECT-TYPE 2623 SYNTAX GMTTimeStamp 2624 MAX-ACCESS read-only 2625 STATUS current 2626 DESCRIPTION 2627 "The instant of the measure of the result." 2628 ::= { ippmReportEntry 2 } 2630 ippmReportValue OBJECT-TYPE 2631 SYNTAX Integer32 2632 MAX-ACCESS read-only 2633 STATUS current 2634 DESCRIPTION 2636 "The value." 2637 ::= { ippmReportEntry 3 } 2639 -- 2640 -- ippmNotifications 2641 -- 2643 ippmSingletonAlarm NOTIFICATION-TYPE 2644 OBJECTS { 2645 ippmReportSetupDefinition, 2646 ippmReportSetupMetricThreshold, 2647 ippmMetricUnit, 2648 ippmHistoryValue 2649 } 2650 STATUS current 2651 DESCRIPTION 2652 "A notification sent because 2 contiguous results are on opposite sides of the metric 2653 threshold value. 2654 The index of the included ippmReportSetupMetricThreshold object identifies the 2655 ippmMeasureEntry and the ippmResultSetupEntry that specified the threshold. 2657 The notification contains the instances of the ippmReportValue object that exceeded 2658 the threshold. The ippmHistoryTimestamp of the index identifies the time the event 2659 occurred. 2660 " 2661 ::= { ippmNotifications 1 } 2663 ippmEventsDurationExceededAlarm NOTIFICATION-TYPE 2664 OBJECTS { 2665 ippmReportSetupDefinition, 2666 ippmReportSetupEventsDurationThreshold, 2667 ippmMetricUnit, 2668 ippmHistoryValue 2669 } 2670 STATUS current 2671 DESCRIPTION 2672 "A notification sent when the duration of contiguous raising 2673 ippmReportSetupMetricThreshold exceeds the ippmReportSetupEventsDurationThreshold 2674 value. The index of the included ippmReportSetupDefinition object identifies the 2675 ippmMeasureEntry and the ippmResultSetupEntry that specified the report. 2677 The notification contains the instances of the ippmReportValue objects saved in the 2678 ippmReportTable for this report. The ippmHistoryTimestamp of the index identifies the 2679 time theses measures results where performed. 2680 " 2681 ::= { ippmNotifications 2 } 2683 ippmCycleOfMeasureReport NOTIFICATION-TYPE 2684 OBJECTS { 2685 ippmReportSetupDefinition, 2686 ippmMetricUnit, 2687 ippmHistoryValue 2688 } 2689 STATUS current 2690 DESCRIPTION 2691 "A notification sent when a measure cycle completes. 2692 The index of the included ippmReportSetupDefinition object identifies the 2693 ippmMeasureEntry and the ippmResultSetupEntry that specified the report. 2695 The notification contains the instances of the ippmReportValue objects saved in the 2696 ippmReportTable for this measure cycle. The ippmHistoryTimestamp of the index 2697 identifies the time the measures where performed. 2698 " 2699 ::= { ippmNotifications 3 } 2701 ippmCompletedMeasureReport NOTIFICATION-TYPE 2702 OBJECTS { 2703 ippmReportSetupDefinition, 2704 ippmMetricUnit, 2705 ippmHistoryValue 2706 } 2707 STATUS current 2708 DESCRIPTION 2709 "A notification sent when a measure completes. 2710 The index of the included ippmReportSetupDefinition object identifies the 2711 ippmMeasureEntry and the ippmResultSetupEntry that specified the report. 2713 The notification contains the instances of the ippmReportValue objects saved in the 2714 ippmReportTable for this measure cycle. The ippmHistoryTimestamp of the index 2715 identifies the time the measures where performed. 2716 " 2717 ::= { ippmNotifications 4 } 2719 -- 2720 -- Compliance statements 2721 -- 2723 ippmCompliance MODULE-COMPLIANCE 2724 STATUS current 2725 DESCRIPTION 2726 "The compliance statement for SNMP entities which implement the IPPM MIB" 2727 MODULE -- this module 2728 MANDATORY-GROUPS { ippmSystemGroup, ippmMeasureGroup, 2729 ippmNetworkMeasureGroup, ippmHistoryGroup } 2730 ::= { ippmCompliances 1 } 2732 END 2734 10. Security Considerations 2736 10.1. Privacy 2738 The privacy concerns of network measurement are intrinsically limited 2739 by the active measurements. Unlike passive measurements, there can be 2740 no release of existing user data. 2742 10.2. Measurement aspects 2744 Conducting Internet measurements raises both security and privacy 2745 concerns. This memo does not specify an implementation of the 2746 metrics, so it does not directly affect the security of the Internet 2747 nor of applications that run on the Internet. However, 2748 implementations of these metrics must be mindful of security and 2749 privacy concerns. 2751 There are two types of security concerns: potential harm caused by 2752 the measurements, and potential harm to the measurements. The 2753 measurements could cause harm because they are active, and inject 2754 packets into the network. The measurement parameters MUST be 2755 carefully selected so that the measurements inject trivial amounts of 2756 additional traffic into the networks they measure. If they inject 2757 "too much" traffic, they can skew the results of the measurement, and 2758 in extreme cases cause congestion and denial of service. 2760 The measurements themselves could be harmed by routers giving 2761 measurement traffic a different priority than "normal" traffic, or by 2762 an attacker injecting artificial measurement traffic. If routers can 2763 recognize measurement traffic and treat it separately, the 2764 measurements will not reflect actual user traffic. If an attacker 2765 injects artificial traffic that is accepted as legitimate, the loss 2766 rate will be artificially lowered. Therefore, the measurement 2767 methodologies SHOULD include appropriate techniques to reduce the 2768 probability measurement traffic can be distinguished from "normal" 2769 traffic. 2771 Authentication techniques, such as digital signatures, may be used 2772 where appropriate to guard against injected traffic attacks. 2774 10.3. Management aspects 2776 There are a number of management objects defined in this MIB that 2777 have a MAX-ACCESS clause of read-write and/or read-only. Such objects 2778 may be considered sensitive or vulnerable in some network 2779 environments. The support for SET operations in a non-secure 2780 environment without proper protection can have a negative effect on 2781 network operations. 2783 SNMPv1 by itself is not a secure environment. Even if the network 2784 itself is secure (for example by using IPSec), even then, there is no 2785 control as to who on the secure network is allowed to access and 2786 GET/SET (read/change/create/delete) the objects in this MIB. 2788 It is recommended that the implementors consider the security 2789 features as provided by the SNMPv3 framework. Specifically, the use 2790 of the User-based Security Model RFC 2574 [18] and the View-based 2791 Access Control Model RFC 2575 [21] is recommended. 2793 It is then a customer/user responsibility to ensure that the SNMP 2794 entity giving access to an instance of this MIB, is properly 2795 configured to give access to the objects only to those principals 2796 (users) that have legitimate rights to indeed GET or SET 2797 (change/create/delete) them. 2799 11. Document management 2801 11.1. Open issues 2803 Describe incompatible bit combinations in IPPMreport and granted 2804 metric 2806 Run SMIlint. 2808 Discussion on the management of the history size. 2810 11.2. changes since release 00 2812 Put in a description of the relationship of certain tables, 2813 particularly the measure/network measure/aggregated measure table. 2815 The TC GMTTimeStamp is the common type to define timestamp objects. 2817 ippmHisoryTable index simplified: ippmHistoryTimestamp replaced with 2818 ippmHistorySqceNdx in the index. 2820 The MIB has been compiled using net-snmp. 2822 Snmpadminstring replaces Displaystring. 2824 IP addresses defined using INETaddresstype. 2826 Sharing table is optional to permit the VACM framework to be used. 2828 The description of the network measure table emphases that the set up 2829 of network measure is not permitted using SNMP. 2831 The TC StandardMetrics is removed and replaced with the table 2832 ippmMetricsTable. 2834 The table pointOfMeasureTable is added to describe multiples 2835 interfaces devices 2837 5 tables have been changed to read/create: ippmOwnersTable, 2838 ippmMeasureTable, ippmAggregatedMeasureTable, ippmResultSharingTable, 2839 and ippmReportSetupTable. 2841 IppmHistoryTable and ippmReportTable index reviews: 2842 IppmHistorySqceNdx field added in the ippmHistoryTable. 2843 INDEX modified. IppmHistorySqceNdx replaces IppmHistoryTimemark. 2845 IppmSystem group refurbished: 2846 IppmSystemTimer renamed ippmSystemTime. 2847 Current and last synch event concept generalized in the 2848 ippmSynchronizationTable. 2850 12. References 2852 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 2853 9, RFC 2026, October 1996. 2855 [2] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for 2856 IP Performance Metrics", RFC 2330, May 1998. 2858 [3] Mahdavi J. and V. Paxson, "IPPM Metrics for Measuring 2859 Connectivity", RFC 2678, September 1999. 2861 [4] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Delay 2862 Metric for IPPM", RFC 2679, September 1999. 2864 [5] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Packet 2865 Loss Metric for IPPM", RFC 2680, September 1999. 2867 [6]Almes, G., Kalidindi, S. and M. Zekauskas, "A Round-trip Delay 2868 Metric for IPPM.", RFC 2681, September 1999. 2870 [7] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for 2871 Describing SNMP Management Frameworks", RFC 2571, April 1999. 2873 [8] Rose, M., and K. McCloghrie, "Structure and Identification of 2874 Management Information for TCP/IP-based Internets", STD 16, RFC 2875 1155, May 1990. 2877 [9] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, 2878 RFC 1212, March 1991. 2880 [10] M. Rose, "A Convention for Defining Traps for use with the 2881 SNMP", RFC 1215, March 1991. 2883 [11] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 2884 M., and S. Waldbusser, "Structure of Management Information 2885 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 2887 [12] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 2888 M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, 2889 RFC 2579, April 1999. 2891 [13] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 2892 M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, 2893 RFC 2580, April 1999. 2895 [14] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple 2896 Network Management Protocol", STD 15, RFC 1157, May 1990. 2898 [15] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 2899 "Introduction to Community-based SNMPv2", RFC 1901, January 1996. 2901 [16] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 2902 "Transport Mappings for Version 2 of the Simple Network Management 2903 Protocol (SNMPv2)", RFC 1906, January 1996. 2905 [17]Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 2906 Processing and Dispatching for the Simple Network Management 2907 Protocol (SNMP)", RFC 2572, April 1999. 2909 [18] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) 2910 for version 3 of the Simple Network Management Protocol (SNMPv3)", 2911 RFC 2574, April 1999. 2913 [19] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol 2914 Operations for Version 2 of the Simple Network Management Protocol 2915 (SNMPv2)", RFC 1905, January 1996. 2917 [20] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2918 2573, April 1999. 2920 [21] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-basedAccess 2921 Control Model (VACM) for the Simple Network Management Protocol 2922 (SNMP)", RFC 2575, April 1999. 2924 [22] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction 2925 to Version 3 of the Internet-standard Network Management 2926 Framework", RFC 2570, April 1999. 2928 13. Acknowledgments 2930 A Kerbe. 2932 14. Authors Addresses 2934 Emile STEPHAN 2935 France Telecom R & D 2936 2 avenue Pierre Marzin 2937 F-22307 Lannion cedex 2938 Phone: (+ 33) 2 96 05 11 11 2939 Email: emile.stephan@francetelecom.com 2941 Jessie Jewitt 2942 France Telecom R & D 2943 801 Gateway Blvd. Suit 500 2944 South San Francisco, CA 94080 2945 Tel : 1 650 875-1524 2946 Email : jessie.jewitt@francetelecom.com 2948 Full Copyright Statement 2950 "Copyright (C) The Internet Society (2001). All Rights Reserved. 2952 This document and translations of it may be copied and furnished to 2953 others, and derivative works that comment on or otherwise explain it 2954 or assist its implementation may be prepared, copied, published and 2955 distributed, in whole or in part, without restriction of any kind, 2956 provided that the above copyright notice and this paragraph are 2957 included on all such copies and derivative works. However, this 2958 document itself may not be modified in any way, such as by removing 2959 the copyright notice or references to the Internet Society or other 2960 Internet organizations, except as needed for the purpose of 2961 developing Internet standards in which case the procedures for 2962 copyrights defined in the Internet Standards process must be 2963 followed, or as required to translate it into languages other than 2964 English. 2966 The limited permissions granted above are perpetual and will not be 2967 revoked by the Internet Society or its successors or assigns. 2969 This document and the information contained herein is provided on an 2970 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2971 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2972 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2973 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2974 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.