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.


What Does SNMP Have to Do With Crestron?

Courtesy Crestron.


     When we last spoke with Fred Bargetzi for IT/AV Report back in the Winter 2004, the Crestron technology VP was ebullient about most of his company’s opportunities, but he was a bit depressed about AV systems use of SNMP. He had come into Crestron as a computer guy, made a huge effort to build SNMP into Crestron’s products, and found that, “The AV industry didn’t care.”
     He continued, “The market wasn’t ready. Now, instead of us pushing SNMP, it’s a pull.”
     The difference is that, these days, an AV systems manager typically either works with or for an IT manager. “They’re both often in the sales meetings now,” stated Bargetzi. “When I look over to the AV people, we talk about our other package, Room-View. For the IT guys, they get comfortable knowing they can monitor and maintain things by running the same SNMP package—something like HP OpenView—that they’re using for the rest of their infra-structure….I can sell the system by removing the objection” to weird, nonstandard AV equipment.
    "Crestron supports all three versions of SNMP. We give them a MIB that allows the IT guys to see all Crestron devices on the network. In fact, we post the MIB file on our website. We provide more than 1000 reports on system status. It lets the AV people feel a little closer to the IT world.”
     And it also gives Crestron a central place in that world, as IT and AV conjoin. Crestron can bridge between the worlds.
      With so few AV devices being SNMP-enabled, but with virtually all being able to respond to Crestron control, “Now we can take devices within the room that are not SNMP-enabled,” said Bargetzi, “and SNMP-enable that device.”
     Bargetzi has not only helped bring Crestron, and all the AV devices its products control, into the SNMP world, the company’s gear now also is controllable over TCP/IP. And they’ve also just started shipping a mesh network for ZigBee. “We’ve been working with Ember for two years,” he said. The effort was “originally more geared to the residential side, but soon we’ll be able to wirelessly link security sensors, lighting sensors, all kinds of other information to the Crestron-controlled system…and bridge that to the larger SNMP-controlled network, too.”
     And so, the networking innovation now comes from the AV side of the IT/AV link-up. Quite a change in just a couple of years.



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

«« Return to IT/AV page                   
2003 - 2009 Archives
 

Video
Audio
IT/AV
Applications
Business


Editorial Team
Masthead
Back Issues
Subscription
Blue Book
More Information
Privacy Policy
 
  Video Celebrating
50 Years of Sound & Communications
Rock 'n' Roll
50th  

 

 

 

 

© 2009 Testa Communications | Privacy Policy