SNMP architecture alternatives

1. Introduction

The following essay will discuss a few alternatives to the traditional SNMP network management architecture. Most of these architectures have developed through a need to generalize and standardize network management applications and also to combine it with enterprise and system administration.

This document will discuss the following architectures:

2. CMIP

The CMIP (Common Management Information Protocol) protocol was supposed to be the protocol that replaced SNMP in the late 1980's. Funded by governments and large corporations, many thought that it would become a reality because of its almost unlimited development budget. Unfortunately, problems with its implementation have delayed its widespread availability and it is now only available in limited form from its developers themselves.

CMIP was designed to build on SNMP by making up for SNMP's shortcomings and becoming a bigger, more detailed network manager. Its basic design is similar to SNMP, whereby PDU's are employed as variables to monitor a network. CMIP however contains 11 types of PDU's (compared to SNMP's five). Also In CMIP, the variables are seen as very complex and sophisticated data structures, with many attributes. These include:

    Variable attributes: which represent the variable characteristics (its data type, whether it is write-able ,etc.)

    Variable behaviors: what actions of that variable can be triggered.

    Notifications: the variable generates an event report whenever a specified event occurs (e.g. a terminal shutdown would cause a variable notification event).

As a comparison, SNMP only employs variable properties one and three from above.

2.1 CMIP and the ISO reference model

CMIS (Common Management Information Services) defines the services provided by each network-computer for network management. These services are general, not specific in nature. CMIP is the protocol that implements the CMIS services.

We know that OSI network protocols are intended to provide common network architecture for all devices on each layer of the ISO reference model. In the same manner, CMIP intends to provide a complete network management protocol suite for use with any network device.

In ISO reference model, network management application processes use the application layer. Accordingly In the application layer, CMISE(Common Management Information Services Element) provides the means for applications for using CMIP. In this layer there are two more ISO application protocols: (1) Association Control Service Element(ACSE) and (2) Remote Operations Service Element(ROSE). ACSE establishes and closes associations between applications; ROSE handles request/reply interactions between applications.

These protocols, and the applications that use them, comprise the framework for the ISO network management scheme.

2.2 CMIP services

CMIP provides 11 types of services for association, notification and operation of the network.

The next section will describe these services.

2.2.1 Management association services

Management association service controls the association between peer open systems. These services are used primarily for the establishment and release of connections between systems. They control the initialization, termination, and abnormal release of a connection of a management association with the following services: The M-INITIALIZE service institutes an association with a peer CMISE-service-user for systems management. The M-TERMINATE service terminates a connection between peer CMISE-service-users. The M-ABORT service is used when a connection between CMISE-service-users terminates in an abnormal manner.

These management association services each assume the use of services of ACSE for operation. Other CMIS services operate with ROSE. According to the ISO model, both ACSE and ROSE assume the use of the ISO presentation service and the remainder of the ISO Reference Model.

2.2.2 Management notification services

Management notification services provide information about events on a network. The M-EVENT-REPORT service tells a peer CMISE-service-user about an event that has occurred on another CMISE-service-user. If the CMISE-service-user on a system notes the change of a value(such as the state change of an interface), it can notify the managing system with the M-EVENT-REPORT service.

2.2.3 Management operation services

The management operation service is consist of the following services: The M-GET service is used by a CMISE-service-user to retrieve management information from a peer CMISE-service user.

The M-SET service allows a CMISE-service-user to modify the management information of a peer CMISE-service-user.

The M-ACTION service is invoked by a CMISE-service-user to instruct a peer CMISE-service-user to perform a desired action. The actions performed are relative to each specific device. There are many actions that an open system can request another open system to perform.

The M-CREATE service is used by a CMISE-service-user to instruct a peer CMISE-service-user to create another instance of a managed object. The managed object represents the CMISE-service-user on the managed system. In CMIS, each object that is managed has an associated instance. CMIS allows many instances of the same object, but only one definition of the object itself. This is similar in concept to object oriented programming, where each object has a definition called a class and each use of this definition is called an instance of the class. One way to use the M-CREATE service is to allow managed objects to instruct each other about the presence of new objects. For example, on a management system, there might exist a definition of an Ethernet bridge. Each time a new bridge is added, the management system would create and use an instance of this definition.

The M-DELETE service is the converse of M-CREATE service. This service is used by a CMISE-service-user to ask that a peer delete an instance of a managed object.

For access control, CMIS use access lists. For each open system, the access lists explicit state the access of other open systems. It is intended that a CMISE-service-user would check the access control before the invocation of any CMIS service.

2.3 Management association

A management association is the connection between two peer open systems for systems management. The process of connection relies on CMISE to interface with other protocols on the OSI protocol stack. With CMIS, four possible types of association can exist between peer open systems, as follows: An Event association permits two open systems to send M-EVENT-REPORT messages. The Event/Monitor association is the same as the Event association except that each system also may receive and issue M-GET messages. The Monitor/Control association allows for the communication of M-GET, M-SET, M-CREATE, M-DELETE, and M-ACTION requests, although no event reporting is allowed. The Full Manager/Agent association supports all of the CMIS services.

2.4 CMIP and SNMP

Using CMIP has a few advantages over using SNMP. Those mainly rely on its numerous services and complexity of variables, as oppose to SNMP. For instance, if a terminal on a network cannot reach its fileserver a pre-determined amount of times, then CMIP can notify the appropriate personnel of the event. With SNMP however a user would have to explicitly keep track of how many unsuccessful attempts to reach a fileserver that a terminal has incurred. CMIP thus results in a more efficient network management system, as less work is required by a user to keep updated on the status of their network.

An advantage it had on SNMP V1 is that it has security measures, such as authentication, security logs etc.

One more advantage is that it is object-oriented, as oppose to SNMP, which is object based. This means that one can use derivation and other OOP capabilities while designing a management system using CMIP, unlike SNMP.

The most problematic feature in CMIP and probably the main reason why the use of it is so minute is that its sophistication requires that the management system would be very costly. It is said that the calculation power needed for using CMIP is about 10 times higher then SNMP. Another thing is that there are very few actual implementations of CMIP.

Because of that and the fact that SNMP came out first and was much simpler to implement, CMIP is used today only in public telephone networks, for management, while SNMP rules most of the network management field.

3. DME

The Open Software Foundation (OSF) is an organization that explores technologies for use throughout the computer industry. One of these technologies is the Distributed Management Environment (DME), which tackles the problem of managing distributed network devices. The OSF/DME defines standard methods for accomplishing some of the functionality of network management systems and applications.

In July 1990, the OSF issued an RFT (Request for Technology), allowing any organization to submit a solution to any part of the overall DME architecture. Twenty-five organizations submitted proposals. In September 1991, the OSF chose the implementations to be included in the production of the DME, among them those from IBM, HP, Tivoli Systems, and Bull Data Systems.

3.1 The DME philosophy

The three guiding principles for the development of the OSF DME management approach are the following:
• Consistency - Management technology must provide managers with a consistent look and feel for managing networks, systems, and applications. It must also provide developers with consistent syntax and semantics of APIs.

• Interoperability - Management technology must provide interoperability between DME-based management systems, through support for industry-standard protocols (SNMP and CMIP), support for the OSI SMI, and a common understanding of object definitions.

• Scalability - Management technology must scale from a single node to the enterprise, and must provide the flexibility needed to accommodate different geographical, topographical, and organizational models.

One can see from those principles why the DME relies heavily on Object Oriented Design, which gives most of what is needed here, therefore all items in the management environment are described as objects. An object is a software-defined entity having its own properties, methods, and internal workings. The internal structure of an object is not known outside of the object. Applications that use an object simply need to know its properties and methods. Objects hide complexity and make it easier to build a complex application by breaking the many facets of the application into smaller, indivisible components. Another benefit from using such an approach is the ability to replace an old version of a device with a new one without altering the conversation between the device and the management tool.

Since a device is known only according to its services, and so a change in the implementation (such as a new version) does not alter its interface, a change of version will require no change of the protocol.

3.2 The DME framework

The DME traditional framework accommodates a variety of network devices and protocols existing on the majority of the data networks today. The client/server methods in this framework use existing, established technology. The network management system is the server; the network devices are seen as clients. The traditional framework specifies a standard for the following features provided by a network management platform and associated applications: X11 Motif (a set of standard software libraries that provide a consistent look and feel for X11 applications) was chosen for the GUI portion of the traditional framework architecture. This specification allows for a wealth of functionality and has a well-defined set of specifications for use. Software engineers can use it to write applications, and it is supported on many varieties of workstations and personal computers.

The traditional framework can use two schemes to gather data from the network: SNMP and CMIS/CMIP. Thus this architecture can manage all of the devices that currently support SNMP and those that may support CMIS/CMIP in the future. Notice that there is no need for especially using neither SNMP nor CMIP, it is just that a way to acquire data from the network. Regular HTTP (as will be explained later) will do.

X/Open's XMP was chosen for the application programming interface. This interface provides access to both the SNMP and CMIS/CMIP. However, these two protocols have different rules for governing their Structure of Management Information (SMI), forcing XMP to use two different ways to access each protocol. This means that applications must decide which protocol to use for data gathering. XMP provides direct access for applications to SNMP. However, another level of abstraction, called the Instrument Request Broker (IRB), allows XMP to access CMIS/CMIP. The IRB attempts to provide a simplified interface to CMIS/CMIP that allows application developers to view network devices as managed objects. This level of abstraction allows the CMIS/CMIP object-oriented design to work within the traditional framework

The DME object-oriented framework makes extensive use of object-oriented technology for the purposes of network management. Instead of using a classic client/server architecture, this framework allows the network management system and network devices to appear as peer objects. A network management application, which is an object, communicates with network devices by using their associated methods. Likewise, the network devices communicate with the network management system by calling its methods. These methods are invoked when an operation is received by an object. The OSF Distributed Computing Environment (DCE) defines the RPC mechanism that the framework uses.

An adapter is another component of the object-oriented framework. OSF realizes that there should be a way for existing technology to be incorporated into the DME. This makes transition to this framework easier and does not require a potential upgrade on all network management applications and devices overnight to support object-oriented technology. An example may be an adapter for SNMP. The adapter could translate between the basic SNMP operations and DME methods. This could enable SNMP-managed devices to be seen as objects with appropriate methods.

3.3 DME services

In addition to the management frameworks, the OSF has decided to provide a few essential applications with DME. These applications include:

3.3.1 Event management

The event services give a way to log, filter, and forward relevant network events in a distributed environment. In other word, management applications and system administrators need to be notified about problems and changes occurring in the system. DME's event management services provide notification of forwarding, logging, and filtering. Filters can be programmed to analyze the attributes of an event notification and associate the event with a particular action. To make this management service easy to use, DME provides a high-level template language for event definition.

3.3.2 Print service

The print services provide distributed print service throughout the network. The facilities for network - printing available today are inadequate for sophisticated distributed environments in terms of both functionality and manageability. The DME printing system, designed with distribution and extensibility in mind, will combine superior functionality with the flexibility needed in heterogeneous computer networks.

3.3.3 Software distribution service

The software distribution services help install applications for distributed use. Installing, distributing and maintaining software in a heterogeneous environment is a complex problem. As the installed base of networked systems grows, the need to update software and install new packages across a diverse range of systems becomes critical. The OSF DME Software Distribution Service (SDS) solves this problem. SDS addresses four steps of software life cycle management.

3.3.4 Network license service

Control and maintenance of software licenses are handled by network license service. Software licensing has become a central business issue, whether a company uses personal computers, workstations, mainframes, or a combination of those systems. The growing diversity of software and the various ways in which it can be distributed and used have created a demand for new and innovative ways to license this technology.

Advances in client/server computing also have changed the way computer resources are accessed and used and, as a result, the way software can be licensed and distributed. Today, single-node licenses make it necessary for larger sites to keep track of hundreds of individual licenses. Site licenses alleviate the burden of tracking individual licenses but can be cumbersome when a license for every user is not necessary.

The DME License Management Service (LMS), running in the OSF Distributed Computing Environment (DCE), provides a vendor-neutral mechanism for creating, distributing, and using software licenses. Software vendors can use it to tailor licensing business practices to meet the requirements of their customers. System administrators use it to retain full control over when, where, and who can allocate the license units. Revenues of software suppliers and their distributors can be protected because applications are usable only according to the terms of their licensing agreements. Distribution of software by suppliers and within end-user organizations becomes easier to control.

Finally, although these types of applications will help in the management of a distributed network, they do not rely on the DME framework. Each of these applications uses the structure described by the OSF DCE. Because of this separation between the distributed services and the framework, OSF has released the DCE components separately from the DME framework.

3.4 DME and SNMP

The advantages of DME on SNMP are quite many. DME is an object-oriented environment (like CMIP) and as such it gains all the benefits of such an environment. An improvement of DME over CMIP is that it can also integrate with CMIP and SNMP, and so older network frameworks are still valid, which allows more flexibility.

As in CMIP, DME also has an important section of event handling that is much more sophisticated then the one in SNMP, which leads to more possibilities and control.

The main problem with DME is that it seems as if it over – generalize the framework, causing a problem for the business interest of the different companies. For example, if SunNet Manager, HP OpenView, and IBM Netview / AIX all have the same GUI, protocols, API, and so on, the bargaining position of these platforms based on unique abilities may be lost. Of course, the applications provided with each platform may be different and could be a differentiation factor. However, platform vendors have not made a major effort to conform to the DME framework. In fact, the future of whether to implement DME is currently being considered by major network - management platform vendors.

The tradeoff is between making the life of your system administrator easier and having to pay for the over – generalization and for the work that will have to be done to move from the already - exist SNMP framework to a new one.

As a result from that DME is hardly used.

4. HNMS - HNMP

HNMS (Hierarchical Network Management System) is a system developed by NAS.

HNMS enables an administrative staff to monitor a very large Internet Protocol network. Since the entire network can be viewed as a whole, HNMS is designed to alert the administrator when something on the network becomes unreachable. HNMS also automatically collects statistics on network traffic to allow the administrator to analyze network utilization, and stores the data in one convenient place.

4.1 HNMS architecture

The system consists of four types of modules. The modules are software entities, typically residing

On separate hosts throughout the network. The server module is the hub of the management system. It provides a center for dissemination of topology and status information. User Interface (UI) modules reside on graphical workstations and provide users with access to real-time or logged data.

Input/Output (IO) modules reside on hosts located at strategic points within the local-area and wide-area networks and handle the actual data collection. IO modules use SNMP and layer 2 monitoring for data collection. The IO modules pass filtered management data up to the server. The server, in turn, sends relevant information to the UI modules participating in the management system. Data are sent only when their values have changed. Thus the hierarchical approach allows us to avoid flooding a network with management traffic and creating bottlenecks where management information is processed. The fourth type of module, the database module, is a place to log long-term traffic studies, as well as keep current network state data. If the server machine should crash or become unreachable, a new server is started on a different machine; the server will then load the network - state from the database. If the database module should become unreachable, data are queued until the database is again available. A fully functional HNMS consists of a server, a database, at least one IO module, and at least one UI module.

4.2 HNMP

All inter-module communication is done via a new Hierarchical Network Management Protocol (HNMP). HNMP, like SNMP, is built on top of UDP/IP, and ostensibly falls at layer 7 in the OSI network model.

The protocol requires the use of a new HNMS MIB, which defines a set of variables (in addition to the standard SNMP variables) in which object data are represented. In addition to transporting object data, HNMP facilitates a higher layer of network management with paradigms such as management domains and subscriptions, explained below. These allow a given module to receive a select set of management information about an arbitrary group of objects without repeatedly asking for it. More importantly, the protocol allows the system to uniquely identify data about any given HNMS object at any point in time, for the lifetime of the system, as each variable binding has a timestamp associated with it. This level of flexibility is not possible with SNMP.

4.3 HNMS objects

The work in the HNMS architecture is done on specific network elements. Network elements are the actual entities that comprise a network -- routers, hosts, serial links, LAN segments, and individual interfaces. HNMS objects are the representations of these elements, and other abstractions, within an HNMS system. Each object is identified by a unique integer, its HNMS id, which is assigned by the server. There are, in total, eleven classes of HNMS objects: In addition to its class, each object has a subclass, and certain objects have a status. The subclass serves to further identify the type of object. Possible subclasses for the Interface class include Ethernet, FDDI, and serial link. The status identifies the operational and administrative state of the element, and is used with all HNMS object classes except Site, Equipment, Administrator, and PostalAddress. Values for the operational state include Responsive, Non-Responsive, and Unreachable. The operational state is ultimately set by the server, depending on whether the element has been heard from within certain preset time periods. Values for the administrative state include Alarm, Unresolved Problem, and Normal.

Object data are the collection of information, which describe a particular HNMS object; they consist of variables represented as name: value pairs that provide information apart from the class, subclass, and status. Representation of object data requires, in addition to the standard SNMP MIB variables, the use of a new HNMS MIB. This MIB contains separate groups of variables dedicated to describing the eleven classes of network objects. It also contains a “log entry” group whose variables are used for reporting alarms as well as for storing free-form textual data about any object.

4.4 HNMS services

There are four types of services given by the HNMS system: System parameters setting, Data exchange, Device discovery and Object management.

4.4.1 System parameters setting

The HNMS has associated with it a number of operational parameters that can be set by users through a UI module. These parameters concern polling intervals, timeout intervals for determining state hangs, intervals and buffer sizes associated with HNMP, and other aspects of module control. Some parameters are module-specific, while others are system-wide; the latter are maintained by the server although copies are kept within each module. If a user chooses to set a parameter on another module, or parameters concerning the entire system, a SetParameters message is employed. Each parameter is a triple of a parameter name, its value, and an integer defining the scope. The scope can identify a certain module or the entire system. If a module wishes to get the current value of a set of parameters, it uses a GetParameters message, which is similarly defined. Problems may result if multiple UIs request that a certain parameter be set to conflicting values. For this reason, the notion of a key is employed, to ensure that only one UI at a time may be modifying a parameter.

The key is a fictitious object that is maintained by the server. When a UI module wishes to send a SetParameters, it must first obtain the key by use of a GetKey message. If the key is not currently in use, the server responds with a SendKey message. At this point, the UI module has free reign to change as many system parameters as it desires. When it is finished, it uses a SendKey to return the key to the server. The server logs all key requests and parameter changes. Additional authentication measures may be employed; however the design of such measures are outside the scope of this paper. For the initial release of the HNMS, we have settled on a scheme in which only certain UI modules have the ability to use the key; these modules are used by select members of the network administration staff.

4.4.2 Data exchange

Processor and Interface objects are first generated by the IO modules when they are discovered. These objects are given temporary HNMS id’s and are sent to the server via an Announce message. An Announce message always includes the HNMS object and a set of object data. The variables used in an announcement are known as definitive variables, since they define the object; they represent the minimal set of variables required to distinguish an object from other objects of its class. Examples of definitive variables for an Interface object are its IP address and its layer 2 (e.g. Ethernet) address. Other variables are known as descriptive variables, which provide incidental information. Examples of these are the SNMP variables ifInOctets and ifOutOctets.

Once the server receives an announcement about an object, it checks the object’s definitive variables against those of all of the objects it currently knows about. If the object appears to be unique, the server assigns it a permanent HNMS id and allows the object to be released to other modules. It immediately sends the object back to the announcing IO module, which replaces its temporary object with the one created by the server. From that point onward, the server receives data about the object by means of a subscription through the use of a SubscribeData message. A subscription consists of an HNMS id and a list of variables that the server would like the IO module to fill in. Each variable binding consists of a name: value pair and a timestamp. The HNMS objects and their object data are sent back to the server in SendData messages. A subscription is filled only when the value of a subscribed variable changes. Furthermore, only the changed variables are reported back to the subscribing module. If the server subscribes to 30 variables concerning an object and three of them change at any given time, those three will be sent back.

In addition to the subscription method, a UI may ask for a set of variables to be sent to it just once. This is accomplished by means of the GetData, GetNextData, and GetWalkData messages. The GetData and GetNextData messages are similar to the SNMP Get and GetNext messages. The GetWalkData message asks for a complete walk of a branch of the MIB starting at each variable specified in the message, and is very effective for saving bandwidth. In typical SNMP management systems, a walk of a MIB branch requires the SNMP client to send a separate message for each requested variable, using the powerful GetNext operator. In return, the client will receive a separate message containing the value of each variable. The GetWalkData message allows the request and the response to each be encoded in one message. When an IO module receives a walk request from the server, it performs the sequence of Get-Next operations required to retrieve the entire branch. Since the IO module is typically situated on the same subnet as the entities within its management domain, the heavy SNMP polling of each set of elements is restricted to their immediate area and does not travel over the entire network.

The last message type dealing with object data is the SetData message. This message is a request by the UI to set the values of variables associated with an object, and requires the use of the key in a fashion similar to the SetParameters message. The server sets the appropriate values and forwards a SetData containing the new values to all modules subscribed to those variables. If the server denies the request, it sends an explanation to the UI module. In the case of SNMP variables associated with a processor, the server forwards the SetData message to the appropriate IO module, which in turn sends an SNMP Set message to the processor. The IO module then sends the server a SendData with the new value to confirm that it has been changed. Once the server updates its object data, all subscribing modules are sent the new values.

4.4.3 Device discovery

The primary discovery method used by the IO module is a three-stage process. Each IO module listens to traffic on its local Ethernet to learn Ethernet and IP addresses of other hosts. If it finds a new IP/Ethernet address pair that falls within one of its management domains, it enters the addresses into a cache and attempts to contact the source device via SNMP. The definitive SNMP variables for the processor (e.g. sysName, ifNumber) are then requested. If the device responds, the IO module then asks it for detailed information about all of its interfaces by simultaneously retrieving selected variables from the ifTable and walking the ipAddrTable. The variables are used as the input to a set of rules for determining whether the processor and its interfaces are unique objects not currently known by the IO module. If the processor has not been previously detected, the IO module announces it to the server. If the server already knows of the object, it sends its existing object data to the IO module; otherwise it assigns the new object an HNMS id and incorporates it into the HNMS system.

A second discovery method is a more directed version of the above. If an IO module is assigned a management domain that specifies a single interface IP address and SNMP community name, the IO module takes the initiative and immediately polls the address for a processor’s definitive variables. This method is used for all of the wide-area routers in the NAS network, as they have separate community names.

A third discovery method utilizes the “next hop” entries in the routing table of each processor to walk through the network. By default, this is used only for routers, as determined by the ipForwarding variable.

The last discovery method simply consists of the reception of a trap from a previously unknown entity.

4.4.4 Object Management

The last type of service is for handling the various types of objects in the HNMS architecture. These are DeleteObject, DeactivateObject, and ActivateObject. When an object is announced by the server, it is automatically assumed to be an active object. However, situations arise where we want to make the object inactive, meaning that it no longer represents an element currently on the network. In other instances, we may want to remove an object altogether from the server’s memory. The DeactivateObject and DeleteObject messages are provided for this purpose. The final message, ActivateObject, is only provided for the sake of orthogonality. It is very rare that an object, once made inactive, will be re-activated.

4.5 HNMS and SNMP

HNMS provides a total architecture for managing devices all around the network, including not only network devices, but also system devices. The main difference between this architecture and SNMP is the usage of UI modules instead of SNMP agents and the lack of a single NMS.

The NAS HNMS boasts mainly on its relatively low management traffic:

Most traffic between IO modules and the server, as well as between the server and UI modules, consists of replies to SubscribeData messages. Since a subscription is filled only when the value of a variable changes or when the status of an object changes, the inter-module HNMP traffic in a steady state is typically very low compared to the SNMP polling traffic between IO modules and their managed agents. If we compare this system to a conventional SNMP NMS, which continuously polls all managed agents from one point, it can be seen that the sum of SNMP traffic generated by each scheme is the same. However, the benefits of the HNMS architecture are apparent when the system is used at multiple locations. The HNMS makes it feasible to monitor a network that has multiple managerial points of control.

The NAS wide-area network, AEROnet, connects six NASA centers (including NAS) and 34 other sites. The HNMS architecture provides the capability for the network to be monitored from any remote location. Under typical network management architecture, each site would run a complete NMS. Each of these systems would contact every single network device through SNMP in order to build a representation of the network. Not only will this result in slightly different network representations at each station, it will generate an inordinate amount of network management traffic. The total number of polling sessions is the number of management stations times the number of managed objects. If there were 300 devices on the network, there would be 12000 SNMP polls going on during the time interval of one polling period. Under the HNMS scheme, there would be only 300 SNMP sessions and a few dozen HNMP connections, each of which is very light-weight compared to a continuous SNMP polling session since only changes are sent. These are obviously extreme examples, since not every site will have a desire or a need to monitor the entire network; they may subscribe to a subset of the information, or none at all. However, it is apparent that the distributed architecture will provide savings in bandwidth in an extended network. Even under situations where the network is in a state of fluctuation and the status values of objects are changing rapidly, each HNMP connection is no more of a burden than an SNMP session, since the frequency of subscription replies would match the frequency of polling by the IO modules.

5. HMMS - HMMP - HMMA

There has been a movement lately to combine network management with system and desktop management. The implementation brought here is one of the more supported, offered by an organization named WBEM that includes Microsoft, Compaq, Cisco, Intel, and BMC Software.

It also enjoys the support of Netscape, Acer, Dell, Wall Data, Zenith, Tandem, 3Com, Hewlett-Packard, Digital Equipment Corp., NetFrame, Oracle, and Computer Associates.

The idea is to integrate existing standards, such as:

These standards are aggregated into an architecture that can be managed using any Web browser.

5.1 HMMA - HyperMedia Management Architecture

HMMA consists of two parts, the schema and the protocol. The HyperMedia Management Schema (HMMS), is a design of how managed objects are structured and how they are interrelated. The HyperMedia Management Protocol (HMMP) is a communications protocol that is effectively SNMP running over HTTP.

HMMS is an object-oriented model for management. Objects within this schema have relationships and inheritance of properties according to the class of managed devices to which they belong. As in many object systems, they communicate by sending events amongst themselves. One common event is a request for information from a browser directed at a managed device. Other events like alarms and notifications also exist. Each managed device is an instance of a class of objects and is designated a HyperMedia Management Object (HMMO).

WBEM structures a new "language" inside of HTML for creating events and communicating with these devices. The scripting command structure for HMMS is stored within HTML Comment tags. For example, the following shows the structure of what WBEM code looks like within an HTML document:

<HTML>
<HEAD> <TITLE>Logical Disk</TITLE></HEAD>

Drive
<!--{[UniversalKey]Name}--> C: <!--{[]}-->

<p>Available Space
<!--{[Integer]AvaliableSpace}--> 102 <!--{[]}--> k Bytes

<p>Size
<!--{[Integer]Size}--> 1000 <!--{[]}--> k Bytes

<p>
<!--{[Ref]DrivePartition}--> <A HREF"Object2.htm">
<!--{[]}-->Drive Partition </A>
</BODY> </HTML>

<!--{{82,5,1}{151,6,3}{162,7,3}{281,11,5}}-->

The code <!--{[UniversalKey]Name}--> is an message telling the device to enter its unique name. Similarly you can see other directives within the comments of this example. The very last line of the example is a list of indices to a universal table of HMMOs identifying where you can get a full description of the object itself. The browser needs to be configured to point to a server which holds this data and table.

5.2 HMMA and SNMP

The advantages HMMA has over SNMP are mostly due to the ability to manage everything through a regular web browser. HMMA provides three key advantages:
With a simple Web browsers the management interface, organizations can cost-effectively take advantage of networking technology they already have in place to manage a wide range of network resources, such as routers, hubs, PCs, workstations, distributed applications, and databases. When the technologies used for building networks are used to create management applications, the scalability of the applications can match that of the network. The proposed standards provide such scalability by allowing a system administrator to learn and implement just one interface to monitor and maintain low-end devices and systems as well as mainframes and everything in between. The standards will support a broad range of management solutions and will build on Internet innovations to meet the demanding requirements of the most complex heterogeneous computing environments.
The proposed open standards offer a single foundation on which to build management applications, obviating the need to design different versions for different management platforms and making applications more efficient and cost-effective. They thus free developers to concentrate on innovative functionality rather than system differences and allow them to bring applications to market more quickly. A major benefit for users will be significant: a greater selection of management applications and added functionality that takes advantage of rapidly evolving Web technology.
A single interface for managing all networks, systems and applications will greatly reduce the complexity that currently frustrates system administrators. The proposed management standards will free them from having to access management applications from specially outfitted consoles. Instead, they will work at any Web-enabled client systems distributed throughout an organization to access distributed management applications. Access is controlled by the security measures implemented within HTTP. A management system based on a Web browser interface that eases access to management data for networks of UNIX, Windows NT, MVS, VMS, and Netware platforms will be less costly to learn, set up, operate, and support. Likewise, as easier application development is enabled, management solutions will proliferate and competition will impact prices. Today thousands of developers are creating open Internet solutions. The Web-based technology will enable them to apply this innovation to distributed management applications.
It seems as if this proposed framework is the long – awaited HTTP version of SNMP. The large support it has also improves its chances to survive. Components of this proposed standard have already been offered to industry standards committees to help promote them in the public forum. The HMMP will be submitted to the IETF. The HMMS will be presented to the DMTF. A reference implementation of an HMOM will be developed and placed in the public domain to initiate development in the broader ISV community.
 
 

6. Conclusion and more

The article discussed 4 architectures, alternatives to the traditional SNMP architecture that are available today. All of them suggest a more complex system then SNMP and this is probably their advantage and, unfortunately, their downfall. From all of those only the HMMA seems to have a future as a replacement for SNMP.

The main interest about the last architecture is that it uses HTTP as access method, instead of SNMP.

A more intensive discussion of the usage of HTTP may be found in the “Simple-Times” newsletter, published by SNMP developers:

http://wuarchive.wustl.edu/packages/first-virtual/simple-times/4-3.html

With the emerging HTTP technologies and browser managing, one might like to have a standard for writing management applications. You can find a work done by Professors Yehuda Afek and Yoram Cohen, for creating a markup language (similar to XML) to describe management application called NMML. They also supply a Java program that “Compiles” those programs into Java applications and hope to continue their work to make them Java Applets:

http://www.math.tau.ac.il/~afek
 
 

7. References

http://tebbit.eng.umd.edu/Classes/ENEE426/docs/SNMP-Intro.html
Network management protocols group homepage:
http://mason.gmu.edu/~ywu1/infs612/content.html
http://www.frontiernet.net/~vsa184/papers/osf_dme.htm
http://www4.informatik.uni-erlangen.de/~tsthiel/Papers/osf-dme-overview.html
http://www.rose-hulman.edu/~mgrlhc/HNMS/index.html (links to other papers are from here)
http://www.infospheres.caltech.edu/mailing_lists/java/msg00181.html
http://sunsite.kren.nm.kr/sunworldonline/