Doug, I'm back with Part 2 as I stated I would.
>Do you foresee a shift towards IP on Sonet with QoS
and is that the likely route for new Carriers. <
If you want the text book answer, the one that I would use
to pass an exam, here goes.
Yes, IP will be mapped directly to SONET with minimal
intervention or involvement by Layer 2 constructs. And both
QoS and ToS features will be employed, due to the
momentum they possess already, and because if IP or ATM
are going to be used, these quality measures would be hard
to live without. This is due to the built in arithmetic
associated with both models.
-----
Now, if you want my more honest answer, I don't know.
There are too many emerging options, some of which may
truly yield some breakaway functionality that we are not
accustomed to considering yet. It's too early to say at this
point what carriers will or wont do over the next two to
three years.
If you consider the following, the preceding sentence makes
more sense: Just twelve to eighteen months ago, many
of the options that now seem likely to take place at
this time didn't even exist yet in commercial product
form.
-----
Now if you want to indulge me for a different type of
answer, one with some historical background and some early
precedents cited, read on.
On the other hand, if you or anyone else has seen enough
already and is getting bored, have a good evening.
Otherwise I invite you to read on.
-----
Expanded Reply:
Carriers are having problems deciphering the many options
that now present themselves in the WAN. Especially those
which address the optical domain. There are more of them,
scarier in some ways, and riskier from the standpoint of their
inevitable short life expectancies. What was last year's next
generation solution in many cases turns out to be this years
boat anchor.
When IBM introduced its SNA model during the Seventies,
it was introduced as a means of ensuring robustness against
the frailties and unreliability associated with analog private
lines. SNA is still being used today, carrying more data than
it ever did before, if not in actual link numbers, then in the
capacity handled by each link. Unusually massive flows, in
some cases.
The longevity and inheritance factors here are attributable to
the investment in both plant and code. Hundreds, thousands
of person years of coding and application profile engineering
in individual user organizations. This continues up to this day
in many of those orgs whose mission critical systems are still
mainframe dependent.
The reliability and error performance of today's fiber
networks, however, are now orders of magnitude improved
over those that SNA was designed to neutralize, 25 years
ago. Needless to say, SNA would never be designed today
for that very reason. Why shoot a horse when it is already
dead?
Yet, SNA proliferates, even while it is being trimmed down
with IP front end gateways and nodal processors.
Mainframes are now, suddenly, chic.
----
Did I get off your topic? Sorry... Your question revolves
around dropping IP on top of SONET, and introducing QoS
somewhere in the mix.
While that was momentarily fashionable a couple of weeks
or months ago, this approach now faces new competition
from the camp that would impart IP directly onto lambdas,
i.e., onto the underlying wavelengths beneath the physical
strand, itself. But I tend to think that the IP crowd may be
getting carried away with itself now. Can you tell that I'm
getting just a bit mischievous here?
My first impulse here is to ask, why?
Why would you want to do that in the first place? You are
taking a perfectly good Ethernet frame and subjecting it to a
protocol that was designed to protect against a nuclear blast,
at a time when fiber optics was never seen as anything but a
means to adorn a Christmas Tree in front of a light source.
In networking we have battles being waged on multiple
fronts, and new claims of solutions coming out daily:
IP vs ATM, switching vs routing, VoIP vs VTOA, VPNs vs
Intranets, the list goes on. Underneath all of this noise
resides the optical layer, where there are, to say the least, no
shortages of new ways to tap and route bandwidth reserves.
Most of the new propositions for tapping Gilder's Fiber
Sphere are credible ones, and they are making it extremely
tough for those in charge of buying decisions.
But we deal with one thing at a time, and sometimes we fail
to focus on the newer approaches while we take the time to
digest what debuted at last year's, or the year before's,
SUPERCOM.
Having said that, carriers can't be chasing their tails
indefinitely. They must make some decisions at some point,
and stick with them, or they'll never make any money. So
they make a choice, for better or worse. Without
clairvoyance, they really don't know.
In the situation you've presented, they must choose on the
basis of what they are charged with carrying in the way of a
traffic mix, the routes they must traverse, and with whom
they choose to interface and exchange traffic. Everything
else is religion, financial, and political, and not necessarily in
that order.
If they are a brand new carrier, like LVLT, GBLX, QWST,
or a fledgling CLEC with a niche target market, they may
take two principal approaches, and stuff everything onto
them. At Layers 2 and 3, with neither ATM no IP being
fully victorious yet in dealing with all traffic types, new
carriers in the class usually choose both. How they get their
IP and ATM onto the glass is where the tough decisions are
that they must now face, where only a year ago the default
was SONET exclusively.
If they are an older, established carrier, their freedom of
choice may be less straightforward, having to cater to the
provisions and types of networks they already have in place.
To do differently would mean having to undo almost all of
the customer related network fabric texture that they have
spent years developing. The same kind of investment
protection is at play here as that of the financial institution
who must hold on to their SNA: Thousands, in the case of
the larger carriers, perhaps tens of thousands, of person
years of building and development.
For these reasons, older and more established carriers will
usually lean almost entirely towards ATM, and if and
when they must, they will superimpose IP on top of the
ATM layer. And where does ATM fit like a glove for these
older organizations? On top of their Sonet networks, usually.
Although, there is now evidence that even the ILECs will be
turning their attention to optical based systems. Not because
of any new found sense of adventure, but because they
simply cannot keep up with the costs, labor and other
logistic issues associated with the Internet bandwidth
explosion. There, I've said it. The Internet and Private Fiber
Network Bandwidth Explosion.
[Curtis B., you listening?]
Before I was just kibitzing, but seriously, why think in terms
of encapsulating LAN payloads today in IP - where else do
we get the Layer 2 frames from? - when optical carriage
would only be complexified immensely by doing so?
Improved visibility through abundant optical paths almost
cries out for a new means to identify payloads and their
destinations. So, the IP packet layer inserts some noise
here that I think must be looked at again, and this time, with
a more open mind.
IP is fast becoming the chief protocol used in tail section
distribution nets, at desktops and other central site nodes,
because of its legacy rules surrounding addressing schemes
and other administrative qualities. No problem there, since
everybody needs an address.
But in the optical domain it is a superficial component being
brought forward by inheritance, principally, to the point of
being redundant and even disruptive to the entire optical
paradigm. Why use it?
Why use it in optical transport networks for transiting
purposes? Perhaps this is where Tag and MPLS fits into the
picture, the same MPLS that is predicated on some of the
very ATM switching principles that it competes with. Oi! It
defies rational thinking at times, doesn't it?
Ten years ago, networking visionaries were calling for the
riserization of wide area networks, or WANs.
I.e., giving WANs the same proportionate characteristics as
building riser systems with regard to the ratio of bandwidth
supply to actual data traffic.
A riser in a commercial building is used to support in house
backbone traffic. It usually has lots of spare room on it
called head room. It is a one time sunk cost item, and it was
at one time characterized as comprising more bandwidth
than would ever be available in the WAN by a user for a
given application. That was back then.
The idea is that fiber will at some point make bandwidth so
pervasive and cheap, that WAN corridors could be equally
abundant for user data, as were the risers in office buildings.
.
With such an abundance of bandwidth, why bother to
implement deterministic protocols, much less QoS
guarantees, since traffic would never become obstructed in
the first place? This is the school of thought that supports
over-sizing the WAN with bandwidth through the
proliferation of fiber, in order to guarantee the safe delivery
of bits.
The competing school still abides by the notion that
bandwidth is limited, it is expensive, and it's still very scarce.
Therefore, in order to guarantee safe delivery, especially for
those services which are time sensitive, special quality of
service measure must be implemented. The QoS school
takes a minimalist and very stingy approach to the
availability and utility of bandwidth. Not surprisingly, many
who reside here are the very ones who stand to gain the
most by squeezing supply.
Against this backdrop of theological discussion, we have a
new breed of pundits, who, perhaps for the first time in the
history of this industry (save, maybe, for some cellular
related fiascoes which I still consider aberrations) they are
bemoaning that a bandwidth glut is upon us, and oh, what
now to do? Forsooth!
This topic is now found as one of the top ten best sellers on
the authors' must-write-about list. Of course, they know
what they are talking about, for they are journalists. And the
public is subjected to their ideas, and learns to heed them
with a degree of deference, and in some cases, reverence.
----
Whether to place IP directly onto SONET or lambda may be
too simplistic a question before long. For one thing, SONET
is dying an unavoidable slow death to a great extent in the
long haul. And in some metro situations, it never even had a
chance to get off the ground, losing instead to new
"proprietary" modes of transport, and those which support
IEEE/ANSI/IETF protocols instead.
It will nonetheless be with us for many years due to
inheritance factors, once again, in the means by which most
users will be forced to continue to attach to the larger
network. The ports to the larger networks will continue to be
sonetized, and these are where users will be forced to
continue to connect to.
Especially those who do not have the resources to
implement their own fiber builds to POPs. And then there
are the investments associated with the port counts in digital
cross connects, and so forth. Even today's most robust
routers, the ones boasting Terabit speeds, still conform to
SONET containerization standards at the OC-48 and
OC-192 rates.
On extremely high capacity routes, it's a no brainer at this
point that SONET, as we have grown to know it, is on its
last leg. I say as we have grown to know it because, there's
some tinkering going on right now to modify its features.
Vendors are attempting in some instances to dumb it down
in some ways, and make it smarter in others, and
streamlining it by reducing its significance in the stack.
This reduction is achieved by making the SONET Layer 1
look "skinnier" in its involvement, while reducing or
eliminating the Layer 2, ATM presumably, altogether.
In this manner what was once a cold cut sandwich now
becomes just two slices of white bread, with nothing in the
middle. Well, almost nothing. Media sublayer convergence
has to take place somewhere.
There's the other alternative for the long haul in the way of
IP over whatever, lambda directly, for the most part, and if
this were to be the case, several questions emerge that I'd
like to see answered:
Will the IP stream or link be permanently assigned to a
lambda as in a static route between two points? If so, why is
it IP and not the native Ethernet that it started out as at the
end point? Will it be dynamically switchable? If so, why are
we doing Layer 3? Will it Burst? Be continuously variable
across different lambdas?
And if bandwidth will become even half as abundant as
many now believe, indeed, as we are warned about, then
why are we protecting our bits with all of these QoS and
ToS measures, when the bogie man is slowly but most
assuredly dying, and will soon be dead?
Hope I didn't keep you up too late. Comments and
corrections always welcome.
Regards, Frank Coluccio
|
