Here to stay: The story of TL1 provides many lessons about the future of telecom management

TL1 is by far the most widely used protocol in telecommunications management today. It was first deployed in earnest a little more than a decade ago but has never been given the same consideration as its peers, common management interface protocol and simple network management protocol.

Despite its low profile, TL1 today remains the only widely implemented, vendor-independent telecom management protocol. Most telecom network elements in North America today can be managed using TL1, and no serious telecom management system developer can ignore it.

The backdrop As the bandwidth available for network operations increased in the early 1970s, vendors started embedding man-machine language management interfaces in network elements to allow operators and management systems to control those elements both locally and remotely.

Man-machine languages can be used by craft operators and in operations support systems (OSSs). Unlike most networking protocols, humans have to be able to compose and read messages in man-machine language (Figure 1).

The ITU-T addressed this in its Z.300 series of standards on user interfaces in telecommunications. Z.300 describes the range of possible man-machine language formats. Choices were extensive, and vendors implemented their own proprietary man-machine languages. As a result, management systems and network operators had to be capable of using many similar and unnecessarily different interfaces for controlling similar machines.

In 1984, Bellcore--in its role as standards-setter for the Bell regional holding companies--decided to specify a standard man-machine language for controlling network elements. It was to be called transaction language 1 (TL1) and to be based on the Z.300 series of standards.

In a series of standards written in 1985 and 1986, Bellcore specified both a language and particular messages for managing different telecommunications technologies. Standards included the language specification (TA-396) and the original maintenance messages such as "REPT-ALM" for "report alarm" (TA-200, later GR-833).

This standard man-machine language was adopted to manage all parts of the telecom network except circuit switches. A large embedded OSS infrastructure and the small number of circuit switch vendors ensured that proprietary circuit switch interfaces remained in use. Elsewhere, however, TL1 prevailed.

Along with TL1 came another large development in telecom management--the Network Monitoring and Analysis system, a new fault management OSS from Bellcore, intended for use by most of the RHCs. TL1 was chosen to be NMA's network element management protocol.

Also at that time, many new vendors of transport and access network elements were trying to sell into the RHC market. To gain credibility, they needed to be NMA-manageable and were required to put TL1 on their devices.

NMA was given two siblings--OPS/INE for provisioning networks and Tirks for maintaining inventory information. For much of the last decade, any network element aimed at the RHC market had to go through a six-month process called OSMINE. During this time, the device was certified for manageability by Bell company OSSs.

Some have complained that OSMINE is little more than a revenue raiser for Bellcore. However, unlike other compatibility or standardization efforts, OSMINE has ensured interoperability instead of just talking about it.

Talk of replacement

In 1988, Bellcore's TA-495 specification was published. The network element management interface specification uses CMIP, which the ITU-T had endorsed as the protocol for managing networks.

Unlike TL1, CMIP is not a man-machine language. Humans--unless gifted or afflicted--cannot format its requests. CMIP is for only machine-to-machine communications.

However, CMIP has one great advantage: It is the communications pipe for the Telecommunications Management Network (TMN) information models the ITU has continued to specify. Now, not only would everyone use the same protocol, but also the structure and naming of management information itself for the first time would be common, CMIP boosters claimed. Vendor-neutral management would be possible without an expensive process like OSMINE.

Despite gaining much press and some implementations by workstation vendors, CMIP has not been embedded in many network elements. Possible reasons for this include the lack of an important, widely used OSS that requires CMIP interfaces--a CMIP NMA. Another contributing factor may be the failure of the Open Systems Interconnection family of protocols--one of which is CMIP--to become the dominant networking protocol suite.

However, the TMN information models are likely to be used in some form in the next generation of OSS, irrespective of the future of CMIP.

On the other hand, TL1 has continued to be implemented in most network elements. Its messages have been understood, and an acceptance procedure such as OSMINE was better than no testing procedure at all. In addition, TL1 had many features such as standard performance reporting for which there were no direct equivalents in the early CMIP standards. Even when a feature was supported by both TL1 and CMIP, network element vendors sometimes found the TL1 version easier to implement.

The well-established practices for designing and implementing TL1 interfaces means that new TL1 deployment will continue for the foreseeable future.

But new OSSs are unlikely to be built around TL1. Instead, they will use object technologies such as common object request broker architecture and Java to provide for software reuse, distribution and scalability. This approach is being taken in the newer generation of telecom management products from Sun Microsystems, Hewlett-Packard and TCSI.

However, new OSSs will need facilities for accessing the huge installed base of network elements--as well as many new network elements--that can be managed only with TL1. Providing such "adaption" is one of the challenges facing the next generation of OSS developers.

With the end of the Bell company hegemony, the telecom market is fractured, and the next great unified scheme for telecom management will probably be a combination of de facto computing standards. Management technologies will not be telecom-specific but instead will have much in common with corporate management systems.

Ironically, TL1 is likely to be one of the few telecom-specific technologies in the next generation of OSSs.

A number of myths about transaction language 1 continue to make the rounds.

TL1 is not for multivendor management. A protocol is like a truck. It transports information from one point to another. The information conveyed is a matter of choice.

No matter what protocol you pick--whether it's TL1, common management interface protocol (CMIP) or simple network management protocol (SNMP), the type of data transferred must be agreed upon between two communicating systems.

When people talk about one vendor's system not understanding the TL1 messages of another vendor's system, they are really talking about incompatible data being exchanged. There is a misconception that protocols such as CMIP can be placed between two vendors' systems to guarantee interoperability. The reality is garbage in, garbage out.

Unless the information being exchanged is understood by both systems, no protocol can deliver interoperability. You can use TL1 for the exchange of agreed-upon information as easily as you can use CMIP or SNMP.

TL1 is a "legacy protocol." People seldom talk about protocols in the present tense. Protocols such as TL1 that are widely implemented today are viewed as yesterday's news.\

The talk given to protocols such as CMIP that have not yet seen wide implementation creates the impression that eventually they will be widely deployed. In reality, network elements with TL1 are being developed and deployed in larger numbers today than ever before.

TL1 is not adequate for managing today's elements. There are three basic requirements for a telecom management interface. With the pace of technology improvements, you must be able to develop new interfaces quickly. In addition, as new features are added to an existing element, you must be able to upgrade the management interface easily. Finally, the deployed interface must be able to keep up with the performance and usability requirements of the management systems and network elements that it connects.

Because TL1 interfaces are string-based and human-readable, they can be rapidly developed and easily updated. No special decoders are needed for debugging, and new messages can be added with minimal effort. This contrasts with the complex environments required to develop and maintain other protocol interfaces, for which development cycles of nine to 12 months regularly fall behind hardware enhancements. Finally, TL1 is scalable, as shown by its ability to work with scalable management systems such as Bellcore's Network Monitoring and Analysis system.

TL1 and object-oriented software are incompatible. Recently, more management systems are being developed using object-oriented tools, techniques and programming languages such as C++ or Java. TL1 is a messaging protocol that represents data as human-readable strings of characters rather than as objects. This does not present a problem, however, because object servers that provide adaption between the two types of data are available from various companies, including Lumos, Vertel, TCSI, Oasys and OSI (see figure).