Download our free Monitoring Fundamentals Tutorial.
An introduction to Monitoring Fundamentals strictly from the perspective of telecom network alarm management.
1-800-693-0351
Have a specific question? Ask our team of expert engineers and get a specific answer!
Sign up for the next DPS Factory Training!
Whether you're new to our equipment or you've used it for years, DPS factory training is the best way to get more from your monitoring.
Reserve Your Seat TodayTransaction 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
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. This is perhaps because of it is perceived as complex. TL1 continues to be the dominant network management protocol.After divestiture, many new companies began using a variety of protocols within their networks. Still, TL1 remains arguably the most widely used protocol in North America today.
The TL1 language consists of a set of messages. There are 4 kinds of messages:
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.
Both SNMP and TL1 share the following benefits:
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.
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.
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.
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.
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.
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.
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.
There are three basic requirements for a telecom management interface:
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.
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.
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.
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:
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:
See also:
