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

In past issues, we’ve looked at the shake-out in the equipment vendor space, a shake-out arising from changes in the nature of enterprise network-building. It’s time to do the same for the carrier services space, and to do that we have to look back into the past.

Telecom ’96 changed that, providing the RBOCs with the incentive (release from offering long-distance calls in their regions) to open their local market to competition. PUCs in various states moved with varying degrees of aggression to mandate local competition, but none of the RBOCs have yet filed papers with the FCC proving adequate compliance with the 14 competitive requirements of the Act, and so the Act’s mandated reforms are not yet effective.

Speaking of time telling things, we’re waiting for the dice to stop rolling on the question of what happens to BellSouth and US West in the RBOC space, and MCI/WC and Sprint in the IXC space. None of these firms are viable in stand-alone mode in a fully competitive market, and the number of possible match-ups are shrinking.

ISPs will follow as the last phase of this market. Media hype notwithstanding, the Internet is a revenue pimple in today’s market, and nobody smart is going to try to secure it when the bigger sectors are still up for grabs. By about 2001 or 2002, however, the VPN market will have grown enough to encourage more traditional players to buy a larger position in the public IP space. This will send all the merged megaplayers to the ISP supermarket, and the result will be the consolidation of the Internet space with the traditional voice space. This will be done by about 2005.

One thing to keep in mind about the carrier space is the dependence on regulatory policy that we cited at the opening of this section. Regulations are government, and government is politics. Anything can happen.

Most carrier relationships today start with an order and not with technology. The administrative infrastructure of the carrier world is not well known among users, even though every phone call and every service order consumes it.

Operations Support Systems, or OSSs, are the support foundation of voice telephony, and also of traditional data services based on leased lines. For some time, carriers have been wrestling with the question of how frame relay services, for example, would interwork with these OSSs. Now that data VPNs are on the horizon, it may well be that work is already obsolete, because VPNs mandate a whole different set of features.

What’s in a "VPNOSS", as we might call these new systems to support data VPNs? Is the VPNOSS a replacement for, an adjunct to, or what, with respect to the current OSSs? Are there key players emerging in the VPNOSS space? These are the issues we’ll consider in this section.

An OSS provides carriers with order support, trunk and circuit inventory and management, trouble-ticket handling, and billing. However different VPNs may be from traditional services, it is clear that all of these functions wouldn’t need to be redone from scratch to form a VPNOSS. In fact, it is certain that carriers would want to reuse large portions of their existing systems—if for no other reason, to protect skills and practices developed through years of use.

VPNOSSs might be expected to interact with OSSs on a sector-dependent basis, as follows:

1. In the order processing space, it is likely that VPNOSS order elements and provisioning issues would be very different from that of the services supported under current OSSs. Thus, it would probably not be useful to attempt to tightly integrate VPNOSS order management and provisioning with that of the traditional OSSs.
2. For trunk and circuit inventory management, VPNs consume a very different kind of resource than traditional circuit-mode networks, and it is likely this area would also not be readily adapted from OSS to VPNOSS.
3. The trouble ticket or problem tracking area for VPNs should not be dramatically different from the comparable OSS area, and it should be possible to adapt the current systems to serve quite well. However, problem isolation and relating network problems to specific customer commitments will require considerably greater effort with VPNs, given the shared infrastructure. Some VPNOSS changes will be required.
4. Billing, in the form of bill generation and receivable tracking, should be the same for VPNs. However, billing elements for VPNs will depend on a different set of chargeable items, and journaling billing events will also likely be different. Thus, VPNOSSs may have to augment standard OSS features here, but will not displace most of them.

From this, we can draw a picture of a VPNOSS. It is a new high-level provisioning and order entry system for VPN services that will be available to service order processors in a carrier center. The VPNOSS will facilitate the gathering of service parameters, and will then provide a means of provisioning the requested service onto the network, making necessary changes in resource inventories. Problem analysis and management elements linked to the shared-resource VPN infrastructure will feed the current problem tracking software, and new billable event journaling elements will provide input to a slightly modified billing system.

A logical question to ask here would be how this structure will be formulated into a product. However logical the question may be, it’s one that’s hard to answer at this point. The problem is that the evolution to a VPNOSS will be influenced by a variety of forces, and it’s not yet clear how those forces will balance over the next five years—the critical period for VPNOSS evolution.

It would be surprising if the first factor that determined the direction of VPNOSSs wasn’t the direction of VPNs, and happily VPN trends are the primary issue. Today, what buyers would call a "VPN" is most likely to be a frame relay or ATM network and associated access equipment, perhaps with some carrier management thrown in. This early VPN structure has its own "VPNOSS" in the management software of the infrastructure vendor.

Frame relay and ATM network management systems provide basic VPNOSS support in the areas of provisioning and problem management. This limitation of scope is not unreasonable given the fact that these services are sold primarily in the form of PVCs, and are subject to relatively long service contracts. In effect, the user’s network is one-off provisioned using a standard management console. The service order function consists of recording the requirements, which are passed in memo form to a specialist who then makes the necessary network changes.

In the problem management area, the virtual circuit nature of ATM or frame relay allows reasonable (but not complete) association of network problems to users, and trouble ticket software is generally offered for problem management.

Billing is handled by creating a recurring monthly contract charge for the service based on the individual pricing of the service elements. Because this is a contract charge, there is no need to meter usage or record special service events.

What this has done is effectively build a completely parallel VPNOSS, one that has no real integration with the standard OSS structure of the carrier. As we noted in the opening comments of this section, this has already resulted in some carrier pressure to create more efficient linkages between the management platforms of frame/cell networks and the OSSs. Thus, the carriers are pushing for some improvement.

The equipment vendors are also pushing, but for more infrastructure in the form of a network to provide for IP VPNs. These VPNs would be offering a connectionless service rather than virtual circuits, and would involve more OSI layers. Both these factors could be expected to make provisioning the service more complex, both in terms of taking the orders and in terms of managing the resources that individual VPNs can consume.

In truth, an IP VPN changes the picture of VPN provisioning fairly radically. Radical change, however, is not the friend of a vendor market segment like network management that’s been a loss leader for a decade or more. Thus, current equipment vendors have tended to attack the problem of supporting IP VPNs using their basic network management offering. Both Cisco and Ascend have recently announced new management features targeting the VPN market, and both have made these features extensions of their management architecture. While both vendors would certainly like the market to view their new offerings as completely new, they are in fact largely based on previous management product elements.

There are other potential players interested in the VPNOSS space. Network management vendors like Micromuse who focus on the fault/alarm correlation and management process may find the fault interpretation aspects of VPN requirements a launch point for their products into the VPNOSS space. Multivendor provisioning vendors like Syndesis could jump off from the VPN requirement to support services across a variety of vendors’ equipment.

What we’re saying is that the shape of a VPNOSS will probably depend on what market forces gain ascendancy over the next year or so. If VPNs develop relatively slowly, we would expect the infrastructure vendors to retain more control over the evolution. If the opportunity develops quickly, the pressure to have a good solution in the VPNOSS space would tend to empower newer players.

As we would see it, the core of a VPNOSS would be the same no matter what kind of player ends up controlling evolution. Virtual network services need to be made concrete in order to be ordered and provisioned, so we would expect that all VPNOSSs would be built around a visualizer element that would create an icon or icons that could be said to represent a given VPN. The customer service rep at the carrier and the buyer’s representative would collaborate to create this VPN image, using interactive tools.

Once the image has been created, a VPNOSS would have to forward the image to a provisioning process to determine if the network infrastructure could support the resources required for the VPN. If the resources were not available, the VPN buyer would have to be contacted (assuming that this wasn’t done in real time) and some resolution to the problems discussed. If the resources were available, the network’s resource inventory would have to be reduced by the requirements for the VPN (even if it were to be made effective later, to be sure that resources were available at the time the VPN was turned on).

The provisioning process is the first place we might see some differences in structure based on the direction the VPNOSS vendor happened to take. An infrastructure vendor might elect to use a link to their own management system to provide the resource inventory and the provisioning interface combined. Thus, to these vendors the VPNOSS is an overlay to their normal management system. Most of the features of provisioning would reside in that management system.

This overlay approach also demands an accommodation to the multi-vendor nature of networks, so equipment players in the VPNOSS space are likely to have an interface to other vendors’ management platforms as well. This would make the VPNOSS a shell around whatever EMSs were in the network.

Vendors who are not players in the equipment space would probably not elect to cede as much functionality to the management system, since these vendors would have to rely on management features of various players. Instead, they would be likely to create sophisticated network map and inventory systems to serve as the basis for the provisioning process, and create specialized software to thread routes for VPNs based on service requirements. This would make them less dependent on the features of equipment EMSs, but since it is not possible to provision frame/cell products based on standard MIBs, some specialized code would be required for each vendor.

The same network image that guides provisioning would have to be used in problem analysis, for two purposes.

First, the resource commitment of the infrastructure to support this particular VPN would have to be recorded with the image so a problem in the network could be correlated to the VPNs it impacts. The way this would work would vary depending on what kind of VPN was involved (virtual circuit or connectionless) and what strategy was used to actually commit resources to it.

Second, the VPN image would form the repository for status data on the VPN, and this would be the basis for a customer display of the VPN—a network icon in the customer’s management system. Problem tracking would have to work off this image, at least where problem tracking was customer-specific. We would assume that the trouble-tracking system would start with "real" hardware problems and generate VPN-specific trouble entries based on the image of the VPN. Customer complaints would have to follow the opposite route—start with a VPN trouble ticket and correlate that and other reports with the network to deduce where the real fault could be found, then generate a hardware ticket on it.

The billing aspect of the VPNOSS may be the most difficult. VPN images could be used to drive a software process to poll nodes and read relevant statistics, but this would impose an operating load on the network. We expect that the VPN players will eventually recognize the virtue of a Bellcore concept called "originating node journaling", where the access device linking the buyer with the VPN at each site is responsible for collecting the data needed to journal the events for billing.

This could have interesting impacts on the role of Class 5 switches. If a large portion of the line population in a given CO were to be VPN-equipped, adding data VPN capability to Class 5s through the use of an xDSL data card that pulled the data off onto a parallel LAN would be practical. In this situation, the data card would feed its data around the Class 5 itself, but journaling events could be funneled through the Class 5 into the billing system.

The originating-node concept plays well with VPNOSS promoters from all camps, because there are really no incumbent VPN edge players. Buyers don’t associate VPN access with routers or FRADs in any determined sense, so incumbent equipment vendors don’t have a lock on the space. With new vendors as valid as old, the software companies targeting the VPNOSS space have plenty of partnership opportunities.

There may be some special handling required on the billing side itself, depending on just what factors are used to develop the charges for VPNs. Time billing can be accommodated easily, and message unit billing practices might be adaptable to usage pricing as well, even that based in part on QoS. Nevertheless, it is clear that a more flexible system of "call detail recording" would be helpful, and that would involve making billing systems understand all of the new options.

The opening gambits in the VPNOSS wars are already underway, with Cisco and Ascend posturing the most impressively. Lucent and Nortel both appear to face some architecture changes if they are to fully realize the VPNOSS potential. While both companies certainly have the resources to make the changes they’d need, the time component of the picture isn’t as favorable for them.

None of the software players, including those we’ve mentioned, has been able to gather the right combination of partners and press attention so far. In truth, it’s not clear whether any software firm is really going to try to field a full VPNOSS, or just court partnerships with an infrastructure vendor.

By about 2001, we expect VPN activity to be impressive enough to create major problems for service providers who don’t have a proper foundation for the operations support process. That, ultimately, will set the forward limit on how far the market can stumble along without a good solution.

There’s always a chance for a surprise in this space. US West, at least, has taken the step of going to a software provider (Syndesis) for a "topology mapper" element that would create for the carrier the central model of provisioning we talked about earlier. With the carriers’ big wallets opening, a lot of action could take place in a hurry, even from players who have little or no established position in the market. Remember, Cascade jumped into frame relay prominence on the strength of the potential RBOC frame relay market alone, without any real wins to back them up. That shows that even a new player can become a giant when the market conditions are prime—which they may be.

Dense Wavelength Division Multiplexing is a topic we’ve explored in a "definition" sense in a prior issue. What we’re going to examine here is how the market for DWDM could develop, and where that might impact the rest of the network product and service market.

The reason this is important is the growth of data traffic. If we measure network traffic at the point of origination and convert everything to digital form, voice or circuit-mode traffic still makes up over 80% of the traffic in the network. Most of this, however, is local calling that never touches a backbone. On long-haul backbones, voice is only about 55% of traffic today, and that number is shrinking. The introduction of this kind of data volume in standard SONET terms would result in all manner of new high-level SONET ADMs, possibly displacing some of the current gear. With DWDM, the new data stuff goes onto its own lambdas and the other traffic and equipment is untouched. The most efficient way to add high-speed data traffic to a fiber network is DWDM.

As great as this sounds, it’s not quite that easy. Most of the older optical gear isn’t compatible with DWDM lambda division—the old stuff slops over all the lambdas and generally messes things up. Thus, it may be necessary to replace older optical gear to make fiber DWDM-compatible in the first place. If that first cost can’t be justified, it may be hard to bootstrap DWDM in. This is particularly true in outside plant applications, because the financial benefits of DWDM are more limited in these applications owing to lower traffic density.

Photonic processing of various types is clearly a key to the widespread deployment of DWDM, because this type of handling would reduce the equipment cost in a DWDM network. Without it, the tendency will be to focus DWDM on long-haul transport applications where the ratio of fiber cost to equipment cost is high anyway.

It is the revenue source, not the technology, that will catalyze DWDM.

In our next issue, we’re going to review the recent activity in the "SS7" space. Cisco has acquired Summa Four, a small switch vendor with a strong SS7 focus. Ascend now proposes to acquire Stratus, a major player in SS7 nodes and processors. What’s happening here? We will also be sending out our vendor questions on advanced ATM carrier switch products early in September, with an eye on publishing the first analysis in early December. Vendors note: We will be publishing reports in roughly the order we receive responses.

CIMI Corporation’s market report "IP VPNs and MPLS: Twin Keys to 21^st-Century Public IP Success" will be available on August 19^th. Interested parties should contact us for an executive summary and order form. Please note that this is a controlled distribution report, and you must qualify to receive it. Do not send money unless you have been advised that your order is approved.

Access the index of CIMI Corporation's recent newsletters.