Check out our White Paper Series!
A complete library of helpful advice and survival guides for every aspect of system monitoring and control.
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 TodayTL1 is one of the most used protocols for telecom network management. It is now considered a legacy protocol, but it is still considered an important tool in the monitoring industry due to its popularity among SONET, legacy gear, and other network elements.
We are a remote network monitoring solutions manufacturer, so we know how important it is for you to have knowledge about TL1 and what you can expect from it. We've helped multiple clients to work with their legacy protocols, and we want to help you have important knowledge about TL1 in order to know what you can and can't do with your legacy monitoring system.
Let's dive into the essential fundamentals of the TL1 protocol.
The Transaction Language 1 (TL1) is a set of ASCII-based instructions. These instructions, or messages, allow a human user or an Operations Support System (OSS) to manage a network element (NE) and its resources.
TL1 was developed in 1984 as a standard man-machine language to manage network elements. Before its development, most vendors created equipment around their own proprietary protocols. This practice cause many issues to operators, programmers, and support techs. Having many different protocols in a single network leads to more training, support issues, and more screens to keep an eye on.
TL1 came to introduce a single, open protocol for managing network elements. It was created with the goal to replace the many different protocols used by different vendors.
TL1 is not only open, but it also bridges the gap between human users and network equipment. It is structured enough to be parsed by machines, bu also verbose enough to be read by human operators.
TL1 messages are also embedded with the database information required to interpret the meaning of an alarm.
TL1 is a multi-vendor protocol with comprehensive management support, so the chances are that this protocol is a very important part of your network. Having a solid knowledge foundation of TL1 allows you to do your job efficiently.
TL1 is text-based, so there's no need to know how to decipher a jumble of code or hexadecimal protocols. This makes the learning curve for basic TL1 much shorter than with other protocols.
But, this doesn't mean you won't need to be introduced to TL1 fundamentals. It's important to learn the basics before you can read, understand, and write TL1 commands.
TL1 is a precursor to SNMP. Both were intended to be open standards and comprehensive languages. These protocols share the following advantages:
Widespread implementation
Open standard makes it easier to connect networked devices with monitoring software
Verbose command responses
There is a wide range of standard TL1 messages, but four types consists of the majority of TL1 communication:
Autonomous messages
Asynchronous messages (usually events or alarms) that are usually sent by network elements.
Input/Command messages
Commands sent by the user or OSS to a network element.
Output/Response messages
Replies sent by the network element in response to an input/command message.
Acknowledgment messages
Acknowledgments of the receipt of a TL1 input message, usually associated with a delayed report or action.
A semicolon means the end of a TL1 message.
Colons are used to separate the data "fields" in a TL1 message.
Commas are used to divide message arguments and to hold the place of omitted arguments.
Hypothetical arguments A through E must be separated by commas (:A,B,C,D,E;)
Arguments may be omitted from the end (:A,B;)
Any gaps in the arguments require commas used as placeholders (:,B,,,E)
TL1 messages might look intimidating to new users, but commonly used messages include several clearly defined elements that are separated by colons:
verb [-modifier [-modifier]]::TID:AID:CTAG:generalblock;
The first section of this message is structured in the following way:
verb [-modifier [-modifier]]:
The verb is the type of action to be taken by the network element (in case of a command message) or the type of event that has occurred in the element (for an autonomous message). For example, "ACT" or "RTRV".
When they are used, Modifier 1 and Modifier 2 identify and describe the object in the network element that the message will act on. Modifiers usually refer to equipment use. For example, "RTRV-ALM-ALL" or "RTRV-ALM-T1".
This second part of the message is also called the "staging block". It identifies the exact resource in the network element that will be acted on by the command. The staging block is constructed in the following format:
:TID:AID:CTAG:generalblock:
Every TL1 device is assigned a Target Identifier (TID) that uniquely defines that device. The TID is the first command in the staging block sequence, and it is subject to the following rules:
The TID can be of maximum 20 ASCII characters and may only contain letters, numbers, and hyphens.
In direct (point-to-point) routing, where commands are sent to an element over a private line, the TID value can be null.
In indirect routing, where commands are sent over a shared or public line, a valid TID value is essential. If multiple devices will see the same command, you must specify a TID so you can choose the device you wish to communicate with.
The TID value is also used to identify the source of a request message from a network element.
You can find the Access Identifier (AID) after the TID. It contains one or more simple or compound parameters. The parameters identify a specific entity within the associated target element to be acted upon by the input message.
So, in other words, the TID defines a network element (Switch Bay 1), and the AID defines the specific segment (Shelf 3, Card 4) of that network element. The AID is often the field that uniquely identifies the alarm.
A Correlation Tag (CTAG) correlates a response or an acknowledgement to an earlier input message. When a response message is sent, it uses the same CTAG to indicate the command to which it is responding. It is, therefore, the user's responsibility to ensure that CTAGs are unique for each message. A replicated CTAG will not directly cause an error, but it'll create confusion when responses are received with duplicate CTAGs.
CTAGs are also used as serial numbers for autonomous alarm messages. If a number in the sequence is skipped (for example 0001,0002,0003,0005), thee use can see that an autonomous message was missed and send a "retrieve all alarms" command.
The General Block holds the information of the message. It also says how the information will be used by the network device. Certain types of large network elements that engage in switching may make an extension to the basic TL1 message.
The General Block is required for commands that have a payload and varies depending on the command. The General Block can also be used to specify delayed actions. To accomplish this functionality, the General Block must contain an order number, date, and time for automatic execution.
The delayed action feature of TL1 is helpful for busy operators who must perform service maintenance or run performance analysis. You may schedule actions that will be stored in a remote buffer and executed at a specific date and time.
Autonomous messages, the most frequently used TL1 response type, are output messages sent by the network elements to report alarms, performance data, configuration changes, or condition changes. This means that alarms are sent immediately, instead of waiting until someone requests a status update.
Autonomous messages are the TL1 equivalent of the SNMP trap. In addition to receiving autonomous notification of alarms, TL1 operators can schedule messages that periodically report performance data values.
The Alarm Clear message is almost identical to the original Autonomous Alarm Message, but with a small difference: the code for Critical Alarm (CR) was replaced by the code for Clear (CL). This means that the alarm condition described in the previous message has been cleared.
TL1 commands requests an action to be executed by the recipient of the message.
In this example above, the UID is a username, and the PID is a password. They will be compared against the receiving element's administrator list to determine the success of this login attempt. It's also important to remember that some devices will send you no respond until you have logged in successfully. This is a security measure to prevent malicious users from discovering that the network element is present at all.
Note that the CANC-USER command is used to log off of a TL1 network element. Remember that some network element's will automatically log you off after some time of inactivity.
The response message (also called output message) works as a reply sent by the device in response to an input message. The response comes upon the completion of the task requested by the TL1 input message, and it also informs if the requested task was successfully completed.
An acknowledgement message is a special reply sent by the network device in connection with a delayed command. This especial response is issued after the receipt of the command and specifies the status of the request. An acknowledgement message begins with one of the following two-letter response codes:
IP - In Progress
Sent if the network element can't perform a requested task within 2 seconds.
PF - Printout Follows
Command execution is in progress and a response will be sent when the task is completed.
OK - Current status is OK
Command has been performed successfully.
NA - No Acknowledgment
The execution status is unknown (error).
NG - No Good
The command is valid, but it can't be performed due to parameters issue.
RL - Repeat Later
System resources are not currently available to process your command.
Immediately after one of these two-letter response code, a CTAG matches the acknowledgement message with its associated command message.
If a TL1 device runs into an error, it will respond directly with an error message containing four standard characters. Most monitoring systems support the same distinct code system. These codes tell you where you need to look to correct your command (TID, AID, etc.).
Other four-letter error codes includes:
ICNV: Input, Command not valid
IITA: Input, Invalid Target Identifier (TID)
IIAC: Input, Invalid Access Identifier (AID)
IDNV: Input, Data Not Valid
INUP: Input, Non-null Unimplemented
IISP: Input, Invalid Syntax or Punctuation
PIFC: Privilege, Illegal Field Code
Although TL1 can bring you many benefits, this legacy protocol also has two main disadvantages that lead many companies into protocol migration. Some of them are:
The first challenge that TL1 imposes is the high bandwidth required for transmission of ASCII text. This can become a problem if you are reporting over slower transports such as dialup.
TL1 can also create issues for users because it is very structured. Any nonconformity with the command message results in an error. Using an automated TL1 interface for daily tasks eliminates typos and increase efficiency.
When you need to use the command line, you can decrease time spent retyping commands by becoming familiar with the most common TL1 messages types. The more you know about message formats, the fewer mistakes you will make.
Although it is useful to understand the command-line foundation of TL1, it's best to use a high-quality alarm master for daily monitoring and control activities. It's more convenient and less frustrating to use an interface that automates the process of sending commands and displays alarms in a standard format.
Different from polled protocols, TL1 sends autonomous messages to your master. Although this reduces network traffic, it also means that you don't 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 if 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.
In TL1, the RTRV-HDR (Retrieve Header) command is used to confirm that a network device is online. Both the command and the response are simple, but they achieve the intended purpose of testing device status.
You must insert the TID of the device you are pinging and specify a CTAG. If you receive a response with the same TID and CTAG you used, then you have confirmed that the device you pinged is online.
While manual RTRV-HDR commands can be useful in some situations, a good alarm master can be programmed to send RTRV-HDR commands to devices at regular intervals to ensure that failures will be detected within a reasonable amount of time. RTRV-HDR can also be used to check the device's current time-of-day and to avoid being logged off due to inactivity.
The Retrieve Alarms command is used to review a network element's current standing alarms. It's also useful if you see a gap in the CTAG sequence of autonomous messages. This almost always means that you've missed an alarm alert, so it's critical to request a full alarm listing so you can see what's happening with your network system.
One useful feature of RTRV-ALM is the availability of additional modifiers that limit the scope of your alarms (for example, RTRV-ALM-ALL will return all standing alarms, while RTRV-ALM-T1 will return only standing T1 alarms). This is similar to a database query and has the added benefit of limiting the bandwidth consumed by the response message. You can also restrict the alarm list by adding other criteria.
SONET devices are commonly deployed at TL1 networks. The special architecture of a SONET ring offers added advantages for TL1 monitoring.
A SONET ring must be connected to the TL1 network through only one device on the ring (the gateway). Whenever the gateway network element receives a TL1 message, it uses the TID to route the message to the appropriate network element.
This way, you can reach all of the devices on a SONET ring by connecting to only one.
TL1 is a legacy protocol. This means that you might have other protocols in your network as well.
If so, you probably are running a TL1 master side-by-side with other managers, such as an SNMP manager. This means that you have two screens to watch, increasing the chances that you'll miss an alarm. Also, you have to train and pay multiple operators just to achieve basic alarm visibility.
The T/Mon LNX master station collects alarms from over 25 protocols, including TL1, and forwards them as SNMP traps to your SNMP manager. This is a cost-effective way to see you entire network status from just one screen.
To learn more the T/Mon and all its capabilities, contact one of our applications engineers today. We can work with you to achieve your perfect-fit protocol mediation solution.
Morgana Siggins
Morgana Siggins is a marketing writer, content creator, and documentation specialist at DPS Telecom. She has created over 200 blog articles and videos sharing her years of experience in the remote monitoring industry.
