re: declining SONET emphasis, debunking "self heal", hello to alternate schemes
Hello All,
In a recent discussion on the GBLX board, I made reference to how Fibre Channel, among other lower layer protocols such as Packet over SONET (POS) and packet over lambda would replace straight SONET for many applications, and why. Of course, as time goes by.. but not as slowly as I would have predicted even as recently as six months ago.
At the same time, I attempted to debunk some of the myth surrounding many of the SONET self-healing claims made by many carriers which have left many to think that all services which ride over SONET facilities are assured the benefits of being fail safe, which of course, they are not. I've copied most of that post below for your review and comments.
I've since come across a rather well written tutorial by Edwin Lee on Fibre Channel. FC is becoming a more relevant network tool each day, if not for its own arbitrated loop applications, then for its ability to transport Ethernet and IP, or whatever.
As fiber optic cable continues to proliferate, and as wavelength services become more available, FC will be used to help redefine the distances between workplace geographies, because when combined with fiber attributes, it removes the distance limitations that heretofore existed for storage area networks, metro LANs, and other copper and fiber-based applications which have, up until now, been relegated to in -building reaches, only. These distance factors are no longer the extremely limiting issues that they once were.
Of course, this all presupposes that dark fiber is attainable, or that a fiber carrier in your area is making lambda based services available. And these offerings, too, are increasing with time.
performancecomputing.com
If you read this tute you can begin to deduce how some of the transformation might take place, given the shift we now see taking place away from the more traditional forms of switched voice services, to a more data centric set of flows, and that said "data" will soon begin to subsume voice, itself, in packetized forms. Comments and corrections welcome.
Regards, Frank Coluccio
=======================
from: Message 11839529 :
-----begin:
I also maintain that Global Crossing's restoration capabilities are a
competitive advantage for them. I went to great lengths to demonstrate
that they had no shortage of ways to achieve this. Your post would lead
the uninitiated to believe that I was arguing that they don't possess this
capability. On the contrary. I listed many different ways that they could
leverage their two, soon three, cable routes to Europe in order to back
themselves up. I even stated, in two separate places, that they do have the
ability to provide traditional (what I termed generic) self healing
of the wraparound type, so your message is a little puzzling to me.
I think that semantics, perhaps, are beginning to divide us to some extent,
since we are probably calling different things by the same name, and/or
using different names to refer to the same thing. It's called a violent
agreement by some, although we do depart materially, in other areas.
How's that for double talk? (Don't even think about it..;-)
I've attempted to differentiate between what is normally termed, in the
generic sense, Sonet/SDH "self healing" techniques, which are spelled out
in the ITU and ANSI standards, i.e., the Sonet fiber element loop back,
the Sonet terminal loop back, and other wraparounds of the Sonet system
elements themselves, which characterize the need for counter-rotating
rings... I've tried to differentiate those from the other forms of restore
techniques that are available to users (and to GBLX themselves, both
now, and when they decide that they want to forego "fat" Sonet on some
applications, when their platforms will permit it). And they will.
My point here is this. These standards-based methods which are written
into Sonet network element designs are not the only procedures that
the carrier and its users will wind up using. Nor, in the end, will these
standards-based features be forced upon users, nor will GBLX make this
a mandatory take-it-or-leave-it on every sale of bandwidth that they ever
make. In my experience with carriers, I've found that this is not the way
things work. A poignant example of this follows, immediately.
Your use of QWST as an example is a perfect case in point. They, too,
make use of self-healing rings, and they also put up signage boasting
claims similar to those of GBLX on their web site, if I might add.
Re: GBLX, you stated:
Let's take it straight from the global crossing web site:
globalcrossing.com
"The Global Crossing Network is being engineered and constructed
using the latest in fiber optic technology, including self-healing ring
structures, erbium-doped fiber amplifier repeaters, wavelength division
multiplexing, and the use of redundant capacity to ensure instantaneous
restoration....."
Later, you cited QWST to reinforce your point:
Fiber rings are not new. Qwest uses them as large interconnecting
rings across the United States. Rings are now used between most telco
central offices to insure reliability, and most CLECs use metropolitan rings
as they loop fiber between customer locations within a city.
That's all very well and good. Everyone knows this, like you say. But I
regard this a form of obligatory rhetoric. Consider, the QWST site
also states:
From qwest.net :
""The Qwest network is built with the industry's most advanced
technologies. It offers 10 gigabit, OC-192 speed and is constructed
on a "self-healing" Sonet ring and 2.4 gigabit (OC-48) Internet
Protocol architecture.""
Now consider this: Earlier today I posted another message (#3125) which
revealed that the foregoing isn't always true despite what their
web site states, and despite what popular impressions suggest:
From:
zdnet.com
Severed cable stalls Internet for 12 hours
By Chris Gonsalves, PC Week
October 3, 1999 9:00 PM PT
A fiber-optic cable cut in Ohio disrupted Internet traffic across the United
States for nearly 12 hours last week before being repaired.
Normal network traffic was restored just before midnight Wednesday on
four OC-192 lines that were accidentally severed by a gas
company employee digging with a backhoe about 30 miles east of
Cleveland, according to Vaughan Harring, a spokesman for GTE
Internetworking, in Burlington, Mass.
Technicians from GTE and Qwest Communications International Inc.,
which share ownership and maintenance responsibilities...
In the post I'm referring to, it was qwst who submitted the outage report
to the FCC. Note, breaks are inevitable, and I'm not singling qwst out for
any other reason than to demonstrate what normally occurs, despite what
web sites say, and despite which carrier we elect to speak about. These
collective conditions apply to all of them..
-----------
It would be easy to suggest that this is just a fluke, but it isn't. The point is
that there are many, many Sonet systems employing linear topologies (or
they may be riding over a ring which relegates them to preempt status in
times of failures) along routes which are not protected by self healing,
despite the fact that the party line at each carrier says otherwise. And,
despite the fact that many other systems riding over the same physical
routes are protected by self healing.
-----------
The remainder of your post is of interest to me because it embodies the
gist of much of the debate, although only one-sided thus far, taking place
right now, about dumbing down the network and why it can or can't
happen, soon. And of course, a major set of objectives in dumbing down
networks is removing layers of inefficiency where new techs permit.
Please allow me to provide you with some counter-point on some of your
points, while possibly agreeing with others.
You stated:
"There is a common misperception that design decisions revolve
around "sonet vs. IP". This is not a zero sum game. Sonet is a layer 1
framing standard, whereas IP is a layer 3 protocol. They both have their
place (although granted wavelength division developments may make
Sonet obsolete at some future time)."
Sonet is far more than a framing standard. Once you get away from
that idea and begin looking at the hardware provisions, along with all of
the associated operations support systems (OSSes) that it takes to keep it
going, this fact comes shining through in a flash.
There is a religious war going on right now, and it's being waged by the
net-heads and some forward looking incumbents, who are growing in numbers,
to do away with, or reduce Sonet, significantly.
Yes, there is a perception, but not a misperception. And for good reasons.
Are vendors beginning to listen to the NSPs? Yes, they are. Can the vendors
and the xSPs extricate themselves from Sonet overnight? No, but they are
dumbing it down, as I have stated here on many occasions. And in so
doing, they remove many of the hooks that go into the administrative and
other overhead functions of Sonet/SDH including many of the hooks that
are responsible for wraparound "self healing" of the type we've been
discussing, i.e., ITU/ANSI for SDH/Sonet.
The reasons for this have more to do than just cost and heavily-
administrative bulk. SONET can't scale with current and future bandwidth
deployments, anymore. Stated another way, it adds additional layers of
complexity and cost to the mix, and its price-performance just doesn't cut
it anymore, at the levels where bandwidth is now being unleashed. It's
tapped out, and to a large extent, perfunctory.
Even in the lowest layers where framing takes place, there are other things
happening, as well. And Sonet extends into a flavor of surveillance and
neighborhood watch scheme that is all its own. It does more than just the
framing of bits and bytes.
I don't think that Sonet is going away soon, and I stated this earlier today.
The industry will hold on to it for some time for its containerization
qualities at the port level. But I do see it getting skinny'ed down to the
mere framing you speak of, and nothing more. As thin as possible, and in
some cases it will be eliminated in favor of different media convergence
techniques, such as fibre channel, for GbE and 10 GbE, and other forms
of almost-direct, and direct, lambda mapping.
The following is an earlier post of mine (#3084) that touches on the same
subject:
Message 11812174
-------
If we address the final points in your message having to do with specific
IP and unroutable protocols, I would agree with you in a flash, except for
two things.
One, bandwidth is rising too fast to be worried about bandwidth
bottlenecking of the type implied by the restrictive conditions you
described. Unless, in some instances, you actually use Sonet.
And two, where bandwidth doesn't cut it alone, faster routers are on the
way which will take many core and edge [even some enterprise] routers
from OC-3 and OC-12 directly to OC-48, and beyond, having the effect
of clearing the passages, for a while..
To a great extent, the argument for staying with Sonet on the basis of the
limitations of pipe sizes and inadequate router speeds is in some ways
merely a form of self fulfillment at some point, not to mention that it does
nothing to offset those conditions.
"You have to use it because it is there," is what it amounts to, to me.
There are a growing number of alternatives to Sonet on the horizon,
alternatives that can do many things that Sonet cannot. The reverse cannot
be stated, except for those features which are soon to be supplanted by
IP and ATM, anyway.
Even if we need to hold onto the the framing format, or the
containerization, as I like to call it, that's okay. Vendors and carriers will
continue to have need for this, for productizing their offerings according to
a given scale, and maintain some points of reference. For a while...
I am not suggesting that there is a product, or even a single agreed-to spec
for thinning down the Sonet layer, yet. Instead, I presented some reasons
why I think that it is coming, soon. Of course, vendors outside the traditional
telco carrier space have already begun. Nexabit, for one, seeks to eliminate
as much of Sonet as possible in their future releases. What does this tell you?
And if you disagree, then how do you reconcile your disagreement with GBLX's
decision to use them?
Regards, Frank Coluccio
------end |
