Published in IT/AV Report, Spring 2006

The Simple Network Management Protocol
By Neal Weinstock

A clunky old control system is radically innovative for AV.

     The coming together of IT and AV can be pretty paradoxical. These things are oil and water in many ways. And nothing about the mixing of them is—let’s say it plainly—weirder than the now rapid pace of adoption of SNMP to control AV systems.

Necessary Trend
     All things considered, the move to SNMP is a good and necessary trend. That’s part of what makes it weird.
     The growing number of PC-aware users (and some programmers) among commercial AV systems customers during the last decade or so increasingly has bemoaned the proprietary and simplistic nature of the AV networking controls deployed by Crestron, AMX and other “show-control” systems. They haven’t bemoaned their almost uniformly rock-solid dependability, or the unthinkability of audio or video connections going down once they’d been made in such systems. But sometimes, of course, any system is balky. And always, of course, it has seemed a no-brainer to bring that AV control to a browser window that could be accessed by any PC…even a remote one. Always, too, the more knowledgeable customers would be likely to ask why they couldn’t network AV over the same Cat5 cables carrying their data traffic, and save on installation, maintenance and space. Once AV is networked together with LAN and internet traffic, older RS232 and controls built around hard-wire interfaces become irrelevant.
     SNMP (the Simple Network Management Protocol) is what the AV guys have to switch to in order to fulfill all these desires. Oddly, though, for several years now, IT network systems designers have been bemoaning the simplistic nature and general clunkiness of SNMP. And much of what they’ve complained about involves SNMP being ill-prepared to deal with AV!
     Still, AV systems designers really don’t have much choice in this matter. SNMP has been around since 1988, and is the standard for controlling devices over the internet. There are other protocols that can be used to accomplish more or less the same level of control.

UPnP: Better Than SNMP
     One of these, UPnP (Universal Plug-n-Play) is in many ways superior to SNMP. But SNMP is pretty good, and it’s a public, no-royalty standard, meaning it’s not only inexpensive to deploy, it is not going to put a manufacturer or user at the mercy of some whimsical protocol change made by a Microsoft (which controls UPnP), Sun Microsystems (Java can be far more effective for network device control than SNMP) or hypothetical others.
     And, because of the preceding, SNMP holds the trump card of being used so widely throughout LANs and the internet that new AV devices deploying it will be controllable from anyplace.
     Which largely—but not entirely—makes up for the fact that, in deploying SNMP, users will give up some of the instant response, security and simplicity of traditional proprietary connections. What’s wrong with SNMP? A lot of little things, and two big ones:
   • It is based on UDP (User Data-gram Protocol), which is an unreliable, best-effort service. All of UDP, and most of SNMP, predate most of what is now IP (Internet Protocol). They were thrown into service in the ’90s to control devices over the internet, and left there.
   • SNMP uses a “pole-select” control concept, involving a synchronous request-respond conversation. Why is this not so good? First, combine the need for a synchronous response with the best-effort characteristics of UDP, and you might hang up the network for awhile waiting for that response. We’re talking about very short hang-ups for most data, but potentially meaningful hang-ups for AV.
   • The more general problem with pole-select is that such a system was designed to use little memory and processing power, when these were quite expensive to deploy throughout the network. Now they’re cheap, allowing more modern control systems to use asynchronous messaging in which, essentially, a “to-do” list is published and devices respond to it over time. As SNMP-controlled networks get larger and more complex, the pole-select scheme means they have to add on heavy layers of management: big, expensive boxes, in other words. A control system that used more of the intelligence located throughout the network could be flatter, essentially simpler, and more efficient and reliable.
     It could also be written in a more modern method (XML is the most reasonable candidate), thus controlled from a highly graphic webpage rather than via a command-line interface, as SNMP is now. In other words, it would have a user interface much like those in AV systems from Crestron or AMX, but viewable and controllable from any device on the network, and could be structured underneath something like UPnP.
     Among the littler problems with SNMP, security used to be a big one, but it was pretty much fixed with SNMPv3, which was approved by the Internet Engineering Steering Group in 2002. SNMPv3 includes data origin authentication, data integrity checks, timeliness indicators and encryption to protect against threats such as masquerade, modification of information, message stream modification and disclosure. (Still, any true network will be less secure than a closed and fairly dumb system, as we’ve long had in AV.)
     But, as with all the other little problems, SNMPv3’s fixes are largely a matter of patching up an inefficient system, making it even less efficient. Also, as with any public standard, nobody’s obligated to move beyond SNMPv2, so users will want to check carefully to be sure equipment is compliant with the latest version.

The Basics
     The basic workings of SNMP are really pretty simple. There are just a few types of requests that one can make of any connected device, plus one type of unsolicited information transmission. To get information from an SNMP device, a “manager” (SNMP terminology for a network client) will send a “Get,” “GetNext,” “GetBulk” or a “Set” request to an “Agent” (SNMP term for a server) and either the requested information or an error message will be sent back in a “Response.”
     The “Get” operation is used to retrieve the values of one or more object instances from an agent (for example, “Is the projector on or off?”). If the agent responding to the “Get” cannot provide values for all the object instances in a list, it doesn’t provide any values.
     The “GetNext” operation is used to retrieve the value of the next object instance in a table or in a list within an agent (that is, “Now that we know about the projector on/off status, is its lamp working?”).
     The “GetBulk” operation is used to retrieve large blocks of data efficiently, such as multiple rows in a table: “Tell me everything about the projector.” “GetBulk” fills a response message with as much of the requested data as will fit: (Provide all projector status information logged in the last minute.)
     The “Set” operation is used to set the values of object instances within an agent. If a manager wants to modify information on an agent, a “Set” request will be sent; the response to that “Set” will confirm either that the change has been made or report an error.
     The unsolicited message form is called a “Trap.” Traps are usually sent by agents on start-up, on status change and/or response to error conditions. Traps are not only unsolicited, they’re also unreliable, because they go via UDP. They may not make it to the destination, and the manager there might not be listening. Those who would argue against using SNMP love criticizing traps, and love implying that SNMP is all about managing information with traps. But traps can be managed around pretty easily. Our exemplary projector could send a trap to tell the manager it has been turned on. If the manager gets that data, it gets it efficiently and uses it; if not, it polls the agent with a “Get,” and then proceeds on the knowledge that the projector is on.
     The Inform operation allows one network management system (NMS) to send trap information to another NMS and then to receive a response. Thus, managed networks of devices can grow infinitely large.
     The information on the agent is stored in a Management Information Base. This is a hierarchical data structure (not, as it may seem, a database) that describes all the objects that can have their status reported or, in some cases, have values set.

Courtesy Cisco Systems.
An SNMP-managed network consists of managed devices, agents and NMSs.

Courtesy Cisco Systems.
SNMP facilitates the exchange of network information between devices.


What We Do With Those Basics
     At least 90% of device control, by sheer volume of activity, is about getting devices to go on or off (or take some intermediate setting) at the right time. The rest is about making sure the device is working properly, but this up-to-10% tends to require far more system development effort than the other 90%. That’s because, although not much often does go wrong, a great many individual functions can go wrong. They all have to be checked frequently, which implies that the management system must have intimate knowledge of the devices it controls, which, in turn, is how Cisco Systems, for example, can use an entirely open and public control protocol such as SNMP and still maintain close to a monopoly on internet routers.
     SNMP is merely a network communication tool set used by Cisco’s overall network management, which functions as a kind of glue that sticks customers to Cisco. The reason: It’s hard enough to control equipment that you make, and much harder to control other vendors’ gear.
     In AV, this difficulty is compounded by the fact that devices—displays, speakers, tape decks, even some IT products such as servers—come from disparate manufacturers that have given little or no thought to network control. Or, perhaps now they’re starting to think about it, but are hoping to pull off their own kind of Cisco glue trick. Unfortunately, they not only typically lack Cisco’s depth of understanding of IT networking, they don’t make enough of the different devices to go it alone.
     Thus, a Tandberg and a Polycom (both very much in the lead on this), or eventually a Sony and a Panasonic, must share SNMP values for their competing devices to assure interoperability—because we all really, really want interoperability, and will not let the manufacturers get our business anymore without providing it.

Scott Lehane is a Toronto, Canada-based journalist and documentary film producer.