Open APIs

On Apr 15, 2020 09:15, Suman Bagde wrote:

> For the alarm management API I see alarmedObject as one of the objects. I assume this is the network element on which the alarm has been raised.

The three main entities for an alarm are:
     reportingSystemId (e.g. EMS-1)
     sourceSystemId (e.g. Router-1)
     alarmedObject (e.g. Port-4)

Network elements (NE) may contains thousands of managed objects (MO).

> To gain more information on the affected element, what API needs to be called? Resource API?

Yes, the value of alarmedObject should be a reference to an instance of Resource Inventory available with TMF639.

> Where is the indication of the type of object?

The attribute alarmedObjectType should provide the managed object class (MOC) of the alarmedObject (e.g. ResourceFunction).

> Also for a proactive alarm, what will be the operation? Notification, alarmCreate?

To create an alarm TMF642 supports the POST operation.

> Is there any field to indicate if the alarm is proactive or reactive?

The attribute perceivedSeverity may have the value "warning".

The information describing an alarm can be viewed as starting with alarmType (one of a few enumerated values) and increasing in detail with probableCause, specificProblem, alarmDetails. You should fit your use case into that model.

On Apr 15, 2020 09:15, Suman Bagde wrote:

> For the alarm management API I see alarmedObject as one of the objects. I assume this is the network element on which the alarm has been raised.

The three main entities for an alarm are:
     reportingSystemId (e.g. EMS-1)
     sourceSystemId (e.g. Router-1)
     alarmedObject (e.g. Port-4)

Network elements (NE) may contains thousands of managed objects (MO).

> To gain more information on the affected element, what API needs to be called? Resource API?

Yes, the value of alarmedObject should be a reference to an instance of Resource Inventory available with TMF639.

> Where is the indication of the type of object?

The attribute alarmedObjectType should provide the managed object class (MOC) of the alarmedObject (e.g. ResourceFunction).

> Also for a proactive alarm, what will be the operation? Notification, alarmCreate?

To create an alarm TMF642 supports the POST operation.

> Is there any field to indicate if the alarm is proactive or reactive?

The attribute perceivedSeverity may have the value "warning".

The information describing an alarm can be viewed as starting with alarmType (one of a few enumerated values) and increasing in detail with probableCause, specificProblem, alarmDetails. You should fit your use case into that model.

On Apr 15, 2020 09:15, Suman Bagde wrote:

> For the alarm management API I see alarmedObject as one of the objects. I assume this is the network element on which the alarm has been raised.

The three main entities for an alarm are:
     reportingSystemId (e.g. EMS-1)
     sourceSystemId (e.g. Router-1)
     alarmedObject (e.g. Port-4)

Network elements (NE) may contains thousands of managed objects (MO).

> To gain more information on the affected element, what API needs to be called? Resource API?

Yes, the value of alarmedObject should be a reference to an instance of Resource Inventory available with TMF639.

> Where is the indication of the type of object?

The attribute alarmedObjectType should provide the managed object class (MOC) of the alarmedObject (e.g. ResourceFunction).

> Also for a proactive alarm, what will be the operation? Notification, alarmCreate?

To create an alarm TMF642 supports the POST operation.

> Is there any field to indicate if the alarm is proactive or reactive?

The attribute perceivedSeverity may have the value "warning".

The information describing an alarm can be viewed as starting with alarmType (one of a few enumerated values) and increasing in detail with probableCause, specificProblem, alarmDetails. You should fit your use case into that model.

> For the alarm management API I see alarmedObject as one of the objects. I assume this is the network element on which the alarm has been raised.

Typically, when we receive an alarm from NE/EMS, we would see:
    sender (who sent the alarm)
    agent(who generated the alarm)
After we received the alarm, we would replace them with MO or AMO (affected MO) and add more attributes. Should the alarmedObject be the MO or AMO would be my question on this. My experience is that it should be the MO and the AMO would be what this alarm is affecting, such as another resource or a service instance.

The bigger issue/problem is how to name MO, by device name, IP address, distinguished name, etc.? As we all know, it is impossible to setup a industry wide MO naming standard though distinguished name was kind of standard in ITU side. I personally think it should leave the parties to work out during the integration. So, TMF just specifies it as an octet string.

> To gain more information on the affected element, what API needs to be called? Resource API? Where is the indication of the type of object?

I think that there should be a resource API which is different from inventory API because the FM or PM system most likely will have different set of attributes about the element and their attribute values are closer to real-time compare to inventory. For the type of the object, typically it is the MOC (MO class) in the alarm.
The reason that I would suggest to have Resource API within Alarm Management API or Performance Management API is to avoid complicating FM and PM by mixing Inventory API into them.

> Also for a proactive alarm, what will be the operation? Notification, alarmCreate? Is there any field to indicate if the alarm is proactive or reactive?
By "proactive alarm" I assuming you meant something like TCA (threshold crossing alarm). If so, it normally is indicated by alarm name, alarm type, or other alarm attribute. Sorry, I am not so familiar with SID related to alarm type definition but ITU has defined alarm types like these: equipment, communication, service, environmental. Maybe SID can extend it to have more alarm types. For Alarm Management API, I would suggest to add alarm type field so that it is simpler for caller.

This brings to another topic: for a performance management system, it is most likely to implement and certify Performance Management API. How would users of the API to get the TCA alarms from the PM system through API? We certainly don't want to force PM system to implement Alarm Management API. I think that adding an optional query method similar to the one in Alarm Management API to Performance Management API would be a good choice

On Apr 15, 2020 09:15, Suman Bagde wrote:

> For the alarm management API I see alarmedObject as one of the objects. I assume this is the network element on which the alarm has been raised.

The three main entities for an alarm are:
     reportingSystemId (e.g. EMS-1)
     sourceSystemId (e.g. Router-1)
     alarmedObject (e.g. Port-4)

Network elements (NE) may contains thousands of managed objects (MO).

> To gain more information on the affected element, what API needs to be called? Resource API?

Yes, the value of alarmedObject should be a reference to an instance of Resource Inventory available with TMF639.

> Where is the indication of the type of object?

The attribute alarmedObjectType should provide the managed object class (MOC) of the alarmedObject (e.g. ResourceFunction).

> Also for a proactive alarm, what will be the operation? Notification, alarmCreate?

To create an alarm TMF642 supports the POST operation.

> Is there any field to indicate if the alarm is proactive or reactive?

The attribute perceivedSeverity may have the value "warning".

The information describing an alarm can be viewed as starting with alarmType (one of a few enumerated values) and increasing in detail with probableCause, specificProblem, alarmDetails. You should fit your use case into that model.

Fazhong (David) Deng writes:
> After we received the alarm, we would replace them with MO or AMO (affected MO) and add more attributes. Should the alarmedObject be the MO or AMO would be my question on this. My experience is that it should be the MO and the AMO would be what this alarm is affecting, such as another resource or a service instance.

In TMF6642 the alarmedObject attribute represents the managed object which the alarm condition describes (managed object instance (MOI) of X.733). The affectedService attribute is available to provide correlation to an affected Service domain entity. 

> I think that there should be a resource API which is different from inventory API 

No! However it is likely that the resource inventory management system (implementing TMF639 Resource Inventory API) used by assurance (FM & PM) is distinct from other inventory managers.

> For Alarm Management API, I would suggest to add alarm type field

TMF642 includes the (mandatory) alarmType attribute as an enumerated list conformant with X.733: communicationsAlarm, processingErrorAlarm, environmentalAlarm, qualityOfServiceAlarm, equipmentAlarm, integrityViolation, operationalViolation, physicalViolation, securityService, mechanismViolation, timeDomainViolation.

> This brings to another topic: for a performance management system

New versions of TMF628 Performance Management API and TMF649 Performance Threshold API are under active development now.

> For the alarm management API I see alarmedObject as one of the objects. I assume this is the network element on which the alarm has been raised.

Typically, when we receive an alarm from NE/EMS, we would see:
    sender (who sent the alarm)
    agent(who generated the alarm)
After we received the alarm, we would replace them with MO or AMO (affected MO) and add more attributes. Should the alarmedObject be the MO or AMO would be my question on this. My experience is that it should be the MO and the AMO would be what this alarm is affecting, such as another resource or a service instance.

The bigger issue/problem is how to name MO, by device name, IP address, distinguished name, etc.? As we all know, it is impossible to setup a industry wide MO naming standard though distinguished name was kind of standard in ITU side. I personally think it should leave the parties to work out during the integration. So, TMF just specifies it as an octet string.

> To gain more information on the affected element, what API needs to be called? Resource API? Where is the indication of the type of object?

I think that there should be a resource API which is different from inventory API because the FM or PM system most likely will have different set of attributes about the element and their attribute values are closer to real-time compare to inventory. For the type of the object, typically it is the MOC (MO class) in the alarm.
The reason that I would suggest to have Resource API within Alarm Management API or Performance Management API is to avoid complicating FM and PM by mixing Inventory API into them.

> Also for a proactive alarm, what will be the operation? Notification, alarmCreate? Is there any field to indicate if the alarm is proactive or reactive?
By "proactive alarm" I assuming you meant something like TCA (threshold crossing alarm). If so, it normally is indicated by alarm name, alarm type, or other alarm attribute. Sorry, I am not so familiar with SID related to alarm type definition but ITU has defined alarm types like these: equipment, communication, service, environmental. Maybe SID can extend it to have more alarm types. For Alarm Management API, I would suggest to add alarm type field so that it is simpler for caller.

This brings to another topic: for a performance management system, it is most likely to implement and certify Performance Management API. How would users of the API to get the TCA alarms from the PM system through API? We certainly don't want to force PM system to implement Alarm Management API. I think that adding an optional query method similar to the one in Alarm Management API to Performance Management API would be a good choice

On Apr 15, 2020 09:15, Suman Bagde wrote:

> For the alarm management API I see alarmedObject as one of the objects. I assume this is the network element on which the alarm has been raised.

The three main entities for an alarm are:
     reportingSystemId (e.g. EMS-1)
     sourceSystemId (e.g. Router-1)
     alarmedObject (e.g. Port-4)

Network elements (NE) may contains thousands of managed objects (MO).

> To gain more information on the affected element, what API needs to be called? Resource API?

Yes, the value of alarmedObject should be a reference to an instance of Resource Inventory available with TMF639.

> Where is the indication of the type of object?

The attribute alarmedObjectType should provide the managed object class (MOC) of the alarmedObject (e.g. ResourceFunction).

> Also for a proactive alarm, what will be the operation? Notification, alarmCreate?

To create an alarm TMF642 supports the POST operation.

> Is there any field to indicate if the alarm is proactive or reactive?

The attribute perceivedSeverity may have the value "warning".

The information describing an alarm can be viewed as starting with alarmType (one of a few enumerated values) and increasing in detail with probableCause, specificProblem, alarmDetails. You should fit your use case into that model.