Network processors let network equipment vendors develop gear that customers easily can upgrade to tap new applications and protocols. However, a lack of hardware interface standards and software APIs has kept vendors from adopting network processor technologies.
The Network Processing Forum (NPF) was launched in 2001 to solve the problem by establishing a common and open set of network processing hardware and software interface specifications, along with a well-defined set of objective performance benchmarks.
Earlier this year, the group released the NPF IPv4 Unicast Forwarding Services API Implementation Agreement. This specification details a set of open, implementation-neutral APIs that control-plane software can use to manage IPv4 forwarding plane functions in network-processing elements.
The forwarding plane forwards packets at line rates. The control plane controls and modies the behavior of forwarding plane components. It processes changes and updates received from network routing protocols such as Open Shortest Path First and Border Gateway Protocol.
Using common APIs lets independent software and network processor vendors develop complete IPv4 forwarding solutions for network processing elements, which are unique combinations of hardware and software. It also simplifies the difficult task manufacturers face in migrating their existing control-plane software to network-processor-based systems.
In the case of a multi-protocol router, control plane elements use an application called a route table manager (RTM) to create and maintain an accurate routing information base (RIB) table that contains all known network-layer connectivity information. An RTM uses an RIB to generate an appropriate subset of mapped IP destination addresses to next hops, routing metrics and other data that is downloaded to the forwarding plane elements using the NPF IPv4 services APIs. The forwarding plane elements store the data in a forwarding information base (FIB) table as described in RFC 1812.
Before the NPF IPv4 Unicast Forwarding Services API was available, the APIs that facilitated communications between control plane elements and forwarding plane elements were proprietary. Silicon manufacturers had to establish relationships with individual network stack vendors to create appropriate interfaces. As the number of network protocols, hardware vendors and software vendors grew, the software libraries needed to maintain these interfaces became costly and unwieldy. The IPv4 Services API Implementation Agreement establishes standard APIs so all these components can interoperate easily.
The NPF IPv4 Unicast Forwarding Service API Implementation Agreement optimizes on a range of network platforms, including everything from enterprise-class switches and routers to carrier-class core IP routers.
This flexibility is enabled by two distinct modes of organizing and manipulating the IPv4 unicast forwarding information stored in FIB tables. The unified mode, or single FIB table implementation, is most appropriate for network designs in which platform memory and cost are critical considerations, such as a departmental router. The discrete mode, or multiple table implementation, supports multiple disaggregated FIB tables, enabling the reduction of processing overhead. This is critical in core router implementations with dense high-end platforms that have hundreds or thousands of interfaces.
The IPv4 Service API Implementation Agreement is the first in a series of APIs to be established by the NPF. APIs for Multi-protocol Lable Switching, Differentiated Services, IPv6 and other network services should follow quickly.
Broad adoption of these services APIs will let network device vendors select the components that best meet their requirements and avoid redesigning their systems when choosing new network processing hardware and software.
Damon is chief software engineer for network processing and Keany is network processing software architect at Intel Corp. Both are software task group chairs of the NPF. They can be reached at damon@fr.ibm.com and bernie.keany@intel.com, respectively.
