Power Programming in HP Openview: Developing CMIP Management Applications

Programmer's, here you go!

Network Management Standards: SNMP, CMIP, TMN

One of the few books still in print on this subject.

SONET & T1

Learn about SONET & T1

ISDN SS7

Learn about ISDN and SS7 technology

Signaling in Telecommunications Networks

An informative book

Understanding SNMP MIBs

Don't know how to read an SNMP MIB? This book is for you.

Windows NT: SNMP

A 325 page guide.

HP Openview: A manager's guide

This 450 page book is chock full of info

How to Manage Your Network Using SNMP

A network management practicum

The Element Management Layer (EML) is the essential bridge between the network managers and network elements. What follows is what I have seen at the EML and what I believe works as a viable and cost effective design.

Protocol Hiding

The underlying CMIP protocol, its supportive API (XOM/XMP) and ASN.1 syntax is both verbose and and in some cases complex. One of the goals of the EML interface is to hide these features from the upper layers. There are several advantages to this approach. One advantage in particular is that the upper layer programming is independent to the underlying protocol. Not only is this interface then easier to program to but also makes it easier to find programmers since they will not require CMIP knowledge.

The most complaints I hear are about how verbose the underlying object representations are. The verbose-ness is due primarily to the genericity of the CMIP protocol specifically in the cases of instance naming. The advantage of this is that any instance can be represented. The disadvantage is the verbosity of the name.

Issues with complexity arise from synchronous and asynchronous communications. Other issues relate to the application of filters to the requests. One of the largest issues is the processing of what appears to be an uncountable number of possible CMIS errors within a response and how to deal with them.

In hiding the underlying protocol dependent issues you want to provide an interface that maps closely to what needs to be done. Let us take a look at the DMI Top Managed Object Class (MOC) and what a possible EML C++ representation might look like.

[ed. This is not a complete representation. Remember too, this is an abstract class and the actual implementation is dependent on your environment.]

class Top {

public:

DMI_SystemID *get_systemId ();

protected:

DMI_SystemID systemId;

}

The C++ class has methods closely mirroring the underlying MOC itself. The ASN.1 representation of the systemId attribute is hidden within the DMI_SystemID class. This attribute can now be manipulated by programmers without having any idea of what the particular XOM object is. You need to note that the programmer still needs to have ASN.1 knowledge to understand how the systemId attribute is formed and what it contains. Additionally, the programmer can get the value of the systemID attribute without knowing the exact mechanism of the CMIP Get Request.

Therefore, an EML providing a set of C++ classes such as this one provides a considerably easier interface from the upper layer management levels to the network elements. This approach is also being standardized by the CMIS High Level API Working Group and hopefully will become a standard soon. Also, some vendors have tools that can take GDMO and construct the appropriate C++ classes. This helps save time during development.