in IT/AV Report, Spring 2006
The Simple Network
By Neal Weinstock
A clunky old control system is radically innovative
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.
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 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
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
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.
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
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’
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?
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
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.