The author is technical support manager at Worldcast Systems Inc. in Miami.
I. INTRODUCTION
Today’s broadcast engineers are facing challenges that seem to be ever-increasing in complexity. While systems in some areas have become more reliable and require less attention from technical personnel, new responsibilities have been delegated to the engineering department. Systems that did not even exist 20 or even 10 years ago — IBOC signals, PPM systems, streaming websites, distribution of data via RDS and IBOC data services — have maintained or even increased the overall workload and demands on the engineering staff. And frequently, that staff is smaller than it was in past decades.
Information technology systems of a broadcast facility are part of those relatively new responsibilities. Many of us can remember when the “network” of a radio station consisted of only the traffic and billing computer, the storage server for that terminal and a dot matrix printer for the logs. Of course, today’s stations have large and complex data networks; many times there are even multiple independent networks in the same facility. Even if a separate department has been created to oversee these systems, the increasing integration of IT into primary broadcast systems such as audio delivery and remote equipment management requires that engineering personnel have at least a basic knowledge of networking and how the IT structure impacts their responsibilities.
While IT requires some additional skill sets in broadcast technicians, it also offers great capabilities to help manage the overall technical workload. Being able to communicate with and control remote equipment over a high-speed network connection enables engineers to troubleshoot, correct problems and, in some cases, even perform maintenance on the most inaccessible sites from their office or home. Beyond that, the IT infrastructure brings with it certain capabilities and standards that, like HTTP or telnet, can be used to the advantage of today’s broadcast engineer.
This brings us to the topic of the Simple Network Management Protocol. The SNMP standard is a set of rules that defines a way to identify certain data points, or objects, in a piece of equipment that is connected to a data 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.
HISTORY AND DEFINITIONS
The Simple Network Management Protocol was developed during the late 1980s by the Internet Engineering Task Force (IETF). SNMP primarily was a way to facilitate communications with and control of distant networked computers as the Internet was being expanded into the worldwide data network that we now know and use on a daily basis. At the time, there were many protocols, some proprietary, which IT administrators used to communicate with and control their routers and other network infrastructure. After much discussion and debate, the protocol we know as SNMP was chosen.
While the “S” in SNMP stands for Simple, that word is used in the context of computers and processors. In other words, it is simple for the machines to understand and use, but perhaps not so simple for human users of the systems.
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.
SNMP DEVICES
Fig. 1: SNMP Manager and Agent Devices All SNMP communications happen between two, and only two, devices. One device is designated the Manager. In almost every case, a Manager initiates the SNMP communication with the target device, which is designated the Agent. While a single Manager — commonly called a Network Management System, or NMS — can manage and control hundreds of Agent devices, each of those communications are discrete, point-to-point connections (see Fig. 1).
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.
OBJECT IDENTIFIERS (OIDs)
At its heart, 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 value of 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 send 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:
Typical OID
MANAGEMENT INFORMATION BASES (MIBs)
Fig. 2: SNMP MIB Structure When an Agent device 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 necessary to access the desired data points on 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.
Unfortunately, it’s not quite as simple as it might sound. As we will see, some OIDs cannot be completely defined at the time of manufacture, and other makers of Agent equipment publish only “truncated” MIBs that refer to other industry standard files (other MIBs or RFC files) to define their own structure and OIDs.
SNMP COMMANDS
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 of an N+1 transmitter. No matter if the value of that particular object is an integer, a floating point number, even a text/numeric string; in any case, the SET command is used in the same way.
The TRAP messages also are simple. They are unique in that they are the only SNMP messages that 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 that could negatively impact the performance or stability of the system. Put simply, they are alarms. High CPU temperature, a router port that has stopped responding, 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 acknowledgement has been received from the Manager 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, but most common Manager systems do support this function. 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 use that number to “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 it has defined within its MIB (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 issues 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.
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 TRANSPORT AND PACKET STRUCTURE
SNMP communications can be carried out via a number of different transport protocols, but typically employ the User Datagram Protocol, or UDP. Because this is a simplex protocol, there is no built-in acknowledgement 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.
Fig. 3: Two Illustrations of SNMP Packet Structure
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.
II. PRACTICAL ASPECTS OF SNMP MANAGEMENT
UNDERSTANDING AN OID
When we look at an OID, we’re really seeing an address — a way to work our way down 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
Fig. 4: MIB Tree for Toshiba UPS
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 MIB tree. 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. 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 official name of the data object is upsEstimatedChargeRemaining, and from the description in the MIB browser software 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 actual definition of the object in the MIB file does not mention the full OID. As mentioned earlier, this is an example of a “Truncated” MIB. Truncating is a typical and tremendously confusing method used by manufacturers to avoid having to write complete MIB files for each piece of equipment with the resultant costs in man hours and possible errors. By examining the text at the beginning of the Toshiba MIB, we can see that a number of ‘imports’ are described:
IMPORTS
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 form the backbone of SNMP; they are “standard” 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 is also truncated, the designers have included the full OID as a comment line before the object description, preceded by the double dash –. This method saves some time and also 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. If there is another way to obtain accurate OIDs, the MIB file itself may be unnecessary.
SPECIAL CASES
In most 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, however, such as systems where data objects can be created by the user after the equipment is delivered. One example set 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 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, an analog reading) in the software. Second, a table is built into that definition in the MIB that will allow the user to add something called an Index value 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 Audemat’s 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 incorporate an index value at the end:
1.3.6.1.4.1.5299.15.42.1.10.3.4.1.3.361
INTEGRATING SNMP MANAGEMENT WITH OTHER INPUTS
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 the information we get may be somewhat confusing when interpreted from other perspectives.
One example might be sending an SNMP GET request to determine the usage level of a hard drive in a remote system. From a normal human perspective, we would expect the result to be an integer from 0 to 100, indicating the percentage of hard drive space that is currently occupied with data. However, from an IT perspective, it might be simpler for the Agent software to deliver a number from 0 to 255, indicating the percentage of use. Or they might have chosen to indicate the number of megabytes remaining, or cylinders occupied, or some other metric that is a natural choice in that world, but might be counterintuitive for a broadcast engineer.
In short, when dealing with numeric results of an SNMP GET request, it usually is advisable to have some information on exactly what form that data will take. 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 format. And depending on the data returned, it is frequently necessary to perform some mathematical operation in order to provide data that can be easily interpreted by the users of the system.
This also brings an enormous challenge when attempting to integrate SNMP monitoring alongside more traditional I/O connections and typical data formats. NMS systems do not normally have any capabilities for connecting with normal 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. So to “bridge” the functions of an SNMP Manager with the more traditional capabilities of a facility control system can require a unique combination of software and hardware.
SUMMARY AND CONCLUSION
Just as IBOC, ATSC, AES and basic IP structure and languages were once little understood by broadcast engineers, SNMP has only recently entered our consciousness 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.
That presents great potential to ease engineering workloads and reduce downtime for broadcasters and anyone who is willing and able to include the Simple Network Management Protocol as a part of their facility monitoring and control toolkit.
Comment on this or any other article to [email protected].
