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.

To summarize what we think the issues are by class of carrier:

1. Incumbent LECs will be looking to protect their access connections to their key customers, and to expand their service set as far as current regulatory largess permits, so as to cement themselves as full-service national players.
2. CLECs will be looking for a defensible niche in the near term, one with a high enough revenue margin to finance infrastructure growth and sustain stock price or effective market cap.
3. Incumbent IXCs will be looking first to protect their current customers from competitive predation, and then to create high-bandwidth access relationships with key customers to gain and maintain account control.
4. New-Gen IXCs will be looking to garner revenue in nearly any legal form to maintain their access to capital and their credibility.
5. ISPs will be seeking profitability, primarily through increased business offerings like VPNs, and to formalize interconnect with other ISPs to eliminate problems with performance (see Strategies in this issue).

M&A has been the focus of activity since the Act was passed, and there are still some events left on that dance card. Both BellSouth and US West remain unallied, and neither is likely to be able to sustain itself in the long run without a partner or two.

Once they have complied with the Act, a merger between either player and an IXC partner would be logical. BellSouth is a plum that any IXC would love to pluck; US West is probably interesting more to a new-gen player. It’s possible that US West and BellSouth might come together to form a third giant ILEC. It’s unlikely that either will merge with one of the two existing ILEC giants—SBC or Bell Atlantic.

The massing up of the ILECs is the greatest competitive threat to the IXCs, because it means that any of the new giants could offer highly credible national services to its customers and be sure of enough of a ready audience to justify the investment in infrastructure.

On the other hand, the ILEC M&A doesn’t force them to offer regional and national toll services, it only facilitates it. We expect to see the IXCs hold off on a lot of highly competitive actions (though not on posturing) until there’s really an indication that the ILECs are poised on the edge of entering the national market. FCC approval is required for at least regional toll, so it’s likely that when such approval seems imminent, the IXCs will move.

Of the IXCs, AT&T and Sprint both seem to have a strategy of at least partial facility bypass through PCS. While PCS won’t solve their business service problems, it will certainly be a viable way to address the upper end of the residential market, the "yuppie" play.

MCI Worldcom is lacking in PCS service options, and their local access activity is still small by their own recent admission. They are the ones most likely to view with interest the acquiring of an ILEC. That would give them at least a core region where they could offer full services to everyone.

MCI also seems to be relying on data services, particularly the UUNET Internet service. That reliance may make them vulnerable, because it’s highly unlikely that revenue growth on the Internet or on data services in general will be nearly as high as predicted. We expect to see some retrenchment of MCI by this time next year, reflecting a more realistic (if late-coming) projection of the data opportunity.

AT&T will clearly be holding their cable play in reserve as a means of guaranteeing customer access to at least a large portion of their market. We don’t think they’ll actually play a cable voice card for now, though. They can gain nearly the same benefit without the investment and risk by bundling conventional long-distance services with their cable and Internet/cable offerings, relying on continued delivery via the ILEC. Until the ILECs’ xDSL offerings are very mature, at the very least, IXCs can rely on the ILEC having to preserve the current long-distance carrier relationships if the customer wants. With xDSL access, it’s possible the ILEC would bundle the service with their own long-distance offering, as indeed they do today with most of their ILEC PCS/cellular offerings.

Sprint probably can’t rely on its PCS strategy alone, and it appears to be hoping to attract a larger-than-usual piece of the integrated high-end corporate market with its ION. That doesn’t appear to be a viable approach, given the poor job the company has done with ION. On the other hand, there’s plenty of time for them to buff up their ION offering as the year wears on. Still, they may try an acquisition in the LEC space themselves.

The next-gen players are caught. The media has made these guys into IP-based competitors to the IXCs, which position has been pretty much a non-starter in a revenue sense. The players must get some dollars flowing soon or risk losing the market’s adulation.

Williams is realistic, seeking to develop bulk deals with big ILEC players like SBC. BellSouth took a stake in Qwest to help duplicate that play. Level 3 is looking to international networking (they plan a terabit cable, for example) to give them a unique market position. We think Williams has the best chance overall, because it’s not saddled with as much retail service baggage. The RBOCs are all interested in broader service footprints, but they don’t want to validate a competitor to get it.

Ironically, there is an opportunity for a small-scale IXC player to create both a business and consumer niche based on IP services and VPNs. The former would require at least access through RBOCs, but they could hope to develop their own CLEC position to cover the VPN space, given the small number of large business sites to address. It’s just that the current new-gen players have been overhyped in a financial positioning sense, and something as limited as this (we estimate the opportunity to be about two-thirds the size of Sprint) just won’t play on Wall Street.

In the ISP space, we think that there’s a dramatic consolidation and change coming. First, it’s clear that even peering agreements and options (again see Strategies) will save the smaller players. We also think that the facility players, particularly the RBOCs, will play a much larger role in the future. Because these guys know how to do interconnect among carriers (and in many cases are obligated to do it), they’ll solve the peering problem in a stroke.

That, of course, will finally spur the Internet community into taking rational action. It may be too late to save the smaller players, but it will keep the major parties in business. In the long run, though, expect all ISPs that survive to either become broad-based facility carriers at least as an adjunct to their Internet offerings, or be acquired by the big facility players.

The current phone network is both a switching network and a service network. We have a loop connection from our phone to a central office, where a large telephone switch (a "Class 5") monitors the state of our phone. When we go "off-hook" it asserts a buzzing noise we call "dial tone". When we push a phone button, it collects the digits we dial, and when we’ve finished it places our calls.

First, the gateway people. Castle Networks was probably the first announced vendor in this space with the concept they called "service mediation" (Castle has now positioned more into the boundary space, but they cover this one as well). Transmedia appears to be targeting this space today, and so do vendors like Ascend/Lucent and Nortel.

The gateway model of voice services is simple. In the future, non-traditional technology will be used to build networks of users—technology like IP/Internet. These new user networks will want voice services among themselves, and more importantly connectivity with the broad public voice network. They will have their own local calling practices and signaling practices/protocols, so when they call outside their community, something will have to mediate or provide a gateway between their non-PSTN network’s practices, and those of the public network. That’s the box the gateway people want to build.

The gateway model’s technology has been influenced primarily by the so-called new-generation carriers, Qwest and Level 3. These guys have an interior or IXC position in the market, so their need is for a way to connect to PSTN networks that provide local exchange telephony services, and offer their customers long-distance voice on IP. For this model of service, the vendors have been induced (driven, perhaps) to a technical model of a service gateway and a gateway controller.

The service gateway is the gadget that sits between the local exchange PSTN network and the IP IXC network (or, for CLECs, between a local exchange VoIP network and the existing IXC PSTN network). The gateway is primarily a conduit for the information flow, providing a facility to translate between the PCM voice coding of the PSTN and a compressed/packetized voice over IP format.

Signaling conversion is also required, between the PSTN SS7 model and an IP model like H.323. This function is of lower importance in a resource sense, however, because a full T3 trunk’s worth of PSTN users only generate three to five calls per second. This fact is handled by offloading the signal conversion to a gateway controller or media controller. This controller talks SS7 and provides the actual gateway with the commands needed to pass calls between the two networks. It communicates with the gateway via a gateway control protocol, such as SGCP or MGCP.

The gateway controller would function as a node or Class 4 switch in the PSTN network, processing SS7 requests on the out-of-band SS7 signaling trunks. The gateway itself would be the information-path connection that handled the interoffice trunks carrying the calls. The Class 4 features that the gateway controller has to support would either be programmed into the controller or extracted from a separate repository of features elsewhere.

Most of the standards activities in the IP telephony space are focusing on this model, even though protocols like MGCP or (more particularly) CGCP have broadened their initial focus to allow for their application in the boundary model as well. IETF activity like the PINT (PSTN-Internet Internetworking—yes we know it’s a sloppy acronym) and international activity like the ETSI TIPHON (Telephone and Internet Protocol Harmonization over Networks—like what else would you harmonize them over) are both targeted at the gateway model. The newly-formed International Softswitch Consortium at least appears to be taking a gateway tack, though it’s only been formally announced for about 2 weeks at time of publication of this piece, and it’s too early to tell for sure.

The benefit of this model is that it relates easily to the business model of new-gen IXCs like Level 3 or to the model that might be adopted by an IP-centric CLEC or an ISP. Because, having raised money from an unwary and semi-educated financial community, those carriers have money to spend on infrastructure. So far, other potential NGV carriers haven’t bellied up to the ticket window for a seat on the NGV bandwagon, so this model has attracted a lot of interest—particularly from the press.

The other model is promulgated by vendors like Salix and Convergent, and others like Castle have expanded their position to envelop it as well. These "boundary people" presume that there will not be a discrete set of voice communities to mediate between. Rather, they assume that a variety of networks connecting users for opportunistic applications (likely to be in the data space) will be pressed into service to offer voice services. Since these networks won’t have any specific voice service features, something will have to be applied to create a voice service. That "boundary layer" is what the boundary people want to sell.

The service model of the boundary people is one of either opportunism or competitive response. In either way, it can be called one of exploiting existing customer relationships and optimizing future ones. It assumes that the early service provider competition will create a bit of niche exploitation, with carriers jumping into new service spaces like the Internet or VPNs to capture new opportunity that dodges the difficult sales resistance incumbent carriers would be likely to mount. These players then either decide to offer voice to garner additional revenue from their customers, or are forced to do so because a full-service competitor offers their customers a multi-service discount.

The technology model of these players is a bit more complex because the goal is to provide not interworking between voice networks, but voice service in a network-independent way. The biggest technical problem is the full set of basic and custom calling features that are normally provided by the big Class 5 switch we talked about. Those features are required by all voice users, and the boundary voice guys have to expect to offer them. The gateway people can assume (rightly or not) that the individual networks between which they are mediating are each providing their users with local voice service features.

The Class 5 requirement has induced the boundary people to envision an architecture that is split between what can be called a service proxy and a service feature repository. The service proxy speaks the signaling language of the service user (DTMF dial, H.323, etc.) and knows the rules for collecting service requests and categorizing them. In voice terms, it’s a call model. The service feature repository knows how to process these service requests, and it acts either to fulfill a service request (Last Number Redial) or make a connection. The boundary people seem to accept that it’s unlikely that they’d want to program the features into their boxes; special calling features aren’t required often enough to justify the cost of storing them at every point where users connect.

The benefit of this approach is its ability to support a range of service missions. An IP-based provider can employ boundary-oriented NGV products to offer primary voice services. This relieves the problems that would exist today in H.323 voice applications owing to a lack of some of the basic service features. Sure they may be provided in H.323 or SIP eventually, but it may take some time. The boundary people can solve the problem quickly.

The problem these players face is the daunting set of features that must be provided. The players in the boundary NGV space have largely fallen back on the concept of "importing" the features from a repository that is a combination of the current AIN/SS7 feature source set, and new-generation feature servers designed to support the VoIP market.

A call process, as we’ve noted, is an interplay between a call model that describes how users signal for calls, and a "feature model" or "service model" that describes how the requests for features are satisfied given the user’s needs and the provider’s policies and network characteristics. The best way to envision this is as three interlinked rule sets—the rules for the calling model, the service model, and the called model. Each, in technical protocol terms, is a state/event model.

The question is how these models get built. A flexible voice network would provide all of the following capabilities:

1. A mechanism to provide each caller with a flexible, extensible, call model to allow introduction of new dial sequences to invoke new features.
2. A mechanism to describe the handling of each service request in generic terms so that feature programming can be made independent of network considerations.
3. A mechanism to map the service logic to the specifics of both the network and the specific calling/called relationship being processed.
4. A mechanism for synchronizing the state of the three models (calling, service, called) in a practical timeframe and without risking ambiguities that could impact call setup or failure recovery.
5. A mechanism to program all of these earlier mechanisms quickly and without significant problems in regression testing.

It seems likely that the solution to this problem will be developed by one of the boundary players, or by a firm who wants to support the boundary model of NGV. The reason is the greater complexity of the boundary model, and the need to make that model even more flexible to provide voice feature creation for service differentiation. Most features of the gateway model are static and invisible to the user, and nearly any model of feature hosting would be suitable if it could sustain the call rates.

The call rate issue is important both in a positive and negative sense. Certainly the processing time associated with fulfilling a feature request cannot be allowed to generate a substantial "delay-after-dial" problem, because research shows that delay-after-dial is a major metric by which users judge voice systems. On the other hand, call handling is a small part of call support—a T3 trunk generates only three to five calls per second for 672 DS0s.

This "yin/yang" combination indicates that the ideal service model approach would have to allow for the hosting of service features in various places, reflecting the performance priority of that particular feature. One might envision a "DNS-like" approach, with the primary NGV feature repository being close to or resident in the NGV edge device or gateway. This first-level feature source would analyze any feature request received and pass requests it could not fill upstream to higher-level sources according to a fixed plan.

OK, what are the service model requirements pointing to? Probably a special call feature modeling language, not unlike the scripting or macro languages in use today. Some vendors (Siemens, in particular) have used special communications languages for literally decades, so the idea isn’t new. The new language might be available in both interpretive and compiled form to facilitate its use at various levels of call handling, reflecting the variation in performance requirements cited earlier.

The real market opportunity for NGV is in the support of voice services with advanced features to promote competitive differentiation, and to support the custom fee-per-use calling services. We have dozens today, and we’ll have more in the future.  But, sorry, this is a topic for our subscribers only!

Infrastructure change for purely technology reasons isn’t sensible in a business sense. Infrastructure change based on the idea that NGV technology would be more bandwidth-conserving is clearly dumb in a world where unit bandwidth cost is declining as fast as any cost in networking. Infrastructure change based on the notion that NGV technology would be cheaper than traditional technology isn’t relevant except for those who don’t have infrastructure already.

The press infatuation with the simple and stupid issue of convergence has, unfortunately, hidden the real issues in NGV from the public and generally reduced the quality of debate on the models and options. Even the web sites of the major NGV players are light on the positioning of their products, to the point where it’s often hard to tell which (if either) of the missions we’ve cited is targeted by the vendor. Hopefully, as the market develops, some hard reviews of technology and direction will correct this. Certainly market development will expose the fact that the real driver of NGV is more revenue, plain and simple.

NGV will be deployed for high-revenue-potential customers who are likely to move beyond analog loop, or who have already done so. It will be based on the need to extract the most revenue from these networking fat-cats, and to control their spending by insuring that you offer them every service and every feature they might desire.

NGV will also provide a foundation for a new view of services in networks. Not only does NGV finally break the link between switches and services that the Bell architecture established so firmly in the late 1970s, it also breaks the link between service providers and features. Once it becomes possible to provide features in a distributed way, it’s inevitable that there will be a new breed of feature vendors distributing their wares over public IP networks or other networks in the future.

There are real issues in this kind of network, not the least being security and stability. How baseline services will be protected from feature programs provided by others is clearly a key concern, particularly when generations of hackers are successfully cracking network applications that don’t permit third-party logic to be inserted and run. Will we have "network virtual machines" which create a virtual operating environment that limits what harm application/feature logic can do? If so, we’d better get on with standardizing it now.

The Internet is held up by many today as a model of future networks, and the inevitable successor to the PSTN. Would we accept a public phone network where the LECs and IXCs refused regulation? Would we accept one where these carriers agreed to interconnect with each other only at a few highly congested public shared portals, but could negotiate private interconnect to favor their own interests? Clearly the business of the Internet isn’t much of a public policy success, by the only fair standards we can judge it—those of the long-standing public telephone network.

Interconnect is the issue that could eventually tear the Internet apart. Like any public network, the Internet is dependent on open communications among its members. Given that the members are spread over a couple of thousand ISPs, this open communications objective can be served only if the ISPs interconnect to permit mutual traffic exchange.

Most people with even passing interest in the Internet structure know that the interconnection was originally provided through Network Access Points and Metropolitan Access (or Area) Exchanges (NAPs and MAEs). Most also know that these shared facilities have become highly congested, and their use often runs traffic through a string of as many as a dozen routers between source and destination. As a result, ISPs began to develop what were called "peering relationships" among themselves, where the ISPs created bilateral portals for traffic exchange.

About six years ago, stung by other ISPs who misused peering, UUNET announced it would no longer peer automatically. Other major ISPs followed suit, and peering is now a major political issue. Without a peering agreement with a major ISP, another ISP could not move traffic to them except though one of the congested "treaty" interconnect points—the NAPs or MAEs.

In a peering agreement, an ISP creates a transport connection to a partner ISP. If the first ISP has a lot of traffic to send users in the second ISP’s domain, most traffic flows from one to two, so to speak. It clogs up the second guy’s infrastructure, and competes with his own users’ traffic. What’s worse, all the money collected for that traffic goes to the first ISP! This truth was quickly exploited by ISPs in the early 1990s, and it was what finally caused UUNET and others to suspend free peering.

So it’s all the fault of these peering hogs? Nope. The bigger ISPs, including UUNET, aren’t really all that wild about doing peering or even doing interconnect. The reason is that a big ISP with a lot of users and a large service geography has a major market advantage over competitors if the connection between ISPs is lousy. Get on the big guy and get good service to all his customers. Get on a little ISP and get crummy MAE-based peering connections to all the big ISP customers. It’s an easy choice; the big get bigger.

In a rational world, one might expect to see peering agreements based on what is actually carried between the networks. One of the options we’ll discuss in a minute provides for that—in theory. In practice, since Internet service isn’t usage priced, there’s been some resistance to having usage-priced peering. It raises a lot of ugly issues, like what happens when your peering partner charges you for transporting his packet and you discard it.

Also in a rational world, this whole problem would be solved in a regulatory heartbeat. Common carriers have to peer. The FCC would certainly be glad to implement Internet peering requirements, but the Internet community has resisted any form of government regulation (a legacy, no doubt, of the hippie heritage of university students in the ‘60s, and thus of most of the Internet founding fathers). No outside influence, they say. We’ll solve our own problems.

Paid transit has its benefits (most obvious of which is getting peering when the partner won’t offer it for nothing), but it also has some of the risks of peering. Most of the transit agreements are necessarily somewhat "soft" in terms of what can be provided. Do you promise to carry x number of packets? Under what conditions? How does a transit carriage service guarantee get enforced in the network when you can’t tell one packet from another?

The problem with any usage/volume metric in paid transport is that it’s hard to decide what the fate of the transiting packets might have been when the time comes to pay the bill. IP networks discard routinely, sometimes massively. Does a paid transport agreement require payment for packets dropped? If not, how does you know they were dropped, and who dropped them? If so, why not charge your partner for transit and then drop all his packets? Resistance to government regulation, after all, can easily translate into resistance to precepts of commercial law.

A more sinister problem with paid transit is that even it may not always be offered. Some ISPs don’t want to sell transit and don’t want to offer peering at all. Some don’t want to peer (paid or unpaid) with ISPs who source a lot more traffic than they sink. There’s also potential problems with who manages the interconnect between the carriers and how traffic there is monitored.

One solution to these problems is the concept of "consortium peering". Mike Gaddis of Savvis (now purchased by Bridge Information Systems) originally proposed a new kind of peering called "brokered private peering". This concept created a kind of exchange point that was run by the partners and open for participation (for a fee, potentially) to all who met basic technical and management requirements.

The concept got financial legs in January of last year with the formation of a corporation with a pool of $20 million contributed by eight mid-sized players, to create peering points in nine locations through the US. The group wants to permit ATM-based zero-loss interconnection, initially for pure connectionless IP and possibly in the future for some form of QoS-specific hand-off, possibly based on mutually agreed DiffServ handling, MPLS, etc.

Unfortunately, it is not necessarily in the interest of the mighty to agree on leveling strategies, and peering certainly lets smaller players achieve a kind of collective competitive mass. Thus, the consortium has had difficulty soliciting cooperation from the largest Internet players. Without interconnection to them, the whole scenario is like Bermuda, Virgin Gorda, and Cayman Islands banding together in a hemisphere defense pact.

A third approach was recently announced by Equinix. Their approach is to create large centers for collective location of multiple ISP facilities, sort of a "shared super-POP" concept. At each location, ISPs would rent space in racks or rooms for servers, modems, and other stuff. ISPs would interconnect here by simply running a wire between their equipment shelves. In effect, interconnect becomes a zero-cost benefit of the shared facility.

Many insiders agree with this concern. Boardwatch, an ISP forum of considerable influence, editorialized "…if competition and a single "Internet" are the missions, I do not at this time see any feasible way to insure those missions short of an FCC moderated peering and exchange policy".

Access the index of CIMI Corporation's recent newsletters.