Comparing T:LAN and xR3/NN InformRequests
All our Remote Terminal Units families (T:LAN/RIO, xR3 and NEXUS nano) can be programmed to send SNMPv2C InformRequests (traps) to alert up to 4 centrally located monitoring stations (NMS, or EMS).
Over the years we have been enhancing and updating the information carried in these InformRequest PDUs. This article briefly examines the commonalities and differences between the notification formats used by our tried-and-true, as well as our new RTU families.
SNMPv2C InformRequest
Header & Varbinds
| T:LAN/RIO | xR3/NN | |
| version | version | |
| community | community | |
| pduType | pduType | |
| requestID | eLtRequestId | |
| errorStatus | errorStatus | |
| errorIndex | errorIndex | |
| timeStamp | timeStamp | |
| snmpTrapOID | snmpTrapOID | |
| sysLocation | sysLocation | |
| sysName | sysName | |
| reltDateAndTime | eLtDateAndTime | |
| reltNodeID | eLtModuleId | |
| reltNodeName | eLtModuleLabel | |
| reltIOType | eLtIoType | |
| reltTBOSPort | ||
| reltTBOSDisplay | ||
| reltTBOSEquipment | ||
| reltTBOSLabel | ||
| reltIOIndex | eLtIoIndex | |
| reltIOLabel | eLtIoLabel | |
| reltIOSev | eLtIoSeverity | |
| reltIOMappedSev | eLtIoMappedSeverity | |
| reltIOStatus | eLtIoStatus | |
| reltIOValue | eLtIoValue | |
| snmpTrapEnterprise | snmpTrapEnterprise | |
| reltEventType* | eLtEventType | |
| ipAdEntAddr* | netSetConnIpV4Address, or netSetConnIpV6Address | |
| ipNetToMediaPhysAddress** | devConfDeviceSerialNumber | |
| eLtClassCategory | ||
| eLtClassPolicy | ||
| eLtClassEquipment | ||
| eLtClassPowerDomain | ||
| eLtClassLoadShed |
| NOTES: | * starting with T:LAN OS BN7241, ** starting with T:LAN OS BN7370 |
|
| Equivalent. Functionally the same, same origin OID. | ||
| Updated. Functionally the same, sourced from a different origin OID. | ||
| Converted. RIO NODE addressing converted to new xR3/NN MODULE
addressing schema. RIO IO types converted to xR3/NN IO types (superset). |
||
| Deprecated. Limited use TBOS options are no longer supported. | ||
| Enhanced. Device Serial Number is a better choice for source identification, as it will not change based on interface (Ethernet/WiFi/BT etc) used to transmit the notification. |
||
| Added. Additional attributes (optional) to aid AIOps/classifying the notifications. |
Summary
As can be seen from the entries in the preceding table, most SNMPv2C InformRequest elements remained functionally the same or have been updated as we move from our long established hardware architecture (T:LAN/RIO) to the latest RTU families (xR3/NN).
The only portion that was dropped was support for the previously optional TBOS fields. TBOS (Telemetry Byte Oriented Serial) had been in use since the late 1960’s and early 1970’s as a way of relaying mostly radio telemetry. However, its use and importance has declined significantly. Virtually all radios that signaled alarms exclusively via a TBOS interfaces have since been phased out or decommissioned.
We have also taken the opportunity to improve on our long established format, upgrading it where we felt we could do better. The new versions no longer send along the MAC address of the originator (to aid in the precise identification of the alarm source).
As our new RTU families now sport multiple interfaces each with their own unique MAC addresses, we elected to embed the device serial number instead. The serial number is unique and does not vary depending on the interface over which a particular alarm notification happens to be sent out.
New is the section dealing with the optional classification attributes. These aid on the receiving side in sorting, classifying and detecting long term patterns using modern AIOps.
Ralf Doewich
Optima Tele.com, Inc.