At NFV Plugtests hosted by ETSI last week, the Open Source MANO (OSM) group tested its code for interoperability with various network function virtualization (NFV) infrastructures and virtual network functions (VNFs).

Participants at the Plugtests were provided with different combinations of VNFs, NFV infrastructures, and orchestrators, and they were given about an hour-and-a-half to make it all interoperate. OSM’s orchestrator software interoperated successfully with all 10 of the NFV infrastructures and all of the 15 “official” VNFs (5 additional VNFs were considered “test” VNFs).

“We are on track for production ready,” says Francisco Javier Ramón Salguero, the chair of OSM.

The open source group’s goal is to deliver a management and network orchestration (MANO) stack that is openly public and can be implemented across different technologies. OSM aims to support use cases in telco networks as well as other networks run by enterprises.

The core of OSM’s work revolves around its information model. OSM’s code helps feed the VNF into the system, working with various infrastructures and whatever is necessary for the service provider to expose.

“You can do it in a manner that is consistent across use cases and not focused on fixed lines or mobile core,” says Ramón.

ETSI's NFV Diagram

The European Telecommunication Standards Institute (ETSI), which hosts OSM, kicked off MANO work with its framework issued in 2014. But open source and standards work has since become much richer than what’s reflected in that diagram.

“The full picture is much more complicated,” says Ramón. “The diagram is useful, but it only has two dimensions. It does not reflect supporting several VIMs [virtual infrastructure managers] simultaneously.”

For instance, networks have infrastructure in different locations. “You need to feed each of those infrastructures with the right type of comments for how to do something that has been asked by the information model and then stitch it across the infrastructures,” he says.

In addition, a VNF may traverse other networks. “Our objective is to interoperate with different types of controllers,” says Ramón. “We are not trying to equalize all the VIMs.”

OSM’s information model will also work with a plethora of VNFs from different vendors. “You create a file with all that information, and the system does what it needs to do. The information about VNF 1 is probably different than for VNF 2,” he says. “They will have commonalities; we are aggregating all that information.”

Finally, OSM’s information model must aid service providers in tying the VNFs into their back-office system. OSM’s code tells service providers how to assemble things together.

OSM Is Happy With Its Scope

Although others — Open-O and ECOMP — are working on MANO code, the contributors to OSM aren’t bothered by that.

“We are exactly where we wanted to be,” says Ramón. “We are in the center and doing all the things we wanted to do in our objective. Others might need to explain their value.”

And while Open-O and ECOMP both claim that their scopes are broad, he says, “To say we don’t do lifecycle services orchestration is simply wrong. We are doing LSO.”

OSM issued its Release One code in October 2016 and plans to issue Release Two in a couple of months. The group now counts 55 members.