Technology, Innovation & Telecomm

The title of this blog of course starts with “Technology” and ends with “Telecomm”. To date, I think I’ve managed to put out a few words on those two topics and even the middle one.

Since I’ve been feeling a bit guilty about spending so much space on issues *other* than the original target ones, I figured the following rant would help assuage my need to be true to the name. Note too that I work in the telecommunications industry and this post has particular poignance for me right now.

I’m responsible at the moment for developing a communications interface (I hesitate to call it a protocol, for reasons that will become clear presently) called “(T)ransaction (L)anguage 1″, or most commonly: TL1. I’ll apologize in advance for what I’m about to say, to those who know and love TL1…but I believe that this has to be one of the poorest excuses for a communications interface (human or computer) that has yet been invented.

I’ve implemented a pretty significant number of protocols in my years as a developer. I don’t at all claim that I’m an expert on the subject, but having done them has given me at least my own perspective on what’s good or bad. First, here’s what’s good about TL1:

1. (…)

Ok, let me move on to what’s bad about it… Just kidding. There are at least a few endearing qualities to TL1:

1. It’s text-based, so it’s fairly easy for a human to understand and enter.
2. It has at least a vaguely common form from implementation to implementation.
3. It’s used in telecommunications vendors’ gear across the industry.

Here’s what’s bad about it:

1. There’s no real standard per-se to the structure of a TL1 transaction. There are recommendations as to how one should structure TL1 messages and what the responses should look like. But, they’re seemingly just that: recommendations. More on that in a second.

2. TL1’s been around for a good while, which means that vendors have managed to implement their own variations that often don’t quite mesh with other vendors’ versions. The “standard” has been evolving for a long time, making the whole spectrum of implementations pretty wide… It has the feel of something that’s grown out of years of work by summer interns…

3. Telcordia (formerly BellCore) is tasked with keeping the standards related to the telecomm industry, but they have to be mindful of the fact that folks don’t just throw away old equipment simply because its TL1 isn’t up to snuff. That said, virtually everything that preceded any given incarnation of the spec has been grandfathered-in.

The basic structure of a TL1 message is this (fully-qualified):

VMM:TID:AID:CTAG:GENERAL_BLOCK:DATA;

Where:

VMM represents the specific command being issued. VMM stands for (V)erb (M)odifier (M)odifier and is essentially a dash-separated construct representing a unique command.

TID (target identifier) is an identifier that usually refers to the piece of equipment you are actually communicating with directly.

AID (access identifier) is the name of the logical entity within the device referenced by TID that is the target of this particular command.

CTAG (correlation tag) is a host-assigned identifier that is returned by the target of this message to allow the host to correlate responses to their associated command.

GENERAL_BLOCK is fairly complicated and is frequently ignored. It can be thought of as belonging to the DATA portion of the message if you like.

DATA is the actual payload of a given message.

Sounds good, right? Wrong. Things being what they are, a message like this is entirely possible:

VMM:CTAG;

As you can see, there are a few missing elements. Most critically, the TID and AID fields seem to be missing. It’s actually OK that there’s no GENERAL or DATA sections. But what makes TL1 so infuriating is that the above message has actually been implemented in some gear.

Another annoying feature of the language has to do with the DATA portion of a TL1 message. There can be fundamentally two types of data. The first is what is known as “position dependent”. The second is (shockingly)…”position INdependent”! The position-dependent data are just that: The data each represents is indicated by WHERE in the message each parameter appears, so the order is critical. Position-independent values are represented by a KEY=VALUE-type structure. This allows the values of various parameters to be located anywhere within the DATA portion of the message. One only has to locate a particular key in order to determine its value. Data parameters (it’s recommended) are to be separated by commas. Alas, that often ain’t the case.

I’ve seen the DATA portion of some TL1 messages structured similarly to:

Parameter,Parameter:Parameter:Parameter

…or some similarly ugly form.

So, from the perspective of a host software developer, the fact that each vendor can more or less structure their TL1 any way they like makes life pretty difficult. You have to have a fair amount of specialized code in place in order to accomodate the bizarre variations that occur, or you must invent some kind of “Rosetta Stone” mechanism that allows you to map your data to the proper form required by a given piece of TL1 equipment. And, that still implies that you manage your TL1 on a per-equipment basis rather than being able to rely on a standarized form at least.

Responses are yet another matter. The form of a TL1 response message in no way relates to the structure of a TL1 command. You’d think that responses would be formed in the same general way. Nope. Not by a mile. Where a TL1 command has colons that generally delineate fields of the message, TL1 responses are a mash-up of time stamp, textual response codes, CTAGs, and free-form data. There are essentially no hard field delimiters, so one has to have some significant text-processing capabilities to deal with the range of possible response formats. One never knows, for instance, if a response will be formatted for consumption by a human or simply for a computer. You may see a response that contains carriage-returns and line-feeds so that it’s more readable…or you may not.

My gripe in this situation (among so many others) relates to the other side of the equation. As an equipment vendor, it ought to be pretty simple. I should just be able to define my own dialect of TL1 commands and responses, and issue a spec that tells anyone using my stuff just how to talk to me. But I can’t. Why? Because my equipment has to be cameleon-like. I need to be able to emulate the behavior of other types of equipment, since the hosts using ours may not be able to be modified to accomodate. Thus, if I have to behave like equipment ‘X’, then I need to know a priori how to manage messages that will arrive. It’s no walk in the park to figure out how to deal with a whole suite of implementations in a generic fashion.

There is a Web site, hosted by Micromuse that has a pretty good description of TL1. To read it, you’d guess that TL1 was the greatest invention in American Telecomm in the last century. But, the industry demands TL1 support and who are we as suppliers to object? Why can’t folks start moving towards emerging standards like Web services, browser-based interfaces, Yiddish, etc.? Because history prevails and there’s an awful lot of gear out there that spews this cruft, that’s why.

There. Geeky enough for you? I hope so, since it’s been a part of my recent work life and frankly, it offends my technical sensibilities. I had to unload. You paid the price.

We now return you to your usual feather-weight postings…

1. 
   Sean said...
   12:17 pm - April 23rd, 2005

   Yes, I can remember myself saying in the 2000-2001 timeframe that TL1 “standard protocol” is “not standard and not even a protocol”. Everybody has their own version of it, and even the syntax varies from vendor to vendor. Its a poor excuse for an interface to a system. And its so minimal that I don’t understand why its not scrapped, its not like its some huge investment. As a means for human-computer interface its terribly clunky for a person to remember the syntax and semantics, especially given that its different for just about every vendor. Plain old text menus would be a much better interface. As a means for computer-computer interfacing its also terrible. There’s no way to create a standard parser for it because it varies from vendor to vendor… sometimes from product to product within a vendor. XML would be much better.

2. 
   refinance mortgage said...
   8:25 pm - October 6th, 2005

   z

3. 
   refinance said...
   8:25 pm - October 6th, 2005

   awesome