Netwatcher (ISSN 0890-5800) is a monthly publication of CIMI Corporation. Subscription information is available here. Copyright © 2000, CIMI Corporation. All rights reserved. No publication or reproduction of this document is permitted without the express written consent of CIMI Corporation.

Management Briefing

Only a real optimist, or someone who doesn’t read financial reports, could believe anything other than that the CLECs are now in deep trouble as a business class.  Our estimates are that the collective market cap of the CLEC sector has declined by over 60% since March, and as expected this is essentially killing their access to capital.

What now, if the CLECs die off?  It could clearly impact the industry in a number of ways, but we think that one key impact will be on the rest of the market, and on the technology trends we’ll see reflected in our industry over the next five years.

CLECs accounted for less than 5% of total carrier spending worldwide, or about 9% of US spending, by our statistics; more by other accounts.  However, this wasn’t spread out evenly across all vendors and technology areas.  In some market sectors, such as DSLAMs, CLECs probably account for half or more of total spending to date, and for some vendors CLECs are one hundred percent of their customer base and growth market target.

As our readers know, we’ve believed that the CLECs were doomed from the start; launched to feather financial nests rather than to support a legitimate market opportunity.  We’d hope that the experience here will induce the market at large to be a bit more cautious when considering so-called “new” market areas.  Hype is as much the fault of those who refuse to hear the truth as it is of those who refuse to tell it.

The factors that doomed the CLECs will effectively doom all the “xLECs”, where “x” is “B” or “D” or whatever.  We’re also of the view that these factors will make it difficult for non-incumbent carriers of any sort to survive, since the CLEC experience will certainly make buyers gun-shy with respect to new players, even with other names.

The market and technology changes this all brings about can be analyzed based on a simple principle; CLECs were a funded source of illogical market evolution.  Their existence in the marketplace validated a series of product and technology alternatives that a real-world market would never have considered.  Unless the VCs spawn another similarly crazy play, the death of the CLECs would be the death of this illogic.  First, it would strike the new-gen carrier space, and then roll over into the technology and equipment space.

Hardest hit, and first to be impacted in the provider space, will be the new-gen carriers targeting business customers.  Businesses weren’t running in droves to the CLECs as it was, fearing as they always do making new deals with unknown players.  BLECs and the multi-tenant players will have greater problems with credibility now than ever before.

It also seems quite possible that the Internet sector will suffer, meaning that ISPs will feel the hit.  We’ve noticed that some of the ISPs are already trading at new lows, and we’d expect to see this process continue as the problems with the CLEC space (now visible for business and technology analysts, but not yet trumpeted on national media) become clear.  However, we do not believe the ISPs are really at risk, and there will be some bargains created in this sector (as there already are) for those who like trading stocks in a volatile market.

We expect to see ISPs begin to consolidate now, and also ISPs being bought by ILECs and IXCs.  It’s clear to all that the service provider market is going to be a game for giants, and building mass is now the order of the day.  In this respect, the FCC has dealt the IXCs a crippling blow (or, perhaps, Congress has) because IXC mergers with ILECs aren’t likely as long as the ILECs haven’t been released for long-distance competition.  IXCs may thus be out of the best part of the merger game—the early part, where there are still good deals to make.

On the plus side, the ILECs are now in the cat-bird’s seat, as their recent stock performance shows.  Because they’ve always held the key cards in the network enhancement space—customer access is the key to all networking—they always had the best chance of being a major player in the future.  Now, most of their competitors are shrinking away to boot, so they’ve a doubly good chance.

In the technology space, it’s this shift to incumbency that will tell the story.  Traditional technologies like ATM are going to be big beneficiaries of the move, and contrary technologies are going to suffer mightily.  This will be most pronounced in the local access equipment space, where anyone who isn’t prepared to sell ATM-based DSL-creating infrastructure to an ILEC may as well sit and wait for the undertaker.

It would be unfair to say that the death of the CLECs killed off convergence because that idea was so totally dumb that it was never really alive.  What the CLECs’ demise will do is make it harder to keep the death of convergence from becoming clearly visible.  The CLECs bought a lot of the so-called “converged infrastructure” (nearly three-quarters of it), and without any near-term PR validators (as meaningless as they were), we can expect to lay this concept to rest shortly.

The death of the CLECs may also have a major impact on the alternative voice players, particularly those who are promoting IP or packet (versus cell) voice.  CLECs bought a whopping 94% of this stuff by our reckoning, and most of the players here are still trying for acquisition or IPO.  Our advice; pray.

Metro fiber is another play that can be considered to be now highly speculative.  RBOC deployment of so-called “metro” technology would likely be based on classical ATM components, not on the packet-over-photon or IP-over-lambda stuff that permeates much of this space.  In any event, metro deployment in a logical market would lag access modernization; you don’t need the interior of the network till you get the exterior.

Does IP lose if ATM wins?  Again, only if you believed in the CLEC wave to start off with.  In truth, the impact of all of this on IP may be favorable.  A market that’s highly fragmented doesn’t respond to innovation well, because no player can be assured of getting a good return on investment.  The FCC’s recent activities have been directed at creating RBOC-to-RBOC and RBOC-to-cable competition, and both of these face-offs would involve a small number of companies.  That’s the ideal mix for promoting service innovation, folks.  A big pot of revenue, a small number of credible players, and you get a land-rush to realize the benefits of the market before the other guy.

The question, of course, is just what kind of IP will win, and how IP will do relative to ATM in dollar terms.

ATM stands to gain about $65 billion in new sales over the next five years—“new sales” meaning sales to new infrastructure applications and not just orderly migration or modernization.  IP could pick up between $30 billion and $85 billion, depending on how well “service networking” develops.  That, in turn, will depend on how rapidly the market accommodates reality.

Service networking or content networking is the concept of selling the end user a variety of services, applications, or content based on what is essentially a set of wholesaled infrastructure relationships.  Shifting competition to the service network sector would accelerate IP investment and also accelerate the modernization of the core network, promoting optical technology.  However, service networking is another of those spaces that are subject to hype, and it’s possible that we might create another land rush of funded but dumb approaches.

The big issue today remains the same; revenue transition strategy.  Worldwide, service providers earn 88% of their revenues from voice.  We’re clearly going to migrate away from that kind of voice-dominated picture over time, but during the migration we’ll have to preserve the stability of existing carriers and networks.  Thus, we can’t expect to see changes that are intrinsically destabilizing.  For example, we can’t expect RBOCs to offer cheap streaming-media bandwidth because it could be used by wholesalers to undermine their voice revenues.

In the Know

From the previous section of this issue, it should be clear to our readers that we think new services are the key issue facing our industry.  Without new services, continued price erosion in the current service set will first kill new carriers, then IXCs, leaving only incumbent LECs.  Even these players will be financially strapped, with minimal profits and growth.  Finally, consumers will face a stagnant telecommunications future.  Overall, folks, an ugly picture.

It’s easy to say “We need services!”, but harder to create them.  The issue of what consumers will get in the way of services has become embroiled in the issue of equipment purchasing—what might be called “infrastructure politics”.  Because networks have traditionally created services directly (phone networks create phone services, after all), vendors all want “services” to be defined in terms of whatever natural behavior their own devices happen to present.  Unfortunately, this puts everyone at risk in a period when nobody is really sure just what the buyer will accept in service terms.  Lacking infrastructure to test services with, providers can’t tempt buyers to adopt new communications offerings.  But infrastructure, if it’s classically service-specific, prejudges the whole service issue.  Buy infrastructure to test services and you’ve essentially committed to the service you’re testing, because it’s hard to get the infrastructure to do something else.

Vendors have tended to gloss over this problem by trying to transplant popular current and conceptual services into a single protocol/infrastructure framework.  Voice over IP is a good example of this; it admits that we need voice services but wants to promote the concept of a future IP-specific infrastructure, so it demands adaptation of our current voice concepts to fit that future.

Our view is that all of this is putting the cart before the horse.  We know some things about future services, and before we start installing big iron in networks somewhere, we need to think about how what we know about service requirements could be satisfied in abstract.  If that abstraction could then be embodied in infrastructure, we’d have a way of creating real services.  If the abstraction-embodiment process were generalized enough and flexible enough, it might accommodate a large percentage (if not all) of the viable service models of the present and future, and also the mixture of equipment that’s already in place and is likely to be deployed.  In short, we might solve the service problem the right way.

This is what we mean when we say that we must “separate networks and services”.  It’s an important concept, we believe.  It’s also a concept that requires a different view of how services are really created and supported, because the abstraction-embodiment process (modeling and provisioning, to put technical names on the steps) are classically elements of management software more than of network hardware.

This leads us to our topic, and to the reason we are trying to develop a schema to define what we’re calling service management systems.  The term comes from the old Telecommunications Management Network (TMN) model of network management, where the “service” layer was the top of the management heap.  We’re proposing that it would be possible—nay, necessary—to separate that service management function completely from the device dependencies of network management, and consider the abstract question of service creation and support.  We’re going to present our framework for accomplishing this, and invite vendors to present their own views.  This series will eventually be published as a free PDF file, as our VPN series was presented, but that will be late next summer.  Our framework will be provided to equipment or management software vendors on request for the purposes of responding with their own views.  Otherwise, this is for subscribers only and will not be posted to our web site.  Thus, our text below is only a per-section summary.  Sorry, Internet readers!

First, Some Guidelines to Vendors

We’d like to see how vendors respond to the service management framework we’re presenting in this section, but we have to exercise some control over the way the material is presented in the interest of insuring the newsletters that carry the responses don’t become excessively large.  Please adhere to these guidelines, or we reserve the right to edit or refuse the material you submit!

1.        Material must be submitted in Microsoft Word format, with no more than 4,000 words, including titles, etc.

2.       Figures must be provided in Microsoft PowerPoint format, using simple graphic shapes to control file sizes.  Avoid bitmapped objects in particular!  There may be no more than three figures per submission.

3.       The material must be organized in the structure of the major headings that follow this section.

4.       Submissions must be made via email, with the text and figure files attached.  Do not include figures within your text!

Please note that any material you submit will be considered to have been disclosed to the public without restriction, and CIMI Corporation will be considered to have your permission to reproduce the material with comments and annotations as we see fit.  We will, however, color the text of your original submission to distinguish it from our comments, and we’ll try to avoid interspersing our remarks with your material.

Vendors who are not subscribers to Netwatcher will be sent a copy of the issue that contains their submission, if a request for the issue is included with the submission and an email address is provided.  Our issues are all in Adobe PDF format.

Service Management Framework

Service management systems are software elements that provide for the creation and support of telecommunications services.  As such, they are software entities that must be integrated both internally (among their piece-parts) and externally.

We believe that a service management system must provide the following key elements:

1.       A service modeling component that allows service providers or vendors to create “models” or “templates” that represent services to be sold.  These templates would contain the basic information needed to describe service behavior, but would lack parameter values specific to a user’s applications.

2.       A service ordering component that allows service provider personnel (or selected customers) to populate a template created by service modeling, in order to create a description of a customer service.

3.       A service provisioning component that accepts a populated service model from the ordering component, and commands network devices in the manner necessary to actually create the service as described.

4.       A service support component that monitors the behavior of the service on an ongoing basis, and provides network and/or customer personnel with information on service status.  This component would also have responsibility for altering network behavior to secure correct service behavior, to the extent to which the service management system is designed to be self-correcting with respect to non-catastrophic problems.

5.       “Back office” components designed to support billing, customer care, inventory management, and other tasks.

Service Modeling

Pretty much everyone agrees that in the future, users will buy what are usually called “virtual” network services.  Such services are based on a statistical sharing of infrastructure rather than on dedicated facilities, but the sharing is done in such a way as to make the user of the service believe the service is private and dedicated.

One clear problem with virtual services is knowing just what they look like—meaning what the elements of the service are.  If a service is to appear real and private to the user, it must be presented to the user as a series of real devices, connections, etc.  Since the user can’t be allowed to see the actual network elements (and couldn’t understand them if  they were presented), a virtual picture of the way the network would look if it was real (if you follow our thought there) is needed.  A virtual connection network like frame relay or ATM, for example, looks like a virtual “wire”.  A virtual Level 3 network would appear as a virtual Level 3 device, a node or router.  But who creates this picture, and how is it populated with parameters to describe its behavior?

That, we think, is the central issue of service management, and the issue that service modeling must address.  Any future service must be conceptualized as a combination of service elements, which include both transport or connection elements and processing or content elements.  The way these elements combine to create a service should be relatively standardized for a given type of service offering, and it should be presentable as a “virtual network” consisting of virtual elements that combine to create the expected service experience.

Service Ordering

A service order, in our service management conceptualization, is a service model template filled out with the information needed to describe an actual customer service.  That information would include the location of the customer sites to be served, the service performance parameters, the service level agreement (if any) to be maintained, the performance metrics to be applied to any processing resources (like DNS, routing, etc.), and the all-important activation and expiration date/times.

Service Provisioning

The heart of the service management system is the service provisioning element.  A virtual service—which is to say, any service in the future—will be created by assigning service missions to real network hardware.  Without the automation of this task, it’s hard to make the whole service management framework useful enough to be worth the money, and virtually impossible to control craft cost and effort.

As we indicated earlier, we see the process of provisioning a service as the process of matching a service order “object’ with the object representation of the real network, using policy rules to determine how to make resource assignments.  The output of this process would be a set of commitments assigned to real devices, which would then be converted into commands to create in each device the desired behavior.

Service provisioning runs afoul of one of the key debates in the industry, however.  There are really two schools of provisioning; the connectionless routed school and the connection-oriented school.

The connectionless school (arguably the “Cisco school”) would say that the network of the future is a routed IP network and the services of the future are all connectionless IP services.  The network is thus intrinsically capable of providing the services, and all that is necessary is to classify packets into the virtual private network class (via a network ID) and performance class (via Type-of-Service bits) at the edge.  In short, directory-enabled networking or DEN.

The connection school would say that all services are created from connections and processes, and that each must be established explicitly through commands to the associated devices.  Only through this hard assignment is resource allocation made in a way as to insure QoS and security.

If you buy into one school or the other, you have to support only your choice through the service management system you pick.  If you make a service management system, however, we believe that the ability to support both architectures is fundamental to a good product.  Routed networks produce only about one percent of service provider revenues today, so you can’t ignore connection services.  IP service is clearly the revenue engine of the future, so you can’t assume that at least some connectionless routed networks will also exist.

Service Support

There is no issue more complex in service management than the issue of service support.  Service support is the term we offer to mean the ongoing fulfillment of the service objectives of the combined customer base.  On a per-service basis, service support would be the monitoring of the service behavior to insure that it met the internal policy goals or the external service guarantees (the SLAs) that related to the service.

Service support is more complicated than network support, because a service was originally created though a specific set of resource commitments (or edge-specified packet taggings, in connectionless networks), and not all network elements participate in a given service.  Thus, a network fault isn’t necessarily a fault to a specific service—or, in fact, to any service.

Service support deals with both hard and soft problems at the service level, meaning conditions under which a service fails completely (offers no communications to one or more sites, or loses one or more of its functional components completely), and conditions where the service is operational but not performing according to specifications (excess delay, loss, etc.).  Similarly, service support must recognize that you can’t fix a virtual problem; any service conditions must be translated to device conditions in order for remediation to occur.

Back-Office Process Support

Most of the service management software sold will be targeted at advanced services based on frame, cell, or IP technology.  Services of this type are already being sold, so there’s a good chance that buyers will have existing service/customer bases to apply their new software to.  The provider probably billed these customers, has trouble ticket software, etc.  Thus, it’s very likely that many service management vendors will elect to provide tools to integrate these “back office” functions rather than duplicating the development.  Buyers, in fact, might resist converting any existing records to a new system.

Back-office service activities are those that involve not the dynamic operation of the network but the ongoing process of the business.  These tasks can be divided into two primary areas; customer-and-service tasks, and infrastructure tasks.

In the infrastructure area, the primary issues relate to the classical CMIS management model functions of configuration, performance, and accounting management.  Back-office configuration management would involve keeping up the records on ordered equipment and maintaining a record of the state of each device.  Back-office performance management would be analysis of business trends as they relate to network capacity, with the goal of anticipating the need for network expansion.  Back-office accounting management would relate to standard functions of accounts payable and receivable in non-customer applications (meaning, not related to service billing).

Conclusion

Well, that about covers it.  We believe the efforts associated with developing a framework for service management are well-spent, because we believe that service management systems will frame the service future.  SMS software is to network hardware what application software is to PCs, in short.  It may well be that some SMS player will emerge as the “Microsoft of networking” in the future (no, IOS doesn’t entitle Cisco to that title; sorry, Cisco!).

We think our readers are going to find the vendor responses in this area interesting.  We will be soliciting responses from all the key equipment/infrastructure players as well as those network software players who we think are clearly targeting the space.  We invite our readers to nominate others to receive solicitations.  We’ll publish the responses (if they conform to our structural rules, at the start of this article) in subsequent issues of the newsletter, and will produce a PDF file for free distribution some time next year, when a reasonable time to receive responses has passed.

Strategies

This section is being omitted this month to save space for the Service Management series in the section above.

Down the Line

If we have vendor submissions on our service management framework, we’ll run them as they’re provided us.  We’re also still looking to summarize the RBOC Asub developments, as soon as things stabilize.  Remember, our VPN series is now available as a free PDF file; see our homepage for details!.