ITU-T M 3703-2010 Common management services C Alarm management C Protocol neutral requirements and analysis (Study Group 2)《公共管理业务警报管理协议的中立要求和分析 2号研究组》.pdf

《ITU-T M 3703-2010 Common management services C Alarm management C Protocol neutral requirements and analysis (Study Group 2)《公共管理业务警报管理协议的中立要求和分析 2号研究组》.pdf》由会员分享，可在线阅读，更多相关《ITU-T M 3703-2010 Common management services C Alarm management C Protocol neutral requirements and analysis (Study Group 2)《公共管理业务警报管理协议的中立要求和分析 2号研究组》.pdf（78页珍藏版）》请在麦多课文档分享上搜索。

1、 International Telecommunication Union ITU-T M.3703TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (06/2010) SERIES M: TELECOMMUNICATION MANAGEMENT, INCLUDING TMN AND NETWORK MAINTENANCE Integrated services digital networks Common management services Alarm management Protocol neutral requirements an

2、d analysis Recommendation ITU-T M.3703 ITU-T M-SERIES RECOMMENDATIONS TELECOMMUNICATION MANAGEMENT, INCLUDING TMN AND NETWORK MAINTENANCE Introduction and general principles of maintenance and maintenance organization M.10M.299 International transmission systems M.300M.559 International telephone ci

3、rcuits M.560M.759 Common channel signalling systems M.760M.799 International telegraph systems and phototelegraph transmission M.800M.899 International leased group and supergroup links M.900M.999 International leased circuits M.1000M.1099 Mobile telecommunication systems and services M.1100M.1199 I

4、nternational public telephone network M.1200M.1299 International data transmission systems M.1300M.1399 Designations and information exchange M.1400M.1999 International transport network M.2000M.2999 Telecommunications management network M.3000M.3599 Integrated services digital networks M.3600M.3999

5、Common channel signalling systems M.4000M.4999 For further details, please refer to the list of ITU-T Recommendations. Rec. ITU-T M.3703 (06/2010) i Recommendation ITU-T M.3703 Common management services Alarm management Protocol neutral requirements and analysis Summary Recommendation ITU-T M.3703

6、provides the requirements and analysis for one of the common management services alarm management. The functional requirements for the alarm management interface include the management functions for alarm forwarding and filtering, clearing of alarms, storage and retrieval of alarms in/from the agent

7、, configuration of alarms, alarm acknowledgement and alarm notification failure. In the analysis part, the detailed information model supporting the above functions across the management interface is provided. History Edition Recommendation Approval Study Group 1.0 ITU-T M.3703 2010-06-29 2 Keywords

8、 Agent, alarm management, analysis, fault management, interface, manager, requirements. ii Rec. ITU-T M.3703 (06/2010) FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunications, information and communication technologies (ICT

9、s). The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis. The World Telecommunication

10、Standardization Assembly (WTSA), which meets every four years, establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics. The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA Resolution 1. In some areas of inform

11、ation technology which fall within ITU-Ts purview, the necessary standards are prepared on a collaborative basis with ISO and IEC. NOTE In this Recommendation, the expression “Administration“ is used for conciseness to indicate both a telecommunication administration and a recognized operating agenc

12、y. Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain mandatory provisions (to ensure e.g., interoperability or applicability) and compliance with the Recommendation is achieved when all of these mandatory provisions are met. The words “shall“ or some o

13、ther obligatory language such as “must“ and the negative equivalents are used to express requirements. The use of such words does not suggest that compliance with the Recommendation is required of any party. INTELLECTUAL PROPERTY RIGHTS ITU draws attention to the possibility that the practice or imp

14、lementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside of the Recommendation development proce

15、ss. As of the date of approval of this Recommendation, ITU had not received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementers are cautioned that this may not represent the latest information and are therefore strongly

16、 urged to consult the TSB patent database at http:/www.itu.int/ITU-T/ipr/. ITU 2011 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. Rec. ITU-T M.3703 (06/2010) iii Table of Contents Page 1 Scope 1 2 References.

17、 1 3 Definitions 2 3.1 Terms defined elsewhere 2 3.2 Terms defined in this Recommendation . 2 4 Abbreviations 2 5 Conventions 3 6 Requirements 3 6.1 Concepts and background . 3 6.2 Business-level requirements . 3 6.3 Specification-level requirements 7 7 Analysis 15 7.1 Concepts and background . 15 7

18、.2 Information object classes 16 7.3 Interface definition . 29 Annex A Event Types . 53 Annex B Probable Causes . 54 Appendix I Examples of using notifyChangedAlarm . 63 Appendix II Background information about fault management . 65 II.1 Fault detection 65 II.2 Alarm acknowledgement 66 II.3 Clearing

19、 of alarms 66 II.4 Fault recovery . 67 Bibliography. 69 iv Rec. ITU-T M.3703 (06/2010) Introduction A network is composed of a multitude of network elements (NE) of various types and, typically, different vendors, which interoperate in a coordinated manner in order to satisfy the network users commu

20、nication requirements. The occurrence of failures in a NE may cause a deterioration of this NEs function and/or service quality and will, in severe cases, lead to the complete unavailability of the respective NE. In order to minimize the effects of such failures on the quality of service (QoS) as pe

21、rceived by the network users, it is necessary to: detect failures in the network as soon as they occur and alert the operating personnel as fast as possible; isolate the failures (autonomously or through operator intervention), i.e., switch off faulty units and, if applicable, limit the effect of th

22、e failure as much as possible by reconfiguration of the faulty NE/adjacent NEs; if necessary, determine the cause of the failure using diagnosis and test routines; and repair/eliminate failures in due time through the application of maintenance procedures. This aspect of the management environment i

23、s termed “fault management“ (FM). The purpose of FM is to detect failures as soon as they occur and to limit their effects on the network quality of service (QoS) as far as possible. The latter is achieved by bringing additional/redundant equipment into operation, reconfiguring existing equipment/NE

24、s, or by repairing/eliminating the cause of the failure. Degradation of service may be detected by monitoring 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. Alarms are a specific type of n

25、otification concerning detected faults or abnormal conditions. Managed object definers are encouraged to include in alarms information that will help understand the cause of the potentially abnormal situation, and other information related to side effects. An example of such diagnostic information i

26、s 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 t

27、he relationship between notifications resulting from a single incident is for further study. The functional areas specified in this Recommendation cover: notification of alarms (including alarm cease) and operational state changes; retrieval of current alarms; alarm filtering; management of alarm se

28、verity levels; retention of alarm and operational state data in the NEs and the operations system (OS). Any (re)configuration activities exerted from the element manager (EM) as a consequence of faults is out of the scope of this Recommendation. This Recommendation defines the requirements for fault

29、 management. Rec. ITU-T M.3703 (06/2010) 1 Recommendation ITU-T M.3703 Common management services Alarm management Protocol neutral requirements and analysis 1 Scope This Recommendation defines an interface through which an agent (typically a network element or a network element manager) can communi

30、cate alarm information for its managed objects to one or several managers (typically network management systems). This Recommendation defines the semantics of alarms and the interactions visible across the reference point in a protocol neutral way. It defines the semantics of the operations and noti

31、fications visible on the interface. It does not define the syntax or encoding of the operations, notifications and their parameters. 2 References The following ITU-T Recommendations and other references contain provisions which, through reference in this text, constitute provisions of this Recommend

32、ation. At the time of publication, the editions indicated were valid. All Recommendations and other references are subject to revision; users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references

33、 listed below. A list of the currently valid ITU-T Recommendations is regularly published. The reference to a document within this Recommendation does not give it, as a stand-alone document, the status of a Recommendation. ITU-T M.3020 Recommendation ITU-T M.3020 (2009), Management interface specifi

34、cation methodology. ITU-T M.3100 Recommendation ITU-T M.3100 (1995), Generic network information model. ITU-T M.3160 Recommendation ITU-T M.3160 (2008), Generic, protocol-neutral management information model. ITU-T M.3702 Recommendation ITU-T M.3702 (2010), Common management services Notification ma

35、nagement Protocol neutral requirement and analysis. ITU-T X.701 Recommendation ITU-T X.701 (1997) | ISO/IEC 10040:1998, Information technology Open Systems Interconnection Systems management overview. ITU-T X.721 Recommendation ITU-T X.721 (1992) | ISO/IEC 10165-2:1992, Information technology Open S

36、ystems Interconnection Structure of management information: Definition of management information. ITU-T X.733 Recommendation ITU-T X.733 (1992) | ISO/IEC 10164-4:1992, Information technology Open Systems Interconnection Systems Management: Alarm reporting function. ITU-T X.736 Recommendation ITU-T X

37、.736 (1992) | ISO/IEC 10164-7:1992, Information technology Open Systems Interconnection Systems Management: Security alarm reporting function. ITU-T X.790 Recommendation ITU-T X.790 (1995), Trouble management function for ITU-T applications. 2 Rec. ITU-T M.3703 (06/2010) 3 Definitions 3.1 Terms defi

38、ned elsewhere This Recommendation uses the following terms defined elsewhere: 3.1.1 alarm ITU-T X.733. 3.1.2 agent ITU-T M.3020. 3.1.3 event ITU-T X.790. 3.1.4 error ITU-T X.733. 3.1.5 fault ITU-T X.733. 3.1.6 manager ITU-T M.3020. 3.1.7 notification ITU-T X.701. 3.2 Terms defined in this Recommenda

39、tion This Recommendation defines the following terms: 3.2.1 active alarm: An alarm that has not been cleared and which is active until the fault that caused the alarm is corrected and a “clear alarm“ is generated. 3.2.2 ADAC faults: Faults that are automatically detected and automatically cleared by

40、 the system when they occur and when they are repaired. 3.2.3 ADMC faults: Faults that are automatically detected by the system when they occur and manually cleared by the operator when they are repaired. 3.2.4 alarm notification: Notification used to inform the recipient about the occurrence of an

41、alarm. 3.2.5 clear alarm: Notification used to inform the recipient about the cessation of an alarm and thus the underlying fault condition. 4 Abbreviations This Recommendation uses the following abbreviations: ADAC Automatically Detected and Automatically Cleared ADMC Automatically Detected and Man

42、ually Cleared ASAP Alarm Severity Assignment Profile CO Conditional-Optional DN Domain Name EM Element Manager FM Fault Management FS Function Set IOC Information Object Class M Mandatory MO Managed Object MOC Managed Object Class MOI Managed Object Instance Rec. ITU-T M.3703 (06/2010) 3 NE Network

43、Element NM Network Manager O Optional OS Operations System QoS Quality of Service 5 Conventions This Recommendation uses the conventions defined in ITU-T M.3020 for requirements capture and analysis. 6 Requirements 6.1 Concepts and background Any evaluation of the NEs and the overall network health

44、status requires the detection of faults in the network and, consequently, the notification of alarms to the OS (EM and/or NM). Depending on the nature of the fault, it may be combined with a change of the operational state of the logical and/or physical resource(s) affected by the fault. Detection a

45、nd notification of these state changes is as essential as it is for the alarms. A list of active alarms in the network and operational state information as well as alarm/state history data may be required by the system operator for further analysis. Additionally, test procedures may be used in order

46、 to obtain more detailed information if necessary, or to verify an alarm, a state or the proper operation of NEs and their logical and physical resources. This service uses the following other services and thus implicitly imports all the requirements defined therein: Notification, defined in ITU-T M

47、.3702. 6.2 Business-level requirements Faults that may occur in the network can be grouped into one of the following categories: Hardware failures, i.e., the malfunction of a physical resource within a NE. Software problems, e.g., software bugs, database inconsistencies. Functional faults, i.e., a f

48、ailure of a functional resource in a NE and no hardware component can be found responsible for the problem. Loss of some or all of the NEs specified capability due to overload situations. Communication failures between two NEs, or between NE and OS, or between two OSs. 6.2.1 Requirements 6.2.1.1 Ala

49、rm forwarding and filtering REQ-FM-FUN-01 For each detected fault, the agent shall generate appropriate alarms (notifications of the fault), regardless of whether it is an ADAC or an ADMC fault. Each alarm should be uniquely identified. For each alarm, the agent shall supply the following information: the managed entity; the device/resource/file/functionality/smallest replaceable unit as follows: for hardware faults, the smallest replaceable unit