Today, in addition to a large number of ad hoc management systems, three comparable standardised architectures are in use in telecommunications, storage, and computing: SNMP, TMN, and WBEM. I describe these in outline in the sections which follow.
The need for standardisation, at least at the interface to the device being managed, has led to a number of proposals for fixing part of the problem. These have tended to exclude the model of what is being managed, and to deal only with the mechanics of the interface between the operator's workstation and the managed device. The Internet Engineering Task Force's (IETF's) NetConf initiative can be seen as a partial solution of this kind ”it defines a vendor-independent protocol (XML over SOAP or BEEP ”Blocks Extensible Exchange Protocol-over TCP) and a set of basic commands that can be sent to a managed device, but in fact it is just a standardised layer above the device vendor's command-line interface (CLI).
In 1985, the standardisation section of the International Telecommunication Union (ITU-T), then known as the CCITT, began to define a set of recommendations for managing telecommunications networks. These emerged in 1992 under the title M.3010, and an update was issued in 1996.
M.3010 starts, not with the model, but with the definition of a management network that overlays the telecommunications network being managed, connecting with it at different points ”See Figure 3.2. As can be seen from the figure, the interface points between the TMN and the telecommunications network are formed by exchanges and transmission systems. For the purposes of management, these exchanges and transmission systems are connected to so-called operations systems, management systems to which operator workstations may be attached.
M.3010 defines the general TMN management concepts and introduces several management architectures at different levels of abstraction. Of these, two are of interest when comparing TMN with CIM and SNMP. TMN has:
An information architecture based on ITU-T Recommendation X.720, "Information Processing Systems ” Open Systems Interconnection-Structure of Management Information - Part 1: Management Information Model," Geneva, 1993. The modelling semantics defined in this document are very similar to those of CIM, including the concepts of classes with properties (known as attributes) and behaviour. CIM can be considered an extension of this modelling methodology, incorporating more recent thinking on object-oriented specification. As the CIM modelling philosophy has its associated language, mof so the X.700 series of specifications has its language, "Guidelines for Definition of Managed Objects" (GDMO), which is defined in X.722. As with CIM, GDMO specifies how a vendor of network devices should describe products formally so that others can write programs able to recognise and manage the device. GDMO uses Abstract Syntax Notation One (ASN.1) as the rules for syntax and attribute encoding, when defining objects. ASN.1 is defined in Recommendation X.208.
A logical, layered architecture which defines the various layers of management, from the detailed and physical to the abstract: element, network, service, and business management. This possibly represents the first realisation that, with increasingly complex systems to manage, layers of abstraction are needed if each type of operator is to work at a different level.
The dominant management system used within the data networking, storage, and computing industry today, particularly in enterprises rather than backbone carriers , is the Internet Standard Management Protocol, more commonly referred to as the Simple Network Management Protocol (SNMP).
Within SNMP each attribute of a device is identified by a unique address, and a set of basic commands (get, set, get-bulk) is available to change its value. The structure of the attributes is defined in a Management Information Base (MIB), which conforms to RFC1155  : "Structure and Identification of Management Information for TCP/IP-based Internets." The current Internet MIB is given in RFC1213 and is sometimes called MIB-II.
SNMP version 1 was standardised in the early 1990s. This was followed by version 2 and in the late 1990s by version 3. It was originally seen as an interim and temporary stop-gap until the long-awaited CMIS/CMIP Standards emerged from the International Standards Organisation (ISO). SNMP gained wide popularity, largely because of its simplicity, and, like many things of a temporary nature, is still with us. 
Recently, however, this very simplicity has hindered the development of device management ”SNMP MIBs are inadequate for defining complex data and, in particular, are inappropriate for expressing relationships between attributes. Many of these shortcomings, including the lack of support for transactions (i.e. the ability of an operator to group commands so that all or none get carried out), are listed in RFC3512.
Given the extent to which SNMP management is deployed, it is essential that any new system interwork with it. For information about the interworking of WBEM/CIM and SNMP, see Chapter 14.
WBEM/CIM emerged in the mid to late 1990s as a means of managing desktop computers. In the late 1990s it started to evolve into a more general-purpose management tool and the number of implementations started to grow.
Initially the CIM standard was defined by the DMTF and the WBEM initiative was driven through a consortium comprising BMC Software, Cisco Systems, Compaq, Intel, and Microsoft. In 1998, the WBEM work passed to the DMTF, which provides an open forum for its ongoing development and organises user and developer conferences. With its alliance partners and the WBEMSource (open source) Initiative, it also organises so-called "fusion" events, bringing together various WBEM implementations, to identify and resolve ambiguities in the standards that prevent complete interoperability.
The DMTF also intends to develop a WBEM certification or compliance programme for WBEM products. Version 1.1 of a CIM Compliance Specification was published in June 2002 and, although this currently has little content, it highlights the direction in which the DMTF wishes to travel.
How do the three existing management philosophies compare?
SNMP, TMN, and WBEM do not address precisely the same ground and so it is difficult to compare them directly. Some of the differences are quite subtle, although important.
As you can see from Figure 3.3, SNMP is typically one of the management interfaces to a device, often working alongside a CLI. The SNMP representation of the managed device (the model encoded as a MIB) is available to the SNMP agent and represents the common language between the agent and the management workstation. It is often not, however, the underlying model used by the core management software. For very simple devices, that model may be implicit in the code; for more sophisticated devices it may be the SNMP MIB, but will more likely be a proprietary internal representation.
Although it can be used in the same way as SNMP, WBEM is most powerful when its model and server lie at the heart of the on-device software. A WBEM interface to management workstations or higher-level management devices (so-called WBEM clients ) is provided out of the device. Of course, other interfaces can be supported, such as a command-line or SNMP, but these communicate with the WBEM server using the same language.
Informally, SNMP can be thought of as an interface technology that allows operators to reach a managed device. Once there, the operator's commands are translated into an internal form (often the CLI format). WBEM, on the other hand, is more than an interface; it provides the local model and software while offering a standard interface outwards and the CLI becomes just another means of access.
This has further beneficial implications for WBEM: complex systems, particularly in the telecommunications field, are managed hierarchically. A particular device is managed through an element management system, a number of devices working together in a network will be managed through a network management system and a number of networks will be managed through an operational support system (OSS). Because of the different needs, the protocols at different levels of this hierarchy have traditionally differed and an "integration tax" has been paid at each level. WBEM and its CIM models offer a possible unifying structure whereby the same models and protocols can be used all the way from the OSS to on-device management.
The orientation of the philosophies is a major point of disagreement : SNMP is datacentric ("set the value of X," "get the value of Y"), as distinct from the task-centric orientation of WBEM ("do this," "do that"). Another pair of terms used to describe the same concepts are that SNMP is "structural," whereas WBEM is " behavioural ."
One major point of dissent is clearly the introduction by TMN of one network (see Figure 3.2 on page 21) to manage another, raising obvious questions of recursion as we introduce a management network to control the management network. The idea probably arose from the voice-switching world where the voice network is no longer used to transfer information between switching points, this being carried over a separate Signalling System 7 network.
Although the SNMP standards do not specify whether the same or a separate network should be used for management, typically the same components are used for the network being managed and for the network over which management information is transferred.
Similarly, WBEM has nothing explicit to say about the separation or integration of these two networks, although an integrated model is tacitly assumed.
Of course, the SNMP and WBEM integrated models do not prevent a service provider from using different access mechanisms to reach the managed device: dial-up modems, in- band tunnels, etc. SNMP and WBEM do not prescribe an overlay management network.
SNMP has a very simple modelling language, while both TMN and CIM use sophisticated object-oriented languages that permit more intuitive modelling and the ability to build larger models without them becoming unwieldy. I give an example contrasting the SNMP and CIM descriptions of an IP routing table starting on page 56.
As a simple example, consider adding a new type of interface port to a device which you manufacture. Intuitively, this new type of port belongs with other ports (Ethernet, Wireless, Token Ring, etc.). In CIM you would describe it as a child of the CIM_NetworkPort class where it is a sibling of EthernetPort, WirelessPort, and TokenRingPort classes. Not only is this natural, but it also reduces your definition workload, because your new class will automatically inherit a great many attributes (properties) from its parent: speed, port number, link technology, permanent address, etc. In addition to having all this work already completed, because of its position in the model, the new port can be associated with a whole collection of port-specific statistics, a physical connector, and a physical module on which it is implemented without the need for additional work. Using the CIM modelling technique, a model can be built quickly because much of the groundwork has already been done and the resulting model is likely to be more consistent ”any external management system can make certain assumptions about all CIM_NetworkPorts, including your new one.
Another benefit of the object-oriented nature of CIM is that it allows a suitably authorised operator to manipulate, not only the state of a component ("set port 3 to UP"), but also the state of what may be managed ("add a new association between ports of this type and protocols of that type"). This provides a very powerful tool for manufacturers and their distributors to add value to the management of a device, in essence tailoring the management to particular vertical markets. Generally, a management workstation connecting to a device over SNMP needs to know a priori what attributes may be manipulated. With CIM, a management workstation is able to extract information about what may be managed from the device itself.
The languages used to define models of devices also differ ; SNMP uses a simple subset of ASN.1, TMN uses a superset of ASN.1, and CIM uses a much more programming-like language, mof .
The interaction between the management workstation and the managed system also differs between the architectures. SNMP offers a few basic commands (get, get next , set, get bulk), assuming that the devices will be simple and the workstations complex. TMN offers a wider selection of basic commands (including filtering), assuming more sophistication on the managed device. CIM continues this trend, allowing functions (called methods ) to be associated with particular elements. This approach is more intuitive for programmers ”SNMP relies a great deal on the side effects of setting different parameters, something which can cause problems when several fields need to be updated atomically. CIM defines a method to perform the complex operation and simply invokes it. As a very simple example, consider taking an Ethernet port out of service. With the SNMP approach, the operator may set the value of a PortRequiredStatus property to DOWN and rely on a side effect of this setting to cause the port to go down. With the CIM approach, the operator would invoke the goOutOfService() method.
Although SNMP is designed to allow the configuration of a device through the side effects of setting parameter values, many equipment manufacturers have not exploited this in their management systems, relying instead on a non-SNMP CLI for configuration and using SNMP for presenting alarms and allowing queries.
SNMP, which was not intended to be an international standard, became popular by virtue of its simplicity. However, it has not been used extensively to configure complex devices, only to monitor and interrogate them. As management systems move towards service and business-level management, SNMP is no longer adequate. TMN could offer much of what is required, but has been tarred with the "unwieldy and inefficient" brush of so many telecommunications standards and is likely to be overtaken by WBEM.
 Request for Comment: The name given to drafts and standards produced by the IETF.
 "Under this proposal, on April 5, 1860, the income tax will expire" (William Gladstone, Prime Minister of Great Britain, 1853).