Transaction Language 1 (TL1) is a set of ASCII-based instructions, or "messages". These messages allow 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. It's widely used to manage optical (SONET) and broadband access infrastructure in North America
What is the origin of TL1?
In the early 70's, network operations began to increase. Many companies started using Man-Machine Language (MML). This is a protocol readable by both humans and machines. It controls equipment elements both locally and remotely.Bellcore is an equipment manufacturer and research institute for the Regional Bell Operating Companies (RBOCs). In 1984, they specified Transaction Language 1 (TL1) as the standard protocol.
Bellcore changed its specification in 1988 to Common Management Interface Protocol (CMIP).
However, CMIP was never widely implemented; likely due to it's reputation of being too complex. As a result, TL1 continues to be the dominant network management protocol even after divestiture and incorporation of new protocols.
What kind of messages does TL1 consist of?
The TL1 language consists of a set of messages, of which there are four kinds:
Input messageThis is the command sent by the user or the OSS.
Output/Response messageThis is reply sent by the NE. It's a response to an input message.
Acknowledgment messageThis 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 messageThese 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 InterfaceTL1 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 LanguageTL1 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.
ServicesUnlike 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/EventsTL1 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 faq or talk to one of our knowledgeable technicians.
What are some TL1 message types?
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, 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.
TL1 commands request an action to be executed by the recipient of the message.
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.
How does the Command Line Interface work in TL1?
Human staff can interact directly with TL1 equipment. They do this through a command line interface. This will be 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. 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. Don't forget that this is not a core part of TL1.
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.
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 joined 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.The information being exchanged must be understood by both systems. Unless it is, 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 gear ?
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 two things. It must keep up with the management systems. It also has to keep up with the network elements that it connects.
TL1 interfaces are string-based and human-readable. That's why they can be rapidly developed and easily updated. No special decoders are needed for debugging.
New messages can be added with minimal effort. This contrasts with the complex environments required to develop and maintain other protocol interfaces. These have development cycles of 9 to 12 months and regularly fall behind hardware enhancements.
TL1 is still being deployed today. It's 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 gear. Agents receive and perform commands sent by the manager. They also 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 gear.
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 need more. 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. 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 and cost-effective. It provides the many advantages of an integrated, multi-protocol network monitoring solution.
Why would I want to use a Multi-protocol Master?
Sometime, you'll be integrating a wide variety of remote telemetry devices. This generally includes a lot of protocols. The ideal solution is quite simple. You should integrate all your monitoring into a single multi-protocol monitoring platform. This is ideal for several reasons. These are:
- Create substantial savings. Save on 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 is a multi-protocol, multifunction alarm master that collects alarms from all your gear, regardless of manufacturer or protocol. This eliminates the need for specialized terminals.
With T/Mon NOC, you can:
- Display the status of your entire network on one screen. You'll use 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. Users can be connected via LAN, dial-up or serial port.
- Send pager and email alarm notifications to multiple users automatically.
TL1 Alarm Monitoring System. | Top 15 TL1 Resources
Get a Custom Application Diagram of Your Perfect-Fit Monitoring System
There is no other network on the planet that is exactly like yours. For that reason, you need to build a monitoring system that's the right fit for you.
"Buying more than you need" and "buying less than you need" are real risks. You also have to think about training, tech support, and upgrade availability.
Send me a quick online message about what you're trying to accomplish. I'll work with you to build a custom PDF application diagram that's a perfect fit for your network.