INTERNATIONAL TELECOMMUNICATION UNION CCITT X.733 THE INTERNATIONAL TELEGRAPH AND TELEPHONE CONSULTATIVE COMMITTEE DATA COMMUNICATION NETWORKS INFORMATION TECHNOLOGY Ð OPEN SYSTEMS INTERCONNECTION Ð SYSTEMS MANAGEMENT: ALARM REPORTING FUNCTION Recommendation X.733 Geneva, 1992 Printed in Switzerland Foreword ITU (International Telecommunication Union) is the United Nations Specialized Agency in the field of telecommunications. The CCITT (the International Telegraph and Telephone Consultative Committee) is a permanent organ of the ITU. Some 166 member countries, 68 telecom operating entities, 163 scientific and industrial organizations and 39 international organizations participate in CCITT which is the body which sets world telecommunications standards (Recommendations). The approval of Recommendations by the members of CCITT is covered by the procedure laid down in CCITT Resolution No. 2 (Melbourne, 1988). In addition, the Plenary Assembly of CCITT, which meets every four years, approves Recommendations submitted to it and establishes the study programme for the following period. In some areas of information technology, which fall within CCITTÕs purview, the necessary standards are prepared on a collaborative basis with ISO and IEC. The text of CCITT Recommendation X.733 was approved on 10thÊofÊFebruary 1992. The identical text is also published as ISO/IEC International Standard 10164-4. _________________ CCITT NOTE In this Recommendation, the expression ÒAdministrationÓ is used for conciseness to indicate both a telecommunication administration and a recognized private operating agency. ‹ÊÊITUÊÊ1992 All rights reserved. No part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from the ITU. Contents Page CCITT NOTE 3 Contents 1 1 Scope 1 2 Normative references 2 2.1 Identical CCITT Recommendations | International Standards 2 2.2 Paired CCITT Recommendations | International Standards equivalent in technical content 2 2.3 Additional references 3 3 Definitions 3 3.1 Basic reference model definitions 3 3.2 Management framework definitions 3 3.3 CMIS definitions 3 3.4 Systems management overview definitions 3 3.5 Event report management function definitions 3 3.6 OSI conformance testing definitions 4 3.7 Additional definitions 4 4 Abbreviations 4 5 Conventions 4 6 Requirements 4 7 Model 5 8 Generic definitions 5 8.1 Generic notifications 5 8.2 Managed objects 11 8.3 Compliance 11 9 Service definition 11 9.1 Introduction 11 9.2 Alarm reporting service 11 10 Functional units 11 11 Protocol 12 11.1Elements of procedure 12 11.2Abstract syntax 13 11.3Negotiation of the alarm reporting functional unit 15 12 Relationships with other functions 15 13 Conformance 15 13.1General conformance class requirements 15 13.2Dependent conformance class requirements 16 ISO/IEC 10165-2 : 1992 (E) INFORMATION NOTE The following table gives a list of X.700 Series Recommendations which were developed in collaboration with the ISO/IEC and are identical to the corresponding International Standard. Cross- references to the corresponding ISO/IEC International Standard number and the short title of the Recommendation | International Standard are provided. CCITT Short Title Recommendation ISO/IEC International Standard X.700 | 7498-4 Management Framework (Note) X.701 | 10040 System Management Overview X.710 | 9595 Common Management Information Service Definition X.711 | 9596-1 Common Management Information Protocol Specification X.712 | 9596-2 CMIP PICS X.720 | 10165-1 Management Information Model X.721 | 10165-2 Definition of Management Information X.722 | 10165-4 Guidelines for the Definition of Managed Objects X.730 | 10164-1 Object Management Function X.731 | 10164-2 State Management Function X.732 | 10164-3 Attributes for Representing Relationships X.733 | 10164-4 Alarm Reporting Function X.734 | 10164-5 Event Management Function X.735 | 10164-6 Log Control Function X.736 | 10164-7 Security Alarm Reporting Function X.740 | 10164-8 Security Audit Trail Function Note Ð This Recommendation and International Standard are not identical, but are technically aligned. INTERNATIONAL STANDARD ISO/IEC 10164-4 : 1992 (E) CCITT Rec. X.733 (1992 E) CCITT RECOMMENDATION INFORMATION TECHNOLOGY Ð OPEN SYSTEMS INTERCONNECTION Ð SYSTEMS MANAGEMENT: ALARM REPORTING FUNCTION 1 Scope This Recommendation | International Standard defines a Systems Management Function that may be used by an application process in a centralized or decentralized management environment to interact for the purpose of systems management, as defined by CCITT Rec. X.700 | ISO/IEC 7498-4. This Recommendation | International Standard defines a function which consists of generic definitions, services and functional units. This function is positioned in the application layer of the OSI reference model (CCITT Rec. X.200 | ISO 7498) and is defined according to the model provided by ISO/IEC 9545. The role of systems management functions is described by CCITT Rec. X.701 | ISO/IEC 10040. The alarm notifications defined by this function provides information that a manager may need to act upon pertaining to a systemÕÕÕÕs operational condition and quality of service. This Recommendation | International Standard Ð establishes user requirements for the alarm reporting function; Ð establishes a model that relates the service and generic definitions provided by this function to user requirements; Ð defines the service provided by the function; Ð defines generic notification types and parameters documented in accordance with CCITT Rec. X.722 | ISO/IEC 10165-4; Ð specifies the protocol that is necessary in order to provide the service; Ð specifies the abstract syntax necessary to identify and negotiate the functional unit in protocol; Ð defines the relationship between this service and SMI notifications; Ð specifies compliance requirements placed on other standards that make use of these generic definitions; Ð defines relationships with other systems management functions; Ð specifies conformance requirements. This Recommendation | International Standard does not Ð define the nature of any implementation intended to provide the Alarm Reporting function; Ð specify the manner in which management is accomplished by the user of the Alarm Reporting function; Ð define the nature of any interactions which result in the use of the Alarm Reporting function; Ð specify the services necessary for the establishment, normal and abnormal release of a management association; Ð preclude the definition of further notification types; Ð define managed objects. 2 Normative references The following CCITT Recommendations and International Standards contain provisions which, through reference in this text, constitute provisions of this Recommendation | International Standard. At the time of publication, the editions indicated were valid. All Recommendations and Standards are subject to revision, and parties to agreements based on this Recommendation | International Standard are encouraged to investigate the possibility of applying the most recent editions of the Recommendations and Standards indicated below. Members of IEC and ISO maintain registers of currently valid International Standards. The CCITT Secretariat maintains a list of the currently valid CCITT Recommendations. 2.1 Identical CCITT Recommendations | International Standards Ð CCITT Recommendation X.701 (1992) | ISO/IEC 10040 : 1992, Information technology Ð Open Systems Interconnection Ð Systems management overview. Ð CCITT Recommendation X.731 (1992) | ISO/IEC 10164-2 : 1992, Information technology Ð Open Systems Interconnection Ð Systems Management Ð State management function. Ð CCITT Recommendation X.732 (1992) | ISO/IEC 10164-3 : 1992, Information technology Ð Open Systems Interconnection Ð Systems Management Ð Attributes for representing relationships. Ð CCITT Recommendation X.7341) | ISO/IEC 10164-5 : 1992, Information technology Ð Open Systems Interconnection Ð Systems Management Ð Event report management function. Ð CCITT Recommendation X.720 (1992) | ISO/IEC 10165-1 : 1992, Information technology Ð Open Systems Interconnection Ð Structure of management information Ð Management information model. Ð CCITT Recommendation X.721 (1992) | ISO/IEC 10165-2 : 1992, Information technology Ð Open Systems Interconnection Ð Structure of management information Ð Definition of management information. Ð CCITT Recommendation X.722 (1992) | ISO/IEC 10165-4 : 1992, Information technology Ð Open Systems Interconnection Ð Structure of Management Information Ð Guidelines for the definition of managed objects. 2.2 Paired CCITT Recommendations | International Standards equivalent in technical content Ð CCITT Recommendation X.7001) , Management framework for Open systems Interconnection (OSI) for CCITT applications. ISO/IEC 7498-4 : 1989, Information processing systems Ð Open Systems Interconnection Ð Basic Reference Model Ð Part 4 : Management framework. Ð CCITT Recommendation X.200 (1988), Reference Model of Open Systems Interconnection for CCITT Applications. ISO 7498 : 1984, Information processing systems Ð Open Systems Interconnection Ð Basic Reference Model. Ð CCITT Recommendation X.208 (1988), Specification of abstract syntax notation one (ASN.1). ISO/IEC 8824 : 1990, Information technology Ð Open Systems Interconnection Ð Specification of Abstract Syntax Notation One (ASN.1). Ð CCITT Recommendation X.210 (1988), Reference Model of Open Systems Interconnection (OSI) Layer Service Definition Conventions for CCITT Applications. ISO/TR 8509 : 1987, Information processing systems Ð Open Systems Interconnection Ð Service conventions. Ð CCITT Recommendation X.710 (1991), Common Management Information Service Definition for CCITT Applications. ISO/IEC 9595 : 1991, Information technology Ð Open Systems Interconnection Ð Common management information service definition. Ð CCITT Recommendation X.290 (1992), OSI Conformance Testing Methodology and Framework for Protocol Recommendations for CCITT Applications Ð General Concepts. ISO/IEC 9646-1 : 1991, Information technology Ð Open Systems Interconnection conformance testing methodology and framework Ð Part 1: General concepts. 2.3 Additional references Ð ISO/IEC 9545 : 1989, Information processing systems Ð Open Systems Interconnection Ð Application Layer structure. 3 Definitions For the purposes of this Recommendation | International Standard, the following definitions apply. 3.1 Basic reference model definitions This Recommendation | International Standard makes use of the following terms defined in CCITT Rec. X.200 | ISOÊ7498. a)open system; b)systems management. 3.2 Management framework definitions This Recommendation | International Standard makes use of the following terms defined in CCITT Rec. X.700 | ISO/IEC 7498-4. managed object 3.3 CMIS definitions This Recommendation | International Standard makes use of the following terms defined in CCITT Rec. X.710 | ISO/IEC 9595. attribute 3.4 Systems management overview definitions This Recommendation | International Standard makes use of the following terms defined in CCITT Rec. X.701 | ISO/IEC 10040. a)agent; b)agent role; c)dependent conformance; d)general conformance; e)generic definitions; f)manager; g)manager role; h)notification; i)systems management application protocol; j)systems management functional unit. 3.5 Event report management function definitions This Recommendation | International Standard makes use of the following terms defined in CCITT Rec. X.734 | ISO/IEC 10164-5. event forwarding discriminator 3.6 OSI conformance testing definitions This Recommendation | International Standard makes use of the following terms defined in CCITT Rec. X.290 | ISO/IEC 9646-1. system conformance statement 3.7 Additional definitions For the purposes of this Recommendation | International Standard, the following definitions apply. 3.7.1error: A deviation of a system from normal operation. 3.7.2fault: The physical or algorithmic cause of a malfunction. Faults manifest themselves as errors. 3.7.3 alarm: A notification, of the form defined by this function, of a specific event. An alarm may or may not represent an error. 3.7.4alarm report: A specific type of event report used to convey alarm information. 4 Abbreviations ASN.1 Abstract Syntax Notation One CMIS Common Management Information Service Conf Confirm Ind Indication MAPDU Management Application Protocol Data Unit Req Request Rsp Response SMAPM Systems Management Application Protocol Machine 5 Conventions This Recommendation | International Standard defines services following the descriptive conventions defined in CCITT Rec. X.210 | ISO/TR 8509. In clauseÊ9, the definition of each service includes a table that lists the parameters of its primitives. For a given primitive, the presence of each parameter is described by one of the following values M the parameter is mandatory (=) the value of the parameter is equal to the value of the parameter in the column to the left U the use of the parameter is a service-user option. Ð the parameter is not present in the interaction described by the primitive concerned. C the parameter is conditional. The condition(s) are defined by the text which describes the parameter. P subject to the constraints imposed on the parameter by CCITT Rec. X.710 | ISO/IEC 9595. NOTE Ð The parameters which are marked ÒPÓ in service tables of this Recommendation | International Standard are mapped directly onto the corresponding parameters of the CMIS service primitive, without changing the semantics or syntax of the parameters. The remaining parameters are used to construct an MAPDU. 6 Requirements The requirements satisfied by this function are the reporting of alarms, errors and related information, in a standard fashion. 7 Model Early detection of faults before significant effects have been felt by the user is a desirable requirement ofÊcommunicating systems. Degradation of service may be detected by monitoring of error rates. Threshold mechanisms on counters and gauges are a method of detecting such trends and providing a warning to managers when the rate becomes high. An important criterion by which failures of communications resources are to be reported is the level to which the fault degrades the quality of the service that was originally requested by (or promised to) the service user. Malfunctions will range in severity from Warning, where there is no impact upon the quality of service offered to the user, to Critical, where it is no longer possible to provide the service requested by (or promised to) the service user. The level of severity can be described generically and criteria specified based upon the level of degradation that the fault causes to the service: Critical, Major, Minor or Warning. Alarms are specific types of notifications concerning detected faults or abnormal conditions. Managed object definers are encouraged to include in alarms information that will help with understanding the cause of the potentially abnormal situation, and other information related to side effects. An example of such diagnostic information is the current and past values of the configuration management state of the object. A single incident may cause the generation of several notifications; it is important to be able to specify in a notification some correlation with other notifications. However, the mechanism, if any, for determining the relationship between notifications resulting from a single incident is outside the scope of this function. It is considered important in some circumstances to provide alarm reports with a standardized style, using a common set of notification types, with standardized parameters and parameter definitions, independent of particular managed objects. The notification types specified in this function are intended to be generally applicable and can be imported into the definition of any managed object. Control of notifications, e.g. whether a notification results in an event report, may be accomplished by use of the Event Report management function defined in CCITT Rec. X.734 | ISO/IEC 10164-5. 8 Generic definitions 8.1 Generic notifications The set of generic notifications, parameters and semantics defined by this Recommendation | International Standard provide the detail for the following general parameters of the M-EVENT-REPORT service as defined by CCITT Rec.ÊX.710 | ISO/IEC 9595 Ð event type; Ð event information; Ð event reply. All notifications are potential entries in a systems management log and this Recommendation | International Standard defines a managed object class for this purpose. CCITT Rec. X.721 | ISO/IEC 10165-2 defines a generic event log record object class from which all entries are derived, the additional information being specified by the event information and event reply parameters. 8.1.1Event type This parameter categories the alarm. Five basic categories of alarm are specified. These are Ð communications alarm type: An alarm of this type is principally associated with the procedures and/or processes required to convey information from one point to another; Ð quality of service alarm type: An alarm of this type is principally associated with a degradation in the quality of a service; Ð processing error alarm type: An alarm of this type is principally associated with a software or processing fault; Ð equipment alarm type: An alarm of this type is principally associated with an equipment fault; Ð environmental alarm type: An alarm of this type is principally associated with a condition relating to an enclosure in which the equipment resides. 8.1.2Event information The following parameters constitute the notification specific information. 8.1.2.1 Probable cause This parameter defines further qualification as to the probable cause of the alarm. Probable cause values for notifications shall be indicated in the behaviour clause of the object class definition. This Recommendation | International Standard defines, for use within the Systems management application context defined in CCITT X.701 | ISO/IEC 10040, standard Probable causes that have wide applicability across managed object classes. These values are registered in CCITT X.721 | ISO/IEC 10165-2. The syntax of standard Probable causes shall be the ASN.1 type object identifier. Additional standard Probable causes, for use within the Systems management application context defined in CCITT X.701 | ISO/IEC 10040, may be added to this Recommendation | International Standard and registered using the registration procedures defined for ASN.1 object identifier values in CCITT Rec. X.208 | ISO/IECÊ8824. Other Probable causes, for use within the Systems management application context defined in CCITT X.701 | ISO/IECÊ10040, may be defined outside of this Recommendation | International Standard and registered using the procedures defined for ASN.1 object identifier values in CCITT Rec. X.208 | ISO/IEC 8824. Probable causes may be defined for use outside of the Systems management application context; the syntax of such Probable causes shall be either an ASN.1 object identifier or ASN.1 type integer. The managed object class definer should choose the most specific Probable cause applicable. This Recommendation | International Standard defines the following Probable causes Ð adapter error; Ð application subsystem failure: A failure in an application subsystem has occurred (an application subsystem may include software to support the Session, Presentation or Application layers); Ð bandwidth reduced: The available transmission bandwidth has decreased; Ð call establishment error: An error occurred while attempting to establish a connection; Ð communications protocol error: A communication protocol has been violated; Ð communications subsystem failure: A failure in a subsystem that supports communications over telecommunications links, these may be implemented via leased telephone lines, by X.25 networks, token-ring LAN, or otherwise; Ð configuration or customization error: A system or device generation or customization parameter has been specified incorrectly, or is inconsistent with the actual configuration; Ð congestion: A system or network component has reached its capacity or is approaching it; Ð corrupt data: An error has caused data to be incorrect and thus unreliable; Ð CPU cycles limit exceeded: A Central Processing Unit has issued an unacceptable number of instructions to accomplish a task; Ð dataset or modem error: An internal error has occurred on a dataset or modem; Ð degraded signal: The quality or reliability of transmitted data has decreased; Ð DTE-DCE interface error: A problem in a DTE-DCE interface, which includes the interface between the DTE and DCE, any protocol used to communicate between the DTE and DCE and information provided by the DCE about the circuit; Ð enclosure door open; Ð equipment malfunction: An internal machine error has occurred for which no more specific Probable cause has been identified; Ð excessive vibration: Vibratory or seismic limits have been exceeded; Ð file error: The format of a file (or set of files) is incorrect and thus cannot be used reliably in processing; Ð fire detected; Ð flood detected; Ð framing error: An error in the information that delimits the bit groups within a continuous stream of bits; Ð heating/ventilation/cooling system problem; Ð humidity unacceptable: The humidity is not within acceptable limits; Ð I/O device error: An error has occurred on the I/O device; Ð input device error: An error has occurred on the input device; Ð LAN error: An error has been detected on a local area network; Ð leak detected: A leakage of (non-toxic) fluid or gas has been detected; Ð local node transmission error: An error occurred on a communications channel between the local node and an adjacent node; Ð loss of frame: An inability to locate the information that delimits the bit grouping within a continuous stream of bits; Ð loss of signal: An error condition in which no data is present on a communications circuit or channel; Ð material supply exhausted: A supply of needed material has been exhausted; Ð multiplexer problem: An error has occurred while multiplexing communications signals; Ð out of memory: There is no program-addressable storage available; Ð output device error: An error has occurred on the output device; Ð performance degraded: Service agreements or service limits are outside of acceptable limits; Ð power problem: There is a problem with the power supply for one or more resources; Ð pressure unacceptable: A fluid or gas pressure is not within acceptable limits; Ð processor problem: An internal machine error has occurred on a Central Processing Unit; Ð pump failure: Failure of mechanism that transports a fluid by inducing pressure differentials within the fluid; Ð queue size exceeded: The number of items to be processed (configurable or not) has exceeded the maximum allowable; Ð receive failure; Ð receiver failure; Ð remote node transmission error: An error occurred on a communication channel beyond the adjacent node; Ð resource at or nearing capacity: The usage of a resource is at or nearing the maximum allowable capacity; Ð response time excessive: The elapsed time between the end of an inquiry and beginning of the answer to that inquiry is outside of acceptable limits; Ð retransmission rate excessive: The number of repeat transmissions is outside of acceptable limits; Ð software error: A software error has occurred for which no more specific Probable cause can be identified; Ð software program abnormally terminated: A software program has abnormally terminated due to some unrecoverable error condition; Ð software program error: An error has occurred within a software program that has caused incorrect results; Ð storage capacity problem: A storage device has very little or no space available to store additional data; Ð temperature unacceptable: A temperature is not within acceptable limits; Ð threshold crossed: A limit (configurable or not) has been exceeded; Ð timing problem: A process that requires timed execution and/or coordination cannot complete, or has completed but cannot be considered reliable; Ð toxic leak detected: A leakage of toxic fluid or gas has been detected; Ð transmit failure; Ð transmitter failure; Ð underlying resource unavailable: An entity upon which the reporting object depends has become unavailable; Ð version mismatch: There is a conflict in the functionality of versions of two or more communicating entities which may affect any processing involving those entities. 8.1.2.2 Specific problems This parameter, when present, identifies further refinements to the Probable cause of the alarm. This parameter qualifies the chosen Probable cause and may be used by the managed object class definer to specify a set of identifiers for use in managed object classes. This parameter is either a set of integers or a set of object identifiers. However, only object identifiers shall be used within the Systems management context defined in CCITT Rec. X.701 | ISO/IEC 10040. Such object identifiers may be registered outside of this Recommendation | International Standard using the registration procedures defined for ASN.1 object identifier values in CCITT Rec. X.208 | ISO/IEC 8824. 8.1.2.3 Perceived severity This parameter defines six severity levels, which provide an indication of how it is perceived that the capability of the managed object has been affected. Those severity levels which represent service affecting conditions ordered from most severe to least severe are Critical, Major, Minor and Warning. The levels defined for use with this mandatory parameter are Ð cleared: The Cleared severity level indicates the clearing of one or more previously reported alarms. This alarm clears all alarms for this managed object that have the same Alarm type, Probable cause and Specific problems (if given). Multiple associated notifications may be cleared by using the Correlated notifications parameter (defined below). This Recommendation | International Standard does not require that the clearing of previously reported alarms be reported. Therefore, a managing system cannot assume that the absence of an alarm with the Cleared severity level means that the condition that caused the generation of previous alarms is still present. Managed object definers shall state if, and under which conditions, the Cleared severity level is used. Ð indeterminate: The Indeterminate severity level indicates that the severity level cannot be determined. Ð critical: The Critical severity level indicates that a service affecting condition has occurred and an immediate corrective action is required. Such a severity can be reported, for example, when a managed object becomes totally out of service and its capability must be restored. Ð major: The Major severity level indicates that a service affecting condition has developed and an urgent corrective action is required. Such a severity can be reported, for example, when there is a severe degradation in the capability of the managed object and its full capability must be restored. Ð minor: The Minor severity level indicates the existence of a non-service affecting fault condition and that corrective action should be taken in order to prevent a more serious (for example, service affecting) fault. Such a severity can be reported, for example, when the detected alarm condition is not currently degrading the capacity of the managed object. Ð warning: The Warning severity level indicates the detection of a potential or impending service affecting fault, before any significant effects have been felt. Action should be taken to further diagnose (if necessary) and correct the problem in order to prevent it from becoming a more serious service affecting fault. 8.1.2.4 Backed-up status This parameter, when present, specifies whether or not the object emitting the alarm has been backed-up, and services provided to the user have, therefore, not been disrupted. The use of this field in conjunction with the severity field provides information in an independent form to qualify the seriousness of the alarm and the ability of the system as a whole to continue to provide services. If the value of this parameter is true, it indicates that the object emitting the alarm has been backed-up; if false, the object has not been backed-up. 8.1.2.5 Back-up object This parameter shall be present when the Backed-up status parameter is present and has the value true. This parameter specifies the managed object instance that is providing back-up services for the managed object about which the notification pertains. This parameter is useful, for example, when the back-up object is from a pool of objects any of which may be dynamically allocated to replace a faulty object. The Back-up object parameter is related to the Back-up object relationship attribute defined in CCITT Rec. X.732 | ISO/IEC 10164- 3. The value of this parameter shall be the same as the Back-up object attribute value when the alarm is emitted. 8.1.2.6 Trend indication This parameter, when present, specifies the current severity trend of the managed object. If present it indicates that there are one or more alarms (Òoutstanding alarmsÓ) which have not been cleared, and pertain to the same managed object as that to which this alarm (Òcurrent alarmÓ) pertains. The Trend indication parameter has three possible values Ð more severe: The Perceived severity in the current alarm is higher (more severe) than that reported in any of the outstanding alarms; Ð no change: The Perceived severity reported in the current alarm is the same as the highest (most severe) of any of the outstanding alarms; Ð less severe: There is at least one outstanding alarm of a severity higher (more severe) than that in the current alarm. In order for Trend indication to be meaningful, the Perceived severity parameter value of each alarm that may be emitted by the managed object must be defined consistently over all of the defined alarm types for that managed object class. Trend indication information is of particular use to managing systems which receive alarm reports from an event forwarding discriminator configured to pass alarms above a Perceived severity level. The severity trend can also be determined by a managing system that monitors the Perceived severity parameter in received alarm reports. The Trend indication parameter shall not be present if there are no outstanding alarms. The absence of the Trend indication parameter cannot be taken to indicate the existence or non-existence of outstanding alarms. 8.1.2.7 Threshold information This parameter shall be present when the alarm is a result of crossing a threshold. It consists of four subparameters Ð triggered threshold: The identifier of the threshold attribute that caused the notification; Ð threshold level: In the case of a gauge the threshold level specifies a pair of threshold values, the first being the value of the crossed threshold and the second, its corresponding hysteresis; in the case of a counter the threshold level specifies only the threshold value. Ð observed value: The value of the gauge or counter which crossed the threshold. This may be different from the threshold value if, for example, the gauge may only take on discrete values. Ð arm time: For a gauge threshold, the time at which the threshold was last re-armed, namely the time after the previous threshold crossing at which the hysteresis value of the threshold was exceeded thus again permitting generation of notifications when the threshold is crossed. For a counter threshold, the later of the time at which the threshold offset was last applied, or the time at which the counter was last initialized (for resettable counters). 8.1.2.8 Notification identifier This parameter, when present, provides an identifier for the notification, which may be carried in the Correlated notifications parameter (see below) of future notifications. Notification identifiers must be chosen to be unique across all notifications of a particular managed object throughout the time that correlation is significant. A Notification identifier may be reused if there is no requirement that the previous notification using that Notification identifier be correlated with future notifications. Generally, Notification identifiers should be chosen to ensure uniqueness over as long a time as is feasible for the managed system. 8.1.2.9 Correlated notifications This parameter, when present, contains a set of Notification identifiers and, if necessary, their associated managed object instance names. This set is defined to be the set of all notifications to which this notification is considered to be correlated. The source object instance shall be present if the correlated event report is from a managed object instance other than the one in which the Correlated notifications parameter appears. The algorithm by which correlation is accomplished is outside the scope of this Recommendation | International Standard. 8.1.2.10 State change definition This parameter, when present, is used to indicate a state transition, as specified in CCITT Rec. X.731 | ISO/IECÊ10164-2, associated with the alarm. In this case, if the managed object class definition includes state change notifications it shall also emit a state change notification as specified in CCITT Rec. X.731 | ISO/IEC 10164-2. 8.1.2.11 Monitored attributes The Monitored attributes parameter, when present, defines one or more attributes of the managed object and their corresponding values at the time of the alarm. Managed object definers may specify the set of attributes which are of interest, if any. This allows, for example, the timely reporting of changing conditions prevalent at the time of the alarm. 8.1.2.12 Proposed repair actions This parameter, when present, is used if the cause is known and the system being managed can suggest one or more solutions (such as switch in standby equipment, retry, replace media). This parameter is a set of possibilities specified by the object class definer. This parameter is either a set of integers or a set of object identifiers. However, only object identifiers shall be used within the Systems management context defined in CCITT Rec. X.701 | ISO/IEC 10040. Such identifiers may be registered using the registration procedures defined for ASN.1 Object Identifier values in CCITT Rec. X.208 | ISO/IECÊ8824. The following note applies to CCITT applications only. NOTE Ð Two values with the following semantics have been assigned to this parameter in this Recommendation | International Standard Ð no repair action required: This value is used to indicate that the manager is not required to initiate any repair action because it is not the managerÕs responsibility; Ð repair action required: This value is used to indicate that the manager is required to initiate repair action to correct the problem reported in the alarm report. This value also indicates that no specific repair action is proposed by the agent system. These values may be used if the cause is known and the system being managed can suggest one or more proposed actions to be taken by the recipient of the alarm report. 8.1.2.13 Additional text This parameter, when present, allows a free form text description to be reported. Understanding the semantics of this field is not required for interpretation of the notification. This Recommendation | International Standard does not specify the format or meaning of the data contained in the Additional text parameter. The contents are not subject to any test of OSI Management conformance. 8.1.2.14 Additional information This parameter, when present, allows the inclusion of a set of additional information in the event report. It is a series of data structures each of which contains three items of information: an identifier, a significance indicator, and the problem information. The identifier subparameter carries a registered object identifier which defines the data type of the information subparameter. The data type must be understood by the managing system in order for the contents of the information subparameter to be parsed. Additional identifiers may be registered using the procedures defined for ASN.1 object identifier values in CCITT Rec. X.208 | ISO/IEC 8824. The significance subparameter is a boolean value which is set to true if the receiving system must be able to parse the contents of the information subparameter for the event report to be fully understood. Even if the Additional information parameter is not fully understood, an event report indication shall be issued to the user. Indication that the Additional information parameter is not fully understood is a local matter. The information subparameter carries information about the event. This information can be parsed if the identifier is understood. 8.1.3Event reply This Recommendation | International Standard does not specify management information to be used in the event reply parameter. 8.2 Managed objects An Alarm record is a managed object class derived from the Event log record object class defined in CCITT Rec.ÊX.721 | ISO/IEC 10165- 2. The Alarm record object class represents information stored in logs as a result of receiving an event report where the event type is one of the alarm types defined in this Recommendation | International Standard. 8.3 Compliance Managed object class definitions support the functions defined in this Recommendation | International Standard by incorporating the appropriate specification of notifications through reference to the notification templates defined in CCITT Rec. X.721 | ISO/IEC 10165- 2. The reference mechanism is defined in CCITT Rec. X.722 | ISO/IEC 10165-4. A managed object class definition importing one or more of the alarms defined in this Recommendation | International Standard is required, for each use of an alarm, to select the alarm type and probable cause that most closely specifies the real event in the managed object. If the managed object class specifies more than one event for a particular combination of alarm type and probable cause, the Specific problems parameter may be used to uniquely identify the event. The Additional text parameter may be used to identify and communicate additional or more specific alarm information. However, the preferred method is by registration and use of additional values for the Probable cause and/or Specific problems and/or Additional information parameters. The Additional information parameter may include diagnostic information and other information relating to the alarm. However, information which can be mapped to the other parameters provided by this Recommendation | International Standard (excepting Additional text) should not be reported using the Additional information parameter. 9 Service definition 9.1 Introduction This Recommendation | International Standard defines one service which is identified below together with the appropriate parameters. The alarm reporting service allows one user to notify another user of an alarm detected in a managed object. The originating user has to specify whether or not a reply is required. Further parameters convey the identification of the managed object, the type and time of the alarm, and other relevant management information. 9.2 Alarm reporting service The alarm reporting service uses the parameters defined in clause 8 of this Recommendation | International Standard in addition to the general M-EVENT-REPORT service parameters defined in CCITT Rec. X.710 | ISO/IEC 9595. Table 1 lists the parameters for the alarm reporting service. The Event time, Correlated notifications, and Notification identifier parameters may be assigned by the object emitting the notification or by the managed system. If no Perceived severity is defined for an object class the value shall be assigned by the managed system. The managed system may assign the Trend indication value if the managed object policy allows system assignment of Perceived severity. 10 Functional units The Alarm reporting function forms a single systems management functional unit. Table 1 Ð Alarm reporting parameters Parameter name Req/In Rsp/Co d nf Invoke P P identifier Mode P Ð Managed object P P class Managed object P P instance Event type M C(=) Event time P Ð Event information Probable M Ð cause Specific U Ð problems Perceived M Ð severity Backed-up U Ð status Back-up C Ð object Trend U Ð indication Threshold C Ð information U Ð Notification identifier Correlated U Ð notifications State U Ð change definition Monitored U Ð attributes Proposed U Ð repair actions Additional U Ð text Additional U Ð information Current time Ð P Event reply Ð Ð Errors Ð P 11 Protocol 11.1 Elements of procedure 11.1.1 Agent role 11.1.1.1 Invocation The alarm reporting procedures are initiated by the alarm reporting request primitive. On receipt of an alarm reporting request primitive, the SMAPM shall construct an MAPDU and issue a CMIS M- EVENT-REPORT request service primitive with parameters derived from the alarm reporting request primitive. In the non-confirmed mode, the procedure in 11.1.1.2 does not apply. 11.1.1.2 Receipt of response On receipt of a CMIS M-EVENT-REPORT confirm service primitive containing an MAPDU responding to an alarm reporting notification, the SMAPM shall issue an alarm reporting confirmation primitive to the alarm reporting service user with parameters derived from the CMIS M-EVENT-REPORT confirm service primitive, thus completing the alarm reporting procedure. NOTE Ð The SMAPM shall ignore all errors in the received MAPDU. The alarm reporting service user may ignore such errors, or abort the association as a consequence of such errors. 11.1.2 Manager role 11.1.2.1 Receipt of request On receipt of a CMIS M-EVENT-REPORT indication service primitive containing an MAPDU requesting the alarm reporting service, the SMAPM shall, if the MAPDU is well formed, issue an alarm reporting indication primitive to the alarm reporting service user with parameters derived from the CMIS M-EVENT-REPORT indication service primitive. Otherwise, the SMAPM shall, in the confirmed mode, construct an appropriate MAPDU containing notification of the error, and shall issue a CMIS M-EVENT-REPORT response service primitive with an error parameter present. In the non-confirmed mode, the procedure in 11.1.2.2 does not apply. 11.1.2.2 Response In the confirmed mode, the SMAPM shall accept an alarm reporting response primitive and shall construct an MAPDU confirming notification and issue a CMIS M-EVENT-REPORT response service primitive with parameters derived from the alarm reporting response primitive. 11.2 Abstract syntax 11.2.1 Managed objects This Recommendation | International Standard references the following support object for which the abstract syntax is specified in CCITT Rec. X.721 | ISO/IEC 10165-2 Ð alarmRecord. 11.2.2 Attributes Table 2 identifies the relationship between the parameters defined in 8.1.2 of this Recommendation | International Standard and the attribute types specifications in CCITT Rec. X.721 | ISO/IEC 10165- 2. Table 2 Ð Attributes Parameter Attribute name Probable cause probableCause Specific specificProble problems ms Perceived perceivedSever severity ity Backed-up backedUpStatus status Back-up object backupObject Trend trendIndicatio indication n Threshold thresholdInfo information Notification notificationId identifier entifier Correlated correlatedNoti notifications fications State change stateChangeDef definition inition Monitored monitoredAttri attributes butes Proposed proposedRepair repair actions Actions Additional additionalText text Additional additionalInfo information rmation 11.2.3 Attribute groups There are no attribute groups defined by this Recommendation | International Standard. 11.2.4 Actions There are no specific actions defined by this Recommendation | International Standard. 11.2.5 Notifications Table 3 identifies the relationship between the notifications defined in 8.1.1 of this Recommendation | International Standard and the notification type specifications in CCITT Rec. X.721 | ISO/IEC 10165-2. Table 3 Ð Notifications Alarm type Notification type Communications communications alarm Alarm Quality of qualityofServi service alarm ceAlarm Processing processingErro error alarm rAlarm Equipment equipmentAlarm alarm Environmental environmentalA alarm larm 11.2.6 Probable causes Table 4 identifies the relationship between the Probable causes defined in 8.1.2.1 of this Recommendation | International Standard and the ASN.1 value references defined in CCITT Rec. X.721 | ISO/IEC 10165-2. 11.2.7 Perceived severity values Table 5 identifies the relationship between the values defined for the Perceived severity in 8.1.2.3 of this Recommendation | International Standard and the ASN.1 value references defined in CCITT Rec. X.721 | ISO/IECÊ10165-2. Table 5 Ð Perceived severity values Perceived ASN.1 value severity reference Cleared cleared Indeterminate indeterminate Critical critical Major major Minor minor Warning warning Table 4 Ð Probable causes Probable cause name DMI value reference Adapter error adapterError Application subsystem applicationSubsystemFail failure ure Bandwidth reduced bandwidthReduced Call establishment error callEstablishmentError Communications protocol communicationsProtocolEr error ror Communications subsystem communicationsSubsystemF failure ailure Configuration or configurationOrCustomiza customization error tionError Congestion congestion Corrupt data corruptData CPU cycles limit cpuCyclesLimitExceeded exceeded Dataset or modem error datasetOrModemError Degraded signal degradedSignal DTE-DCE interface error dTE-DCEInterfaceError Enclosure door open enclosureDoorOpen Equipment malfunction equipmentMalfunction Excessive vibration excessiveVibration File error fileError Fire detected fireDetected Flood detected floodDetected Framing error framingError Heating/ventilation/cool heatingOrVentilationOrCo ing olingSystemProblem Humidity unacceptable humidityUnacceptable I/O device error inputOutputDeviceError Input device error inputDeviceError LAN error lANError Leak detected leakDetected Local node transmission localNodeTransmissionErr error or Loss of frame lossOfFrame Loss of signal lossOfSignal Material supply materialSupplyExhausted exhausted Multiplexer problem multiplexerProblem Out of memory outOfMemory Output device error outputDeviceError Performance degraded performanceDegraded Power problem powerProblem Pressure unacceptable pressureUnacceptable Processor problem processorProblem Pump failure pumpFailure Queue size exceeded queueSizeExceeded Receive failure receiveFailure Receiver failure receiverFailure Remote node transmission remoteNodeTransmissionEr error ror Resource at or nearing resourceAtOrNearingCapac capacity ity Response time excessive responseTimeExcessive Retransmission rate retransmissionRateExcess excessive ive Sofware error sofwareError Sofware program sofwareProgramAbnormally abnormally terminated Terminated Sofware program error softwareProgramError Storage capacity problem storageCapacityProblem Temperature unacceptable temperatureUnacceptable Threshold crossed thresholdCrossed Timing problem timingProblem Toxic leak detected toxicLeakDetected Transmit Failure transmitFailure Transmitter Failure transmitterFailure Underlying resource underlyingResourceUnavai unavailable lable Version mismatch versionMismatch 11.3 Negotiation of the alarm reporting functional unit This Recommendation | International Standard assigns the following object identifier {joint-iso-ccitt ms(9) function(2) part4(4) functionalUnitPackage(1)} as a value of the ASN.1 type FunctionalUnitPackageId defined in CCITT Rec. X.701 | ISO/IEC 10040 for negotiating the following functional unit 0 alarm reporting functional unit where the number identifies the bit position assigned to the functional unit, and the name references the functional unit as defined in clauseÊ10. Within the Systems management application context, the mechanism for negotiating the alarm reporting functional unit is described by CCITT Rec. X.701 | ISO/IEC 10040. NOTE Ð The requirement to negotiate functional units is specified by the application context. 12 Relationships with other functions Control of the alarm reporting service is provided by mechanisms specified in CCITT Rec. X.734 | ISO/IEC 10164-5. The alarm reporting service may exist independently of the control mechanisms of CCITT REC. X.734 | ISO/IECÊ10164-5. The notifications defined by this function may report instances of the back-up relationship as defined in CCITT Rec.ÊX.732 | ISO/IEC 10164-3. 13 Conformance There are two conformance classes; general conformance class and dependent conformance class. A system claiming to implement the elements of procedure for the systems management services defined in this Recommendation | International Standard shall comply with the requirements for either the general or the dependent conformance class as defined in the following clauses. The supplier of the implementation shall state the class to which conformance is claimed. 13.1 General conformance class requirements A system claiming general conformance shall support this function for all managed object classes that import the management information defined in this Recommendation | International Standard. 13.1.1 Static conformance The system shall a)act in the role of manager or agent or both with respect to the alarm reporting functional unit; b)support the transfer syntax derived from the encoding rules specified in CCITT Rec. X.209 | ISO/IECÊ8825 and named {joint-iso-ccitt asn1(1) basic encoding(1)}, for the purpose of generating and interpreting the MAPDUs defined by the abstract data types referenced in 11.2.5 of this Recommendation | International Standard. 13.1.2 Dynamic conformance The system shall, in the role(s) for which conformance is claimed, support the elements of procedure defined in this Recommendation | International Standard for the alarm reporting service. 13.2 Dependent conformance class requirements 13.2.1 Static conformance The system shall a)supply a system conformance statement which identifies the standardized use of this Recommendation | International Standard; b)support the transfer syntax derived from the encoding rules specified in CCITT Rec. X.209 | ISO/IECÊ8825 and named {joint-iso-ccitt asn1(1) basic encoding(1)}, for the purpose of generating and interpreting the MAPDUs, defined by the abstract data types referenced in 11.2.5 of this Recommendation | International Standard, as required by a standardized use of this Recommendation | International Standard. 13.2.2 Dynamic conformance The system shall support the elements of procedure, defined in this Recommendation | International Standard, required by a standardized use of this Recommendation | International Standard. Annex A Example Probable cause usage (This Annex does not form an integral part of this Recommendation | International Standard) This informative annex shows meaningful combinations of Probable causes and alarm types. Alarm type Probable cause Communications Loss of signal Loss of frame Framing error Local node transmission error Remote node transmission error Call establishment error Degraded signal Communications subsystem failure Communications protocol error LAN error DTE-DCE interface error Quality of service Response time excessive Queue size exceeded Bandwidth reduced Retransmission rate excessive Threshold crossed Performance degraded Congestion Resource at or nearing capacity Processing error Storage capacity problem Version mismatch Corrupt data CPU cycles limit exceeded Software error Software program error Software program abnormally terminated File error Out of memory Underlying resource unavailable Application subsystem failure Configuration or customization error Equipment Power problem Timing problem Processor problem Dataset or modem error Multiplexer problem Receiver failure Transmitter failure Receive failure Transmit failure Output device error Input device error I/O device error Equipment malfunction Adapter error Environmental Temperature unacceptable Humidity unacceptable Heating/ventilation/c ooling system problem Fire detected Flood detected Toxic leak detected Leak detected Pressure unacceptable Excessive vibration Material supply exhausted Pump failure Enclosure door open _______________________________ 1) Presently at state of draft Recommendation.