Modules ease programming task

Although the new generation of software-programmable network processors offers both flexibility and performance, its programming is quite involved. Add to that the variations in vendor architectures and programming tools, and you are soon facing a significant learning curve.

This situation is complicated by multiboard system architectures where the control-plane and data-plane functions run on separate cards. So the Network Processing Forum (NPF) and the Internet Engineering Task Force Forwarding and Control Element Separation Working Group (IETF ForCES) are working to define a modular architecture and work on the specific modules that implement the functions.

The classical planar networking architectural model specifies three planes: control, forwarding and management. The control-plane software typically runs on a general-purpose processor and is used to set up tables and modify the behavior of the forwarding plane, which usually runs in microcode and is responsible for high-performance forwarding of packets. The management plane includes software executing on the general-purpose processor and counters on the hardware and microcode. One example of a control-plane function is the Open Shortest Path First (OSPF) Protocol routing-protocol software on a router. IPv4 forwarding based on the tables built up by the OSPF protocol is an example of a forwarding-plane function, while an SNMP agent is an example of a management-plane function.

The NPF architecture focuses only on the control and forwarding planes (the latter is also known as the data plane). Based on the number of network processors performing packet processing and forwarding, there will be multiple forwarding planes in the system. For example, each port may have its own dedicated network processor to perform fast packet processing. Alternatively, one may be used to handle multiple ports. To simplify the software architecture, the NPF software model specifies two functional layers of abstraction: a system abstraction layer (SAL) and an element abstraction layer (EAL).

The SAL hides the implementation of multiple forwarding planes (if there are multiple network processors) by presenting the view of a unified forwarding plane to the higher-layer applications. This implies that the applications above the SAL will have only a "system" view.

Why is this important? For example, routing protocols like OSPF are not aware of multiple forwarding entities. They view the forwarding function as a single entity with access to multiple physical ports and build a routing table based on this assumption.

A lower-layer translation function will need to map this routing table view to the multiple forwarding-plane implementation. The SAL presents a set of application programming interfaces (APIs), known as the services APIs, for use by applications like routing protocol stacks. The services APIs include IPv4, multiprotocol label switching (MPLS) and DiffServ APIs. A separate task group in the NPF Software Working Group is specifying the IPv4 services APIs.

The EAL is aware of the existence of multiple forwarding planes (network processors), but abstracts the actual implementation of each network processor via an API known as the functional API. This API is element-aware, so the caller knows which network processor is being addressed.

The functional API abstraction, while providing the "element" view, is very useful for an application to be ported across multiple network processors without having to worry about the actual implementation. For example, a classification and prioritization application can just specify the rules for classification via this API and have the actual implementation be realized differently on individual network processors.

This leads to the question: How do we abstract the functionality of a network processor? The NPF defines logical functional blocks (LFBs) that are used to represent the functionality and ordering of packet processing in the forwarding plane. Each LFB constitutes a stage in a sequence-the stages and sequence are totally logical and not tied to actual hardware implementations. These can include functions like classification, quality-of-service, queuing and so on. The functional API is being specified by the Functional API Task Group in the NPF Software Working Group.

Why do we require this two level abstraction? It is important that the higher-level applications like protocol stacks view the packet processing as a black box implementation so that they can be independent of the hardware and system architecture. The services API is designed to fit this requirement.

The functional API abstracts the network processor's hardware-specific details to ensure that future changes in the hardware for performance reasons will have no impact on the application as long as the API is maintained. The abstraction avoids maintaining multiple proprietary code modules, one for each network processor.

The NPF also defines other APIs required for the functioning of the system; these are known as operational APIs. Included are APIs for interface management (creation, deletion and configuration), which have been specified by the Interfaces Task Group in NPF SWG.

Packet interchange between the control and forwarding planes is handled via the packet handler API. This API is responsible for receiving and transmitting packets between the control and forwarding planes. These packets may be packets addressed to the router, say, routing protocol or management packets.

Each packet passed between the control and data planes will include metadata that describes the type of information in the packet. The packet handler API is being specified by a separate task group in the NPF.

In this architecture, the caller of an API is known as the "application" and the realization of the API function is known as the "implementation." For example, the application for the services API is a routing protocol stack like RIP/OSPF while for a functional API, like Classification, an IPv4 services API implementation is the application (that is the caller of the functional API).

Consider a single-board router with a general-purpose processor and a single network processor used for forwarding among multiple Ethernet ports. In this case, the application and the API implementation will run on the same CPU (the general-purpose processor). Consider the services API for IPv4, used to populate a forwarding table. The routing protocol or routing table manager will be the caller of this API.

The API implementation will map this as an entry to be added to the forwarding table for one or more network processors that are part of the system. This may involve making calls to the functional API for the relevant LFBs that need to be configured for this routing table entry. Thus, for the functional API, the IPv4 services API implementation acts as an application. The functional API implementation, which is network processor-specific, configures the network processors.

Routing software and other application vendors will modify their code to use the NPF services APIs for IPv4, IPv6 and so on. Network processor vendors will provide implementations of these APIs for the specific services they support, and also provide functional APIs to the LFBs that the higher layers can use.

The Benchmarking Working Group in the NPF helps to define the performance benchmarks at the task, application and system levels for network processors. The performance benchmarks are defined in relation to the services, functional and operation NPF APIs. For example, the "Specification for IPv4 Forwarding Application Level Benchmark" is associated with the IPv4 unicast forwarding API defined by the NPF SW Working Group.

A popular implementation of a network-processor-based system is a control card plus multiple line card system, where the control card consists of the general-purpose processor running control-plane software and the line cards consist of network processors. The line cards may also have a general-purpose processor to perform specific data-plane functions and communicate with the control card. In this scenario, the API and implementation are still part of the control card general-purpose processor as in the single-board case.

See related chart