The EVENT-REPORT operation is used indicated that some change as occurred to a managed object instance that needs to be reported to the manager system. This may be a change of state, or a change in the value of an attribute due to some change in the state of the resource that the managed object instance represents and is reported to enable the manager system to keep up-to-date. It may indicate an alarm that usually requires something needs to be done to rectify the problem.

The EVENT-REPORT operation carries information defined in a NOTIFICATION template. The MANAGED OBJECT CLASS template specifies the notifications that are supported by that managed object class.

The mode of the EVENT-REPORT operation can be either confirmed or unconfirmed

An EVENT-REPORT operation is invoked by the system acting in the agent role. A message is sent using a CMIP INVOKE request from the agent system to the system acting as a manager. The CMIP INVOKE request includes the information defined in the EventReportArgument syntax of the EVENT-REPORT definition.

Unconfirmed Event Report Operation

Usually an EVENT REPORT that indicates a state change, attribute value change, creation and deletion of objects, and relationship changes are unconfirmed. The ITU-T recommends that alarms are confirmed, but many commercial systems that use CMIP only support unconfirmed EVENT REPORTS, including alarms.

Confirmed Event Report Operation

If the operation is successful, the agent system will return a CMIP RESULT response to the manager to indicate that the operation was successful. The CMIP RESULT includes information defined in the EventReportResult syntax of the EVENT-REPORT definition.

If the operation fails, a CMIP ERROR is returned. If an error occurs because the APDU could not be decoded, either due to stack failure or an unrecognised syntax, then a CMIP REJECT is returned to the manager.

Arthur Foster is a

founder member of

Hosted by