This file is raw output from pdftotext and may not be ideal for distribution. If you are a maintainer for Hackipedia, please sit down when you have time and clean this text version up. Source PDF: /mnt/main/jmc-storage/docs/SCTE/ANSI SCTE 038-02 Hybrid Fiber & Coax Outside Plant Status Monitoring SCTE-HMS-ALARMS-MIB Def (2011).pdf Like all conversions the text below should be fully readable as UTF-8 unicode text. --------------------------------------------------------------- ENGINEERING COMMITTEE Hybrid Management Sub-Layer Subcommittee AMERICAN NATIONAL STANDARD ANSI/SCTE 38-2 2011 Hybrid Fiber/Coax Outside Plant Status Monitoring SCTE-HMS-ALARMS-MIB Management Information Base (MIB) Definition NOTICE The Society of Cable Telecommunications Engineers (SCTE) Standards are intended to serve the public interest by providing specifications, test methods and procedures that promote uniformity of product, interchangeability and ultimately the long term reliability of broadband communications facilities. These documents shall not in any way preclude any member or nonmember of SCTE from manufacturing or selling products not conforming to such documents, nor shall the existence of such standards preclude their voluntary use by those other than SCTE members, whether used domestically or internationally. SCTE assumes no obligations or liability whatsoever to any party who may adopt the Standards. Such adopting party assumes all risks associated with adoption of these Standards or Recommended Practices, and accepts full responsibility for any damage and/or claims arising from the adoption of such Standards or Recommended Practices. Attention is called to the possibility that implementation of this standard may require use of subject matter covered by patent rights. By publication of this standard, no position is taken with respect to the existence or validity of any patent rights in connection therewith. SCTE shall not be responsible for identifying patents for which a license may be required or for conducting inquires into the legal validity or scope of those patents that are brought to its attention. Patent holders who believe that they hold patents which are essential to the implementation of this standard have been requested to provide information about those patents and any related licensing terms and conditions. Any such declarations made before or after publication of this document are available on the SCTE web site at http://www.scte.org. All Rights Reserved © Society of Cable Telecommunications Engineers, Inc. 2011 140 Philips Road Exton, PA 19341 1 Contents 1.  SCOPE 2  2.  COPYRIGHT 2  3.  NORMATIVE REFERENCE 2  4.  INFORMATIVE REFERENCE 2  5.  TERMS AND DEFINITIONS 2  6.  REQUIREMENTS 2  1. Scope This document defines the historical list of alarms detected by the transponder, as well as the SNMP trap generated for these alarms. 2. Copyright The MIB definition found in this document may be incorporated directly in products without further permission from the copyright owner, SCTE. 3. Normative Reference IETF RFC 1155 ANSI/SCTE 37 2010 4. Informative Reference None 5. Terms and Definitions This document defines the following terms: Management Information Base (MIB) - the specification of information in a manner that allows standard access through a network management protocol. 6. Requirements This section defines the mandatory syntax of the SCTE-HMS-ALARMS-MIB. It follows the IETF Simple Network Management Protocol (SNMP) for defining the managed objects. The syntax is given below. 2 -- **************************************************************************** -- * -- * Module Name: HMS023R14.MIB SCTE-HMS-ALARMS-MIB -- * -- * SCTE Status: PUBLISHED -- * -- * Description: This MIB describes the historical list of alarms detected by the transponder, -- * as well as the SNMP trap generated for these alarms. -- * -- * Change: -- * January 2005 Modify hmsAlarmEvent description to allow for additional -- * optional objects. -- **************************************************************************** SCTE-HMS-ALARMS-MIB DEFINITIONS ::= BEGIN IMPORTS TRAP-TYPE FROM RFC-1215 OBJECT-TYPE FROM RFC-1212 DisplayString FROM RFC1213-MIB alarmsIdent FROM SCTE-HMS-ROOTS commonPhysAddress FROM SCTE-HMS-COMMON-MIB commonLogicalID FROM SCTE-HMS-COMMON-MIB scteHmsTree FROM SCTE-ROOT ; alarmLogNumberOfEntries OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The current number of entries in the alarmLogTable." ::= { alarmsIdent 1 } alarmLogLastIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Index of the most recent alarm entry logged in the alarmLogTable." ::= { alarmsIdent 2 } alarmLogTable OBJECT-TYPE SYNTAX SEQUENCE OF AlarmLogEntry ACCESS not-accessible STATUS mandatory DESCRIPTION 3 "A list of alarms that have been logged. Agent should generate generic SNMP HMS trap every time a new alarm entry is logged. This table should support a minimum of 16 entries." ::= { alarmsIdent 3 } alarmLogEntry OBJECT-TYPE SYNTAX AlarmLogEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A set of data describing an alarm event that has been logged." INDEX { alarmLogIndex } ::= { alarmLogTable 1 } AlarmLogEntry ::= SEQUENCE { alarmLogIndex INTEGER, alarmLogInformation OCTET STRING } alarmLogIndex OBJECT-TYPE SYNTAX INTEGER (1..32767) ACCESS read-only STATUS mandatory DESCRIPTION "An index that uniquely identifies an entry in the log table. Indexes are assigned beginning with 1 and increased by one with each new log entry up to 32767. The next entry after 32767 is one. The agent may choose to delete the oldest instances of alarmLogEntry as required because of lack of memory. It is an implementation-specific matter as to when this deletion may occur." ::= { alarmLogEntry 1 } alarmLogInformation OBJECT-TYPE SYNTAX OCTET STRING ( SIZE ( 17..255 ) ) ACCESS read-only STATUS mandatory DESCRIPTION "Alarm information encoded as octet string. Format of this octet is: Octet 1-4: POSIX Time of alarm occurrence (Most significant byte first) Octet 5: Alarm Type (See description below) Octet 6: Contents of commonNeStatus immediately after alarm occurred; Octet 7-m: Alarm Object Identifier (BER encoded) Octet n-z: Alarm value (BER encoded) Alarm Type(Enumerated type): 1 NOMINAL 2 HIHI 4 3 HI 4 LO 5 LOLO 6 Discrete Major 7 Discrete Minor " ::= { alarmLogEntry 2 } alarmText OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS optional DESCRIPTION "This object is mandatory for transponders that are required to report a text field with the trap. This field is a place holder for text that contains the prescribed text as identified by the object description of the item in alarm. This object is therefore volatile and shall not be expected to contain a given value at any specific time. Values returned are of no use. Access is read-only to satisfy SMIv1 requirements. Those objects which should report a name shall be identified as such." ::= { alarmsIdent 4 } hmsAlarmEvent TRAP-TYPE ENTERPRISE scteHmsTree VARIABLES { commonPhysAddress, commonLogicalID, alarmLogInformation } DESCRIPTION "The SNMP trap that is generated when an alarm event is found. At the option of the transponder, the alarmText variable may be reported as a fourth varbind, for those instances where an additional text field is indicated by the object, as noted in the alarmText object description. Also, at the option of the transponder, additional specific varbinds MAY be added to clearly define the event that caused the trap to be sent. In the case where the event is defined in the propertyTable, the additional varbinds (when present) MUST BE the parameterOID object & value and the currentAlarmState object & value (see HMS026) from the table entry for which the trap was generated. In the case where the event is defined in the discretePropertyTable, the additional varbinds (when present) MUST BE the discreteParameterOID object & value and the discreteAlarmState object & value from the table entry for which the trap was generated. The non-optional parameters of the trap (commonPhysAddress, commonLogicalID, alarmLogInformation) MUST still be filled in properly, regardless of whether additional parameters are appended. It is highly recommended that transponders not requiring specific HMS software at the headend include these varbinds in order to assist networks that do not implement HMS-specific SNMP management software. Additionally, though indicated as an option for the transponder, it is 5 recommended that transponders using HMS specified RF transmission (specifically, SCTE 25-1 aka HMS005) SHOULD NOT append these additional parameters, due to the limited bandwidth available in the return path." ::= 1 END 6