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 section is not provided in this month's newsletter. Our next Market Area Focus will be published in the June issue, and will address new-age voice technology. Is it dead, or ready to take off? Remember, this section is always reserved for subscribers.
Our industry
continues to muddle forward, bombarded by outside forces that will
eventually either shape us into something functional and profitable, or
kill us off one by one. What’s
frustrating is that most of the inside players (of whatever type you
want to name) are still trying to get one more shot at that old 1999
boom Internet/CLEC scam rather than build a sustainable business model.
Perhaps it’s just as well that the regulators and Wall Street
won’t let that happen.
Late in March, the
FCC’s Powell appeared before the House Subcommittee on
Telecommunications and the Internet to answer questions on how “his”
FCC would propose to deal with what the House thought the key issues
were. During the hearing,
there was surprising consensus that some revamping of the regulatory
framework of the Telecom Act was in order.
Nothing in that hearing had force of law, but it was an
encouraging climate.
In April, the FCC
took steps to reform the utterly awful area of reciprocal compensation.
As many of our readers will recall, reciprocal comp was
introduced in the Telecom Act to help spread the burden on CLECs who
would receive calls from a large calling population supported by the
incumbent, but receive no revenues for handling these calls to their own
subscribers because they’re billed to the incumbent’s customer.
The plan called for having a carrier receive from a competing LEC
a fixed fee per minute for each call-minute the calling LEC terminated
on the called LEC. The
financial wizards in the CLEC space jumped on this to support ISP
activity, reasoning that an ISP was a customer who never placed calls
and who thus generated a positive reciprocal comp flow.
The FCC ruled last
year that Internet calls were not “local calls” and thus not subject
to reciprocal comp, and in April they moved to cap the payments under
existing agreements. We’ve
always believed that these kinds of “ regulatory arbitrage” hurt the
industry by focusing competition on what were not opportunities but
rather loopholes. It will
take time for this to work through, but we’d hope that everyone sees
the handwriting on the wall; Powell’s FCC won’t demand that the
ILECs subsidize the CLECs just to keep the latter alive. Without that, they can’t live.
Wall Street and the players should have known that all along.
Another helpful
step was taken in Pennsylvania, where AT&T and others had been
lobbying the PUC to demand that Verizon break up into a wholesale/retail
dipole as a condition of operating in Pennsylvania.
This would have run 180 degrees contrary to the current FCC
policy, hurt consumers, and had a bunch of other bad impacts, and
Verizon was appealing it through Federal courts.
We think they’d have won, or that the FCC would have asserted
its primary jurisdiction there, but now the matter is probably closed
without Verizon’s breaking up.
Finally, the House
Commerce Committee (of which the aforementioned Telecommunications and
the Internet subcommittee is a sub) scheduled its first hearing on
Internet access and related issues for April 25th.
Obviously, it’s too soon to have an exact picture of where
these guys might be going with the future of the industry, but it’s
encouraging that they’re starting, and there are a few comments we can
make based on the first draft of the bill, just added to the House
website.
The new legislation
is called “The Internet Freedom and Broadband Deployment Act of
2001”, and the purpose of the Act, as described therein, is to rectify
the way that the Telecom Act has been applied so as to eliminate the
disincentive that application has on RBOC deployment of broadband
access. The “hook” the
House is hanging its intervention on is that the Internet requires
special support, and that the prohibition on RBOCs’ providing
interLATA services and the mandate for their unbundling voice
infrastructure are incompatible with giving that support.
Definitions are
important in Congress, so let’s get them out of the way:
1.
The Act defines a high-speed data service as one that operates at
“generally not less than 384 kbps” in at least one direction and
which uses “packet-switched or successor technology”.
2.
The Act defines the Internet as the collection of computer and
communications facilities that comprise the interconnected worldwide
collection of networks using TCP/IP or its successors.
3.
The Act defines an Internet Access Service as a service that
combines information processing and storage, protocol conversion, and
routing with transmission services to enable users to access the
Internet, but from Internet to user and not the reverse.
Given all of this,
the Act would exempt services that provide high-speed data services and
Internet access services from regulation by all Federal and state
processes except as provided for under the Act itself.
It affirms regulation of exchange services for voice so that they
cannot be claimed to fall under this Act.
It also reaffirms FCC rights to continue or alter then enhanced
provider exemption from access charges and issues relating to Universal
Services requirements.
The heart of the
Act is its modifications to the Communications Act of 1934, as amended
by the Telecom Act of 1996. Here,
it says that the ILECs shall not be required to unbundled or wholesale
any service or network element used in the provision of high-speed data
services. It also gives the FCC authority to expand the exemption as
needed to meet the requirements of Section 706 of the Telecom Act (which
requires the FCC take the steps necessary to assure the availability of
advanced services to all Americans on a non-discriminatory basis).
This, in effect, codifies and expands the “packet exemption”
granted to the RBOCs by FCC ruling 99-238.
It also appears to provide the RBOCs with the ability to offer
data services that don’t involve voice out of region or in, without
wholesale/unbundling risk. This
moots the separate subsidiary requirement previously articulated by the
FCC (98-188), embodied into the SBC and Verizon merger approvals, and
overturned by a Federal Appeals Court in January 2001.
The Act also
requires that the ILEC provide the consumer with ISP choice in any
high-speed data service, make available services to facilitate ISP
attachment, and provide collocation as required.
Finally, it forbids the RBOCs to sell voice over any high-speed
data service or Internet access service until they’re released from
long-distance restrictions.
Unlike previous
versions of the broadband reform bills in the Senate, the Act as
proposed does not include a provision to link the regulatory relief with
specific levels of broadband penetration or availability.
This is probably a smart move, since the linkage would tend to
induce the RBOCs to seek an answer to the question of whether
residential empowerment would be profitable on a large scale before
they’d experiment.
We believe that
this law deals with the issues we’ve been citing as the factors
depressing the networking marketplace.
If the “high-speed data service” definition stands through
the process of hearing and passage, it would also unfetter the RBOCs
completely in the data space and make investment by the RBOCs in public
data services or any data service much more viable.
Obviously, it also has other consequences, which we’ll
summarize here and deal with in more detail in the coming months, as
progress on this bill unfolds.
The first and most
obvious consequence is that it kills the whole CLEC unbundling and
wholesaling paradigm on that portion of the network used for advanced
services, while leaving the remainder of the network (the voice service
part) alone. If an RBOC
provides DSL through home-run copper, the loop is still a voice loop and
the RBOC could be presented with a requirement to unbundle it.
If the DSL is provided via a remote, the unbundling shield is
absolute (more so than even the FCC order would have made it).
This makes CLEC arbitrage of RBOC facilities much more difficult.
The second
consequence is that the bill would eliminate the requirement to
wholesale DSL services to CLECs or anyone else.
That’s a new perk for the RBOCs, and probably the death knell
for any pure access DLECs. That’s
no loss because none could have survived in any case, but this provision
is going to raise a lot of dust in the marketplace, and Congress will be
under intense lobbying pressure here.
The requirement
that an Internet access service include the Internet-to-customer
direction but not the reverse would seem to be aimed at preventing the
facilities used to provide back-channel connections for DBS Internet
services or other “off-network” server-to-client connection services
to be partitioned off as exempt from wholesaling and unbundling, when
these facilities are usually simply voice-grade network facilities.
The fact that the
Act separately defines “High-Speed Data Services” and “Internet
Access Services” seems to admit the likelihood that the RBOCs would
have other data services than the Internet.
This, and the definition of the Internet itself, seems to open
the door to shelter any public data services of any nature, and to
support technologies based on something other than IP as the delivery
vehicle for client/server or content networks.
Both these exemptions are important.
So what happens now
as a result of this, in terms of industry trends?
Here are our guesses:
1.
The RBOCs will rekindle
their fiber remote deployment in support of DSL,
but they may move away from the early favorite, Alcatel, in favor of a
player with more residential video potential.
This could be big for Marconi.
2.
The CO DSLAM version of
the DSL market will suffer at both the provider of services level and
the equipment level, because
RBOC fiber remotes will be the strategy de jure.
Look for Lucent and Nortel to try to shift their stance more
toward remotes, away from pure DSLAMs.
3.
ATM hardware products
will grow in importance as
the RBOCs deploy ATM-based regional networks and expand their data
services. ATM will be the
basis for RBOC voice advances, as well as the framework for their
interoffice data transport, in our view.
4.
Some ISPs will see an
opportunity arising out of
DSL deployment, and others will be crushed.
With the RBOCs taking over customer provisioning responsibility
and with the congressional mandate for “Internet freedom”, it will
be impossible to own a customer for broadband Internet.
5.
The cable industry will
be confronted by equal access requirements
if the “freedom” provisions remain in the Act, because it’s
unreasonable to assess restrictions on one access industry and not all
of them. That point was
made during Powell’s visit to the House subcommittee in March. But cable will benefit from the overall gains in residential
broadband services that will arise from the RBOC DSL build-out.
Cable companies need to strategize their video-on-demand
approach, though. Content
video is a big near-term opportunity, and it collides with cable
strategies for competition with the satellite players, and with
pay-per-view services.
6.
The concept of
competitive access will have to be restructured
to reflect the reality that for the mass market there will be no
competing with the RBOCs. Metro
is a niche, at best. DLECs
are less than a niche. Broadband
wireless and alternative technologies will find a role in rural
deployments. DSL wins the
mass market, and the RBOCs win DSL.
We don’t think
the current legislation is the be-all, end-all.
The draft is from April 20th, so this is a very
preliminary view of legislative intent.
As of this writing, the full committee hearing has been held, and
it appears that the Act will in fact be reported for a vote in the House
within the next month or so. It
also appears that there are sufficient votes for it to pass easily.
But some of the seeming bipartisanism of the Powell meeting with
the subcommittee seems to have evaporated in the full committee context.
This could make it harder to pass the bill in the Senate, where
the Democrats (who appear to oppose the bill) have a 50:50 split
(literally).
The rumors rushing
about the Beltway indicate there’s still a bit of a power play here,
though. If the lobbyists
controlling the Democrats and the lobbyists controlling the Republicans
work out their own deal, the bill will fall into line and the President
would certainly sign it. In
aid of this outcome, some of the latter lobbyists seem to be floating
the thought that the FCC might simply accelerate their own actions under
the current law, which admits the RBOCs into long-distance markets
fully, and essentially kills off the IXCs or forces immediate (and
probably unfavorable) merger terms with the RBOCs.
We’ll keep our
subscribers informed on the regulatory twists and turns, and we remind
them to check the regular postings we make at http://www.cimicorp.com/thoughts.html
periodically to see if we’ve added any news.
We’ve looked a
little at the service switch space in the past, but primarily in the
context of IP VPNs. As our
readers may recall, we believe that products that decode IP streams to
isolate application flows, and then route those flows for appropriate
(largely connection-oriented) handling in the network are the keys to
the corporate VPN market. We published a VPN primer that identifies the feature
requirements for this space and presented some submissions by vendors in
response to our framework, and this is downloadable from our website
(click the “Services” icon and look for the “Free Information”
heading to download).
The regulatory
shift we discussed in Management Briefing this month, combined
with the business conditions in the networking space, may combine to
create a environment in which service switches would play a much larger
and more important role in networking than just VPN creation.
Since the regulatory shift is now becoming visible, we think
it’s important to organize our broader view of this space and present
it as a mechanism for reviewing both vendors in this space and in
related spaces.
A “service
switch” is what, exactly? Unfortunately
the marketplace hasn’t arrived at a consistent definition for the
space, and the fact that vendors don’t even attempt to apply the label
to a consistent product set certainly doesn’t help matters.
We’ve talked about the concept for some time, so we’ll assert
pride of place with respect to the space and set about to do a basic
definition.
We all know what a
phone switch does, or an IP switch.
In both these terms, a modifier that indicates just what’s
being switched precedes the word “switch”.
We propose therefore that the term “service switch” defines
something that switches “services”, or a service, at least.
Since things that switch a single service are defined already as
“something-switches” where the “something” is that single
service’s name, we’ll opt for the idea that “service switches”
must switch multiple services.
This definition
still doesn’t completely categorize the space, though. Switching multiple services could be accomplished by
switching a single protocol/technology like IP or ATM, as long as that
protocol or technology was capable of supporting multiple services.
This brings us to the first point we can make about the service
switch space: Service
switches can be classified by whether they support multiple services by
supporting a common underlying protocol, or whether they support
multiple service protocols.
OK, we’ve handled
the service part. Now
let’s get on with our process of classification by looking at the
other end of the picture. Service
is something you sell; networks are something that you build.
The service switch must link service with network in some way. Here, there are three options:
1.
The service switch could be a switch of a single multi-service
protocol, requiring that the service offering be presented in that
protocol’s format, and that the network support that same protocol.
An example of this would be a service switch based on creating IP
services out of a routed IP core through application of traffic
classification, tunneling, encryption, or whatever.
2.
The service switch could be a switch that handles multiple
service protocols by separating the service requests by protocol and
forwarding them via an attached network that speaks that same protocol.
Thus, the product doesn’t convert or create a
service, it just makes a kind of electronic patch between network and
service interface. Some
IADs fit this description.
3.
The service switch could be a switch that handles multiple
service protocols by terminating the user’s service interface (via a
proxy function), isolating the network service elements, and fulfilling
each element out of the available connection/service resources.
Here, the product actually creates the service, and also provides
some conversion of a given service protocol to a perhaps quite different
network protocol. Frame
over IP tunnels or MPLS LSPs is an example of this sort of thing.
It should be clear
that the complexity of the “service switch” is greater as you move
downward on this list of possible approaches.
A product of the first group is essentially a refined form of
access device for the selected service protocol—a superFRAD for frame
relay, or a super-access-router. A
product of the second group has to support what is essentially a set of
service-to-network relationships, and could be viewed as a product that
is an integrated version of the access devices for each of the service
protocols it supports. A
FRAD/router combination, for example, would support both frame relay and
IP services. The third
product, of course, defies standard description.
Protocol converters
were once quite a hit in the marketplace.
In the prime period of the 1980s, more than half the large
communications buyers in the US used them, and they often provided
support for both harmonized backbone data networks in multi-vendor
shops, and for migration from one protocol to another.
In some ways, the third group of service switches is products
that resemble protocol converters.
The easiest way to
visualize a protocol converter is to visualize two OSI stacks side by
side. If we assume they
represent two different network protocols, and that we want to convert
one to the other, the logical approach (and the one taken) is to
essentially build a bridge between the stacks.
Level 4 in the OSI model represents the layer where end-system
communications begins, so the services offered there represent the
“user” of the network. Protocol converters built a bridge at level 4, terminating
the lower protocol layers and emulating the facilities of the network(s)
at this point of user connection. IBM
(no surprise) formulated the most sophisticated approach to this
bridging task in its MultiProtocol Transport Network (MPTN).
Don’t be disappointed if you don’t recognize the name; it’s
been so long that even Netwatcher coverage of the topic predates
our electronic format!
The key to making
this concept of protocol bridging for an arbitrary set of protocols (the
MPTN goal) was to establish a common semantic to describe service
features, and to isolate the procedural and management commands sent
between users and networks (the “control plane”) from the end-to-end
user information (the “data plane”).
That’s what it means to terminate a given protocol.
How this gets done has been a subject of increased industry
interest. How these
approaches work is yet another layer to service switch classification.
Networks are
cooperating collections of devices, and they rely on internal protocols
to arbitrate this cooperation. Thus,
a device connecting to a network can be viewed as a user of the
network (a consumer of the services the network makes available at the
boundary, but not a participant in these internal protocol exchanges),
as a partner to the network connected across an administrative
boundary like an inter-carrier connection point, or a member node
of the network with full internal privileges.
A service switch
can connect to a network as a user.
In that case, it functions as a kind of virtual client to the
network and as a virtual network to the service consumer, using
conversion facilities to link one to the other.
This client proxy mode of switching does not require the
service switch to participate in the internal behavior of the network,
or even be aware of it.
The second
relationship a service switch could take, the NNI proxy, is
really very similar. Most
network protocols have an explicit provision for administrative domains,
places where two networks are separated at the business level even
though they may be combined at the technology level.
An NNI interface is thus really nothing but a special and more
privileged version of a client interface.
The third thing a
service switch could do in theory is be a node proxy. As a node in a multi-service network, the service switch must
behave as an internal network member interleaved with other nodes
presumably built by other people. An
IP switch in the Ipsilon model was capable of operating as a node proxy
to a router.
These options pose
very different problems to the vendor.
A client proxy
requires only that the product support the standard UNI for the network
connection, and the standard UNIs for the service-side connections. A “service virtual network” can then be established among
the service switches over the connecting network, and the connecting
network need not be aware of or participate in this relationship. The service switches have converted their users’ requests
to a form of request compatible with the native service of the
connecting network, and satisfying these derived requests now make up
the mission of that network.
An NNI proxy may
have a more complex problem. The
partner network often has options of route management offered by the
connecting network. ATM’s
PNNI and IP’s MPLS both present a set of route choices to what is
essentially an administrative boundary node, and exercising these route
choices optimally may require that the NNI proxy relate the topology of
the connecting partner network to the topology of the service itself.
A node proxy has
the most complex problem of all. Here,
the service switch must behave as a virtual member of the network and
fulfill all the internal protocol exchanges for service, route, and
resource allocation and control. This
requires that the switch have both the virtual vision of the service and
the actual vision of the network’s connections and capabilities.
If you add the
concept of multi-service to all this, it’s clear that the increasing
levels of “proxy-hood” offer even greater challenges.
Supporting any view of the virtual topology of a service requires
that the service switch understand how that service would be coordinated
in a real network based on that service’s protocol.
An IP VPN has to look to the user like an IP network.
But it’s doing this for multiple services that creates
the problem, and that’s where the concept of control and data place
separation come in.
All networking
reduces to shuffling information from place to place.
What makes one protocol different from another is primarily the
service-specific signaling that occurs—the control plane.
It follows that it would be possible to build a network device in
which the handling of information (the data plane) was separated from
the control plane. Such a
device, if given multiple parallel control planes representing each
service it offered, would be capable of leveraging common information
handling logic across multiple services.
It would also be capable of supporting the virtual service and
network views needed to embrace any of the three proxy missions.
It turns out that
the concept of control/data separation has been around for a while.
It was articulated in the original MPLS Framework document, where
it was said that the MPLS forwarding procedures should be able to
operate independent of the “routing policies” that govern how
elements of the network are addressed and how network topology is
related to user reachability (routing).
Over time, the IETF work on MPLS has tended to pull MPLS more
into an IP-specific process, but the framework is better than that, and
there is some work underway to make MPLS more independent of IP at both
the service and infrastructure level.
A more precise (or
at least more explicit) map of control/data independence is provided by
the Multiservice Switching Forum (www.msforum.org).
The MSF architecture divides a network of devices into four
horizontal layers (application, control, switching, and adaptation),
with a vertical management layer thrown in.
Unlike MPLS, which touts multi-service support but so far
codifies only how it works in an IP network, MSF explicitly contains
reference to the other protocols. But
MSF isn’t available as an implementation that matches its theoretical
scope.
Any service switch
must recognize a model of the service it’s switching. Two of the proxy models also require it to recognize a model
of the network, in some form. Do
all service switches have to support pure framework-based MPLS, MSF, or
both?
If they do, there
probably aren’t any service switches today.
In truth, support of these architected control/data segregation
strategies isn’t critical in the near term, but it may become so over
time.
Today, both
networks and services are evolving.
Users, overall, are tending to move up the OSI stack in their
consumption of service, in order to limit capital investment in
technology and reduce their dependence on skilled network professionals
on staff. While this
movement is slower than IP pundits would like to admit, it’s
nevertheless real. At the
same time, the principles of network design are being challenged by the
introduction of enormous optical capacity and increased optical
intelligence.
Right now, we have
“networks” and we have slow evolution in the service area.
A service switch that functioned as a pure client proxy or as an
NNI proxy would conform to most near-term requirements, because there is
generally enough capacity to carry traffic in the core (reducing the
need to add devices there) and because the geographic expansion of
carrier footprints (the near-term trend we’ll see owing to regulatory
change) necessarily adds edge boxes in the new service areas.
Stick new-service-switch on old-service-core using any convenient
edge interface and you’ve got it knocked.
As network services
build network traffic, though, it may be desirable to have a better way
of linking the virtual vision of service topology with the real
resources of the network. That,
in our language, would imply letting the service switches and the
network core share a control plane—the MSF model or the MPLS
framework’s routing policy.
Service Management
also plays in this process, or at least our vision of it does.
Constructing a virtual model of the service and reconciling it
with the actual model of the network is a mission we defined for SMSs in
the framework we published in the fall of 2000.
It’s also a fixture of most of the responses we’re getting
from vendors (including the one we’re publishing this month).
It’s very likely that as the concept of control plane
segregation develops as a requirement in service switches, the same
forces of the marketplace will validate service management systems.
If you like this
approach (and, yea, we have to admit we’d prefer you like it than hate
it), you’re probably already disappointed that you can’t get this
from service switch players. In
fact, some of them come pretty close to this model now.
The problem is that the hype and jazz of the convergence, CLEC,
and Internet frenzy of the past couple of years created a kind of
alternate reality for the media. This
perverse view of the market distorted the positioning of the individual
players, and that distortion hasn’t worked out of the system yet.
Thus, you probably can’t find out what your service switching
alternatives even do in the critical areas we’ve defined above, or
even get them to classify themselves according to our taxonomy.
We believe that the
market, as it evolves under pressure of Wall Street and Congress, will
force players in the service switch space to adopt an approach to their
market similar to the one we’ve described here.
When that happens, you’ll see the rise of what may well be the
first real new product class in years!
This section of our newsletter is
dedicated to the service management framework response of new-age
service management player Trendium Sorry, 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.