idnits 2.17.1 draft-ietf-ippm-reporting-mib-00.txt: -(1048): 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 6 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 1 longer page, the longest (page 1) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** 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 2713: '...rk. The measurement parameters MUST be...' RFC 2119 keyword, line 2726: '... methodologies SHOULD include approp...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 200 has weird spacing: '...te them with ...' == Line 1030 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 (June 20, 2002) is 7982 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: '2' is mentioned on line 226, but not defined == Missing Reference: '6' is mentioned on line 104, but not defined == Missing Reference: '17' is mentioned on line 128, but not defined ** Obsolete normative reference: RFC 2679 (ref. '4') (Obsoleted by RFC 7679) ** Obsolete normative reference: RFC 2680 (ref. '5') (Obsoleted by RFC 7680) ** Obsolete normative reference: RFC 2571 (ref. '7') (Obsoleted by RFC 3411) ** Downref: Normative reference to an Informational RFC: RFC 1215 (ref. '10') ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '14') ** Downref: Normative reference to an Historic RFC: RFC 1901 (ref. '15') ** Obsolete normative reference: RFC 1906 (ref. '16') (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2574 (ref. '18') (Obsoleted by RFC 3414) ** Obsolete normative reference: RFC 1905 (ref. '19') (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 2573 (ref. '20') (Obsoleted by RFC 3413) ** Obsolete normative reference: RFC 2575 (ref. '21') (Obsoleted by RFC 3415) ** Obsolete normative reference: RFC 2570 (ref. '22') (Obsoleted by RFC 3410) ** Obsolete normative reference: RFC 2021 (ref. '24') (Obsoleted by RFC 4502) ** Downref: Normative reference to an Informational RFC: RFC 2896 (ref. '26') Summary: 20 errors (**), 0 flaws (~~), 12 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Stephan/J. Jewitt 4 Internet Draft France Telecom R&D 6 Document: draft-ietf-ippm-reporting-mib-00.txt June 20, 2002 8 IPPM reporting MIB 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026 [1]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or made obsolete by other documents at 20 any time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This memo defines a portion of the Management Information Base (MIB) 32 designed for use with network management protocols in TCP/IP-based 33 internets. 34 In particular, this MIB specifies the objects used for managing the 35 results of the IPPM metrics measures, for pushing alarms, and for 36 reporting the measures results. 38 Table of Contents 40 1. Introduction................................................3 41 2. The IPPM Framework..........................................3 42 3. The SNMP Management Framework...............................3 43 4. Overview....................................................5 44 4.1. Textual Conventions.........................................6 45 4.2. Structure of the MIB.......................................10 46 4.3. Row identification in an application namespace.............12 47 5. IPPM-REPORTING-MIB conceptual presentation.................14 48 5.1. IPPM-REPORTING-MIB diagram.................................14 49 5.2. Conceptual programming interface...........................15 50 5.3. SNMP mapping...............................................15 51 6. Measurement architectures..................................16 52 6.1. Proxy architecture.........................................16 53 6.2. Reporting architecture.....................................17 54 6.3. Gateway architecture.......................................19 55 6.4. Security...................................................19 56 7. Reporting mode integration with the control and test 57 protocols................................................20 58 7.1. Integration................................................20 59 7.2. Setup of the measure.......................................20 60 7.3. Setup of the measurement report............................21 61 7.4. Writing the measurement results in the IPPM-REPORTING 62 MIB......................................................21 63 7.5. Report download and upload.................................22 64 7.6. Default value..............................................22 65 8. Definition.................................................22 66 9. Security Considerations....................................58 67 9.1. Privacy....................................................58 68 9.2. Measurement aspects........................................58 69 9.3. Management aspects.........................................58 70 10. References.................................................59 71 11. Acknowledgments............................................61 72 12. Author's Addresses.........................................61 74 1. Introduction 76 This memo defines a MIB for managing the measures using the IP 77 performance metrics specified by the IPPM Working Group. 79 It specifies the objects to manage the results of the measure of 80 metrics standardized by IPPM Working Group. They are built on notions 81 introduced and discussed in the IPPM Framework document, RFC 2330 82 [2]. 84 This memo defines a Management Information Base (MIB), and as such 85 it 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 in 3 major components: 97 A general framework for defining performance metrics, described 98 in the Framework for IP Performance Metrics, RFC 2330 [2]; 100 A set of standardized metrics which conform to this framework: 101 The IPPM Metrics for Measuring Connectivity, RFC 2678 [3]; The One- 102 way Delay Metric for IPPM, RFC 2679 [4]; The One-way Packet Loss 103 Metric for IPPM, RFC 2680 [5]; The Round-trip Delay Metric for IPPM, 104 RFC 2681 [6]. 106 Emerging metrics that are being specified in respect of this 107 framework. 109 3. The SNMP Management Framework 111 The SNMP Management Framework consists of five major components: 113 An overall architecture, described in RFC 2571 [7]. 115 Mechanisms for describing and naming objects and events for the 116 purpose of management. The first version of this Structure of 117 Management Information (SMI) is called SMIv1 and described in STD 16, 118 RFC 1155 [8], STD 16, RFC 1212 [9] and RFC 1215 [10]. The second 119 version, called SMIv2, is described in STD 58, RFC 2578 [11], STD 58, 120 RFC 2579 [12] and STD 58, RFC 2580 [13]. 122 Message protocols for transferring management information. The 123 first version of the SNMP message protocol is called SNMPv1 and 124 described in STD 15, RFC 1157 [14]. A second version of the SNMP 125 message protocol, which is not an Internet standards track protocol, 126 is called SNMPv2c and described in RFC 1901 [15] and RFC 1906 [16]. 127 The third version of the message protocol is called SNMPv3 and 128 described in RFC 1906 [16], RFC 2572 [17] and RFC 2574 [18]. 130 Protocol operations for accessing management information. The 131 first set of protocol operations and associated PDU formats is 132 described in STD 15, RFC 1157 [14]. A second set of protocol 133 operations and associated PDU formats is described in RFC 1905 [19]. 135 A set of fundamental applications described in RFC 2573 [20] and 136 the view-based access control mechanism described in RFC 2575 [21]. 138 A more detailed introduction to the current SNMP Management Framework 139 can be found in RFC 2570 [22]. 141 Managed objects are accessed via a virtual information store, termed 142 the Management Information Base or MIB. Objects in the MIB are 143 defined using the mechanisms defined in the SMI. 145 This memo specifies a MIB module that is compliant to the SMIv2. A 146 MIB conforming to the SMIv1 can be produced through the appropriate 147 translations. The resulting translated MIB must be semantically 148 equivalent, except where objects or events are omitted because no 149 translation is possible (use of Counter64). Some machine readable 150 information in SMIv2 will be converted into textual descriptions in 151 SMIv1 during the translation process. However, this loss of machine 152 readable information is not considered to change the semantics of the 153 MIB. 155 Managed objects are accessed via a virtual information store, termed 156 the Management Information Base or MIB. Objects in the MIB are 157 defined using the subset of Abstract Syntax Notation One (ASN.1) 158 defined in the SMI. In particular, each object type is named by an 159 OBJECT IDENTIFIER, an administratively assigned name. 161 The object type together with an object instance serves to uniquely 162 identify a specific instantiation of the object. For human 163 convenience, we often use a textual string, termed the descriptor, to 164 refer to the object type. 166 4. Overview 168 Although the number of measurement devices that implement IPPM 169 metrics is growing, there is not currently any standardized 170 management interface to manage remotely the results of these metrics. 171 This memo defines a Management Information Base for managing the 172 results of the measures of IPPM metrics. 174 To permit metrics to be referenced by other MIBs and other protocols, 175 the IPPM WG has defined a registry of the current metrics and a 176 framework for the integration of future metrics in [IPPM metrics 177 registry]. 179 As the specification of new metrics is a continuous process, this 180 memo defines a framework for the integration of the future 181 standardized metrics. To address future needs Specialized tables may 182 be created, while augmenting the definition of the ippmMeasureTable. 184 The MIB architecture is inspired by the RMON model [23],[24] which 185 specifies the MIB for the monitoring of a single point of measure. 186 The IPPM-REPORTING-MIB differs from this model in that IPPM metrics 187 measurement involves several points of measures and requires common 188 references for time and for measure identification. The IPPM- 189 REPORTING-MIB defines an absolute timeFilter. 191 The IPPM-REPORTING-MIB introduces a framework where each application 192 identifies its measures in an owner namespace. Using the namespace 193 framework, an application may grant other owners access to its 194 measure results for aggregated metrics computation, reporting, or 195 alarming. 197 Different architectures may be used to perform metric measurements, 198 using a control protocol and a test protocol. Different control 199 frameworks are suitable for performing a measure. The memo lists 200 them, while also looking for a way to integrate them with the IPPM- 201 REPORTING-MIB . This section is informational, but helps to specify 202 the relationship among the test protocol, the control protocol and 203 IPPM-REPORTING-MIB. 205 Special care has been taken to provide a reporting mode suitable for 206 control protocol and test protocol. It addresses the need to provide 207 access to results for the applications. Moreover, it may be used to 208 reduce the number of control frameworks. 210 This MIB is intended to handle multiple concurrent access by SNMP 211 applications. They are not in constant contact with the measurement 212 devices. For this reason, this MIB allows continuous measures 213 collection and statistics computation. 215 The objects defined in this document are not intended for direct 216 manipulation.. 218 4.1. Textual Conventions 220 Five types of data are introduced as a textual convention in this 221 MIB document: TypeP,GMTDateAndTime, GmtTimeFilter, 222 IppmReportDefinition and IppmStandardMetrics. 224 4.1.1. Packet of type P 226 Section 13 of the IPPM framework [2] introduces the generic notion of 227 a "packet of type P" because in some contexts the metric's value 228 depends on the type of the packets involved in the metric. In the 229 definition of a metric, the type P will be explicitly defined, 230 partially defined, or left generic. Measurement of metrics defined 231 with generic type P are made specific when performing actual 232 measurements. This naming convention serves as an important reminder 233 that one must be conscious of the exact type of traffic being 234 measured. 236 The standardization of the management of the IPPM measures relies on 237 the capability to configure finely and unambiguously the type P of 238 the packets, and the parameters of the protocol suites of the type P. 240 RMON2 introduced the concept of protocol identifiers. The RFC2895 241 [25] specifies a macro for the definition of protocol identifier. The 242 RFC2896 [26] defines the protocol identifiers for different protocol 243 encapsulation trees. 245 The type P implementation relies on the MACRO PROTOCOL-IDENTIFIER 246 defined for identifying protocol suites in RMON2. It is achieved by 247 defining the TypeP as a new syntax in SMIv2 TEXTUAL-CONVENTION. 249 4.1.1.1. Internet addresses 251 The section 14 of the IPPM framework defines (for the usual case of a 252 unidirectional path through the Internet) the term "Src" and "Dst". 253 "Src" denotes the IP address of the beginning of the path, and "Dst" 254 denotes the IP address of the end. 256 The section 3 of the RMON PI Reference specifies the Protocol 257 Identifier Encoding rules which consists briefly in a recursive 258 length value format. "Src" and "Dst" are protocol identifier 259 parameters. Their values are encoded in separated fields using the 260 protocol identifier encoding rule, but without trailing parameters. 262 The packet encapsulation defined in an instance of TypeP embeds the 263 format of "Src" and "Dst" and their values. These addresses type and 264 value depend on the type P of the packet, IP version 4, V6, IP in 265 IP... Both participate to the completion of the packet encoding. 267 Examples: 269 RFC2896 defines the protocol identifiers ip and ipip4. Should there 270 be an Internet tunnel end-point of the IP address 192.168.1.1 in the 271 tunnel 128.2.6.7. The TypeP of the source address of the tunnel, Src, 272 is 8.0.0.8.0.0.0.0.17.2.0.0 (ip.ipip4). The trailer 2.0.0 in the 273 TypeP indicates that there are 2 parameters. In the IPPM context 274 these 2 parameters are provided in Src, which has the value 275 10.4.192.168.1.1.4.128.2.6.7. 277 4.1.2. GMTDateAndTime 279 This textual convention defines the date and time, and is represented 280 by the following format: year, month, day, hour, minutes, seconds, 281 fractions of second. 283 The first part is human readable. The fields year, month, day, hour, 284 minutes are seconds are printable characters. 286 The last field is the fraction of second. The fraction step is 250 287 picoseconds. 289 or example, 50 ms is 200000000 times 250 picosecond which correspond to 290 0BEBC200'H. 0001000201090200010501000BEBC200 represent 8:15pm, 10 291 econds and 50 ms GMT on 19 February 2001 and is displayed as 01-02- 292 9,20:15:10, 200000000. 294 4.1.3. GmtTimeFilter 296 GmtTimeFilter uses an absolute reference of time, and is intended to be 297 used for the index of a table. It allows an application to download only 298 those rows changed since a particular time. A row is considered changed 299 if the value of any object in the row changes, or if the row is created 300 or deleted. 302 Each new conceptual row will be associated with the timeMark instance 303 that was created at the value of ippmTimeSysTimer. 305 It is intended to provide an absolute timestamp index for the results of 306 measures. Typically for each singleton produced by an IPPM measure is 307 associated the timemark corresponding to the moment of the measure. 309 Illustrations: 311 Consider the 2 tables measureTable and resultTable 313 measureTable OBJECT-TYPE 314 SYNTAX SEQUENCE OF MeasureEntry 315 MAX-ACCESS not-accessible 316 STATUS current 317 DESCRIPTION '' 318 ::= { fooMib 1 } 319 INDEX { measureIndex } 321 resultTable OBJECT-TYPE 322 SYNTAX SEQUENCE OF ResultEntry 323 MAX-ACCESS not-accessible 324 STATUS current 325 DESCRIPTION '' 326 ::= { fooMib 2 } 327 INDEX { measureIndex, resultTimeMark } 329 ResultEntry { 330 resultTimeMark TimeFilter, 331 resultCounts Counter 332 } 334 Let�s assume there are two measure rows in the measure table 335 (measureIndex == 1, measureIndex == 2) which produced results 336 asynchronously (e.g. made at Poisson intervals or sibling) and logged 337 them in the result table. 339 Let�s also assume that Measure 1 produced the result 34 at time 340 0001000201090200010501000BEBC200 GMT, while Measure 2 produced the value 341 54 10ms later at time 0001000201090200010501000E4E1C00 GMT, and that 342 both rows are updated on several later occasions such that the current 343 values are 37 and 53 respectively. 345 Then the following resultCounts instances would exist: 347 resultCounts.1.0001000201090200010501000BEBC200 34 348 resultCounts.2.0001000201090200010501000E4E1C00 54 349 resultCounts.1.00010002010902000105010016A65700 65 350 resultCounts.1.0001000201090200010501000E4E1C00 57 351 resultCounts.2.0001000201090200010501001312D000 48 352 resultCounts.2.0001000201090200010501001443FD00 53 353 resultCounts.1.00010002010902000105010101312D00 49 354 resultCounts.1.00010002010902000105010104C4B400 37 356 The following get-bulk explains how an NMS retrieves the results of the 357 measures. 359 get-bulk(nonRptrs=1, maxReps=10, resultCounts.1); 360 returns: 361 resultCounts.1. 0001000201090200010501000BEBC200 == 34 362 resultCounts.1.00010002010902000105010016A65700 == 65 363 resultCounts.1.0001000201090200010501000E4E1C00 == 57 364 resultCounts.1.00010002010902000105010101312D00 == 49 365 resultCounts.1.00010002010902000105010104C4B400 == 37 366 # return lexigraphically-next two MIB instances 368 get-bulk(nonRptrs=0, maxReps=2, 369 resultCounts.1.0001000201090200010501000E4E1C00 , 370 resultCounts.2.0001000201090200010501000E4E1C00 ); 371 returns: 372 resultCounts.1.00010002010902000105010016A65700 == 65 373 resultCounts.2.0001000201090200010501001312D000 == 48 374 resultCounts.1.0001000201090200010501000E4E1C00 == 57 375 resultCounts.2.0001000201090200010501001443FD00 == 53 377 get-bulk(nonRptrs=0, maxReps=2, 378 resultCounts.1.00010002010902000105010104C4B400 , 379 resultCounts.2.00010002010902000105010104C4B400 ); 380 returns: 381 return lexigraphically-next two MIB instances 382 no 'resultTable' counter values at all are returned because 383 neither counter has been updated since the time 384 00010002010902000105010104C4B400 386 4.1.4. Report definition 388 A report consists of sending or logging a subset of results of 389 measure. The elaboration of the report consists of actions to perform 390 on the measurement results. An action is performed either: 392 + For each result 393 + On the results corresponding to a measurement cycle 394 + On the results available at the measurement completion. 396 To preserve the scalability of the whole measurement system, it 397 limits: 399 + The amount of data sent to the applications 400 + The bandwidth consumption for uploading the result 401 + The number of alarms sent to the applications 402 + The amount of data saved in the point of measure 404 The comparison of the measure results in a metric threshold that 405 identifies particular measure values and times that directly impact 406 service availability. 408 The comparison of the duration of repeated events with a duration 409 threshold identifies particular measure values and times that 410 directly affect an SLA. 412 The combination of IPPM metric results, threshold events, and event 413 filtering provides a very efficient mechanism to report results, 414 events, and alarms. 416 A report is described using the TEXTUAL-CONVENTION 417 IppmReportDefinition. The report setup must not dramatically increase 418 the amount of data needed by the control protocol to setup a measure: 420 + A basic report is defined in the object 421 ippmReportSetupDefinition; 422 + More elaborate reports are described using a metric 423 threshold to generate alarms and events. 424 + Pushing of alarms and reports requires an NMS address. 425 + SLA alarms are described using an events duration 426 threshold. 428 The TEXTUAL-CONVENTION IppmReportDefinition specifies the list of 429 events and actions that are used to create a report. 431 4.1.5. IppmStandardMetrics 433 The TEXTUAL-CONVENTION IppmStandardMetrics defines the standardized 434 IPPM metrics. 436 4.2. Structure of the MIB 438 The MIB is arranged as follow: 440 - ippmOwnersGroup 442 - ippmSystemGroup 444 - ippmMeasureGroup 446 - ippmHistoryGroup 448 - ippmNetworkMeasureGroup 450 - ippmAggregatedMeasureGroup 452 - ippmReportGroup 454 - ippmNotifications 456 4.2.1. The ippmOwners Group 458 This group controls access to the probe. 460 4.2.2. The ippmSystem Group 462 This group consists of a set of parameters describing the clock 463 synchronization over the time. 465 This group is Critical to the implementation of the IPPM MIB. 467 Section 6.3. of the IPPM Framework states that 468 "Those who develop such measurement methodologies should strive to: 469 + Minimize their uncertainties/errors, 470 + Understand and document the sources of uncertainty/error, and 471 + Quantify the amounts of uncertainty/error." 473 The aim of this group is to have these values available to compute 474 reliable statistics. The implementation of this group is mandatory 475 whether the time synchronization is automatic or not. 477 4.2.3. The ippmMeasureGroup 479 This group displays all the measures configured on the measurement 480 entity. It consists of the ippmMetricsTable, ippmMeasureTable. 482 The measurement entity describes in the ippmMetricsTable of the SNMP 483 agent the local implementation of the standardized metrics. 485 The control protocol registers a description of the existing measures 486 in the ippmMeasureTable and in the auxiliary measure tables. 488 ippmMeasureTable holds the common part of a measure, while the 489 specific parameters are handled in the corresponding auxiliary table 490 (ippmNetworkMeasure, ippmAggregatedMeasureTable�) . 492 The results of the measures are logged in the ippmHistoryTable. 494 4.2.4. The ippmNetworkMeasure Group 496 The control protocol registers a description of the existing network 497 measures in the ippmNetworkMeasureTable and in the ippmMeasureTable. 499 This group displays the network measures defined by the control 500 protocol. The results are saved in the ippmHistoryTable. 502 ippmNetworkMeasureTable is an auxiliary table of ippmMeasureTable, 503 and is responsible for the configuration of the network measure. 505 4.2.5. The ippmAggregatedMeasure Group 507 ippmAggregatedMeasureTable is an auxiliary table of ippmMeasureTable, 508 and is responsible for the consolidation of the results previously 509 measured and saved in the ippmHistoryTable. The aggregated results 510 are saved in the ippmHistoryTable and may be used for higher 511 aggregated measures. 513 4.2.6. The report Group 515 This group displays the existing reports of the measures. 516 ippmReportSetupTable is an auxiliary table of ippmMeasureTable, and 517 is responsible for the configuration of the reports. 518 The reports are saved in the ippmReportTable, or sent directly to the 519 applications. 521 4.2.7. The notification Group 523 The Notification group specifies a list of valid notifications. They 524 are used to push alarms or reports to the applications. 526 4.3. Row identification in an application namespace 528 The control protocol or the test protocol adds rows in the namespace 529 of the corresponding measure. 531 An identifier of an instance of an object is defined as a list of 532 objects in the clause INDEX. An identifier of an instance of an 533 object in an owner namespace is defined as a list of objects in the 534 clause INDEX where the first object type is OwnerString. 536 As the OBJECT IDENTIFIER, which identifies the instance, begins with 537 the owner value, the remaining value of the index fields may be 538 chosen independently from one namespace to another. 540 This allows the user to choose arbitrary values for the remaining 541 fields of the INDEX clause without checking that the values of these 542 fields exist in the MIB tables. This allows the owner to use the same 543 values across MIB implementations. 545 Thus, it avoids polling to determine the next free index. Also, as a 546 consequence, s 2 applications will never find the same free index 547 value. 549 The usage of owner namespace increases the speed of the management 550 operations while reducing bandwidth consumption and CPU load in the 551 agents and applications. 553 Measurements are requested by NMS applications. An instance of an 554 object managed by an NMS is identified by the NMS OwnerString and the 555 private index provided by the NMS. 557 As the NMS manages its private range of indices, it simply chooses 558 one when it wishes to create a new control entry. For the same 559 reason, the setup of a measure on several points of measures consists 560 of simply sending the same copy of the measure setup to the different 561 points of measures involved. 563 5. IPPM-REPORTING-MIB conceptual presentation 565 5.1. IPPM-REPORTING-MIB diagram 567 Conceptual view of objects configured using the IPPM-REPORTING-MIB 569 +--------------------------------------------------------+ 570 | IPPM-REPORTING-MIB entity | 571 | | 572 | +---------------------+ +-------------------+ | 573 | | | | | | 574 | | Measure scheduler | | Result storage | | 575 | | | | | | 576 | | ^ | | ^ ^^^ | | 577 | | | | | | ||| | | 578 | +----------|----------+ +-|---|||-----------+ | 579 | | | ||| | 580 | +----------|--------------|---|||-----------+ | 581 | | | owner | ||| | | 582 | | | Acces | ||| | | 583 | | | Control | ||| | | 584 | +----------|--------------|---|||-----------+ | 585 | | | ||| | 586 +------------------|--------------|---|||----------------+ 587 | | ||| 588 | | ||| 589 +----------------+ | +----------+-+ ||| +-------------+ 590 | ControlMeasure | | | GetResult | ||| | CreateResult| 591 |----------------+-+ |------------| ||+--+-------------| 592 | | | | || | | 593 | owner | | owner | || | owner | 594 | privateNdx | | privateNdx | || | privateNdx | 595 | metrics | | metric | || | metrics | 596 | scheduler | | timestamp | || | timestamp | 597 | addresses | +------------+ || | value | 598 | status | || +-------------+ 599 +----------------+ || 600 || 601 +---------------------------+| 602 | | 603 +---------+---------+ +------+-----------------+ 604 |GetMeasureResults | |GetMeasureMetricResults | 605 |-------------------| |------------------------| 606 | | | owner | 607 | owner | | privateNdx | 608 | privateNdx | | metric | 609 +-------------------+ +------------------------+ 611 The managed objects of the IPPM-REPORTING-MIB are the measures and 612 the results. 614 5.2. Conceptual programming interface 616 This section describes a conceptual programming interface for the 617 integration of the IPPM-REPORTING-MIB in a point of measure. 619 5.2.1. Measure control 621 A measure is created/deleted/suspended through the ControlMeasure() 622 call. 624 5.2.2. Result log 626 A result of a measure is created in the IPPM-REPORTING-MIB History 627 table using a CreateResult() call. Results belonging to a measure are 628 managed according to the setup of the measure. 630 5.2.3. Reporting 632 Results are reported using the method GetResult(), 633 GetMeasureMetricResults() and GetMeasureResults() respectively to get 634 a singleton result, the singleton result of a metric measure, and 635 finally to get the singleton result of a measure. 637 5.2.4. Logical calls 639 Objects are managed using 5 main primitives: 641 controlMeasure(); 642 CreateResult(); 643 GetResult(); 644 GetMeasureMetricResults(); 645 GetMeasureResults(). 647 5.3. SNMP mapping 649 ControlMeasure() corresponds to a SNMP set-request on a conceptual 650 row of ippmMeasureEntry and on a conceptual row of 651 ippmNetworkMeasureEntry. 653 CreateResult() is a internal interface for adding measure results in 654 the ippmHistoryTable. 656 GetResult() corresponds to an SNMP get-request on a result. 658 GetMeasureMetricResults() corresponds to a SNMP walk on the results 659 of a metric measure subtree. 661 GetMeasureResults() corresponds to a SNMP walk on the results of a 662 measure subtree. 664 6. Measurement architectures 666 There are four main measurement architectures. 668 6.1. Proxy architecture 670 +----+ +----+ 671 |NMS1| |NMS2| 672 +----+ +----+ 673 ^ ^ 674 | | 675 +----------+ +----------+ 676 | | 677 SNMP or Sibling 678 | | 679 v v 680 +--------------------------+ 681 | IPPM-REPORTING-MIB agent | 682 +--------------------------+ 683 ^ ^ 684 | | 685 OWDP-Control 686 | | 687 +----------+ +----------+ 688 | | 689 v v 690 +----------------+ +------------------+ 691 | Packets-Sender |--OWDP-Test-->| Packets-Receiver | 692 +----------------+ +------------------+ 694 In this architecture, the different NMS�s query the IPPM-REPORTING- 695 MIB agent for measurements. The agent controls whether the NMS is 696 granted access to perform the measure requested. Each NMS accesses 697 the results of its measurements in the IPPM-REPORTING-MIB statistics 698 table. 700 The measurement setup/teardown and the data collection are done using 701 the control protocol and the test protocol. 703 In this mode the NMS does not depend either on the control protocol 704 nor on the test protocol. The entities involved in the measurement do 705 not need to implement the IPPM-REPORTING-MIB nor SNMP. This mode 706 allows for lightweight implementation in the point of measure, and 707 also for heterogeneous control protocols to coexist. 709 Finally, the proxy is a checkpoint where measurement activity may be 710 logged, and where access to measurement setups may be tightly 711 controlled. Thus, it provides a reliable architecture to manage the 712 security of a measurement system. 714 6.2. Reporting architecture 716 In this architecture the SNMP protocol is only used to read the 717 results of the measurements in the IPPM-REPORTING-MIB History Table, 718 and also to inform the NMS that an event has occurred. 720 +----+ +----+ 721 |NMS1| |NMS2| 722 +----+ +----+ 723 ^ ^ ^ ^ 724 | | | | 725 SNMP| SNMP| 726 | | | | 727 | | | | 728 | OWDP | OWDP 729 |Control |Control 730 | | | | 731 | | +------------------------------+ 732 | | | | | 733 | | +--|---------------------------+ | 734 | | | | | | 735 | +--|--|------------------------+ | | 736 | | | | | | | 737 +--------+---------------------+ | | 738 | | | | | | | | 739 | | | | | | | | 740 v v v v v v v v 741 +------------------+ +------------------+ 742 |IPPM-REPORTING-MIB| |IPPM-REPORTING-MIB| 743 | agent | | agent | 744 +------------------+ +------------------+ 745 | Packets-Sender |--OWDP-Test-->| Packets-Receiver | 746 +------------------+ +------------------+ 748 The activation of a measure by the control protocol or the test protocol 749 creates a measure in the IPPM-REPORTING-MIB Measure table. The table in 750 question may be not accessible by SNMP. In this case, a list of the 751 measure identifiers (owner, index) is handled by the measurement 752 software. 754 Each timestamped result of the measure is logged on the fly in the IPPM- 755 REPORTING-MIB History table in order to allow read access to the NMS�s 756 and event handling. 758 On completion, the measurement results are managed according to the 759 measure setup: 760 + The results may be sent to an NMS using a SNMP Trap PDU or 761 a SNMP Inform PDU. The NMS may be the sender entity or the 762 control entity; 763 + They may be dropped from the IPPM-REPORTING-MIB History 764 table. 766 In this mode, it is recommended to use an SNMPv2 Inform PDU to send the 767 result because it ensures that the entire block of the result is 768 received. There is no control using SNMP Trap PDU. 770 Also, in this mode, it is recommended to implement the IPPM-REPORTING- 771 MIB Measure table in read only in order to allow an NMS to read the 772 status of their measures. 774 6.3. Gateway architecture 776 The gateway architecture combines the proxy mode and the reporting mode. 778 +-------+ +------+ 779 | NMS1 | | NMS2 | 780 +-------+ +------+ 781 ^ ^ 782 | | 783 SNMP SNMP 784 | | 785 | +----------------------------------------+ 786 | | | 787 +-------------+ +------------------+ 788 | | | | | 789 +----------------------------------------+ | 790 | | | | | | 791 | | v v | | 792 | | +------------------------+ | | 793 | | | IPPM-REPORTING-MIB | | | 794 | | | scheduler | | | 795 | | +------------------------+ | | 796 | | | control server | | | 797 | | +------------------------+ | | 798 | | ^ ^ | | 799 | | | | | | 800 | | OWDP-Control protocol | | 801 | | | | | | 802 | | +-----+ +-------+ | | 803 | | | | | | 804 v v v v v v 805 +-------------+---------+ +--------+-------------+ 806 | IPPM- | Packets | |Packets | IPPM | 807 |REPORTING-MIB| Sender | |Receiver|REPORTING-MIB| 808 | agent | |-OWDP-Test->| | agent | 809 +-------------+---------+ +--------+-------------+ 811 The NMS measurement queries are registered in the IPPM-REPORTING-MIB 812 scheduler and performed by the control and the test protocol. The NMS 813 directly consults the result in the corresponding points of measure. 815 6.4. Security 817 The proxy mode provides flexibility and control of the access to the 818 points of measure, while allowing lightweight control protocol and test 819 protocol implementations in the points of measure. Different security 820 rules may be applied to the NMS domain and to measurement system 821 domains. 823 The reporting mode has 2 security domains: 825 +The control of the measurement setups relies on the control and the 826 test protocol security mechanisms. 827 + The control of access to the results depends on the SNMP security 828 mechanisms. 830 The gateway mode security relies on the security of the proxy mode and 831 of the reporting mode. 833 7. Reporting mode integration with the control and test protocols 835 The IPPM-REPORTING-MIB standardizes the parameters that: 837 + Define the configuration of the IPPM metrics measures; 838 + Define the format of the results of the measure; 839 + Define the report of the IPPM metric measures results. 841 It introduces the concept of owner namespace to allow for fast 842 configuration and reporting across multiple points of measurement. 844 A measure is a distributed object describing a task to be performed by 845 the control and the test protocols. A measure is identified by its owner 846 and its owner index. This identifier is the same in all the points of 847 measure. As the owner chooses the index, there is no need for 848 negotiation between the NMS and the points of measure before activating 849 the measure. 851 A measure is primarily defined by its identifier, the metrics to 852 measure, the description of the end point addresses and the description 853 of the scheduling of the measure. 855 The description of the measure is distributed to the points of measure 856 involved. The distribution may not be synchronized. 858 7.1. Integration 860 The control protocol, test protocol and the IPPM-REPORTING-MIB share the 861 same semantic. 863 The integration of the IPPM-REPORTING-MIB, and the test and control 864 protocols, relies on the use of the conceptual programming interface 865 described in section 6. It consists in pushing the measure 866 setup/teardown parameters and the result values from the measurement 867 software to the IPPM-REPORTING-MIB agent. 869 7.2. Setup of the measure 871 The creation of the measure consists only in transferring the measure 872 description from the measurement software to the MIB. The management of 873 the measure is done using the ControlMeasure(). 875 The protocol, which provides the parameters of the measure to manage, 876 may be the control protocol of the test protocol. 878 Different frameworks may be used to setup a measure. 880 7.2.1. Synchronous setup 882 The control protocol sets up the measure both in the sender and the 883 receiver before the measurement. 885 7.2.2. Asynchronous setup 887 The control protocol sets up the measure only in the sender. In this 888 case, the receiver has a service already activated (or pending )for the 889 typeP of the measurement. 891 As the first test packet includes the description of the measure, it may 892 differ from regular test packets. If the first test packet is not 893 consistent with the regular test packets, it must not be used for 894 performing metrics measurement. 896 7.3. Setup of the measurement report 898 The report description is an extension to the definition of a measure. 899 It describes the event and the data to include in the report. A report 900 is read by an NMS in the ippmReportTable, or pushed to a NMS using a 901 SNMP Trap PDU, a SNMP Inform PDU, an email, or a SMS. 903 The control protocol, or the test protocol, includes the description of 904 the report in the setup of the measure. 906 Different types of reports may be combined: 908 + A trivial report defines the results to be saved in the 909 ippmReportTable; 910 + A basic report defines the host to which the results are 911 pushed on completion of the measure; 912 + An alarm report defines a threshold on the results of the 913 measure. A message is sent to a host when the result raises 914 or fall the threshold; 915 + An SLA report defines a threshold on the results of the 916 measure. The events are filtered using a staircase method. 917 The report consists in the results of the measure (time and 918 value) of the filtered events. The reports are sent at each 919 measure cycle or when the measure completes. 921 7.4. Writing the measurement results in the IPPM-REPORTING-MIB 923 Results have to be written by the measurement task in the agent 924 implementing the IPPM MIB. 926 Adding the results of a measurement consists in the transfer of the 927 result from the measurement software to the agent. The protocol that 928 provides the result may be the control protocol, or the test protocol. 930 Writing a result is done using the CreateResult(). 932 7.5. Report download and upload 934 A report is read in the ippmReportTable using SNMP, or pushed by the 935 IPPM_MIB agent using a SNMP Trap PDU, a SNMP Inform PDU, an email or a 936 SMS. 938 7.6. Default value 940 The default values correspond to Ipv4 best effort. 942 8. Definition 944 IPPM-REPORTING-MIB DEFINITIONS ::= BEGIN 946 IMPORTS 947 MODULE-IDENTITY, 948 NOTIFICATION-TYPE, 949 OBJECT-TYPE, 950 Integer32, 951 Counter32, 952 experimental 953 FROM SNMPv2-SMI 954 OwnerString 955 FROM RMON-MIB 956 protocolDir 957 FROM RMON2-MIB 958 DisplayString, 959 TimeStamp, 960 DateAndTime, 961 TruthValue, 962 RowStatus, 963 StorageType, 964 TEXTUAL-CONVENTION 965 FROM SNMPv2-TC 966 MODULE-COMPLIANCE, 967 OBJECT-GROUP, 968 NOTIFICATION-GROUP 969 FROM SNMPv2-CONF; 971 ippmReportingMib MODULE-IDENTITY 972 LAST-UPDATED "200202011200Z" -- March 17, 2002 973 ORGANIZATION "France Telecom - R&D" 974 CONTACT-INFO 975 "Mail : Emile Stephan 976 France Telecom - R&D, Dpt. CPN 977 2, Avenue Pierre Marzin 978 Technopole Anticipa 979 22307 Lannion Cedex 980 FRANCE 981 Tel: + 33 2 96 05 36 10 982 E-mail: emile.stephan@francetelecom.com 984 Jessie Jewitt 985 France Telecom - - R&D 986 801 Gateway Blvd. Suit 500 987 South San Francisco, CA 94080 988 Tel : 1 650 875-1524 989 E-mail : jessie.jewitt@rd.francetelecom.com" 991 DESCRIPTION 992 " This memo defines a portion of the Management Information Base 993 (MIB) for use with network management protocols in TCP/IP-based 994 internets. In particular, it specifies the objects used for managing 995 the results of the IPPM metrics measurements, alarms and reporting 996 the measures results. 997 " 998 ::= { ippm 2 } 999 -- 1000 -- TEXTUAL-CONVENTION 1001 -- 1003 TimeUnit ::= TEXTUAL-CONVENTION 1004 STATUS current 1005 DESCRIPTION 1006 "A list of time units." 1007 SYNTAX INTEGER { 1008 year(1), 1009 month(2), 1010 week(3), 1011 day(4), 1012 hour(5), 1013 second(6), 1014 ms(7), 1015 us(8), 1016 ns(9) 1017 } 1018 -- 1019 -- 1020 -- A absolute, GMT timer using UTC like convention. 1021 -- 1022 -- 1024 GMTDateAndTime ::= TEXTUAL-CONVENTION 1025 DISPLAY-HINT "d-d-d,d:d:d,4d" 1026 STATUS current 1027 DESCRIPTION 1028 "A date-time specification. 1030 field octets contents range 1031 ----- ------ -------- ----- 1032 1 1-2 year* 0..99 1033 2 3-4 month 1..12 1034 3 5-6 day 1..31 1035 4 7-8 hour 0..23 1036 5 9-10 minutes 0..59 1037 6 11-12 seconds 0..59 1038 7 13-16 250 picoseconds 0..2^32-1 1039 " 1040 SYNTAX OCTET STRING (SIZE (16)) 1042 GmtTimeFilter ::= TEXTUAL-CONVENTION 1043 STATUS current 1044 DESCRIPTION 1045 "GmtTimeFilter TC is inspired by the TimeFilter defined 1046 in RMON2. The reference for the time of TimeFilter is 1047 the local value of sysUptime, while GmtTimeFilter uses 1048 an absolute reference of time.� � 1050 SYNTAX GMTDateAndTime 1052 TypeP ::= TEXTUAL-CONVENTION 1053 DISPLAY-HINT "1d." 1054 STATUS current 1055 DESCRIPTION 1056 "This textual convention is used to describe the 1057 protocol encapsulation list of a packet, and is used as 1058 the value of the SYNTAX clause for the type of the Src 1059 and Dst of an IPPM measure. The RFC2895 specifies a 1060 macro for the definition of protocol identifiers while 1061 its companion document, the RFC2896 defines a set of 1062 protocol identifiers. 1064 Notes: An IPPM TypeP does not differ from RMON2 Protocol 1065 identifiers, but TypeP usage in IPPM MIB differs from 1066 Protocol identifier usage in RMON2. A IPPM measure is 1067 active, so generally TypeP does not describe the link 1068 layer (i.e. ether2...). Valid Internet packets are sent 1069 from Src to Dst. Then the choice of the link layer 1070 relies on the Internet stack. 1072 For example, the RFC2896 defines the protocol identifier 1073 '16.0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.23.3.0.0.0' which 1074 represents ether2.ip.tcp.telnet and the protocol 1075 identifier 16.0.0.0.1.0.0.8.0.0.0.0.4.0.0.0.17.3.0.0.0 1076 which stands for ether2.ip.ipip4.udp. The corresponding 1077 TypeP are '12.0.0.8.0.0.0.0.6.0.0.0.23.3.0.0.0' 1078 (ip.tcp.telnet) and 12.0.0.8.0.0.0.0.4.0.0.0.17.3.0.0.0 1079 (ip.ipip4.udp)." 1080 SYNTAX OCTET STRING 1082 IppmReportDefinition ::= TEXTUAL-CONVENTION 1083 STATUS current 1084 DESCRIPTION 1085 "IppmReportDefinition is intended to be used for describing the 1086 report resulting from a measurement. By default, all the results of a 1087 measure belong to the report of this measure. 1089 The first step of the report definition sets up triggers on the 1090 value of the measure, and on the distribution over time of the events 1091 generated by these triggers. 1093 The resulting measures corresponding to an event are reported 1094 periodically, or sent in alarms as soon as the event occurs. 1096 The end of the description describes housekeeping tasks. 1098 An action if performed if the corresponding bit is set to 1. 1100 onSingleton(1): 1101 The actions are performed each time a new result of the 1102 measure occurs. 1104 onMeasureCycle(2): 1105 The actions are performed on the results of the measure 1106 at the end of each cycle of measure. 1108 onMeasureCompletion(3): 1109 The actions are performed on the results of the measure 1110 at the end of the measure. 1112 reportOnlyUptoDownMetricResults(4): 1113 Report the contiguous results that are on opposite sides 1114 of the metric threshold. 1116 reportOnlyExceededEventsDuration(5): 1117 Report the current result of a series of contiguous 1118 results that exceed the metric threshold when the 1119 duration of the series is over the events duration 1120 threshold seconds. 1122 inIppmReportTable(6): 1123 Store the report in the local ippmReportTable. 1125 inSNMPTrapPDU(7): 1126 Send the report using a SNMP-Trap-PDU. 1128 inSNMPv2TrapPDU(8): 1129 Send the report using a SNMPv2-Trap-PDU. 1131 inInformRequestPDU(9): 1132 Send the report using a SNMP InformRequest-PDU. 1134 inEmail(10): 1135 Send the report using an email. 1137 inSMS(11): 1138 Send the report using a SMS. 1140 clearHistory(12): 1141 Remove all the results corresponding to this measure 1142 from the ippmHistoryTable. 1144 clearReport(13): 1145 Remove all the results corresponding to this measure 1146 from the ippmReportTable. 1147 " 1149 SYNTAX BITS { 1150 none(0), -- reserved 1151 onSingleton(1), 1152 onMeasureCycle(2), 1153 onMeasureCompletion(3), 1154 reportOnlyUptoDownMetricResults(4), 1155 reportOnlyExceededEventsDuration(5), 1156 inIppmReportTable(6), 1157 inSNMPTrapPDU(7), 1158 inSNMPv2TrapPDU(8), 1159 inInformRequestPDU(9), 1160 inEmail(10), 1161 inSMS(11), 1162 clearHistory(12), 1163 clearReport(13) 1164 } 1166 IppmStandardMetrics ::= TEXTUAL-CONVENTION 1167 STATUS current 1168 DESCRIPTION 1169 "The definition of the standardized IPPM metrics. 1170 If the draftMetrics bit is set then the other bits describe a WG 1171 draft metric identifier. 1172 " 1173 SYNTAX BITS { 1174 draftMetrics(0), 1175 instantaneousUnidirectionalConnectivity(1), 1176 instantaneousBidirectionalConnectivity(2), 1177 intervalUnidirectionalConnectivity(3), 1178 intervalBidirectionalConnectivity(4), 1179 intervalTemporalConnectivity(5), 1180 onewayDelay(6), 1181 onewayDelayPoissonStream(7), 1182 onewayDelayPercentile(8), 1183 onewayDelayMedian(9), 1184 onewayDelayMinimum(10), 1185 onewayDelayInversePercentile(11), 1186 onewayPacketLoss(12), 1187 onewayPacketLossPoissonStream(13), 1188 onewayPacketLossAverage(14), 1189 roundtripDelay(15), 1190 roundtripDelayPoissonStream(16), 1191 roundtripDelayPercentile(17), 1192 roundtripDelayMedian(18), 1193 roundtripDelayMinimum(19), 1194 roundtripDelayInversePercentile(20) 1195 } 1196 -- IPPM Mib objects definitions 1198 ippmCompliances OBJECT IDENTIFIER ::= { ippmMib 2 } 1199 ippmOwnersGroup OBJECT IDENTIFIER ::= { ippmMib 3 } 1200 ippmSystemGroup OBJECT IDENTIFIER ::= { ippmMib 4 } 1201 ippmMeasureGroup OBJECT IDENTIFIER ::= { ippmMib 5 } 1202 ippmHistoryGroup OBJECT IDENTIFIER ::= { ippmMib 6 } 1203 ippmNetworkMeasureGroup OBJECT IDENTIFIER ::= { ippmMib 7 } 1204 ippmAggregatedMeasureGroup OBJECT IDENTIFIER ::= { ippmMib 8 } 1205 ippmReportGroup OBJECT IDENTIFIER ::= { ippmMib 9 } 1206 ippmNotifications OBJECT IDENTIFIER ::= { ippmMib 10 } 1208 -- 1209 -- ippmOwnersGroup 1210 -- 1211 -- The ippmOwnersGroup objects are responsible for managing 1212 -- the owners access to the measurements. 1213 -- 1214 -- 1215 ippmOwnersTable OBJECT-TYPE 1216 SYNTAX SEQUENCE OF IppmOwnersEntry 1217 MAX-ACCESS not-accessible 1218 STATUS current 1219 DESCRIPTION 1220 "A NMS entity wishing to create and activate remote Ippm 1221 measurements in an agent must previously be registered 1222 in the ippmOwnersTable. 1224 ippmOwnersTable content is read only. 1226 ippmOwnersTable is mandatory. It contains at least the 1227 owner 'monitor'. 1228 " 1230 ::= { ippmOwnersGroup 1 } 1232 ippmOwnersEntry OBJECT-TYPE 1233 SYNTAX IppmOwnersEntry 1234 MAX-ACCESS not-accessible 1235 STATUS current 1236 DESCRIPTION 1237 "The description of the resources the agent granted to a 1238 SNMP application. 1240 For example, an instance of ippmOwnersOwner with an 1241 OwnerString 'acme', which represents the 14th owner 1242 created in ippmOwnersTable would be named 1243 ippmOwnersEntryOwner.14. 1245 Notes: 1247 The ippmOwnersIndex value is a local index managed 1248 directly by the agent. It is not used in anyway in the 1249 other IPPM tables." 1251 INDEX { ippmOwnersIndex } 1252 ::= { ippmOwnersTable 1 } 1254 IppmOwnersEntry ::= SEQUENCE { 1255 ippmOwnersOwner OwnerString, 1256 ippmOwnersIndex Integer32, 1257 ippmOwnersGrantedMetrics IppmStandardMetrics, 1258 ippmOwnersGrantedRules BITS, 1259 ippmOwnersIpAddress DisplayString, 1260 ippmOwnersEmail DisplayString, 1261 ippmOwnersSMS DisplayString, 1262 ippmOwnersStatus OwnerString 1263 } 1265 ippmOwnersIndex OBJECT-TYPE 1266 SYNTAX Integer32 (1.. 65535) 1267 MAX-ACCESS not-accessible 1268 STATUS current 1269 DESCRIPTION 1270 "An arbitrary index that identifies an entry in this 1271 table" 1272 ::= { ippmOwnersEntry 1 } 1274 ippmOwnersOwner OBJECT-TYPE 1275 SYNTAX OwnerString 1276 MAX-ACCESS read-only 1277 STATUS current 1278 DESCRIPTION 1279 "The owner described by this entry." 1280 ::= { ippmOwnersEntry 2 } 1282 ippmOwnersGrantedMetrics OBJECT-TYPE 1283 SYNTAX IppmStandardMetrics 1284 MAX-ACCESS read-only 1285 STATUS current 1286 DESCRIPTION 1287 " Defines the metrics granted to an owner." 1288 ::= { ippmOwnersEntry 3 } 1290 ippmOwnersGrantedRules OBJECT-TYPE 1291 SYNTAX BITS { 1292 all(0), 1293 readonly(1), 1294 permanent(2), 1295 sender(2), 1296 receive(3), 1297 report(4), 1298 alarm(5) 1299 } 1300 MAX-ACCESS read-only 1301 STATUS current 1302 DESCRIPTION 1303 "Defines the rules this owner may act on in the current IPPM MIB 1304 instance. 1305 all(0): 1306 The owner is granted all the rules. 1307 readonly(1): 1308 The measures (not only the metrics) that this owner may 1309 access are setup by the manager of the point of measure. The owner 1310 can not add new measures for these metrics. The creation and the 1311 configuration of the measures corresponding to these metrics are 1312 managed by the manager of the point of measure. 1313 permanent(2): 1314 The measures (not only the metrics) that this owner may 1315 access are determined by the manager of the point of measure. The 1316 owner can not add new measures for these metrics. The creation and 1317 the first configuration of the measures corresponding to these 1318 metrics are managed by the manager of the point of measure. The owner 1319 may modify the measures parameters of the entries of the 1320 corresponding ippmMeasureEntry whose access is read-write. 1321 Typically this allows the owner to suspend the measures, 1322 to change the beginning and end of the measures. 1324 sender(3): 1325 The owner may only activate measures for those metrics 1326 that send packets from the current point of measure. This flag is 1327 only suitable for network measures. It shall be ignored for derived 1328 metrics. 1329 receiver(2): 1330 The owner may only activate measures for those metrics 1331 that receive packets on the current point of measure. This flag is 1332 only suitable for network measures. It shall be ignored for derived 1333 metrics. Such control increases the security. The owner may not 1334 generate packets from the probe. 1336 report(4): 1337 The owner may setup aggregated metrics on the measures 1338 corresponding to these metrics. 1340 alarm(5): 1341 The owner may setup alarms on the results of the 1342 measures metrics. 1344 e.g.: 1345 if the owner Acme is granted with the metric Instantaneous- 1346 Unidirectional-Connectivity as a Receiver in the current point of 1347 measure, then Acme can not setup a Instantaneous-Unidirectional- 1348 Connectivity to another point of measure. 1349 " 1350 DEFVAL { 1 } 1351 ::= { ippmOwnersEntry 4 } 1353 ippmOwnersIpAddress OBJECT-TYPE 1354 SYNTAX DisplayString 1355 MAX-ACCESS read-only 1356 STATUS current 1357 DESCRIPTION 1358 "The IP address of the NMS corresponding to this owner. 1359 The address is human readable and is represented using the dot 1360 format." 1361 ::= { ippmOwnersEntry 5 } 1363 ippmOwnersEmail OBJECT-TYPE 1364 SYNTAX DisplayString 1365 MAX-ACCESS read-only 1366 STATUS current 1367 DESCRIPTION 1368 "The email address of the NMS corresponding to this 1369 owner." 1370 ::= { ippmOwnersEntry 6 } 1372 ippmOwnersSMS OBJECT-TYPE 1373 SYNTAX DisplayString 1374 MAX-ACCESS read-only 1375 STATUS current 1376 DESCRIPTION 1377 "The SMS phone number of the NMS corresponding to this 1378 owner." 1379 ::= { ippmOwnersEntry 7 } 1381 ippmOwnersStatus OBJECT-TYPE 1382 SYNTAX RowStatus 1383 MAX-ACCESS read-only 1384 STATUS current 1385 DESCRIPTION 1386 "The status of this table entry." 1387 ::= { ippmOwnersEntry 8 } 1389 -- 1390 -- ippmResultSharingTable 1391 -- 1393 ippmResultSharingTable OBJECT-TYPE 1394 SYNTAX SEQUENCE OF IppmResultSharingEntry 1395 MAX-ACCESS not-accessible 1396 STATUS current 1397 DESCRIPTION 1398 " The ippmResultSharingTable controls the access of an 1399 owner to the measure results of other owners. An owner 1400 may grant another access to read the result of its 1401 measure. 1403 Entries may exist in ippmResultSharingTable even if the 1404 measures to be shared are not yet defined. Deleting a 1405 measure entry in the ippmMeasureTable does not delete 1406 the entries corresponding to this measure in the 1407 ippmResultSharingTable. 1409 IppmResultSharingTable is optional. 1410 IppmResultSharingTable content is read only. 1412 If this table is not implemented then the owner has only 1413 access to its measure results." 1415 ::= { ippmOwnersGroup 2 } 1417 ippmResultSharingEntry OBJECT-TYPE 1418 SYNTAX IppmResultSharingEntry 1419 MAX-ACCESS not-accessible 1420 STATUS current 1421 DESCRIPTION 1422 "An entry allows an owner to read the results of a 1423 measure owned by another owner. 1424 It permits 2 typical usages: 1425 1) Creating derived measurements on these results 1426 2) Reading the results from a remote NMS. 1428 Example: if acme.12 is a One-way-Delay(6) measure 1429 Acme may allow Peter to make derived metrics 1430 on the results of this measure. 1431 " 1433 INDEX { ippmResultSharingOwner, ippmResultSharingIndex} 1434 ::= { ippmResultSharingTable 1 } 1436 IppmResultSharingEntry ::= SEQUENCE { 1437 ippmResultSharingOwner OwnerString, 1438 ippmResultSharingIndex Integer32, 1439 ippmResultSharingMeasureOwner OwnerString, 1440 ippmResultSharingMeasureIndex Integer32, 1441 ippmResultSharingGrantedOwner OwnerString, 1442 ippmResultSharingStatus RowStatus 1443 } 1444 ippmResultSharingOwner OBJECT-TYPE 1445 SYNTAX OwnerString 1446 MAX-ACCESS read-only 1447 STATUS current 1448 DESCRIPTION 1449 " The owner of this result control entry. Typically the 1450 owner who created this conceptual row." 1451 ::= { ippmResultSharingEntry 1 } 1453 ippmResultSharingIndex OBJECT-TYPE 1454 SYNTAX Integer32 (1.. 65535) 1455 MAX-ACCESS read-only 1456 STATUS current 1457 DESCRIPTION 1458 " The index of this result control entry. The value is 1459 managed by the owner. On creation a SNMP error 'inconsistentValue' is 1460 returned if this value is already in use by this owner." 1461 ::= { ippmResultSharingEntry 2 } 1463 ippmResultSharingMeasureOwner OBJECT-TYPE 1464 SYNTAX OwnerString 1465 MAX-ACCESS read-only 1466 STATUS current 1467 DESCRIPTION 1468 "The owner of the measure to be shared. The couple 1469 ippmResultSharingMeasureOwner, ippmResultSharingMeasureIndex 1470 identifies absolutely a measure" 1471 ::= { ippmResultSharingEntry 3 } 1473 ippmResultSharingMeasureIndex OBJECT-TYPE 1474 SYNTAX Integer32 (1.. 65535) 1475 MAX-ACCESS read-only 1476 STATUS current 1477 DESCRIPTION 1478 "The index of the measure to be shared." 1479 ::= { ippmResultSharingEntry 4 } 1481 ippmResultSharingGrantedOwner OBJECT-TYPE 1482 SYNTAX OwnerString 1483 MAX-ACCESS read-only 1484 STATUS current 1485 DESCRIPTION 1487 "The owner who is granted access to the result of the 1488 measure described by the couple ippmResultSharingMeasureOwner, 1489 ippmResultSharingMeasureIndex." 1490 ::= { ippmResultSharingEntry 5 } 1492 ippmResultSharingStatus OBJECT-TYPE 1493 SYNTAX RowStatus 1494 MAX-ACCESS read-only 1495 STATUS current 1496 DESCRIPTION 1497 " The status of this table entry. Once the entry status 1498 is set to active." 1499 ::= { ippmResultSharingEntry 6 } 1501 -- 1502 -- ippmSystemGroup 1503 -- 1504 -- 1506 ippmSystemTimer OBJECT-TYPE 1507 SYNTAX GMTDateAndTime 1508 MAX-ACCESS read-only 1509 STATUS current 1510 DESCRIPTION 1511 "The current time of the system." 1512 ::= { ippmSystemGroup 1 } 1514 ippmSystemSynchonizationType OBJECT-TYPE 1515 SYNTAX INTEGER { 1516 other(0), 1517 ntp(1), 1518 gps(2), 1519 cdma(4) 1520 } 1521 MAX-ACCESS read-only 1522 STATUS current 1523 DESCRIPTION 1524 "ippmSystemSynchonizationType describes the mechanism 1525 used to synchronize the system. 1527 Other(0) 1528 The synchronization process must be defined 1529 in the ippmSystemSynchonizationDescription. 1531 Ntp(1) 1532 The system is synchronized using the network 1533 time protocol. The NTP synchronization must be described 1534 in the ippmSystemSynchonizationDescription. 1536 Gps (2) 1537 The system is synchronized using the GPS clocks. 1539 Cdma(4) 1540 The system is synchronized using the CDMA 1541 clocks. 1542 " 1543 ::= { ippmSystemGroup 2 } 1545 ippmSystemSynchonizationDescription OBJECT-TYPE 1546 SYNTAX DisplayString 1547 MAX-ACCESS read-only 1548 STATUS current 1549 DESCRIPTION 1550 "The description of the synchronization process." 1551 ::= { ippmSystemGroup 3 } 1553 ippmSystemClockResolution OBJECT-TYPE 1554 SYNTAX Integer32 1555 MAX-ACCESS read-only 1556 STATUS current 1557 DESCRIPTION 1558 "ippmSystemClockResolution provides the precision of the 1559 clock used for the measures. The unit is 1/10 of 1560 millisecond. For example, the clock on an old Unix host 1561 might advance only once every 10 msec, and thus have a 1562 resolution of only 10 msec." 1564 ::= { ippmSystemGroup 4 } 1566 ippmSystemSynchronisationTime OBJECT-TYPE 1567 SYNTAX DateAndTime 1568 MAX-ACCESS read-only 1569 STATUS current 1570 DESCRIPTION 1571 "The time when the last synchronization of the clock 1572 occured. The last synchronization must be set even if 1573 the synchronization is not automatic." 1574 ::= { ippmSystemGroup 5 } 1576 ippmSystemClockAccuracy OBJECT-TYPE 1577 SYNTAX Integer32 1578 MAX-ACCESS read-only 1579 STATUS current 1580 DESCRIPTION 1581 "The most recent accuracy of the clock computed. The 1582 accuracy must be computed even if the synchronization is 1583 not automatic." 1584 ::= { ippmSystemGroup 6 } 1586 ippmSystemClockSkew OBJECT-TYPE 1587 SYNTAX Integer32 1588 MAX-ACCESS read-only 1589 STATUS current 1590 DESCRIPTION 1591 "The most recent skew of the clock computed. The 1592 ippmSystemSkew must be computed even if the 1593 synchronization is not automatic." 1594 ::= { ippmSystemGroup 7 } 1596 ippmSystemPrevClockAccuracy OBJECT-TYPE 1597 SYNTAX Integer32 1598 MAX-ACCESS read-only 1599 STATUS current 1600 DESCRIPTION 1601 "The previous accuracy of the clock measured. The 1602 ippmSystemPrevClockAccuracy must be computed even if the 1603 synchronization is not automatic." 1604 ::= { ippmSystemGroup 8 } 1606 ippmSystemPrevClockSkew OBJECT-TYPE 1607 SYNTAX Integer32 1608 MAX-ACCESS read-only 1609 STATUS current 1610 DESCRIPTION 1611 "The previous skew of the clock measured. The 1612 ippmSystemPrevClockSkew must be computed even if the 1613 synchronisation is not automatic." 1614 ::= { ippmSystemGroup 9 } 1615 ippmSystemSynchonizationOperStatus OBJECT-TYPE 1616 SYNTAX INTEGER { 1617 other(0), 1618 unsynchronized(1), 1619 initializing(2), 1620 synchronized(4) 1621 } 1622 MAX-ACCESS read-only 1623 STATUS current 1624 DESCRIPTION 1625 " ippmSystemSynchonizationOperStatus describes the 1626 operational status of the clock synchronization. 1628 Other(0) 1629 The status of the synchronization is unknown. 1631 unsynchronized(1) 1632 The system is not synchronized. 1634 initializing(2) 1635 The system is receiving synchronization 1636 information but is not yet synchronized. 1638 synchronized(4) 1639 The system is synchronized. 1640 " 1641 ::= { ippmSystemGroup 10 } 1643 -- 1645 -- 1646 -- 1647 -- ippmMeasureGroup 1648 -- 1649 -- 1650 -- 1652 ippmMetricTable OBJECT-TYPE 1653 SYNTAX SEQUENCE OF IppmMetricEntry 1654 MAX-ACCESS not-accessible 1655 STATUS current 1656 DESCRIPTION 1657 "This table describes the current implementation and is 1658 mandatory. Each IPPM standardized metric must be 1659 described in the table. 1660 In reporting mode, the entries of this table may be not 1661 accessible. It means that the measure software handles 1662 the table internally. 1664 ippmMetricTable is mandatory. 1665 ippmMetricTable content is read only. 1667 " 1668 ::= { ippmMeasureGroup 1 } 1670 ippmMetricEntry OBJECT-TYPE 1671 SYNTAX IppmMetricEntry 1672 MAX-ACCESS not-accessible 1673 STATUS current 1674 DESCRIPTION 1675 "An entry describes the static capabilities of a metric 1676 implementation." 1677 INDEX { ippmMetricIndex } 1678 ::= { ippmMetricTable 1 } 1680 IppmMetricEntry ::= 1681 SEQUENCE { 1682 ippmMetricIndex Integer32, 1683 ippmMetricCapabilities INTEGER, 1684 ippmMetricUnit INTEGER, 1685 ippmMetricDescription DisplayString, 1686 ippmMetricMaxHistorySize Integer32 1687 } 1689 ippmMetricIndex OBJECT-TYPE 1690 SYNTAX Integer32 (1.. 65535) 1691 MAX-ACCESS read-only 1692 STATUS current 1693 DESCRIPTION 1694 "ippmMetricIndex defines an unambiguous index for each 1695 standardized metric. Its value is the value of the node of the 1696 metric in the IPPM-REPORTING-MIB metrics registry 1697 ippmMib.metrics.rfc. 1698 Each metric registered in the standard registry must be present 1699 in this table. 1700 This index is used to identify the metric calculated between the 1701 IPPM-REPORTING-MIB entities involved in the measure. 1702 Example: 1703 The index of the metric onewayPacketLossAverage which is 1704 registered as ippmMib.metrics.rfc.onewayPacketLossAverage will 1705 always have the value 14." 1706 ::= { ippmMetricEntry 1 } 1708 ippmMetricCapabilities OBJECT-TYPE 1709 SYNTAX INTEGER { 1710 notImplemented(0), 1711 implemented(1) 1712 } 1713 MAX-ACCESS read-only 1714 STATUS current 1715 DESCRIPTION 1716 "notImplemented 1717 the metric is not implemented. 1718 implemented 1719 the metric is implemented." 1720 DEFVAL { implemented } 1721 ::= { ippmMetricEntry 2 } 1723 ippmMetricUnit OBJECT-TYPE 1724 SYNTAX INTEGER { 1725 noUnit(0), 1726 second(1), 1727 ms(2), 1728 us(3), 1729 ns(4), 1730 percentage(5), 1731 packets(6), 1732 byte(6), 1733 kbyte(7), 1734 megabyte(8) 1735 } 1736 MAX-ACCESS read-only 1737 STATUS current 1738 DESCRIPTION 1739 "The unit used in the current entity for the results of 1740 the measurement of this metric." 1741 ::= { ippmMetricEntry 3 } 1743 ippmMetricDescription OBJECT-TYPE 1744 SYNTAX DisplayString 1745 MAX-ACCESS read-only 1746 STATUS current 1747 DESCRIPTION 1748 "A textual description of the metric implementation." 1749 ::= { ippmMetricEntry 4 } 1751 ippmMetricMaxHistorySize OBJECT-TYPE 1752 SYNTAX Integer32 1753 MAX-ACCESS read-only 1754 STATUS current 1755 DESCRIPTION 1756 "Specifies the maximum number of results that a metric 1757 measure can save in the ippmHistoryTable." 1758 ::= { ippmMetricEntry 5 } 1760 -- 1761 -- ippmMeasureTable 1762 -- 1763 -- 1765 ippmMeasureTable OBJECT-TYPE 1766 SYNTAX SEQUENCE OF IppmMeasureEntry 1767 MAX-ACCESS not-accessible 1768 STATUS current 1769 DESCRIPTION 1770 "The table of all the IPPM measures which are running in 1771 the device. They may not all be active. 1773 A measure consists of a subset of metrics to compute. 1774 The results of the measure may be saved in the 1775 ippmHistoryTable. The configuration of the measure sets 1776 the size of the history requested in 1777 ippmMeasureHystorySize. 1779 The maximum number of MIB objects to be collected in the 1780 portion of ippmHistoryTable associated with this metric 1781 depends on the value of the ippmMetricMaxHistorySize. 1783 The value of each metric ippmMeasureHystorySize must not 1784 be over the value of ippmMetricMaxHistorySize 1785 corresponding to this metric in the ippmMetricTable. 1787 The ippmMeasureTable is mandatory. 1789 ippmMeasureTable content is read only. It means that the 1790 table is handled internally by the measurement 1791 software. 1792 " 1793 ::= { ippmMeasureGroup 2 } 1795 ippmMeasureEntry OBJECT-TYPE 1796 SYNTAX IppmMeasureEntry 1797 MAX-ACCESS not-accessible 1798 STATUS current 1799 DESCRIPTION 1800 "The measure entries are created/deleted internally by 1801 the measurement software. 1803 " 1804 INDEX { ippmMeasureOwner, ippmMeasureIndex } 1805 ::= { ippmMeasureTable 1 } 1807 IppmMeasureEntry ::= 1808 SEQUENCE { 1809 ippmMeasureOwner OwnerString, 1810 ippmMeasureIndex Integer32, 1811 ippmMeasureName DisplayString, 1812 ippmMeasureMetrics IppmStandardMetrics, 1813 ippmMeasureBeginTime GMTDateAndTime, 1814 ippmMeasureClockPeriodUnit TimeUnit, 1815 ippmMeasureClockPeriod Integer32, 1816 ippmMeasureDurationUnit TimeUnit, 1817 ippmMeasureDuration Integer32, 1818 ippmMeasureHystorySize Integer32, 1819 ippmMeasureStorageType StorageType, 1820 ippmMeasureStatus RowStatus 1821 } 1823 ippmMeasureOwner OBJECT-TYPE 1824 SYNTAX OwnerString 1825 MAX-ACCESS read-only 1826 STATUS current 1827 DESCRIPTION 1828 "The owner who has configured this entry." 1829 DEFVAL { "acme" } 1830 ::= { ippmMeasureEntry 1 } 1832 ippmMeasureIndex OBJECT-TYPE 1833 SYNTAX Integer32 (1.. 65535) 1834 MAX-ACCESS read-only 1835 STATUS current 1836 DESCRIPTION 1837 "The owner index of the measure. The value is managed by 1838 the owner." 1839 ::= { ippmMeasureEntry 2 } 1841 ippmMeasureName OBJECT-TYPE 1842 SYNTAX DisplayString 1843 MAX-ACCESS read-only 1844 STATUS current 1845 DESCRIPTION 1846 "The name of the instance of the metric. It illustrates 1847 the specificity of the metric and includes the metric 1848 and the typeP. 1850 example: IP-port-HTTP-connectivity" 1851 ::= { ippmMeasureEntry 3 } 1853 ippmMeasureMetrics OBJECT-TYPE 1854 SYNTAX IppmStandardMetrics 1855 MAX-ACCESS read-only 1856 STATUS current 1857 DESCRIPTION 1858 "Defines the metrics to compute within this measure. A 1859 measure may be configured for the result of different 1860 metric singletons to be archived in the 1861 ippmHistoryTable. The ippmMetricIndex of the created 1862 result has the value of the bit index of the 1863 corresponding ippmMeasureMetrics as explained above in 1864 the ippmMetricIndex definition. 1866 Example: 1867 A measure asking for One-way-Delay(6) and One-way- 1868 Packet-Loss(12) generated a flow of singletons which are 1869 logged in the ippmHistoryTable. The singletons created 1870 for the One-way-Delay measure have a value of 1871 ippmMetricIndex of 6 while the created singletons for 1872 the One-way-Packet-Loss measure have a value of 1873 ippmMetricIndex of 12." 1874 DEFVAL { { one-way-Delay, one-way-Packet-Loss } } 1875 ::= { ippmMeasureEntry 4 } 1877 ippmMeasureBeginTime OBJECT-TYPE 1878 SYNTAX GMTDateAndTime 1879 MAX-ACCESS read-only 1880 STATUS current 1881 DESCRIPTION 1882 "Specifies the time at which the measure starts." 1883 ::= { ippmMeasureEntry 5 } 1885 ippmMeasureClockPeriodUnit OBJECT-TYPE 1886 SYNTAX TimeUnit 1887 MAX-ACCESS read-only 1888 STATUS current 1889 DESCRIPTION 1890 "Specifies the unit of the measure period." 1891 DEFVAL { second } 1892 ::= { ippmMeasureEntry 6 } 1894 ippmMeasureClockPeriod OBJECT-TYPE 1895 SYNTAX Integer32 1896 MAX-ACCESS read-only 1897 STATUS current 1898 DESCRIPTION 1899 "Specifies the amount of time between 2 measurement 1900 action intervals. The action is specific to the semantic 1901 of the measure. 1903 Network metrics: 1905 The ippmNetworkMeasureClockPattern transforms the flow 1906 of periodical instants as a flow of unpredictable 1907 instants of measurement packet emission. 1909 As the source and the sink share the definition of the 1910 clock of the measure, as the sending timestamp is part 1911 of the measurement packet, the sink have the information 1912 to verify that the stream of packets generated by the 1913 source respects the clock law. 1915 Aggregated metrics: 1917 They are performed periodically on a sequence of results 1918 of other measures. The period corresponds to the 1919 interval between two successive computations of the 1920 metric. The ippmHistoryTimeMark result value of the 1921 metric computed corresponds to the ippmHistoryTimeMark 1922 value of the last metric result of the sequence used in 1923 the computation." 1924 DEFVAL { 60 } 1925 ::= { ippmMeasureEntry 7 } 1927 ippmMeasureDurationUnit OBJECT-TYPE 1928 SYNTAX TimeUnit 1930 MAX-ACCESS read-only 1931 STATUS current 1932 DESCRIPTION 1933 "Specifies the unit of the measure duration." 1934 DEFVAL { second } 1935 ::= { ippmMeasureEntry 8 } 1937 ippmMeasureDuration OBJECT-TYPE 1938 SYNTAX Integer32 1939 MAX-ACCESS read-only 1940 STATUS current 1941 DESCRIPTION 1942 "Specifies the duration of the measure." 1943 DEFVAL { 120 } 1944 ::= { ippmMeasureEntry 9 } 1946 ippmMeasureHystorySize OBJECT-TYPE 1947 SYNTAX Integer32 1948 MAX-ACCESS read-only 1949 STATUS current 1950 DESCRIPTION 1951 "Specifies the maximum number of results saved for each 1952 metric of this measure. The history of each metric is 1953 managed as a circular table. The newest result 1954 overwrites the oldest one when the history granted to 1955 this metric measure is full. 1957 The management of the results may be optimized if 1958 synchronized with the reports steps of this measure. 1959 " 1960 DEFVAL { 120 } 1961 ::= { ippmMeasureEntry 10 } 1963 ippmMeasureStorageType OBJECT-TYPE 1964 SYNTAX StorageType 1965 MAX-ACCESS read-only 1966 STATUS current 1967 DESCRIPTION 1968 "This object defines whether this row and the measure 1969 controlled by this row are kept in volatile storage and 1970 lost upon reboot or if this row is backed up by 1971 non-volatile or permanent storage. 1972 Possible values are: other(1), volatile(2), nonVolatile(3), 1973 permanent(4), readOnly(5)" 1974 DEFVAL { nonVolatile } 1975 ::= { ippmMeasureEntry 11 } 1977 ippmMeasureStatus OBJECT-TYPE 1978 SYNTAX RowStatus 1979 MAX-ACCESS read-only 1980 STATUS current 1981 DESCRIPTION 1982 "The status of this table entry. Once the entry status 1983 is set to active, the associate entry cannot be 1984 modified." 1985 DEFVAL { createAndGo } 1986 ::= { ippmMeasureEntry 12 } 1988 -- 1989 -- ippmHistoryGroup 1990 -- 1991 -- 1993 -- 1994 -- ippmHistoryTable 1995 -- 1997 ippmHistoryTable OBJECT-TYPE 1998 SYNTAX SEQUENCE OF IppmHistoryEntry 1999 MAX-ACCESS not-accessible 2000 STATUS current 2001 DESCRIPTION 2002 "The table of the results of the measures." 2004 ::= { ippmHistoryGroup 1 } 2006 ippmHistoryEntry OBJECT-TYPE 2007 SYNTAX IppmHistoryEntry 2008 MAX-ACCESS not-accessible 2009 STATUS current 2010 DESCRIPTION 2012 "An ippmHistoryEntry entry is one of the results of a 2013 measure identified by the index members ippmMeasureOwner 2014 and ippmMeasureIndex. 2016 In the index : 2018 + ippmMeasureOwner and ippmMeasureIndex identify 2019 the ippmMeasureEntry on whose behalf this entry was 2020 created 2021 + ippmMetricIndex identifies the ippmMetricEntry 2022 of the metric to measure 2023 + ippmLogTimeMark value is the absolute time 2024 when the result of the metric was measured. 2026 The ippmHistoryTimeMark value is the absolute time when 2027 the ippmHistoryValue was performed. 2029 IppmHistoryValue is the value of the metric measured at 2030 the time ippmHistoryTimeMark. 2032 Example: 2033 A one way delay measure is created by the entity 'acme' 2034 using the owner index 1 and setting the 6th bit 2035 (corresponding to One-way-Delay) of ippmMeasureMetrics 2036 to 1. 2037 Consider that the result of the one way delay measured 2038 for acme on the day 15 of June at 8h20mn 10s 50ms is 23. 2039 The result is identified as the singleton 2040 ippmHistoryValue.acme.1.6.0001000201090200010501000BEBC2 2041 00 and stored with value 23. 2043 Its value may be retrieved using a get- 2044 next(ippmHistoryValue.acme.1.6.0001000201090200010501000 2045 0000000) which returns 2046 (ippmHistoryValue.acme.1.6.0001000201090200010501000BEBC 2047 200 == 23). The ippmMetricIndex value of '6' corresponds 2048 to the 6th metric of ippmMetricTable which is Type-P- 2049 One-way-Delay. 2050 " 2051 INDEX { ippmMeasureOwner, ippmMeasureIndex, ippmMetricIndex, 2052 ippmHistoryTimeMark } 2053 ::= { ippmHistoryTable 1 } 2055 IppmHistoryEntry ::= 2056 SEQUENCE { 2057 ippmHistoryTimeMark GMTDateAndTime, 2058 ippmHistorySqceNdx Integer32, 2059 ippmHistoryValue Integer32 2060 } 2061 ippmHistoryTimeMark OBJECT-TYPE 2062 SYNTAX GMTDateAndTime 2063 MAX-ACCESS read-only 2064 STATUS current 2065 DESCRIPTION 2066 "The instant of the measure of the result." 2067 ::= { ippmHistoryEntry 1 } 2069 ippmHistorySqceNdx OBJECT-TYPE 2070 SYNTAX Integer32 2071 MAX-ACCESS read-only 2072 STATUS current 2073 DESCRIPTION 2075 " ippmHistorySqceNdx is the sequence index of the 2076 measurement results of the measure of a metric. 2078 Network metrics: 2080 It's the sequence index of a measurement packet. Typically, it 2081 identifies the order of the packet in the stream of packets sends by 2082 the source. 2084 Aggregated metrics: 2086 It is the sequence index of the aggregated metric results 2087 computed. 2088 " 2089 ::= { ippmHistoryEntry 2 } 2091 ippmHistoryValue OBJECT-TYPE 2092 SYNTAX Integer32 2093 MAX-ACCESS read-only 2094 STATUS current 2095 DESCRIPTION 2097 "The value of the measure." 2098 ::= { ippmHistoryEntry 3 } 2100 -- 2101 -- ippmNetworkMeasureGroup 2102 -- 2104 -- 2105 -- 2106 -- ippmNetworkMeasureTable 2107 -- 2108 -- 2110 ippmNetworkMeasureTable OBJECT-TYPE 2111 SYNTAX SEQUENCE OF IppmNetworkMeasureEntry 2112 MAX-ACCESS not-accessible 2113 STATUS current 2114 DESCRIPTION 2115 "A entry is a measure which performs network measures 2116 and provides a flow of results. 2118 This table extends the ippmMeasureTable. A network 2119 measure is a specific measure. 2121 It performs several metric measurements per packet 2122 exchange. Each step of a measure produces a singleton 2123 result per metric. The time of the measure and the value 2124 of the metric are saved in the ippmHistoryTable." 2125 ::= { ippmNetworkMeasureGroup 1 } 2127 ippmNetworkMeasureEntry OBJECT-TYPE 2128 SYNTAX IppmNetworkMeasureEntry 2129 MAX-ACCESS not-accessible 2130 STATUS current 2131 DESCRIPTION 2132 " Typically the configuration operation sets both the 2133 values of the new ippmMeasureEntry and of the new 2134 IppmNetworkMeasureEntry. 2136 IppmNetworkMeasureTable is mandatory. 2138 IppmNetworkMeasureTable content is read only. It means 2139 that the measurement software handles the table 2140 internally. 2142 The ippmMeasureMetrics is set to a list of metrics to be 2143 computed from the same raw packet exchange. Each step of 2144 measurement delivers a singleton per chosen metric. 2145 Results are timestamped and saved in the 2146 ippmHistoryTable." 2147 INDEX { ippmMeasureOwner, ippmMeasureIndex } 2148 ::= { ippmNetworkMeasureTable 1 } 2150 IppmNetworkMeasureEntry ::= 2151 SEQUENCE { 2152 ippmNetworkMeasureSrcTypeP TypeP, 2153 ippmNetworkMeasureSrc OCTET STRING, 2154 ippmNetworkMeasureDstTypeP TypeP, 2155 ippmNetworkMeasureDst OCTET STRING, 2156 ippmNetworkMeasureClockPattern OCTET STRING, 2157 ippmNetworkMeasureTimeoutDelay Integer32, 2158 ippmNetworkMeasureL3PacketSize Integer32, 2159 ippmNetworkMeasureDataPattern OCTET STRING 2160 } 2162 ippmNetworkMeasureSrcTypeP OBJECT-TYPE 2163 SYNTAX TypeP 2164 MAX-ACCESS read-only 2165 STATUS current 2166 DESCRIPTION 2167 "Defines the type P of the source address of the packets 2168 sent by the measure." 2169 DEFVAL { '04000080001000'H } -- ->ip: 4.0.0.8.0.1.0 2170 ::= { ippmNetworkMeasureEntry 1 } 2172 ippmNetworkMeasureSrc OBJECT-TYPE 2173 SYNTAX OCTET STRING 2174 MAX-ACCESS read-only 2175 STATUS current 2176 DESCRIPTION 2177 "Specifies the address of the source of the measure. 2179 It is represented as an octet string with specific 2180 semantics and length as identified by the 2181 ippmNetworkMeasureSrcTypeP. 2183 For example, if the ippmNetworkMeasureSrcTypeP indicates 2184 an encapsulation of 'ip', this object length is 4, 2185 followed by the 4 octets of the IP address, in network 2186 byte order." 2187 DEFVAL { '04C0210415'H } -- -> ip: 192.33.4.21 2188 ::= { ippmNetworkMeasureEntry 2} 2190 ippmNetworkMeasureDstTypeP OBJECT-TYPE 2191 SYNTAX TypeP 2192 MAX-ACCESS read-only 2193 STATUS current 2194 DESCRIPTION 2195 "Defines the type P of the destination address of the 2196 packets sent by the measure." 2197 DEFVAL { '04000080001000'H } -- ->ip: 4.0.0.8.0.1.0 2198 ::= { ippmNetworkMeasureEntry 3 } 2200 ippmNetworkMeasureDst OBJECT-TYPE 2201 SYNTAX OCTET STRING 2202 MAX-ACCESS read-only 2203 STATUS current 2204 DESCRIPTION 2205 "Specifies the address of the destination of the 2206 measure. 2208 It is represented as an octet string with specific 2209 semantics and length as identified by the 2210 ippmNetworkMeasureDstTypeP. 2212 For example, if the ippmNetworkMeasureDstTypeP indicates 2213 an encapsulation of 'ip', this object length is 4, 2214 followed by the 4 octets of the IP address, in network 2215 byte order." 2216 DEFVAL { '04C0220414'H } -- -> ip: 192.34.4.20 2217 ::= { ippmNetworkMeasureEntry 4 } 2219 ippmNetworkMeasureClockPattern OBJECT-TYPE 2220 SYNTAX OCTET STRING 2221 MAX-ACCESS read-only 2222 STATUS current 2223 DESCRIPTION 2224 "This cyclic clock shapes the profile of the instants of 2225 measurement action provided by ippmMeasureClockPeriod 2226 according to an arbitrary distribution law. The clock 2227 resolution is ippmMeasureClockPeriod. The bits of the 2228 clock pattern set to the value 1 determine the valid 2229 instants of measurement action. A measure is to be 2230 processed if and only if the current bit value is 1. 2232 This pseudo-random clock pattern allows the 2233 configuration by the NMS of numerous kind of time 2234 sampling law such as periodic, pseudo random or Poisson. 2236 The source of the measure sends the stream of 2237 measurement packets synchronously with the stream of 2238 instants selected by the clock pattern sampling. 2239 " 2240 DEFVAL { 11111111} -- 100% periodic 2241 ::= { ippmNetworkMeasureEntry 5 } 2243 ippmNetworkMeasureTimeoutDelay OBJECT-TYPE 2244 SYNTAX Integer32 2245 MAX-ACCESS read-only 2246 STATUS current 2247 -- UNITS "Milliseconds" 2248 DESCRIPTION 2249 "Specifies the delay after which the packet is 2250 considered lost by the sink." 2251 DEFVAL { 1 } 2252 ::= { ippmNetworkMeasureEntry 6 } 2254 ippmNetworkMeasureL3PacketSize OBJECT-TYPE 2255 SYNTAX Integer32 2256 MAX-ACCESS read-only 2257 STATUS current 2258 DESCRIPTION 2259 "Specifies the size of the packets sent at the last 2260 network layer in regards to the TypeP definition." 2261 DEFVAL { 64 } 2262 ::= { ippmNetworkMeasureEntry 7 } 2264 ippmNetworkMeasureDataPattern OBJECT-TYPE 2265 SYNTAX OCTET STRING 2266 MAX-ACCESS read-only 2267 STATUS current 2268 DESCRIPTION 2269 "The current field defines the round robin pattern used 2270 to fill the packet." 2271 DEFVAL { 'FF'H } 2272 ::= { ippmNetworkMeasureEntry 8 } 2274 -- 2275 -- 2276 -- ippmAggregatedMeasureGroup 2277 -- 2278 -- 2279 -- 2280 -- 2281 -- ippmAggregatedMeasureTable 2282 -- 2283 -- 2285 ippmAggregatedMeasureTable OBJECT-TYPE 2286 SYNTAX SEQUENCE OF IppmAggregatedMeasureEntry 2287 MAX-ACCESS not-accessible 2288 STATUS current 2289 DESCRIPTION 2290 " This table extends the ippmMeasureTable. 2291 An aggregated measure summarizes the results of previous 2292 network or aggregated measures. The results may be saved 2293 in the ippmHistoryTable. 2295 Each step of the calculation for the measure produces a 2296 singleton result per metric." 2297 ::= { ippmAggregatedMeasureGroup 1 } 2299 ippmAggregatedMeasureEntry OBJECT-TYPE 2300 SYNTAX IppmAggregatedMeasureEntry 2301 MAX-ACCESS not-accessible 2302 STATUS current 2303 DESCRIPTION 2304 "Typically the configuration operation sets both the values of 2305 the new ippmMeasureEntry and of the new 2306 IppmAggregatedMeasureEntry. 2308 ippmAggregatedMeasureTable is mandatory. 2310 ippmAggregatedMeasureTable content is read only. It means that 2311 the measure software handles the table internally. 2313 The ippmMeasureMetrics defines the metric to compute. 2314 The results of the measure to summarize are identified 2315 by: 2316 + ippmAggregatedMeasureHistoryOwner, 2317 + ippmAggregatedMeasureHistoryOwnerIndex and 2318 + ippmAggregatedMeasureHistoryMetric 2320 The aggregated task starts at ippmMeasureBeginTime and ends 2321 after ippmMeasureDuration. An aggregated result is performed and 2322 saved in the ippmHistoryTable for each ippmMeasureClockPeriod 2323 tick. 2324 " 2325 INDEX { ippmMeasureOwner, ippmMeasureIndex } 2326 ::= { ippmAggregatedMeasureTable 1 } 2328 IppmAggregatedMeasureEntry ::= 2329 SEQUENCE { 2330 ippmAggregatedMeasureHistoryOwner OwnerString, 2331 ippmAggregatedMeasureHistoryOwnerIndex Integer32, 2332 ippmAggregatedMeasureHistoryMetric Integer32 2333 } 2335 ippmAggregatedMeasureHistoryOwner OBJECT-TYPE 2336 SYNTAX OwnerString 2337 MAX-ACCESS read-only 2338 STATUS current 2339 DESCRIPTION 2340 "The owner of the measure to summarize. " 2341 ::= { ippmAggregatedMeasureEntry 1 } 2343 ippmAggregatedMeasureHistoryOwnerIndex OBJECT-TYPE 2344 SYNTAX Integer32 (1.. 65535) 2345 MAX-ACCESS read-only 2346 STATUS current 2347 DESCRIPTION 2348 "The owner index of the measure to summarize. " 2349 ::= { ippmAggregatedMeasureEntry 2 } 2351 ippmAggregatedMeasureHistoryMetric OBJECT-TYPE 2352 SYNTAX Integer32 2353 MAX-ACCESS read-only 2354 STATUS current 2355 DESCRIPTION 2356 "The metric of the measure to summarize. " 2357 ::= { ippmAggregatedMeasureEntry 3 } 2359 -- 2360 -- ippmReportGroup 2361 -- 2363 -- 2364 -- 2365 -- ippmReportSetupTable 2366 -- 2367 -- 2369 ippmReportSetupTable OBJECT-TYPE 2370 SYNTAX SEQUENCE OF IppmReportSetupEntry 2371 MAX-ACCESS not-accessible 2372 STATUS current 2373 DESCRIPTION 2374 "The ippmReportSetupTable is a list of definition of reports. It 2375 defines the results of a network or aggregated measures that are to 2376 be reported. A report is saved in the ippmReportTable, or sent to an 2377 application using a SNMP Trap, a SNMP inform PDU, an email or a SMS. 2378 The reporting task is not intended to be a batch action processed at 2379 the end of the measure. It is coupled with threshold detections and 2380 event filtering to deliver application level events and data, while 2381 preserving scalability. 2383 It extends the definition of a measure: the definition of a measure 2384 may include the definition of a report." 2385 ::= { ippmReportGroup 1 } 2387 ippmReportSetupEntry OBJECT-TYPE 2388 SYNTAX IppmReportSetupEntry 2389 MAX-ACCESS not-accessible 2390 STATUS current 2391 DESCRIPTION 2392 "The report applies to the results of the measure which is extended 2393 by the current report definition. 2395 Typically the creation of a report sets both the values of the new 2396 measure and those of the new IppmReportSetupEntry. 2397 The ippmReportSetupDefinition describes the data and the events to 2398 include in the report. The definition consists in a list of tasks to 2399 perform on the results of the measure." 2400 INDEX { ippmMeasureOwner, ippmMeasureIndex } 2401 ::= { ippmReportSetupTable 1 } 2403 IppmReportSetupEntry ::= 2404 SEQUENCE { 2405 ippmReportSetupDefinition IppmReportDefinition, 2406 ippmReportSetupMetricThreshold Integer32, 2407 ippmReportSetupEventsDurationThreshold Integer32, 2409 ippmReportSetupNMS DisplayString 2410 } 2412 ippmReportSetupDefinition OBJECT-TYPE 2413 SYNTAX IppmReportDefinition 2414 MAX-ACCESS read-only 2415 STATUS current 2416 DESCRIPTION 2417 "The description of the events and actions that are used in the 2418 definition of the report. 2419 Send the report using the type of message selected by the bits 8 2420 to 12. The report consists of the results of the measure which have 2421 been saved in the ippmReportTable. If the onEventSendReport(7) bit is 2422 unset, the report is not saved. 2424 The message sent is a notification defined in the 2425 ippmNotifications node. The notification sent depends on the step of 2426 the measure: 2428 + Singleton events are sent using the notification 2429 ippmSingletonAlarm 2430 + Exceeded events durations are sent using the 2431 notification ippmEventsDurationExceededAlarm 2432 + A report of a cycle of measure is sent using the 2433 notification ippmCycleOfMeasureReport 2434 + A report of a complete measure is sent using the 2435 notification ippmCompletedMeasureReport 2437 Example 1: 2438 The setup of an alarm to be sent to the owner in a SNMP Trap 2439 each time the staircase crosses the metric threshold value of 5: 2441 ippmReportSetupMetricThreshold 5 2442 ippmReportSetupDefinition { 2443 onSingleton(1), 2444 reportOnlyUptoDownMetricResults(4), 2445 inSNMPTrapPDU(8) 2446 } 2448 Example 2: 2449 The setup of a report to be sent to the owner in a SNMP 2450 informRequestPDU per measure cycle. It reports the staircase values 2451 corresponding to a metric threshold of 5: 2453 ippmReportSetupMetricThreshold 5 2454 ippmReportSetupDefinition { 2455 onMeasureCycle(2), 2456 reportOnlyUptoDownMetricResults(4), 2457 inInformRequestPDU(10), 2458 clearHistory(13) 2459 } 2461 Default report: 2462 The default report provides the control protocol with an 2463 implicit mechanism to forward the result of a cycle of measure to the 2464 owner of the measure while deleting the results from the 2465 ippmHistoryTable on reception of the response to the InformRequestPDU 2466 : 2468 ippmReportSetupDefinition { 2469 onMeasureCycle(2), 2470 inInformRequestPDU(10), 2471 clearHistory(13) 2472 } 2473 " 2474 DEFVAL { { onMeasureCycle, inInformRequestPDU, clearHistory } } 2475 ::= { ippmReportSetupEntry 1 } 2477 ippmReportSetupMetricThreshold OBJECT-TYPE 2478 SYNTAX Integer32 2479 MAX-ACCESS read-only 2480 STATUS current 2481 DESCRIPTION 2482 "An event is generated when the result of the measure exceeds 2483 the value of ippmReportSetupMetricThreshold. 2484 The threshold has the same unit as the metric. The metric unit 2485 is recorded in the object ippmMetricsUnit of this metric entry in the 2486 ippmMetricTable. 2487 " 2488 ::= { ippmReportSetupEntry 2 } 2490 ippmReportSetupEventsDurationThreshold OBJECT-TYPE 2491 SYNTAX Integer32 2492 UNITS "Seconds" 2493 MAX-ACCESS read-only 2494 STATUS current 2495 DESCRIPTION 2496 "An event is generated when the duration of a series of results, 2497 which are continuously over the metric threshold, cross over the 2498 duration of the ippmReportSetupEventsDurationThreshold. 2499 " 2500 DEFVAL { 15 } 2501 ::= { ippmReportSetupEntry 3 } 2503 ippmReportSetupNMS OBJECT-TYPE 2504 SYNTAX DisplayString 2505 MAX-ACCESS read-only 2506 STATUS current 2507 DESCRIPTION 2508 "The recipient of the report may be provided in the setup. By 2509 default the recipient of the report is the owner of the measure. Its 2510 addresses are recorded in the ippmOwnersTable. 2511 " 2512 ::= { ippmReportSetupEntry 4 } 2514 -- 2515 -- ippmReportTable 2516 -- 2518 ippmReportTable OBJECT-TYPE 2519 SYNTAX SEQUENCE OF IppmReportEntry 2520 MAX-ACCESS not-accessible 2521 STATUS current 2522 DESCRIPTION 2523 "The ippmReportTable logs the results of the reports. 2524 The results consist of a subset of the results of a measure as 2525 described in the report definition. The activation of an up and down 2526 filtering in the report definition limits the results logged to those 2527 corresponding to major events. Otherwise, the ippmReportTable is 2528 identical to the ippmHistoryTable. 2529 " 2531 ::= { ippmReportGroup 2 } 2533 ippmReportEntry OBJECT-TYPE 2534 SYNTAX IppmReportEntry 2535 MAX-ACCESS not-accessible 2536 STATUS current 2537 DESCRIPTION 2538 "A report is a list of results of a measure. This sample is 2539 associated with the ippmReportSetupEntry which has set up the report. 2540 An ippmReportEntry entry is one of the results of a measure to 2541 report. The measure and the report definition are identified by the 2542 index members ippmMeasureOwner and ippmMeasureIndex. 2544 In the index : 2546 + ippmMeasureOwner and ippmMeasureIndex identify the 2547 ippmMeasureEntry and the ippmReportSetupEntry on whose behalf 2548 this report was created 2550 + ippmMetricIndex identifies the ippmMetricEntry of the metric 2551 measured 2552 + ippmReportTimeMark value is the absolute time when the value 2553 of the metric was measured. 2555 The ippmReportTimeMark value is the absolute time when the 2556 ippmHistoryValue was performed. 2557 IppmHistoryValue is the value of the metric measured at the time 2558 ippmReportTimeMark. 2559 " 2560 INDEX { ippmMeasureOwner, ippmMeasureIndex, ippmMetricIndex, 2561 ippmReportTimeMark } 2562 ::= { ippmReportTable 1 } 2564 IppmReportEntry ::= 2565 SEQUENCE { 2566 ippmReportTimeMark GMTDateAndTime, 2567 ippmReportValue Integer32 2568 } 2569 ippmReportTimeMark OBJECT-TYPE 2570 SYNTAX GMTDateAndTime 2571 MAX-ACCESS read-only 2572 STATUS current 2573 DESCRIPTION 2574 "The instant of the measure of the result." 2575 ::= { ippmReportEntry 1 } 2577 ippmReportValue OBJECT-TYPE 2578 SYNTAX Integer32 2579 MAX-ACCESS read-only 2580 STATUS current 2581 DESCRIPTION 2583 "The value." 2584 ::= { ippmReportEntry 2 } 2586 -- 2587 -- ippmNotifications 2588 -- 2590 ippmSingletonAlarm NOTIFICATION-TYPE 2591 OBJECTS { 2592 ippmReportSetupDefinition, 2593 ippmReportSetupMetricThreshold, 2594 ippmMetricUnit, 2595 ippmHistoryValue 2596 } 2597 STATUS current 2598 DESCRIPTION 2599 "A notification sent because 2 contiguous results are on 2600 opposite sides of the metric threshold value. 2602 The index of the included ippmReportSetupMetricThreshold 2603 object identifies the ippmMeasureEntry and the 2604 ippmResultSetupEntry that specified the threshold. 2606 The notification contains the instances of the 2607 ippmReportValue object that exceeded the threshold. The 2608 ippmHistoryTimeMark of the index identifies the time the 2609 event occurred. 2610 " 2611 ::= { ippmNotifications 1 } 2613 ippmEventsDurationExceededAlarm NOTIFICATION-TYPE 2614 OBJECTS { 2615 ippmReportSetupDefinition, 2616 ippmReportSetupEventsDurationThreshold, 2617 ippmMetricUnit, 2618 ippmHistoryValue 2619 } 2620 STATUS current 2621 DESCRIPTION 2622 "A notification sent when the duration of contiguous 2623 raising ippmReportSetupMetricThreshold exceeds the 2624 ippmReportSetupEventsDurationThreshold value. The index 2625 of the included ippmReportSetupDefinition object 2626 identifies the ippmMeasureEntry and the 2627 ippmResultSetupEntry that specified the report. 2629 The notification contains the instances of the 2630 ippmReportValue objects saved in the ippmReportTable for 2631 this report. The ippmHistoryTimeMark of the index 2632 identifies the time theses measures results where 2633 performed. 2634 " 2635 ::= { ippmNotifications 2 } 2637 ippmCycleOfMeasureReport NOTIFICATION-TYPE 2638 OBJECTS { 2639 ippmReportSetupDefinition, 2640 ippmMetricUnit, 2641 ippmHistoryValue 2642 } 2643 STATUS current 2644 DESCRIPTION 2645 "A notification sent when a measure cycle completes. 2646 The index of the included ippmReportSetupDefinition 2647 object identifies the ippmMeasureEntry and the 2648 ippmResultSetupEntry that specified the report. 2650 The notification contains the instances of the 2651 ippmReportValue objects saved in the ippmReportTable for 2652 this measure cycle. The ippmHistoryTimeMark of the index 2653 identifies the time the measures where performed. 2654 " 2655 ::= { ippmNotifications 3 } 2657 ippmCompletedMeasureReport NOTIFICATION-TYPE 2658 OBJECTS { 2659 ippmReportSetupDefinition, 2660 ippmMetricUnit, 2661 ippmHistoryValue 2662 } 2663 STATUS current 2664 DESCRIPTION 2665 "A notification sent when a measure completes. 2666 The index of the included ippmReportSetupDefinition 2667 object identifies the ippmMeasureEntry and the 2668 ippmResultSetupEntry that specified the report. 2670 The notification contains the instances of the 2671 ippmReportValue objects saved in the ippmReportTable for 2672 this measure cycle. The ippmHistoryTimeMark of the index 2673 identifies the time the measures where performed. 2674 " 2675 ::= { ippmNotifications 4 } 2677 -- 2678 -- Compliance statements 2679 -- 2681 ippmCompliance MODULE-COMPLIANCE 2682 STATUS current 2683 DESCRIPTION 2684 "The compliance statement for SNMP entities which 2685 implement the IPPM MIB" 2686 MODULE -- this module 2687 MANDATORY-GROUPS { ippmSystemGroup, ippmMeasureGroup, 2688 ippmNetworkMeasureGroup, ippmHistoryGroup } 2689 ::= { ippmCompliances 1 } 2691 END 2693 9. Security Considerations 2695 9.1. Privacy 2697 The privacy concerns of network measurement are intrinsically limited 2698 by the active measurements. Unlike passive measurements, there can be 2699 no release of existing user data. 2701 9.2. Measurement aspects 2703 Conducting Internet measurements raises both security and privacy 2704 concerns. This memo does not specify an implementation of the 2705 metrics, so it does not directly affect the security of the Internet 2706 nor of applications that run on the Internet. However, 2707 implementations of these metrics must be mindful of security and 2708 privacy concerns. 2710 There are two types of security concerns: potential harm caused by 2711 the measurements, and potential harm to the measurements. The 2712 measurements could cause harm because they are active, and inject 2713 packets into the network. The measurement parameters MUST be 2714 carefully selected so that the measurements inject trivial amounts of 2715 additional traffic into the networks they measure. If they inject 2716 "too much" traffic, they can skew the results of the measurement, and 2717 in extreme cases cause congestion and denial of service. 2719 The measurements themselves could be harmed by routers giving 2720 measurement traffic a different priority than "normal" traffic, or by 2721 an attacker injecting artificial measurement traffic. If routers can 2722 recognize measurement traffic and treat it separately, the 2723 measurements will not reflect actual user traffic. If an attacker 2724 injects artificial traffic that is accepted as legitimate, the loss 2725 rate will be artificially lowered. Therefore, the measurement 2726 methodologies SHOULD include appropriate techniques to reduce the 2727 probability measurement traffic can be distinguished from "normal" 2728 traffic. 2730 Authentication techniques, such as digital signatures, may be used 2731 where appropriate to guard against injected traffic attacks. 2733 9.3. Management aspects 2735 There are a number of management objects defined in this MIB that 2736 have a MAX-ACCESS clause of read-write and/or read-only. Such objects 2737 may be considered sensitive or vulnerable in some network 2738 environments. The support for SET operations in a non-secure 2739 environment without proper protection can have a negative effect on 2740 network operations. 2742 SNMPv1 by itself is not a secure environment. Even if the network 2743 itself is secure (for example by using IPSec), even then, there is no 2744 control as to who on the secure network is allowed to access and 2745 GET/SET (read/change/create/delete) the objects in this MIB. 2747 It is recommended that the implementors consider the security 2748 features as provided by the SNMPv3 framework. Specifically, the use 2749 of the User-based Security Model RFC 2574 [18] and the View-based 2750 Access Control Model RFC 2575 [21] is recommended. 2752 It is then a customer/user responsibility to ensure that the SNMP 2753 entity giving access to an instance of this MIB, is properly 2754 configured to give access to the objects only to those principals 2755 (users) that have legitimate rights to indeed GET or SET 2756 (change/create/delete) them. 2758 10. References 2760 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 2761 9, RFC 2026, October 1996. 2763 [2]Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for 2764 IP Performance Metrics", RFC 2330, May 1998. 2766 [3] Mahdavi J. and V. Paxson, "IPPM Metrics for Measuring 2767 Connectivity", RFC 2678, September 1999. 2769 [4] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Delay 2770 Metric for IPPM", RFC 2679, September 1999. 2772 [5] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Packet 2773 Loss Metric for IPPM", RFC 2680, September 1999. 2775 [6]Almes, G., Kalidindi, S. and M. Zekauskas, "A Round-trip Delay 2776 Metric for IPPM.", RFC 2681, September 1999. 2778 [7] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for 2779 Describing SNMP Management Frameworks", RFC 2571, April 1999. 2781 [8] Rose, M., and K. McCloghrie, "Structure and Identification of 2782 Management Information for TCP/IP-based Internets", STD 16, RFC 2783 1155, May 1990. 2785 [9] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, 2786 RFC 1212, March 1991. 2788 [10] M. Rose, "A Convention for Defining Traps for use with the 2789 SNMP", RFC 1215, March 1991. 2791 [11] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 2792 M., and S. Waldbusser, "Structure of Management Information 2793 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 2795 [12] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 2796 M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, 2797 RFC 2579, April 1999. 2799 [13] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 2800 M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, 2801 RFC 2580, April 1999. 2803 [14] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple 2804 Network Management Protocol", STD 15, RFC 1157, May 1990. 2806 [15] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 2807 "Introduction to Community-based SNMPv2", RFC 1901, January 1996. 2809 [16] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 2810 "Transport Mappings for Version 2 of the Simple Network Management 2811 Protocol (SNMPv2)", RFC 1906, January 1996. 2813 [17]Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 2814 Processing and Dispatching for the Simple Network Management 2815 Protocol (SNMP)", RFC 2572, April 1999. 2817 [18] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) 2818 for version 3 of the Simple Network Management Protocol (SNMPv3)", 2819 RFC 2574, April 1999. 2821 [19] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol 2822 Operations for Version 2 of the Simple Network Management Protocol 2823 (SNMPv2)", RFC 1905, January 1996. 2825 [20] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2826 2573, April 1999. 2828 [21] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-basedAccess 2829 Control Model (VACM) for the Simple Network Management Protocol 2830 (SNMP)", RFC 2575, April 1999. 2832 [22] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction 2833 to Version 3 of the Internet-standard Network Management 2834 Framework", RFC 2570, April 1999. 2836 [23] Waldbusser, S., "Remote Network Monitoring MIB", STD 59, RFC 2837 2819, Lucent Technologies, May 2000 2839 [24] Waldbusser, S., "Remote Network Monitoring Management 2840 Information Base Version 2 using SMIv2", RFC 2021, International 2841 Network Services, January 1997. 2843 [25] Remote Network Monitoring MIB Protocol Identifier Reference. A. 2844 Bierman, C. Bucci, R. Iddon. RFC RFC2895 ,August 2000. 2846 [26] Remote Network Monitoring MIB Protocol Identifier Macros. A. 2847 Bierman, C. Bucci, R. Iddon. RFC RFC2896, August 2000. 2849 11. Acknowledgments 2851 A Kerbe. 2853 12. Author's Addresses 2855 Emile STEPHAN 2856 France Telecom R & D 2857 2 avenue Pierre Marzin 2858 F-22307 Lannion cedex 2859 Phone: (+ 33) 2 96 05 11 11 2860 Email: emile.stephan@francetelecom.com 2862 Jessie Jewitt 2863 France Telecom R & D 2864 801 Gateway Blvd. Suit 500 2865 South San Francisco, CA 94080 2866 Tel : 1 650 875-1524 2867 Email : jessie.jewitt@francetelecom.com 2869 Full Copyright Statement 2871 "Copyright (C) The Internet Society (2001). All Rights Reserved. 2873 This document and translations of it may be copied and furnished to 2874 others, and derivative works that comment on or otherwise explain it 2875 or assist its implementation may be prepared, copied, published and 2876 distributed, in whole or in part, without restriction of any kind, 2877 provided that the above copyright notice and this paragraph are 2878 included on all such copies and derivative works. However, this 2879 document itself may not be modified in any way, such as by removing 2880 the copyright notice or references to the Internet Society or other 2881 Internet organizations, except as needed for the purpose of 2882 developing Internet standards in which case the procedures for 2883 copyrights defined in the Internet Standards process must be 2884 followed, or as required to translate it into languages other than 2885 English. 2887 The limited permissions granted above are perpetual and will not be 2888 revoked by the Internet Society or its successors or assigns. 2890 This document and the information contained herein is provided on an 2891 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2892 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2893 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2894 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2895 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.