The key to really understanding TCP/IP network management is to comprehend the information-oriented nature of the entire Internet Standard Management Framework (SNMP Framework). To see what I mean by this, let's step back for a moment and consider in general terms the problem of network management, and more specifically, the problem of managing devices on a network.

A network administrator needs to perform two basic types of actions: gather data about devices to learn how they are functioning, and give commands to devices to change how they are functioning. In the simplest terms, the first category can be considered like a “read” operation, and the second is comparable to a “write” operation.

A classical way of implementing this functionality is to define a communication protocol. Most such protocols are command-oriented—they consist of a specific set of commands to perform the “read” and “write” operations we mentioned above. For example, a network management protocol might have a read command such as “report on number of hours device has been in use”, and a write command such as “put this device into test mode”. The network manager would control the device by giving the appropriate commands.

A command-oriented management protocol has the advantage of simplicity: it's clear what the commands are for and how they are to be used. It can be reasonably well-suited for use in certain environments, but it doesn't work well on a large, heterogeneous TCP/IP internetwork. The main reason for this is that command-orientation inextricably ties the protocol to the devices being managed. Consider:

• Every type of device might require a distinct set of commands. For example, the commands given to a router might need to be different than those given to a host. This would lead either to a proliferation of commands in the protocol, or to inflexibility in allowing proper management of different device types.
  
  
• Every time a company created a new type of device, or made a unique version of a type of device, the network management protocol would have to be changed.
  
  
• Whenever the operation of a kind of device changed, due perhaps to a change in another protocol, the management protocol would need to be updated.
  
  
• The protocol itself could not be easily changed without affecting a lot of hardware.

The solution to the problems of command-oriented management protocols was to use an information-oriented model. Instead of defining specific commands that interrogate or control devices, the devices are defined in terms of units of information that are to be exchanged between the devices and a management station.

Instead of “read” commands and “write” commands, we have variables that can be “read” or “written”. Take the two examples mentioned earlier. Instead of a command like “report on a number of hours device has been in use”, the device keeps a variable called “number of hours in use” and the network management station can “read” this as one of many variables, with no need for a specific protocol command. Instead of a “write” command called “put this device into test mode”, the device has a variable called “current mode”. The network manager can change the mode of the device to “test” by changing the value of the variable.

This difference may seem subtle, but it in fact underlies every aspect of how SNMP works. I believe part of why the SNMP Framework is hard to understand is because insufficient emphasis is placed on looking at things in the “SNMP way”, which means thinking about information objects and not commands.