NPF Tackles Services API
LAS VEGAS -- Networld+Interop -- Network processor vendors say they've taken a critical step forward in standards with today's release of the Network Processing Forum's first application programming interface (API) for services, targeting unicast IPv4.
An API defines the nitty-gritty details of communicating with hardware or software, outlining the format of signals and the expected response to particular events. In the case of IPv4, the current iteration of the mainstream Internet Protocol, the NPF's work defines how to use any IPv4 protocol stack with any network processor. The hope is that this will speed up systems design by allowing OEMs to use an arbitrary network processor with their existing software and protocol stacks.
The NPF says this is the first of a series of APIs that target services and aren't just aimed at a specific type of hardware or software. The forum picked IPv4 because it's ubiquitous and stands as a prerequisite for other services. APIs are in the works for DiffServ, MPLS, and IPv6, and there's still a slate of software- and hardware-related APIs in the works.
The NPF was created in 2000, the marriage of two ad-hoc forums that were trying to develop network processor standards. A key goal is to create APIs and standards for hardware, software, services, and benchmarking -- all directed at making it easier for OEMs to embrace network processors.
The NPF uses a decentralized process, with separate API task forces working without a formal set of priorities or deadlines, making it hard to say which API will come out next. The NPF had been more aggressive at first, but its members are under the strain of layoffs and company closures, which pushes API work down in priority.
"It's hard to put a schedule behind this because we are a volunteer organization," says Chuck Sannipoli, an NPF board member and a vice president at IP Infusion Inc.
The NPF has hammered out some standards related to hardware and benchmarking, but progress has been slower in the services realm. That's partly because the services API work had to wait for the NPF's definition of a general software framework, which was completed last fall.
Future services APIs should move a bit faster, now that the NPF's done a run-through, Sannipoli says. "This helped us determine how the forum was going to support all the competing demands placed by platform vendors, by silicon vendors, and so on."
— Craig Matsumoto, Senior Editor, Light Reading