As processing power and memory become less expensive, many silicon vendors are offering so-called all-in-one products that give their customers 80 percent of a switch or router's functionality right off the shelf. The trend, referred to as OEM-in-a-box, allows OEMs to build better products by focusing only on the 20 percent of the features that add proprietary value.

A major challenge to these vendors, however, is providing network access to, and control of, their systems.

Vendors view access and control, particularly Web-based management, as a new burden on the network equipment's processor and real-time operating system (RTOS). But the truth is quite the opposite. An intelligent software backplane in the network device can be used to implement the new features without any additional burden on the processor or RTOS, and it can effectively future-proof the device by providing forward compatibility with emerging access and control technologies.

Access and control for network devices has traditionally taken the form of Simple Network Management Protocol (SNMP) and command-line interfaces such as Telnet. Those protocols are now mandatory check-box items for network equipment.

Today there is a new one: Web-based management via HTML pages. Many network OEMs are also beginning to use Java applets for management control, and some are even employing the XML markup language. New service-centered technologies, such as Sun's Jini, impose further complications on embedded systems.

For device developers, having so many different access and control interfaces begins to look like a major maintenance headache. For vendors of all-in-one chip sets that have to provide those features for their OEM customers, it can look like a complicated, expensive embedded software mess lacking tremendous payback. There are three primary reasons: maintaining multiple code lines; creating protocol interfaces, and allowing interfaces run-time access to embedded data and functions.

The first problem is that most embedded network systems contain not only an SNMP agent but also a Telnet server as well as embedded Web servers and Java applets. Tomorrow's requirement is likely to be XML. But the traditional method of providing those management and control interfaces results in a different embedded software code line for each protocol supported.

Developing and maintaining an embedded code line for each of the interfaces quickly becomes a large investment. In addition, developers have likely spent hundreds of hours on their existing SNMP systems and can't afford to recode all that for the new protocols.

To further complicate matters, many of the protocol libraries come from different suppliers, creating a ripple effect: By changing one of these control layers, the engineer may break other components. Tying all of the functions to a single intelligent backplane avoids the problem.

A second problem, however, is that each of the supported access and control protocols requires the creation of an actual interface. Whether the interface is in the form of ASCII tables, SNMP management information bases, HTML pages, Java applets, metadata definitions for a process or policy application or something else, embedding the protocol support is all but useless without creating an interface for it.

Designing an interface is fundamentally an iterative process. Although an initial interface is often good enough, rarely is it right the first time. System developers must be able to update all the interfaces easily after the 1.0 version.

A twist on the problem plagues developers of OEM-in-a-box systems. Because they sell a large set of functionality to their OEM customers, they must allow for customization of the interfaces. Without that capability, OEMs have little leeway for product differentiation.

The third major concern is exposing the embedded functions and data of the chip set to the various protocol interfaces in a consistent and reliable way. Additionally, new functions added by OEM customers also must be exposed in the same manner.

An inexperienced engineer's first thought might be to code function calls right into the interface, such as putting C code into an HTML stream or using printf to put out HTML code. What could be more straightforward? The machine gets a request for information and provides the information in the proper format and style.

Although that approach is certainly straightforward for initial implementation, it carries downstream burdens that are not exposed until the engineer has to produce a version 1.1 or 2.0. Because the function calls are hard-coded for linking at compile time, whenever a change is made either to the external presentation or to the internal data structures the engineer will have to deal with the ripple effect.

Software backplane

More efficient is to use a software backplane to link function calls to data at run time instead of at compile time. That allows development and testing of the embedded code to occur in parallel to development and testing of the external interface. Once the entry-point mapping has been defined for run-time reconciliation-like defining and freezing an object-oriented API set-the developer does not have to revisit the code to accommodate minor changes.

Vendors of OEM-in-a-box products have customers that rely on predictable access to the embedded data. Without a software backplane providing run-time linking to the embedded data, the vendor must provide entirely new versions of its products for even minor patches.

The embedded software backplane essentially provides a data dictionary of manageable and configurable elements within the device, providing key benefits to the system developer.

As the network environment gets more heterogeneous and requires more granular and more complete access and control solutions, OEM-in-a-box products will get significantly more complex, offering new options. System designers need to look to the future and understand that design is no longer a one-shot process but rather a multistep life cycle with new requirements. A software backplane empowers the design process and can make a big difference in whether the product grows into a successful platform or becomes a commodity component.