Hello Teddy, there is no need for you to read more slowly. You've proven to be a quick study in these matters. And of course, at the root level all of your observations were sound ones.
You caught me in one of my more facetious moments when I asked about the Class 5 switches, granted. Having said that, however, a good deal of new voice traffic will actually be supported over these new pipes, at reduced rates thus engendering more traffic, both switched, for the most part at first (to be sure), and simultaneously, and more gradually, over newer packet service arrangements.
Not only by incumbent providers (who will most likely stay with the switched format for the time being), but, by design, the newer competitors who have come onto the scene who will be leading the way to the more innovative packet level services supporting voice and other multimedia trafic over IP and ATM.
Here, when referring to packet voice services, we can get into a long discussion, probably multiple discussions, as to just what voice over IP is, IP telephony, Internet telephony, and so on, but we'll save that for another time. Suffice it to say at this time that some of these newer protocols are truly breakaway approaches to solving the voice problem, and some are simply emulation techniques which reuse or mimic the "old world" PSTN approaches.
Included in the latter are the DSL-based packet voice arrangements which use concentrators and central office multiplexers at the access level. Namely, most of the DSL_AMs and concentrators. Dialups may apply too, but then again, dialups by definition already use a Class 5 switch. But some concentrators (which support multiple line types at the layer 1/2 protocols) actually do support VoIP services with SS7 features from dialup users, too.
--------
Regarding my Class 5 quip, you asked:
"Is that really what they have to do, or could they just buy a couple of high end access concentrators integrated with SS7?
Can additional voice and other traditional POTS services be supported by concentrators integrated into their SS7, as opposed to end office electronic switches? Is that what you are asking? Where? In Ireland?
I don't really know the answer to that, but I suspect not at this time except for a limited number of instances. But that would only be a form of substitution at the network element level, with little significance where going to an all IP scheme was concerned. More like a means of abetting an all ATM mode, not IP. Most access concentrators used for this purpose by established telcos are ATM-based, not IP. IP may ride on top of ATM, however, but then the claim for all IP goes away.
I don't think that many parts of our own PSTN, here in the states, are ready for what you've suggested yet. Note, I stipulated PSTN. Private operators and CLECs who support alternative arrangements can do this now through the use of gateways, but they are not the dominant players who are bound to serve all of the public in a non-discriminatory way.
I suspect that the answer is no, where their PSTN is concerned. I say this NOT because it isn't physically possible to do, but because the operations support systems (OSSes) used in central offices are not tied into the newer access concentrators yet. And the ones which do work in the manner which you suggest must also be tied into OSSes and class 5-linked data bases, which precludes then, the possibility of mutual exclusion, at least for the time being, because there will continue to be a dependency on the Class 5 infrastructure. If not in hardware, then in software.
Also, where DSL is used at the concentrator level, splitters often take the voice portion off and send it directly into a Class 5. It's only where packet level VoverATM and VoIP are implemented that you escape the need to enter a Class 5 port. And even here, unless true Internet telephony is being used, like you say, there is still the dependency to SS7. What you didn't say, though, was that there is still a dependency at the central office level, too, for subscriber data base lookup and pointer information, and indeed, where Phone to Phone is used, entry into Class 5 ports, as well... at the other end.
There are databases and links to these: subscriber, directory, billing, local number portability, E911, client records, etc.. These data bases and subordinate systems are crucial to the way telcos operate, and they would need to be tied into the concentrator schemes before the ILEC could even begin to adopt them. That takes code. That is, if they use the concentrator platforms to support customers who subscribe to their "PSTN" services.
Resellers, and (again,) next gen providers, on the other hand, who fly under the radar screens where tariffs and access charges are concerned, well, those present a different set of issues, altogether. Here we have a different story, the permutations of which would require another message or thread. But they are the aberration, still, and do not represent significant traffic at this time, nor is it fully understood where they will grow to.
But even here, if a reseller or CLEC is providing dsl access in connection with, say, a concentrator, then they must pick off a set of directory numbers, somewhere. If they are reselling ILEC numbers, then they are actually dependent on the class 5 as well, because that is the element that has, so far, been associated with the numbering plans which defines where homing takes place.
And again, this is where the local subscriber data bases are tied into and sometimes reside, as well. The significance of the Class 5 switch is greater than we normally appreciate.
So I'd be inclined to answer 'no' to that question where it applies to PSTN applications for now, and qualify my answer with "at this time."
To be sure, some central offices may be employing the right mix of infrastructure and Operations Support Systems to support concentrator-centric (as opposed to Class 5-centric) switching NOW, but scaling this model is a big investment involving plenty of planning in order to make it happen, and I don't see them being ahead of us here in the states, in that respect, again, not at this time.
There are at least three things about the battle cries of "next gen" "and IP" that seem highly conspicuous to me, and consequently, they tend to stick in my craw. They are really not important matters, as things go, but notable to me just the same.
Anyone not interested in further discussion surrounding these semantics is cautioned to take some caffeine, or kindly invited to leave at this time. No hard feelings, to be sure.
==========
Those three things, from a stream of consciousness (I said three things, above, so I'm going to come up with three), are:
One is, if it is next gen, then it can't be this gen.
Why not just call these new networks SOTAs, for state-of-the-art, or emerging technology, platforms. Such designations would at least put them into the "here and now," even if the "are" still full of futures and quite buggy. Terabit routing, indeed.
Secondly, most of the traffic going over these SOTAnets using dwdm backbones in international venues are NOT all IP. They are carrying tons of other forms of carrier network traffic, predominantly, as well as traffic from some very large enterprises which run the gamut from Voice, to IP, to ATM, to IBM Channel Extension and SNA, to Frame Relay, T1-based video conferencing, and so on.
And you would be surprised to know just how much X.25 and other forms of higher layer data link protocols (HDLCs) are still out there now going over these pipes, as well, not to mention NTSC and PAL program grade television services, too. Guess where all of these services I've listed have been supported in the past. For the most part they were supported on the old world's SDH and SONET networks, and over international satellite networks.
Will they migrate to IP at some point? Yes, most of them will. Is IP supporting them today? For many applications using older proprietary or non-IP protocols (and there are tons of these) only in a limited way up until now on the fat pipes at the aggregate levels of their use. We've not seen the hockey stick profile here yet, where we can say that IP has gone over the top, yet. Even for a great many ISP services, where ATM pipes are the preferred lower layer protocol. IP is simply a tenant there.
But getting back to the proprietary and other non-IP apps, the higher speed interfaces and associated gateway gear needed to make them happen on all the disparate protocols I've mentioned above have been late to market. They are not yet available at the T3, OC-3 and above rates, in other words, where they could be leveraged on a fat pipe or IRU. So, those applications continue to be encapsulated in SONET and SDH high capacity containers, and shipped in their own native states.
Moreover, not only are the line interfaces not ready, but the backend systems themselves need to be converted to IP. Consider an IBM environment where SNA has been the rule of the land for the past thirty years. Now they want to convert to IP. There are not only interface issues on the surface that need to be handled, but all of te other IP considerations, as well. They include DNS (a huge task for large enterprises with the most traffic to send), security, and the whole ball of wax that goes along with any IP addressing and numbering schema for a multinational enterprise. Consequently, many IBM shops continue to send native, and their migrations to IP will very likely be slow and tedious, if and when they get to it.
-----
I think that most people would be surprised to learn just how much of these fat pipes support ATM, over which, all sorts of other things are taking place. Which is the general idea and the primary the reason for ATM in the first place: To support many different platforms and protocols, including all of those I've mentioned above, and then some.
A majority of the IRUs and term leases are for Private Lines of all sizes which are provided on a pass through basis, the ultimate reasons for which the wholesaler or backbone provider has no notion about (what they are used for, nor do they care) in many cases. This is because many of these fat pipes are actually like apple pies that are carved up at the luncheonette counter, and sold to customers by the slice. Here the customers are actually the resellers, and increasingly, telecomm commodities dealers and brokers. Ironically, some of the futures they sell are as old in vintage as many who read these boards, in terms of when those protocols were first used. A little play on words.
Many of the fat pipes get broken down into T3s and derivative T1s etc., even DS-0s, which may, or may not, support native IP. Who knows? More to the point, who cares?
In those cases where Frame Relay and ATM support traffic, they may indeed be supporting IP, which resides upstairs at Layer 3. Do these FR and ATM services qualify for inclusion in class of services being touted as "all IP?"
And thirdly, if everyone is doing the same mantras, then the differentiation component disappears very quickly and "next gen" simply becomes an obligatory claim (as you, too, have suggested, in your own round'bout way) like any other "must carry" item on their repertoir or agenda, such as the disclaimers at the bottom of every press release which put them in the better graces of the regs.
======
These may seem like only semantic arguments, but to those in network engineering at the service provider and large enterprise levels, who must get a grip on what they are actually leasing, they are not trivial considerations, at all. But I make too much of this in a forum such as this, I'm sure. No one here really cares about such matters, except to show off how much we all know. Right? Wrong.
------
Discussing these matters is beneficial, if for no other reason than to gain a fuller understanding of what is actually taking place in the factory which we all too often observe from a distance.
This company does their fair share of bandwagoning, something that is their right to do, to be sure. And something that is very likely their obligation to do, in some perverse way when you get right down to it. Competition and marketecture schtick being the things that they are, today.
Comments and corrections welcome.
Regards, Frank |
