Hi Tera Bit,
>>Are you aware of efforts by any carriers to migrate 1/0 and 3/1 services off traditional DACs equipment like equipment made by TLAB and LU?<<
The shift taking place right now - across the board - in a more general sense, is what you are referring to, I think? For the majority of users whose access and transport links still function at the sub-OC-48 or 2.5 Gb/s levels, which takes into account all but the largest entities, they still demand a physical layer pipe of a SONET-containerized nature to support upper layer protocols, such as ATM, FR and IP.
Thus, DACS-, or Digital Cross Connect-(DCS-) provided delivery still suffices, and will continue to suffice, for aggregation and grooming purposes for quite some time to come. What we'll likely see is more protocol integration at the DCS level itself, such as what has taken place at the T1 level with products such as the Vina Technologies universal channel bank device, which does multi-protocol integration at the T1 level.
IOW, It incorporates time slot interchange, and routing, within the same [partitioned?] fabric, and aggregates everything up to a T1 stream.
[Note I prefer to use the generic three letter acronym here, which is DCS, since DACS (digital access cross-connect system), even though it has been assimilated into the lexicon as a generic DCS, it is nonetheless a trademark of ATT/LU. The generic is DCS, FWIW.]
What I'm getting at here is that traditional DCSs still suffice at the throughput levels I've stipulated, i.e., below OC-48 and OC-192, when the user does not have access to a proprietary fiber or wireless feed that is free standing. Which is 99.xx percent of all cases.
Having said that, there is a tremendous shift underway concerning what protocols are employed within those T1s, T3s and OC-n's. But the fundamental building blocks continue to be SONET-based, in modules that are groomed, as you say, by DCSs.
>> Presumably, much of the grooming could take place over a 3/1 or 1/0 ATM circuit emulation box. "Mulit-Service" currently means ATM & Frame to the analyst community (as it relates to products from ASND, CSCO, LU, NN and NT).<<
I'm not sure if that last statement can be regarded as being true for all situations. Multi-service does not necessarily require the use of ATM, although in many cases as you note, this is the implication. Increasingly, multi-service implies the co-existence of multiple services at the 'application' level (as well as defined by their supporting protocol layers), supported by a common undercarriage. This does not necessarily have to be uniquely ATM, however. Increasingly, in fact, ATM will be eliminated from the formula, in many environments.
>> However, I expect several large deployments of circuit grooming over ATM to displace traditional DACs networks this year.<<
While that is conceivable, and actually happening under certain circumstances, the ATM stream still resides within an optical carrier (OC) container, and OC's are switchable in devices such as the TITAN 5500 and others, just the same. It's a function of granularity, and at what level you want to discuss the matter.
OC-ification (the use of SONET formats) takes place even in DWDM and IP over lambda hardware situations, if you'll note. If you take a standard DWDM you'll note in its specifications that it will handle payloads specified at OC-48 or OC-192. The SONET headers and framing don't go away, in other words.
These environments, even where DCSs are not required at the super-OC-192 levels, are packaged in SONET format, for reasons having to do with convenience of precedent. Where this begins to differ is when a DWDM-derived wavelength is used to support an IEEE or ANSI type of protocol such as Gigabit Ethernet or Fibre Channel, but these are still the exception at this stage of the game, where most carrier/SP-supported services are concerned.
IMO, ATM will continue to be a service that falls within the SONET-ized format, however, and as such, the vast majority of these streams will continue to be groomed and mapped at he DCS level, for the foreseeable future. In those situations where the ATM device can do it all, it will then have become the super DCS, and it will subsume the functionality of the more mundane features or the traditional DCS as well.
>>TLAB is a great company but I think they need to aquire or be aquired. Circuit grooming over ATM circuit emulation will hurt them, IMO.<<
If anyone is well positioned to handle this, it's probably TLAB, for reasons I've cited above (the super DCS alternative).
What TLAB must be concerned about, however, is where the displacing protocol is not ATM, rather, where it is IP or packet over SONET (POS) or packet over lambda. Let's hear what others have to say here.
Thanks for the reply, and Regards, Frank Coluccio |
