Protocol Wars

Which Network Management Protocols Must I, Should I Use Now?

When companies want to solve complex global problems through networks of computers they turn to protocols. These magic software tools are supposed to make it easy for software systems to talk to each other. The problem is that they don't.

Protocols are hard to define, harder to build and even harder to test. In addition, there are so many to chose from that to settle on one and only one is impossible. In all this confusion, what is a manager to do? Recognize that real-world solutions will have multiple protocols and that to achieve an integrated network of computers will cost machine cycles and demand extensive testing.Just as impedance matching makes it possible to cascade electronics in unanticipated ways, protocols provide the means to interconnect disparate software systems. Protocols let separately developed systems work together when both systems interpret them in the same way.

For software systems to successfully work together they must be able to exchange data, properly interpret it, transform it into the structure its application requires, and put the data in the right context. For example, say I asked you to tell me your telephone number. You must make sure that I can hear you, that I can understand the language you are speaking, that I understand the number plan implied in your answer and that you understand where I am calling from. To successfully dial your number, I must know if we are in the same area code.

OSI

Software engineers turned to standards organizations to define approaches for system interconnection. An internationally standardized solution to this problem is based on the seven-layer Open System Interconnection Reference Model (OSI), a complete structure that has proven difficult to implement. The network management community provided more definition for each layer in its Telecommunications Network Management standard. Even this was not enough: Special multitransaction interface brokers had to be built to make sure that information extracted from multiple databases properly updated a system. Transactions in legacy systems are wrapped with object code to make the interfaces easier to coordinate. With the advent of object technology, Object Request Brokers were defined, and CORBA is a special common one. CORBA was heralded as the new standard way to interface systems. The problem was that it could only handle one transaction at a time, so it needed extensions.

Marshall Rose, an early contributor to the Internet and the co-inventor of the Simple Network Management Protocol, knew another way. He understood that it was right to start with something appropriate to the times for computer communications. He saw this as a much better way to start than having to making a major investment in tools and skills to use the OSI-based CMIP (Common Management Information Protocol.) SNMP has clearly won in the computer communications marketplace, but it does not have the features telecommunications managers need. Security is a major shortcoming of SNMP. Attempts to upgrade top a version 2 have not been widely accepted because of compatibility problems and complexity.

TMN

The Telecommunications Network (TMN) finally seems to be coming of age. The underlying OSI management framework is in hand and a number of TMN platform products on the market have reached maturity. There is a set of guidelines for the definition of managed objects (GDMO) that define the objects used to build TMN solutions. C++ is the most used language in implementing TMN application, but JAVA...useful for building prototypes...is on the way. Another useful approach is using the Tool Command Language (Tcl) for design and prototyping. TMN is designed to support analog and digital networks that include public and private networks, transmission terminals, transmission systems, switching systems, exchanges, circuit and packet-switches, signaling systems and customer terminal equipment. The TMN can monitor the network elements in nearly real time. Using the data it obtains for the network elements through TMN, applications can determine billing, resource allocation and the nature and severity of problems. It can help locate failures, assist in activation and determine usage for billing purposes. Its functions include:
Alarm surveillance
Status and control
Performance monitoring
Failure localization
Installation
Provisioning
Testing
Traffic management
Billing
Service observation.

A particular instance of the CMIP interface for use in telecommunications systems has been defined as the Q3 network element interface. It is a complete definition, but tough to debug. There are two sides for Q3: the manager side and the agent side. They are different and use different sets of tools. Because Q3 code must reside in the network manager application computer, its performance becomes a major issue. The choice of toolkit for implementation is a critical decision regarding the likelihood of successful implementation of the protocol.

Three that have proven useful are the HP's OpenView, the Marben stack and Radix. The challenging part in Q3 is not just the Q3 complexity, but the mapping of "real world" to Q3. (The "real world@ means the modeling of the elements being managed and the servers.) Each is different. So the challenge is how to model correctly and how to implement it in Q3 efficiently. To model correctly requires those hard-to-find top-notch systems engineers who span the application and protocols worlds. Then the protocol code must be optimized to make it practical to run, as this code will be executed so often. All this adds up to allocating five times the effort and three times the time that you would allow for the application development. The best protocol houses produce 50-100 source instructions per staff month. Protocol work is difficult.

Rigorous testing of specifications and conformance to specifications is a must. Trustworthy protocols are the glue that binds separately developed systems that work together. A significant step forward in state-of-the-art protocol testing is the use of a finite state model. Inspection of your protocol supplier's finite state model is a must.

CORBA

Billing and other Operations, Administra-tion, Provisioning and Maintenance systems must be able to work in a heterogeneous world of protocols. The goal is to get to a protocol-independent architecture. The three most common protocols being used to connect systems are Tl-1, CMIP and SNMP. All these will probably exist within the same telephone company's operation. Sometimes a gateway is used as an independent mediation device to translate data transaction by transaction between these protocols. The hope is that the object-oriented CORBA will provide the fabric to let architects connect their independently designed components together. OpenCon Systems Inc. and Expersoft Corp are teaming to build a CORBA-based TMN gateway. Versant Object Technol-ogy has a powerful way of combing Orbix from Iona Technologies in its release 5.0 object database. The Versant/Orbix mediator adds the dimension of a database storing the objects used in the communication interface. Network Programs Inc. provides the multiple transaction capability needed for mapping applications to one another. Its adapter/ collector technology is the most robust way of connecting systems yet avoiding the head-aches of undesired interactions.

TL1

Today, TL1 is the most widely used protocol in tying Operations Support Systems together. It is based on two simple concepts. First, the interface should be readable to humans as well as computers and second, the identification of the data is carried along with the value of the data as information is transferred between systems. This powerful approach allows systems that don't need all the data elements in one set of an information block to still use the interfaces and uncouple the systems where designers want them uncoupled. The interface can be changed between systems by adding a data element, and any other system using that data block won't have to be modified because part of the protocol is to ignore any data item that it does not recognize. This Bellcore standard was defined in 1984 and is called Transaction Language 1. It was adopted to manage most parts of the telephone network. TL1 protocols have been easier to build then CMIP ones. They can be mapped into object mediators.

New systems will likely be built around object libraries with JAVA to provide the way for running distributed architecture. It is amazing to see how easy it is to integrate dispersed applications through JAVA on the World Wide Web. There is work under way to build an Internet version of CORBA. This is called IIOP. Until JAVA tools and platforms are industrial strength, developers need to rely on the earlier TL1 protocols and CORBA solutions. But those who ignore the possibilities of the JAVA future will be left behind. New interfaces should rely on JAVA for administration of their configurations so changes can be carried to the resident protocol code through the Internet. If that is not secure enough, companies can use intranets for managing protocol software.

Recommendations

So, the question is: "What's a manager to do?"If you need to interface to legacy systems and their interfaces are well known, encapsulate them in an object database and use them. Where TL1 is used, map the objects into elements and an object library.

Where several protocols are used, rely on a mediation system for translating between systems. Be careful to use an object database or adapter/collector technology when there is a "many-to-one mapping" needed between software systems. Use CORBA for new developments; look for JAVA for future developments. Most of all, buy do not build protocol software. Check the suppliers' software processes for conformance to the Software Engineering Institutes process profiles; check their design and study their finite state machine models and test in real environments. There are commercial tools available to help with the testing.

Larry Bernstein is a recognized expert in network management, software and technology conversion. He is president of the National Software Council and is and consultant through his firm Have Laptop-Will Travel. Larry is the Chief Technical Officer of Telecommunications Intellectual Software building software systems for managing telephone services. He can be reached at lbernstein@worldnet.att.net.