"I've been reading quite a bit lately that the stack is going to be compressed and that for most of the glass guys, the notion will be to run IP apps on GbE and 10GbE networks, mapped onto SONET protocols (but not necessarily SONET gear) on top of WDM, with frame relay and ATM slowly fading from view."
The determining factor is based on who owns the domain, apparently. For example, a large slice of the wide area is quickly giving way to a new order of fiber backbone providers who might favor IP over lambda. But look closely when IP is spoken here. A large amount of inter-router (switch) traffic will actually be MPLS, but is the routing/lambda switching really being taking place under the usual Layer 3 routing protocols?
It's said that ATM cannot scale to the humongous levels of OC-xxx that IP over SONET can, or even IP over Lambda with thin SONET shims. Even the fiber barons, and those who decry "all IP" status are not entirely unified on IP, because even they will use ATM over SONET for certain parts of their network requirements. Take UUNET, for example. Or any of a dozen other upper-tier providers. They have made the claim to me, both orally and via Power Point with shades drawn, that they are entirely IP. To the point of mantra.
That's Great. However, go get a slice of their network for some real heavy duty time-of-day bulk-data transfer stuff, say, in the multi-GB range, and then tell them that it must meet demanding criteria for latency and dropped data, etc.
They will review your requirements, and most times (unless there are some extenuating circumstances) they will put your traffic on their ATM overlay.
Yes, they'll provide you with router interfacing, but when they get your IP traffic onto their own net, the trunks that your data rides over is ATM between pops. Not one which is purely IP over Sonet or Lambda. I suppose that this will change at some point, but as far as I know, the ATM switches are still finding new buyers.
Next, look at not only DSL networks, but emerging fiber to the curb (which will also use a flavor of dsl, namely VDSL), and you find that the preferred means of doing this is to use Sonet to the node, and then passive optical networking (PON) between the main nodes and the subscriber. And in the PON, ATM is finding its way to being the primary transport. Here you have both DSLs and PONs, then, being shaped by the service providers who have historically controlled those domains, and they are using ATM/DSL/SONET.
Your point about using Gb over lambda is one that I've been a proponent of for months over on the NFCTF (and before), and one that Canarie is experimenting with in Canada at this time. I believe that there is merit in exploring those options further, but I don't think that the impetus for doing so is going to come from the incumbents who are set on using ATM and SONET. It will depend on some breakaway thinking that only new players can bring to the game. But when you think about it, the basic difference between Gb and ATM is that Gb doesn't yet extend itself to the class of service capabilities that ATM can.
And maybe Gb never will, while it depends, instead, on the greater amount of "head room" available both with Gb and future 10 Gb speeds which come from the pure girth to get them through the night. Yep, that'll work.
"Maybe in the old world of copper loops there's hope for these older protocols, but I think their time has come and gone. Any comments?"
Their time isn't gone yet. It'll take some time before the older stuff tapers off of the DS_Zero plant, and onto Ethernet frames. Quite some time. Again, depending on the venue.
It's a no brainer between routers in a metro setting, and even over greater WAN distances, now. But between voice PBXs, no matter what the distance, we're still talking about a number of years before a major shift takes place, where an appreciable market share moves to Voice over IP/GbE, or VoIP, in general.
The new format simply isn't compatible, yet, with the long list of legacy termination equipments (CPEs) which continue to look for 64k chunks as they depreciate, and beyond.
In one real case that I am aware of, some decision makers were willing to endure the bleeding edge stages of voip wrt service quality and other unknowns, until someone mentioned that the existing voice mail system, which must also be networked between enterprise locations, cannot do so at this time in an all voip environment.
Not, I should qualify, without incurring another very large cost to change an architecture that isn't broken, first, with no perceived immediate gains. Oh, and while doubling the count of Ethernet ports required in the process. All of which sent the justification process back to the drawing board for the m, and nth, times, respectively.
FAC |
