re: fiberopticsonline.com{6EB4B666-A1A5-11D3-9A73-00A0C9C83AFB}&Bucket=&Featured=&VNETCOOKIE=NO
Ken, the article you referenced (above) is IMO good for its provocative and instructive value, and it paves the way to some discussion on purer forms of optical networking, primarily in the public network spaces. I should note, however, that it has its share of conundrums and contradictions, if you read it keeping in mind the literal meanings of the technical terms used.
But given the insights that I detect in the authors approach, I'll write those apparent shortcomings off to limited page real estate on the copy, and a tight deadline. -s-
For example:
"High-performance routers feature high bit rate optical interfaces (OC-48c and OC-192c), which obviates the need for high bit rate multiplexing traditionally performed by a SONET terminal."
?
While the muxing element might be eliminated, the concatenated optical carrier levels of OC-48c and OC-192c are still SONET framing formats. What the author fails to adequately highlight, IMO, is that even these new "optical" devices continue to use SONET containerization (framing), predominantly. Although, the new distinguishing characteristics of the emerging terabits -and many gigabit dwdm approaches- he described do, in fact, omit many of the other heavy baggage aspects which historically have been used by the xLECs and IXCs.
The latter constructs that I'm referring to are data link layer hooks for self healing capabilities, surveillance, traffic management, accounting, order wires, carrier-reserved special data channels, etc. Instead, the newer model uses a "thinner" SONET layer, but a SONET layer nonetheless, that avoids many of the overhead issues of the networking attributes I've just [partially] listed. And this thinning down process is effected by the elimination, or nullification, of many of the overhead functions in the SONET header.
You say,
"The author points out that many of the solutions proposed to eliminate the SONET layer just replace that layer with another box thereby reducing the cost benefits and inserting unnecessary complexity into the backbone. What solutions do you think he is talking about?"
In part, he is talking about some of the same features I've just enumerated two paragraphs up.
Self healing and traffic management capabilities, particularly, are missing when you strip the overhead bits out of the "normal" SONET headers which exist prior to thinning it down, and these have to be compensated for somewhere else, if the same level of restoration and surveillance are to be maintained.
But there are some philosophical factors that come into play here that may obfuscate this issue, such as IP Layer restoration versus physical and SONET layer restoration schemes, etc. The author points this out by stating:
"Terabit routers also handle equipment protection, another SONET function, which further dilutes the need for SONET."
And these are fine, but for the moment these can only be implemented in the deeper segments of core networking, but they do little for end office situations where an ILEC, say, needs to feed a number of end offices for voice circuit switching and private line data services, including Internet access trunks. In other words, we'll see emerging forms of restoration capabilities in the edge and core before we'll see them in the telco distribution and last mile access layers.
As noted above, SONET and SDH "containers," or framing formats such as OC-48, will continue to dominate in high speed streams for quite some time. This is because the vast majority of all local distribution schemes (both by ILECs and CLECs, alike) continue to be supportive of digital cross connect systems (DCSs) and these boxes use T1, T3 and SONET formats, almost exclusively. Even when he port is optically defined.
What this means is that if a service provider wants their flows to be communicable to end users over today's last mile provisions, then they still have to define those flows in terms that SONET boxes can interpret and forward.
Unless, of course, there is dark fiber in place to support DWDM to the building, in which case IEEE and ANSI protocols could substitute for the SONET formats. But then you run into other problems, such as the extensibility and scalability of these protocols into the greater WAN, which is very difficult to do where the IXCs do not support them. So, in the end, these "other" protocols such as Gigabit Ethernet, Fiber Channel, and pure IP over lambda are still very much relegated to campus and intranet uses, where dark fiber or lambda contracts can be put in effect, but where extending these protocols to other communities remains an unlikely capability at affordable pricing, during the near term.
All in all, a very good article for the reasons I mentioned in my opening sentence.
Regards, Frank Coluccio
|
