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

Technology IPOs are the legally sanctioned version of a ponze scheme.  People start one not because they think the foundation concept is real, but because they think others believe in it.  No matter how high Juniper goes, it doesn’t prove the technology.  It proves there’s too much money in the market.

Having said that, we come to the real developments.  Lucent purchased Nexabit, another terabit player.  In fact, Nexabit has a more objective reason to claim the title of “terabit product” than Juniper, because they have a much higher switching capacity.  But the Lucent release cited the mission of Nexabit products clearly; support for Lucent’s DWDM strategy as the device at the opto-electrical network boundary.

By itself, anything Lucent does is interesting.  In combination with the previous acquisition of Argon by Siemens/Unisphere, it seems to suggest that there’s vendor validation for the perspective we’ve quoted before.  Optical cores are really the way of the future, and dense multiplexing missions will be performed at the lambda level.  The question is how the electrical and service edge of the network will be coupled to that core.  We’ve covered DWDM networking issues in prior issues.  This month, we want to look at how it will impact the vendor landscape.

Lambda networking is a market issue for any vendor who provides optical transport or loop technology.  DWDM permits the sharing of a fiber by parallel information streams, so it offers optical multiplexing on the fiber.  On point-to-point fiber networks, DWDM’s primary value is capacity multiplication (the more lambdas, the more bits) and/or reduction of pressure to support higher-rate SONET (OC-192 and beyond).  In multi-fiber networks, lambda-hopping can reduce the electrical device content of the network and thus reduce capital and craft costs.

For the vendor who offers fiber core technology, lambda networking will (over time) undermine the value of SONET.  The undermining will occur first at the high SONET rates, and move downward as the cost efficiency of lambda networking improves.  In general, the SONET impact occurs at the next SONET rate higher than the current optimum DWDM rate.  Today, for example, the optimum rate is OC-48 and the first impacted SONET speed is OC-192.  As optical efficiency moves DWDM downward to OC-12, SONET impact will increase.

The core player faced with lambda networking must figure out how to justify a device that can terminate a fairly large number of lambdas (at least 128 as the maximum; more on that in a minute) and also terminate the logical electrical network connection speeds that the users’ access networks will deliver.  If we assume that a lambda is an OC-48 (2.4 Gbps), a hundred of these as output, and enough electrical interfaces to fill them, would add up to 480 Gbps of switching by the usual conventions of measurement.  Increase the lambda count to 256 and we get close to a terabit.  Move it to 512 and we’re over that.

Didn’t we then just justify terabit routers?  Not really, because those products are being built on the assumption that the product has a core switching mission.  What we’re saying is that there has to be a kind of lambda-grooming function that steers electrical payloads onto optical virtual circuits.  If this function has to be performed with a degree of service awareness, then this device starts to look more like a kind of super-service-access-multiplexer than a terabit router.

In fact, many of the terabit players get terabits by switching OC-192s in smaller quantities.  Leaving aside our assertion that OC-192s are already dumb based on lambda networking benefits, one side of the lambda edge device is more likely to support many low-speed electrical interfaces.  That would allow this device to be the concentration point for service point-of-presence edge devices.  It’s altogether likely that there would be hundreds of these, each sourcing a DS3 to OC-12.  In many cases, there may be differences in the electrical makeup of these interfaces; some might be ATM, some channelized SONET/TDM, and some packet-over-SONET.  It’s also quite likely that there would be multiple high-level services represented, and that some of the lambda destinations would be ATM, SONET, and packet in structure.  In short, this is a lot more complicated than “routing”.

One of the complexities is the topic we deferred from a prior paragraph, when talking about a near-term maximum of 128 lambdas for fiber.  DWDM technology is in a state of rapid evolution, and it’s very possible that no standard fiber interface will be developed that can adapt to the changing lambda technology per fiber.  Thus, it may be necessary to protect the electrical edge from rapid changes at the lambda edge.

One approach to this would be to have a simple gadget that does a lambda-to-electrical translation.  The optical side could have one or more fiber inputs, and the electrical side a number of STM-formatted (electrical) OC-48s, or a number of simple SONET-formatted (1310 nanometer) optical interfaces.  The real lambda edge device would then hook to this simple adapter, which would isolate the DWDM technology shifts from the bigger and more expensive box.

We’d submit that Lucent and Unisphere are both committed to some form of this strategy in that both have purchased “terabit players” whose only possible valid mission is DWDM access.  What we can’t yet be sure of is whether either company is committed to DWDM networking in the lambda-hopping sense.  If they are not, their acquisitions are probably never going to pay back for them.  If they are, they need to take a quick and effective position on lambdas in their strategic messaging portfolio.

Now, for the access side.  DWDM in the access network is less an issue of capacity multiplication or even lambda virtual circuits, than an issue of infrastructure optimization.  For an access carrier, the customer’s traffic has to be firewalled from other customer influences.  A good way to do that for a customer that can justify fiber access is to give the customer an independent lambda.  That way, each customer’s needs can be met independent of the others, and no one can interfere with another’s traffic.

A good way to look at this is to envision a fiber ring.  If I use SONET for that ring, each customer can have a portion of the SONET payload—say, an OC-12 or OC-3.  The more customers I have, the greater the cost per customer since the price of high-level SONET add/drop multiplexers rises faster at the top end than the capacity itself rises (an OC-192 costs more than 4 OC-48s).  If one customer wants ATM over SONET and another wants packet and a third wants TDM and virtual tributaries, this mixture may impact the choice of equipment, meaning that a change of any customer’s strategy might obsolete or at least de-tune common equipment.

Now, do the same thing with lambdas.  Each customer gets a lambda, and each customer decides whether that lambda is OC-3 or OC-48.  Each customer’s equipment type and vendor choice are non-interfering.  Each customer’s management practices are likewise.

What is required for this situation is a gadget that provides translation from a lambda-formatted fiber to a SONET 1310 nm optical interface to CPE.  This is the kind of box that Sycamore, for example, has already announced.  This box would shield the access user from changes in the DWDM technology base, but the service provider would still have to insure that the DWDM interface was modular so that those changes wouldn’t obsolete the entire box.

Lambda hopping is still useful to the access player under some conditions, and it might help solve the problem of DWDM technology evolution besides.  For example, I might want to have a lambda ring with a “tail circuit” to a customer.  In this case, I’d hop my customer’s lambda off the ring and connect to a lambda on the customer’s (presumably dedicated) access fiber.  If this were done, it would reduce or eliminate the need to interrupt the ring to introduce a new customer, and it would allow the customer to retain a particular DWDM interface on the dedicated access fiber while the ring’s technology was upgraded to reflect better lambda density in new technology offerings.

Will lambdas kill off some of the new-generation outside plant strategies like the ones based on ATM?  Not likely.  Multiplexing in the outside plant (the access network) is required as long as the average customer doesn’t have an optical interface.  Universal fiber access is a long way in the future.  In fact, in some ways the lambda-based plant might accelerate the penetration of new-generation multiplexed access networks.  Such a network could share fiber with an existing fiber-based remote as long as everyone was converted from standard SONET 1310 nm to the DWDM 1550 nm optics.

In the access network, in fact, it’s likely that the success of DWDM will depend on the cost-effectiveness of the 1310-to-1550 converters.  Low cost here will facilitate the transition of existing equipment to lambda-compatible fiber, and also insulate the electrical components of the network from the impact of DWDM improvements, particularly in lambda-per-fiber density or maximum range.

So it is with voice networking.  The focus of the industry has been on “convergence”, meaning a shift of technology focus from voice networking and data networking as parallel elements, to voice and data over a common network.

Convergence may be real (or it may not), but it certainly isn’t driving anything.  Unfortunately, the debate on convergence is obscuring the real debate—the debate on voice features.

If we have to do voice networking over again, for any reason, it’s logical to assume that the primary driver would be revenue, and the primary goal of any technology changes would be revenue maximization.  This, in a feature-driven market, means voice features.  Custom calling, as we’ve noted before, already makes up more revenue for local exchange carriers than data services.  Imagine what could be done if calling features could be created faster, and that the features themselves could be more valuable!

Features 101

In a public or private voice network, the essential service is one of connection—making a call to a desired communications partner.  Essential, minimalist, services have a way of getting price-differentiated, of course, so service providers have sought advanced features to facilitate this essential service of the call.  Some of the features deal with billing (800 and 900 numbers), some deal with who receives the call (forwarding), some with what happens when a call is received (call waiting, voice mail), and some with the aftermath (last number recall).

At a technical level, call features can be more simply classified.  There are features that can be executed entirely “on-switch” at the point of origination or termination, and those that require some form of network coordination.  For the latter—the most familiar example of which is the 800 call and calling-card calls—the prevailing PSTN technical architecture has provided for the generation of “triggers” that pass in message form from a switch to a service logic repository.  The 800 number trigger message moves through the SS7 network, as does the response.  Calling card handling is usually provided by switching the call itself to an Intelligent Peripheral that gets the calling card number, validates it, and redirects the call to the ultimate recipient.

For the network-coordinated features, it’s easy to see how feature programming and even feature creation would work.  First, you have to get a trigger event generated to activate some sort of external network handling.  Second, you have to get some logic on the network to receive and handle the event.

The on-switch features present a greater challenge.  Connecting a call is, in itself, an on-switch feature.  A moment’s reflection will show that a lot of how this process would have to work is dependent on the architecture of the switch.  Furthermore, since this kind of feature may be one that’s invoked all the time, users may be very sensitive to any delay between completion of dialing and receipt of a connection (or whatever the appropriate response may be).

But moving forward for a moment without dealing with the business issues, the process of feature creation and support can be divided at a technical level into the following pieces:

1.       A modification to the state-event logic running in the switch and interpreting subscriber signaling, to generate a request for special handling logic when the feature is invoked.  This invoking may occur either at the called or calling end.  The state-event logic that decides what to do during a call is usually known as the “call model”.

2.       Development of the feature logic itself.  To be useful, this development must support a variety of switch architectures, or it may be too confining to attract customers or developers.  The approach must also be suitable for on-switch or on-network feature development.

3.       Location and loading of the feature logic when the feature is invoked.  This process will have to support a strong element of security to prevent the “hacking” of the public network through the introduction of useless or harmful features.

In the prior issue, we talked a bit about the new-generation voice players and their models.  In this issue, we’ll talk more about the essential process of feature creation, but we're sorry to say that this is for subscribers only!

We can’t claim to have an inside track on insight into the way the deal will finally go down, but we do (like all consultants) claim the right to tell everybody what they should do.  Making an acquisition this big will have an irreversible impact on Lucent’s positioning.  There’s no turning back, so will they go in the right direction?

First, we have to consider how the “right direction” is to be defined.

Quo Vadis, Lucent?

Right now, Lucent is the kingpin of the telecommunications equipment space in the US market, with total earnings (as of the April Fortune 500 rankings) of about $30 billion, four times rival Cisco’s.  Its primary rival in the US market, Nortel, seems paralyzed by the changes in the industry and is no real threat to Lucent any more.  Its new-age rival Cisco has seemingly foresworn the lucrative voice switch market that makes up most of Lucent’s revenues, and thus isn’t a near-term threat, either.

One might think that the best thing Lucent could do strategically is squat down on its current position and let the competitors batter one another.  Not a bad near-term strategy, in fact, but one that probably carries excessive long-term risks.

Lucent stands on the verge of two revolutions, one to a degree caused by the other.  The prime revolution is the shift of public carriers from a voice-dominated profit model to one dominated by data.  Note we said “profit” here and not “revenue”.  As public data services expand, they’ll offer high returns on network investment, and thus justify a lot of new build-outs.  Eventually, these new networks will carry a lot of today’s voice traffic.  As that happens, it could undermine some of Lucent’s voice revenues.

But the promise of new-networks-to-come may create its own threat.  Offshore players like Siemens, Alcatel, and Ericsson, are all hungrily eyeing the US carrier space, and these players are not only willing to offer products that directly compete with Lucent (unlike Cisco, at present), they’re already doing it!  If Nortel is less a risk, these players are more of one.

Faced with these conditions, Lucent can’t rest on its laurels.  That’s why the Ascend acquisition can make real sense, but also why how it’s handled is so important.

Five Rules for the Future

Lucent has to look at its absorption of Ascend and common positioning challenges in the light of 5 simple rules.

Rule One is “Thou shall not mess up thy incumbent voice market”.  Service providers have hundreds of billions of dollars worth of traditional gear installed, and despite the technology hype there’s no good reason to mess with it in the near term.  Thus, Lucent could expect to ride the wave of inertia for at least a couple of years while they get richer and competitors (possibly) get poorer.

Messing up the incumbent market would be easy.  If Lucent, in an effort to counter the PR wave of voice over IP, should appear to be saying that IP is really the wave of the future for voice, they’ve completely rehabilitated Cisco’s position and created an incentive for service providers to shift more rapidly away from the very type of equipment Lucent makes its greatest profits selling.

Does that mean standing pat on TDM voice and positioning ATM and IP as important only in the data space?  No way.  Rule Two is “Thou shall not stick thy head in the sand, media-wise”.  The status quo is the least likely thing to be written about by the technology press, whether it’s the best approach or not.  “News” means novelty, not truth.

A positioning that says “TDM forever” is a fully paid ticket to oblivion in media visibility terms.  From such a position, Lucent would have no means of exercising any form of market manipulation, and would thus be helpless to even promote its own good messages.

Good messaging is needed because Lucent can’t settle for a win in the TDM voice space while losing the new wave of data opportunity.  But Lucent also can’t just promote IP, because the market’s association of Cisco with routing and routing with IP/Internet is strong.

Sticking to TDM would also tend to force the Ascend products to justify themselves purely on a data mission, foreswearing the traditional ATM multi-service value proposition.  In short, Lucent is balanced between a need to maintain TDM and evolve it, from a need to validate IP and a need to differentiate from it.

But to some degree Lucent has set its path by acquiring Ascend in the first place.  Rule Three is “Thou shall love ATM with all thy heart, because that’s what you bought.”  Whatever the press may think of Ascend, it’s the ATM products that will make or break the acquisition.

Ascend’s ATM switches are incumbent in some of the most important accounts in all the carrier world, and Cisco is incumbent in only one of these major accounts (AT&T, which it shares with Ascend).  If Lucent can control how these players evolve their Ascend networks, they have a shot at controlling how the key service provider networks evolve toward non-TDM infrastructure.  In short, these guys are the keys to the kingdom and Lucent already has them…to win or lose.

Winning, or extending the current incumbency, isn’t a slam dunk.  The service providers themselves are playing a balancing game, between the revenue truth of voice and the revenue promise of data.

What wins for Lucent here?  A view that voice revenues won’t fall precipitously (which is what the major carriers want to believe anyway, and also what’s true), and that new-generation infrastructure will therefore be more ATM-like in the near term.  A view that IP services don’t necessarily mean routing.  A view that in troubled times, it’s best if buyers stay the course with trusted partners.

All of that is possible, in fact easy, for Lucent to accomplish—if they can contain the IP PR blitz.  That leads to Rule Four, “Thou shall extend thy Ascend TNT product more into the facility VPN space, because connectionless routing and the Internet is the land of iniquity”.  The media needs IP pap to throw the masses, and simple Internet pap is Cisco’s alone to throw.  Ascend’s TNT line is incumbent in the ISPs, and if Lucent can get those products aligned more toward facility VPNs, they can lead the Internet community to a new revenue source that will quickly overwhelm the Internet.  If you can’t win their hearts and minds, buy the suckers.

The weak link here is the full circle this brings us.  We started out trying to protect the incumbent providers’ positions in Lucent voice gear, and now we’re trying to support their competitors.  This seems to some to compel an IP-driven value set, which would open up the RBOCs to Cisco, which would threaten Lucent’s short-term and long-term revenue stream.  How to save it?

Rule Five is “Thou shall not forget the FCC sets the business framework, not the trade press”.  The FCC says that whatever the ILECs (including the RBOCs) deploy, they must wholesale to all comers.  Right now, the RBOCs don’t really deploy much ATM or IP, so which way do they turn?

To ATM, says Lucent, logic, and the FCC (indirectly).  There is no retail market for ATM to speak of, so an RBOC decision to make it the basis for advanced infrastructure exposes them to no new risk of wholesale-retail arbitrage.  Remember, about 90% of CLEC lines today are simply wholesaled and resold.  Why?  Because there is a retail market for the wholesaled services.  Deploy ATM and the wholesale risk is minimized because a CLEC can’t buy ATM at 23% off and resell it at only a slight discount, earning a nice return for doing nothing.

IP is the opposite.  Build your infrastructure on “converged IP” mister RBOC, and you’ll have to wholesale the very thing that all that new profit is coming from.  Every sleazy little technocrat with a couple of bucks will become an ISP, VPN player, or both, on your capital investment.  You went to the FCC last year to try to avoid having to wholesale the elements of advanced data services (the so-called “706 appeal”), so don’t blow it now.

What Happens Now?

Now, it’s time for Lucent to decide.  While they haven’t made their positioning in the Ascend deal clear at the time of writing this, they’ll have made their move by the time you read it.  But that doesn’t mean we’ll know the answer to our questions.

Lucent, like most big companies, has forgotten how to speak with one voice, and they need to come back to messaging basics (Cisco, who has only one thing to say—routing—doesn’t need to re-learn it).  If they follow their usual pattern, the new positioning will be complex enough that their real views won’t even show through.

That’s not a disaster, though.  Lucent has time, because their competitors have given it to them.  Over the next six to nine months, the real nature of the Ascend/Lucent deal will emerge at the sales and product level, where it’s impossible to hide the truth.  As this happens, we’ll see how Lucent answered these questions.

If Lucent moves strongly in the right direction, they’ll quickly jump to $70 billion or more in revenues.  This will put them out of Cisco’s reach forever.  It will also insure that Siemens, Alcatel, Ericsson, and other international telecom equipment vendors will have to content themselves with the number two slot.

If Lucent moves weakly, they’ll still outpace Cisco (though by a smaller margin).  Most significantly, they’ll lose about a third of the North American next-generation network market to their offshore competitors.  That will make trouble for Lucent as the data wave moves convincingly into the international space, some time around the middle of the next decade.

If Lucent moves wrong-headedly, they could end up with less than a third of the new-gen network equipment space, and thus have to fight off Cisco, Nortel, and all the international competitors on much more like an equal footing.  Then, their long-term position will depend on how well Lucent can execute in the world market, where they are a decidedly small player today.

OK Lucent. Decide.

Access the index of CIMI Corporation's recent newsletters.