SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : Ascend Communications (ASND) -- Ignore unavailable to you. Want to Upgrade?


To: djane who wrote (53158)8/29/1998 10:30:00 PM
From: djane  Read Replies (1) | Respond to of 61433
 
T1, Anyone? Data Centric CLECs Make the Push for Non Voice Services [ASND reference]

x-changemag.com

By Gary Kim

Only three things matter to competitive local exchange carriers (CLECs)
choosing access platforms: data, data and data.

"Voice over data is a huge trend," says Lonnie Martin, ADC
Telecommunications Inc. senior vice president.

Already, "many CLECs are focusing heavily on data services, including
ICG Communications [Inc.], e.spire [Communications Inc.] and MDC
[Communications] in Canada," says Roger Koenig, CEO of vendor
Carrier Access Corp. And that means growing emphasis on Internet
protocol (IP), asynchronous transfer mode (ATM) and frame relay
services.

But the practical realities are that CLECs are scrambling to provide the
services smaller businesses know they need today. That means support
for office key systems, private branch exchange (PBX) equipment, local
area networks (LANs) and Internet access.

So CLECs must connect to routers and voice switches. And, generally
speaking, that means a heavy reliance on T1 technology as the access
method.

Customer parsimony and carrier desire to maximize revenue are factors
leading to the reliance on T1. Since smaller businesses are quite price-
conscious, CLECs want low-cost solutions and the ability to capture
multiple revenue streams. That, in turn, leads to a desire for voice and
data delivery over a single pipe.

"I see the majority of CLECs going to a multiline data and voice platform
to address the smaller and medium businesses, those that have
$1,000-a-month total telecom bills, on a profitable basis," says Koenig.

The logic is fairly simple. CLECs excel financially when a single T1 pipe
can be filled up with voice and incremental data traffic. "One
infrastructure, multiple revenue streams" is the mantra.

Leasing full T1 circuits from the incumbent local exchange carrier (ILEC)
is an option. But CLECs can do even better when two copper pairs can
be leased at $50 and outfitted with high-bit-rate digital subscriber line
(HDSL) modems to deliver multiple voice circuits and high-speed
Internet or data access. So CLECs are installing traditional time division
multiplex (TDM) access equipment, including channel service units/data
service units (CSUs/DSUs) and integrated access devices (IADs) that
handle IP and frame relay traffic, typically using HDSL. Despite the
growing importance of newer synchronous protocols, T1 and DS-3 are
the mainstays of CLEC access.

"You can put lots of things inside that kind of pipe, which is why it's
popular and will grow for long time," says Martin.

Of course, there's no disagreement about the importance of IP and
ATM. But "the speed at which the data revolution occurs is the subject
of debate," says Stephen Susina, marketing manager for Tellabs
Operations Inc. "But the traditional transport market continues to grow,
and there still is no shift in customer demand in terms of what they
actually deploy."

Packet Fever

Early summer telecom developments reinforced the notion that data is
hot.

Even media companies further validated the notion that the Internet is a
strategic new medium when Walt Disney Co. bought a 43 percent stake
in Infoseek Corp., the web browser/
portal firm, with an option to take majority control. Meanwhile, the
National Broadcasting Co. (NBC) acquired 19 percent of Cnet Inc.,
another portal firm, with an option to increase the stake to 60 percent
within three years.

Telephony's equipment giants similarly signaled data's exploding
importance. Northern Telecom Ltd. acquired Bay Networks Inc. Lucent
Technologies rolled out its line of "PacketStar" IP systems, while virtually
every other major telecom switch provider said it would do the same.

Carriers also made data-centric moves. Sprint Communications Co.
announced an accelerated move to an all-cell, all-distance ATM network
it calls the Integrated On-Demand Network (ION). AT&T Corp.,
meanwhile, introduced its new "GeoPlex" software environment, which
allows third-party programmers to develop applications for the AT&T
network. AT&T also tried to buy America Online Inc., but was rebuffed.

It's not hard to figure out why data is the "only" thing that matters.

According to analysts at Strategic Networks Consulting Inc., IP traffic
will consume more than 90 percent of global bandwidth by 2003.
Planners at Bell Atlantic Corp. and Sprint likewise estimate that IP
revenues will eclipse 1998 voice and data revenues by 2001 or so. And
of the 80 billion minutes worth of U.S. network traffic in 2001, about half
will consist of IP or frame relay packets or ATM cells, according to
Yankee Group analysts.

In the next century, data services will provide 80 percent of carrier
revenues, but will comprise only 40 percent of network traffic, says
Voorhees, N.J.-based consulting firm CIMI Corp.


That has to drive CLEC thinking on access platforms as well. Yankee
Group researchers are more cautious, estimating that of the $140-plus
billion carrier services market in 2001, just shy of $40 billion will be
contributed by data services. So it stands to reason CLEC access
thinking will be dominated by data access.

T1

Of course, the U.S. competitive access provider (CAP) market was built
on private line (T1, 1.544 megabits per second [mbps] connections,
especially) service, primarily to connect business customers with their
long distance carrier points of presence. But CLECs now are assaulting
the much-larger switched services market. And since data increasingly
drives the business, frame relay, IP and ATM services should be wiping
out the private line T1 business, right?

Nope. T1 continues to grow. Today, some 1.6 million T1 lines are in
service in the United States, with growth rates in the 25 percent-a-year
range, according to researchers at DataQuest, a Gartner Group Inc.
company, and the Multimedia Telecommunications Association. This
figure includes both "wholesale" use of DSL as a method for increasing
capacity on existing copper and "retail" lines sold to end users.
Executives at PairGain Technologies Inc., for example, suggest that
DSL-driven T1 growth is in the 40 percent annual range.

Internet service providers (ISPs) are part of the reason T1 growth hasn't
leveled off the way many observers anticipated.

"To support the growth of the Internet, 350,000 T1s and 25,000 T3s will
need to be provisioned during the next four years," says Paul Johnson, an
analyst with banking concern Robertson Stephens. "Compare this with
today's installed base of about 300,000 T1s and 2,200 T3s."

DSL is another reason T1 keeps growing. Where traditional T1 systems
require repeaters every 3,000 to 6,000 feet, DSL loops can reach
12,000 feet without using any repeaters. That translates into lower cost
and higher usage. CLECs, for example, can lease "dry" copper pairs and
convert them into T1 spans using HDSL modems.

"The most important thing today is to aggregate voice and data over a
single pipe," says Dave Gallerman, Newbridge Networks Inc. vice
president. "And of course, price, price, price."

The emphasis on integrated, affordable solutions is a direct result of
CLEC focus on smaller and medium-sized businesses. Such customers
focus on upfront capital costs, not life-cycle cost or "total cost of
ownership." They also tend not to have in-house networking expertise.
So CLECs want a simple, do-everything solution and equipment prices
that don't scare customers away.

None of which is to say demand for capacity won't skyrocket further.

"DS-3 prices are going through the floor now," says Jesse Price, Eastern
Research Inc. marketing vice president.

If so, CLECs will be looking for channelized DS-3 equipment that
terminates directly at the PBX and router, says Price.

As that trend continues, CLECs will gain more freedom to choose
platforms. Today, it makes a difference which transport format a carrier
chooses.

"Up to about 9mbps, it makes a cost difference whether a carrier
chooses ATM, frame relay or TDM," says Tom Nolle, president of
CIMI. "At T3 and above, it doesn't matter that much."

What ultimately may matter is which packet format is used and by whom.
Most incumbent carriers are ATM adherents. ISPs and several of the
new long distance carriers are IP-centric. It remains unclear what CLECs
ought to do.

"The crux of the CLEC business is that it's hard to make bets about
technology," says Leif Hoglund, business development vice president for
E/O Networks.

T1 is fundamental. "But the access part of the market is really fraught
with confusion," Hoglund says. "ATM to the desktop, IP over SONET
(syncronous optical network) are examples. You can't tell where it's
going to go."

What is abundantly clear is that no carrier wants to deal with "stranded
capital," in which network assets are deployed but only a fraction of full
capacity is used, or in which capacity cannot be expanded to meet
additional need. Even the regional Bell operating companies (RBOCs),
for example, now are investing in smaller line-count digital loop carrier
(DLC) equipment
, says Kris Sowolla, E/O Networks product
management director.

CLEC Trends

CLECs tend to fall into three camps when it comes to access platforms.

Some carriers have a clear focus on services they expect to offer, and
want an optimized platform that addresses those services. Such a
business strategy favors single-purpose terminals that trade flexibility for
lower initial capital investment. Chicago-based Focal Communications
Corp., for example, is a local dial tone specialist. NorthPoint
Communications Inc. and Covad Communications Co., have different
business strategies based on a wide variety of potential services, including
voice, data and local and wide area networking. In such environments,
flexibility is more important.

Some contestants also are betting that new applications, as yet
unforeseen, will be important. So platform adaptability is strategic for that
reason, as well. Data-centric and "bundled services" providers such as
Intermedia Communications Inc., GST Telecommunications Inc. and
Convergent Communications Inc. are examples.

"If you're in a 'get-me-to-revenue' mode, you may not want to pay for a
multifunction solution," says Gallerman.

The low-cost, application-specific terminal fits there. But "some service
providers want to do a limited set of things real well, while others want to
do everything the customer wants," says Gallerman.

The integrated, feature-rich device may work better in that scenario.

Its the Equipment Stupid

As one might expect, two concurrent trends are seen in access
equipment. Cheaper, single-purpose equipment and integrated,
multifunction devices are available. One example of the single-purpose
terminal is the ADC Satellite 651 CSU/DSU. It's aimed at the
business-to-business ISP, for example.

Vina Technologies Inc.'s T1 Integrator is a prime example of the
multipurpose trend. The Business Office Exchange version, for example,
supports key system voice switching as well as remote and Internet
access. It incorporates the functions of a router, channel bank, T1
CSU/DSU, multiplexer, frame relay access device and Internet firewall.

Adtran Inc.'s Total Access Multi-Service Optical Platform is another
example of the "multifunction" trend. Total Access supports HDSL,
integrated services digital network (ISDN), T1, optical DS-2 and DS-3
access at a central office or point-of-presence. Likewise, Premisys
Communications Inc.'s Q-155 supports TDM traffic (T1/DS-3), frame
relay, IP, ATM and HDSL on the access side of the terminal, and
SONET on the transport side of the terminal.

HDSL integration also is a prime trend. Telco Systems Inc.'s Access 60
and Access 45 integrated access devices, as well as the ADC
Telecommunications/Carrier Access Corp. EZT-1/DI-HDSL terminal,
for example, incorporate HDSL directly into access terminals. One
advantage is the marrying of Soneplex management tools with the
lower-cost access device.

"We're seeing more and more requests for simple network management
protocol (SNMP) capabilities built right into the access vehicles," says
Rick Vesny, ADC marketing director.

Carriers also are trying to collapse whole layers of equipment in the
network. Trends such as IP over SONET (see related story, page 26)
and multiservice switches are examples. The Ascend Communications
Inc. GX 550 combines digital cross-connect system (DCS) with SONET
multiplexer functions to collapse a SONET, DCS and frame relay/ATM
switch into one device.


The same approach to simplifying networks applies to the Lucent
Technologies Inc./Sun Microsystems Inc. "ISP-in-a-box" approach. The
two firms bundle IP telephony, remote access, network management,
e-mail server, web server and electronic commerce capabilities.

IP was once considered a legacy technology destined for rapid
replacement by open systems interconnection (OSI) protocols. Instead,
OSI died, while IP has swept the world. T1, also a legacy technology, is
probably going to surprise us as well.

Gary Kim is strategic research director for Convergent
Communications Inc. He can be reached at (303) 749-3061.

Copyright c 1998 by Virgo Publishing, Inc.
Please read our legal page before using this site.





To: djane who wrote (53158)8/30/1998 8:23:00 PM
From: djane  Respond to of 61433
 
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.