TL1 FAQ

What is TL1?
Transaction Language 1 (TL1) is a set of ASCII-based instructions, or "messages". These messages enable a human user or an Operations Support System (OSS) to manage a network element (NE) and its resources.

TL1 is a widely used management protocol in telecommunications. It is a cross-vendor, cross-technology man-machine language, and is widely used to manage optical (SONET) and broadband access infrastructure in North America

What is the origin of TL1 protocol?
In the early 70's, network operations began to increase and many companies started using Man-Machine Language (MML), a protocol readable by both humans and machines, to control equipment elements both locally and remotely. In 1984, Bellcore, an equipment manufacturer and research institute for the Regional Bell Operating Companies (RBOCs), specified Transaction Language 1 (TL1) as the standard protocol.

Bellcore changed its specification in 1988 to Common Management Interface Protocol (CMIP). However, perhaps because of its perceived complexity, CMIP was never widely implemented and TL1 continues to be the dominant network management protocol. After divestiture, many new companies began using a variety of protocols within their networks, but TL1 remains arguably the most widely used protocol in North America today.

What kind of messages does TL1 consist of?
The TL1 language consists of a set of messages. There are 4 kinds of messages:

• Input message - This is the command sent by the user or the OSS.
• Output/Response message - This is reply sent by the NE in response to an input message.
• Acknowledgment message - This is an acknowledgment of the receipt of a TL1 input message and is sent if the response message will be delayed by more than 2 seconds.
• Autonomous message - These are asynchronous messages (usually events or alarms) sent by the NE.

What are some of the advantages of TL1 as a management protocol?

Standard Command-line Interface:
TL1 provides an industry standard command line interface CLI for managing network elements. It is also flexible enough to allow for vendor extensions where appropriate.

Human-to-machine Language:
TL1 messages are in plain ASCII text, so operators and developers alike can always read them. As messages are easily readable, TL1 does not require sophisticated debuggers or protocol analyzers - what you see is what you get.

Services:
Unlike protocols such as SNMP, TL1 has a well-defined set of management services for performance, fault, security and other areas of management. For instance, an operator has standard ways to set up performance schedules and receive performance reports from any vendor's TL1-manageable NE.

Tracking of Alarms/Events:
TL1 easily tracks and handles events with a built-in identifier, or "alarm correlation tag" called an ATAG. This unique identifier TL1 is inserted in each autonomous alarm or event message sent from an NE. If an alarm message is "lost," the manager knows about it, as the ATAG of the next event is not in sequence.

How is TL1 in comparison to SNMP?
Both SNMP and TL1 share the following benefits:

• Widespread implementation
• Ease-of-use and ease of implementation
• Can co-reside with each other or with other management protocols
• Follow a client/server or manager/agent paradigm
• Standards-based protocol
• Just as TCP/IP is the dominant communications protocol, SNMP is by far the most dominant network management protocol in IP networks.
• Virtually all enterprise networks and many public networks include SNMP NEs and OSSs.
• SNMP provides a machine-readable interface.

Why do I need to know TL1?
TL1 is a multi-vendor and multi-technology protocol with comprehensive management support. There's a very good chance that TL1 protocol plays a significant role in your network. A solid foundation of TL1 knowledge allows you to do your job more effectively.

Is TL1 Easy to Understand?
TL1 is a set of ASCII-based instructions, or "messages". Because TL1 is text-based, a jumble of code won't intimidate you. This makes the learning curve for basic TL1 much shorter than with other protocols.

However, this doesn't mean that you won't need a basic introduction to TL1 fundamentals. You must learn the basics before you can read, understand, and write TL1 commands. Fortunately, TL1 message formats are very well defined and documented, and you can learn about the most frequently used commands in this guide.

What are some TL1 message types?

Response Messages:
The response message is a reply sent by the NE in response to an input message. The response comes upon the completion of the task requested by the TL1 input message, and it states whether or not the requested task was completed successfully.

Autonomous Messages:
Autonomous messages, the most frequently used TL1 response type,are output messages sent by the NEs to report alarms, performance data, configuration changes, or condition changes.

Command Messages:
TL1 commands request an action to be executed by the recipient of the message

Acknowledgement Messages:
An acknowledgement message is a special reply sent by the NE in connection with a delayed command. This special response is issued after the receipt of the command and indicates the status of the request.

How does the Command Line Interface work in TL1?
Human operators can interact directly with TL1 equipment through a command line interface via Telnet or serial connection. Commands may be typed manually to query and control network elements.

Entering TL1 commands manually via command line must be done carefully as any syntax mistake will result in an error. This can be especially frustrating, because the message must be retyped from scratch. If your NEs have special editing capabilities, you might be able to scroll back to your previous message and correct your mistake, but this is not a core part of TL1.

More TL1 commands

What are some potential pitfalls with TL1?

High Bandwidth Requirement:
One potentially significant TL1 challenge is the high bandwidth required for transmission of ASCII text. This becomes an issue if you are reporting over slower transports such as dialup or 1200 baud.

Strict Message Formats:
TL1 can also create issues for users because it is very structured. Any deviation in the command message will result in an error. Using an automated TL1 interface for day-to-day tasks will eliminate typing errors and increase your efficiency.

With TL1, would I automatically receive notification that a network element is down?
Unlike polled protocols, TL1 sends autonomous messages to your master. While this reduces network traffic, it also means that you do not automatically receive notification that a network element is down. If you're not receiving autonomous alarms from a device, you don't know for sure whether the situation is normal or your TL1 device has failed. You must send a command to act as a “ping”. If you receive a reply, you will know that your network element is online.

How does a SONET device work within the TL1 network?
SONET devices are some of the most commonly deployed TL1 network elements today. The special architecture of a SONET ring offers added benefits for TL1 monitoring.A SONET ring must be connected to the TL1 OSS through only one device on the ring (known as the “Gateway”). Whenever the gateway network element receives a TL1 message, it uses the TID to route the message to the appropriate network element. In this way, you can reach all of the devices on a SONET ring by connecting to only one.

Does TL1 support multi-vendor management?
A protocol is like a truck. It transports information from one point to another. The information conveyed is a matter of choice. 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 other open management protocols like SNMP. No such open process exists for any other management protocol.

Is TL1 suitable for managing today's sophisticated equipment ?
There are three basic requirements for a telecom management interface:

• You must be able to develop new interfaces quickly.
• You must be able to upgrade the management interface easily.
• 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 9 to 12 months regularly fall behind hardware enhancements.

Is TL1 still being deployed today?
Yes, and more widely than ever before. New technologies such as WDM and xDSL are being managed with TL1 for the same reasons that made it popular for their predecessors. Powerful TL1 OSSs can be used directly in craft interfaces, and have a set of well-defined, powerful services.

Does TL1 follow the "Manager-Agent paradigm"?
The "Manager-Agent paradigm" is an approach to equipment management. An "Agent" is an application which runs on the equipment and allows a management application or "Manager" running on a PC or workstation to control that equipment. Agents receive and perform commands sent by the manager and send unsolicited messages or events to the Manager based on the state of the equipment.

TL1 managers receive autonomous alarm messages when problems arise on a piece of TL1 managed equipment from a TL1 agent on that equipment. That agent processes TL1 commands received from a TL1 manager, allowing it to control a piece of equipment.

What should I do if TL1 is my primary protocol for monitoring my network, but it is not enough to monitor my remote sites?
If TL1 is your preferred protocol for monitoring your network, you may find that you still need other protocols to get complete visibility of your remote sites. Network outages can occur because of failures of non-IP equipment or environmental factors. But your TL1 master is deeply embedded in your network, and you don't want to install a specialized network monitoring system to manage site alarms.

The answer is a remote that collects alarms from discrete contact closures and analog sensors and sends the alarm data in TL1 to your master. This solution is practical, cost-effective, and provides the many advantages of an integrated, multi-protocol network monitoring solution.

Why would I want to use a Multi-protocol Master?
When you are integrating a wide variety of remote telemetry devices, including multiple protocols, the ideal solution is to integrate all your monitoring into a single multi-protocol monitoring platform, for several reasons:

• Create substantial savings in initial expenditure, operational, and maintenance costs
• Save your investment in legacy protocol devices
• Give you a smooth transition to advanced telemetry capabilities

Is any Multi-protocol Master widely recognized as a superior choice?
T/Mon NOC is a multi-protocol, multifunction alarm master that collects alarms from all your equipment, regardless of manufacturer or protocol, eliminating the need for specialized terminals.
With T/Mon NOC, you can:

• Display the status of your entire network on one screen using the graphical user interface for viewing alarms.
• Forward alarm data to other masters.
• Mediate alarm data to different protocols.
• Monitor alarms in 25 standard, legacy and proprietary protocols.
• Maintain alarm history logs and create reports of alarm events.
• Control remote site equipment manually or automatically in response to alarm inputs.
• Present network status and alarm information to multiple users connected via LAN, dial-up or serial port.
• Send pager and email alarm notifications to multiple users automatically.

TL1 Alarm Monitoring System.

Download the SCADA White Paper

Give Us a Call!

To find out more about this and other DPS applications, give us a call at our toll-free number and talk to one of our network specialists. They'll help you put together a perfect fit solution for your network!