7/98 Netwatcher on VPNOSS [ASND references]
Excerpt: 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.
cimicorp.com
In the Know
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.
What's a VPNOSS, Anyway?
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.
Who's Pushing VPNOSSs?
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.
Now, What a VPNOSS Might Look Like
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.
When Will We See Them?
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. |
