Re: SONET Interconnect (was RE: MCI)
At 10:48 AM 3/26/96 -0500, Shikhar Bajaj wrote:
Currently, the only way of doing this is the "traditional way" of using SONET add-drop muxes to get you up to higher rates. You mux the STS-3c into an STS-12 and then mux the 12's into a STS-48. This is what we are doing in ATDNet which is a ATM OC-48 bidirectional line-switched ring for ARPA
and DoD.
(see http://www.atd.net/atdnet.html).
As per our previous discussion, the trend seems to be putting the switching and transport functions in one box so that you may be able to buy an ATM switch that also does SONET protection switching.
I fail understand, however, why ATM over SONET is desirable when there is such a loss to overhead, especially when viable alternatives may exist to get more bang-for-the-buck. Perhaps someone could enlighten me on this particular datapoint? - paul
According to Paul Ferguson:
At 10:48 AM 3/26/96 -0500, Shikhar Bajaj wrote:
Currently, the only way of doing this is the "traditional way" of using SONET add-drop muxes to get you up to higher rates. You mux the STS-3c into an STS-12 and then mux the 12's into a STS-48. This is what we are doing in ATDNet which is a ATM OC-48 bidirectional line-switched ring for ARPA
and DoD.
(see http://www.atd.net/atdnet.html).
As per our previous discussion, the trend seems to be putting the switching and transport functions in one box so that you may be able to buy an ATM switch that also does SONET protection switching.
I fail understand, however, why ATM over SONET is desirable when there is such a loss to overhead, especially when viable alternatives may exist to get more bang-for-the-buck.
Perhaps someone could enlighten me on this particular datapoint?
Several of our clients seriously consider ATM/SONET the best way to go because they feel that a switched technology like ATM is the best single technology (currently) to offer them high speed and support for multiple applications (like video and voice, as well as data). They are not just sending around 200-byte IP packets. Furthermore, the ability to get quality of service support and guarantees is important them. They don't think that RSVP, when it comes, will be enough. Finally, to them, the economics makes sense. They understand the limitations (i.e. overheads) and believe that they are acceptable. If viable alternatives exist that are cheaper and better for your applications, you should use them. All I'm saying is that to lots of other people, ATM/SONET is just as viable. Shikhar
I fail understand, however, why ATM over SONET is desirable when there is such a loss to overhead, especially when viable alternatives may exist to get more bang-for-the-buck.
Perhaps someone could enlighten me on this particular datapoint?
Telecom and datacom have historically been different worlds. Telecom kept coming up with faster ways to do standard-interface long haul, and datacom kept jumping into each new telecom technology. Eventually the telecom people and the datacom people started talking to each other and they decided to come up with an ubertechnology that would solve all problems in both fields, once and for all. Only a small number of the datacom people in the room knew anything about IP. IP people have historically been "tin cups and string" users; as a rule, we believe in context free switching (no virtual circuits), and we believe in end-to-end {congestion control, error checking, connection management, and reassembly}. IP's view is that you can build arbitrary complexity on top of a good fabric, whereas an overspecified fabric makes down-simulation very expensive and often unusable. Traditional datacom and telecom people believe the opposite of all these things. Witness X.25 as the canonical example of traditional principles in action. Both the X.25/ISO/ATM/telecom crowd, and the IP/datagram/end-to-end crowd, believe that their ideology is best since it enables all other things to be layered on top. What ATM has is an excellent set of buzzwords and a lot of vendor support. What IP has is an actual market with real end-to-end products and users. With iPhone and cu-seeme and mbone starting to come into wide use, we are running into a situation where IP needs more bandwidth than it can get from most of the pre-ATM telecom solutions. The IP looks at ATM and says "this thing wastes a lot of bandwidth*delay on things I'm already doing end-to-end, and it does them in a way that my end-to-end implementation considers pathological, so let's look for another solution." Hmmm, ATM seems to be running on top of SONET. SONET is faster than modulating a bent coathanger, let's run IP over SONET. A worldwide fabric of IP-over-SONET and IP-over-bent-coathangers and IP-over- tin-cups-and-string is _going_ to occur, and soon. A worldwide fabric of end-to-end ATM may or may not occur, depending on the PR capabilities of the folks who think it's the right way to go. One of these nets will come up sooner, work better, and be cheaper. The other one will go the way of X.25. Where's Padlipski when we need him?
participants (3)
-
bajaj＠bellcore.com -
Paul A Vixie -
Paul Ferguson