ITU-T J 172-2005 IPCablecom management event mechanism (Study Group 9)《IPCablecom中继网关控制协议(TGCP)管理事件机制 研究组9》.pdf

1、 International Telecommunication Union ITU-T J.172TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (11/2005) SERIES J: CABLE NETWORKS AND TRANSMISSION OF TELEVISION, SOUND PROGRAMME AND OTHER MULTIMEDIA SIGNALS IPCablecom IPCablecom management event mechanism ITU-T Recommendation J.172 ITU-T Rec. J.1

2、72 (11/2005) i ITU-T Recommendation J.172 IPCablecom management event mechanism Summary This Recommendation defines the Management Event Mechanism that IPCablecom elements can use to report asynchronous events that indicate malfunction situations and notification about important non-fault situations

3、. Events are defined in this Recommendation as conditions requiring the reporting of information to management systems and/or a local log. A goal of IPCablecom is to maintain consistency with the Cable Modem event-reporting mechanisms. Source ITU-T Recommendation J.172 was approved on 29 November 20

4、05 by ITU-T Study Group 9 (2005-2008) under the ITU-T Recommendation A.8 procedure. ii ITU-T Rec. J.172 (11/2005) FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunications. The ITU Telecommunication Standardization Sector (IT

5、U-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 Standardization Assembly (WTSA), which meets every four

6、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 information technology which fall within ITU-Ts purview, the n

7、ecessary 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 agency. Compliance with this Recommendation is voluntary. How

8、ever, 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 other obligatory language such as “must“ and the negative

9、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 implementation of this Recommendation may involve the use of

10、 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 process. As of the date of approval of this Recommendation, IT

11、U had not received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementors are cautioned that this may not represent the latest information and are therefore strongly urged to consult the TSB patent database. ITU 2006 All r

12、ights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. ITU-T Rec. J.172 (11/2005) iii CONTENTS Page 1 Scope 1 2 References. 1 2.1 Normative references 1 2.2 Informative references 1 3 Terms and Definitions 2 4 Abbreviation

13、s, acronyms and conventions. 2 4.1 Abbreviations and acronyms 2 4.2 Conventions 2 5 Background. 3 6 IPCablecom management event mechanism functional requirements . 3 7 Management event reporting mechanism. 4 7.1 Event notification categories 4 7.2 IPCablecom management event format 5 7.3 IPCablecom

14、management event access method. 5 7.4 Management event ID 6 7.5 Management event severities . 6 7.6 Notification mechanism 6 7.7 Local log of events . 7 7.8 Syslog . 7 7.9 Event throttling. 9 8 IPCablecom management event data template. 10 Annex A IPCablecom-defined provisioning events 11 Annex B IP

15、Cablecom-defined powering events. 14 ITU-T Rec. J.172 (11/2005) 1 ITU-T Recommendation J.172 IPCablecom management event mechanism 1 Scope This Recommendation defines the Management Event Mechanism that IPCablecom elements can use to report asynchronous events that indicate malfunction situations an

16、d notification about important non-fault situations. Events are defined in this Recommendation as conditions requiring the reporting of information to management systems and/or a local log. A goal of IPCablecom is to maintain consistency with the Cable Modem event-reporting mechanisms. 2 References

17、2.1 Normative references The following ITU-T Recommendations and other references contain provisions which, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the editions indicated were valid. All Recommendations and other references are subjec

18、t 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 listed below. A list of the currently valid ITU-T Recommendations is regularly published. The reference to a document wi

19、thin this Recommendation does not give it, as a stand-alone document, the status of a Recommendation. ITU-T Recommendation J.164 (2005), Event message requirements for the support of real-time services over cable television networks using cable modems. ITU-T Recommendation J.166 (2005), IPCablecom M

20、anagement Information Base (MIB) framework. ITU-T Recommendation J.167 (2005), Media terminal adapter (MTA) device provisioning requirements for the delivery of real-time services over cable television networks using cable modems. ITU-T Recommendation M.3100 (2005), Generic network information model

21、. ITU-T Recommendation X.733 (1992), Information technology Open Systems Interconnection Systems Management: Alarm reporting function. IEFT RFC 3164 (2001), The BSD syslog Protocol. 2.2 Informative references ITU-T Recommendation J.160 (2005), Architectural framework for the delivery of time-critica

22、l services over cable television networks using cable modems. ITU-T Recommendation J.168 (2001), IPCablecom Media Terminal Adapter (MTA) MIB requirements. IETF RFC 2573 (1999), SNMP Applications. IETF RFC 2670 (1999), Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS complia

23、nt RF interfaces. ANSI/SCTE 23-3-2003, DOCSIS 1.1 Part 3: Operations Support System Interface. 2 ITU-T Rec. J.172 (11/2005) 3 Terms and Definitions This Recommendation defines no new terms. 4 Abbreviations, acronyms and conventions 4.1 Abbreviations and acronyms This Recommendation uses the followin

24、g abbreviations and acronyms. CMS Call Management Server CMTS Cable Modem Termination System FQDN Fully Qualified Domain Name (Refer to IETF RFC 821 for details.) IANA Internet Assigned Numbers Authority MAC Media Access Control MGC Media Gateway Controller MIB Management Information Base MTA Media

25、Terminal Adapter OSS Operations Support System SNMP Simple Network Management Protocol UDP User Datagram Protocol 4.2 Conventions If this Recommendation is implemented, the keywords “MUST“ and “SHALL“ as well as “REQUIRED“ are to be interpreted as indicating a mandatory aspect of this Recommendation

26、. The keywords indicating a certain level of significance of a particular requirement that are used throughout this Recommendation are summarized below: “MUST“ This word or the adjective “REQUIRED“ means that the item is an absolute requirement of this Recommendation. “MUST NOT“ This phrase means th

27、at the item is an absolute prohibition of this Recommendation. “SHOULD“ This word or the adjective “RECOMMENDED“ means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a d

28、ifferent course. “SHOULD NOT“ This phrase means that there may exist valid reasons in particular circumstances when the listed behaviour is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behaviour described with this l

29、abel. “MAY“ This word or the adjective “OPTIONAL“ means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example, another vendor may omit the same item. ITU-T Rec. J.172 (11/2005) 3 5 Back

30、ground The IPCablecom architecture is an end-end broadband architecture that supports voice, video, and other multimedia services. The individual components that compose the IPCablecom architecture are defined in ITU-T Rec. J.160. The OSS back office contains business, service, and network managemen

31、t components supporting the core business processes. The IPCablecom set of Recommendations defines a limited set of OSS functional components and interfaces to support MTA device provisioning, Event Messaging to carry billing information, and the Management Event Mechanism defined in this Recommenda

32、tion to carry fault and other data. In addition to the Management Event Mechanism, the IPCablecom architecture supports the following additional reporting mechanism: ITU-T Rec. J.164 IPCablecom event messages. This reporting mechanism uses the RADIUS transport protocol, a predefined set of Event Mes

33、sage attributes (e.g. BillingCorrelationID, CalledPartyNumber, TrunkGroupID, etc.), and the IPCablecom Event Messages data format to carry per-call information between IPCablecom network elements (CMS, CMTS, MGC) and a Record Keeping Server (RKS). For each call, the RKS combines all associated Event

34、 Messages into a single Call Detail Record (CDR) which may be sent to a back-office billing, fraud detection or other system. Vendor-proprietary data attributes may be included along with the IPCablecom-defined set of attributes in an IPCablecom Event Message. Other reporting methods. It is possible

35、 that IPCablecom elements implement reporting methods specified in Cable Modem MIBs, IPCablecom MIBs or other standard MIBs. It is possible that IPCablecom elements implement methods such as SNMPv3, CMIP, TL1. These event-reporting mechanisms are not defined in this Recommendation. 6 IPCablecom mana

36、gement event mechanism functional requirements The functional requirements addressed by the message event mechanism Recommendation are as follows: 1) The event report MUST provide either the FQDN or IP address of the reporting device. NOTE 1 It is highly recommended that the device provide the FQDN.

37、 2) The IPCablecom management event reporting mechanism MUST support two types of events: IPCablecom-specific and vendor-specific. 3) The management event reporting mechanism MUST support the IPCablecom Management Event MIB (Annex D/J.166). All the events that can be generated by the IPCablecom devi

38、ce MUST be included in the MIB table pktcDevEventDescrTable. 4) The IPCablecom management event reporting mechanism MUST support the BSD SYSLOG protocol per RFC 3164. 5) The management event reporting mechanism MUST support SNMPv3/v2c TRAPS, SNMPv3/v2c INFORMS. 6) The management event reporting mech

39、anism MUST comply with SNMP Applications (RFC 3413) since these MIBs provide the mechanism for distributing SNMPv3 TRAPS and INFORMS. The elements MUST support a mechanism to allow the element management system to map each event to a reported notification mechanism(s). For example: none, local, SYSL

40、OG, SNMPv3 TRAP, SNMPv3 INFORM. NOTE 2 Refer to the IPCablecom MTA Device Provisioning Recommendation (ITU-T Rec. J.167) for more information about SNMP configuration. 4 ITU-T Rec. J.172 (11/2005) 7) Each event MUST be uniquely identifiable to the point of origin such as a specific endpoint on an MT

41、A. 8) The capability SHOULD exist to map event IDs to priorities in the back office. 9) IPCablecom elements MUST send a timestamp with each management event. 10) IPCablecom elements MUST send a severity level with each management event. Elements MAY use the Severity level within the network element

42、to determine the order in which events are sent. 11) The severity level of management events generated by the network element MUST be modifiable on the IPCablecom element by the management system. 12) The display string of management events generated by the IPCablecom element MUST be modifiable on t

43、he network element by the management system. 13) A default notification mechanism MUST be associated with each event. 14) IPCablecom-specific event definitions SHOULD contain a NULL display string in order to reduce memory requirements on the IPCablecom element. 15) Event definitions MUST contain a

44、display string. 16) Vendor-specific event definitions MAY contain a NULL display string in order to reduce memory requirements on the IPCablecom element. 17) Event throttling mechanism MUST be configurable by the management system. 18) All events are uniquely identified by vendor through the IANA as

45、signed enterprise number. IPCablecom events use the IPCablecom IANA assigned enterprise number. 19) An event MUST provide the Event ID of the event. 7 Management event reporting mechanism The Management Event Mechanism and the associated Management Event Mechanism MIB MUST be implemented on the MTA.

46、 The Management Event Mechanism and the associated Management Event Mechanism MIB MAY be implemented on any IPCablecom element such as the CMS, MGC, and others. 7.1 Event notification categories All events delivered by (event mechanism document) fit into two main categories: IPCablecom-specific; Ven

47、dor-specific. IPCablecom-specific events are defined in this Recommendation and referenced by concerned specifications whereas vendor-specific events are left to vendor implementation and are out of the scope of this Recommendation. Each Event has an associated Event ID as described in the next clau

48、se. IPCablecom-Specific events are identical if their EventIDs are identical. The IPCablecom-Specific EventIDs are specified by the IPCablecom Recommendations, including this Recommendation. For each particular vendor, Vendor-specific events are identical if the corresponding Event IDs are identical

49、. The Vendor-specific EventIDs are defined by particular vendors and are beyond the scope of this Recommendation. Example: Two or more IPCablecom Events with the same Event ID (Say 4000950100) are considered to be identical irrespective of the description or other parameters. ITU-T Rec. J.172 (11/2005) 5 Two or more Vendor-Specific Events, from the same vendor (Say XYZ) with the same Event ID (Say 10) are considered to be identical, irrespective of the description or other parameters. For identical events occurring consecutively, the MTA MAY choose