he debate rages on in the International Softswitch Consortium (www.softswitch.org) over the definition of a soft switch. It parallels the one generated by a much quoted 1998 article arguing that it is time for a paradigm shift away from the intelligent network model developed by the telephone companies toward a "stupid network" model enabled by the Internet and embodied in it.

In the article, the cover story in the Association for Computing Machinery’s Networker, "Rise of the Stupid Network," (www.rageboy.com/stupidnet.html) David S. Isenberg maintained that "stupid" is better because the proliferation of powerful end-user devices and abundant bandwidth eliminates the need for intelligence in the network. Also, he wrote, it would allow new features and services limited only by the imagination, since any third party developer with a C++ or Java tool kit can develop for the intelligent endpoints such as PCs, handheld devices and programmable phones.

The sides in the soft-switch dust-up split along the same lines as those in the intelligent vs. stupid dispute.

Most see the soft switch as an open platform version of the hard switch developed over the last 25 years by the traditional telecom vendors such as Ericsson, Lucent, Nortel and Siemens-as the name implies. The main reason for the soft-switch movement was to end the dependence on the legacy hardware vendors and leverage Moore’s Law in its application to the soft-switch processing power. In addition, the soft switch promised open APIs by leveraging standard languages and tool kits, such as C++ and Java.

In the other camp, several strident advocates of the Session Initiation Protocol (SIP) define a soft switch as simply software that’s used to control a communications network. By that definition, a SIP proxy server fits the bill. The same individuals reject the notion that next-generation equipment must first duplicate the PSTN before it can begin to provide enhanced services not possible in the PSTN. When deployed correctly a SIP-based network conforms to the stupid network paradigm.

There are several issues that "smart" soft switch implementers have to take into account. In particular, because of the expectation that soft switches must replace Class 4 and Class 5 switches and need to provide feature equivalency, there is a huge burden to develop those features. Legacy switch vendors routinely advertise 1,500 to 2,000 features in their switches, developed over 20 to 25 years; next-generation suppliers probably do not have a hope of duplicating every one of them. However, in practice, only the top 20 to 30 are really required by the network operators because there are many legacy features that don’t sell. Instead, we expect that the problem of 99.999 percent reliability will be a much harder one to solve for next-generation suppliers of carrier grade equipment. In particular, the network operators are used to demanding "five-nines" reliability from their vendors because they have to report network outages to the FCC and fines result. The following sections examine some of the obstacles to guaranteed five-nines.

To reach that level of reliability, the soft-switch complex must be designed so that there is no single point of failure. That is, there must be no hardware or software component of the system whose failure could cause the soft switch to become unavailable. Instead, every component must be redundant so that failures are accounted for using either a backup or spare capacity. At the basic level, this suggests that the computing elements that make up the soft switch must be redundant. When two or more computing elements are deployed to form a soft switch, clustering must be applied to make the computing elements look like a single logical entity to the rest of the network.

One of the features of clustering is IP interface multihoming, which allows each computing element to take over its partner’s IP addresses in the case of failures. In addition, within each computing element, it is desirable to deploy redundant Ethernet interfaces. This means that connectivity is maintained in case of upstream failures, such as Internet Protocol switching failures, or even someone removing an Ethernet cable. Next, the IP switching or routing gear must be considered. Again, it is desirable that the soft switch has redundant paths into the IP network.

In addition, when the soft switch provides on-board Signaling System No. 7 (SS7) connectivity, the same principle of multihoming must be applied. This likely involves distributing SS7 connectivity between the redundant computing elements and ensuring that the soft switch appears as a single switching point to the SS7 network. This introduces several complex problems, since the SS7 network will load share traffic across the available links, resulting in the need for the soft-switch computing elements to operate in an active-active mode.

The addition of external redundant shared disks completes the picture. To allow each soft-switch computing element to share configuration data and to allow each to write call-detail-record files, each computing element must be able to access its partner’s data.

Several choices are available in redundancy configurations of the soft-switch computing elements. In the simplest case, hardware fault-tolerant platforms can be utilized. In such a system, every component is duplicated and the standby half operates in lock step with the active half. There are several problems with this approach, not the least of which is the added cost. In addition, a software error is likely to be repeated on the standby half because the systems operate in lock step so are not software fault tolerant.

Computing elements can be deployed in an active/cold standby configuration. In this case, a failure of the active computing element causes the standby to become the active, but no calls are preserved because no account has been made to checkpoint application data to the standby. An advance over this configuration is an active/hot standby mode. Here, application data is checkpointed to the standby node so that the standby is primed to take over in case of a failure. To limit the amount of data to be checkpointed, most systems only save stable call data, making them able to preserve stable calls only. Calls in the setup phase are lost upon failures.

Once a hot standby capability has been provided, the next step is to enhance the redundancy scheme to provide an active/active mode. In this case, each computing element operates in active mode, with a load-sharing implementation to distribute traffic among the nodes. In addition, each computing element acts as the hot standby for its partner so that it is able to take over in the case of a failure. There are several advantages to this mode. The service provider is able to fully utilize the hardware it has purchased. It can choose to fully load all computing elements so that during failures the soft switch cannot handle the full load, or it can load the system so that the full load can be handled during failure.

Discussion of the active/hot standby and active/active modes of redundancy leads to the issue of application data checkpointing. In order to keep the standby hot, per-call application data, such as call state information, billing data and resource usage information, must be duplicated to the standby at regular intervals during the call. In its simplest form, this involves making a copy of data in memory and packing it into a message which is then transmitted across an interconnect between computing elements. At the other side, the message is unpacked and the data saved into memory.

This can be handled with off-the-shelf third party middleware currently being marketed by several vendors, or it can be developed in-house.

In order to provide five-nines reliability, it is also necessary to provide for a rolling upgrade strategy. With an active/active mode of redundancy, rolling upgrades are accommodated with little additional development. Their need is indicated because service providers are accountable for all service outages, even planned ones. So to take advantage of new software releases, the service provider requires that the upgrade not affect service.

In principle, rolling upgrades work as follows: During the maintenance window (in the early morning), one computing element is taken off line. All existing calls and any new calls migrate to the remaining in-service node or nodes. The off-line computing element is then upgraded with the new software and brought back online. Calls then migrate back to that computing element. The procedure is repeated for each remaining computing element. At any time, if problems with the new software are detected, the system is able to fall back to the previous version.

Stupid soft switches based on Session Initiation Protocol (SIP) proxy servers do not have the same types of problems as smart soft switches. Since SIP proxy servers can be implemented in a call-stateless manner, the problems of redundancy and fault tolerance are easier to solve. In particular, fault tolerance can be addressed using redundant server farms. Since no call state is maintained, there is no need for application data check-pointing.

However, there are different concerns that must be dealt with by proponents of SIP-controlled networks.

When endpoints are intelligent and the network is dumb, what is to prevent users from making voice calls directly to each other without using the SIP proxies in the network? If the network does not know about the call, how does the network provider bill it?

Just as the traditional music companies don’t like the peer-to-peer method of music distribution via Napster and Gnutella because they don’t receive any revenue from it, the traditional telephone companies do not like the stupid network call model.

To resolve this, a basic paradigm shift is required from the traditional phone companies. Instead of billing on a per-call basis, the network provider must be able to bill for the network bandwidth usage. Much work has been done in the PacketCable project (http://www.packetcable.com) to address the matter of billing. The result is that PacketCable introduces Quality of Service (QoS) mechanisms to differentiate between peer-to-peer calling and a network-provider-controlled call setup. The former provides voice conversations with best-effort packet delivery only, whereas the latter provides guaranteed voice QoS, comparable with the PSTN. The assumption is that customers are willing to pay a premium for voice quality.

A problem similar to billing is wiretapping. In a carrier environment the Communications Assistance for Law Enforcement Act (CALEA) requires that a service provider be able to support requests from law enforcement agencies to place wiretaps on suspects. The question here is that if users can make voice calls directly between each other without using the service provider’s SIP Proxy, then how can the service provider know when a suspect under surveillance needs to be wiretapped? This problem is already harder to solve than in a time-division-multiplexed (TDM) environment since for packet telephony users, the taps must be made at the IP edge router closest to the surveillance target. The CALEA collection function must then provide a packet interface in addition to the TDM interfaces normally supported for Class 5 switches.

Where a surveillance target can make direct peer-to-peer calls without involving the network provider’s SIP proxies, the network cannot make the requests to the edge router to enable and disable the packet bicasts to the collection function for the length of the call. Instead, the only alternative is for the edge router to permanently bicast all packets to the collection function for as long as the wiretap order is in effect.

The only other way forward is for the packet telephony operators to be granted a permanent exemption from CALEA, which we feel is extremely unlikely.

Next-generation voice networks based on the stupid network principle may be easier to build, provide better resiliency and scale better than those built on the intelligent network model. However, the paradigm shifts required to enable the stupid network version may be too much of a leap for the incumbent local-exchange carriers, or ILECs.

For these reasons, we expect the intelligent network version of the soft-switch-controlled network to be deployed first, while the SIP-based network will see deployment in the enterprise.