Frank:
You gave a really great response to my high level hand waving
comment on SONET rings and wasted bandwidth. Yours is the
kind of data that you don't get from whitepaper and presentations.
I was told the about the 50% wasted dual ring bandwidth story by
an "expert" at a high level strategy conference about 3 years ago as
a reason why you should drop SONET for IP over fiber (whatever
that as in his head).
You have just given another reason why SONET is still there and
doing very well. Thanks.
However, carriers do sell this standby bandwidth on 2-fiber
rings to ISPs and other organizations on a more
tentative and discounted basis, with the prior knowledge that
they may be "pre-empted" or "bumped" when a
break occurs. Such leads to a form of double jeopardy for these
subscribers, if you think about it. They go out of
service when fiber fails "anywhere" along the ring (on any arc of
the ring), even if their end point pairs are not on
the arc that was broken. But cash-strapped ISPs and others will
opt for this, especially if their networks are
resilient at the upper layers (reroutable).
It sounds like the marketplace has invented a crude but very useful
two tier QoS- SONET availability that is either high or
questionable. This is a 'found feature' that the community might
resist losing if another technology or architecture is deployed.
It's the user's responsibility, in the end, to manage their own
"mesh" network connections when they decide to
forego the SLA guarantees that are afforded by self healing ring
provisions. And this appears to be gaining a lot of
interest lately, both in the use of legacy carrier network facilities,
and at higher speeds using WDM and optical
switching and routing.
So there must be a quite complex manual network management job
in the event of failure? Are there autonomous recovery systems out
there?
Finally, there are large regional networks which are made up of
linear SONET overlays that are used for the voice
switching network. These usually terminate in digital cross
connects (DCSes, or Digital Access-Cross Connects
(DACSes), and often do not enjoy the benefits of all of their
routes being on self healing rings, at the fiber layer.
Possibly because they don't need the benefits of self healing
SONET. The PSTN has a LOT of retry and recovery mechanisms
at every level, and a hole lot of well thought out traffic engineered
redundancy. SS7 alone does a really good job of trunk outage
handling, and bypassing bad routes. But the PSTN is the worlds
largest mesh network, and we've come to take it for granted.
Sometimes (as if we needed a way to prove this), not often,
but sometimes, it takes a DCS mesh up to a day to
fully rebuild their connection tables and recover, after a fiber or
DCS failure has occurred. In this respect we see
cases where instead of wasting bandwidth for standby purposes,
the carrier may actually be acting in a way that is
overly frugal with the stuff.
As a software switching guy, I've often wondered why DAC/DCS's
are so slow and manual. I've looked at the API and command sets
of digital cross connects, and I've shaken my head at their volume
and complexity. For the simple function of setting up and tearing
down a path, things got out of hand really quickly. The audit
functions alone for examining the cross connect matrix are
unbelievable, but I guess they are necessary.
And I suppose if you let end users control path set up and tear
down, you would lose control of the network. For a whole lot less
than the amount of money, say Tellabs has made over the years, you
could design and deploy autonomous switching and recovery
software for a switch that didn't need 800 signaling types, 200
features, and a monster OA&M, in a couple of years.
Mind you you'd need a standard- MGCP with variable bandwidth,
anyone? I wonder if anyone is working on this for bandwidth on
demand. Of course there are minor issues like billing to consider.
And there is a 'grass is always greener' effect in software- other
peoples jobs always seem easier from the outside. |
