by Tony Peterle, manager of Worldcast Systems Inc. in Miami, FL
February 2021
Without question, the introduction of IP network systems into broadcast operations has had a generational impact on our industry.
Audio distribution (both in-house and across the Internet), IBOC/DTV broadcasts and Internet streaming are some of the ways IP networks have become essential in broadcast operations, and ATSC 3.0 is taking networked data on to the actual broadcast signal.
Along with new ways to reach our customers, IP networks offer benefits for engineers, like remote equipment management, reduced time and complexity of studio builds using AoIP, and TeamViewer connections with manufacturer support personnel.
And along with the more familiar interfaces with networked equipment, like embedded websites or Telnet links, many networked devices support the Simple Network Management Protocol. The SNMP standard is a set of rules that defines certain data points, or objects, in a piece of equipment that is connected to an IP network. The protocol establishes a standard syntax that allows users to query that equipment via the network and receive the real-time values of those data objects. And in certain cases, the user can even change those values using SNMP, which can allow them to control the functions or settings of that equipment.
This paper will attempt to explain at least the basics of the SNMP structure and capabilities, and how broadcast technical personnel could benefit by integrating the SNMP protocol into their overall facility control and management systems.
The Simple Network Management Protocol was developed during the late 1980s as a way to facilitate communications with and control of distant network devices as the Internet was burgeoning. At the time, there were many protocols used to communicate with and control the routers and other network infrastructure. Around 1987, the protocol we know as SNMP was chosen by the market as a unified and efficient way to communicate with the hardware.
The earliest version of SNMP was called V1. Currently, the most commonly used versions are V2c, which added some new commands, and V3, which applies a somewhat more secure process to send the SNMP data back and forth across the network.
To clear a semantic point, the terms “Manager” and “Agent” refer specifically to the software modules running in each device that enable and support the transfer of data using SNMP, but for the purposes of this paper, the terms are applied equally to the hardware and software on each end of an SNMP message. Also keep in mind that the device running the Manager application can also itself be an Agent, managed either by its own internal NMS software or perhaps by another Manager system elsewhere on the network. A Manager will normally send SNMP requests to the Agent on IP port 161.
SNMP is simply a way to retrieve and set data points in a remote system. These data points, called Objects, are defined by the maker of that system, usually at the time of manufacture. The type of data presented by an SNMP object is very flexible ‒ it could be an integer, a floating-point number, even a text/numeric string. Each Object has a unique identifying number, which is used by the Manager and Agent systems to locate and deliver the requested data to the user. These numbers are called Object Identifiers, or OIDs. A Manager will use the OID to request data from an Agent, and the Agent, in its response to the request, will include that same number along with its current value. The OID is also used when the Manager device sends a SET command to change the value of a data point in the Agent, and also on those rare occasions when the Agent device is the one to initiate communications.
Object Identifiers are written with a specific (and rather old) syntax called Abstract Syntax Notation One, or ASN-1. A typical OID might look like this: 1.3.6.1.4.1.186.1.19.2.1.2.4.0
When a device with an SNMP Agent is manufactured, the designers will usually organize all of the OIDs for that device into a structured text file, called the Management Information Base, or MIB (see Fig. 2). The MIB can be viewed as a “menu” that a user of NMS software can use to browse to and identify the OIDs associated with the desired data points in that Agent device. There are many software applications, called MIB Browsers, that will allow a user to examine these files, and most browsers display the MIB as a directory-tree type structure.
There are some exceptions. As we will see, some OIDs cannot be completely defined at the time of manufacture, and some makers of Agent equipment publish only “truncated” MIBs that refer to industry standard files (other MIBs or RFC files) to define their own structure and OIDs. More in a moment.
The commands and messages that pass between the Manager and Agent devices can be divided into three categories: GET commands, SET commands and TRAP messages.
SET commands are perhaps the simplest. They are messages sent from the Manager device to the Agent, containing the OID for a particular data point, and the desired value to be set for that point. This is the way a Manager can command the remote device to enable or disable functions or change a value, such as the frequency setting of a transmitter. No matter if the value of that particular object is an integer, a floating-point number, even a text/numeric string; the SET command is used in the same way each time.
The TRAP messages also are simple. They are unique in that they are generated autonomously by the Agent and sent to the Manager. As you might guess from this characteristic, they generally are used to alert the Manager (and its users) to abnormal conditions in the Agent device that could negatively impact the performance or stability of the system. Put simply, they are alarms. High CPU temperature, RF output failure, a hard drive approaching full status — these are examples of some of the conditions for which SNMP Agents might send a TRAP message to a Manager.
Since SNMP was designed in the early days of connectivity, minimizing bandwidth usage was a high priority, which is why there is no default automatic acknowledgement for SNMP messages. However, the critical nature of TRAP messages has led many designers of SNMP Agent software to include optional settings that will cause the Agent to resend the TRAP message until the Manager replies that the message has been received and understood. It is important to know that this acknowledgement handshake must also be supported by the NMS software. The standard port on which a Manager will “listen” for traps is IP port 162.
The GET command is certainly the most-used in SNMP systems. A Manager will send a GET command containing a specific OID to an Agent, and the Agent will “look up” the current value for that data point. It will then send that value in a message called a GETRESPONSE that also repeats the OID.
All versions of SNMP support these message types, as well as the GETNEXT command. GETNEXT is a command that, when repeated, will cause the Agent to methodically research and deliver data on each and every object that has been defined within its configuration (see Table 1). In some Agent systems, data is defined in tables — for example, the connection status and speed of each port on a router. For these types of systems, the GETNEXT command is an easy way to retrieve a large number of data points without having to write multiple GET commands, each with the specific OID of a single object in the Agent. When the Agent returns a response to the Manager, the Manager can issue another GETNEXT, which causes the Agent to look up and deliver data on the next OID in its MIB.
An additional GET command, GETBULK, was introduced in SNMP V2c and is also supported by version 3. The GETBULK command allows an NMS to request from the agent a large portion of a data table with one command. Again, this is done to minimize the need to send GET commands for each data point and so minimize the demands on programmers and network bandwidth.
The GETNEXT and GETBULK commands are used primarily for SNMP analysis and design by human operators, they have little to no use in a 24/7 monitoring system.
For each GET command received from a Manager system, the Agent device will return a GETRESPONSE. Or in cases where the structure of the GET command is improper, the Agent might return an error message.
There are several other types of SNMP messages that were defined in the V2c and V3 standards, including INFORM, NOTIFICATION and REPORT.
INFORM is the mechanism by which an NMS can acknowledge SNMP Traps sent by an Agent. A NOTIFICATION is a variation on the SNMP TRAP message, created to share the same data structure as the GET and SET commands (the original TRAP messages as defined in V1 had a different structure). And the REPORT message is designed to allow different NMS systems on a network to communicate easily with one another about the status of the devices and network segments each is monitoring. INFORM V2c messages are the most common alarm messages used today, and although they don’t have the same data structure of the original V1 alarm messages, they are still commonly called TRAPS.
SNMP communications can be carried out via a number of different transport protocols, but typically employ the User Datagram Protocol, or UDP, a simplex protocol with no built-in confirmation of messages traveling in either direction. UDP is a Transport protocol, operating in Layer 4 of the OSI model. SNMP itself operates in the Application layer 7. UDP allows systems to communicate with each other without having to first establish communications ports and protocols.
Since an SNMP message (particularly the GETRESPONSE) can contain different amounts of data, they cannot be a fixed length. Instead, the data are defined as variable bindings. An SNMP message packet follows the basic encoding rules, and the data contained in the variable bindings can be divided into three parts: Type, Length and Data.
Type is a single byte that specifies the type of data being transported — Octet, Integer, String, etc. Length delineates the size or amount of data, in bytes; and Data is of course the data itself. It is noteworthy that the data can span multiple bytes (see Fig. 3). In such cases, the highest order bit is used as a flag to indicate that the data is being spread into two or more bytes, and only the lower 7 bits are actual data.
A message in SNMP will contain three elements — the SNMP version being used (V1, V2c or V3), the Community string, (or username and password for V3 messages) and finally the SNMP function itself — be it a SET request, a GET Response, TRAP, etc. This central part of the message is called the Protocol Data Unit, or PDU. The Community string is like a password that must be used to retrieve or set data points using SNMP (from V2c on). This is absolutely no guarantee of security, as the strings are sent using open text on the network, so it would be comically easy for someone to intercept and read that information. SNMP version 3 offers some more robust security, with data encryption and stronger passwords.
When we look at an OID, we’re really seeing an address — a way to navigate through a MIB tree until we arrive at the specific data point in which we are interested. But the OID starts from a much broader viewpoint. To understand this perspective, we should examine the meaning of each of the numbers in a typical OID, for example:
1.3.6.1.4.1.186.1.19.2.1.2.4.0
The first six numbers in the OID will be the same for most OIDs in nearly every commonly encountered object. They are intended to allow traceability of the OID, as follows:
1 – Identifies the International Standards Organization, or ISO
3 – Specifies that this OID belongs to an ISO recognized organization
6 – Indicates the Department of Defense, creator of the Internet
1 – Confirms that this is an Internet OID
4 – Shows that this OID belongs to a private organization
1 – Tells us that this organization is a business enterprise
The next number identifies the manufacturer of the equipment to which this OID refers. In this instance, the 186 refers to Toshiba; this OID comes from a Toshiba UPS power system (see Fig. 4).
After the manufacturer number, the remaining numbers delineate a path down the manufacturer’s MIB tree for that device. Each branch of that tree has a number assigned to it and by following the numbers down the MIB we come to the object specified by this OID. After the manufacturer number 186, the 1 says it belongs to a piece of Toshiba equipment, the 19 indicates a Toshiba UPS system, the 2 specifies the Toshiba Industrial line of said systems, and the 1 identifies the particular software. This same software (and thus the same MIB) could be in use on any number of different models.
The SNMP name of the data object is upsEstimatedChargeRemaining, and from the description in the MIB browser we can see that it is an Integer type data point, from 0 to 100. In raw text form, the OID definition in the MIB would look like this:
upsEstimatedChargeRemaining OBJECT-TYPE
SYNTAX INTEGER(0..100)
UNITS “percentage”
ACCESS read-only
STATUS mandatory
DESCRIPTION
“An estimate of the charge to battery charge depletion
under the present load conditions if the utility power
is off and remains off, or if it were to be lost and
remain off”
::= { upsBattery 4 }
Note that the full OID is not present in the MIB file, only upsBattery 4. This is an example of a “Truncated” MIB. Truncating is used by manufacturers to avoid having to write complete OID numbers for each data point in the equipment with the associated costs in man hours and possible errors. So the OID is defined by naming the ‘branch’ of the MIB that contains this data point, plus an integer to define the specific data point in that branch.
By examining the beginning of the Toshiba MIB, we can see that a number of ‘imports’ are described:
DisplayString, TimeStamp, TimeInterval, TestAndIncr, AutonomousType
FROM SNMPv2-TC
enterprises
FROM RFC1155-SMI
OBJECT-TYPE
FROM RFC-1212
TRAP-TYPE
FROM RFC-1215;
SNMPv2-TC, RFC1155-SMI, RFC-1212 and RFC-1215 are “standard” of “community” MIBs published by the IETP and ISO that organize basic structural elements and methods such as data types, table structures, definitions, etc. By incorporating these standard files into their own MIB structures, manufacturers help ensure compliance with the standards while also saving themselves from having to write the full syntax of each OID in the MIB files for their equipment. As long as your browser or NMS software can import and integrate these standard MIBs, it should remain relatively easy to locate and use the OIDs you need.
An example of an OID from a different MIB (this one from an APT Horizon audio codec), looks like this:
1.3.6.1.4.1.22425.2.1.4
alarmTrap NOTIFICATION-TYPE
OBJECTS { sequenceNo, name, status }
STATUS current
DESCRIPTION
“This trap is sent when an alarm is either
set or cleared on the unit. The variable
bindings which are sent are:-
Sequence No
Alarm Name
Status of alarm.
“
::= { horizonalarm 4 }
Note that while this MIB uses a truncated OID, the designers have included the full OID as a comment line before the object description, preceded by the double dash –. This convention helps make the MIB more legible to the human readers.
Regardless of structure, the MIB file serves only to indicate the correct OIDs for each data point. An address book, or map, if you like. If there is another way to obtain accurate OIDs, the MIB file itself may be unnecessary.
In many instances, the OIDs for a particular system can be defined and the MIB file published at the time of manufacture.
There are notable exceptions to this rule, such as systems where data objects can be created by the user after the equipment is delivered. One example group are facility control systems, where inputs, controls and analog information can all be integrated, polled and controlled by remote equipment using SNMP. Since the inputs and controls are sometimes software based, they can be created and altered as needed by the user, so their OIDs cannot be completely defined when the equipment is built.
For these types of data objects, two things are defined, the first being a “base” OID, which identifies a class of object (say a reading from an analog voltage input) in the software. Second, a table is built into that definition in the MIB that will allow something called an Index value to be appended to the base OID. Together, the base + Index value can identify a specific object in the Agent, even one that was created only moments ago.
As an example, here is the “base” definition of a user created button in Worldcast Systems’ Scripteasy software:
1.3.6.1.4.1.5299.15.42.1.10.3.4.1.3 : scripteasyActionsState
scripteasyActionsState OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
“No description”
::= { scripteasyActionsEntry 3 }
Just above that definition of the base OID, the MIB file defines the Index table:
1.3.6.1.4.1.5299.15.42.1.10.3.4.1.1 : scripteasyActionsidScriptObject
scripteasyActionsidScriptObject OBJECT-TYPE
SYNTAX INTEGER (0..2147483647)
ACCESS read-only
STATUS mandatory
DESCRIPTION
“Scripteasy action button identifierr”
::= { scripteasyActionsEntry 1 }
As each button is created in the software, a specific Index number is assigned to it and made visible to the user. So while the base OID for ‘a’ button in the software would look like this:
1.3.6.1.4.1.5299.15.42.1.10.3.4.1.3
The OID for a specific button would append the index value at the end:
1.3.6.1.4.1.5299.15.42.1.10.3.4.1.3.361
When we begin to formulate a plan to incorporate SNMP monitoring and control within a broadcast facility, we must remember that this protocol comes from the world of computers and IT, and thus we must be able to correctly interpret the information before we can use it.
In most cases, the object description in the MIB will give some indication. In other instances, a user might have to perform multiple GET commands and look at the raw values in order to understand the results. And depending on the data returned, it is sometimes necessary to perform some mathematical operation in order to provide data that can be easily interpreted by the users of the system.
There are also hurdles on the path to integrating SNMP monitoring alongside more traditional broadcast facility control connections (GPIO, etc.). NMS systems do not normally have any capabilities for connecting with physical analog and status inputs, nor do they generally have any kind of relay outputs or control functions outside the SET command. For broadcast operations, users expect these functions plus robust monitoring and alerting, and even the capability to preform automatic actions based on the information received. Fortunately, there are several solutions on the market that can “bridge” the functions of an SNMP Manager with the more traditional capabilities of a facility control system so the users can monitor and control the entire length and breadth of their operations.
Just as IBOC, ATSC, AES and basic IP structure and languages were once little understood by broadcast engineers, there is growing recognition of SNMP as a useful tool. More and more manufacturers of transmitters and other broadcast equipment are including support for SNMP operations within their systems, and that is a trend that is not likely to change soon.
It is a powerful option, since it expands the user’s capabilities in two important ways. First, SNMP provides the ability to control and monitor more different types of equipment. Since SNMP is a standardized system, not only broadcast gear, but IT devices such as routers, servers, printers, etc. can be incorporated into the overall facility control plan. And second, the concept that the equipment being monitored can be remotely located from the facility control device, whatever it may be. This allows great possibilities for inter-site communications and being able to monitor a large network of sites and equipment that may be spread over great distances. With SNMP, anything you can reach over a network connection can be controlled.
With a proven record of easing engineering workloads and reducing downtime for broadcasters, anyone with responsibilities that involve IP networks should consider the Simple Network Management Protocol as a part of their facility monitoring and control toolkit.
