TL1 Commands: ACT-USER, SET-ATTR-ENV, RTRV-ALM-ENV

TL1 protocol is an open, human-readable precursor to SNMP.

Being ASCII-based, it's not as efficient as a simple bit protocol. That's less important in the modern era, as all alarm management protocols use relatively little bandwidth by today's standards. What you gain for the small price of increased bandwidth is human-readability. Although you do need to know something about TL1 messages, it's fairly easy with a bit of practice.

The proliferation of TL1 RTUs and the following shift to other protocols has created a situation in which versatile alarm monitoring equipment is key. Emerging protocols must be supported, of course, but there are too many TL1 devices in use to ignore them and hope to achieve high network reliability.

There are many advantages to TL1 alarm monitoring compared with monitoring based on other protocols. It receives and reacts to specific commands from users and masters, is relatively inexpensive, and transmits in a format that is easy for humans to read and understand.

The creators of TL1 also tried to minimize the required bandwidth by creating efficient device responses to queries, filtering all but the requested information.

Overall, however, TL1 alarm monitoring depends on a protocol that is high bandwidth, so transmitting via 1200 baud or dialup is bound to be frustrating. LAN transmission should not be a problem, though.

DPS Telecom offers TL1-based monitoring solutions including products for collecting alarms from TL1 devices, reporting discrete and analog alarms as TL1, and mediating other protocols, like SNMP, to TL1. This lowers cost by removing the need to scrap older (yet still functioning) equipment. The T/Mon LNX and the T/MON Slim are two such monitoring solutions that seamlessly integrate older TL1 interfaces with newer SNMP equipment.

TL1 Protocol: Brief History And Recommended Equipment

The TL1 Protocol is widely used in network management. It was created to solve several problems, the most significant of which was the incompatibility of devices using different proprietary protocols. Other goals for TL1 protocol included a human-readable format and responsiveness to commands.

Because it was designed to be open, TL1 protocol can be considered a precursor to SNMP. So long as a group of devices support TL1, they will be able to communicate, regardless of the manufacturer.

But computer-to-computer communication isn't the only benefit of the TL1 protocol. It is also human-readable. Although it is structured enough to be parsed, it is also relatively easy for humans to read. This allows a much higher level of understanding with a much lower learning curve than was possible before.

Finally, the TL1 protocol supports responses to commands. A user can issue a command to a TL1 device requesting that it report all of its standing alarms, for example.

Today, TL1 is an aging protocol, but its popularity requires that any high-quality alarm monitoring system must be designed with TL1 protocol in mind.

Where Can I Find TL1?

Despite its age, TL1 is found in a surprising number of networks. This is especially true if you have SONET optical network gear. You can find TL1 used for contact closure monitoring, event monitoring, SCADA, and remote site monitoring.

Sometimes, specific examples are the best way to start learning. These are very specific, but you can likely use similar TL1 implementations in your network:

1. Monitor AFC equipment via TL1 with T/Mon.

2. Report to Your Alcatel TSM-8000 with T/Mon Mediation.

TL1 Command List

What good is a protocol if you don't know the commands you can use? TL1 commands are basic elements of TL1 alarm monitoring. The list below is a reference for some of the most common TL1 commands used in network reliability management.

• ACT-USER

• SET-ATTR-ENV

• SET-ATTR-CONT

• SET-ATTR

• RTRV-ATTR-ENV

• RTRV-ATTR-CONT

• RTRV-ATTR

• RTRV-ALM-ENV

• RTRV-EXT-CONT

• RTRV-ALM

• RTRV-COND

• OPR-EXT-CONT

• RLS-EXT-CONT

• RTRV-HDR

Because it's ASCII-based, TL1 can be effectively parsed with a text-analyzing master station like T/Mon. With the T/Mon ASCII Processor software module, this master station is about to break down TL1 into its component parts and incorporate it into any modern monitoring system (ex. SNMP, DNP3...).

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. It's a response to an input message.
• Acknowledgment message. - This is an acknowledgment of the receipt of a TL1 input message. It 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. It is useful 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 staff 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. These handle performance, fault, security and other areas of management. For instance, an operator has standard ways to do things. He or she can 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.

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 basics. You must learn the basics first. Only then you can read, understand, and write TL1 commands. Fortunately, TL1 message formats are very well defined and documented. 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. 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. They can also report performance data, configuration changes, or condition changes.

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

Acknowledgment Messages:
An acknowledgment 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.

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. What if you're not receiving autonomous alarms from a device? What will you know? Sadly, you won'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.