Designing for multiservice nets

Despite the bloodbath going on at the 10/100-Gbit/second network core, players at the edge and enterprise have continued to build, albeit at a much slower pace and on a smaller scale. Their budgets are drastically reduced and their focus is no longer time-to-market but "cost-to-market." But even though saving money and using resources efficiently are now the name of the game, there are plenty of opportunities for embedded developers that still want to play.

At the core of a network are large, fast optical pipes in a fixed architecture based on a small number of protocols, predominantly Sonet. The primary purpose of a core network device is to move network traffic fast without getting in the way. And since many of the once-centralized services and features have migrated out to the edge, the range of I/O interfaces implemented is generally limited to a small number of high-speed optical lines.

It is far different at the network's edge. Here resides a wide array of access technologies, ranging from T1/E1and DS3/E3 copper networks to wireless standards such as 2.5- and third-generation technologies, among others. There is also a mixture of protocols such as frame relay, ATM and Ethernet.

Service providers have learned the hard way that it is very difficult to make money from simple access networks, so now they're offering a range of services that include firewalls, virtual private networks, bandwidth-on-demand and virus protection for data networks. Traditional voice services, such as voice mail, call waiting and caller ID, have also moved to the edge of the network.

Expanding infrastructure

The result is a new "multiservice" network edge that requires scalable network devices supporting a wide range of interfaces, features and services. In turn, communications equipment developers need embedded-system developers to provide the building blocks that can address their broad needs quickly and cost-effectively. The successful embedded-systems developer must have strong technologists, engineers and product specialists focusing on the three required building blocks of any basic computing system: CPU, I/O and systems infrastructure.

Today's CPU products must incorporate communications technology into the core design. Embedded-systems developers need to offer two classes of CPUs: generic models often based on an X86 or PowerPC, and processors tailored for I/O applications and packet processing, including network processors and similar devices.

The generic CPU must manage network devices that provide the ability to host system-wide functions such as op erations, administration, maintenance and provisioning-all the activities involved in administering and taking care of a network, device or switch security and monitoring. This type of CPU product provides high-end processors (predominantly X86 and PowerPC) with memory and storage devices that are flexible enough to interface to a data bus, such as PCI, and to a packet-switched architecture, such as the PICMG 2.16 standard. The operating system is usually a non-real-time embedded OS, such as Linux.

The second CPU product class, aimed at I/O and packet processing, features network processors or PowerPC processors connected to an internal architecture that is highly optimized for the job of moving packets. These CPU products run real-time operating systems such as VxWorks and embedded Linux and must be capable of supporting a wide array of I/O interfaces.

Both CPU classes are available in various form factors, though communications equipment developers prefer CompactPCI, PCI Mezzanine Card (PMC) or a mixture of both.

The I/O challenge is significant. Not only must the embedded-systems developer provide a large range of I/O interfaces running from Ethernet and T1/E1 to DS-3 and OC-x, it must also provide the protocols that run on them, and obtain and maintain the various regulatory compliance and certifications. Embedded-systems developers must keep up with emerging trends in network architecture. But most important, the I/O products must be scalable, allowing the network equipment developer to integrate a wide range of interfaces or to migrate to new, emerging I/O technologies with little additional development and integration effort.

Building blocks

To accomplish all of this, embedded-systems developers need to streamline their I/O product lines into product families that use common hardware and software architectures. This allows them to offer a broad range of products in various form factors and enables them to develop and maintain the drivers and protocols that are required. The simplified, modular approach reduces development time and effort for communications equipment developers while giving them the flexibility and scalability they demand.

The business models of many communications equipment developers have been steadily changing. Over time they have evolved from hardware/software/system integration houses to primarily software developers. In the current environment, where companies are outsourcing more frequently using communications devices based on open-architecture embedded products, software is the ultimate differentiator, the valued intellectual property, the so-called secret sauce.

Communications equipment developers need the basic building blocks-chassis, backplanes, power supplies and thermal management. But they also need embedded developers to integrate CPUs and I/O hardware with the relevant drivers and other "glue" software.

Embedded-systems developers can easily offer this valuable service if they have the right products and expertise for the communications space. Systems need to be able to support high-availability standards, and many must be designed to meet Network Equipment Building Systems shake-and-vibration specifications, standards from Telcordia for equipment used in telco central offices. All of the required components must be tested for interoperability, allowing the embedded-systems developer to guarantee they will work together.

The multitude of network devices, systems and services at the network's edge often drives the need for custom or tailor-made products. This may sound like an insurmountable task, but it can be done-and efficiently and cost-effectively. The secret lies in a modular approach for embedded-systems design. Hardware and software products can be designed in layers, with each successive layer employing a common or standard interface to its partner layer.

This is by no means a new concept. However, many developers do not employ this approach efficiently. Instead, most focus on a single area of expertise, providing one or two of the three required building blocks. The communications equipment developer may need to incorporate building blocks from multiple vendors and therefore may not get the full advantage of a modular architecture.

Customizing platforms

Automakers have employed a similar, successful modular approach described as mass customization. It enables an automaker to offer and maintain a broad range of vehicles-all using common parts and platforms. Embedded-systems developers can use this approach to develop a range of products and combine them into customized products for their individual customers.

Consider the case of a network blade. Described simply, the blade functions as a "trunking" interface. It must connect to multiple T1/E1 lines, handle voice and data, host a range of protocols and management interfaces (such as SNMP) and run the secret-sauce software or intellectual property that the network equipment developer designed. This is a classic blending of computing and I/O.

Such a product could be developed from scratch, laying down the T1/E1 circuitry, Ethernet for a packet-switched backplane, embedded processor and serial ports for management, as well as writing the software to pull all of this together. This could take a developer six to 12 months depending on the technical details.

A more efficient approach is to design a range of modular CPU and I/O products. The hardware could be built using existing CPU blades and hosting the I/O board on a mezzanine card such as PMC. It could be built using an existing I/O blade, hosting the processor in a mezzanine slot, such as a Processor PMC. Software building blocks might include those for T1/E1 line maintenance, SNMP modules and the all-important application programming interface. This could all be done in a few months.

See related chart