idnits 2.17.1 draft-ietf-ippm-reporting-mib-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 4 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 too long lines in the document, the longest one being 4 characters in excess of 72. ** 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 2845: '...rk. The measurement parameters MUST be...' RFC 2119 keyword, line 2858: '... methodologies SHOULD include approp...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 909 has weird spacing: '... field octet...' == Line 1075 has weird spacing: '...running the I...' == Line 1415 has weird spacing: '...t least the...' == Line 1541 has weird spacing: '... the ippmM...' == Line 2822 has weird spacing: '... noauth exact...' == (2 more instances...) -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. -- 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: '12' is mentioned on line 125, but not defined -- Looks like a reference, but probably isn't: 'RFC 1305' on line 915 == Missing Reference: '18' is mentioned on line 2881, but not defined == Missing Reference: '21' is mentioned on line 2882, but not defined ** Obsolete normative reference: RFC 2571 (ref. '2') (Obsoleted by RFC 3411) ** Downref: Normative reference to an Informational RFC: RFC 1215 (ref. '5') ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '9') ** Downref: Normative reference to an Historic RFC: RFC 1901 (ref. '10') ** Obsolete normative reference: RFC 1906 (ref. '11') (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2574 (ref. '13') (Obsoleted by RFC 3414) ** Obsolete normative reference: RFC 1905 (ref. '14') (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 2573 (ref. '15') (Obsoleted by RFC 3413) ** Obsolete normative reference: RFC 2575 (ref. '16') (Obsoleted by RFC 3415) ** Obsolete normative reference: RFC 2570 (ref. '17') (Obsoleted by RFC 3410) Summary: 17 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Stephan/J. Jewitt 3 Internet Draft France Telecom R&D 4 Document: draft-ietf-ippm-reporting-mib-05.txt February, 2004 5 Category: Standards Track 7 IPPM reporting MIB 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026 [1]. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or made obsolete by other documents at 19 any time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt. 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This memo defines a portion of the Management Information Base (MIB) 31 designed for use with network management protocols in TCP/IP-based 32 internets. 33 In particular, this MIB specifies the objects used for managing the 34 results of the IPPM metrics measures, for pushing alarms, and for 35 reporting the measures results. 37 Table of Contents 39 1. Introduction................................................2 40 2. The IPPM Framework..........................................3 41 3. The SNMP Management Framework...............................3 42 4. Overview....................................................5 43 4.1. Textual Conventions.........................................5 44 4.2 Structure of the MIB.........................................8 45 4.3 Row identification in an application namespace..............10 46 4.4 Relationship of IPPM REPORTING MIB tables...................11 47 5 Measurement architectures...................................12 48 5.1 Proxy architecture..........................................12 49 5.2 Reporting architecture......................................13 50 5.3 Gateway architecture........................................15 51 5.4 Security....................................................15 52 6 Reporting mode integration..................................16 53 6.1 Integration.................................................16 54 6.2 Setup of the network measure table..........................16 55 6.3 Setup of the aggregated measure table.......................16 56 6.4 Updating the history of the MIB.............................17 57 6.5 Default value...............................................17 58 7 Definition..................................................17 59 8 Security Considerations.....................................57 60 8.1 VACM Access control.........................................57 61 8.2 Privacy.....................................................59 62 8.3 Measurement aspects.........................................59 63 8.4 Management aspects..........................................60 64 9 Document management.........................................61 65 9.1 Open issues.................................................61 66 9.2 Changes done since release 04...............................61 67 9.3 Changes done since release 03...............................61 68 9.4 Changes done since release 02...............................62 69 10 References..................................................62 70 11 Acknowledgments.............................................64 71 12 Authors' Addresses..........................................64 73 1. Introduction 74 This memo defines a MIB for managing network measurements based upon 75 the IP performance metrics specified by the IPPM Working Group. 77 The definition of objects in the IPPM MIB are built on notions 78 introduced and discussed in the IPPM Framework document, RFC 2330 79 [ii]. 81 This memo defines a Management Information Base (MIB), and as such it 82 is intended to be respectful of the "Boilerplate for IETF MIBs" 83 defined in http://www.ops.ietf.org/mib-boilerplate.html. 85 There are companion documents to the IPPM-REPORTING-MIB both in the 86 Transport Area (See section 2), and in the Operations and Management 87 Area (See section 3). The reader should be familiar with these 88 documents. 90 2. The IPPM Framework 92 The IPPM Framework consists of 3 major components: 94 A general framework for defining performance metrics, as described in 95 the Framework for IP Performance Metrics, RFC 2330 [2]; 97 A set of standardized metrics which conform to this framework: The 98 IPPM Metrics for Measuring Connectivity, RFC 2678 [iii]; The One-way 99 Delay Metric for IPPM, RFC 2679 [iv]; The One-way Packet Loss Metric 100 for IPPM, RFC 2680 [v]; The Round-trip Delay Metric for IPPM, RFC 101 2681 [vi]; 103 Emerging metrics that are being specified in respect of this 104 framework. 106 3. The SNMP Management Framework 108 The SNMP Management Framework consists of five major components: 110 An overall architecture, described in RFC 2571 [2]. 112 Mechanisms for describing and naming objects and events for the 113 purpose of management. The first version of this Structure of 114 Management Information (SMI) is called SMIv1 and described in STD 16, 115 RFC 1155 [3], STD 16, RFC 1212 [4] and RFC 1215 [5]. The second 116 version, called SMIv2, is described in STD 58, RFC 2578 [6], STD 58, 117 RFC 2579 [7] and STD 58, RFC 2580 [8]. 119 Message protocols for transferring management information. The 120 first version of the SNMP message protocol is called SNMPv1 and 121 described in STD 15, RFC 1157 [9]. A second version of the SNMP 122 message protocol, which is not an Internet standards track protocol, 123 is called SNMPv2c and described in RFC 1901 [10] and RFC 1906 [11]. 124 The third version of the message protocol is called SNMPv3 and 125 described in RFC 1906 [11], RFC 2572 [12] and RFC 2574 [13]. 127 Protocol operations for accessing management information. The 128 first set of protocol operations and associated PDU formats is 129 described in STD 15, RFC 1157 [9]. A second set of protocol 130 operations and associated PDU formats is described in RFC 1905 [14]. 132 A set of fundamental applications described in RFC 2573 [15] and 133 the view-based access control mechanism described in RFC 2575 [16]. 135 A more detailed introduction to the current SNMP Management Framework 136 can be found in RFC 2570 [17]. 138 Managed objects are accessed via a virtual information store, termed 139 the Management Information Base or MIB. Objects in the MIB are 140 defined using the mechanisms defined in the SMI. 142 This memo specifies a MIB module that is compliant to the SMIv2. A 143 MIB conforming to the SMIv1 can be produced through the appropriate 144 translations. The resulting translated MIB must be semantically 145 equivalent, except where objects or events are omitted because no 146 translation is possible (use of Counter64). Some machine readable 147 information in SMIv2 will be converted into textual descriptions in 148 SMIv1 during the translation process. However, this loss of machine 149 readable information is not considered to change the semantics of the 150 MIB. 152 Managed objects are accessed via a virtual information store, termed 153 the Management Information Base or MIB. Objects in the MIB are 154 defined using the subset of Abstract Syntax Notation One (ASN.1) 155 defined in the SMI. In particular, each object type is named by an 156 OBJECT IDENTIFIER, an administratively assigned name. 158 The object type together with an object instance serves to uniquely 159 identify a specific instantiation of the object. For human 160 convenience, we often use a textual string, termed the descriptor, to 161 refer to the object type. 163 4. Overview 165 Although the number of measurement devices that implement IPPM 166 metrics is growing, there is not currently any standardized 167 management interface to manage remotely the measurement of these 168 metrics. This memo defines a Management Information Base for managing 169 the measurement of IPPM metrics. 171 To permit metrics to be referenced by other MIBs and other protocols, 172 the IPPM WG has defined a registry of the current metrics and a 173 framework for the integration of future metrics in the [IPPM metrics 174 registry]. 176 As the specification of new metrics is a continuous process, this 177 memo defines a framework for the integration of the future 178 standardized metrics. 180 The IPPM-REPORTING-MIB introduces a framework where each application 181 identifies its measures in an owner namespace. The administrator may 182 grant access to a measure, or set of measures to another owner via 183 view based access control. As a result, one owner may compute 184 aggregated metrics on another owner�s network measures. 186 Different architectures may be used to perform metric measurements, 187 using a control protocol and a test protocol. Different control 188 frameworks are suitable for performing measurements. The memo lists 189 them, while also looking for a way to integrate them with the IPPM- 190 REPORTING-MIB. This section is for informational purposes only, and 191 is intended to help specify the relationship among the test protocol, 192 the control protocol and the IPPM-REPORTING-MIB. 194 Special care has been taken to provide a reporting mode suitable for 195 control protocols and test protocols. It addresses the need to 196 provide access to results for the applications. 198 This MIB is intended to handle multiple concurrent sessions by SNMP 199 applications. However, the SNMP requests are not necessarily to be 200 handled explicitly by the measurement devices, but can be sent to 201 middleware performing an aggregation function. This allows for 202 continuous collection of measurements and statistics computation. 204 4.1. Textual Conventions 206 Eight types of data are introduced as textual conventions in this 207 document: IppmOwnerString, IppmOwnerIndex, TimeUnit, PacketType, 208 PacketTypeAddress, GMTTimeStamp, IppmStandardMetrics and 209 IppmMetricResultFilter. 211 4.1.1 IppmOwnerString 212 This octet string is used to represent the owners of the various 213 measures and reports in the measurement system. 215 4.1.2 IppmOwnerIndex 217 This integer identifies an instance of an object in an owner 218 namespace. 220 4.1.3 TimeUnit 222 This textual convention is used to indicate a unit of time, ranging 223 from nanosecond, microsecond, millisecond, second, hour, day, and 224 week. 226 4.1.4 PacketType and PacketTypeAddress 228 Section 13 of the IPPM framework [2] introduces the generic notion of 229 a "packet of type P", because in some contexts the metric's value 230 depends on the type of the packets involved in the metric. In the 231 definition of a metric, the type P will be explicitly defined, 232 partially defined, or left generic. Measurement of metrics defined 233 with generic type P are made specific when performing actual 234 measurements. It is important that one be conscious of the exact type 235 of traffic being measured. 237 The standardization of the management of IPPM measures relies on the 238 capability to unambiguously configure the type P of the packets, and 239 the parameters of the protocol suites of the type P. 241 RMON2 introduced the concept of protocol identifiers. RFC2895 [xxv] 242 specifies a macro for the definition of protocol identifier. The 243 RFC2896 [xxvi] defines the protocol identifiers for different 244 protocol encapsulation trees. 246 The type P implementation relies on the MACRO PROTOCOL-IDENTIFIER 247 defined for identifying protocol suites in RMON2. It is achieved by 248 defining the PacketType and the PacketTypeAddress as new syntax in 249 SMIv2 TEXTUAL-CONVENTION. 251 4.1.4.1 Internet addresses 253 The section 14 of the IPPM framework defines (for the usual case of a 254 unidirectional path through the Internet) the term "Src" and "Dst". 255 "Src" denotes the IP address of the beginning of the path, and "Dst" 256 denotes the IP address of the end. 258 The section 3 of the RMON PI Reference specifies the Protocol 259 Identifier Encoding rules, which consists briefly in a recursive 260 length value format. "Src" and "Dst" are protocol identifier 261 parameters. Their values are encoded in separated fields using the 262 encoding rules of the protocol identifier, but without trailing 263 parameters. 265 The packet encapsulation defined in an instance of PacketType embeds 266 the format of "Src" and "Dst" and their values. The type and value of 267 these addresses depend on the type P of the packet, IP version 4, 268 IPV6, IP in IP... Both participate in the completion of the packet 269 encoding. 271 Examples: 273 RFC2896 defines the protocol identifiers ip and ipip4. Should there 274 be an Internet tunnel end-point of the IP address 192.168.1.1 in the 275 tunnel 128.2.6.7. the PacketType of the source address of the tunnel, 276 Src, is 'ip.ipip4'. The encoding of 'ip.ipip4' using the RFC2895 277 rules adds a trailer 2.0.0. It means that an instance of this 278 protocol identifier has 2 parameters, which values will be set only 279 when implemented. In the IPPM PacketType context these 2 parameters 280 are provided in Src (or Dst). In the current example the value of Src 281 is "192.168.1.1 128.2.6.7". 283 4.1.5 GMTTimeStamp 285 This textual convention defines the time at which an event occurred. 286 It is very similar to the NTP timestamp format except that it 287 represents the time elapsed since January 1st, 2000 instead of 288 January 1st, 1900. 290 4.1.6 IppmStandardMetrics 292 Each standard metric is identified in the IPPM-METRICS-REGISTRY under 293 the node rfc in chronological order. This textual convention defines 294 an octet string to permit several metrics to be performed in a single 295 measure. 297 4.1.7 Report definition 299 A report consists of sending, or logging, a subset of results of 300 measurements that have been taken over a period of time. The report 301 defines actions that are taken on the measurement results. An action 302 is performed either: 304 + For each result 305 + On the results corresponding to a measurement cycle 306 + On the results available at the measurement completion. 308 To preserve the scalability of the whole measurement system, it 309 limits: 311 + The amount of data sent to the applications 312 + The bandwidth consumption for uploading the result 313 + The number of alarms sent to the applications 314 + The amount of data saved in the point of measure 316 Metric thresholds (low, high, inband, outband...) may be defined that 317 indicate when measure values should be reported. These values and 318 their associated time may directly impact service availability. 320 One may also want to report when particular values (i.e. constantly 321 over a threshold) repeatedly occur over a period of time. For 322 example, if one-way-day is constantly over a specified acceptable 323 threshold value for 10 minutes, then the values should be reported. 325 The combination of IPPM metric results, threshold events, and event 326 filtering provides a very efficient mechanism to report measurement 327 results, events, and alarms. 329 A report is described using the TEXTUAL-CONVENTION 330 IppmMetricResultFilter. The report setup must not dramatically 331 increase the amount of data needed by the control protocol to setup a 332 measure: 334 + A basic report is defined in the object ippmAggrMeasureFilter; 335 + More elaborate reports are described using a metric threshold to 336 generate alarms and events. 337 + The generation of alarms and reports requires a management station 338 address to which the data will be sent. 339 + SLA alarms are described using an events duration threshold. 341 The TEXTUAL-CONVENTION IppmMetricResultFilter specifies the list of 342 events and actions that are used to create a report. 344 4.2 Structure of the MIB 346 The MIB is arranged as follow: 348 - ippmSystem Group: 350 + ippmPointOfMeasureTable; 351 + ippmSynchronizationTable; 352 + ippmMetricsTable. 354 - ippmOwners Group: 355 - 356 + ippmOwnersTable; 358 - ippmHistory Group: 359 - 360 + ippmHistoryTable; 362 - ippmNetMeasure Group: 363 - 364 + ippmNetMeasureTable; 366 - ippmAggrMeasure Group: 367 - 368 + ippmAggrMeasureTable. 370 - ippmNotifications 372 4.2.1 The ippmSystem Group 374 The implementation of this group is mandatory. 376 This group consists of a set of parameters describing the clock 377 synchronization at a particular point of measure over time, as well 378 as the system clock of the IPPM-REPORTING-MIB agent. 380 The table ippmPointOfMeasureTable describes the points of measure. 382 The table ippmSynchronisationTable is critical to the implementation, 383 especially to be respectful of the Section 6.3. of the IPPM 384 Framework, which states that 385 "Those who develop such measurement methodologies should strive to: 386 + Minimize their uncertainties/errors, 387 + Understand and document the sources of uncertainty/error, and 388 + Quantify the amounts of uncertainty/error." 390 Consequently the table ippmSynchronisationTable makes these values 391 available to compute reliable statistics. 393 The table ippmMetricsTable list all the IPPM metrics using the 394 registry order and describes their implementation (unit...). 396 4.2.2 The ippmOwners Group 398 This group identifies an owner, or group of owners, that have access 399 to measurements on a probe. 401 4.2.3 The ippmHistory Group 403 The results of any given measure are stored in the ippmHistoryTable. 404 The indexing is such that there is an entry in this table for each 405 result of a given measure for a given metric. 407 4.2.4 The ippmNetMeasure Group 408 The control protocol registers a description of the existing network 409 measures in the ippmNetMeasureTable. 411 This group displays the network measures defined by the control 412 protocol. The results are saved in the ippmHistoryTable. 414 ippmNetMeasureTable is a reflection of the configuration of the 415 network measure. 417 4.2.5 The ippmAggrMeasure Group 419 ippmAggrMeasureTable is responsible for the aggregation of results. 420 The aggregated results are saved in the ippmHistoryTable and may be 421 used for higher aggregated measures. 423 4.2.6 The Notification Group 425 The Notification group specifies a list of valid notifications. They 426 are used to generate alarms, or reports, to management applications. 428 4.3 Row identification in an application namespace 430 IPPM metrics measurement is a distributed task. An owner namespace is 431 defined to avoid the need of polling to determine the next free 432 index, to avoid index collision when 2 applications are looking for a 433 new index as the same time; to increase the speed of the management 434 operations; to reduce bandwidth consumption and to reduce CPU load in 435 the agents and applications. 437 In a MIB, an object instance identifier is defined by the clause 438 INDEX of the table as a list of objects. 440 The owner namespace is defined in the INDEX as a couple of 2 objects 441 where the type of first one is IppmOwnerString and the type of the 442 second is IppmOwnerIndex. 444 The first term of the instance identifier is the name of the owner. 445 The second term is an private index managed by the owner. This index 446 value is unique in an owner namespace. Before the creation of an 447 instance the creator pick up an IppmOwnerIndex value not in use. 449 This allows the user to choose arbitrary values for the remaining 450 fields of the INDEX clause without checking that the values of these 451 fields exists in the MIB tables. Moreover this allows the owner to 452 use the same instance identifier over a set of IPPM MIB 453 implementations. 455 Measurements are requested by management applications. An instance of 456 an object managed by a management station is identified by the 457 management station IppmOwnerString and the private index provided by 458 the MS. 460 4.4 Relationship of IPPM REPORTING MIB tables 461 There is inherently a relationship between various tables in the IPPM 462 REPORTING MIB, and as such, the data integrity must be assured. This 463 relationship is depicted in the following examples. 465 4.4.1 Relationship between the Owners Table and the aggregated 466 measure table 468 The owners table contains the list of "owners" that can create and 469 activate remotely aggregated measures in an IPPM agent, or read the 470 existing network measures. 472 It is recommended to make use of "view based access control" in order 473 to restrict access to this table. For example, the master user 474 "administrator" may be given "write" privileges on the 475 ippmOwnersTable, whereas all others are restricted to "read" access. 476 The user "administrator" can then setup the list of other users that 477 have access to measures. 479 There must be at least 1 owner in the owners' table. This owner may 480 be either setup by default by the IPPM agent, or configured as stated 481 above. 483 An owner may have multiple corresponding entries in the network and 484 aggregated measure tables. Each entry in a measure table is 485 associated with one, and only one, entry in the owners' table. That 486 is to say, that a defined measure may NOT have multiple owners. 488 Thus, we have a 1:N relationship between the owners' table and a 489 measure table. 491 4.4.2 Relationship between the Network Measure Table and the 492 Aggregated Measure Table 494 The network measure table is read-only, thus entries in this table 495 must be populated by the agent upon startup. 496 The agent could potentially read a database that contains network 497 measures configured by a 3rd party proprietary management system that 498 directly interacts with the points of measure. However, the "owner" 499 of the measure must be defined in the owners table. It may be either 500 configured directly, or exported to the agent by the external 501 measurement tool. 503 The aggregated measure table allows for an "owner" to create 504 aggregated measures (such as average, minimum, maximum...) on 505 existing measures. An owner may even create aggregated measures on 506 network measures that are owned by other owners. However, it is 507 recommended to use view based access control to grant access of 508 network measures to other owners in the system. 510 5 Measurement architectures 512 There are three main measurement architectures. 514 5.1 Proxy architecture 516 . +----+ +----+ 517 . |NMS1| |NMS2| 518 . +----+ +----+ 519 . ^ ^ 520 . | | 521 . +----------+ +----------+ 522 . | | 523 . SNMP or Sibling 524 . | | 525 . v v 526 . +--------------------------+ 527 . | IPPM-REPORTING-MIB agent | 528 . +--------------------------+ 529 . ^ ^ 530 . | | 531 . OWDP-Control 532 . | | 533 . +----------+ +----------+ 534 . | | 535 . v v 536 .+----------------+ +------------------+ 537 .| Packets-Sender |--OWDP-Test-->| Packets-Receiver | 538 .+----------------+ +------------------+ 540 In this architecture, the different NMS�s query the IPPM-REPORTING- 541 MIB agent for measurements. The agent controls whether the NMS is 542 granted access to perform the measure requested. Each NMS may access 543 the results of its measurements in the IPPM-REPORTING-MIB history 544 table. 546 The measurement setup/teardown and the data collection are done using 547 the control protocol and the test protocol. 549 In this mode the NMS does not depend on the control protocol nor on 550 the test protocol. The entities involved in the measurement do not 551 need to implement the IPPM-REPORTING-MIB nor SNMP. This mode allows 552 for lightweight implementation in the point of measure, and also for 553 heterogeneous control protocols to coexist. 555 Finally, the proxy is a checkpoint where measurement activity may be 556 logged, and where access to measurement setups may be tightly 557 controlled. Thus, it provides a reliable architecture to manage the 558 security of a measurement system. 560 5.2 Reporting architecture 562 In this architecture the SNMP protocol is only used to read the 563 results of the measurements in the IPPM-REPORTING-MIB History Table, 564 and also to inform the NMS that an event has occurred. 566 . +----+ +----+ 567 . |NMS1| |NMS2| 568 . +----+ +----+ 569 . ^ ^ ^ ^ 570 . | | | | 571 . SNMP| SNMP| 572 . | | | | 573 . | | | | 574 . | OWDP | OWDP 575 . |Control |Control 576 . | | | | 577 . | | +------------------------------+ 578 . | | | | | 579 . | | +--|---------------------------+ | 580 . | | | | | | 581 . | +--|--|------------------------+ | | 582 . | | | | | | | 583 . +--------+---------------------+ | | 584 . | | | | | | | | 585 . | | | | | | | | 586 . v v v v v v v v 587 . +------------------+ +------------------+ 588 . |IPPM-REPORTING-MIB| |IPPM-REPORTING-MIB| 589 . | agent | | agent | 590 . +------------------+ +------------------+ 591 . | Packets-Sender |--OWDP-Test-->| Packets-Receiver | 592 . +------------------+ +------------------+ 594 The activation of a measure by the control protocol or the test 595 protocol creates a measure in the IPPM-REPORTING-MIB Network Measure 596 table. The table in question may be not accessible by SNMP. In this 597 case, a list of the measure identifiers (owner, index) is handled by 598 the measurement software. 600 Each timestamped result of the measure is logged in the IPPM- 601 REPORTING-MIB History table in order to allow read access to the 602 NMS�s and event handling. 604 On completion, the measurement results are managed according to the 605 measure setup: 606 + The results may be sent to an NMS; 607 + They may be dropped from the IPPM-REPORTING-MIB History table. 609 In this mode, it is recommended to use an SNMPv2 Inform PDU to send 610 reporting events because it ensures that the entire block of the 611 result is received. There is no control using SNMP Trap PDU. 613 5.3 Gateway architecture 615 The gateway architecture combines the proxy mode and the reporting 616 mode. 618 . +-------+ +------+ 619 . | NMS1 | | NMS2 | 620 . +-------+ +------+ 621 . ^ ^ 622 . | | 623 . SNMP SNMP 624 . | | 625 . | +----------------------------------------+ 626 . | | | 627 . +-------------+ +------------------+ 628 . | | | | | 629 . +----------------------------------------+ | 630 . | | | | | | 631 . | | v v | | 632 . | | +------------------------+ | | 633 . | | | IPPM-REPORTING-MIB | | | 634 . | | | Gateway | | | 635 . | | +------------------------+ | | 636 . | | | control server | | | 637 . | | +------------------------+ | | 638 . | | ^ ^ | | 639 . | | | | | | 640 . | | OWDP-Control protocol | | 641 . | | | | | | 642 . | | +-----+ +-------+ | | 643 . | | | | | | 644 . v v v v v v 645 . +-------------+---------+ +--------+-------------+ 646 . | IPPM- | Packets | |Packets | IPPM | 647 . |REPORTING-MIB| Sender | |Receiver|REPORTING-MIB| 648 . | agent | |-OWDP-Test->| | agent | 649 . +-------------+---------+ +--------+-------------+ 651 The NMS measurement queries are registered in the IPPM-REPORTING-MIB 652 gateway and performed by the control and the test protocol. The NMS 653 directly consults the result in the corresponding IPPM REPORTING MIB 654 agent of the points of measure. 656 5.4 Security 658 The proxy mode provides flexibility and control of the access to the 659 points of measure, while allowing lightweight control protocol and 660 test protocol implementations in the points of measure. Different 661 security rules may be applied to the NMS domain and to measurement 662 system domains. 664 The reporting mode has 2 security domains: 666 + The control of the measurement setup relies on the control and 667 the test protocol security mechanisms; 668 + The control of access to the results depends on the SNMP 669 security mechanisms such as community strings, but may also be 670 restricted using VACM for customized access. 672 The gateway mode security relies on the security of the proxy mode 673 and of the reporting mode. 675 6 Reporting mode integration 677 The IPPM-REPORTING-MIB standardizes the parameters that: 679 + Define the configuration of the IPPM metric measures; 680 + Define the format of the results of the measure; 681 + Define the report of the IPPM metric measure results. 683 It introduces the concept of owner namespace to allow for fast 684 configuration and reporting across multiple points of measurement. 686 A measure is a distributed object describing a task to be performed 687 by the control and the test protocols. A measure is identified by its 688 owner and its owner index. This identifier is the same in all the 689 points of measure. As the owner chooses the index, there is no need 690 for negotiation between the NMS and the points of measure before 691 activating the measure. 693 A measure is primarily defined by its identifier, the metrics to 694 measure, the description of the end point addresses and the 695 description of the scheduling of the measure. 697 The description of the measure is distributed to the points of 698 measure involved. The distribution may not be synchronized. 700 6.1 Integration 702 The integration of the IPPM-REPORTING-MIB, and the test and control 703 protocols consists in pushing the network measure setup/teardown 704 parameters and the result values from the measurement software to the 705 IPPM-REPORTING-MIB agent. 707 6.2 Setup of the network measure table 709 The measurement system updates the MIB on creation of a network measure. 711 6.3 Setup of the aggregated measure table 713 There are 2 ways to setup an aggregated measure: 715 The measurement system updates the MIB on creation of an aggregated 716 measure; 717 An SNMP application creates an aggregated measure. 719 6.4 Updating the history of the MIB 721 Results have to be written by the measurement task in the agent 722 implementing the IPPM REPORTING MIB. 724 Adding the results of a measurement consists in the transfer of the 725 result from the measurement software to the SNMP agent. The protocol 726 that provides the result may be the control protocol, or the test 727 protocol, or another mechanism. 729 6.5 Default value 731 The default values correspond to IP version 4. 733 7 Definition 735 IPPM-REPORTING-MIB DEFINITIONS ::= BEGIN 737 IMPORTS 738 MODULE-IDENTITY, 739 NOTIFICATION-TYPE, 740 OBJECT-TYPE, 741 experimental ,Integer32, zeroDotZero, Counter64, Unsigned32 742 FROM SNMPv2-SMI 743 -- 744 -- ippm 745 -- FROM IPPM-REGISTRY 746 -- 747 InetAddressType, 748 InetAddress 749 FROM INET-ADDRESS-MIB 750 SnmpAdminString 751 FROM SNMP-FRAMEWORK-MIB 752 RowStatus, 753 StorageType, 754 TEXTUAL-CONVENTION 755 FROM SNMPv2-TC 756 MODULE-COMPLIANCE, 757 OBJECT-GROUP, 758 NOTIFICATION-GROUP 759 FROM SNMPv2-CONF; 761 ippmReportingMib MODULE-IDENTITY 762 LAST-UPDATED "200402121200Z" -- 12 February 2004 763 ORGANIZATION "France Telecom - R&D" 764 CONTACT-INFO 765 "Emile Stephan 766 France Telecom - R&D 767 2, Avenue Pierre Marzin 768 Technopole Anticipa 769 22307 Lannion Cedex 770 FRANCE 771 Tel: + 33 2 96 05 36 10 772 E-mail: emile.stephan@francetelecom.com 774 Jessie Jewitt 775 France Telecom - R&D 776 801 Gateway Blvd. Suit 500 777 South San Francisco, CA 94080 778 Tel : 1 650 875-1524 779 E-mail : jessie.jewitt@rd.francetelecom.com" 781 DESCRIPTION 782 " This memo defines a portion of the Management Information Base 783 (MIB) for use with network management protocols in TCP/IP-based 784 internets. In particular, it specifies the objects used for 785 managing the results of the IPPM metrics measurements, alarms and 786 reporting of measurement results." 788 REVISION "200210181200Z" -- 18 October 2002 789 DESCRIPTION 790 "General cleanup 791 Change 5 tables to read write" 793 REVISION "200302141200Z" -- 14 February 2003 794 DESCRIPTION 795 "Modifications based upon feedback from IETF-55" 797 REVISION "200306291200Z" -- 29 June 2003 798 DESCRIPTION 799 "Adaptation to VACM, preparation of the final version" 801 REVISION "200310241200Z" -- 24 October 2003 802 DESCRIPTION 803 "Modifications based upon feedback from experimental 804 implementation." 806 REVISION "200402121200Z" -- 12 February 2004 807 DESCRIPTION 808 "Modifications based upon feedback 58th IETF: The report group 809 and the corresponding notification are removed." 811 ::= { experimental 10001 } -- XXX to be assigned by IANA 813 ippm OBJECT IDENTIFIER ::= { experimental 10000 } 815 -- 816 -- TEXTUAL-CONVENTION 817 -- 819 IppmOwnerString ::= TEXTUAL-CONVENTION 820 STATUS current 821 DESCRIPTION 822 "The owner namespace is defined in the INDEX of a table as a 823 couple of 2 objects where the type of the first one is 824 IppmOwnerString and the type of the second is IppmOwnerIndex. 825 IppmOwnerString is an OwnerString which length is limited to 32 826 bytes." 827 SYNTAX OCTET STRING (SIZE (0..32)) 829 IppmOwnerIndex ::= TEXTUAL-CONVENTION 830 STATUS current 831 DESCRIPTION 832 "The owner namespace is defined in the INDEX of a table as a 833 couple of 2 objects where the type of first one is 834 IppmOwnerString and the type of the second is IppmOwnerIndex. 835 An object of type IppmOwnerIndex uniquely identifies a row of a 836 table inside an owner namespace. 837 Inside one namespace several objects of type IppmOwnerIndex 838 coexist and share the IppmOwnerIndex range of values to provide a 839 unique instance identifier. 840 " 841 SYNTAX Unsigned32 (1.. 65535) 843 TimeUnit ::= TEXTUAL-CONVENTION 844 STATUS current 845 DESCRIPTION 846 "A enumerated list of time units." 847 SYNTAX INTEGER { 848 week(1), 849 day(2), 850 hour(3), 851 minute(4), 852 second(5), 853 millisecond(6), 854 microsecond(7), 855 nanosecond(8) 856 } 857 -- 858 -- 860 IppmStandardMetrics ::= TEXTUAL-CONVENTION 861 STATUS current 862 DESCRIPTION 863 " Each standard metric is identified in the IPPM-METRICS- 864 REGISTRY under the node rfc in chronological order. In order to 865 allow for several metrics to be calculated in a single measure, 866 there is a need to describe in a bit string the metrics to be 867 measured. 869 This textual convention defines an octet string that gathers in a 870 bit string a sequence of bits. The bit order corresponds to the 871 order of the metric identifiers in the registry. 872 The first bit of the string has the index 0. The index 1 873 corresponds to the first metric of the registry 874 (instantaneousUnidirectionalConnectivity ). 876 Example: 877 One-way-Delay(6) is identified as the leaf number 6 of the node 878 rfc of the registry. One-way-Packet-Loss(12) is identified as the 879 leaf number 12 of the node 880 rfc of the registry. A network measure performing both One-way- 881 Delay(6) and One-way-Packet-Loss(12) will be described as 882 '0001000001000000'b, '1040'B. 883 " 884 SYNTAX OCTET STRING (SIZE (1..64)) 886 IppmMetricsRegistryIndex ::= TEXTUAL-CONVENTION 887 STATUS current 888 DESCRIPTION 889 "IppmMetricsRegistryIndex defines an unambiguous index for each 890 standardized metric. It identifies a metric, and as such its 891 value is the value of the node of the metric in the IPPM 892 registry. This value is the same in any implementation of the 893 IPPM REPORTING MIB. 895 Example: 896 In the IPPM-METRICS-REGISTRY, onewayPacketLossAverage is 897 registered as the node 14 of ippmMetricsRegistry.metrics.rfc. 898 Consequently the index of the metric onewayPacketLossAverage in 899 the IppmMetricsTable will always be '14'. At large an instance, 900 which type is IppmMetricsRegistryIndex and which value is '14', 901 points to the metric onewayPacketLossAverage." 902 SYNTAX Unsigned32 (1.. 65535) 904 GMTTimeStamp ::= TEXTUAL-CONVENTION 905 STATUS current 906 DESCRIPTION 907 "The time value at which a measure or an event took place. 909 field octets contents range 910 ----- ------ -------- ----- 911 1 1-4 second since 1 Jan 1900 0H00* 0..2^31 - 1 912 2 5-8 fractional part of the second* 0..2^32 - 1 913 * the value is in network-byte order 915 The timestamp format is the NTP timestamp format [RFC 1305]. 916 The reference of time is GMT. 918 " 919 SYNTAX OCTET STRING (SIZE (8)) 921 PacketType ::= TEXTUAL-CONVENTION 922 STATUS current 923 DESCRIPTION 924 "This textual convention is a display string used to describe the 925 protocol encapsulation list of a packet, and is used as the value 926 of the SYNTAX clause for the type of the Src and Dst of an IPPM 927 measure. The RFC2895 specifies a macro named PROTOCOL-IDENTIFIER 928 for the definition of protocol identifiers, while its companion 929 document, the RFC2896 defines a set of protocol identifiers. 931 PacketType is defined as a display string. It consists of a list 932 of dot separated protocol names. Each protocol name has been 933 previously defined using the macro PROTOCOL-IDENTIFIER of the RFC 934 2895. 936 Examples: 937 The RFC2896 defines the protocol identifiers 'ether2', 'ip', 938 'ipip4', 'udp', 'tcp', 'telnet'... 940 The PacketType of the source address corresponding to telnet is 941 the string 'ip.tcp.telnet'. 943 The PacketType of the source address corresponding to UDP packets 944 sent in an IP tunnel is the string 'ip.ipip4.udp'. 946 Note: 947 An IPPM measure is active, so generally a PacketType value does 948 not describe the link layer (i.e. ether2...). Valid Internet 949 packets are sent from Src to Dst. Then the choice of the link 950 layer relies on the Internet stack." 951 SYNTAX OCTET STRING (SIZE (0..512)) 953 PacketTypeAddress ::= TEXTUAL-CONVENTION 954 DISPLAY-HINT "255a" 955 STATUS current 956 DESCRIPTION 957 "This textual convention is a Display string used to describe the 958 parameters of the protocol encapsulation list of a packet, 959 basically the address. 961 PacketTypeAddress is defined as a display string. It consists in 962 a list of blank separated addresses that reflect the 963 encapsulation of the PacketType. Each parameter in the list 964 corresponds to a parameter of a PROTOCOL-IDENTIFIER of the 965 PacketType. 966 Example: 968 The PacketType 'ip.ipip4' has 2 parameters. A valid 969 PacketTypeAddress value is '192.168.1.1 128.2.6.7'." 970 SYNTAX OCTET STRING (SIZE (0..512)) 972 IppmMetricResultFilter ::= TEXTUAL-CONVENTION 973 STATUS current 974 DESCRIPTION 975 " Given that not all results from a metric measurement are 976 pertinent, and that the size of the history must be limited whenever 977 possible, the TC IppmMetricResultFilter defines basic filters to 978 limit the among of data collected: 980 Filter's parameters are the 2 fields ippmAggrMeasureLowThreshold and 981 ippmAggrMeasureLowThreshold of the aggregated measure setup. 983 A filter determines if the result of the current aggregation has to 984 be stored: 986 LogInBandValue: 987 The value is stored if it is lower than the high threshold of 988 the aggregated measure setup and greater than the low 989 threshold of of the aggregated measure setup. 991 LogOutBandValue: 992 The value is stored if it is greater than the high threshold 993 of the aggregated measure setup or lower than the low 994 threshold of the aggregated measure setup. 996 LogAboveValue: 997 The value is stored if it is greater than the high threshold 998 of the aggregated measure setup. 1000 LogBelowValue: 1001 The value is stored if it is lower than the low metric 1002 threshold field of the aggregated measure setup. 1004 logUpAndDownValue: 1005 This filter stores contiguous results that are on opposite 1006 sides of the up and down metric thresholds: 1007 A result is stored if it is the first result aggregated: 1008 If it is greater than the high threshold and lower than the 1009 low threshold then its value is set to the value of the low 1010 threshold; 1012 A result greater than the high threshold is stored if the 1013 previous result is lower than the low threshold; 1015 A result lower than the low threshold is stored if the 1016 previous result is greater than the high threshold; 1018 " 1019 SYNTAX INTEGER { 1020 logInBandValue(1), 1021 logOutBandValue(2), 1022 logAboveValue(3), 1023 logBelowValue(4), 1024 logUpAndDownValue(5) 1025 } 1027 -- 1028 -- IPPM Notifications 1029 -- 1030 ippmNotifications OBJECT IDENTIFIER ::= { ippm 0 } 1032 -- 1033 -- IPPM Conformance 1034 -- 1035 ippmConformance OBJECT IDENTIFIER ::= { ippm 1 } 1037 -- 1038 -- IPPM MIB Object definitions 1039 -- 1041 ippmSystem OBJECT IDENTIFIER ::= { ippmReportingMib 1 } 1042 ippmOwners OBJECT IDENTIFIER ::= { ippmReportingMib 2 } 1043 ippmHistory OBJECT IDENTIFIER ::= { ippmReportingMib 3 } 1044 ippmNetMeasure OBJECT IDENTIFIER ::= { ippmReportingMib 4 } 1045 ippmAggrMeasure OBJECT IDENTIFIER ::= { ippmReportingMib 5 } 1047 -- 1048 -- ippmSystem Group 1049 -- 1050 -- 1052 ippmSystemTime OBJECT-TYPE 1053 SYNTAX GMTTimeStamp 1054 MAX-ACCESS read-only 1055 STATUS current 1056 DESCRIPTION 1057 "The current time of the system running the IPPM REPORTING MIB 1058 SNMP agent. When the agent is running in proxy mode, it is the 1059 current time of the proxy agent. 1060 When the agent is located in the probe, it is the current time of 1061 the probe agent. " 1062 ::= { ippmSystem 1 } 1064 ippmSystemSynchronizationType OBJECT-TYPE 1065 SYNTAX INTEGER { 1066 other(0), 1067 ntp(1), 1068 gps(2), 1069 cdma(3) 1070 } 1071 MAX-ACCESS read-only 1072 STATUS current 1073 DESCRIPTION 1074 "ippmSystemSynchronizationType describes the mechanism 1075 used to synchronize the system running the IPPM REPORTING MIB 1076 SNMP agent. 1078 Other(0) 1079 The synchronization process must be defined 1080 in the ippmSystemSynchonizationDescription. 1082 Ntp(1) 1083 The system is synchronized using the network 1084 time protocol. The NTP synchronization must be described 1085 in the ippmSystemSynchonizationDescription. 1087 Gps(2) 1088 The system is synchronized using the GPS clocks. 1090 Cdma(3) 1091 The system is synchronized using the CDMA clocks." 1092 ::= { ippmSystem 2 } 1094 ippmSystemSynchronizationDesc OBJECT-TYPE 1095 SYNTAX SnmpAdminString 1096 MAX-ACCESS read-only 1097 STATUS current 1098 DESCRIPTION 1099 "The description of the synchronization process of the system 1100 running the IPPM REPORTING MIB SNMP agent." 1101 ::= { ippmSystem 3 } 1103 ippmSystemClockResolution OBJECT-TYPE 1104 SYNTAX Unsigned32 1105 UNITS "Nanoseconds" 1106 MAX-ACCESS read-only 1107 STATUS current 1108 DESCRIPTION 1109 "ippmSystemClockResolution provides the precision of the clock 1110 used for the measures . The unit is the nanosecond. For example, 1111 the clock on an old Unix host might advance only once every 10 1112 msec, and thus have a resolution of 10 msec. So its resolution is 1113 10000000 nanoseconds and the value of ippmSystemClockResolution 1114 is 10000000." 1115 ::= { ippmSystem 4 } 1117 ippmSystemOperationalStatus OBJECT-TYPE 1118 SYNTAX INTEGER { 1119 unknown(0), 1120 up(1), 1121 down(2) 1122 } 1123 MAX-ACCESS read-only 1124 STATUS current 1125 DESCRIPTION 1126 "This object describes the status of the system running the IPPM 1127 REPORTING MIB SNMP agent. It does not describe end point measurement 1128 status. 1129 unknown(0) means the service is unknown. 1130 up(1) means the service is operational and available for general 1131 use. 1132 down(2) means the agent is not available for use. 1133 " 1134 ::= { ippmSystem 5 } 1136 ippmSystemAggregatedMetrics OBJECT-TYPE 1137 SYNTAX IppmStandardMetrics 1138 MAX-ACCESS read-only 1139 STATUS current 1140 DESCRIPTION 1141 " ippmSystemAggregatedMetrics lists the aggregated metrics that 1142 are performed in the SNMP agent instead of in the point of 1143 measure." 1144 ::= { ippmSystem 6 } 1146 ippmSynchronizationTable OBJECT-TYPE 1147 SYNTAX SEQUENCE OF IppmSynchronizationEntry 1148 MAX-ACCESS not-accessible 1149 STATUS current 1150 DESCRIPTION 1151 "This table registers the event related to the synchronization of 1152 the points of measure. Each event is described in an 1153 ippmSynchronizationEntry. 1154 ippmSynchronizationTable is mandatory. 1155 ippmSynchronizationTable content is read only." 1156 ::= { ippmSystem 7 } 1158 ippmSynchronizationEntry OBJECT-TYPE 1159 SYNTAX IppmSynchronizationEntry 1160 MAX-ACCESS not-accessible 1161 STATUS current 1162 DESCRIPTION 1163 "An entry describes a modification of the synchronization 1164 status." 1165 INDEX { ippmPointOfMeasureIndex, ippmSynchronizationIndex } 1166 ::= { ippmSynchronizationTable 1 } 1168 IppmSynchronizationEntry ::= 1169 SEQUENCE { 1170 ippmSynchronizationIndex Unsigned32, 1171 ippmSynchronizationTime GMTTimeStamp, 1172 ippmSynchronizationStratum Unsigned32, 1173 ippmSynchronizationResolution Unsigned32 1174 } 1176 ippmSynchronizationIndex OBJECT-TYPE 1177 SYNTAX Unsigned32 (1 .. 65535) 1178 MAX-ACCESS not-accessible 1179 STATUS current 1180 DESCRIPTION 1181 "An index that identifies the synchronization events in 1182 chronological order. 1183 65535 is an arbitrary size. It is not recommended to keep 1184 permanently a history of 65535 events." 1185 ::= { ippmSynchronizationEntry 1 } 1187 ippmSynchronizationTime OBJECT-TYPE 1188 SYNTAX GMTTimeStamp 1189 MAX-ACCESS read-only 1190 STATUS current 1191 DESCRIPTION 1192 "The time when the synchronization event occurs." 1193 ::= { ippmSynchronizationEntry 2 } 1195 ippmSynchronizationStratum OBJECT-TYPE 1196 SYNTAX Unsigned32 1197 MAX-ACCESS read-only 1198 STATUS current 1199 DESCRIPTION 1200 "The stratum level of the clock computed when the synchronization 1201 event occurs." 1202 ::= { ippmSynchronizationEntry 3 } 1204 ippmSynchronizationResolution OBJECT-TYPE 1205 SYNTAX Unsigned32 1206 UNITS "Nanoseconds" 1207 MAX-ACCESS read-only 1208 STATUS current 1209 DESCRIPTION 1210 "The new time resolution computed after the synchronization event 1211 occurred." 1212 ::= { ippmSynchronizationEntry 4 } 1214 ippmPointOfMeasureTable OBJECT-TYPE 1215 SYNTAX SEQUENCE OF IppmPointOfMeasureEntry 1216 MAX-ACCESS not-accessible 1217 STATUS current 1218 DESCRIPTION 1219 " This table is the list of measurement end points available in 1220 the measurement system. 1222 Proxy mode: 1223 It is the list of the measurement end points of the set of probes 1224 for which the IPPM agent provides an SNMP interface. 1226 IPPM MIB implemented in a probe: 1227 It is the list of the measurement end points of the probe. 1229 The ippmPointOfMeasureTable content is read only. This implies 1230 that the measurement software handles the table internally 1232 ippmPointOfMeasureTable is mandatory." 1233 ::= { ippmSystem 8 } 1235 ippmPointOfMeasureEntry OBJECT-TYPE 1236 SYNTAX IppmPointOfMeasureEntry 1237 MAX-ACCESS not-accessible 1238 STATUS current 1239 DESCRIPTION 1240 " An entry may be the management address of some middleware in 1241 charge of the management of a set of probes. It may the 1242 management address of a probe that contains several line cards. 1244 An entry describes the capability of a point of measure. 1246 ippmPointOfMeasureMetrics lists the metrics handles by the point 1247 of measure." 1248 INDEX { ippmPointOfMeasureIndex } 1249 ::= { ippmPointOfMeasureTable 1 } 1251 IppmPointOfMeasureEntry ::= SEQUENCE { 1252 ippmPointOfMeasureIndex Unsigned32, 1253 ippmPointOfMeasureMgmtAddrType InetAddressType, 1254 ippmPointOfMeasureMgmtAddress InetAddress, 1255 ippmPointOfMeasureTestAddrType InetAddressType, 1256 ippmPointOfMeasureTestAddress InetAddress, 1257 ippmPointOfMeasureMetrics IppmStandardMetrics 1258 } 1260 ippmPointOfMeasureIndex OBJECT-TYPE 1261 SYNTAX Unsigned32 (1 .. 65535) 1262 MAX-ACCESS not-accessible 1263 STATUS current 1264 DESCRIPTION 1265 "A local index that identifies an entry in the point of measure 1266 table." 1268 ::= { ippmPointOfMeasureEntry 1 } 1270 ippmPointOfMeasureMgmtAddrType OBJECT-TYPE 1271 SYNTAX InetAddressType 1272 MAX-ACCESS read-only 1273 STATUS current 1274 DESCRIPTION 1275 "The address type associated with the management address." 1276 ::= { ippmPointOfMeasureEntry 2 } 1278 ippmPointOfMeasureMgmtAddress OBJECT-TYPE 1279 SYNTAX InetAddress (SIZE (1..128)) 1280 MAX-ACCESS read-only 1281 STATUS current 1282 DESCRIPTION 1283 "The management address on the point of measure" 1284 ::= { ippmPointOfMeasureEntry 3 } 1286 ippmPointOfMeasureTestAddrType OBJECT-TYPE 1287 SYNTAX InetAddressType 1288 MAX-ACCESS read-only 1289 STATUS current 1290 DESCRIPTION 1291 "Defines the address type of the measurement interface of the 1292 point of measure." 1293 ::= { ippmPointOfMeasureEntry 4 } 1295 ippmPointOfMeasureTestAddress OBJECT-TYPE 1296 SYNTAX InetAddress 1297 MAX-ACCESS read-only 1298 STATUS current 1299 DESCRIPTION 1300 "Specifies the address of the measurement interface for the point 1301 of measure." 1302 ::= { ippmPointOfMeasureEntry 5} 1304 ippmPointOfMeasureMetrics OBJECT-TYPE 1305 SYNTAX IppmStandardMetrics 1306 MAX-ACCESS read-only 1307 STATUS current 1308 DESCRIPTION 1309 " ippmPointOfMeasureMetrics lists the metrics this point of 1310 measure implements." 1311 ::= { ippmPointOfMeasureEntry 6 } 1313 ippmMetricsTable OBJECT-TYPE 1314 SYNTAX SEQUENCE OF IppmMetricsEntry 1315 MAX-ACCESS not-accessible 1316 STATUS current 1317 DESCRIPTION 1318 "This table is mandatory. It describes the current 1319 implementation. Each IPPM standardized metric must be described 1320 in the table. 1321 ippmMetricsTable content is read only." 1322 ::= { ippmSystem 9 } 1324 ippmMetricsEntry OBJECT-TYPE 1325 SYNTAX IppmMetricsEntry 1326 MAX-ACCESS not-accessible 1327 STATUS current 1328 DESCRIPTION 1329 "An entry describes the static capabilities of a metric 1330 implementation." 1331 INDEX { ippmMetricsIndex } 1332 ::= { ippmMetricsTable 1 } 1334 IppmMetricsEntry ::= 1335 SEQUENCE { 1336 ippmMetricsIndex IppmMetricsRegistryIndex, 1337 ippmMetricsType INTEGER, 1338 ippmMetricsUnit INTEGER, 1339 ippmMetricsDescription SnmpAdminString 1340 } 1342 ippmMetricsIndex OBJECT-TYPE 1343 SYNTAX IppmMetricsRegistryIndex 1344 MAX-ACCESS not-accessible 1345 STATUS current 1346 DESCRIPTION 1347 "ippmMetricsIndex defines an unambiguous index for each 1348 standardized metric. It identifies a metric, and as such its 1349 value is the value of the node of the metric in the IPPM 1350 registry. This value is the same in any implementation of the 1351 IPPM REPORTING MIB. 1353 Example: 1354 In the IPPM-METRICS-REGISTRY, onewayPacketLossAverage is 1355 registered as the node 14 of ippmMetricsRegistry.metrics.rfc. 1356 Consequently the index of the metric onewayPacketLossAverage in 1357 the IppmMetricsTable will always be '14'" 1358 ::= { ippmMetricsEntry 1 } 1360 ippmMetricsType OBJECT-TYPE 1361 SYNTAX INTEGER { 1362 network(0), 1363 aggregated(1) 1364 } 1365 MAX-ACCESS read-only 1366 STATUS current 1367 DESCRIPTION 1368 "Indicates the metric type, whether it is network or aggregated" 1369 ::= { ippmMetricsEntry 2 } 1371 ippmMetricsUnit OBJECT-TYPE 1372 SYNTAX INTEGER { 1373 noUnit(0), 1374 second(1), 1375 millisecond(2), 1376 microsecond(3), 1377 nanosecond(4), 1378 percentage(5), 1379 packet(6), 1380 byte(7), 1381 kilobyte(8), 1382 megabyte(9) 1383 } 1384 MAX-ACCESS read-only 1385 STATUS current 1386 DESCRIPTION 1387 "The unit used in the current entity for the results of the 1388 measurement of this metric." 1389 ::= { ippmMetricsEntry 3 } 1391 ippmMetricsDescription OBJECT-TYPE 1392 SYNTAX SnmpAdminString 1393 MAX-ACCESS read-only 1394 STATUS current 1395 DESCRIPTION 1396 "A textual description of the metric implementation following the 1397 exact name of this metric in the registry. For example: 1398 oneWayDelay: OWD Metric ." 1399 ::= { ippmMetricsEntry 4 } 1401 -- 1402 -- ippmOwners Group 1403 -- 1404 -- The ippmOwners objects are responsible for managing 1405 -- the owners access to the measurements. 1406 -- 1407 -- 1408 ippmOwnersTable OBJECT-TYPE 1409 SYNTAX SEQUENCE OF IppmOwnersEntry 1410 MAX-ACCESS not-accessible 1411 STATUS current 1412 DESCRIPTION 1413 "A management entity wishing to access or aggregate remote Ippm 1414 measurements in an agent must previously be registered in the 1415 ippmOwnersTable. This table is read-create and contains at least the 1416 owner 'monitor'." 1417 ::= { ippmOwners 1 } 1419 ippmOwnersEntry OBJECT-TYPE 1420 SYNTAX IppmOwnersEntry 1421 MAX-ACCESS not-accessible 1422 STATUS current 1423 DESCRIPTION 1424 "The description of the resources granted to an SNMP application. 1426 For example, an instance of ippmOwnersOwner with an 1427 IppmOwnerString 'acme', which represents the 14th owner created 1428 in ippmOwnersTable would be named ippmOwnersEntryOwner.14. 1429 " 1430 INDEX { ippmOwnersOwner } 1431 ::= { ippmOwnersTable 1 } 1433 IppmOwnersEntry ::= SEQUENCE { 1434 ippmOwnersOwner IppmOwnerString, 1435 ippmOwnersGrantedMetrics IppmStandardMetrics, 1436 ippmOwnersQuota Unsigned32, 1437 ippmOwnersIpAddressType InetAddressType, 1438 ippmOwnersIpAddress InetAddress, 1439 ippmOwnersEmail SnmpAdminString, 1440 ippmOwnersStatus RowStatus 1441 } 1443 ippmOwnersOwner OBJECT-TYPE 1444 SYNTAX IppmOwnerString 1445 MAX-ACCESS not-accessible 1446 STATUS current 1447 DESCRIPTION 1448 "The owner described by this entry." 1449 ::= { ippmOwnersEntry 1 } 1451 ippmOwnersGrantedMetrics OBJECT-TYPE 1452 SYNTAX IppmStandardMetrics 1453 MAX-ACCESS read-create 1454 STATUS current 1455 DESCRIPTION 1456 " Defines the metrics granted to an owner for which measurements 1457 can be performed." 1458 ::= { ippmOwnersEntry 2 } 1460 ippmOwnersQuota OBJECT-TYPE 1461 SYNTAX Unsigned32 1462 MAX-ACCESS read-create 1463 STATUS current 1464 DESCRIPTION 1465 " The maximum number of records that this owner may have in the 1466 history table and in the report table." 1467 ::= { ippmOwnersEntry 3 } 1469 ippmOwnersIpAddressType OBJECT-TYPE 1470 SYNTAX InetAddressType 1471 MAX-ACCESS read-create 1472 STATUS current 1473 DESCRIPTION 1474 "The IP address type of the management entity corresponding to 1475 this owner. 1476 InetAddressType is restricted to ipv4(1),ipv6(2)and dns(16). " 1477 ::= { ippmOwnersEntry 4 } 1479 ippmOwnersIpAddress OBJECT-TYPE 1480 SYNTAX InetAddress (SIZE (1..128)) 1481 MAX-ACCESS read-create 1482 STATUS current 1483 DESCRIPTION 1484 "The IP address of the management entity corresponding to this 1485 owner. For example, the IP address of the management console used 1486 to send SNMP requests." 1487 ::= { ippmOwnersEntry 5 } 1489 ippmOwnersEmail OBJECT-TYPE 1490 SYNTAX SnmpAdminString 1491 MAX-ACCESS read-create 1492 STATUS current 1493 DESCRIPTION 1494 "The email address of the management entity corresponding to this 1495 owner." 1496 ::= { ippmOwnersEntry 6 } 1498 ippmOwnersStatus OBJECT-TYPE 1499 SYNTAX RowStatus 1500 MAX-ACCESS read-create 1501 STATUS current 1502 DESCRIPTION 1503 "The status of this table entry. Once this status is set to 1504 active, the corresponding entry in the table may not be 1505 modified." 1506 ::= { ippmOwnersEntry 7 } 1508 -- 1509 -- ippmHistory Group 1510 -- 1511 -- 1512 -- ippmHistoryTable 1513 -- 1515 ippmHistoryTable OBJECT-TYPE 1516 SYNTAX SEQUENCE OF IppmHistoryEntry 1517 MAX-ACCESS not-accessible 1518 STATUS current 1519 DESCRIPTION 1520 "The table containing the measurement results." 1521 ::= { ippmHistory 1 } 1523 ippmHistoryEntry OBJECT-TYPE 1524 SYNTAX IppmHistoryEntry 1525 MAX-ACCESS not-accessible 1526 STATUS current 1527 DESCRIPTION 1528 "An ippmHistoryEntry entry is one of the results of a measure 1529 identified by ippmHistoryMeasureOwner, ippmHistoryMeasureIndex, 1530 ippmHistoryMetricIndex and ippmHistorySequence. 1532 In the index : 1534 + ippmHistoryMeasureOwner identifies the owner of the measure; 1536 + ippmHistoryMeasureIndex identifies the measure in the owner 1537 namespace; 1539 + ippmHistoryMetricIndex identifies the metric measured by the 1540 measure. The metric is described in the corresponding entry of 1541 the ippmMetricsTable; 1543 + ippmHistorySequence is the sequence number of the measurement 1544 result for an entry in the history table." 1545 INDEX { ippmHistoryMeasureOwner, ippmHistoryMeasureIndex, 1546 ippmHistoryMetricIndex, ippmHistorySequence } 1547 ::= { ippmHistoryTable 1 } 1549 IppmHistoryEntry ::= 1550 SEQUENCE { 1551 ippmHistoryMeasureOwner IppmOwnerString, 1552 ippmHistoryMeasureIndex IppmOwnerIndex, 1553 ippmHistoryMetricIndex IppmMetricsRegistryIndex, 1554 ippmHistorySequence Unsigned32, 1555 ippmHistoryTimestamp GMTTimeStamp, 1556 ippmHistoryValue Integer32 1557 } 1559 ippmHistoryMeasureOwner OBJECT-TYPE 1560 SYNTAX IppmOwnerString 1561 MAX-ACCESS not-accessible 1562 STATUS current 1563 DESCRIPTION 1564 "The owner of the measure that produced this result. The measure 1565 is either an ippmNetMeasure or an ippmAggrMeasure." 1566 ::= { ippmHistoryEntry 1 } 1568 ippmHistoryMeasureIndex OBJECT-TYPE 1569 SYNTAX IppmOwnerIndex 1570 MAX-ACCESS not-accessible 1571 STATUS current 1572 DESCRIPTION 1573 "The owner index of the measure that produced this result. The 1574 measure is either an entry of the ippmNetMeasureTable or of the 1575 ippmAggrMeasureTable." 1576 ::= { ippmHistoryEntry 2 } 1578 ippmHistoryMetricIndex OBJECT-TYPE 1579 SYNTAX IppmMetricsRegistryIndex 1580 MAX-ACCESS not-accessible 1581 STATUS current 1582 DESCRIPTION 1583 " ippmHistoryMetricIndex identifies the metric measured by the 1584 measure. The metric is described in the corresponding entry of 1585 the ippmMetricsTable." 1586 ::= { ippmHistoryEntry 3 } 1588 ippmHistorySequence OBJECT-TYPE 1589 SYNTAX Unsigned32 (0..4294967295) 1590 MAX-ACCESS not-accessible 1591 STATUS current 1592 DESCRIPTION 1593 "ippmHistorySequence is the sequence number of the measurement 1594 results for a metric. 1596 Network metrics: 1597 It's the sequence number of a measurement packet. Typically, it 1598 identifies the order of the packet in the stream of packets sent 1599 by the source. 1601 Aggregated metrics: 1602 It is the sequence order of the aggregation computed." 1603 ::= { ippmHistoryEntry 4 } 1605 ippmHistoryTimestamp OBJECT-TYPE 1606 SYNTAX GMTTimeStamp 1607 MAX-ACCESS read-only 1608 STATUS current 1609 DESCRIPTION 1610 "The timestamp when the measurement occurred." 1611 ::= { ippmHistoryEntry 5 } 1613 ippmHistoryValue OBJECT-TYPE 1614 SYNTAX Integer32 1615 MAX-ACCESS read-only 1616 STATUS current 1617 DESCRIPTION 1618 "The observed value of the measurement." 1619 ::= { ippmHistoryEntry 6 } 1621 ippmHistoryPathToResults OBJECT-TYPE 1622 SYNTAX SnmpAdminString 1623 MAX-ACCESS read-only 1624 STATUS current 1625 DESCRIPTION 1626 "It is typically an URL describing the file location where bulk 1627 results are logged." 1628 ::= { ippmHistory 2 } 1630 -- 1631 -- ippmNetMeasure Group 1632 -- 1634 -- 1635 -- ippmNetMeasureTable 1636 -- 1637 -- 1639 ippmNetMeasureTable OBJECT-TYPE 1640 SYNTAX SEQUENCE OF IppmNetMeasureEntry 1641 MAX-ACCESS not-accessible 1642 STATUS current 1643 DESCRIPTION 1644 "An entry is a measurement that performs network measures and 1645 provides results. 1646 It performs several metric measurements per packet exchange. Each 1647 step of a measure produces a singleton result per metric. The 1648 time of the measurement and the value of the metric are saved in 1649 the ippmHistoryTable." 1650 ::= { ippmNetMeasure 1 } 1652 ippmNetMeasureEntry OBJECT-TYPE 1653 SYNTAX IppmNetMeasureEntry 1654 MAX-ACCESS not-accessible 1655 STATUS current 1656 DESCRIPTION 1657 " The IppmNetMeasureTable is mandatory, and its content is read 1658 only. It means that the measurement software handles the table 1659 internally. The setup of the network measure is not permitted 1660 through the IPPM REPORTING MIB. As an example, OWAP provides a 1661 setup protocol to setup and tear down networks measures. 1663 The ippmNetMeasureMetrics is set to a list of metrics to be 1664 computed from the same raw packet exchange. Each step of 1665 measurement delivers a singleton per metric. Results are 1666 timestamped and saved in the ippmHistoryTable. 1668 One may create aggregated measures by using the results of 1669 network measures." 1671 INDEX { ippmNetMeasureOwner, ippmNetMeasureIndex } 1672 ::= { ippmNetMeasureTable 1 } 1674 IppmNetMeasureEntry ::= SEQUENCE { 1675 ippmNetMeasureOwner IppmOwnerString, 1676 ippmNetMeasureIndex IppmOwnerIndex, 1677 ippmNetMeasureName SnmpAdminString, 1678 ippmNetMeasureMetrics IppmStandardMetrics, 1679 ippmNetMeasureBeginTime GMTTimeStamp, 1680 ippmNetMeasureCollectionRateUnit TimeUnit, 1681 ippmNetMeasureCollectionRate Unsigned32, 1682 ippmNetMeasureDurationUnit TimeUnit, 1683 ippmNetMeasureDuration Unsigned32, 1684 ippmNetMeasureHistorySize Unsigned32, 1685 ippmNetMeasureFailureMgmtMode INTEGER, 1686 ippmNetMeasureResultsMgmt INTEGER, 1687 ippmNetMeasureSrcPacketType PacketType, 1688 ippmNetMeasureSrc PacketTypeAddress, 1689 ippmNetMeasureDstPacketType PacketType, 1690 ippmNetMeasureDst PacketTypeAddress, 1691 ippmNetMeasureTxMode INTEGER, 1692 ippmNetMeasureTxPacketRateUnit TimeUnit, 1693 ippmNetMeasureTxPacketRate Unsigned32, 1694 ippmNetMeasureMedOrBurstSize Unsigned32, 1695 ippmNetMeasureDevOrIntBurstSize Unsigned32, 1696 ippmNetMeasureLossTimeout Unsigned32, 1697 ippmNetMeasureL3PacketSize Unsigned32, 1698 ippmNetMeasureDataPattern OCTET STRING, 1699 ippmNetMeasureTotalPktsRecv Counter64, 1700 ippmNetMeasureLastUpdate GMTTimeStamp, 1701 ippmNetMeasureOperState INTEGER 1702 } 1704 ippmNetMeasureOwner OBJECT-TYPE 1705 SYNTAX IppmOwnerString 1706 MAX-ACCESS not-accessible 1707 STATUS current 1708 DESCRIPTION 1709 "The owner of the network measure." 1710 ::= { ippmNetMeasureEntry 1 } 1712 ippmNetMeasureIndex OBJECT-TYPE 1713 SYNTAX IppmOwnerIndex 1714 MAX-ACCESS not-accessible 1715 STATUS current 1716 DESCRIPTION 1717 "The owner index of the network measure." 1718 ::= { ippmNetMeasureEntry 2 } 1720 ippmNetMeasureName OBJECT-TYPE 1721 SYNTAX SnmpAdminString 1722 MAX-ACCESS read-only 1723 STATUS current 1724 DESCRIPTION 1725 "The name of the metric instance(s) as defined in 1726 ippmNetMeasureMetrics. It illustrates the specificity of the 1727 metric(s) and includes the metric(s) and the PacketType. 1729 Example: 1730 IP-TCP-HTTP-One-way-Delay: free text " 1731 ::= { ippmNetMeasureEntry 3 } 1733 ippmNetMeasureMetrics OBJECT-TYPE 1734 SYNTAX IppmStandardMetrics 1735 MAX-ACCESS read-only 1736 STATUS current 1737 DESCRIPTION 1738 "ippmNetMeasureMetrics defines the metrics to compute within this 1739 measure. Only network metrics of the same type are allowed in 1740 this field (e.g. poisson-based metrics and periodic-based metrics 1741 are incompatibles, while one-way delay and packet loss are 1742 generally processed simultaneously: a very bad delay is 1743 potentially a very good packet loss). 1745 Results are saved in the ippmHistoryTable. Results of a metric 1746 are identified using an index of type IppmMetricsRegistryIndex. 1748 Example: 1749 Given a multi-metrics measure of One-way-Delay(6) and One-way- 1750 Packet-Loss(12). The value of the field ippmNetMeasureMetrics is 1751 '0001000001000000'b, '1040'B. Results are logged in the 1752 ippmHistoryTable where One-way-Delay singletons have a value of 1753 ippmMetricsIndex of 6 while One-way-Packet-Loss singletons have a 1754 value of ippmMetricsIndex of 12. 1756 " 1757 ::= { ippmNetMeasureEntry 4 } 1759 ippmNetMeasureBeginTime OBJECT-TYPE 1760 SYNTAX GMTTimeStamp 1761 MAX-ACCESS read-only 1762 STATUS current 1763 DESCRIPTION 1764 "Specifies the time at which the measurement begins." 1765 ::= { ippmNetMeasureEntry 5 } 1767 ippmNetMeasureCollectionRateUnit OBJECT-TYPE 1768 SYNTAX TimeUnit 1769 MAX-ACCESS read-only 1770 STATUS current 1771 DESCRIPTION 1772 "Specifies the unit of the measurement period." 1773 ::= { ippmNetMeasureEntry 6 } 1775 ippmNetMeasureCollectionRate OBJECT-TYPE 1776 SYNTAX Unsigned32 1777 MAX-ACCESS read-only 1778 STATUS current 1779 DESCRIPTION 1780 "Gives the period used to collect singletons from the point of 1781 measures. This value is used as the cycle period in the report." 1782 ::= { ippmNetMeasureEntry 7 } 1784 ippmNetMeasureDurationUnit OBJECT-TYPE 1785 SYNTAX TimeUnit 1786 MAX-ACCESS read-only 1787 STATUS current 1788 DESCRIPTION 1789 "Specifies the measurement duration unit." 1790 ::= { ippmNetMeasureEntry 8 } 1792 ippmNetMeasureDuration OBJECT-TYPE 1793 SYNTAX Unsigned32 1794 MAX-ACCESS read-only 1795 STATUS current 1796 DESCRIPTION 1797 "Specifies the measurement duration." 1798 ::= { ippmNetMeasureEntry 9 } 1800 ippmNetMeasureHistorySize OBJECT-TYPE 1801 SYNTAX Unsigned32 1802 MAX-ACCESS read-only 1803 STATUS current 1804 DESCRIPTION 1805 "Specifies the maximum number of results saved for each metric of 1806 this measure. 1807 Overflow condition will be managed by the object 1808 ippmNetMeasureResultsMgmt. " 1810 ::= { ippmNetMeasureEntry 10 } 1812 ippmNetMeasureFailureMgmtMode OBJECT-TYPE 1813 SYNTAX INTEGER { 1814 auto(1), 1815 manual(2), 1816 discarded(3) 1817 } 1818 MAX-ACCESS read-only 1819 STATUS current 1820 DESCRIPTION 1821 "This object defines whether this row (and the measure controlled 1822 by this row) is restarted automatically, manually, or discarded 1823 upon failure, or reboot of the measurement system. 1824 'auto' 1825 The measure is restarted automatically. 1826 'manual' 1827 The measure has to be restarted manually. 1828 'discarded' 1829 The measure and it results are discarded. 1830 " 1831 ::= { ippmNetMeasureEntry 11 } 1833 ippmNetMeasureResultsMgmt OBJECT-TYPE 1834 SYNTAX INTEGER { 1835 wrap(1), 1836 suspend(2) 1837 } 1838 MAX-ACCESS read-only 1839 STATUS current 1840 DESCRIPTION 1841 " 1842 Action to take when the log is full. The measurement system owner 1843 may choose to either wrap, in which case the agent writes over 1844 existing records. The user may choose to suspend writing to the 1845 log in the event that he wishes to archive the data. The resume 1846 action causes the agent to begin to write in the log, and assumes 1847 the data has been cleared. 1848 This object indicates the way the measurement results are managed 1849 when the owner quota has been exceeded: 1850 'wrap' 1851 continue the measurement and erase the older entries in the 1852 history. 1853 'suspend' 1854 stop the measure and keep the results in the history. 1855 " 1856 ::= { ippmNetMeasureEntry 12 } 1858 ippmNetMeasureSrcPacketType OBJECT-TYPE 1859 SYNTAX PacketType 1860 MAX-ACCESS read-only 1861 STATUS current 1862 DESCRIPTION 1863 "Defines the type P of the source address of the packets sent by 1864 the measure." 1865 ::= { ippmNetMeasureEntry 13 } 1867 ippmNetMeasureSrc OBJECT-TYPE 1868 SYNTAX PacketTypeAddress 1869 MAX-ACCESS read-only 1870 STATUS current 1871 DESCRIPTION 1872 "Specifies the address of the source of the measure. 1873 It is represented as a list of parameters corresponding to those 1874 of the PROTOCOL IDENTIFIER set in ippmNetMeasureSrcPacketType." 1875 ::= { ippmNetMeasureEntry 14} 1877 ippmNetMeasureDstPacketType OBJECT-TYPE 1878 SYNTAX PacketType 1879 MAX-ACCESS read-only 1880 STATUS current 1881 DESCRIPTION 1882 "Defines the type P of the destination address of the packets 1883 sent by the measure." 1884 ::= { ippmNetMeasureEntry 15 } 1886 ippmNetMeasureDst OBJECT-TYPE 1887 SYNTAX PacketTypeAddress 1888 MAX-ACCESS read-only 1889 STATUS current 1890 DESCRIPTION 1891 "Specifies the address of the destination of the measure. 1892 It is represented as a list of parameters corresponding to those 1893 of the PROTOCOL IDENTIFIER set in ippmNetMeasureDstPacketType." 1894 ::= { ippmNetMeasureEntry 16 } 1896 ippmNetMeasureTxMode OBJECT-TYPE 1897 SYNTAX INTEGER { 1898 other(0), 1899 periodic(1), 1900 poisson(2), 1901 multiburst(3) 1902 } 1903 MAX-ACCESS read-only 1904 STATUS current 1905 DESCRIPTION 1906 "The transmit mode used to send the packets: 1907 'other' 1908 The rule used to send the packets is unknown. 1909 'periodic' 1910 Packets are sent periodically at ippmNetMeasureTxPacketRate 1911 rate. 1912 'poisson' 1913 Packets are sent using a Poisson law, the median is the value 1914 of ippmNetMeasureDevOrIntBurstSize, the deviation is 1915 ippmNetMeasureMedOrBurstSize. 1916 'multiburst' 1917 Packets are sent bursty at ippmNetMeasureTxPacketRate. The 1918 size of the burst is made of ippmNetMeasureMedOrBurstSize 1919 packets. 1920 Between 2 consecutive bursts, transmission stops during the time 1921 needed to send ippmNetMeasureDevOrIntBurstSize. 1923 " 1924 ::= { ippmNetMeasureEntry 17 } 1926 ippmNetMeasureTxPacketRateUnit OBJECT-TYPE 1927 SYNTAX TimeUnit 1928 MAX-ACCESS read-only 1929 STATUS current 1930 DESCRIPTION 1931 "The packet rate unit used to send the packets." 1932 ::= { ippmNetMeasureEntry 18 } 1934 ippmNetMeasureTxPacketRate OBJECT-TYPE 1935 SYNTAX Unsigned32 1936 UNITS "Packets" 1937 MAX-ACCESS read-only 1938 STATUS current 1939 DESCRIPTION 1940 "The rate the packets are sent." 1941 ::= { ippmNetMeasureEntry 19 } 1943 ippmNetMeasureMedOrBurstSize OBJECT-TYPE 1944 SYNTAX Unsigned32 1945 UNITS "Packets" 1946 MAX-ACCESS read-only 1947 STATUS current 1948 DESCRIPTION 1949 " 1950 Multi-burst mode: This field represents the burst size in number 1951 of packets. 1952 Poisson mode: This field indicates the number of packets sent, on 1953 average, during each period corresponding to the median. 1954 The median is therefore 1955 MedOrBurstSize*TxPacketRateUnit/TxPacketRate. 1957 Example: 1958 If TxPacketRateUnit/TxPacketRate is 100 packets/second, and if 1959 MedOrBurstSize, the number of packets sent during the period 1960 corresponding to the median is 50 packets, then the median equals 1961 50*1/100 = 1/2 seconds. 1962 " 1963 ::= { ippmNetMeasureEntry 20 } 1965 ippmNetMeasureDevOrIntBurstSize OBJECT-TYPE 1966 SYNTAX Unsigned32 1967 UNITS "Packets" 1968 MAX-ACCESS read-only 1969 STATUS current 1970 DESCRIPTION 1971 " 1972 Multi-burst mode: This field indicates the gap between 2 bursts, 1973 in number of packets. 1974 Example: 1975 If TxPacketRateUnit/TxPacketRate is 100 packets/second, 1976 and DevOrIntBurstSize equals 50 packets, then the gap between 2 1977 bursts is 1978 equal to 50*1/100, or 1/2 second. 1980 Poisson mode: 1981 This field indicates the typical difference between the packets 1982 of the period corresponding to the median. 1984 " 1985 ::= { ippmNetMeasureEntry 21 } 1987 ippmNetMeasureLossTimeout OBJECT-TYPE 1988 SYNTAX Unsigned32 1989 UNITS "Milliseconds" 1990 MAX-ACCESS read-only 1991 STATUS current 1992 DESCRIPTION 1993 "Specifies the delay after which the packet is considered lost 1994 by the sink." 1995 ::= { ippmNetMeasureEntry 22 } 1997 ippmNetMeasureL3PacketSize OBJECT-TYPE 1998 SYNTAX Unsigned32 1999 UNITS "Bytes" 2000 MAX-ACCESS read-only 2001 STATUS current 2002 DESCRIPTION 2003 "Specifies the size of the packets counted at the IP network 2004 layer in regards to the PacketType definition. 2005 Example: For a PacketType 'ip ipip4' the L3 size will be the size 2006 of the packet at ipip4 level. 2007 " 2008 ::= { ippmNetMeasureEntry 23 } 2010 ippmNetMeasureDataPattern OBJECT-TYPE 2011 SYNTAX OCTET STRING 2012 MAX-ACCESS read-only 2013 STATUS current 2014 DESCRIPTION 2015 "The pattern used to fill the payload of the packet." 2017 ::= { ippmNetMeasureEntry 24 } 2019 ippmNetMeasureTotalPktsRecv OBJECT-TYPE 2020 SYNTAX Counter64 2021 UNITS "Packets" 2022 MAX-ACCESS read-only 2023 STATUS current 2024 DESCRIPTION 2025 "Reports the current number of packets received since the 2026 beginning of the measure. 2027 This parameters is useful to monitor the measure and it is needed 2028 to compute statistics." 2029 ::= { ippmNetMeasureEntry 25 } 2031 ippmNetMeasureLastUpdate OBJECT-TYPE 2032 SYNTAX GMTTimeStamp 2033 MAX-ACCESS read-only 2034 STATUS current 2035 DESCRIPTION 2036 "The time when the last aggregation was computed." 2037 ::= { ippmNetMeasureEntry 26 } 2039 ippmNetMeasureOperState OBJECT-TYPE 2040 SYNTAX INTEGER { 2041 unknown(0), 2042 running(1), 2043 stopped(2) 2044 } 2045 MAX-ACCESS read-only 2046 STATUS current 2047 DESCRIPTION 2048 "Reports the operational status of the network measure." 2049 ::= { ippmNetMeasureEntry 27 } 2051 -- 2052 -- 2053 -- ippmAggrMeasure Group 2054 -- 2055 -- 2057 -- 2058 -- 2059 -- ippmAggrMeasureTable 2060 -- 2061 -- 2063 ippmAggrMeasureTable OBJECT-TYPE 2064 SYNTAX SEQUENCE OF IppmAggrMeasureEntry 2065 MAX-ACCESS not-accessible 2066 STATUS current 2067 DESCRIPTION 2068 "An aggregated measure summarizes the results of previous network 2069 or aggregated measures. The results are saved in the 2070 ippmHistoryTable. 2071 Each step of the calculation for the measure produces a singleton 2072 result per metric." 2073 ::= { ippmAggrMeasure 1 } 2075 ippmAggrMeasureEntry OBJECT-TYPE 2076 SYNTAX IppmAggrMeasureEntry 2077 MAX-ACCESS not-accessible 2078 STATUS current 2079 DESCRIPTION 2080 "Typically, the configuration operation creates and sets the 2081 value of the fields of a new ippmAggrMeasureEntry. 2082 ippmAggrMeasureOwner and ippmAggrMeasureIndex identify the 2083 instance created. 2084 The field ippmAggrMeasureMetrics identifies the metric to 2085 compute. As such its ippmMetricsType should be 'aggregated'. 2087 The measure aggregates the results of a measure identified by 2088 ippmAggrMeasureHistoryOwner, ippmAggrMeasureHistoryIndex and 2089 ippmAggrMeasureHistoryMetric. The measure to aggregate belongs to 2090 ippmNetMeasureTable or ippmAggrMeasureTable. 2092 The aggregation starts at ippmAggrMeasureBeginTime and ends after 2093 ippmAggrMeasureDuration. 2095 An aggregated result is computed for each 2096 ippmMeasureCollectionRate tick and saved in the 2097 ippmHistoryTable." 2098 INDEX { ippmAggrMeasureOwner, ippmAggrMeasureIndex } 2099 ::= { ippmAggrMeasureTable 1 } 2101 IppmAggrMeasureEntry ::= SEQUENCE { 2102 ippmAggrMeasureOwner IppmOwnerString, 2103 ippmAggrMeasureIndex IppmOwnerIndex, 2104 ippmAggrMeasureName SnmpAdminString, 2105 ippmAggrMeasureMetrics IppmStandardMetrics, 2106 ippmAggrMeasureHistoryOwner IppmOwnerString, 2107 ippmAggrMeasureHistoryIndex IppmOwnerIndex, 2108 ippmAggrMeasureHistoryMetric IppmMetricsRegistryIndex, 2109 ippmAggrMeasureFilter IppmMetricResultFilter, 2110 ippmAggrMeasureLowThreshold Unsigned32, 2111 ippmAggrMeasureHighThreshold Unsigned32, 2112 ippmAggrMeasureBeginTime GMTTimeStamp, 2113 ippmAggrMeasureAggrPeriodUnit TimeUnit, 2114 ippmAggrMeasureAggrPeriod Unsigned32, 2115 ippmAggrMeasureDurationUnit TimeUnit, 2116 ippmAggrMeasureDuration Unsigned32, 2117 ippmAggrMeasureHistorySize Unsigned32, 2118 ippmAggrMeasureStorageType StorageType, 2119 ippmAggrMeasureAdminState INTEGER, 2120 ippmAggrMeasureFastReport OBJECT IDENTIFIER, 2121 ippmAggrMeasureResultsMgmt INTEGER, 2122 ippmAggrMeasureLastUpdate GMTTimeStamp, 2123 ippmAggrMeasureOperState INTEGER, 2124 ippmAggrMeasureNbPktsTreated Counter64, 2125 ippmAggrMeasureStatus RowStatus 2126 } 2128 ippmAggrMeasureOwner OBJECT-TYPE 2129 SYNTAX IppmOwnerString 2130 MAX-ACCESS not-accessible 2131 STATUS current 2132 DESCRIPTION 2133 "The owner who has configured this entry." 2134 ::= { ippmAggrMeasureEntry 1 } 2136 ippmAggrMeasureIndex OBJECT-TYPE 2137 SYNTAX IppmOwnerIndex 2138 MAX-ACCESS not-accessible 2139 STATUS current 2140 DESCRIPTION 2141 "The index of the aggregated measure. The value is managed by the 2142 owner." 2143 ::= { ippmAggrMeasureEntry 2 } 2145 ippmAggrMeasureName OBJECT-TYPE 2146 SYNTAX SnmpAdminString 2147 MAX-ACCESS read-create 2148 STATUS current 2149 DESCRIPTION 2150 "The name of the instance of the metric. It illustrates the 2151 specificity of the metric and includes the metric and the typeP. 2153 example: IP-port-HTTP-connectivity: free text." 2154 ::= { ippmAggrMeasureEntry 3 } 2156 ippmAggrMeasureMetrics OBJECT-TYPE 2157 SYNTAX IppmStandardMetrics 2158 MAX-ACCESS read-create 2159 STATUS current 2160 DESCRIPTION 2161 "ippmAggrMeasureMetrics defines the metrics to compute within 2162 this aggregated measure. 2164 Only aggregated metrics of the same type are allowed in this 2165 field (e.g. Measurement of minimum, average and maximum metrics 2166 are generally processed simultaneously on the same network 2167 measure). 2169 Results are saved in the ippmHistoryTable. Results of a metric 2170 are identified using an index of type IppmMetricsRegistryIndex. 2172 Example: 2173 Given a multi-aggregation of One-way-Delay-Median(9) and One-way- 2174 Delay-Minimum(10). The value of the field ippmAggrMeasureMetrics 2175 is '0000011000000000'b, '0600'B. Results are logged in the 2176 ippmHistoryTable where One-way-Delay-Median singletons have a 2177 value of ippmMetricsIndex of 9 while One-way-Delay-Minimum 2178 singletons have a value of ippmMetricsIndex of 10. 2180 NOTE WELL: It is not recommended to use the multi aggregation 2181 capability in conjunction with the filter feature. 2182 " 2183 ::= { ippmAggrMeasureEntry 4 } 2185 ippmAggrMeasureHistoryOwner OBJECT-TYPE 2186 SYNTAX IppmOwnerString 2187 MAX-ACCESS read-create 2188 STATUS current 2189 DESCRIPTION 2190 "The owner of the measure to summarize. " 2191 ::= { ippmAggrMeasureEntry 5 } 2193 ippmAggrMeasureHistoryIndex OBJECT-TYPE 2194 SYNTAX IppmOwnerIndex 2195 MAX-ACCESS read-create 2196 STATUS current 2197 DESCRIPTION 2198 "The owner index of the measure to summarize. " 2199 ::= { ippmAggrMeasureEntry 6 } 2201 ippmAggrMeasureHistoryMetric OBJECT-TYPE 2202 SYNTAX IppmMetricsRegistryIndex 2203 MAX-ACCESS read-create 2204 STATUS current 2205 DESCRIPTION 2206 "The metric of the measure to summarize. " 2207 ::= { ippmAggrMeasureEntry 7 } 2209 ippmAggrMeasureFilter OBJECT-TYPE 2210 SYNTAX IppmMetricResultFilter 2211 MAX-ACCESS read-create 2212 STATUS current 2213 DESCRIPTION 2214 " 2215 ippmAggrMeasureFilter defines the kind of filter to apply on a 2216 result to determine if the result is stored or not. The 2217 parameters of the filter are ippmAggrMeasureLowThreshold and 2218 ippmAggrMeasureHighThreshold. 2220 Thresholds have the same unit as the metric value. 2222 In the following examples we consider an aggregated measure. Its 2223 low threshold is set to 80.its high threshold is set to 100. The 2224 aggregation produced a flow of 12 aggregated results {40 30 60 85 2225 140 130 190 95 50 90 30 20}. 2227 If the filter is set to 'logInBandValue' then the results 85, 95, 2228 90 will be stored. 2230 If the filter is set to 'logOutBandValue' then the results 40 30 2231 60 140 130 190 50 30 20 will be stored. 2233 If the filter is set to 'logAboveValue' then the results 140 130 2234 190 will be stored. 2236 If the filter is set to 'logBelowValue' then the results 40 30 60 2237 50 30 20 will be stored. 2239 If the filter is set to 'logUpAndDownValue' then the results 40, 2240 140, 50 will be stored." 2241 ::= { ippmAggrMeasureEntry 8 } 2243 ippmAggrMeasureLowThreshold OBJECT-TYPE 2244 SYNTAX Unsigned32 2245 MAX-ACCESS read-create 2246 STATUS current 2247 DESCRIPTION 2248 "An event is generated when the result of the measure of the 2249 metric is lower that the value of ippmAggrMeasureLowThreshold. 2250 The threshold has the same unit as the metric. The metric unit is 2251 recorded in the object ippmMetricsUnit of this metric entry in 2252 the ippmMetricsTable. 2253 " 2254 ::= { ippmAggrMeasureEntry 9 } 2256 ippmAggrMeasureHighThreshold OBJECT-TYPE 2257 SYNTAX Unsigned32 2258 MAX-ACCESS read-create 2259 STATUS current 2260 DESCRIPTION 2261 "An event is generated when the result of the measure of the 2262 metric exceeds the value of ippmAggrMeasureHighThreshold. 2263 The threshold has the same unit as the metric. The metric unit is 2264 recorded in the object ippmMetricsUnit of this metric entry in 2265 the ippmMetricsTable. 2266 " 2267 ::= { ippmAggrMeasureEntry 10 } 2269 ippmAggrMeasureBeginTime OBJECT-TYPE 2270 SYNTAX GMTTimeStamp 2271 MAX-ACCESS read-create 2272 STATUS current 2273 DESCRIPTION 2274 "Specifies the time at which the aggregated measure starts." 2275 ::= { ippmAggrMeasureEntry 11 } 2277 ippmAggrMeasureAggrPeriodUnit OBJECT-TYPE 2278 SYNTAX TimeUnit 2279 MAX-ACCESS read-create 2280 STATUS current 2281 DESCRIPTION 2282 "Specifies the unit of the aggregated measure period." 2283 DEFVAL { second } 2284 ::= { ippmAggrMeasureEntry 12 } 2286 ippmAggrMeasureAggrPeriod OBJECT-TYPE 2287 SYNTAX Unsigned32 2288 MAX-ACCESS read-create 2289 STATUS current 2290 DESCRIPTION 2291 "Specifies the amount of time between 2 measurement action 2292 intervals. The action is specific to the semantic of the measure. 2294 Network metrics: 2296 The ippmNetMeasureClockPattern transforms the flow of periodical 2297 instants as a flow of unpredictable instants of measurement 2298 packet emission. 2300 As the source and the sink share the definition of the clock of 2301 the measure, and as the sending timestamp is part of the 2302 measurement packet, the sink has the information to verify that 2303 the stream of packets generated by the source respects the clock 2304 law. 2306 Aggregated metrics: 2308 They are performed periodically on a sequence of results of other 2309 measures. The period corresponds to the interval between two 2310 successive computations of the metric. The value of 2311 ippmHistoryTimestamp result of a aggregated metric computed 2312 corresponds to the value of the ippmHistoryTimestamp of the last 2313 metric result of the sequence used to compute the aggregated 2314 metric." 2315 DEFVAL { 60 } 2317 ::= { ippmAggrMeasureEntry 13 } 2319 ippmAggrMeasureDurationUnit OBJECT-TYPE 2320 SYNTAX TimeUnit 2321 MAX-ACCESS read-create 2322 STATUS current 2323 DESCRIPTION 2324 "Specifies the unit of the measure duration." 2325 DEFVAL { second } 2326 ::= { ippmAggrMeasureEntry 14 } 2328 ippmAggrMeasureDuration OBJECT-TYPE 2329 SYNTAX Unsigned32 2330 MAX-ACCESS read-create 2331 STATUS current 2332 DESCRIPTION 2333 "Specifies the duration of the measure." 2334 DEFVAL { 120 } 2335 ::= { ippmAggrMeasureEntry 15 } 2337 ippmAggrMeasureHistorySize OBJECT-TYPE 2338 SYNTAX Unsigned32 2339 MAX-ACCESS read-create 2340 STATUS current 2341 DESCRIPTION 2342 "Specifies the maximum number of results saved for each metric of 2343 this measure. Overflow condition will be managed by the object 2344 ippmAggrMeasureResultsMgmt. " 2345 DEFVAL { 2 } 2346 ::= { ippmAggrMeasureEntry 16 } 2348 ippmAggrMeasureStorageType OBJECT-TYPE 2349 SYNTAX StorageType 2350 MAX-ACCESS read-create 2351 STATUS current 2352 DESCRIPTION 2353 "This object defines whether this row and the measure controlled 2354 by this row are kept in volatile storage and lost upon reboot or 2355 if this row is backed up 2356 by non-volatile or permanent storage. 2358 Possible values are: other(1), volatile(2), nonVolatile(3), 2359 permanent(4), readOnly(5)." 2360 DEFVAL { nonVolatile } 2361 ::= { ippmAggrMeasureEntry 17 } 2363 ippmAggrMeasureResultsMgmt OBJECT-TYPE 2364 SYNTAX INTEGER { 2365 wrap(1), 2366 suspend(2) 2367 } 2368 MAX-ACCESS read-only 2369 STATUS current 2370 DESCRIPTION 2371 "This object displays the way the history of the aggregated 2372 measure is managed. 2373 'wrap' 2374 continue the measure and erase the older entries in the 2375 history. 2376 'suspend' 2377 stop the measure and keep the results in the history. 2378 " 2379 DEFVAL { wrap } 2380 ::= { ippmAggrMeasureEntry 18 } 2382 ippmAggrMeasureAdminState OBJECT-TYPE 2383 SYNTAX INTEGER { 2384 start(0), 2385 stop(1) 2386 } 2387 MAX-ACCESS read-create 2388 STATUS current 2389 DESCRIPTION 2390 "This object controls the activity of the aggregated measure. 2391 'start' 2392 The aggregated measure is started. 2393 'stop' 2394 The aggregated measure is stopped." 2395 DEFVAL { start } 2397 ::= { ippmAggrMeasureEntry 19 } 2399 ippmAggrMeasureFastReport OBJECT-TYPE 2400 SYNTAX OBJECT IDENTIFIER 2401 MAX-ACCESS read-create 2402 STATUS current 2403 DESCRIPTION 2404 "A fast report is required in order to verify quickly that a 2405 measure is running well. 2407 The feature 'fast report' is active if ippmAggrMeasureFastReport 2408 is not null and points to a notification. 2409 A fast report consists of sending by email to the owner of the 2410 measure, a table of the results of all the metrics computed by 2411 this aggregated measure. The owner email address is read from the 2412 ippmOwnersTable. 2414 ippmAggrMeasureFastReport identifies the notification which 2415 defines the header of the report. 2417 The results part of the report is made of a column of results per 2418 metrics. Results are separated using commas. 2420 To avoid disaster, an aggregated measure using a fast report must 2421 have a cycle of aggregation greater than or equal to 1 second and 2422 should not sent more than an email every 5 minutes and should not 2423 sent more than 12 emails." 2424 DEFVAL { zeroDotZero } 2425 ::= { ippmAggrMeasureEntry 20 } 2427 ippmAggrMeasureLastUpdate OBJECT-TYPE 2428 SYNTAX GMTTimeStamp 2429 MAX-ACCESS read-only 2430 STATUS current 2431 DESCRIPTION 2432 "The time when the last aggregated measure was computed." 2433 ::= { ippmAggrMeasureEntry 21 } 2435 ippmAggrMeasureOperState OBJECT-TYPE 2436 SYNTAX INTEGER { 2437 unknown(0), 2438 running(1), 2439 stopped(2) 2440 } 2441 MAX-ACCESS read-only 2442 STATUS current 2443 DESCRIPTION 2444 "Reports the operational status of the aggregated measure." 2445 ::= { ippmAggrMeasureEntry 22 } 2447 ippmAggrMeasureNbPktsTreated OBJECT-TYPE 2448 SYNTAX Counter64 2449 UNITS "Packets" 2450 MAX-ACCESS read-only 2451 STATUS current 2452 DESCRIPTION 2453 "Reports the current number of packets used to calculate the 2454 aggregation since the start of the measure. 2456 This parameters is useful to monitor the measure and it is needed 2457 to compute statistics." 2458 ::= { ippmAggrMeasureEntry 23 } 2460 ippmAggrMeasureStatus OBJECT-TYPE 2461 SYNTAX RowStatus 2462 MAX-ACCESS read-create 2463 STATUS current 2464 DESCRIPTION 2465 "The status of this entry. Once the entry status is set to 2466 active, the associate entry cannot be modified. 2467 " 2468 ::= { ippmAggrMeasureEntry 24 } 2470 -- 2471 -- IPPM Notifications 2472 -- 2474 ippmAggrMeasureReport NOTIFICATION-TYPE 2475 OBJECTS { 2476 ippmAggrMeasureFilter, 2477 ippmAggrMeasureLowThreshold, 2478 ippmAggrMeasureHighThreshold, 2479 ippmMetricsType, 2480 ippmMetricsUnit, 2481 ippmMetricsDescription, 2482 ippmHistoryTimestamp, 2483 ippmHistoryValue, 2484 ippmHistoryPathToResults 2485 } 2486 STATUS current 2487 DESCRIPTION 2488 "A notification sent because the value of the measure is under 2489 the high threshold value and greater than the low threshold 2490 value. 2491 The notification contains the instances of the ippmHistoryValue 2492 object that exceeded the threshold. 2493 The notification contains the instances of the 2494 ippmHistoryTimestamp identifying the time the event occurred. 2495 ippmHistoryPathToResults is a link to the file name, which 2496 contains detailed results corresponding to this event." 2497 ::= { ippmNotifications 1 } 2499 ippmAggrMeasureHistoryFull NOTIFICATION-TYPE 2500 OBJECTS { 2501 ippmAggrMeasureName, 2502 ippmAggrMeasureHistorySize, 2503 ippmMetricsType, 2504 ippmMetricsUnit, 2505 ippmMetricsDescription, 2506 ippmHistoryTimestamp, 2507 ippmHistoryValue 2509 } 2510 STATUS current 2511 DESCRIPTION 2512 "A notification sent when the size of the history of a metric of 2513 a aggregated measure exceeds ippmAggrMeasureHistorySize. The 2514 agent will then manage the reports according to the policy 2515 described in ippmAggrMeasureResultsMgmt." 2516 ::= { ippmNotifications 2 } 2518 ippmNetMeasureHistoryFull NOTIFICATION-TYPE 2519 OBJECTS { 2520 ippmNetMeasureName, 2521 ippmNetMeasureHistorySize, 2522 ippmMetricsType, 2523 ippmMetricsUnit, 2524 ippmMetricsDescription, 2525 ippmHistoryTimestamp, 2526 ippmHistoryValue 2527 } 2528 STATUS current 2529 DESCRIPTION 2530 "A notification sent when the size of the history of a metric of 2531 a network measure exceeded ippmNetMeasureHistorySize. Then the 2532 agent manages the records according to the policy described in 2533 ippmNetMeasureResultsMgmt." 2534 ::= { ippmNotifications 3 } 2536 -- 2537 -- IPPM MIB Conformance statements 2538 -- 2540 ippmCompliances OBJECT IDENTIFIER ::={ ippmConformance 1 } 2542 ippmGroups OBJECT IDENTIFIER ::={ ippmConformance 2 } 2544 ippmProxyInterDomainCompliances MODULE-COMPLIANCE 2545 STATUS current 2546 DESCRIPTION 2547 "The compliance statement for SNMP entities which implement the 2548 IPPM MIB as a proxy in interdomain. The implementation of the 2549 VACM control is mandatory." 2550 MODULE -- this module 2551 MANDATORY-GROUPS { 2552 ippmSystemGroup, ippmHistoryGroup, ippmNetMeasureGroup, 2553 ippmAggrMeasureGroup, ippmNotificationGroup 2554 } 2555 ::= { ippmCompliances 1 } 2557 ippmProxyCompliances MODULE-COMPLIANCE 2558 STATUS current 2559 DESCRIPTION 2560 "The compliance statement for SNMP entities which implement the 2561 IPPM MIB as a proxy." 2562 MODULE -- this module 2563 MANDATORY-GROUPS { 2564 ippmSystemGroup, ippmOwnersGroup, ippmHistoryGroup, 2565 ippmNetMeasureGroup, ippmAggrMeasureGroup, ippmNotificationGroup 2566 } 2567 GROUP ippmOwnersGroup 2568 DESCRIPTION 2569 "The ippmOwnersGroup is needed if VACM is not implemented." 2570 ::= { ippmCompliances 2 } 2572 ippmEmbeddedCompliances MODULE-COMPLIANCE 2573 STATUS current 2574 DESCRIPTION 2575 "The compliance statement for SNMP entities which implement the 2576 IPPM MIB in a probe." 2577 MODULE -- this module 2578 MANDATORY-GROUPS { 2579 ippmSystemGroup, ippmHistoryGroup, ippmNetMeasureGroup 2580 } 2581 ::= { ippmCompliances 3 } 2583 ippmSystemGroup OBJECT-GROUP 2584 OBJECTS { 2585 ippmSystemSynchronizationDesc, 2586 ippmSystemTime, 2587 ippmSystemSynchronizationType, 2588 ippmSystemClockResolution, 2589 ippmSynchronizationTime, 2590 ippmSynchronizationStratum, 2591 ippmSynchronizationResolution, 2592 ippmPointOfMeasureMgmtAddrType, 2593 ippmPointOfMeasureMgmtAddress, 2594 ippmPointOfMeasureTestAddrType, 2595 ippmPointOfMeasureTestAddress, 2596 ippmSystemOperationalStatus, 2597 ippmSystemAggregatedMetrics, 2598 ippmPointOfMeasureMetrics, 2599 ippmMetricsType, 2600 ippmMetricsUnit, 2601 ippmMetricsDescription 2602 } 2603 STATUS current 2604 DESCRIPTION 2605 "The IPPM System Group" 2606 ::= { ippmGroups 1} 2608 ippmNetMeasureGroup OBJECT-GROUP 2609 OBJECTS { 2610 ippmNetMeasureName, 2611 ippmNetMeasureMetrics, 2612 ippmNetMeasureBeginTime, 2613 ippmNetMeasureCollectionRateUnit, 2614 ippmNetMeasureCollectionRate, 2615 ippmNetMeasureDurationUnit, 2616 ippmNetMeasureDuration, 2617 ippmNetMeasureHistorySize, 2618 ippmNetMeasureFailureMgmtMode, 2619 ippmNetMeasureResultsMgmt, 2620 ippmNetMeasureSrcPacketType, 2621 ippmNetMeasureSrc, 2622 ippmNetMeasureDstPacketType, 2623 ippmNetMeasureDst, 2624 ippmNetMeasureTxMode, 2625 ippmNetMeasureTxPacketRateUnit, 2626 ippmNetMeasureTxPacketRate, 2627 ippmNetMeasureMedOrBurstSize, 2628 ippmNetMeasureDevOrIntBurstSize, 2629 ippmNetMeasureLossTimeout, 2630 ippmNetMeasureL3PacketSize, 2631 ippmNetMeasureDataPattern, 2632 ippmNetMeasureTotalPktsRecv, 2633 ippmNetMeasureLastUpdate, 2634 ippmNetMeasureOperState 2635 } 2636 STATUS current 2637 DESCRIPTION 2638 "The IPPM Network Measure Group" 2639 ::= { ippmGroups 2} 2641 ippmHistoryGroup OBJECT-GROUP 2642 OBJECTS { 2643 ippmHistoryTimestamp, 2644 ippmHistoryValue, 2645 ippmHistoryPathToResults 2646 } 2647 STATUS current 2648 DESCRIPTION 2649 "The IPPM History Group" 2651 ::= { ippmGroups 3} 2653 ippmAggrMeasureGroup OBJECT-GROUP 2654 OBJECTS { 2655 ippmAggrMeasureName, 2656 ippmAggrMeasureMetrics, 2657 ippmAggrMeasureBeginTime, 2658 ippmAggrMeasureAggrPeriodUnit, 2659 ippmAggrMeasureAggrPeriod, 2660 ippmAggrMeasureDurationUnit, 2661 ippmAggrMeasureDuration, 2662 ippmAggrMeasureFilter, 2663 ippmAggrMeasureLowThreshold, 2664 ippmAggrMeasureHighThreshold, 2665 ippmAggrMeasureHistorySize, 2666 ippmAggrMeasureStorageType, 2667 ippmAggrMeasureHistoryOwner, 2668 ippmAggrMeasureHistoryIndex, 2669 ippmAggrMeasureHistoryMetric, 2670 ippmAggrMeasureAdminState, 2671 ippmAggrMeasureFastReport, 2672 ippmAggrMeasureResultsMgmt, 2673 ippmAggrMeasureLastUpdate, 2674 ippmAggrMeasureOperState, 2675 ippmAggrMeasureNbPktsTreated, 2676 ippmAggrMeasureStatus 2677 } 2678 STATUS current 2679 DESCRIPTION 2680 "The IPPM AggregatedMeasure Group" 2681 ::= { ippmGroups 4} 2683 ippmOwnersGroup OBJECT-GROUP 2684 OBJECTS { 2685 ippmOwnersGrantedMetrics, 2686 ippmOwnersQuota, 2687 ippmOwnersIpAddressType, 2688 ippmOwnersIpAddress, 2689 ippmOwnersEmail, 2690 ippmOwnersStatus 2691 } 2692 STATUS current 2693 DESCRIPTION 2694 "The IPPM Owners Group" 2695 ::= { ippmGroups 5} 2697 ippmNotificationGroup NOTIFICATION-GROUP 2698 NOTIFICATIONS { 2699 ippmAggrMeasureReport, 2700 ippmNetMeasureHistoryFull, 2701 ippmAggrMeasureHistoryFull 2702 } 2703 STATUS current 2704 DESCRIPTION 2705 "The IPPM Notification Group" 2706 ::= { ippmGroups 6} 2708 END 2710 8 Security Considerations 2712 8.1 VACM Access control 2714 View Based Access Control, or VACM may be used to restrict access to 2715 certain objects, or even object instances within tables. For example, 2716 one may: 2718 + Give an 'administrator' write access to the ippmOwnersTable, 2719 whereas all other users may only have read access 2720 + Give access to individual rows in the network measure, aggregated 2721 measure, history, and report table to particular owners based upon 2722 indexing on an 'owners name', and even upon a particular measure. 2723 This will be illustrated below. 2724 + Give access of one owner�s measure, and associated results, to 2725 another owner in order to create an aggregated measure based upon the 2726 results. 2728 8.1.1 Example of implementing VACM control for the IPPM-REPORTING-MIB 2730 The following example illustrates how one could use VACM to restrict 2731 access to particular objects within the MIB. It uses syntax specific 2732 to a particular agent development toolkit, but may be generalized 2733 using the concepts as defined in the VACM MIB. 2735 In this example, we have two NMS users, namely user1=owner1 and 2736 user2=owner2: 2737 1) First we define the two users and their host addresses: 2738 com2sec owner1 owner1computer@ private 2739 com2sec owner2 owner2computer@ private 2741 2) We then define SNMPv2c groups 2742 group owner1 v2c owner1 2743 group owner2 v2c owner2 2744 view notif included ippmNotifications ff 2746 3.1) For the user owner1, we now define the views for which he will 2747 have read access 2748 # covers PointOfMeasureTable SynchronizationTable and all scalars 2749 view owner1read included ippmSystem ff 2750 # covers OwnersTable 2751 view owner1read included ippmOwners ff 2752 # covers MetricsTable 2753 view owner1read included ippmMeasure ff 2754 # covers NetworkMeasureTable 2755 view owner1read included 2756 ippmNetMeasureOwner.6.111.119.110.101.114.49 ff.df.c0 2757 # covers AggrMeasureTable 2758 view owner1read included 2759 ippmAggrMeasureOwner.6.111.119.110.101.114.49 ff.df.c0 2761 3.2) We will now define the views for which owner1 will have write 2762 access 2763 view owner1write included 2764 ippmAggrMeasureOwner.6.111.119.110.101.114.49 ff.df.c0 2765 # covers ReportSetupTable 2766 view owner1read included 2767 ippmReportSetupOwner.6.111.119.110.101.114.49 ff.df.c0 2768 view owner1write included 2769 ippmReportSetupOwner.6.111.119.110.101.114.49 ff.df.c0 2770 # covers HistoryTable 2771 view owner1read included 2772 ippmHistoryMeasureOwner.6.111.119.110.101.114.49 ff.df.c0 2773 # covers ReportTable 2774 view owner1read included 2775 ippmReportSequence.6.111.119.110.101.114.49 ff.df.c0 2777 3.3) For owner2, we will define the views for which he has read 2778 access 2779 view owner2read included ippmSystem ff 2780 view owner2read included ippmOwners ff 2781 view owner2read included ippmMeasure ff 2782 # covers NetworkMeasureTable plus let's say the owner1 network 2783 measure of index X 2784 view owner2read included 2785 ippmNetMeasureOwner.6.111.119.110.101.114.50 ff.df.c0 2786 view owner2read included 2787 ippmNetMeasureOwner.6.111.119.110.101.114.49.X ff.df.e0 2788 # covers AggrMeasureTable plus let's say the OWNER1 aggregated 2789 measure of index Y 2790 view owner2read included 2791 ippmAggrMeasureOwner.6.111.119.110.101.114.50 ff.df.c0 2792 view owner2read included 2793 ippmAggrMeasureOwner.6.111.119.110.101.114.49.Y ff.df.e0 2794 3.4) For owner2, we will define the views for which he has write 2795 access 2796 view owner2write included 2797 ippmAggrMeasureOwner.6.111.119.110.101.114.50 ff.df.c0 2798 # covers ReportSetupTable 2799 view owner2read included 2800 ippmReportSetupOwner.6.111.119.110.101.114.50 ff.df.c0 2802 view owner2write included 2803 ippmReportSetupOwner.6.111.119.110.101.114.50 ff.df.c0 2804 # covers HistoryTable plus OWNER1 related X network measure results 2805 and OWNER1 related Y aggregated measure results 2806 view owner2read included 2807 ippmHistoryMeasureOwner.6.111.119.110.101.114.50 ff.df.c0 2808 view owner2read included 2809 ippmHistoryMeasureOwner.6.111.119.110.101.114.49.X ff.df.e0 2810 view owner2read included 2811 ippmHistoryMeasureOwner.6.111.119.110.101.114.49.Y ff.df.e0 2812 # covers ReportTable 2813 view owner2read included 2814 ippmReportSequence.6.111.119.110.101.114.50 ff.df.c0 2816 3.5) Now we give the two users access to the views defined above. 2817 Note that owner1 and owner2 have read access to owner1read and 2818 owner2read views respectively. They have write access to owner1write 2819 and owner2write view respectively. And they both have access to all 2820 the notifications. 2822 access owner1 "" any noauth exact owner1read 2823 owner1write notif 2824 access owner2 "" any noauth exact owner2read 2825 owner2write notif 2827 8.2 Privacy 2829 The privacy concerns of network measurement are intrinsically limited 2830 by the active measurements. Unlike passive measurements, there can be 2831 no release of existing user data. 2833 8.3 Measurement aspects 2835 Conducting Internet measurements raises both security and privacy 2836 concerns. This memo does not specify an implementation of the 2837 metrics, so it does not directly affect the security of the Internet 2838 nor of applications that run on the Internet. However, 2839 implementations of these metrics must be mindful of security and 2840 privacy concerns. 2842 There are two types of security concerns: potential harm caused by 2843 the measurements, and potential harm to the measurements. The 2844 measurements could cause harm because they are active, and inject 2845 packets into the network. The measurement parameters MUST be 2846 carefully selected so that the measurements inject trivial amounts of 2847 additional traffic into the networks they measure. If they inject 2848 "too much" traffic, they can skew the results of the measurement, and 2849 in extreme cases cause congestion and denial of service. 2851 The measurements themselves could be harmed by routers giving 2852 measurement traffic a different priority than "normal" traffic, or by 2853 an attacker injecting artificial measurement traffic. If routers can 2854 recognize measurement traffic and treat it separately, the 2855 measurements will not reflect actual user traffic. If an attacker 2856 injects artificial traffic that is accepted as legitimate, the loss 2857 rate will be artificially lowered. Therefore, the measurement 2858 methodologies SHOULD include appropriate techniques to reduce the 2859 probability measurement traffic can be distinguished from "normal" 2860 traffic. 2862 Authentication techniques, such as digital signatures, may be used 2863 where appropriate to guard against injected traffic attacks. 2865 8.4 Management aspects 2867 There are a number of management objects defined in this MIB that 2868 have a MAX-ACCESS clause of read-write and/or read-only. Such objects 2869 may be considered sensitive or vulnerable in some network 2870 environments. The support for SET operations in a non-secure 2871 environment without proper protection can have a negative effect on 2872 network operations. 2874 SNMPv1 by itself is not a secure environment. Even if the network 2875 itself is secure (for example by using IPSec), even then, there is no 2876 control as to who on the secure network is allowed to access and 2877 GET/SET (read/change/create/delete) the objects in this MIB. 2879 It is recommended that the implementors consider the security 2880 features as provided by the SNMPv3 framework. Specifically, the use 2881 of the User-based Security Model RFC 2574 [18] and the View-based 2882 Access Control Model RFC 2575 [21] is recommended. 2884 It is then a customer/user responsibility to ensure that the SNMP 2885 entity giving access to an instance of this MIB, is properly 2886 configured to give access to the objects only to those principals 2887 (users) that have legitimate rights to indeed GET or SET 2888 (change/create/delete) them. 2890 9 Document management 2892 9.1 Open issues 2894 Smilint complains when accessible-for-notify is used for an index. 2896 9.2 Changes done since release 04 2898 Report Group deleted: 2899 reportHistoryTable deleted; 2900 reportSetupTable deleted; 2901 6 related notifications deleted; 2903 low and high thresholds added in ippmAggrMeasureTable; 2905 TC IppmOwnerIndex added to clearly define the owner namespace. 2907 GMTTimestamp time origine changed to NTP (1900). 2909 9.3 Changes done since release 03 2911 + SMI subtype: INTEGER vs Integer32...; 2912 + SMI UNITS: Clauses added; 2913 + cleanup of DEFVAL values; 2915 + Counter/index wrapping: 2916 the index of the table wrap independently of the sequence of the 2917 results. That makes it very difficult for application to track the 2918 results. As the sequence id identify the instance of the result of a 2919 measure the index is removed both from the table and from the index 2920 clause. 2921 ippmHistoryIndex removed from ippmHistoryEntry; 2922 ippmHistoryIndex removed from the INDEX clause of the table 2923 ippmHistoryTable; 2924 ippmReportIndex removed from ippmAggrHistoryEntry; 2925 ippmReportIndex removed from the clause INDEX of 2926 ippmAggrHistoryEntry INDEX clause of the table ippmAggrHistoryTable; 2928 9.4 Changes done since release 02 2930 + Security/VACM: 2931 sharing table removed; 2932 ippmMeasure merged with networkMeasure and AggrMeasure to have 2933 all networkMeasure objects in read only. 2934 Indexes belong to the table; 2935 remove all reference to SNMPv1 ...inSNMPTrapPDU 2937 + System: 2938 ippmSystemOperationalStatus added 2940 ippmSynchronizationTable adapted for proxy mode: 2941 ippmPointOfMeasureIndex added to the index of 2942 ippmSystemCurrentSynchronization removed from system 2944 capabilities: 2945 ippmPointOfMeasureMetrics added to 2946 IppmPointOfMeasureEntry; 2947 ippmMetricsType added to ippmMetricsTable; 2949 + Owners 2950 ippmMetricMaxHistorySize replaced with quota in ippmOwnersTable; 2952 + ippmOnHistoryFullAction replaced with resultsMgmt in aggr and network.; 2954 + network measure: 2955 ippmNetMeasureOperState added to indicate the state of the network 2956 measure 2957 state; 2958 added burst mode; 2959 state of the measure: nb of singletons collected and oper status 2960 added; 2962 +aggregated metric: 2963 fast report added to get raw results by email; 2965 + report setup: 2966 onReportDeliveryClearHistory removed from 2967 IppmMetricResultFilter; 2969 + Map field added to network, aggr and report tables to help to map 2970 on topology map or admin view. 2972 10 References 2974 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 2975 9, RFC 2026, October 1996. 2977 [2] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for 2978 Describing SNMP Management Frameworks", RFC 2571, April 1999. 2980 [3] Rose, M., and K. McCloghrie, "Structure and Identification of 2981 Management Information for TCP/IP-based Internets", STD 16, RFC 2982 1155, May 1990. 2984 [4] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, 2985 RFC 1212, March 1991. 2987 [5] M. Rose, "A Convention for Defining Traps for use with the SNMP", 2988 RFC 1215, March 1991. 2990 [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 2991 M., and S. Waldbusser, "Structure of Management Information 2992 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 2994 [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 2995 M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, 2996 RFC 2579, April 1999. 2998 [8] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 2999 M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, 3000 RFC 2580, April 1999. 3002 [9] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple 3003 Network Management Protocol", STD 15, RFC 1157, May 1990. 3005 [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 3006 "Introduction to Community-based SNMPv2", RFC 1901, January 1996. 3008 [11] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 3009 "Transport Mappings for Version 2 of the Simple Network Management 3010 Protocol (SNMPv2)", RFC 1906, January 1996. 3012 [12]Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 3013 Processing and Dispatching for the Simple Network Management 3014 Protocol (SNMP)", RFC 2572, April 1999. 3016 [13] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) 3017 for version 3 of the Simple Network Management Protocol (SNMPv3)", 3018 RFC 2574, April 1999. 3020 [14] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol 3021 Operations for Version 2 of the Simple Network Management Protocol 3022 (SNMPv2)", RFC 1905, January 1996. 3024 [15] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 3025 2573, April 1999. 3027 [16] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-basedAccess 3028 Control Model (VACM) for the Simple Network Management Protocol 3029 (SNMP)", RFC 2575, April 1999. 3031 [17] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction 3032 to Version 3 of the Internet-standard Network Management 3033 Framework", RFC 2570, April 1999. 3035 11 Acknowledgments 3037 A Kerbe. 3039 12 Authors' Addresses 3041 Emile STEPHAN 3042 France Telecom R & D 3043 2 avenue Pierre Marzin 3044 F-22307 Lannion cedex 3045 Phone: (+ 33) 2 96 05 11 11 3046 Email: emile.stephan@francetelecom.com 3048 Jessie Jewitt 3049 France Telecom R & D 3050 801 Gateway Blvd. Suit 500 3051 South San Francisco, CA 94080 3052 Tel: 1 650 875-1524 3053 Email: jessie.jewitt@francetelecom.com 3055 Full Copyright Statement 3057 "Copyright (C) The Internet Society (2001). All Rights Reserved. 3059 This document and translations of it may be copied and furnished to 3060 others, and derivative works that comment on or otherwise explain it 3061 or assist its implementation may be prepared, copied, published and 3062 distributed, in whole or in part, without restriction of any kind, 3063 provided that the above copyright notice and this paragraph are 3064 included on all such copies and derivative works. However, this 3065 document itself may not be modified in any way, such as by removing 3066 the copyright notice or references to the Internet Society or other 3067 Internet organizations, except as needed for the purpose of 3068 developing Internet standards in which case the procedures for 3069 copyrights defined in the Internet Standards process must be 3070 followed, or as required to translate it into languages other than 3071 English. 3073 The limited permissions granted above are perpetual and will not be 3074 revoked by the Internet Society or its successors or assigns. 3076 This document and the information contained herein is provided on an 3077 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3078 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3079 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3080 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3081 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.