Telecom equipment makers must build on Linux to remain viable

Why build next-generation communication systems on Linux? The current woes of Telecommunications Equipment Manufacturers (TEMs) and Network Equipment Manufacturers (NEPs) have been described as a "perfect storm" with no signs of abating. Slow demand growth and the accompanying glut in carrier bandwidth and goods-in-channel, conspire to depress communications markets ecosystems, with repercussions upstream for technology providers. For the past year, the storm has swamped traditional suppliers and has created an opening for Open Source and Linux.

While, TEMs and NEPs look to Linux initially to cut top line deve lopment and deployment costs, but they end up realizing a series of benefits from the shelter that Open Source and Linux provide: compatibility with existing/legacy investments in UNIX-based middleware and applications; rich and integrated IP networking for current datacommunication and nascent IP voice requirements; and support for general-purpose and specialized blade processors and legacy line-card CPUs.

Not only are troubled U.S. and European manufacturers turning to Linux to remain viable but traditional and emerging suppliers in developing markets, such as China, Korea, and Brazil, are building both direct legacy replacement and new designs on Linux for the same reasons.

Architecture SupportLinux is gaining design wins both in telecommunications and data communications at the same time that several trends are changing the structure of communications systems. Even before the current slowdown, TEMs and NEPs had begun moving away from specialized, vertically integrated architectures to COTS-based (Commercial Off-the-Shelf) approaches, to reduce design costs and accelerate product cycles. In most marketplaces, movement away from circuit switching to digital voice technology bolstered this trend — more generic hardware handling pure IP streams, with specialized front-end hardware pushing last-mile applications into premises and POP racks.

With this "IP-ification" of voice and the movement of data access further from the Central Office, what once was "heavy iron" begins to look more like specialized enterprise server farms — where Linux is traditionally most at home. Out at the edge of the 'Net, on client networking devices, and in handsets, Linux is now accompanying the introduction of IP-based voice and ubiquitous data.

In this overhaul of voice and data networks, Linux is also able to track specific CPU architecture migration trends. For example, in prior generation systems the typical line card (E1/T1) boasted a 16/32-bit dedicated CPU, like the Motorola QUICC (683xx) with minimal ROM and RAM — a prototypical RTOS application. In the last five years, that same node moved up to PowerQUICC (8xx) and more recently PowerQUICC II (82xx) or equivalent processors, gaining capacity/bandwidth through faster cores and higher integration. This ascent to full compute-peer CPUs, armed with abundant RAM, ROM, Ethernet, and MMU-equipped processors, and the descent of data plane operations into specialized communications engines and network processors, meant that the lowly line card could now run a "real" operating system (OS) like Linux, with bandwidth to spare for complex control and management tasks.

The overall transition is dramatic. Many Central Office applications now run on Linux-based IA-32 servers, made robust and highly available with "carrier-grade" Linux implementations. Front-end, access, and client devices are now as likely to build on IBM 4xx PowerPC, Intel IXP, and various MIPS processors.

Network client devices and enterprise routers, switches, gateways and access points have evolved similarly in the same period. Once dominated by custom ASICs, highly proprietary 16-bit processors, and low-end MIPS designs, they are now as likely to boast the very same high-integration COTS CPUs. Linux, for its part, is successfully ousting proprietary embedded OSes from these voice and data nodes, and now offers CPU coverage that equals and surpasses traditional RTOSes in breadth and depth. In handsets, the action revolves around ARM CPUs.

More backing

Convergence among voice and data is creating a new vs. old split in protocols. To support existing infrastructure, Linux-based communications designs need traditional protocol support — SS7, ISDN and ATM while newer pure IP designs demand requisite VoIP support.

Finding support for protocol stacks and underlying drivers presents some unique challenges to developers leveraging Linux as well as for embedded Linux platform vendors that market to and support those developers. While developers may choose embedded Linux for its strong core IP networking, they often must look to independent Open Source projects or to proprietary ISVs for specialized protocols. Even when the Linux kernel includes native support, they may need an ISV for comprehensive, standards-compliant stackware.

A good example lies in the Open Source implementation of the ATM family of protocols. While relatively few new designs get built on ATM, Linux is winning new spins of legacy designs using ATM fabric, as with use of key ATM-family protocols, such as LANE or AAL in broadband access. As it turns out, developers can leverage Linux kernel support for an interesting subset of ATM, including raw ATM ("AAL0"), AAL5, IPoATM (NULL/SNAP), ATMARP (RFC1577), Arequipa (Application REQuested IP over ATM), LAN Emulation, LANE 2, and ANS.

Even if a subset of a given protocol family is sufficient, device OEMs may still need to turn to ISVs — such as Hughes Softwa re, IPinfusion, Intoto, NextHop and Trillium — since Linux vendors don't necessarily support every feature of the Linux kernel, and to specialized hardware vendors (like Interphase) for NICs and device drivers.

Communications systems developers, like other embedded designers, crave both raw network throughput and deterministic response to events. Embedded Linux offers both, but delivers performance differently than legacy RTOS products.

Linux networking is often cited as a "gold standard," in that the OS offers comprehensive core IP networking and high throughput. As with any OS, Linux networking delivers on this promise best for its most mature implementations (such as IA-32, PowerPC, and MIPS) with stable, optimized network device drivers.

The other area of concern to developers is real-time responsiveness. While market studies reveal that at least 90% of respondents are satisfied with Linux real-time performance, many applications in networking and elsewhere still need cert ain response guarantees. While Linux makes no pretense of delivering RTOS-like determinism, its performance is impressive for a General-Purpose OS (GPOS).

Line cards and various client devices of old featured 16/32 bit processors that either carried limited EPROM resources on-board or used network fabric and backplane resources to boot and run from remote code images. For on-board storage, code images were limited to scarce ROM and available address spaces on 68K, 80C186, and other classic line-card CPUs. Leveraging more plentiful remote stores, like hard drives on shelf/system controllers, solved the space issue but presented bottlenecks when racks of hundreds or thousands of line cards needed to boot at the same time.

Today's better-provisioned line cards and blades, based on 32/64 bit CPUs, leverage more massive on-board stores and faster fabric-based network boot options. Resource-rich Linux presents memory footprints several times larger than legacy RTOS kernels, but offers far grea ter functionality in that footprint.

Proponents across the embedded space cite the inherent synergy among embedded, desktop and server versions of Linux as proof positive that Linux will continue to build on its impressive gains in embedded networking. Linux upgrades embedded devices from the status of "poor relations" to full peers of enterprise systems, and assures the rapid migration of new technologies from desktop and server into embedded and vice versa.

TEMs, NEPs, and the carriers they support seek to emphasize their own value-add and simplify their infrastructure expenditures by building on a single common platform. While Microsoft promotes the same end-to-end vision, only Linux has been able to deliver simultaneously on servers and embedded devices, while cutting the training and design and deployment costs of formerly divergent efforts.

Even as this troubled telecommunications sector continues to downsize, it is also optimizing, most visibly by building to deliver its ne xt generation products on Linux and Open Source.

See related chart

See related chart

See related chart