The Three Pillars of “Open” NFV Software

In retrospect, 2014 was the year when the topic of “openness” became part of any conversation about solutions for Network Functions Virtualization (NFV). Throughout industry conferences as well as at meetings of the ETSI NFV Industry Standards Group (ISG), it was clear that service providers see the availability of open solutions as key to their NFV plans. In this post, we’ll propose a definition of what “openness” actually means in this context and we’d welcome your feedback on our concept.

The emergence of the Open Platform for NFV (OPNFV) open-source project was a direct response to this need. While it’s a separate initiative from the ETSI NFV ISG, the objectives for OPNFV are heavily driven by service providers, who represent many of the most influential members of the project. Hosted by the Linux Foundation, OPNFV is a collaborative project to develop a high-availability, integrated, open source reference platform for NFV. Close cooperation is expected with other open source projects such as OpenStack, Open Daylight, KVM, DPDK and Open Data Plane (ODP).

For software companies developing solutions for NFV, it’s obviously important to understand exactly what is meant by “openness” in this context. When service providers and Telecom Equipment Manufacturers (TEMs) evaluate software suppliers, what criteria do they use to judge whether a solution is “open” or not?

From numerous conversations with our customers, we at Wind River have concluded that there are basically three elements to an Open Software solution. We like to think of them as three legs to a stool: remove just one and the stool falls down, along with your claims of openness.

First and maybe most obvious, service providers and TEMs expect that “Open Software” comes from a company that’s active in the open source community and a major contributor to the applicable open source projects. There’s no hiding from this one since it’s straightforward to determine the number of contributions made by a given company.

It’s worth noting, though, that the number of commits submitted to the community isn’t representative of the technical leadership provided in a a highly specialized area such as Carrier Grade reliability. The mainstream community is focused on enterprise data center applications, so commits focused on topics of narrow interest such as Carrier Grade take longer to be understood and accepted.

We see this delay when we submit OpenStack patches that are related to Carrier Grade behavior and performance, which we have developed as a result of our leadership position in telecom infrastructure. With most OpenStack usage being in enterprise applications, many of these telecom-related patches languish for a very long time before acceptance, even though they are critical for NFV infrastructure. The opposite is true with, for example, the hundreds of patches that we have submitted for the Yocto Linux project, which tend to be widely applicable and quickly accepted.

The second leg of the stool is Standard APIs. A key premise of NFV is that open standards will encourage and incentivize multiple software vendors to develop compatible, interoperable solutions. We’re already seeing many software companies introducing NFV solutions, some of whom were never able to compete in the traditional telecom infrastructure market dominated by proprietary, single-vendor integrated equipment. The open NFV standards developed by the ETSI ISG enable suppliers of OSS/BSS software, orchestration solutions, Virtual Network Functions (VNFs) and NFV infrastructure (NFVI) platforms to compete in this market as long as they comply with vendor-neutral APIs.

The ETSI NFV architecture provides plenty of opportunities for companies to deliver value-added features while remaining compatible with the standards. In case of our Titanium Server NFVI platform, for example, we provide a wide range of Carrier Grade and performance-oriented features that are implemented via OpenStack plug-ins. These are therefore available for use by the OSS/BSS, orchestrator and VNF’s, which can chose to leverage the advanced features to provide differentiation in their own products.

As the third leg of the “Open Software” stool, service providers and TEMs want to avoid vendor lock-in at the software component level. The standard APIs between levels of the ETSI architecture enable multi-vendor solutions and interoperability between, for example orchestrators and VNFs. It’s equally important for customers to avoid getting locked into integrated solutions that comprise a complete level of the architecture, so that they can incorporate their own proprietary components with unique differentiation.

The NVFI layer provides a good example. In our case, we find many customers who see enormous value in our pre-integrated Titanium Server solution that combines multiple components into a single, integrated package: Carrier Grade Linux, hardened KVM, an accelerated vSwitch, Carrier Grade OpenStack and a wealth of telecom-specific middleware functions. Those customers benefit enormously from the time-to-market advantage of an integrated solution and the guaranteed six-nines (99.9999%) availability that it provides. They are able to leverage leading-edge capabilities. Other customers, though, may have their own Linux distribution or their own version of OpenStack and we can accommodate them in combining those components with ours, though potentially at the expense of Carrier Grade reliability.

So our customer discussions have led us to conclude that, for NFV, an “Open Software” company is one that is a major contributor to the relevant open-source projects, that delivers products 100% compatible with the open ETSI standards and that allows customers to avoid vendor lock-in at the component level. With those three legs in place, the stool stands and you have a viable source of open software.

What do you think? Do you have a better definition? We’d be pleased to hear your thoughts.