Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Silkroad -- Ignore unavailable to you. Want to Upgrade?

To: ahhaha who wrote (452)	8/5/1999 6:58:00 PM
From: Frank A. Coluccio	Read Replies (2) \| Respond to of 626

"They've stepped out of the shadows and fired a giant salvo." It certainly appears that way. It's only now that the boldness of their approach is starting to penetrate. I can envision some dilemmas that they and their early adopters will face in certain scenarios. Let me babble a bit, and you and others can correct me where I go off... We can consider, first, those nodes which serve as junction points [typically, digital cross-connect nodes and add-drop multiplexer points], where larger flows are commonly groomed and filled with voice grade DS0s, T1s/T3s, and where exchanges and handoffs take place between disparate carriers or ISPs, or even enterprises and their service providers. I would be interested in knowing how they plan to achieve these sorts of networking activities. We spoke about these earlier in the thread, but we never resolved anything amidst all of the catharsis-seeking. I will assume that if an OC-48 or OC-192 optical stream is carried over one of SR's systems, then that OC-x signal will at some point need to be extracted from their larger flow, using a tuned RF method of some sort. How is this OC-x broken down into its constituent T1s and T3s for distribution purposes, once it hits the remote SR device? Disassembly of the OC-48 (2.5 Gb/s stream) or 192 stream (10 Gb/s), and dissemination of its constituent parts, are equally important to the act of creating the massive flows, either for routing discrete payloads to other nodes, or for exchanging traffic with end users whose line rates might only be on the order of a T1 (1.5 Mb/s) or at most a T3 or OC3. Compare these user rates to those of the OC-192 whose girth contains 192 T3s, or maybe as many as 5,376 T1s, or any combination of T3s and T1s in between. This is what the real world of traffic is made up of. Hundreds of thousands of T1s and other sub-OC-x rates from end users, typically. How will SR do this without some form of industry-compatible time slot interchanger in tandem with an array of ports capable of satisfying all of these feeds? The answer to this is that it will need to enter a DCS, or digital cross-connect system while preserving the integrity of the OC-48 or the OC-192 at some optical level of the types made by ALA or TLAB, etc. This may be difficult to do if they ignore the conventions and the underlying syntax contained in SONET headers. For these reasons, two things appear to be likely to me at this time. (1) that SR engines will be used primarily as "dense route" aggregation vehicles, such as those required between core routers on the Internet's backbones, and not those which are needed between clusters of largely heterogeneous traffic types (no mixed marriages, in other words); and, (2) in the future, they will need to devise some method of creating (accepting and launching) the same types of channelized bundles which are now common to the rest of the industry, from at least the T3 level on up, if not the T1 level. This need will vary inversely with their success as a function of penetration and overall presence, over time. But there will be no way for them to get there without having to accommodate this conundrum during the ramp up stages, if they are to be successful (in mixed marraiges, in any event). Right now they are taking information from various sources and compactifying individual large flows (which are already aggregations of many smaller flows) onto an even denser flow. They must also be able to selectively de-constitute that flow at the usual nexus points and redirect subordinate streams (i.e., virtual tributaries) in ways which are similar to the mapping techniques used today by conventional central office equipment. [I know, I know, don't say it.] Otherwise, they will find themselves stranded in some imporatant ways, unless those who purchase their wares are accommodating in principle, and make the necessary adjustments to deal with such inflexible flows until the model has had some time to become more commonplace. Well, I said that I would babble a bit, didn't I?