idnits 2.17.1 draft-bierman-rmonmib-hc-alarm-mib-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard 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 abstract seems to contain references ([RFC2819]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 840 has weird spacing: '...imed to perta...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (12 November 2001) is 8200 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2026' on line 911 looks like a reference -- Missing reference section? 'RFC2819' on line 972 looks like a reference -- Missing reference section? 'RFC2571' on line 925 looks like a reference -- Missing reference section? 'RFC1155' on line 868 looks like a reference -- Missing reference section? 'RFC1212' on line 879 looks like a reference -- Missing reference section? 'RFC1215' on line 883 looks like a reference -- Missing reference section? 'RFC2578' on line 953 looks like a reference -- Missing reference section? 'RFC2579' on line 960 looks like a reference -- Missing reference section? 'RFC2580' on line 966 looks like a reference -- Missing reference section? 'RFC1157' on line 873 looks like a reference -- Missing reference section? 'RFC1901' on line 887 looks like a reference -- Missing reference section? 'RFC1906' on line 900 looks like a reference -- Missing reference section? 'RFC2572' on line 931 looks like a reference -- Missing reference section? 'RFC2574' on line 1009 looks like a reference -- Missing reference section? 'RFC1905' on line 893 looks like a reference -- Missing reference section? 'RFC2573' on line 937 looks like a reference -- Missing reference section? 'RFC2575' on line 1010 looks like a reference -- Missing reference section? 'RFC2570' on line 919 looks like a reference -- Missing reference section? 'RFC2863' on line 981 looks like a reference -- Missing reference section? 'RFC2119' on line 915 looks like a reference -- Missing reference section? 'RFC2021' on line 907 looks like a reference -- Missing reference section? 'RFC2856' on line 976 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 24 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Andy Bierman 3 Cisco Systems, Inc. 4 Keith McCloghrie 5 Cisco Systems, Inc. 6 12 November 2001 8 Remote Monitoring MIB Extensions for 9 High Capacity Alarms 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with all 16 provisions of Section 10 of RFC2026 [RFC2026]. 18 Internet-Drafts are working documents of the Internet Engineering Task 19 Force (IETF), its areas, and its working groups. Note that other groups 20 may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference material 25 or to cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Distribution of this document is unlimited. Please send comments to 34 authors. 36 1. Copyright Notice 38 Copyright (C) The Internet Society (2001). All Rights Reserved. 40 2. Abstract 42 This memo defines a portion of the Management Information Base (MIB) for 43 use with network management protocols in the Internet community. In 44 particular, it describes managed objects for extending the alarm 45 thresholding capabilities found in the RMON MIB [RFC2819], to provide 46 similar threshold monitoring of objects based on the Counter64 data 47 type. 49 3. Table of Contents 51 1 Copyright Notice ................................................ 1 52 2 Abstract ........................................................ 2 53 3 Table of Contents ............................................... 2 54 4 The SNMP Network Management Framework ........................... 2 55 5 Overview ........................................................ 3 56 5.1 Terms ......................................................... 4 57 5.2 Relationship to the Remote Monitoring MIBs .................... 5 58 6 MIB Structure ................................................... 5 59 6.1 MIB Group Overview ............................................ 6 60 6.1.1 High Capacity Alarm Group ................................... 6 61 6.1.2 High Capacity Alarm Notifications ........................... 7 62 7 Definitions ..................................................... 8 63 8 Intellectual Property ........................................... 21 64 9 Acknowledgements ................................................ 21 65 10 References ..................................................... 21 66 11 Security Considerations ........................................ 24 67 12 Authors' Addresses ............................................. 25 68 13 Full Copyright Statement ....................................... 25 70 4. The SNMP Network Management Framework 72 The SNMP Management Framework presently consists of five major 73 components: 75 o An overall architecture, described in RFC 2571 [RFC2571]. 77 o Mechanisms for describing and naming objects and events for the 78 purpose of management. The first version of this Structure of 79 Management Information (SMI) is called SMIv1 and described in 80 RFC 1155 [RFC1155], RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. 81 The second version, called SMIv2, is described in RFC 2578 82 [RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2580]. 84 o Message protocols for transferring management information. The 85 first version of the SNMP message protocol is called SNMPv1 and 86 described in RFC 1157 [RFC1157]. A second version of the SNMP 87 message protocol, which is not an Internet standards track 88 protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] 89 and RFC 1906 [RFC1906]. The third version of the message 90 protocol is called SNMPv3 and described in RFC 1906 [RFC1906], 91 RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. 93 o Protocol operations for accessing management information. The 94 first set of protocol operations and associated PDU formats is 95 described in RFC 1157 [RFC1157]. A second set of protocol 96 operations and associated PDU formats is described in RFC 1905 97 [RFC1905]. 99 o A set of fundamental applications described in RFC 2573 100 [RFC2573] and the view-based access control mechanism described 101 in RFC 2575 [RFC2575]. 103 A more detailed introduction to the current SNMP Management Framework 104 can be found in RFC 2570 [RFC2570]. 106 Managed objects are accessed via a virtual information store, termed 107 the Management Information Base or MIB. Objects in the MIB are 108 defined using the mechanisms defined in the SMI. 110 This memo specifies a MIB module that is compliant to the SMIv2. A 111 MIB conforming to the SMIv1 can be produced through the appropriate 112 translations. The resulting translated MIB must be semantically 113 equivalent, except where objects or events are omitted because no 114 translation is possible (use of Counter64). Some machine readable 115 information in SMIv2 will be converted into textual descriptions in 116 SMIv1 during the translation process. However, this loss of machine 117 readable information is not considered to change the semantics of the 118 MIB. 120 5. Overview 122 There is a need for a standardized way of providing the same type of 123 alarm thresholding capabilities for Counter64 objects, as already exists 124 for Counter32 objects. The RMON-1 alarmTable objects and RMON-1 125 notification types are specific to 32-bit objects, and cannot be used to 126 properly monitor Counter64-based objects. Extensions to these existing 127 constructs are needed which explicitly support Counter64-based objects. 128 These extensions are completely independent of the existing RMON-1 alarm 129 mechanisms. 131 The usage of Counter64 objects is increasing. One of the causes for 132 this increase is the increasing speeds of network interfaces; RFC 2863 133 [RFC2863] says: 135 As the speed of network media increase, the minimum time in which a 136 32 bit counter will wrap decreases. For example, a 10Mbs stream of 137 back-to-back, full-size packets causes ifInOctets to wrap in just 138 over 57 minutes; at 100Mbs, the minimum wrap time is 5.7 minutes, and 139 at 1Gbs, the minimum is 34 seconds. Requiring that interfaces be 140 polled frequently enough not to miss a counter wrap is increasingly 141 problematic. 143 and therefore requires: 145 For interfaces that operate at 20,000,000 (20 million) bits per 146 second or less, 32-bit byte and packet counters MUST be supported. 147 For interfaces that operate faster than 20,000,000 bits/second, 148 and slower than 650,000,000 bits/second, 32-bit packet counters 149 MUST be supported and 64-bit octet counters MUST be supported. 150 For interfaces that operate at 650,000,000 bits/second or faster, 151 64-bit packet counters AND 64-bit octet counters MUST be supported. 153 Of the variables on which thresholds are set using RMON-1's alarmTable, 154 two of the most popular are: ifInOctets and ifOutOctets. Thus, the 155 increasing usage of the 64-bit versions: ifHCInOctets and ifHCOutOctets 156 means that there's an increasing requiurement to use RMON-1's 157 thresholding capability for ifHCInOctets and ifHCOutOctets. 159 The RMON-1 Alarm Group is implemented not only by all RMON probes, but 160 also by the SNMP agents in many other types of devices for the purpose 161 of monitoring any of their (non-RMON) integer-valued MIB objects. The 162 fact that it has been so widely implemented indicates its obvious value. 163 Without this extension, that obvious value is becoming incomplete 164 because of its lack of support for 64-bit integers. This extension is 165 the easiest, simplest, and most compatible way for an implementation to 166 overcome that lack of support. 168 5.1. Terms 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 172 document are to be interpreted as described in RFC 2119. [RFC2119] 173 5.2. Relationship to the Remote Monitoring MIBs 175 This MIB is intended to be implemented in Remote Monitoring (RMON) 176 probes, which may also support the RMON-1 MIB [RFC2819]. Such probes 177 may be stand-alone devices, or may be co-located with other networking 178 devices (e.g., ethernet switches and repeaters). 180 The functionality of the High Capacity Alarm Group is a supserset of 181 RMON-1's Alarm Group. Thus, one day in the distant future, it's a 182 possibility that RMON-1's Alarm Group will be deprecated in favour of 183 this MIB's High Capacity Alarm Group. However, that day will not come 184 before this document, or one of its successors, reaches the same 185 standardization state as RMON-1. 187 6. MIB Structure 189 Figure 1: HC-ALARM MIB Functional Structure 191 +---------------------------------------------+ 192 | | 193 | (RMON-1) (HC-ALARM) | 194 | +-----------+ +-----------+ | 195 | | | | | | 196 | | alarm | | hcAlarm | | 197 | | Table | | Table | | 198 | | | | | | 199 | +-----------+ +-----------+ | 200 | | | | 201 | V (RMON-1) V | 202 | +----------------------------------+ | 203 | | | | 204 | | eventTable | | 205 | | | | 206 | +----------------------------------+ | 207 | | | | 208 | | | | 209 | V V | 210 | +---------------+ +----------------+ | 211 | | risingAlarm | | hcRisingAlarm | | 212 | | fallingAlarm | | hcFallingAlarm | | 213 | | Notifications | | Notifications | | 214 | +---------------+ +----------------+ | 215 | (RMON-1) (HC-ALARM) | 216 +---------------------------------------------+ 218 6.1. MIB Group Overview 220 The HC-ALARM MIB contains two MIB groups: 222 - hcAlarmObjects group 223 Controls the configuration of alarms for high capacity MIB object 224 instances. 226 - hcAlarmNotifications group 227 Provide new rising and falling threshold notifications for high 228 capacity objects. 230 6.1.1. High Capacity Alarm Group 232 This group contains one table, which is used by a management station to 233 configure high capacity alarm entries. To configure alarm thresholding 234 for Counter64 or CounterBasedGauge64 objects, a management application 235 must configure the hcAlarmTable in a manner similar to how RMON-1's 236 alarmTable is configured. 238 Because the language in the some of the DESCRIPTION clauses of objects 239 in the alarmTable is specific to the alarmTable itself, their defined 240 semantics do not allow them to be used for this MIB also. Therefore, 241 the following objects are essentially cloned from the alarmTable to the 242 hcAlarmTable: 244 alarmTable hcAlarmTable 245 ---------- ------------ 246 alarmIndex hcAlarmIndex 247 alarmInterval hcAlarmInterval 248 alarmVariable hcAlarmVariable 249 alarmSampleType hcAlarmSampleType 250 alarmStartupAlarm hcAlarmStartupAlarm 251 alarmRisingEventIndex hcAlarmRisingEventIndex 252 alarmFallingEventIndex hcAlarmFallingEventIndex 253 alarmOwner hcAlarmOwner 254 alarmStatus hcAlarmStatus 256 In addition, the following hcAlarmTable objects are used as high 257 capacity values instead of the corresponding 32-bit version in the 258 alarmTable. 260 alarmTable hcAlarmTable 261 ---------- ------------ 262 alarmValue hcAlarmAbsValue 263 hcAlarmValueStatus 264 alarmRisingThreshold hcAlarmRisingThresholdAbsValue 265 hcAlarmRisingThresholdValStatus 266 alarmFallingThreshold hcAlarmFallingThresholdAbsValue 267 hcAlarmFallingThresholdValStatus 269 Nevertheless, the hcAlarmTable does have a few differences from the 270 alarmTable: 272 - Counter64 based objects are thresholded properly 273 - an entry is not destroyed if the instance identified by the 274 hcAlarmVariable is not available during a polling interval. 275 - the RowStatus textual convention is used instead of EntryStatus for 276 the hcAlarmStatus object." 278 6.1.2. High Capacity Alarm Notifications 280 This group contains two notifications, hcRisingAlarm and hcFallingAlarm. 281 These are generated for high capacity alarms in the same manner and used 282 to convey essentially the same information as RMON-1's risingAlarm and 283 fallingAlarm notifications do for alarmTable-specified alarms. 285 7. Definitions 287 HC-ALARM-MIB DEFINITIONS ::= BEGIN 289 IMPORTS 290 MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, 291 Integer32, Counter64, experimental 292 FROM SNMPv2-SMI 293 MODULE-COMPLIANCE, OBJECT-GROUP, 294 NOTIFICATION-GROUP 295 FROM SNMPv2-CONF 296 RowStatus, VariablePointer, TEXTUAL-CONVENTION 297 FROM SNMPv2-TC 298 OwnerString, rmonEventGroup 299 FROM RMON-MIB; 301 hcAlarmMIB MODULE-IDENTITY 302 LAST-UPDATED "200111060000Z" 303 ORGANIZATION "Cisco Systems, Inc." 304 CONTACT-INFO 305 " Andy Bierman 306 Cisco Systems, Inc. 307 Tel: +1 408 527-3711 308 E-mail: abierman@cisco.com 309 Postal: 170 West Tasman Drive 310 San Jose, CA USA 95134 312 Keith McCloghrie 313 Cisco Systems, Inc. 314 Tel: +1 408 526-5260 315 E-mail: kzm@cisco.com 316 Postal: 170 West Tasman Drive 317 San Jose, CA USA 95134 318 " 319 DESCRIPTION 320 "This module defines Remote Monitoring MIB extensions for 321 High Capacity Alarms." 322 REVISION "200111060000Z" 323 DESCRIPTION 324 "Initial version of the High Capacity Alarm MIB module." 325 ::= { experimental 999999 } -- unassigned 327 hcAlarmObjects OBJECT IDENTIFIER ::= { hcAlarmMIB 1 } 328 hcAlarmNotifications OBJECT IDENTIFIER ::= { hcAlarmMIB 2 } 329 hcAlarmConformance OBJECT IDENTIFIER ::= { hcAlarmMIB 3 } 331 hcAlarmControlObjects OBJECT IDENTIFIER ::= { hcAlarmObjects 1 } 333 -- 334 -- Textual Conventions 335 -- 337 HcValueStatus ::= TEXTUAL-CONVENTION 338 STATUS current 339 DESCRIPTION 340 "This data type indicates the validity and sign of the data 341 in associated object instances of the type HcAbsoluteValue. 342 Objects of this type MUST be defined together with an object 343 of type HcAbsoluteValue. 345 If the associated object instance of type HcAbsoluteValue 346 could not be accessed during the sampling interval, and is 347 therefore invalid, then the associated HcValueStatus object 348 will contain the value 'valueNotAvailable(1)'. 350 If the associated object instance of type HcAbsoluteValue is 351 valid and actual value of the sample is greater than or 352 equal to zero, then the associated HcValueStatus object will 353 contain the value 'valuePositive(2)'. 355 If the associated object instance of type HcAbsoluteValue is 356 valid and the actual value of the sample is less than zero, 357 then the associated HcValueStatus object will contain the 358 value 'valueNegative(3)'. The associated absolute value 359 should be multiplied by -1 to obtain the true sample value." 360 SYNTAX INTEGER { 361 valueNotAvailable(1), 362 valuePositive(2), 363 valueNegative(3) 364 } 366 HcAbsoluteValue ::= TEXTUAL-CONVENTION 367 STATUS current 368 DESCRIPTION 369 "Objects of this data type represent a 64-bit absolute 370 value. Objects of this type MUST be defined together with 371 an object of type HcValueStatus. The 'combined object' 372 represents a 64-bit signed integer, or an unavailable 373 number. 375 This data type represents a non-negative integer, which may 376 increase or decrease, but shall never exceed a maximum 377 value, nor fall below a minimum value. The maximum value can 378 not be greater than 2^64-1 (18446744073709551615 decimal), 379 and the minimum value can not be smaller than 0. The value 380 of an HcAbsoluteValue has its maximum value whenever the 381 information being modeled is greater than or equal to its 382 maximum value, and has its minimum value whenever the 383 information being modeled is smaller than or equal to its 384 minimum value. If the information being modeled 385 subsequently decreases below (increases above) the maximum 386 (minimum) value, the HcAbsoluteValue also decreases 387 (increases). 389 Note that this TC is not strictly supported in SMIv2, 390 because the 'always increasing' and 'counter wrap' semantics 391 associated with the Counter64 base type are not preserved. 392 It is possible that management applications which rely 393 solely upon the (Counter64) ASN.1 tag to determine object 394 semantics will mistakenly operate upon objects of this type 395 as they would for Counter64 objects. 397 This textual convention represents a limited and short-term 398 solution, and may be deprecated as a long term solution is 399 defined and deployed to replace it." 400 SYNTAX Counter64 -- CounterBasedGauge64 402 -- 403 -- High Capacity Alarm Table 404 -- 406 hcAlarmTable OBJECT-TYPE 407 SYNTAX SEQUENCE OF HcAlarmEntry 408 MAX-ACCESS not-accessible 409 STATUS current 410 DESCRIPTION 411 "A list of entries for the configuration of high capacity 412 alarms." 413 ::= { hcAlarmControlObjects 1 } 415 hcAlarmEntry OBJECT-TYPE 416 SYNTAX HcAlarmEntry 417 MAX-ACCESS not-accessible 418 STATUS current 419 DESCRIPTION 420 "A conceptual row in the hcAlarmTable. Entries are created 421 in this table by management application action only. 423 The agent SHOULD support non-volatile configuration of this 424 table, and upon system initialization, the table SHOULD be 425 initialized with the saved values." 426 INDEX { hcAlarmIndex } 427 ::= { hcAlarmTable 1 } 429 HcAlarmEntry ::= SEQUENCE { 430 hcAlarmIndex Integer32, 431 hcAlarmInterval Integer32, 432 hcAlarmVariable VariablePointer, 433 hcAlarmSampleType INTEGER, 434 hcAlarmAbsValue HcAbsoluteValue, 435 hcAlarmValueStatus HcValueStatus, 436 hcAlarmStartupAlarm INTEGER, 437 hcAlarmRisingThresholdAbsValue HcAbsoluteValue, 438 hcAlarmRisingThresholdValStatus HcValueStatus, 439 hcAlarmFallingThresholdAbsValue HcAbsoluteValue, 440 hcAlarmFallingThresholdValStatus HcValueStatus, 441 hcAlarmRisingEventIndex Integer32, 442 hcAlarmFallingEventIndex Integer32, 443 hcAlarmOwner OwnerString, 444 hcAlarmStatus RowStatus } 446 hcAlarmIndex OBJECT-TYPE 447 SYNTAX Integer32 (1..65535) 448 MAX-ACCESS not-accessible 449 STATUS current 450 DESCRIPTION 451 "An arbitrary integer index value used to uniquely identify 452 this high capacity alarm entry." 453 ::= { hcAlarmEntry 1 } 455 hcAlarmInterval OBJECT-TYPE 456 SYNTAX Integer32 (1..2147483647) 457 UNITS "seconds" 458 MAX-ACCESS read-create 459 STATUS current 460 DESCRIPTION 461 "The interval in seconds over which the data is sampled and 462 compared with the rising and falling thresholds. When 463 setting this variable, care should be taken in the case of 464 deltaValue sampling - the interval should be set short 465 enough that the sampled variable is very unlikely to 466 increase or decrease by more than 2^63 - 1 during a single 467 sampling interval. 469 This object may not be modified if the associated 470 hcAlarmStatus object is equal to active(1)." 471 ::= { hcAlarmEntry 2 } 473 hcAlarmVariable OBJECT-TYPE 474 SYNTAX VariablePointer 475 MAX-ACCESS read-create 476 STATUS current 477 DESCRIPTION 478 "The object identifier of the particular variable to be 479 sampled. Only variables that resolve to an ASN.1 primitive 480 type of INTEGER (INTEGER, Integer32, Counter32, Counter64, 481 Gauge, or TimeTicks) may be sampled. 483 Because SNMP access control is articulated entirely in terms 484 of the contents of MIB views, no access control mechanism 485 exists that can restrict the value of this object to 486 identify only those objects that exist in a particular MIB 487 view. Because there is thus no acceptable means of 488 restricting the read access that could be obtained through 489 the alarm mechanism, the probe must only grant write access 490 to this object in those views that have read access to all 491 objects on the probe. 493 During a set operation, if the supplied variable name is not 494 available in the selected MIB view, a badValue error MUST be 495 returned. 497 This object may not be modified if the associated 498 hcAlarmStatus object is equal to active(1)." 499 ::= { hcAlarmEntry 3 } 501 hcAlarmSampleType OBJECT-TYPE 502 SYNTAX INTEGER { 503 absoluteValue(1), 504 deltaValue(2) 505 } 506 MAX-ACCESS read-create 507 STATUS current 508 DESCRIPTION 509 "The method of sampling the selected variable and 510 calculating the value to be compared against the thresholds. 511 If the value of this object is absoluteValue(1), the value 512 of the selected variable will be compared directly with the 513 thresholds at the end of the sampling interval. If the 514 value of this object is deltaValue(2), the value of the 515 selected variable at the last sample will be subtracted from 516 the current value, and the difference compared with the 517 thresholds. 519 If the associated hcAlarmVariable instance could not be 520 obtained at the previous sample interval, then a delta 521 sample is not possible, and the value of the associated 522 hcAlarmValueStatus object for this interval will be 523 valueNotAvailable(1). 525 This object may not be modified if the associated 526 hcAlarmStatus object is equal to active(1)." 527 ::= { hcAlarmEntry 4 } 529 hcAlarmAbsValue OBJECT-TYPE 530 SYNTAX HcAbsoluteValue 531 MAX-ACCESS read-only 532 STATUS current 533 DESCRIPTION 534 "The absolute value (i.e. unsigned value) of the 535 hcAlarmVariable statistic during the last sampling period. 536 The value during the current sampling period is not made 537 available until the period is completed. 539 To obtain the true value for this sampling interval, the 540 associated instance of hcAlarmValueStatus must be checked, 541 and the value of this object adjusted as necessary. 543 If the MIB instance could not be accessed during the 544 sampling interval, then this object will have a value of 545 zero and the associated instance of hcAlarmValueStatus will 546 be set to 'valueNotAvailable(1)'." 547 ::= { hcAlarmEntry 5 } 549 hcAlarmValueStatus OBJECT-TYPE 550 SYNTAX HcValueStatus 551 MAX-ACCESS read-only 552 STATUS current 553 DESCRIPTION 554 "This object indicates the validity and sign of the data for 555 the hcAlarmAbsValue object, as described in the 556 HcValueStatus textual convention." 557 ::= { hcAlarmEntry 6 } 559 hcAlarmStartupAlarm OBJECT-TYPE 560 SYNTAX INTEGER { 561 risingAlarm(1), 562 fallingAlarm(2), 563 risingOrFallingAlarm(3) 564 } 565 MAX-ACCESS read-create 566 STATUS current 567 DESCRIPTION 568 "The alarm that may be sent when this entry is first set to 569 valid. If the first sample after this entry becomes valid 570 is greater than or equal to the rising threshold and this 571 object is equal to risingAlarm(1) or 572 risingOrFallingAlarm(3), then a single rising alarm will be 573 generated. If the first sample after this entry becomes 574 valid is less than or equal to the falling threshold and 575 this object is equal to fallingAlarm(2) or 576 risingOrFallingAlarm(3), then a single falling alarm will be 577 generated. 579 This object may not be modified if the associated 580 hcAlarmStatus object is equal to active(1)." 581 ::= { hcAlarmEntry 7 } 583 hcAlarmRisingThresholdAbsValue OBJECT-TYPE 584 SYNTAX HcAbsoluteValue 585 MAX-ACCESS read-create 586 STATUS current 587 DESCRIPTION 588 "The absolute value for threshold for the sampled statistic. 589 The actual threshold value is determined by the associated 590 instance of the hcAlarmRisingThresholdValStatus object, as 591 described in the HcAbsoluteValue textual convention. 593 When the current sampled value is greater than or equal to 594 this threshold, and the value at the last sampling interval 595 was less than this threshold, a single event will be 596 generated. A single event will also be generated if the 597 first sample after this entry becomes valid is greater than 598 or equal to this threshold and the associated 599 hcAlarmStartupAlarm is equal to risingAlarm(1) or 600 risingOrFallingAlarm(3). 602 After a rising event is generated, another such event will 603 not be generated until the sampled value falls below this 604 threshold and reaches the threshold identified by the 605 hcAlarmFallingThresholdAbsValue and 606 hcAlarmFallingThresholdValStatus objects. 608 This object may not be modified if the associated 609 hcAlarmStatus object is equal to active(1)." 610 ::= { hcAlarmEntry 8 } 612 hcAlarmRisingThresholdValStatus OBJECT-TYPE 613 SYNTAX HcValueStatus 614 MAX-ACCESS read-create 615 STATUS current 616 DESCRIPTION 617 "This object indicates the sign of the data for the 618 hcAlarmRisingThresholdAbsValue object, as described in the 619 HcValueStatus textual convention. 621 The enumeration 'valueNotAvailable(1)' is not allowed, and 622 the associated hcAlarmStatus object cannot be equal to 623 'active(1)' if this object is set to this value. 625 This object may not be modified if the associated 626 hcAlarmStatus object is equal to active(1)." 627 ::= { hcAlarmEntry 9 } 629 hcAlarmFallingThresholdAbsValue OBJECT-TYPE 630 SYNTAX HcAbsoluteValue 631 MAX-ACCESS read-create 632 STATUS current 633 DESCRIPTION 634 "The absolute value for threshold for the sampled statistic. 635 The actual threshold value is determined by the associated 636 instance of the hcAlarmFallingThresholdValStatus object, as 637 described in the HcAbsoluteValue textual convention. 639 When the current sampled value is less than or equal to this 640 threshold, and the value at the last sampling interval was 641 greater than this threshold, a single event will be 642 generated. A single event will also be generated if the 643 first sample after this entry becomes valid is less than or 644 equal to this threshold and the associated 645 hcAlarmStartupAlarm is equal to fallingAlarm(2) or 646 risingOrFallingAlarm(3). 648 After a falling event is generated, another such event will 649 not be generated until the sampled value rises above this 650 threshold and reaches the threshold identified by the 651 hcAlarmRisingThresholdAbsValue and 652 hcAlarmRisingThresholdValStatus objects. 654 This object may not be modified if the associated 655 hcAlarmStatus object is equal to active(1)." 656 ::= { hcAlarmEntry 10 } 658 hcAlarmFallingThresholdValStatus OBJECT-TYPE 659 SYNTAX HcValueStatus 660 MAX-ACCESS read-create 661 STATUS current 662 DESCRIPTION 663 "This object indicates the sign of the data for the 664 hcAlarmFallingThresholdAbsValue object, as described in the 665 HcValueStatus textual convention. 667 The enumeration 'valueNotAvailable(1)' is not allowed, and 668 the associated hcAlarmStatus object cannot be equal to 669 'active(1)' if this object is set to this value. 671 This object may not be modified if the associated 672 hcAlarmStatus object is equal to active(1)." 673 ::= { hcAlarmEntry 11 } 675 hcAlarmRisingEventIndex OBJECT-TYPE 676 SYNTAX Integer32 (0..65535) 677 MAX-ACCESS read-create 678 STATUS current 679 DESCRIPTION 680 "The index of the eventEntry that is used when a rising 681 threshold is crossed. The eventEntry identified by a 682 particular value of this index is the same as identified by 683 the same value of the eventIndex object. If there is no 684 corresponding entry in the eventTable, then no association 685 exists. In particular, if this value is zero, no associated 686 event will be generated, as zero is not a valid event index. 688 This object may not be modified if the associated 689 hcAlarmStatus object is equal to active(1)." 690 ::= { hcAlarmEntry 12 } 692 hcAlarmFallingEventIndex OBJECT-TYPE 693 SYNTAX Integer32 (0..65535) 694 MAX-ACCESS read-create 695 STATUS current 696 DESCRIPTION 697 "The index of the eventEntry that is used when a falling 698 threshold is crossed. The eventEntry identified by a 699 particular value of this index is the same as identified by 700 the same value of the eventIndex object. If there is no 701 corresponding entry in the eventTable, then no association 702 exists. In particular, if this value is zero, no associated 703 event will be generated, as zero is not a valid event index. 705 This object may not be modified if the associated 706 hcAlarmStatus object is equal to active(1)." 707 ::= { hcAlarmEntry 13 } 709 hcAlarmOwner OBJECT-TYPE 710 SYNTAX OwnerString 711 MAX-ACCESS read-create 712 STATUS current 713 DESCRIPTION 714 "The entity that configured this entry and is therefore 715 using the resources assigned to it." 716 ::= { hcAlarmEntry 14 } 718 hcAlarmStatus OBJECT-TYPE 719 SYNTAX RowStatus 720 MAX-ACCESS read-create 721 STATUS current 722 DESCRIPTION 723 "The status of this row. 725 An entry MUST NOT exist in the active state unless all 726 objects in the entry have an appropriate value, as described 727 in the description clause for each writable object." 728 ::= { hcAlarmEntry 15 } 730 -- 731 -- Notifications 732 -- 733 hcAlarmNotifPrefix OBJECT IDENTIFIER 734 ::= { hcAlarmNotifications 0 } 736 hcRisingAlarm NOTIFICATION-TYPE 737 OBJECTS { hcAlarmVariable, 738 hcAlarmSampleType, 739 hcAlarmAbsValue, 740 hcAlarmValueStatus, 741 hcAlarmRisingThresholdAbsValue, 742 hcAlarmRisingThresholdValStatus, 743 hcAlarmRisingEventIndex } 744 STATUS current 745 DESCRIPTION 746 "The SNMP notification that is generated when a high 747 capacity alarm entry crosses its rising threshold and 748 generates an event that is configured for sending SNMP 749 traps. 751 The hcAlarmEntry object instances identified in the OBJECTS 752 clause are from the entry that causes this notification to 753 be generated." 754 ::= { hcAlarmNotifPrefix 1 } 756 hcFallingAlarm NOTIFICATION-TYPE 757 OBJECTS { hcAlarmVariable, 758 hcAlarmSampleType, 759 hcAlarmAbsValue, 760 hcAlarmValueStatus, 761 hcAlarmFallingThresholdAbsValue, 762 hcAlarmFallingThresholdValStatus, 763 hcAlarmFallingEventIndex } 764 STATUS current 765 DESCRIPTION 766 "The SNMP notification that is generated when a high 767 capacity alarm entry crosses its falling threshold and 768 generates an event that is configured for sending SNMP 769 traps. 771 The hcAlarmEntry object instances identified in the OBJECTS 772 clause are from the entry that causes this notification to 773 be generated." 774 ::= { hcAlarmNotifPrefix 2 } 776 -- 777 -- Conformance Section 778 -- 780 hcAlarmCompliances OBJECT IDENTIFIER ::= { hcAlarmConformance 1 } 781 hcAlarmGroups OBJECT IDENTIFIER ::= { hcAlarmConformance 2 } 783 hcAlarmCompliance MODULE-COMPLIANCE 784 STATUS current 785 DESCRIPTION 786 "Describes the requirements for conformance to the High 787 Capacity Alarm MIB." 788 MODULE -- this module 789 MANDATORY-GROUPS { 790 hcAlarmControlGroup, 791 hcAlarmNotificationsGroup 792 } 794 MODULE RMON-MIB 795 MANDATORY-GROUPS { rmonEventGroup } 797 ::= { hcAlarmCompliances 1 } 799 -- Object Groups 801 hcAlarmControlGroup OBJECT-GROUP 802 OBJECTS { 803 hcAlarmInterval, 804 hcAlarmVariable, 805 hcAlarmSampleType, 806 hcAlarmAbsValue, 807 hcAlarmValueStatus, 808 hcAlarmStartupAlarm, 809 hcAlarmRisingThresholdAbsValue, 810 hcAlarmRisingThresholdValStatus, 811 hcAlarmFallingThresholdAbsValue, 812 hcAlarmFallingThresholdValStatus, 813 hcAlarmRisingEventIndex, 814 hcAlarmFallingEventIndex, 815 hcAlarmOwner, 816 hcAlarmStatus 817 } 818 STATUS current 819 DESCRIPTION 820 "A collection of objects used to configure entries for high 821 capacity alarm threshold monitoring purposes." 822 ::= { hcAlarmGroups 1 } 824 hcAlarmNotificationsGroup NOTIFICATION-GROUP 825 NOTIFICATIONS { 826 hcRisingAlarm, 827 hcFallingAlarm 828 } 829 STATUS current 830 DESCRIPTION 831 "A collection of notifications to deliver information 832 related to a high capacity rising or falling threshold event 833 to a management application." 834 ::= { hcAlarmGroups 2 } 836 END 837 8. Intellectual Property 839 The IETF takes no position regarding the validity or scope of any 840 intellectual property or other rights that might be claimed to pertain 841 to the implementation or use of the technology described in this 842 document or the extent to which any license under such rights might or 843 might not be available; neither does it represent that it has made any 844 effort to identify any such rights. Information on the IETF's 845 procedures with respect to rights in standards-track and standards- 846 related documentation can be found in BCP-11. Copies of claims of 847 rights made available for publication and any assurances of licenses to 848 be made available, or the result of an attempt made to obtain a general 849 license or permission for the use of such proprietary rights by 850 implementors or users of this specification can be obtained from the 851 IETF Secretariat. 853 The IETF invites any interested party to bring to its attention any 854 copyrights, patents or patent applications, or other proprietary rights 855 which may cover technology that may be required to practice this 856 standard. Please address the information to the IETF Executive 857 Director. 859 9. Acknowledgements 861 This memo is based on existing alarmTable objects in the RMON-1 MIB 862 module [RFC2819]. In order to maintain the RMON 'look-and-feel' and 863 semantic consistency, some of Steve Waldbusser's text from [RFC2819] has 864 been adapted for use in this MIB. 866 10. References 868 [RFC1155] 869 Rose, M., and K. McCloghrie, "Structure and Identification of 870 Management Information for TCP/IP-based Internets", RFC 1155, 871 Performance Systems International, Hughes LAN Systems, May 1990. 873 [RFC1157] 874 Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 875 Management Protocol", RFC 1157, SNMP Research, Performance Systems 876 International, Performance Systems International, MIT Laboratory 877 for Computer Science, May 1990. 879 [RFC1212] 880 Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, 881 Performance Systems International, Hughes LAN Systems, March 1991. 883 [RFC1215] 884 M. Rose, "A Convention for Defining Traps for use with the SNMP", 885 RFC 1215, Performance Systems International, March 1991. 887 [RFC1901] 888 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 889 Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, 890 SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, 891 Inc., International Network Services, January 1996. 893 [RFC1905] 894 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 895 Waldbusser, "Protocol Operations for Version 2 of the Simple 896 Network Management Protocol (SNMPv2)", RFC 1905, SNMP Research, 897 Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 898 International Network Services, January 1996. 900 [RFC1906] 901 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 902 Waldbusser, "Transport Mappings for Version 2 of the Simple Network 903 Management Protocol (SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco 904 Systems, Inc., Dover Beach Consulting, Inc., International Network 905 Services, January 1996. 907 [RFC2021] 908 S. Waldbusser, "Remote Network Monitoring MIB (RMON-2)", RFC 2021, 909 International Network Services, January 1997. 911 [RFC2026] 912 Bradner, S., "The Internet Standards Process -- Revision 3", RFC 913 2026, Harvard University, October, 1996. 915 [RFC2119] 916 S. Bradner, "Key words for use in RFCs to Indicate Requirement 917 Levels" RFC 2119, Harvard University, March 1997. 919 [RFC2570] 920 Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to 921 Version 3 of the Internet-standard Network Management Framework", 922 RFC 2570, SNMP Research, Inc., TIS Labs at Network Associates, 923 Inc., Ericsson, Cisco Systems, April 1999. 925 [RFC2571] 926 Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for 927 Describing SNMP Management Frameworks", RFC 2571, Cabletron 928 Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, April 929 1999. 931 [RFC2572] 932 Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 933 Processing and Dispatching for the Simple Network Management 934 Protocol (SNMP)", RFC 2572, SNMP Research, Inc., Cabletron Systems, 935 Inc., BMC Software, Inc., IBM T. J. Watson Research, April 1999. 937 [RFC2573] 938 Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 939 2573, SNMP Research, Inc., Secure Computing Corporation, Cisco 940 Systems, April 1999. 942 [RFC2574] 943 Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for 944 version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 945 2574, IBM T. J. Watson Research, April 1999. 947 [RFC2575] 948 Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access 949 Control Model (VACM) for the Simple Network Management Protocol 950 (SNMP)", RFC 2575, IBM T. J. Watson Research, BMC Software, Inc., 951 Cisco Systems, Inc., April 1999. 953 [RFC2578] 954 McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 955 and S. Waldbusser, "Structure of Management Information Version 2 956 (SMIv2)", RFC 2578, STD 58, Cisco Systems, SNMPinfo, TU 957 Braunschweig, SNMP Research, First Virtual Holdings, International 958 Network Services, April 1999. 960 [RFC2579] 961 McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 962 and S. Waldbusser, "Textual Conventions for SMIv2", RFC 2579, STD 963 58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, First 964 Virtual Holdings, International Network Services, April 1999. 966 [RFC2580] 967 McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 968 and S. Waldbusser, "Conformance Statements for SMIv2", RFC 2580, 969 STD 58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, 970 First Virtual Holdings, International Network Services, April 1999. 972 [RFC2819] 973 S. Waldbusser, "Remote Network Monitoring Management Information 974 Base", STD 59, RFC 2819, Lucent Technologies, May 2000. 976 [RFC2856] 977 Bierman, A., McCloghrie, K., and R. Presuhn, "Textual Conventions 978 for Additional High Capacity Data Types", RFC 2856, Cisco Systems, 979 Inc., BMC Software, Inc., June, 2000. 981 [RFC2863] 982 McCloghrie, K., and F. Kastenholz, "The Interfaces Group MIB", RFC 983 2863, Cisco Systems, Argon Networks, June, 2000. 985 11. Security Considerations 987 There are a number of management objects defined in this MIB that have a 988 MAX-ACCESS clause of read-write and/or read-create. Such objects may be 989 considered sensitive or vulnerable in some network environments. The 990 support for SET operations in a non-secure environment without proper 991 protection can have a negative effect on network operations. 993 There are a number of managed objects in this MIB that may contain 994 sensitive information. These are: 996 hcAlarmAbsValue 997 hcAlarmValueStatus 999 This object may expose the values of particular MIB instances, as 1000 identified by associated instances of the hcAlarmVariable object. 1002 SNMPv1 by itself is not a secure environment. Even if the network 1003 itself is secure (for example by using IPSec), even then, there is no 1004 control as to who on the secure network is allowed to access and GET/SET 1005 (read/change/create/delete) the objects in this MIB. 1007 It is recommended that the implementors consider the security features 1008 as provided by the SNMPv3 framework. Specifically, the use of the User- 1009 based Security Model RFC 2574 [RFC2574] and the View-based Access 1010 Control Model RFC 2575 [RFC2575] is recommended. 1012 It is then a customer/user responsibility to ensure that the SNMP entity 1013 giving access to an instance of this MIB, is properly configured to give 1014 access to the objects only to those principals (users) that have 1015 legitimate rights to indeed GET or SET (change/create/delete) them. 1017 12. Authors' Addresses 1019 Andy Bierman 1020 Cisco Systems, Inc. 1021 170 West Tasman Drive 1022 San Jose, CA USA 95134 1023 Phone: +1 408-527-3711 1024 Email: abierman@cisco.com 1026 Keith McCloghrie 1027 Cisco Systems, Inc. 1028 170 West Tasman Drive 1029 San Jose, CA USA 95134 1030 Phone: +1 408-526-5260 1031 Email: kzm@cisco.com 1033 13. Full Copyright Statement 1035 Copyright (C) The Internet Society (2001). All Rights Reserved. 1037 This document and translations of it may be copied and furnished to 1038 others, and derivative works that comment on or otherwise explain it or 1039 assist in its implementation may be prepared, copied, published and 1040 distributed, in whole or in part, without restriction of any kind, 1041 provided that the above copyright notice and this paragraph are included 1042 on all such copies and derivative works. However, this document itself 1043 may not be modified in any way, such as by removing the copyright notice 1044 or references to the Internet Society or other Internet organizations, 1045 except as needed for the purpose of developing Internet standards in 1046 which case the procedures for copyrights defined in the Internet 1047 Standards process must be followed, or as required to translate it into 1048 languages other than English. 1050 The limited permissions granted above are perpetual and will not be 1051 revoked by the Internet Society or its successors or assigns. 1053 This document and the information contained herein is provided on an "AS 1054 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1055 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1056 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1057 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1058 FITNESS FOR A PARTICULAR PURPOSE.