The Open Platform for NFV (OPNFV) project is targeting "spring" for its first code release, called Arno, but that doesn't mean network functions virtualization (NFV) deployments are going to sprout like dandelions.

That's partly because Arno won't include all the pieces for a complete NFV architecture. The project is starting off modestly, as contributors told attendees at a Tuesday OPNFV workshop during the NFV World Congress taking place in San Jose, Calif., this week.

Arno has no specific release date, other than "as soon as we can," said Chris Price, an Ericsson manager and the head of the OPNFV technical steering committee.

The goal is for OPNFV to craft an NFV reference architecture that's as open as possible. The implementation would follow the template defined by the ETSI Industry Specifications Group (ISG) that defined NFV.

That's a lofty goal, so the OPNFV crew started with one key principle: Get something done. OPNFV members felt it crucial to not get bogged down in standards-like discussions.

After Arno comes out, it will be time to "dissipate, allow other projects to come forward," Price said, adding that "25-odd projects" are waiting behind that dam.

Arno, by contrast, is the product of one project, tellingly named Boostrap & Get Started (BGS). One of the first BGS decisions: Ignore management and orchestration.

Those pieces are vital to NFV — but they're also difficult, as they comprise the software to manage the creation and destruction of virtualized network functions (VNFs). If OPNFV tackled this first, it might never get to its first release, Price said — a joke, but he might actually be correct.

BGS also took time to contact upstream organizations — other open source projects that OPNFV will depend upon, such as the OpenStack Foundation and the Open Networking Foundation.

OPNFV also picked some starting blocks for its implementation:

  • OpenStack
  • OpenDaylight Helium as an SDN controller
  • KVM virtual machines
  • Ceph for storage

All of these pieces are replaceable, even OpenStack. The idea was simply to make some first-pass choices — again, as a way to get something done. Support for other SDN controllers and other types of storage systems would be welcome, Price said.

So OpenDaylight, for example, hasn't been picked as the OPNFV SDN controller. It's just that you've got to start somewhere.

OPNFV won't even define APIs for connecting SDN controllers, or any other upstream components, into the OPNFV architecture.

"We don't intend to try to build shim layers," Price said. "We do not have the right to dictate how the APIs should look. We do have the right to work with the upstream communities to find the best APIs for everybody."

To implement and validate code, OPNFV is creating a federation of labs. These will be set up so that they can be added to the federation with the push of a button; it's an automation-heavy design, very DevOps-like. Three labs exist now — hosted by Intel in Portland, Ore.; the Linux Foundation; and Ericsson — and more will come online later.

"Arno," by the way, is a river in Tuscany — and yes, the subsequent OPNFV release will be named after a river starting with "B," Price said.