Meeting the need for flexible network services

Capabilities, however, have been generally limited by hardware-based implementations to simple forwarding based on various routing parameters either updated manually by management systems, or dynamically by route discovery protocols. Each packet was inspected and routed to the physical interface serving the next station.

Demands for network services, are growing. Vendors are expected to offer multiple services across the same core network. These include: guaranteed bandwidth services for voice and video streaming; private secure networks for use as corporate intranets; best effort data services for consumer internet access; and flexible, on-demand provisioning for data services.

More and more, customers are also demanding service level agreements (SLA) guaranteeing quality of service (QoS). Implementations need to be flexible to allow for the addition of new services, and must cope with the evolving landscape of the existing network where new standards such as multiprotocol label switching (MPLS) and IP version 6 (IPv6) are being introduced.

The network processor device was created to address the inflexibility of the hardware-based implementations. The software-based approach facilitates updating as standards change, and allows more comprehensive QoS management using flexible packet queues that ensure high priority packets get through in times of congestion.

The flexibility enabled by network processors has seen them being integrated into packet voice and packet video equipment where the devices can give more architecture options, including ATM and IP packet aggregation and distribution within a multi-card chassis; Network address translation to hide an internal IP network and present a single IP address to the external network; Ethernet to packet over SDH/SONET translation, increasing the range of connectivity options.

But, the drawback of flexibility is complexity; it becomes difficult to get the best out of the devices in single and multiple processor architectures, and each new development becomes a huge software task.

There are parallels here to what has happened in the digital signal processor (DSP) market. DSPs are programmable devices optimized for signal processing algorithms, replacing traditional ASIC-based designs. At that time, DSPs were going through a quantum leap in performance, enabling new and exciting applications. However, it was difficult to find good 3rd party support for low level algorithms and when algorithms were available, they were difficult to integrate because they followed different programming models and calling conventions. As a result, there was never a simple way to make use of the functionality without actually programming the DSP, which in itself was difficult.

However, by developing and standardizing on some conventions for algorithms, and backing this up with appropriate tools and operating system support, the leading DSP vendors were able to create an ecosystem of available "plug in" algorithms. Board-level vendors developed resource control frameworks with a host-level programming environment, into which these algorithms would fit. OEM developers could now get access to the benefits of DSPs (programmability, upgradability, performance) without actually doing any DSP programming.

Taking a cue from the DSP market model, an organization called the Network Processing Forum (NPF) is leading the efforts toward standardization. The NPF was formed to establish common specifications for hardware interconnects between network processors and software interfaces that will enable an ecosystem of 3rd party algorithms, frameworks and control routines.

The hardware interface is called the Common Switch Interface (CSIX) and the software interfaces are the Common Programming Interface (CPIX). Basically, CSIX is used to link network processors via switch fabrics to enable the creation of arrays of network processors and coprocessors. This in turn allows for a mix of high performance and flexibility to be achieved, and allows designs to be scaled cost-effectively to meet demand. The NPF has published the first version of this interface (CSIX-L1) and is at work defining the next generation. Standard interfaces can be mapped to board-level interfaces, so plug-in network processor boards offer a CSIX style interface for high speed data transport throughout a chassis.

Hidden complexity

The CPIX software interfaces, still under development, are more complex. In essence, there are two application programmers interfaces (APIs). A low level forwarding plane software interface (the Functional APIs or "FAPI"s) provides for control of different packet interpretation and forwarding resources as well as actual physical interfaces. The API structure is intended to be vendor independent but aware of the network processing elements underneath, and so arranged in a way that can make the most of the actual element capability.

For many vendors, this is where they will offer closed, board-level interfaces, but this could also be offered on, or at the edge of, a programmable network processor device so allowing 3rd parties to create and optimize packet manipulation algorithms to fit into this standard framework.

It also allows certain functions to be accelerated by coprocessors that could sit below the network processor resident interface. The area between the forwarding plane software interfaces and the actual network elements can be proprietary but is also is being addressed by a new initiative from the Internet Engineering Task Force (IETF) called ForCES (Forwarding and Control Element Separation).

In addition, there is a high level control plane software interface (the Services APIs or "SAPI"s), typically offered on a control element, and the control applications use these APIs to implement the actual services. At this level, the software interface, and the underlying framework implementation, is aware of the topology of the system underneath in terms of types, capabilities, and connections between network processing elements, but hides this from the control plane applications.

Examples of service applications include IP or ATM forwarding systems -to implement VLAN or "diffserv" class of service policing- or MPLS edge routers. As an example, in the implementation of an IPv4 forwarding element, each forwarding block has a specific function with a particular group of FAPI function calls to control it. The forwarding blocks are logical functions that have access to at least four processing resources:

1) Ethernet Ingress and Egress blocks have functions to set the physical port up/down, query the status, and perhaps access counters.

2) An IPv4i block performs packet checking, does a longest prefix match, associates a flow ID with the frame, and has two outputs depending on whether the packet has quality of service features, or whether it is a "best effort" class of service. The FAPI has functions to add and modify table entries, and access statistics, for example, bad checksums, time-to-live expiry.

3) A Packet Process block is a multi-function element that can perform filtering to catch excess packets, change the type of service field for the next hop, apply other SLA policies etc. The FAPI has functions to manage tables, set filters, access statistics, and can redirect non-compliant packets to the "best effort" classification.

4) A multiplexer block merges packets into queues for the next hop port. It applies shaping (delay) policies and discards packets if congestion occurs. The FAPI has functions for queue setting, discard policy, and statistics access.

At the control plane level, the control application uses standard routing and path discovery protocols such as Border Gateway Protocol (BGP), Routing Information Protocol (RIP) and Open Shortest Path First (OSPF), and then uses the NPF services API (SAPI) to update next hop and differentiated services tables in the forwarding elements. The SAPI functions in turn call on the appropriate FAPI functions to implement the service requests.

While the definitions of blocks and the exact APIs associated with the blocks is still underway, this example shows the basic structure and intent.

It is clear that the demand for network processors is rising, but the various interconnect initiatives means that a new design very quickly becomes a software problem rather than a hardware or performance problem. These problems will be aided by building a software ecosystem around network processors, and the CPIX and ForCES initiatives will help that happen. While these initiatives are still in their infancy, the network processor lobby has certainly learned from the pioneering days of DSP so the industry should expect a bright future at both a board and a system level.