Technology, Innovation & Telecomm

So, SuperComm 2005 has officially come to a close. In a way it’s kind of sad, since this is the last one.

For the last 18 or so years, SuperComm was the collaboration of USTA (U.S. Telecom Association) and TIA (Telecommunications, Industry Association) and held in a few places, including Chicago and Atlanta. The two organizations have decided to go their own ways over differing views of the direction the show should be headed in general.

As a result, there will now be two shows, one put on by TIA and the other hosted by USTA. TIA will continue to use Chicago and will be run at about the same time next year, while USTA will be hosting its new show in Las Vegas. It should be interesting how this shakes out for vendors that are used to showing at SuperComm. It was the biggie of the year for Telecom vendors and now that it’s being split up, one wonders how different equipment and service providers will divide their efforts…if they do. It used to be that vendors would use SuperComm as *the* show for introducing new products and services and just being there was practically an implicit “must do”. Now, folks will need to decide if their budgets will support two shows, or if in fact one or the other is more targeted towards the markets they serve. I don’t know what my company plans to do. It’ll be interesting.

It goes without repeating that the focus of this year’s show was IP everywhere. Specifically how voice, video and data can be efficiently implemented in the telecomm vendors’ space. It’s seen as a battle against the cable MSO’s, but I really wonder:

> It seems that the Telco’s are in an excellent position to capitalize on the wireless infrastructure, as they’ve done so well to date. One kind of wonders why they feel the burning need to have the video side too…

> The cable folk on the other hand have long had the video side of things handled really well and have been continually improving their networks. Why would they feel the desire to take voice business from the Telco market?

It almost seems to me that these guys want to play in the wrong sandbox. Mind you, I’m not against competition in principal and I suppose that it helps to drive technology. But, you have to wonder if the end user really makes out at the end of the day. Either way, it’s good for me and my industry and God knows I’ll try to make the best products for our target as I can.

It was a good show. I enjoyed the classes and I think that it was worthwhile attending. Oddly though, I always feel like I’m in another world during these things, what with all the shiny new tech and glitter and fanfare. In the end, I miss my wife and home and reality begins looking really good after about 3 days. I’ll be happy to be back.

Now it’s time to apply what we learned.

I’ve found it kind of interesting that for the last several years, “Carrier Class Ethernet” has been a tag line for various products. The notion behind that phrase is that traditional LAN-based Ethernet doesn’t have the reliability and quality of service (QoS) that other transports like ATM, SONET, SDH, etc. have always had. All very true.

So, various vendors and industry consortia have been trying to get it right. Standards have emerged that are intended to address the gap and to make it possible for Ethernet to be the true transport for the world’s IP and other traffic. MPLS was developed, for example, to address a few needs. One was the need to make it possible to establish a known route through a network, between various end-points. Another reason was to allow equipment to be able to make switching decisions very rapidly, doing the least amount of frame disassembly and inspection as possible.

All that is to say that Ethernet has had kind of a rough road becoming the primary delivery vehicle throughout a Carrier’s network. SuperComm this year has seemed to focus more heavily than ever on IP-based services (voice, video, data, etc. - see the prior post), with a tacit belief that all this will eventually be carried by good old Ethernet.

Here’s some interesting information (based on various vendor’s opinions):

1. There needs to be better QoS features within Ethernet. Vendors then need to make consistent use of them so that end-to-end quality can be assured.

2. Ethernet is quite complex to set up and run when it lives within the core of a large Metro- or Wide- area network. Don’t presume that it’s somehow vastly easier than current technologies.

3. While ATM is assuredly on the decline, last year more ATM gear shipped than ever before. Vendors have de-emphasized development of ATM gear in favor of Ethernet, but these things take time for adoption, once it starts.

4. To achieve the kinds of bandwidth and bandwidth density that the market feels will be necessary, a lot of the existing SONET/SDH infrastructure may not be adequate. If you believe that a consumer will need 50 Mbps, that seems very true. Thus, carriers are pushing fiber directly to xDSL DSLAMs at Gig-E and 10Gig-E line rates. That’s expensive and time consuming.

5. It’s not clear to me whether Ethernet in the core is really any cheaper for the carriers or the consumers directly. I think that various vendors are in the same predicament. Time will shake a lot of that out, but at the moment it could well be mainly customer perception, rather than reality, that shapes the desire for “All Ethernet, All the Time”.

That’s all the news that’s fit to print and I have to get ready for another day at the show.

One thing is very clear: The so-called “triple play” is at the top of the telephony providers’ list of ” things to do”.

Not that this is some kind of news-flash, but there is certainly more evidence at the SuperComm show this year that it’s the current hot-ticket than I’ve seen previously.

That’s what they agree on. What’s perhaps more interesting is what they don’t. For example, one provider claims that 20 Mbps will serve the needs of the market for the next 5 years. Another vendor believes that’s a pipe dream and that in fact, consumers would be using 100 Mbps if it was available today. Still others claim that the only true answer to the bandwidth problem is to run fiber directly to the customer premises. The counter-claim is that one can achieve the same results by parking fiber at the curb, within the last 500 feet of the customer.

One thing is clear to me: There will be no single solution in the coming years that addresses all of the projected needs for bandwidth and associated content. It’s in this blend of technologies that a number of opportunities lie. Moreover, the types of services that will become possible once those kinds of data rates are achieved make for yet more opportunities for those creative enough and gutsy enough to pursue ‘em.

Areas and technologies to watch:

1. Beware the impact of service providers who “selectively manage” their bandwidth. That is, if you buy your pipe from provider “x”, watch out for how they manage the traffic for some service that is provided by another service vendor. If the pipe vendor also offers that service, you may not get the performance you expect. Anti-competitive? You tell me.

2. Mobile content. Look for companies to begin working the notion of “portable data” in the sense that they will offer servers (in your home or on the net somewhere) that know your preferences regarding movies, music, email and other content and will make that content available to you regardless of where you are. The implications for the mobile networking folks is obvious.

3. “Narrowcast” video will begin to find new homes once mobile high-speed networks truly become ubiquitous. Keep a close eye on the cellular providers and technologies like WiMAX to see where they’re headed. It’s clear that your data will become location independent. It’ll be a great time to be a podcaster and video-caster.

4. In-home network delivery systems are beginning to mature. Technologies like “media over cable”, power-line networks, phone line networking, etc. are beginning to take their place in the consumer premise.

It’s looking to me like the opportunities in the telecom market are returning. Just watch whats’s happening in the data, video and voice marketplace to get a small taste of the changes that now beginning to occur.

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…