Common software architecture to foster NPU ecosystem

However, despite their success, ASICs are not without their drawbacks. First, they are hard to design, taking up to 18 months from conception to deployment. Also, as the name implies, ASICs are designed specifically for single applications and cannot be targeted to multiple applications. In addition, ASICs are not extensible and adding new capabilities requires developing new ASICs.

To solve this problem, network processing units (NPUs) have been developed to address the shortcomings of ASICs by combining line-speed fabric switching architectures with programmable cores.

The programmability of NPUs makes them highly flexible, meaning that network equipment manufacturers can use one device in multiple applications. For example, a networking blade based on the C-5 network processor can be programmed to work as a multiprotocol I/O device or as an asynchronous transfer mode (ATM) switch. Further, equipment manufacturers can add functionality to NPU-based hardware. They can upgrade their ATM switch, for example, by adding different levels of classification or they can upgrade an IP router by adding the ability to offer differentiated service levels.

With the power and flexibility of NPUs, however, there comes a challenge: developing and integrating microcode and control-plane stacks. Unlike ASICs, network processors have to be programmed to be useful. In many cases, equipment manufacturers have to develop microcode to optimize a network processor's forwarding-plane capabilities. Then, that forwarding plane has to be integrated with a control-plane stack, most likely from a third-party vendor.

The programming process gets complicated when building a system that incorporates multiple network processors from different vendors, all of which have different microcode development environments and different control-plane application programming interfaces (APIs).

For example, while it is possible to use a single network processor for multiple functions, it is likely that equipment manufacturers designing multiservice switches would use several different NPUs in order to leverage the relative strengths of each. They might use a Wintegra Winpath as an ATM interface, a C-5 as an ATM switch, an IBM PowerNP as a Packet over SONET interface, and an Intel IXP1250 for an Ethernet interface.

They might even want to use an ASIC as an IP security device. Today, such a project would include four distinctly different NPU development tool chains and four different control-plane interfaces. On top of that, there are likely to be myriad host processors, classification engines, and queue management processors. Perhaps worst of all, once the system is up and running, it may be nearly as hard to upgrade to the hottest new network processor as it would be to upgrade to the next-generation ASIC.

Complexity demands

To address these difficulties, the Network Processing Forum (NPF) has created a working group to develop common APIs. When completed, these APIs will supplement the work NPF is doing in the area of hardware interfaces and will support the NPF goal of fostering the adoption of network processing technology by creating an environment where system vendors can rapidly integrate network processing elements, protocol stacks and applications to deliver solutions to customers.

Traditionally, protocol software is separated into three different layers or planes. The forwarding plane receives, processes and forwards packet data. The control plane responds to changes in the network by updating routing tables, for example. The control plane also manages resources within the forwarding plane, making sure traffic is properly balanced between multiple ports.

Meanwhile, the management plane interfaces with both the control and forwarding plane. It provides high-level network management interfaces such as command line interfaces or simple network management protocol (SNMP) interfaces and also supports the monitoring and reporting of activity within the forwarding plane.

In its Common Programming Interface (CPIX) architecture, the NPF is blending these three standard protocol planes into three distinct APIs: the Services APIs, the Functional APIs and the Operational APIs.

The Services APIs will allow software stacks to control service-specific functionality while hiding the details of the system architecture. This creates a 'black box' scenario in which system vendors can take standard protocol stacks and integrate them without needing to be concerned with the details of the network processing subsytem.

For example, a DiffServ Service API would allow an application to set up the various DiffServ resources (classifiers, traffic manager) without understanding the system architecture or the elements of that architecture. Similarly, a multiprotocol label switching (MPLS) Services API would provide interfaces for controlling the label switching of packets. Other examples of Services APIs being considered by the NPF include IP version 4, IP version 6 and an Access Control List API.

The Functional API model is similar to the Internet Engineering Task Force's (IETF's) Forwarding and Control Element Separation (ForCES) model. This model allows the system developer to see more deeply into the details of the system while hiding the vendor-specific details of individual NPUs. Through these APIs, developers are able to map the functionality provided by the high-level Services APIs to specific forwarding-plane devices. Thus, developers are able to implement functions such as traffic management and classification rules at the device level.

Essentially, there are four different layers: an application layer, a system abstraction layer, an element abstraction layer, and an interconnect layer that hides the vendor-specific details of the individual network processors. Both management and control planes are contained within the different abstraction layers.

Applications, such as MPLS stacks, and control plane interfaces sit on top of a system abstraction layer which includes the NPF Services APIs. The Services APIs, then sit on top of the Functional APIs in the Element Abstraction Layer. An application written to the services APIs would not need to have any understanding of the underlying architecture, and indeed could be easily moved to a different architecture as long as the new architecture, also, complies to the Services APIs.

Alternately, it is possible for application and stack developers to bypass the System Abstraction Layer by developing their own hooks directly into the Functional APIs. In this case, they get a deeper view into the architecture and are able to map functionality to specific network processing elements. In either case, end customers and system developers benefit by being able to use existing applications and off-the-shelf software stacks on new platforms. Similarly, software vendors are all able to leverage their stacks over multiple architectures.

By taking advantage of the ForCES interface, network processor vendors are able to make their devices compliant to the Functional APIs which then make their latest devices available to the entire ecosystem of software and existing applications.

Beside the top three layers, a set of Operational APIs provide control and management functions--such as address management, counter and statistical management, and packet handling between applications-that span the service and functional abstraction layers.

These APIs are still in the early stages of development and are not ready for actual technical implementation. They do, however, offer an attractive roadmap to a network processing ecosystem in which:

-System developers benefit from the ability to integrate different network processors and to get to market more quickly,

-Software vendors benefit from the ability to sell their protocol stacks on multiple hardware architectures, and

-Network processor vendors benefit from the ability to leverage the various commercially available software stacks, as well as gaining a better ability to introduce hot new products into existing system architectures.

Customers of all three vendor classes benefit from a useful set of hardware and software solutions that help unlock the value proposition of NPUs: a flexible, programmable architecture that provides an attractive alternative to hardware-only ASIC designs.