SNMP, the Simple Network Management Protocol, is the most commonly-used means of configuring and monitoring network devices from a central management station. Although the name makes it sound straightforward, SNMP is in fact quite a complex subject, mainly because it was designed to be generic and extensible (an intention that usually causes an over-complicated result). So, the changes to the structure in which SNMP data is presented has grown like mad over the years.

The basic SNMP protocol has three basic commands. Information is read using the GetRequest and GetNextRequest commands (the former fetches the first item in a set, the latter steps through any additional data items) and settings are changed using the SetRequest command. Responses to the various request commands are returned from the managed device to the client workstation using the GetResponse transfer method.

Evolutions
Version 2 of SNMP added a couple more commands: GetBulkRequest (a more efficient version of GetNextRequest which fetches multiple items instead of dealing with them one at a time) and InformRequest (a special function designed to allow multiple SNMP management stations to communicate with each other to update status information). Of course, in real life you don't find yourself typing these commands yourself – you'll use some kind of Windows package that draws pretty pictures on the screen and this package will issue the appropriate commands in response to you clicking and typing at the GUI.

All of these requests and responses occur as part of transfers that are initiated by the management station (although the GetResponse is sent from the managed device to the management station, this is a direct result of a request for information from the station). There is one transfer type that is initiated by the managed device, and that is a Trap. Traps are sent from the managed device to one or more nominated management stations. They are used by the devices to proactively alert the network manager to an important occurrence (this could be a problem, such as a link becoming saturated, or simply something the network manager wants to be aware of, such as a port being unplugged).

This is all very simple so far – in fact, the main complexity of SNMP lies with the database structure itself. SNMP's data structure is called the Management Information Base, or MIB, which was first defined in 1990 by RFC1155, "Structure and Identification of Management Information for TCP/IP-based Internets".

Chicken or egg?
Okay, this is a non-question: in fact, the database came first and SNMP is just one of the protocols that have been defined for administering its structure (there were others, but for whatever reason it was SNMP that became the popular one). The database structures we're concerned with actually form just a part of a much larger entity known as the ISO/ITU-T Global Naming Tree. As the name suggests, this is a hierarchical data structure that's maintained jointly by the OSI and ITU-T. The bit we care about is the section set aside for Internet operations, which in fact lives in the part of the global tree that the ISO looks after on its own.

A quick pause at this point for a bit of terminology: the way you express "object identifiers" (nodes) in this tree is to list them in order inside {brackets}, separated by spaces. So if you imagine a Windows directory AA\BB\CC, we'd express that as {AA BB CC}.

The MIB world we're interested in lies under {iso org dod internet}, and it's under here that you find all the bits of information relating to networked devices. The core component is {iso org dod internet mgmt mib-2}; MIB-2, defined in RFC1213) covers all of the fundamental aspects of networking equipment such as interfaces, IP, TCP and UDP. Generally you'll find the majority of what you're looking for lives in here.

Over the years, as new technologies and concepts have appeared, the database structure has been extended. Although there are dozens and dozens of new technologies that have been added to the structure over the years, this process has been controlled (the advantage of it living within an ISO-controlled data structure) and all new additions are described in dozens and dozens of RFCs.

Not quite there yet
Although generally beneficial, the fact that the structure of the tree is strictly controlled throws up one major problem – namely what happens if you're a technology company and you come up with a new concept that doesn't fit? We'll go into how you deal with vendor specifics in a moment, but what if you come up with something general (a new type of network interface, for instance) which will eventually be supported by a number of vendors?

The answer to this is the "experimental" subtree, located at {iso org dod internet experimental}. This is where vendors can throw anything that isn't standard until such time as the ISO accepts it as a valid addition to the overall structure and places it in a permanent home under {iso org dod internet mgmt}

Vendor specifics
We've said that the standard stuff lives under {iso org dod internet mgmt}. But what about non-standard items? We all know that although standards are important, most vendors have their own specific stuff in there.

This is dealt with by setting aside a part of the tree for vendor-specific structures, which is called the "private" subtree. It's located at {iso org dod internet private enterprises}, and the different bits are kept separate simply by having a differently-numbered subtree for each vendor. These vendor numbers are administered by the Internet Assigned Numbers Authority (IANA), and at the last count there were 18,970 different vendor-specific codes (if you don't believe us, have a shufti at http://www.iana.org/assignments/enterprise-numbers). So Novell stuff lives under node 23, Cisco is number 9 and IBM is number 2, while new kids on the block have much higher numbers (Trapeze Networks are 14,525, for instance).

Plug-ins
Given that there are this many different vendor IDs, it would be impossible to implement their specific data structures in a single package – and anyway, what's the point having a package that understands thousands of vendors' data structures when you only have half a dozen in your network? This is where packages such as HP OpenView come into their own – they implement all of the public data structures, but are able to accept "plugin" modules describing vendor-specific parts under the {iso org dod internet private enterprises} world. Each vendor produces its own plug-ins for the popular management programs, which enables these packages to understand their proprietary bells and whistles. You 'll also find, incidentally, that the big equipment vendors have their own entirely proprietary management applications. They make a better job of representing the physical device on the screen because the manufacturer is able to customise the package to fit its particular kit.

Summary
If you want to learn more about the intricacies of SNMP, the best starting place is the RFC library. Have a look at the ones we've mentioned here, then if you search the index for "SNMP" you'll get some idea of just how many new technologies have been added to the structure since its inception. The RFCs describing data structures seem cryptic, but it's not as hard as it first looks and the notation soon becomes clear.