1.0 Introduction

In the late 1970’s, people began to connect the single, separate computer networks to build larger networks, called internets. As networks grew to connect hundreds or even thousands of workstations, to manage (i.e. Monitor and maintain) them became difficult. It is impossible to manage this multivendor network without a standard. That is to say, a network management protocol should be developed.

The designers of networks put forward two mainstream protocols for network management: Simple Network Management Protocol (SNMP) and compliant Common Management Information Protocol (CMIP).

SNMP was the first management protocol to be used in the internets. A working group (initially only four persons) of the Internet Engineering Task Force (IETF) developed a straightforward asynchronous request/response protocol, SNMP, which was appeared in 1988. It was a transport-independent protocol that grew out of TCP/IP and UNIX roots, and became an Internet standard.

The International Standards Organization (OSI) has been backing a complex standard known as Common Management Information Protocol (CMIP).

Then, network management protocol wars between SNMP vs. CMIP were fought in the late ‘80s. The outcome of those wars was that SNMP was adopted by the industry and OSI standards were put on the shelves.

2.0 Manager and Agents

The manager and agents are two key concepts in systems (and network) administration. The so called manager here is the workstation set up for viewing information collected by the agents. So the agents are special programs designed to retrieve specific information from systems on the network. Workstation users do not know the existence of the agent and it does not affect the performance of the workstation on the applications running on it. The information collected by the agent is retrieved from one or more databases to be viewed on the systems administrator’s console.

Figure 1 Manager and agent

There are several ways (cells, charts, text) to display and analyze the information from multiple sets of data. The information is analyzed for license management or inventory management, and printed as a report. Now agents are getting more and more popular as the method of doing repetitive, programmable tasks.

A comprehensive agent-based management application allows the system administrator to perform the following key functions: fault management, configuration management, security management, performance management, and accounting management (The International Organization for Standards has defined five key areas of network management).. The best way to manage a network is to run each of the five above mentioned areas of network management most efficiently [1].

3.0 SNMP

3.1 An introduction to SNMP

SNMP is comprised of three key components: the Structure of Management Information (SMI) specification, the Management Information Base (MIB), and the SNMP protocol or Protocol Data Units (PDUs).

3.1.1 SMI

The Structure of Management Information (SMI) which is a set of common structures and an identification scheme used to reference the variables in the MIB (Management Information Base), is specified in RFC 1155. SNMP uses only a few different types of data, such as integer, object identifier, etc., and it spells out the ways data can be represented. A hierarchical naming structure, similar to the DNS, is used to identify each object in an MIB. Figure 2 [2] shows objects identifier in MIB. An object identifier is a sequence of integers separated by decimal points to specify an authoritatively named object.

Unlike objects used by programmers to build applications, MIB objects are quite simple. They normally have six or so attributes, shown in table 1.

Table 1 Attributes of objects in MIB

Internet SMI

Figure 2 Object identifiers in the MIB

Agents and managing processes can load MIB objects in a binary form. MIB-II is the generic TCP/IP MIB standard at present, and specific MIBs have been put in use for bridges, printers, and other entities-provide a useful common denominator for management application developers, most vendors find it necessary to define their own proprietary objects to take advantage of their products' capabilities.

As is known the SMI is two layers of abstraction away from the kind of management data that users are interested in. SMI decides the rules for defining MIB objects, which are one layer of abstraction away from management data. The abstract rules and reserved words enable us to have specifications that are recognizable to machines and remain intelligible to humans. The SMI makes it possible for a seller to give an SMI-compliant management object definition, run the text through a standard MIB compiler to produce an executable code, and install the code in existing agents and in management consoles so that they can generate relevant documentation [3].

3.1.2 MIB

The Management Information Base (MIB) is the database of information maintained by the agent that the manager can query or set via SNMP. MIB-II, specified in RFC 1213 is current standard.

The MIB is a set of definitions of standard variables for monitoring and control of network devices. The structure of these devices is like a tree. Its root is connected to many labeled nodes. Each of those nodes is expanded when subtrees are connected to it. So the tree can be expanded infinitely. The leaves of the tree represent definitions of standard variables and are known as objects. Each of these objects is given a unique numerical identifier. This identifier shows the path to the object through the tree.

Each nodes as shown in Figure 2 will be registered by the Internet Assigned Numbers Authority (IANA). Every MIB object ID must begin with either 1.3.6.1.2.1 (MIB-II node) or 1.3.6.1.4.1 (enterprises node). MIB also includes specific collections of objects for specific purposes. For example, RMON (remote monitoring) MIB objects are under the MIB-II node. RMON is an extension of the MIB. An RMON probe can collect more data and processes than traditional SNMP agents [3].

The MIB is divided into groups of related objects named system, interfaces, at, ip, and so on. The following table lists eight object groups and their functions.

Table 2 SNMP object groups

3.1.3 SNMP Protocol

SNMP protocol operates between the network manager system (NMS) and the network elements. It is specified in RFC 1157 (Request for Comment). The NMS operate a ‘manager’ program, while the network elements known as agents must be run by ‘agent’ software.

Five types of messages are defined to exchange between the manager and agent in SNMP.

From the manager to the agent:

get-request operator, asks for the value of object instances.

get-next-request operator, asks for the next variable after one or more specified variables...

set-request operator, sets the value of object instances.

From the agent to the manager:

get-response operator, returns the value of object instances

trap operator, notifies the manager when something happens on the agent that the manager might want to know about.

Since four of the five SNMP messages are simple request-reply protocols, the relative simple transport protocol UDP (User Datagram Protocol) is normally used with SNMP. This means that a request or a reply may not arrive the destination.

3.1.4 Implementation

Entities managed by SNMP, such as hubs, routers, database managers, toasters, must be equipped with an agent that implements all the MIB objects which have connections with them. The managing process should know beforehand that all the MIB objects implemented on entities it is going to manage. Each different type of entity must also receive incremental resources from management consoles that communicate with many kinds of devices. So management consoles are resource intensive.

Figure 3 illustrates the relationship of an SNMP client and its agents. Client software that operates in a SNMP manager normally contains a database representing all managed network devices and all MIB variables. Agent software resides on each device to be managed. The client asks the agent for a specific value and the agent answers it. The client can set the variables in the agent and the agent also reports to the client that something has happened.

Figure 2 SNMP operation relationship

 

3.2 SNMP and CMIP

SNMP and CMIP have the same purpose to bring network management details to the network administrator using Management Information Base (MIB). Both protocols also support vendor-specific extensions to the MIB. These extensions enable network devices with more intelligence to report or accept greater amounts of information without requiring that all devices support the same intelligence.

SNMP does a better job at accessing specific items of information, but CMIP is more efficient in retrieving collections of information. When you ask for a particular item, you use SNMP; when you use CMIP, you make a general request first and then specify that request by indicating what you do not want. The way SNMP operates is more concentrated on a certain item, whereas CMIP works on classes of data you tell it to do according to your demands.

SNMP works in a polling way, that means: a central management processor should regularly ask each device on the network for its current status. CMIP uses reporting, in which the device only informs your central management station about changes in the device’s status.

A network management system built on SNMP is smaller, faster, and less expensive than a CMIP implementation. CMIP asks for a faster computer and a bigger memory for its function. This is because polling needs less intelligence from the devices being managed than reporting requires.

The SNMP management standard uses TCP/IP’s User Datagram Protocol, which is unreliable and insecure. This means that the sender will retry the send operation several times before declaring that the receiver has died. CMIP uses connection-oriented communications sessions to retrieve large amounts of data better. But this feature also can make the network harder to manage when problems occur. If the network is failing and almost nonfunctional, SNMP will retry its network management requests until one of them gets through. The session - oriented connections on which CMIP depends may no longer exist as a result of the network failure [4].

Although CMIP is a very well designed network management system that improves on many of SNMP's weaknesses, it has the main problem that in fixing SNMP's problems it has become such a large and complete management system that only the best equipped networks can afford to run it. In contrast, SNMP is composed of a simple set of network communication specifications that cover all the basics of network management in a method that poses little stress on an existing network. To choose SNMP and discard the ideal CMIP by industry is understandable.

3.3 SNMP and SNMPv2

Although SNMP has been relatively successful so far, it is not a perfect network manager. SNMP accesses control and authentication in the form of a community name, which is visible in unencrypted form in each packet. It is easy for a hacker to access the information with a protocol analyzer.

The latest version of SNMP, called SNMPv2, has solved that problem. SNMPv2 is an improvement on SNMP, which incorporates many of the features of the original as well as a few added features that addressed the original protocol's shortcomings.

The biggest problem with SNMP is that it is too simple to deal with information that is detailed enough and well-organized for the expanding networks of the 1990s. This can be explained by the fact that SNMP was developed quickly, it was not designed to lead network into the 1990s. SNMPv2 can deal with more in detail specification of variables, including using the table data structure for easier data retrieval. Two new PDU’s are also installed for manipulating the tabled objects. New features are so many that the formal specifications for SNMP have increased from 36 pages (with v1) to 416 pages with SNMPv2.

The following are the major improvements from SNMPv1 to SNMPv2 [2].

1. A new packet type get-bulk-request allows the manager to retrieve large blocks of data efficiently.

1. Another new packet type inform-request allows one manager to send information to another manager.
3. Two new MIBs are defined: the SNMPv2 MIB and the SNMPv2-M2M MIB (Manager-to-Manager).
4. SNMPv2 provides security enhancements over SNMPv1.

SNMPv2 could be the direction for development to go. But, it is only alive in theory. It is hard to program and not widely supported. SNMPv2 failed because its creators (Case, McCloghrie, Rose, and Waldbusser) could not agree on several key facets. Though introduced in 1993, it has not been adopted by the IETF. Nonetheless finding an SNMP manager or agent that fully supports the proposed v2 extensions is quite difficult. Many agents support the security extensions, yet do so while offering SNMP's extensions as well. SNMP is used everywhere today and to expect to fix all its problems while keeping all of its great features was a goal that could not be accomplished. SNMP has outlived anyone's expectations and because of this it has made the role of a successor impossible to fulfill.

3.4 Current Development

OSI is a beautiful dream, and TCP/IP is living it. It is important to understand that the industry often has difficulty distinguishing between dreams and reality [5]. SNMP is everywhere but CMIP so far has found no acceptation by the industry world.

The biggest advantage of using SNMP is that its design is simple. So it is easy to implement on a large network, for it neither takes a long time to set up nor poses a lot of stress on the network. The net result of this simplicity is a network manager that is easy to implement and not too stressful on an existing network.

Today, SNMP agents run on just about everything, including intermediate-systems, such as routers and gateways; supporting devices, such as bridges, repeaters, hubs, and modems; and end systems, such as workstations, mainframes, terminal servers, and printers. It is used to manage remote devices on local- or wide-area networks. This gives another undeniable advantage of SNMP: much more products support it than they does CMIP ( Part of the reason is the difference in age between the two protocols; SNMP has been around longer). This popularity came about when no other network managers appeared to replace the "band-aid" implementation of SNMP.

Recently, there has been a fair bit of activity in so-called dual-role entities, devices that are both agents and managers. These devices collect and process information from agents and then make this information available to managers. Examples include devices that implement SNMPv2’s manager-to-manager facilities, remote network monitoring (RMON) probes, and proxy devices.

Various vendors have developed proprietary extensions to SNMP to overcome the shortcomings of SNMP, such as encryption. Using intelligent agents to detect and report problems can solve the message traffic problem caused by the SNMP approach. Many companies now are developing network management systems that use CMIP or a combination of CMIP and SNMP. As they develop network management products, vendors are merging the capabilities of SNMP and CMIP MIBs. By making SNMP and CMIP use compatible MIBs, vendors can create a network management product that can accept information from SNMP or CMIP but store the information in a common format.

People can expect that SNMP will remain a viable network management product throughout the 1990s. The reasons are: although SNMP communications primarily involves UDP, it is not limited to that protocol. SNMP has been extended to non-TCP devices and can operate over OSI transport services. Internet Engineering Task Force working groups were researching methods to extend the SNMP MIB to includs objects that address toking ring LANs and other communications products. SNMP enjoys wide acceptance because communications equipment merchants can get SNMP code from several software developers who have created executable code based upon SNMP specifications. This saves a lot of effort on the part of equipment merchants in making their products SNMP compliant.

3.5 Future Development

Since SNMP has faults, it has to change to overcome those disadvantages especially when the internets size is increasing at an exponential rate. CMIP and SNMPv2 are but dreams now. How to realize it will be determined by the industry and it needs time.

It is good news for network management that the working group for SNMP has started to work together again to develop the next version of SNMP - SNMPv3. A key feature of SNMPv3 is for security. Once that is achieved people will see standards-based interoperability for all SNMP products.

More products will be developed for the next version of the SNMP Remote Monitoring standard (RMON2) when it is published in the near future. It will allow for a greater degree of interoperability between management stations and probes from different vendors. Sys App MIB which is a more standards-based MIB for monitoring applications will also be approved by IETF soon.

SNMP was built on a UNIX server which is getting smaller. People are now doing it on a desktop which is getting bigger. For example, one way is to link SNMP agents to APIs of Windows NT to make the desktop compatible with management platforms [6].

4.0 Conclusion

SNMP is an elegant mechanism for exchanging well-formed messages about bounded sets of properties end tasks. As this is the first management protocol, it has its limits. Nevertheless, it has now become a well-accepted standard within the datacom and internetworking marketplace segments [7].

Standardized network management has certainly had a great impact on the industry. Because TCP/IP is a public, not a proprietary one controlled by the Internet Activities Board, it is now extremely widely used as the basis for interconnecting LANs from different vendors. This situation was definitely to change because the US federal government already has decreed that all major computer/network acquisitions after August, 1990, must comply with GOSIP, the Government OSI Profile. So by the late 1990s, OSI protocols would have replaced TCP/IP, at least for federal government work. But, CMIP, like other OSI protocols is not easy to replace SNMP. For now, though, the number of vendors that support TCP/IP is actually increasing.[4]

However, there is no evidence that SNMP will be defeated by the OSI protocols. SNMP will overcome its weakness by adopting different extensions of MIB and develop the next version of SNMP. Also, IETF makes effort to standardize the network management to let SNMP more interoperability. SNMP will continue to dominate the network management domain for some time.

 

 

 

References

[1] Nathan J. Muller, "System Management: The Emerging Role of Intelligent Agents," Strategic Information Resources, www.ddx.com.

[2] W. Richard Stevens, TCP/IP Illustrated, Volume 1, [Addison-Wesley Publishing Company, 1994], pp. 359-388.

[3] Steinke, Steve, "Lesson 102: Simple Network Management Protocol - SNMP," LAN Magazine, Feb 1997 v12 n2 p21(2).

[4] Barry Nance, Introduction to Networking, 3^rd Edition, [Que Corporation, 1995], pp. 279, 336-337.

[5] Marshall T. Rose, "Challenges in Network Management," IEEE Network, November 1993, pp.16-19.

[6] Yasin, Rutrell, "Management’s future," CommunicationsWeek, Jan 6, 1997 n644 p29(1).

[7] Cikoski, Thomas R., "The complexities and future evolution of SNMP as a management protocol," Telecommunications, August 1996, v30 n8 p37(3).