NPF Implementation Agreements Overview

Hardware

The hardware working group creates Implementation Agreements for the required interfaces (physical and logical) used on Network Processing Elements (NPEs) such as Network Processing Units (NPU), network co-processors and traffic managers. The group defines, promotes, and delivers hardware interfaces for the packet data path through a network processor ("Streaming Interface") as well as for components attached to a network processor but not in the data path ("Look-Aside Interface"). These interfaces lessen the design burdens of equipment providers and give them the flexibility to use whatever components best fit their requirements and help them maintain their competitive advantage.


Message Layer (October 2003) - PDF File
The Message Layer IA establishes a common format and definition for the data exchanged between network processing elements (NPE). The specification outlines a set of defined message fields, how to compose those message fields into a valid message, how any NPE can specify which fields it needs and which it requires, and finally, a model for how any instantiation of the above can be communicated to an NPE. This enables networking software to be designed with little or no awareness of the details of the underlying hardware interfaces and promotes the reuse of networking software across different hardware interfaces. The IA combines a high degree of flexibility with the ability to be efficiently implemented in both hardware and software. The specification covers NPE-to-NPE communications over a range of common NPE-to-NPE conveyances including the NPF Streaming Interface, NPF Look Aside Interface and switch fabrics.

[Return to top]

Streaming Interface (NPSI) (October 2002) - PDF File
The Streaming Interface specification defines link layer interoperability among data path devices including framer to NPE, NPE to NPE, and NPE to switch fabric. This work builds on the success of the existing 2.5 Gbps CSIX-L1 specification and adopts a reduced pin-count approach to a 10 Gbps interface between network processors, framers, and switching fabrics. The protocol is speed independent and scalable. It is initially targeted for 10 Gbps applications. The Streaming Interface IA enables network equipment manufacturers to combine data path chips from different manufacturers and be able to modify existing designs simply by adding or changing individual components.

[Return to top]

Look Aside Interface LA-1 (May 2002-Updated April 2004) - PDF File
The Look-Aside Implementation Agreement (LA-1) is a hardware interface specification intended for devices located adjacent to a network processing device that off-load certain tasks from the network processor. This includes devices such as Content-Addressable Memories (CAMs), classifiers, and encryption co-processors. The interface supports lookup requirements for OC-48 through OC-192 line rates. For the first time, design engineers can choose from a variety of Network Processing (NP) components knowing that the fundamental hardware interconnection is the same.

[Return to top]

The hardware working group will refine these specifications as speeds increase and technologies evolve. The group is already in the process of creating an updated Look-Aside Interface (LA-2) for response-request-based NPEs and an updated streaming interface to extend the interface to 40 Gbps applications.

[Return to top]

Software

The Software Working Group's purpose is to define, promote, and deliver software interfaces that permit integration between multiple software applications and network processors. Similar to the hardware IA's, these specifications give System OEMs additional freedom to choose a software solution that best meets their unique requirements knowing that the basic functionality is supported.

SSL Accelerator SAPI (August 2006) -
PDF File
The SSL Accelerator SAPI specifies an open and generic interface for the configuration and management of an SSL Accelerator device by an SSL Acceleration Service Client. This includes configuration and management of the SSL session negotiation database, the SSL flow database, and the SSL target selector database. Furthermore, the SSL Accelerator SAPI allows the SSL Acceleration Service Client to register for and receive event notifications indicating packet drops, SSL alerts and other information. In accordance with the NPF framework model, the SSL Accelerator SAPI is Network Element unaware.

[Return to top]

Switch Address Generator ATM LFB and Functional API (March 2006) -
PDF File
The Switch Address Generator ATM LFB receives a packet on one of the four inputs from the previous LFB in the pipeline, performs a lookup to find the backplane link, produces the required backplane PDU and forwards the PDUs to the next LFB. The Switch Address Generator ATM LFB uses the BP Link ID signaled in the metadata to find the backplane link to be used to transport the packet over the backplane.

The Switch Address Generator ATM LFB obtains configurations from the ATM Confiuration Manager Functional API. In addition the Switch Address Generator ATM LFB contains an optional formatting function for merging of incoming metadata or static defined strings into the switch address. The optional function can also specify the placement of the metadata-generated part in relation to the ATM SDU (header or trailer).

[Return to top]

AAL1 Transmit Functional API (February 2006) - PDF File
The AAL1 provides a mechanism to its service users to transfer and deliver service data units with a constant bit rate across an ATM network. This implementation agreement defines the ATM Adaptation Layer 1 (AAL1) Transmit LFB and lists the configurations required by the LFB. The AAL1 Transmit LFB sends ATM SDUs to the ATM layer for transmission over VCs configured for AAL1 service. It performs the SAR and CS sublayer functions required for segmentation of the user information, as per ITU recommendation I.363.1. The AAL1 Transmit LFB obtains its configurations from the ATM Configuration Manager Functional API implementation. This document describes the inputs and outputs of the LFB along with the metadata expected at the inputs and the metadata produced by the LFB at its outputs.

[Return to top]

AAL1 Receive Functional API (February 2006) - PDF File
The AAL1 provides a mechanism to its service users to transfer and deliver service data units with a constant bit rate across an ATM network. This implementation agreement defines the ATM Adaptation Layer 1 (AAL1) Receive LFB and lists the configurations required by the LFB. The AAL1 Receive LFB receives ATM SDUs from the ATM layer over VCs configured for AAL1 service. It performs the SAR and CS sublayer functions required for re-assembly of the user information, as per ITU recommendation I.363.1. The AAL1 Receive LFB obtains its configurations from the ATM Configuration Manager Functional API implementation. This document describes the inputs and outputs of the LFB along with the metadata expected at the inputs and the metadata produced by the LFB at its outputs.

[Return to top]

Inverse Multiplexing for ATM (IMA) LFB and Functional API (November 2005) - PDF File
The IMA LFB performs multiplexing and de-multiplexing of ATM cells in a cyclical fashion among links of an IMA group to form a higher bandwidth logical link whose rate is approximately the sum of the link rates. In the transmit direction, the ATM cell stream received from the ATM layer is distributed on a cell by cell basis, across the multiple links within the IMA group. In the receive direction, the IMA LFB recombines the cells from each link, on a cell by cell basis, recreating the original ATM cell stream. The aggregate cell stream is then passed to the ATM layer. This Implementation Agreement provides an Functional API with data structures and functions for IMA link and IMA group management.

[Return to top]

Next Hop LFB and FAPI (October 2005) - PDF File
Depending on the Forwarding plane NP architecture, a Forwarding Information Base (FIB) may be modeled in several ways. One mode, the unified table model, uses a single table for structuring and managing IPv4 unicast forwarding information. A second mode, the discrete table model, uses separate Prefix and Next Hop tables for structuring and managing IPv4 unicast forwarding information. This LFB relates to the discrete table model, specifically for the management of the Next Hop tables. It is responsible for selecting a Next Hop from a possible set of Next Hops associated with a prefix according to a preset policy (for example, load balancing, MPLS LLSPs, etc.). It is also responsible for checking if the egress interface MTU allows the current packet to be forwarded without fragmentation (might trigger an ICMP packet if the DF bit is set and the MTU is too small). Furthermore, it optionally maintains the TTL value associated with the Next Hop entry, in the case where TTL check is enabled. The FAPI Logical Function Block APIs are used to configure LFB resources and associate resources between LFBs. This contribution describes the Next Hop LFB and its associated APIs.

[Return to top]

ATM OAM Transmit LFB and Functional API (August 2005) - PDF File
The ATM OAM Transmit LFB does the insertion of the ATM OAM cells in the transmitted ATM cell stream. The ATM OAM cell insertion may be requested by the ATM OAM receive LFB as a response to received ATM OAM cells, detected fault conditions, performance monitoring functions performed by the ATM OAM receive LFB, etc. The ATM OAM Transmit LFB also performs OAM cell insertion as directed by the FAPI client to carry out procedures like activation or deactivation of continuity check/ performance monitoring procedures, alarm generation, loopback initiation, etc.

When performance monitoring is enabled for a F4 or F5 flow, the ATM OAM transmit LFB maintains statistics for the user cells transmitted on those flows and generates FPM cells periodically based on the configured block size. When continuity check procedures are enabled for a F4 or F5 flow, the continuity check cells are generated by the ATM OAM transmit LFB. The CC cells may be generated periodically or if no user cell for that flow has been transmitted for the continuity check period as specified by the FAPI client when activating the continuity check procedure.

The ATM OAM receive LFB has two standard inputs. One input is used to receive user cells requested for transmission by the previous LFB in the processing chain. The other input is used to receive the ATM SDUs for ATM OAM cells requested for insertion into the F4/F5 flows by the ATM OAM receive LFB.

OAM flows are related to bi-directional Maintenance Entities (MEs) corresponding either to the entire ATM VPC/VCC, referred to as the VPC/VCC ME, or to a portion of this connection referred to as a VPC/VCC segment ME. Before the start of any OAM operation, the boundary needs to be drawn for the paired endpoints. The MEs terminating the ATM links are configured before as an endpoint of the VPC/VCC or endpoint of the VPC/VCC segment. End-to-end F5 flows terminate at the endpoints of a VCC, while the segment F5 flows terminate at the VCC segment endpoints. Similarly, the end-to-end F4 flows terminate at the endpoints of a VPC, while the segment F4 flows terminate at the VPC segment endpoints. The ATM OAM Transmit LFB performs the OAM functions configured for the OAM flow terminations.

ATM OAM Transmit LFB obtains its configurations from the ATM Configuration Manager Functional API implementation. This document describes the inputs and outputs of the LFB along with the metadata expected at the inputs and the metadata produced by the LFB at its outputs.

[Return to top]

ATM OAM Receive LFB and Functional API (August 2005) - PDF File
The ATM OAM Receive LFB does ATM OAM processing on the ATM SDU received from the previous LFB in the packet processing chain. Depending on the connection on which the cells are received the cells may be classified into user cells and OAM cells for the OAM flow associated with that connection. The cells received on a VP link may be either user cells or OAM cells for F4 flow. The cells received on a VC link may be either user cells or OAM cells for F5 flow. Additionally, F5 OAM cells received on VC links are considered as user cells for the F4 flow on the associated VP.

OAM flows are related to bi-directional Maintenance Entities (MEs) corresponding either to the entire ATM VPC/VCC, referred to as the VPC/VCC ME, or to a portion of this connection referred to as a VPC/VCC segment ME. Before the start of any OAM operation, the boundary needs to be drawn for the paired endpoints. The MEs terminating the ATM links are configured before as an endpoint of the VPC/VCC or endpoint of the VPC/VCC segment. End-to-end F5 flows terminate at the endpoints of a VCC, while the segment F5 flows terminate at the VCC segment endpoints. Similarly, the end-to-end F4 flows terminate at the endpoints of a VPC, while the segment F4 flows terminate at the VPC segment endpoints. The ATM OAM receive LFB performs the OAM functions configured for the OAM flow terminations. The ATM OAM receive LFB may also be configured to perform passive monitoring of OAM flows. ATM OAM Receive LFB obtains its configurations from the ATM Configuration Manager Functional API implementation. This document describes the inputs and outputs of the LFB along with the metadata expected at the inputs and the metadata produced by the LFB at its outputs.

[Return to top]

AAL2 SAR SSCS Transmit LFB and Functional API (August 2005) - PDF File
The AAL2 SAR SSCS Transmit LFB receives packets to be transferred on AAL2 channels from the previous LFB in the packet processing chain. The AAL2 SAR SSCS LFB then segments the receive packets to create CPS SDUs using the AAL2 channel ID, UUI and frame length signaled in the metadata. The AAL2 CPS SDUs created by the AAL2 SAR SSCS Transmit LFB are passed to the next LFB in the packet processing chain. AAL2 SAR SSCS Transmit LFB obtains its configurations from the ATM Configuration Manager Functional API implementation. This document describes the inputs and outputs of the LFB along with the metadata expected at the inputs and the metadata produced by the LFB at its outputs.

[Return to top]

AAL2 SAR SSCS Receive LFB and Functional API (August 2005) - PDF File
The AAL2 SAR SSCS Receive LFB receives CPS SDUs from the previous LFB and performs re-assembly of the CPS SDUs to create SSSAR SDUs. Depending on the configuration of the ATM AAL2 channel on which the SSSAR SDU is received further processing by the SSADT and SSTED sublayers may be performed. AAL2 SAR SSCS Receive LFB obtains its configurations from the ATM Configuration Manager Functional API implementation. This document describes the inputs and outputs of the LFB along with the metadata expected at the inputs and the metadata produced by the LFB at its outputs.

[Return to top]

AAL2 CPS Transmit LFB and Functional API (August 2005) - PDF File
The AAL2 CPS Transmit LFB receives CPS SDUs to be transferred on AAL2 channels from the previous LFB in the packet processing chain. The AAL2 CPS Transmit LFB uses the AAL2 channel ID, UUI and Length indicator signaled in the metadata to create CPS packets. AAL2 CPS Transmit LFB then places these CPS packets into ATM SDUs sent to the next LFB in the packet processing chain. The AAL2 channels created on an AAL2 path may be offered differential service with respect to the bandwidth usage and service delay. One or more AAL2 channels may be associated with a priority level. The bandwidth of the configured AAL2 path is shared between these priority levels proportionate to a weight configured for the priority level. The AAL2 CPS Transmit LFB enforces a threshold for the number of packets which may be queued in each priority queue for an AAL2 path. AAL2 CPS Transmit LFB obtains its configurations from the ATM Configuration Manager Functional API implementation. This document describes the inputs and outputs of the LFB along with the metadata expected at the inputs and the metadata produced by the LFB at its outputs.

[Return to top]

AAL2 CPS Receive LFB and Functional API (August 2005) - PDF File
The AAL2 CPS Receive LFB performs receives ATM SDUs from the previous LFB in the packet processing chain and extracts CPS packets interleaved on the ATM cell stream. The AAL2 CPS Receive LFB uses the VC link ID signaled in the metadata to perform the CPS packet extraction. The LFB also determines the SSCS configured on the AAL2 channel along with the higher layer interface bound to it and signals them in the metadata to the next LFB in the packet processing chain along with the extracted CPS SDU. AAL2 CPS Receive LFB obtains its configurations from the ATM Configuration Manager Functional API implementation. This document describes the inputs and outputs of the LFB along with the metadata expected at the inputs and the metadata produced by the LFB at its outputs.

[Return to top]

ATM Traffic Manager LFB and Functional API (August 2005) - PDF File
The ATM Traffic Manager is used to ensure conformance of the traffic on a virtual link to the established traffic contract for a virtual link by using mechanisms like buffering, traffic shaping, queuing and scheduling, etc. on the virtual links of the connection. The LFB uses the VP link ID, VC link ID, Payload Type Identifier (PTI) and Loss Priority (LP) signaled in the metadata to perform the traffic management actions on the received ATM SDU. The ATM Traffic Manager LFB obtains its configurations from the ATM Configuration Manager Functional API implementation. This document describes the inputs and outputs of the LFB along with the metadata expected at the inputs and the metadata produced by the LFB at its outputs.

[Return to top]

ATM Policer LFB and Functional API (August 2005) - PDF File
The ATM Policer LFB monitors received ATM SDU from the previous LFB in the packet processing chain to ensure conformance to the traffic contract. The ATM policer LFB may be used to perform UPC or NPC functions on the received cell stream. The ATM policer uses the traffic parameters specified in the traffic descriptor (used by the source of the cell stream on this virtual link) to perform the UPC or NPC function. The ATM policer may perform the following actions to ensure conformance of the virtual link to negotiated traffic contract:
          - Cell passing
          - Cell Tagging by changing loss priority to 1 from 0
          - Cell discarding
The ATM policer may also be configured to perform frame discard by examining the payload type of the ATM SDU using the below schemes:
          - Partial Packet Discard (PPD)
          - Early Packet Discard (EPD)
The LFB uses the VP link ID, VC link ID, Payload Type Identifier (PTI) and Loss Priority (LP) signaled in the metadata to perform the policing actions on the received ATM SDU. The ATM Policer LFB obtains its configurations from the ATM Configuration Manager Functional API implementation. This document describes the inputs and outputs of the LFB along with the metadata expected at the inputs and the metadata produced by the LFB at its outputs.

[Return to top]

AAL5 Transmit LFB and Functional API (August 2005) - PDF File
The AAL5 Transmit LFB receives packets to be transferred on VC links from the previous LFB in the packet processing chain. The AAL5 Transmit LFB uses the VC link ID, CPCS loss priority, UUI and the frame length signaled in the metadata to transform input packets into AAL5 frames. The LFB then segments the AAL5 frames into ATM SDUs to pass to the next LFB in the packet processing chain. The AAL5 Transmit LFB obtains its configurations from the ATM Configuration Manager Functional API implementation. This document describes the inputs and outputs of the LFB along with the metadata expected at the inputs and the metadata produced by the LFB at its outputs.

[Return to top]

AAL5 Receive LFB and Functional API (August 2005) - PDF File
The AAL5 Receive Logical Functional Block (LFB) receives ATM SDUs from the previous LFB in the packet processing chain and performs re-assembly of the ATM SDUs to create AAL5 packets. The AAL5 Receive LFB uses VC link ID, Payload Type Identifier (PTI) and Loss Priority (LP) signaled in the metadata to perform the reassembly. The AAL5 Receive LFB obtains its configurations from the ATM Configuration Manager Functional API implementation. This document describes the inputs and outputs of the LFB along with the metadata expected at the inputs and the metadata produced by the LFB at its outputs.

[Return to top]

ATM Configuration Manager Functional API (March 2005) - PDF File
This document specifies the API for the ATM configuration Manager Logical Functional Block (LFB). The ATM configuration manager LFB is the entity responsible for configuration and management of ATM LFBs on a Forwarding Element (FE). The ATM configuration manager provides API function calls and data structures for
          - ATM connection management
          - AAL2 channel management
          - ATM OAM services
          - There are two types of ATM connections:
                 1.   Virtual Path Connections (VPC)
                 2.   Virtual Circuit Connections (VCC)

[Return to top]


ATM Header Generator LFB and Functional API (March 2005) - PDF File
The ATM Header Generator Logical Functional Block (LFB) receives ATM a Service Data Unit (SDU) from the previous LFB in the pipeline, applies the ATM cell header on the ATM cell and hands it off to the ATM TC Transmit LFB. The ATM Header Generator LFB uses the VP/VC Link ID, payload type and loss priority signaled in the metadata to determine the ATM header to form the ATM cell.

[Return to top]

ATM Header Classifier LFB and Functional API (March 2005) - PDF File
The ATM Header Classifier Logical Functional Block (LFB) receives ATM cells from the external ATM interface and does validation of the ATM header for errors. The ATM Header Classifier LFB uses the VPI from the ATM header along with the interface type identifying the interface as a UNI or NNI interface to determine the VP link on which the cell was received. If the VP is terminated at this node, the VCI of the ATM header is used to determine the VC link on which the cell was received. The ATM cell SDU is then extracted and sent to the next LFB in chain for processing.

[Return to top]

ATM SW API Architecture Framework (March 2005) - PDF File
This document outlines the Architecture Framework for NPF ATM SW APIs and should be seen as a complement to the API Software Framework (August 2002) Implementation Agreement. It is intended as the basis for using network processing elements in the construction of networking equipment for ATM.

The NPF Software Architecture has its special Service API and Functional APIs for ATM. There are also ATM extensions to the Interface Management API and the Packet Handler API. These APIs can be used for configuring and managing ATM functions on Network Processing Elements (NPEs). The Packet Handler API comprises a service level API that supports input and output sessions for individual applications, and a Functional API that communicates directly with a Forwarding Element (FE).

[Return to top]

This document defines a NPF Service API for the Mobile IPv6 Home Agent function (MIPv6 HA for short). The MIPv6 HA Service API serves to configure and manage some specific MIPv6 HA forwarding path functions.

The primary data plane task performed by a MIPv6 HA is to tunnel packets destined to mobile nodes (MNs for short), identified with their home addresses – denoted the HoA, to their current location in the IPv6 internet, the Care-of-Address - denoted the CoA, as well as conversely, to accept and decapsulate reversely tunneled packet from the mobile nodes and forward those onto the internet for further delivery.

On the MIPv6 HA to/from MN path, the packets are tunneled using IPv6-in-IPv6, possibly with the addition of IP Security ESP depending on the nature of the payload. In the first case the MIPv6 HA decapsulation and encapsulation function should be applied to the packets. In the latter case, the packets are processed by the corresponding IP Security decryption and encryption functions.

Mobile nodes use MIPv6 signaling to register for the MIPv6 HA service as well as to notify their Home Agents about their current location. Mobile node registration data, the HoA, the CoA as well as a number of auxiliary parameters, lifetime and more, are cached in the conceptual Binding Cache of the MIPv6 HA.

In an architecture with separation of forwarding and control elements, the (MIPv6) signaling processing is normally handled in the control plane, whereas payload handling functions such as IP forwarding and interface processing functions, and for the MIPv6 HA node function specifically, the MIPv6 HA tunnel encapsulation and decapsulation functions, are implemented in the forwarding plane.

The MIPv6 HA Service API provides the means for a HA control plane entity to manage the MIPv6 HA encapsulation and decapsulation tunneling function of the forwarding plane as well as to manage one auxiliary MIPv6 HA forwarding path function, the MIPv6 HA Proxy Neighbor Discovery function.

The anticipated user of the MIPv6 HA Service API is a conceptual MIPv6 HA Service Layer Module responsible for the processing of the MIPv6 signaling messages, for the maintenance of the Binding Cache in accordance with the MIPv6 signaling messages received and for the push down and retrieval of the appropriate Binding Cache attributes to the afore mentioned MIPv6 HA specific forwarding path functions.

The conceptual MIPv6HA Service Layer module may also be responsible for the instantiation of other forwarding path functions required for the MIPv6 HA function, this either directly via the respective Service APIs or indirectly via mediation with the Service Layer Users of the respective Service APIs.

[Return to top]

IPv4 Prefix LFB and Functional API (February 2005) - PDF File

Depending on the Forwarding plane NP architecture, a Forwarding Information Base (FIB) may be modeled in several ways. One mode, the unified table model, uses a single table for structuring and managing IPv4 unicast forwarding information. A second mode, the discrete table model, uses separate Prefix and Next Hop tables for structuring and managing IPv4 unicast forwarding information [IPV4SAPI].

This LFB relates to the discrete table model, specifically for the management of the Prefix tables. It is responsible for LPM (longest prefix match) search on the packet to determine the matching Next Hop metadata for a particular prefix (destination IP address in normal case). It also performs checks to validate the prefix for the packet according to RFC 1812.

The FAPI Logical Function Block APIs are used to configure LFB resources and associate resources between LFBs. This document describes the Prefix LFB and its associated APIs.

[Return to top]

Generic Classifier LFB and Functioncal API (December 2004) - PDF File

This document describes a Classifier Logical Functioncal Block. A Classifier examines a packet and, based on its content, produces an output ClassID metadata that can affect the processing of that packet in downstream.

[Return to top]

Topology Manager Functional API (December 2004) - PDF File

The Functional API (FAPI) is used by vendors to expose board-level functionality. FAPI exposes the functionality specific to each board, as such, it is expected that the set of functions exposed will vary just as the network processing elements on different boards vary. While variance in the set of exposed functions is expected, for each type of function the methods used and the semantics of the function is expected to be vendor agnostic and consistent. Thus, while one board might expose functionality for IPv4 forwarding and NAT, perhaps based on a programmable network processor, and another board might expose functionality for IPv4 forwarding and MPLS using a classification chip and QoS chip, the IPv4 functionality exposed would be the same, at least as to the syntax used. Differences might exist in capabilities (supported numbers of forwarding entries, maximum rate of forwarding, etc.) but not in syntax. The same method would be used to add a forwarding entry, using the same data structures. In order to expose the variation in functions provided by different boards the FAPI model defines two sets of APIs. These are the FAPI Topology Discovery APIs and the FAPI Logical Function Block APIs.

The FAPI Topology Discovery APIs are used to learn the presence of types of functions on a device and acquire handles used to configure instances of those functions. The learning aspects of the FAPI Topology Discovery APIs are expected to be used in scenarios where a blade is “hot plugged” into a system and the control plane must learn the type of blade it is. The handle retrieval methods of the FAPI Topology Discovery APIs are used both in “hot plug” scenarios and in static configuration scenarios, and allow a client program to programmatically acquire handles for use in configuring the tables which control forwarding device behavior.
The FAPI Logical Function Block APIs are used to configure LFB resources and associate resources between LFBs. For example, they can be used to configure Data Path functions such as IPv4 forwarding, MPLS forwarding, tunneling in conjunction with IPv4, etc. The FAPI LFB APIs are specific to different LFBs and will be discussed in separate contributions.

[Return to top]

FAPI Model and Usage Guidelines (October 2004) - PDF File

Service APIs (SAPIs) provide an interface that hides the detail of the network element. By contrast, Functional APIs (FAPIs) are aware of the composition of the network element and require the ability to address individual functions in its forwarding path(s).

Thus a FAPI is used by vendors to expose the resources that underlie network element-level functionality. It is expected that the set of functions exposed in any particular device will vary just as the network processing elements (NPEs) on different boards vary. While variance in the set of exposed functions is expected, for each type of function the methods used and the semantics of the function is expected to be vendor agnostic and consistent. Thus, while one board, i.e. a physical realization of a forwarding element (FE) might expose functionality for IPv4 forwarding and NAT, perhaps based on a programmable network processor, and another board might expose functionality for IPv4 forwarding and MPLS using a generic classification chip and QoS chip, the IPv4 functionality exposed would be the same, at least insofar as to the syntax used. Differences might exist in resource capabilities (supported numbers of forwarding entries, maximum rate of forwarding, etc.) but not in syntax. The same method would be used to add a forwarding entry, using the same data structures.

To capture the diversity of function offered by network elements (NEs), we break down the functionality of an FE into smaller functional elements, known as Logical Functional Blocks, (LFBs). An LFB has a specific function in the FE and receives well-defined inputs and outputs. It can be composed together with other LFBs to build a complete packet processing chain.
The concept of the LFB has also been adopted by the ForCES WG of the IETF [FORCESCH, FORCESREQ] and many of the modeling principles used by ForCES have been adopted in the NPF FAPI model. There are thus significant similarities between the ForCES model and the NPF FAPI model but it must not be forgotten that ForCES is essentially a distributed processing abstraction whereas the FAPI model deals with tangible resources such as processors, registers and memory.

In order to expose the variation in functions provided by different realizations the FE is accessed using two sets of APIs. These are the FAPI Topology Discovery APIs, [FAPITOPO], which allow the structure of a FE to be obtained, in particular the identities of the function blocks and thence resources in it, and the FAPI Logical Function Block (LFB) APIs, which allow access to functions’ resources.

The FAPI Topology Discovery APIs are used to learn the presence of types of functions on a device and acquire handles used to configure instances of those functions. The learning aspects of the FAPI Topology Discovery APIs are expected to be used in scenarios where, for example, a blade is “hot plugged” into a system and the control plane must learn the type of blade it is. The handle retrieval methods of the FAPI Topology Discovery APIs are used both in “hot plug” scenarios and in static configuration scenarios, and allow a client program to programmatically acquire handles for use in configuring the tables which control forwarding device behavior.
The FAPI LFB APIs are domain specific APIs that manage the behavior of forwarding plane functions, and the tables used to configure them. FAPI LFB APIs will be defined for many domains including IP, MPLS, DiffServ, ATM, and interfaces of various types. It is expected that reuse of APIs between different domains will be important, thus function signatures for common operations such as retrieving counters or deleting table entries should be reused between different LFB APIs as appropriate.

[Return to top]

Messaging LFB (September 2004) - PDF File

A forwarding plane, as modeled within the NPF, is comprised of a series of Logical Function Blocks (LFBs), which may span multiple forwarding elements (FEs), to perform distinct packet processing activities. Within each FE, these LFBs are connected together, via the LFB Topology [LFB_TOPO], in order to carry out a consistent forwarding plane function for the FE. In order to carry out the forwarding plane function of the FE, or in order to provide forwarding functionality across FEs, it is often necessary for these LFBs to share metadata with each other, as a downstream LFB may rely on metadata from a previous LFB as part of its processing. When the passing of packet and metadata occurs between FEs that span a physical boundary, it is necessary to have common, well-defined interfaces for accepting and receiving packet and metadata at the edges of these FEs. The mechanism by which an FE passes packet and metadata, across a physical boundary, to another FE is the Messaging LFB. The following describes the Messaging LFB and how it is used.

The function of the Messaging LFB is to pass packet and metadata between FEs, across a physical boundary (e.g. LA-1, switch fabric, etc.), in a consistently packaged manner. This allows for interoperability of FEs, from a logical perspective, even if those FEs come from different vendors. The Messaging LFB uses the NPF Messaging Layer Implementation Agreement [NPF_MSG] as the basis for how it formats the metadata.

[Return to top]

IP Security (IPSec) Service API (August 2004) - PDF File

IPSec provides security services at the IP layer. These services include data confidentiality, integrity and authentication. In order to provide these services, two rules databases need to be defined in accordance with the IPSec protocol specification. These are the Security Policy Database (SPD) and the Security Association Database (SAD). These databases contain various attributes allowing a given IPSec implementation in the forwarding plane to determine how to handle ingress and egress IP data packets. Within the IPSec realm, the SPD defines what to do in handling a given IP packet, whereas the SAD defines how to do this.
The IPSec Service API (SAPI) provides a generic interface for configuring and managing the IPSec databases (SPD and SAD). Furthermore, the IPSec SAPI allows a client application to receive event notifications indicating state changes, alerts and other information data. In accordance with the NPF framework model, the IPSec SAPI is Network Element unaware.

[Return to top]

HA Service API (July 2004) - PDF File
NOTE: Software API Framework Revision 2.0 deprecates the "HA Service API IA".Details on how High Availability (HA) functionality will be carried out going forward can be found in chapter 9 of Software API Framework Revision 2.0.
The HA Service API IA specifically defines how the various APIs described in the HA Architectural Model and Framework IA interact to enable HS services in network processing-based systems. Once implemented, these interfaces will enable System OEMs to more quickly and cost-effectively develop multi-vendor networking solutions that support HA features. The IA defines the data structures and required data types of an operational API that will be used by HA aware applications to send HA parameters to the other NPF software APIs. The IA also describes in detail two additional APIs, the HA-Services API and the HA-Functional API, that are needed to interface HA Services with existing NPF software APIs.

[Return to top]

HA Architecture Model and Framework (July 2004) - PDF File
NOTE: Software API Framework Revision 2.0 deprecates the "HA Architecture Model and Framework IA" . Details on how High Availability (HA) functionality will be carried out going forward can be found in chapter 9 of Software API Framework Revision 2.0.
The HA Architectural model and Framework IA outlines the additions that are needed to build highly available systems within the confines of the NPF software framework. HA functions protect against network and operational failures that cause disruptions in real-time services. The document describes the framework for how HA systems will function within the NPF software environment, how the SA Forum's services can be used with the NPF HA API and how existing NPF software APIs can be modified to incorporate HA features.

[Return to top]

Diffserv Services API Specification (July 2004) - PDF File
The Diffserv Services API IA is a software interface specification that covers all Diffserv-related protocol functions. The IA provides a hardware architecture agnostic and independent software developer interface that enables and configures Differentiated Services, including both edge and core Diffserv functions. When implemented by network processing hardware and software vendors, the interface will enable an ecosystem of interchangeable components that can be used to build networking systems with enhanced Quality of Service capabilities. The availability of these compatible components will make it easier for System OEMs to select network processing-based elements and speed the development of networking solutions that can process Diffserv functions. The API is designed for the management of Diffserv policies and QoS objects, it defines how to specify filters, how to query Diffserv capability profiles, and how to gather Diffserv-related statistics.

[Return to top]

IPv4 Unicast Forwarding Service API Revision 2 (June 2004) - PDF File
The IPv4 API IA describes service API definitions for IPv4 unicast forwarding and address resolution. The API function details include input/output parameters, return code specifications and detailed usage notes specific to each invocation. The specification also includes details regarding the handling of a synchronous events and expected responses from API function invocations, including specifications for completion callback and event handler routine registration and deregistration. This IA enables the development of complete IPv4 forwarding software solutions from independent software and network processor vendors and will also greatly simplify the difficult task System OEMs face migrating their existing control-plane software to network processor-based systems. Revision 2 adds support for the usage of next hop information in the form of MPLS LSPs used for FTN mapping in an ingress Label Edge Router.

[Return to top]

IPv6 Unicast Forwarding Service API Revision 2 (June 2004) - PDF File
IPv6 Unicast Forwarding Service API Revision 2 (June 2004) The IPv6 API IA describes vendor-neutral data structures/Service API definitions for IPv6 unicast forwarding and address resolution. The API function details include input/output parameters, return code specifications and detailed usage notes specific to each invocation. The IA provides details regarding the handling of asynchronous events and expected responses from API function invocations, including specifications for completion callback and event handler routine registration and deregistration. A major addition in revision 2 is that the specification now supports the usage of next hop information in the form of MPLS LSPs used for FTN mapping in an ingress Label Edge Router.

[Return to top]

Interface Management API Revision 3 (November 2004) - PDF Files
Interface Management API Revision 2 (December 2003) - PDF File
Interface Management APIs Version 1 (August 2002) - PDF File
The Interface Management API establishes a standard interface for the configuring, provisioning and monitoring of a networking system's physical and logical external network ports. The API is both device-independent and OS-independent, making router and switch control-plane applications more portable. The IA is currently in its third revision (3.0) and supports various interface types including LAN (various flavors of Ethernet), ATM (support for AAL5 termination only), Packet-over-Sonet (POS), IPv4 logical interface, IPv6 logical interface, IPv6 in IPv4 logical interface, IPv4 tunnel, and IPv6 tunnel. The specification will benefit system designers by extending application life and reducing software development costs. It will also create a standardized programming interface for protocol stack vendors that enables service applications to be coded to a single interface management API that significantly reduces programming and development costs. Finally, the IA gives silicon vendors the ability to expose the configuration capabilities of their devices and it enables them to go after new markets.

[Return to top]

IPv6 Unicast Forwarding Service API (September 2003) - PDF File
The IPv6 API describes a vendor-neutral programming interface to configure and manage any IPv6 Forwarding Information Base (FIB). The specification provides an interface to configure and manage address resolution tables and it includes unified and discrete mode versions similar to those found in the IPv4 Forwarding Services API announced earlier this year.

[Return to top]

Packet Handler API (September 2003) - PDF File
The Packet Handler API outlines an open interface specification that facilitates the transfer of packets between the data plane forwarding elements and control plane applications for control or exception path processing. Control plane applications such as signaling stacks can use this API to send and receive packets from network processing elements. The IA can easily interface with existing networking stack implementations and has a set of interfaces that provide basic packet transfer capabilities.

[Return to top]

MPLS Forwarding Service API (September 2003) - PDF File
The NPF MPLS Forwarding Services API provides an open and generic interface for control plane software components to configure and manage the forwarding plane elements of the MPLS layer. The IA highlights the key MPLS structures that are required to be implemented in the forwarding plane and provides a vendor neutral API for control plane stacks such as LDP and RSVP-TE to configure and manage this MPLS information.

[Return to top]

Software API Conventions Revision 2 (April 2003) - PDF File
Software API Conventions Version 1 (August 2002) - PDF File
The Software API conventions document dictates the conceptual and documentation conventions used within all API specifications produced by the NPF Software Working Group. This revision supersedes the original document that was published in September of 2002. The key revisions include enabling support for optional functions, improving event notification, support for lost or duplicated callbacks, and clarifying the instructions related to multi-vendor and multi-instance interoperability.

[Return to top]

IPv4 Unicast Forwarding Service API (April 2003) - PDF File
The IPv4 Unicast Forwarding Service API specification describes service API definitions for IPv4 unicast forwarding and address resolution. The API function details include input/output parameters, return code specifications and detailed usage notes specific to each invocation. The specification also includes details regarding the handling of a synchronous events and expected responses from API function invocations, including specifications for completion callback and event handler routine registration and deregistration. This IA enables the development of complete IPv4 forwarding software solutions from independent software and network processor vendors and will also greatly simplify the difficult task System OEMs face migrating their existing control-plane software to network processor-based systems.

[Return to top]

API Framework Lexicon (August 2002) - PDF File
This document defines terms that are used in NPF Software API documents.

[Return to top]

[Return to top]

Benchmarking


The objectives of the Benchmarking Working Group include the definition, promotion and delivery of a standard set of benchmarks and the methods for reporting benchmark results. NPF benchmarking IA's specify precisely how vendors and independent parties should measure the performance of NP-based subsystems. These specifications will provide customers and vendors with objective performance data needed to properly compare and evaluate network processing components.

Network processing manufacturers that wish to certify the performance results of their benchmark tests must submit their products to a third party independent auditor and certification authority such as the Tolly Group. Once testing is completed, the NPF provides the "NPF Certified" mark to the manufacturer validating that the benchmark results are in complete compliance with NPF benchmark specifications.

TCP Proxy Application Level Benchmark (March 2006) -
The TCP Proxy Application Level Benchmark specifies performance metrics and testing methodologies for the measurement of TCP Proxy applications on a network processor subsystem. TCP Proxies fully terminate TCP connections enabling full data scanning and modification. TCP Proxies serve as the foundation for applications such as L7 firewalls, load balancers, SSL accelerators and Intrusion Detection Systems. This benchmark defines standard testing procedures for TCP Proxy Goodput on existing connections, Goodput with connection setup/teardown, connection setup rate, connection setup and teardown rate, SYN/ACK latency, and connection setup latency. Standard workloads are defined including TCP object sizes, number of concurrent connections, traffic patterns and round trip times. Tester performance calibration is handled through the specification of both DUT and loopback tests. This is the NPF's first layer 4 benchmark.

[Return to top]

IPSec Forwarding Application Level Benchmark -
The IPSec Forwarding Application Level Benchmark Implementation Agreement (IA)enables the objective measurement and reporting of the IPSec performance of any Network Processing Unit (NPU)-based device or set of components under test. The benchmark provides both vendors and System OEMs with a quantitative analysis of how the system/part(s) will perform providing IPSec-based functions. The IA includes specific instructions for set-up and configuration, tests and test parameters and result reporting formats. The specification supports a number of different configurations including systems with multiple NPU's, PC Board's and/or daughter cards, and a backplane or switch fabric. Whichever configuration is used, all of the systems components must be documented. The IA includes three specific tests. Each test has its own procedure, test setup, frame sizes and reporting format. The three tests measure the IPSec forwarding rate, IPSec throughput and the IPSec latency.

[Return to top]

Switch Fabric Benchmark (July 2003) -
The Switch Fabric Benchmark is a compilation of five fabric Implementation Agreements that were released starting in October of 2002. The five IA's include Switch Fabric Benchmarking Framework, Fabric Traffic Models, Fabric Performance Metrics, Performance Testing Methodology for Fabric Benchmarking, and Switch Fabric Benchmark Test Suites. Together, these agreements provide all of the background methodology and testing parameters needed for vendor independent switch fabric performance measurement. The tests are divided into three suites including hardware benchmarks, arbitration benchmarks and multicast benchmarks. Each suite includes multiple tests with their own test objective, arrival pattern, test procedure, and result presentation instructions. The three main performance metrics include latency, accepted vs. offered bandwidth and jitter. This benchmark will enable system design engineers to assess and compare different switch fabrics in an open and objective manner.

[Return to top]

IP Forwarding Benchmark (June 2003) -
This Implementation Agreement extends the scope of the IPv4 Forwarding Benchmark (July 2002) to include the IPv6 protocol and new IPv4 and IPv6 routing tables. This specification provides industry standard measures of the forwarding performance of network processing systems with native IPv4, native IPv6 and mixed IPv4/IPv6 traffic. IPv4 routing tables featuring 10k, 120k and 1M routes are included as are IPv6 routing tables of 400 and 1.2k routes The IA details the terminology, test configurations, benchmark tests, routing tables and reporting formats needed to measure and publish the forwarding performance of network processing based systems.

The tests are grouped into three categories: data plane tests, control plane tests, and concurrent data plane and control plane tests. The data plane tests include measures of the aggregate forwarding rate, throughput, latency, loss ratio, overload forwarding rate, and system power consumption. Different traffic combinations are used including 100 percent native IPv4, 50 percent IPv4/50 percent IPv6, and 100 percent IPv6. The control plane tests include measures of forwarding table update rates. Lastly, the concurrent data plane and control plane tests include measures of concurrent forwarding table updates on the forwarding rate.

[Return to top]

MPLS Application Level Benchmark (January 2003) -
The MPLS IA defines a methodology to obtain network processor MPLS application level benchmarks and describes the tests used to obtain MPLS performance metrics in Ingress, Egress and Transit configurations. It includes an Annex that describes a reference implementation of the benchmark, outlines the traffic streams required to run the benchmark tests, and provides the references and descriptions associated with the benchmark routing tables. An associated MPLS reporting template presents a sample report. This IA establishes consistent and objective measurement criteria that accurately assess the MPLS performance of Network processing products.

[Return to top]

IPv4 Forwarding Benchmark (July 2002) -
The IPv4 Forwarding Benchmark IA details the interfaces, configuration parameters, test set-up and execution details, including traffic mix and routing table contents, needed to measure the IPv4 forwarding performance of NPU-based systems. The IPv4 interface takes the methodology defined for network equipment by the IETF (RFC2544) and adapts it in a new framework that targets the NPU subsystem. Using a consistent methodology, it enables easy comparison between NP-based systems with widely varying architectures. Design engineers will now be able to assess and compare, in an open, objective, and reproducible way, the IPv4 forwarding performance of NP-based devices. The features of this benchmark have been incorporated into the more general IP Forwarding Benchmark (June 2003).

[Return to top]