Copyright © 2001, CIMI Corporation, Voorhees, NJ, USA. All rights reserved. This issue may be printed or stored in Web format for personal, non-commercial, use, provided that the entire issue including this copyright notice is reproduced and included. Portions of this issue may be quoted, printed, or stored providing that the subject portion is annotated with the issue identification above, and is attributed to the copyrighted material of CIMI Corporation. Other publication, reproduction, electronic storage or retrieval of this material, in whole or in part, without the express written consent of CIMI Corporation, is prohibited.
This month, we covered the opportunities available for service providers and equipment vendors in the important access market space, but this material is for subscribers only.
“It’s all a matter of timing”
is a cliché in today’s world, but it’s nevertheless often a true
statement. In networking
today, in particular, it might well be gospel.
What’s about to happen in our industry is likely to be a
function of the timing of supply and demand.
We subsidize wheat production, and
that of many farm products, in a negative sense—meaning that we pay
farmers not to produce. The
reason is that a free market might well generate so much wheat (or other
products of that ilk) that the market for the product could not absorb
the quantities, and prices would collapse, rendering the entire market
unstable. In short, we have
a long economic history of recognizing that there has to be some balance
of supply and demand.
In networking, “supply” can be
considered the available bandwidth of the network, and “demand” the
need for bandwidth at a price that suppliers can live with.
An imbalance is created when we can generate a bunch more bits
than current applications can consume.
When that happens, the competitive market forces tend to drive
prices down and destabilize the sellers.
Most (about 80% in the US, in fact,
and 88% internationally) of network service revenues today are
associated with voice and “traditional” TDM services. These services have demonstrated, over the last five years or
more, relatively little price-demand elasticity, meaning that reductions
in price don’t result in compensatory increases in buying activity.
Growth in these services, if measured by total-market growth in
the service revenues for them, has been extremely modest, certainly no
more than low-teens per year at best, and often single-digit.
Into this not-so-happy demand
picture, we now enter the supply side estimates.
We’ve currently lit about 13% of the glass in the ground, and
that portion that is lit is illuminated to less than 10% of its
potential capacity and used perhaps to less than 30% of what is
available. We could easily,
at least technically, multiply the network’s capacity by a hundred
times or more without even breaking an optical sweat.
The question is what happens when we do that.
Incumbent players have relatively
little incentive to light glass they can’t fill with dollars.
Thus, if we had a fully regulated industry, we would expect the
fiber capacity to remain untapped until means were found to convert it
into new revenues at an adequate rate of return.
In an unregulated industry (roughly where we really are today),
the nascent capacity can be exploited by new market entrants to create
infrastructure with a lower cost than the incumbents, allowing them to
address current opportunities at a lower price. This results in a kind of downward spiral of pricing until a
level is reached at which market entry is no longer profitable relative
to other opportunities. Putting
that in financial market terms, the ROI of funding new entrants falls as
prices fall, until new entrants can no longer attract capital.
Obviously, this death spiral is most
likely to occur where technology improvements that let us create
capacity at low cost have the greatest impact on the cost in
total of providing services. In
the local exchange space, other cost factors tend to dominate over
transport-of-bits costs, so LECs aren’t too much impacted by this. In other words, fiber-driven price reductions don’t apply
to carriers whose prices are based more on human costs or other
non-fiber costs. IXCs or
any type of service provider who are connected to customers through
another carrier’s access infrastructure are a different story.
Their networks are primarily longer-haul fiber, and the minimum
number of strands needed to create a connection network over their
service geography is sufficient to create a credible market entry (in
the network sense, at least). Thus,
a few fiber strands could create a credible regional carrier competitor.
Based on these points, we can draw
the conclusion that non-LEC carriers will be subjected to increased
competitive pressure as fiber-bandwidth costs decline, and that these
players will eventually be destabilized.
The only carrier spaces that would be defensible in the long run
would be those involving per-customer local access.
Thus, the RBOCs would be the only players left standing.
Ugly picture, huh?
There are only two ways that this
could be avoided; government could regulate the industry to prevent
competitive destabilization (as the wheat example shows happens in the
agriculture space), or demand could increase to offset the excess supply
and prevent revenue erosion. We
think regulations to prohibit long-distance competition or Internet
competition are absolutely crazy to even consider as a possibility, so
that leaves demand, and brings us back to our timing question.
Let’s accept, for discussion at
least, that new applications could increase demand for bandwidth by 400%
by 2004. These new
applications’ revenues would then offset revenue losses in the
traditional services (and, in particular, voice spaces).
Margins for longer-haul carrier types would not be destabilized. All’s right with the world.
Fine, what’s the barrier to this happier picture?
Access.
The problem is that we can’t get traffic onto the
network at a pace consistent with our need to grow transport bandwidth
consumption. The real goal
of the Telecom Act and every regulatory measure since has been to
encourage access modernization to provide a means for validating a new
class of high-bandwidth applications.
Had this goal been achieved in 1996 when the Act was passed,
we’d all be in bandwidth heaven today and the NASDAQ might still be
hovering in the 5000 area. The
timing question is now when the goal can be achieved.
Regulatory reform is probably needed
as things stand if we are to encourage access modernization.
The exact nature of the reform and its timing will determine how
fast things like DSL deploy. That,
in turn, will determine how fast we can develop revenue-efficient
applications of public data services to replace declining voice
revenues. The Internet
isn’t such a service (our views on this are surely known by now to our
readers), and it will take a bit of time to find out what they are.
The race, then, is on.
We probably cannot hope for effective
regulatory reform sooner than the end of the year.
Given that, we probably cannot expect to see significant DSL
progress before the middle of 2003. In our view, both Sprint and AT&T can survive that long,
and still be possible market factors in the second half of the decade.
MCI, Level 3, Williams, and other long-haul players may not be as
lucky. At least their
transport divisions are in jeopardy.
Virtually all ISPs are in jeopardy.
This doesn’t mean we won’t have
phone or Internet service, it means that we are more and more likely to
have a network service future dominated by the RBOCs. If
these dominating RBOCs are allowed to buy players (or merge with
players) in the long-haul space, these players will live on inside the
RBOC and their investors will receive some protection.
If not, these non-access players will gradually die off.
New competition in the services
market would obviously be possible if the new demand was made up of
demand for new services with no strong incumbent players to hold
customer loyalties. However,
it’s unlikely that existing transport players could retrench on their
investments and marketing to be effective in these new opportunity
spaces, and if transport players at large are dying it may even be
unlikely that Wall Street would finance new service competitors where an
opportunity existed. After
all, as long as bandwidth costs are plummeting and market entry barriers
are eroding, these new spaces will eventually be under threat as
strongly as today’s spaces are.
So that’s our race. If we can get regulatory reform quickly, develop access infrastructure quickly, and validate new service opportunities quickly, we can sustain a competitive carrier marketplace. Lacking that, we’re going to see a pace of consolidation and failure in the provider space that will turn a lot of investors and users gray.
It’s safe to say
that the heart of networking is the set of functions that the good old
(circ. 1974) OSI model assigns to Level 3.
In fact, it may be no accident that the official name of that
layer of the model is “the Network layer”.
But all good things must come to an end, and the market
conditions today demand that we look again at this venerable
communications construct and decide what its fate—and that of our
conception of building networks—might be.
Level 3 provides
the mechanisms needed to route traffic to destinations based on network
addresses, and it includes the ability to discover routes and alternate
routes where dynamism of required.
Level 3 is effectively the language of the network, because
it’s the highest layer of function that the OSI model recognizes in
the network itself; go higher and you’re in the domain of user
connection devices.
Over the years, our
conception of the OSI model has changed.
Few (if any) implementations of the full 7-layer structure exist
commercially, and many of the layers have been subdivided to recognize
functional boundaries the original OSI fathers didn’t anticipate.
We’re also finding that some of the OSI functions really
don’t merit separation (many would say that Session and Transport
layers should be, and are, combined) and some (like Presentation) may
not even be useful. Arguably,
the OSI concept of the ‘70s, if addressed today, would result in a
completely different structure.
The debates on the
nature of OSI are really debates on the role of network elements in the
function of supporting communications.
Like everything else in the world, OSI was a product of the
times. Times they are a’
changing, as they say. Is
our conception of the Network Layer and of networking due to change with
them?
Obviously, we have
to start our exploration of the path Level 3 will take by examining what
it was supposed to do in the first place.
The OSI model attempted to simplify network design and
development by creating functional layers that built on one another and
provided abstract services to the layer above.
This allowed changes in one layer to be contained to that layer
as long as the service features of the layer were unchanged, and it also
allowed two different implementations of the same layer to be
substituted one for the other, subject again to service cohesiveness.
What are Level 3’s services?
Essentially,
edge-to-edge connection. Level
3 provides the ability to move information between network points in a
pair-wise or multi-point manner. The
assumption is that a higher layer will ask for information delivery and
Level 3 will provide it. In
doing that, Level 3 must convert an abstract address of one or more
destinations to a set of routes that will take the information to the
intended place. This
conversion means that the layer must have a table or database that
relates network topology to network address space. If the network supports any form of service level guarantee,
Level 3 must recognize the guarantee and select a path according to the
ability to meet it.
All this adds up to
the fact that what Level 3 is supposed to do is offer higher layers the
ability to create a logical information path.
How that happens is up to Level 3.
Higher layers request a path and are either given it, or told
it’s not possible to obtain; are given the ability to use the path as
specified, or told it’s no longer available.
To provide all of
this capability, Level 3 draws on a series of network routes, linking
the network nodes in the network into the familiar mesh topology. At each node, the table/database that combines address and
topology data is used to steer information from node to node over
selected routes, creating an end-to-end path.
Connection-oriented Level 3 protocols create the path when the
higher level requests it, and the routing is done once per path setup
(setting up a virtual circuit in ATM or frame relay is an example of
this). Connectionless Level
3 protocols do the routing on each individual information element—as
IP does.
Inside the network,
Level 3 moves traffic over data links that run the OSI Level 2 protocol
and that have physical layer structures compatible with OSI Level 1.
In theory, any Level 2/1 protocols could be used over these
links, but in practice most networks are built using suites of protocols
that customarily run together wherever they’re used.
Thus, one doesn’t usually see IP running over data links using
HDLC, though it does happen.
Whatever the link
protocols, Level 3 insulates the user from them—with the single
exception of the one used on the connection between user and network.
Lower OSI layers inside a “cloud” are simply not visible
outside the cloud, and the features they offer are invisible as well.
Remember this point; it’s important.
In applications
where routes are determined dynamically, Level 3 runs a discovery
protocol that “learns” the network topology and the users that are
connected to each node. This
protocol is the basis for building the database that allows information
to be routed in the network. The
database, if it is dynamic, can also be used to provide for recovery
from link or node failures in the network, by selecting an alternate
path. This feature set is
likely to be present with connectionless Level 3 protocols, because in
connectionless services loss of a link or node and selection of an
alternate route doesn’t raise questions about packets lost in the
changeover—there’s no delivery assurance in connectionless Level 3
service.
Level 3 is the
highest layer of the OSI model that exists both within the network and
at the points of user connection, so it’s safe to say that Level 3 is
the glue that binds network and user together.
Since, like all layers of the OSI model, Level 3 has services
associated with it, these services become the common service set created
by the network and adopted by the user.
Building the network, of course, means selecting a Level 3
protocol, and so building the network selects the service.
User devices on the network inherit the service set of Level 3,
and that sets the requirements for their higher OSI
levels—particularly Level 4. TCP,
for example, does end-to-end flow control and error recovery and packet
reordering because connectionless Level 3 services don’t include
information protection in these areas.
Optical networking
poses a clear threat to our conception of Level 3 a la OSI model.
The advent of DWDM has raised the prospect of a core network that
has effectively limitless capacity.
Since a great number of the Level 3 services and features are
based on a presumptive need to conserve bandwidth, this glut of capacity
threatens to undermine the design basis of modern protocols.
A couple of examples will make the problem clear.
Example number one
is the classical one of route discovery.
In present connectionless Level 3 networks, we run topology
protocols to discover the shortest route or least-cost route (depending
on the protocol) to destinations. If
optical networking makes bandwidth extremely cheap, wouldn’t it be
likely that we’d simply mesh our infrastructure, creating direct
routes from place to place? Wouldn’t
that then tend to undermine the whole topology discovery process?
In any event, what’s the “lowest-cost” route over a network
that has near-zero bandwidth cost?
Answer: All routes
are essentially the same cost; so forget worrying about least-cost
routes.
Another example
arises from the competitive response to declining bandwidth costs.
If bits are cheap, equipment vendors are faced with a market
where what they build creates a featureless commodity.
Features are needed in optical networks if optical vendors are to
maintain their margins. One
good feature might be optical rerouting, meaning that the optical
(physical) layer of the network would fail over to an alternate route if
a primary route failed.
Ah, now we can see
the problem! Level 3 is
supposed to be doing all this stuff, and Level 1 is getting into the
act. The supposed
independence of the layers in the OSI model says that Level 1 can’t be
seen at Level 3, and in fact says that these rerouting and topology
features don’t belong in Level 1.
What do we do to fix the problem?
One possible answer
is to allow Level 3 to run largely as-is, and simply provide a mechanism
for Level 1 and Level 3 to communicate around the restrictions of the
OSI model. While this seems
to be a sanctioning of a violation of the OSI rules of the game, the
truth is that we’ve suffered these violations repeatedly over the
years. The frame relay
concept of forward and backward explicit congestion notifications (FECNs
and BECNs, to those with short memories) creates just such a
problem—in this case, between a Level 2 and Level 4 protocol—because
flow control isn’t a Level 2 function, and that’s where frame relay
runs.
One could argue
that the OIF and ODSI efforts are examples of attempts to deal with the
“smart optics” problem in this way.
In effect, they create an optical network that is recognized as a
“smart” network, define protocols for interfacing to that network
from more-or-less-conventional edge devices, and then define how network
problems of the type we’re used to dealing with using a
network-distributed Level 3 function set can be dealt with inside the
optical cloud with instructions (of some sort) from the edge.
Of course,
there’s another possibility. Why
worry about how to communicate a failure of the optical network to the
edge of the network at all? If
the optical network is a “perfect” network, with full error recovery
capability, do we need to even report a failure?
In effect, we could
make a smart optical network into a kind of virtual node, whose internal
information movements are outside the ken of the OSI model. The user would then be “attached” to the optical network
through a device that bound the user’s service protocol to optical
features. The
“information plane” requirements of networking—the requirements
associated with end-to-end traffic flows—would be subsumed into the
optical space. The binding
device would map between the user’s addressing scheme and the optical
network’s scheme in order to “reach” the binding devices that
served each of the user’s partner-site connections.
Any Level 3 services other than those available from the optical
cloud would then have to be “emulated” by these binding devices.
Having the binding device replicate packets designated as
point-to-multipoint, then route each packet as if it were a
point-to-point flow, for example, might create multi-casting.
Interestingly, if
the user has to be “bound” to core resources through an active
process of adaptation between user service protocols and the optical
service set, it’s likely that the process wouldn’t be any more
difficult for multiple user service protocols than for one.
Thus, the optical core might be naturally multi-service, and user
devices could continue to use whatever protocols they found convenient.
What all this means
is simple. By becoming
“smarter”, optical core networks can create virtual Level 1 services
that undermine the whole nature of Level 3 within the network.
This would eliminate ordinary protocol intelligence in the core,
eliminate ordinary electrical-protocol-based network core hardware, and
push smarts out to the optical edge.
There, a new set of features would be needed to provide
simulation of some of the now-displaced Level 3 services, and to bind
users to these services.
Well, gosh,
that’s interesting, but does it matter?
Maybe it does.
Carriers want to
make more money from their customers, which means selling them stuff the
customers don’t buy at the moment.
How do we develop those new revenue streams?
There are two steps needed: first, develop new services that
could be useful, and second, provide the user a reasonable means of
connecting to those new services.
“Reasonable means
of connecting” to most users would mean “means of connecting
compatible with current service interfaces”, so equipment could be
preserved through the service transition.
The two are intertwined in that any limits on customer-to-service
connection would translate into restrictions on the range of services
that could be made credible.
As a benchmark
approach, we might speculate that a service should be accessible using
whatever interface the customer already has in place.
Thus, we might expect a customer who currently buys frame relay
service to want a frame relay interface.
This would be easily accomplished if the core network were a
frame relay network, but what if the network and the service were
mismatched? Do we want to
deliver frame over MPLS, for example?
Do we want IP services to appear as virtual router frame relay
partners, as AT&T’s popular IP-enabled Frame Relay service does?
If so, we have to acknowledge that we might need more flexibility
in creating a customer’s service interface.
Clearly, a router
currently equipped with a frame relay interface can more easily adapt to
a service like AT&T’s than it could to a new service that didn’t
use a frame relay interface at all.
Ease of adaptation would make it easier to sell a given customer
the new service. Similarly,
the provider who expected to see his revenue stream expand through the
introduction of IP services into a frame relay service family would find
it easier to provide both types of service if a common infrastructure
could be used. This would
translate into lower cost, better margins, etc.
Another example of
the benefits of flexibility is the managed IP service, which appears to
the user like a private router network.
What’s the interface to this service?
If the user has only LAN equipment at a site, the service should
appear as a default gateway router attached to the LAN.
That would mean an Ethernet-like interface to the user site.
If the site already has a router, the best interface is one the
router supports, at the physical level (V.35, etc.), the encapsulation
level (PPP, RFC 1490, etc.), and the router protocol level (RIP, OSPF,
BGP4).
Then there’s the
classical issue of how an IP service looks to the user in the management
and control planes. A
“tunnel VPN” looks like a wire, and the user must provide his own
router capabilities. A
virtual router service looks like one or more routers.
A service based on real routers and connections would display its
real topology and characteristics.
Who creates all this? The
service edge, presumably. The
same service edge, in fact, who’d have to proxy the frame relay LMI
and MIB were the provider to sell frame relay over MPLS.
OK, it should be
clear that a dynamic service environment would be expected to either
burden the subscriber with continually changing to adapt to a static
carrier service interface, or burdening the carrier to change service
networks for each service change. A
better option would be to let the service edge device provide the
interface between the service consumer and the service network, adapting
each interface to suit conditions and cross-connecting information
between the two as required.
…is the service
layer of the network. As
the optical core expands, it will approach each metro access point of
presence. As that happens, more and more of the traditional features of
Level 3 will be assimilated into the optical network, and the thing
we’d call a “protocol network” today thins down to something one
device thick.
Clearly, creating a
full IP-based network just to satisfy the requirements of a UNI isn’t
sensible. If the core
isn’t based on IP (and an optical core isn’t), then the service
switch that melds user service interface to core will have to create a
kind of virtual IP environment that meets users’ UNI specifications
and exploits whatever features are present in the core to move traffic,
determine reachability, and heal faults.
The industry view
of the evolution of network services is faulty, and the fault is caused
not only by the usual hype and hypocrisy in the market but also by the
tendency of the industry to view market spaces rather than the market at
large. We’ve constructed
a consensus view of the industry whose parts don’t add up to the
whole. We believe in optical revolution but protocol stagnation, of
service diversification in the face of static service relationships.
The role of IP as a
service protocol is so well established it may be that few alive today
will ever experience a data alternative to it.
The role of IP in internal network operation is, in our view, not
only insecure but also already changing.
Smart buyers and sellers will reflect that truth in their future
relationships.
To most of us, “communications”
means telephone. The common
carriers, and in particular the ILECs, are the underpinning of public
communications and networking in the US, and their national
administration counterparts have the same role in the rest of the world.
Given this, it would be stupid to
believe that these players weren’t going to be the benchmark for
broadband empowerment in the future.
Copper loop technology in the US alone amounts to nearly a
quarter-billion connection points.
That loop plant currently supports services that have a base cost
of less than $20 per month, even for most business services.
Thus, broadband empowerment of these loops would have to be at
least an attractive option, if not the most attractive one.
There are probably a zillion
different things that could, in theory, be done with copper loops to
make broadband pipes out of them. The
RBOCs themselves, however, won’t do most of these things. Since our readers are already well aware of our view that the
CLEC exploitation of wholesale copper is a losing proposition, that
means that copper technology a la RBOC is what we have to look at, and
that means DSL. We examine DSL in this section of our newsletter,
but it's for subscribers only!
Netwatcher is a copyrighted information product of CIMI Corporation. Subscription is on a controlled circulation basis only. Subscription information may be obtained by clicking here.