Will OPNFV become the de facto standard for NFV compatibility?

As Network Functions Virtualization (NFV) takes its first steps beyond trials and evaluations into real-world deployments, suppliers throughout the value chain are wrestling with how to demonstrate the elusive concept of “compatibility”. For our team at Wind River, this has certainly been a critical question to address while seeing our Titanium Server NFV infrastructure platform adopted by multiple customers for a wide range of use cases.

In this post, we’ll discuss some of the approaches that have been successful for us in terms of proving compatibility with NFV’s open standards. We’ll also explore whether the emerging Open Platform for NFV (OPNFV) project will in fact become the de facto standard against which vendors’ solutions are measured.

First, a quick background on OPNFV for anyone that hasn’t followed this open-source project closely. Formally launched in September 2014, the OPNFV project is an open source reference platform intended to accelerate the introduction of NFV solutions and services. OPNFV operates under the Linux Foundation and the primary goal of the project is to implement the ETSI specification for NFV. Members include telecom and cable service providers such as AT&T, CenturyLink, China Mobile, KT, NEC, NTT DOCOMO, Ooreedo, Orange, SK Telecom, Sprint, Telecom Italia and Vodafone. A number of NFV solution vendors are also members. At Wind River, the decision to join OPNFV and actively contribute was a no-brainer, given our existing participation in several open-source communities and our focus on delivering NFV solutions aligned with open standards.

The fact that so many service providers have joined OPNFV is a strong indication of the potential benefits that they see from the project. Several have been quoted publicly as confirming that they see the OPNFV reference platform as a way to accelerate the transition from the standards established by ETSI to actual NFV deployments. They believe that collaboration by companies throughout the NFV ecosystem, in an open-source environment, will result in high-quality reference software that can quickly be incorporated into commercial solutions. They expect that solutions leveraging OPNFV code will available in the market significantly faster than those developed from ground-up or those that start from enterprise projects. Of course they recognize that OPNFV code can’t be directly deployed into live networks, anticipating that software companies will use OPNFV as the baseline for commercial solutions with full Service level Agreement (SLA) support.

OPNFV’s initial focus is NFV Infrastructure (NFVI) and Virtualized Infrastructure Management (VIM) software, implemented by integrating components from upstream projects such as OpenDaylight, OpenStack, Ceph Storage, KVM, Open vSwitch and Linux. Along with application programmable interfaces (APIs) to other NFV elements, these NFVI and VIM components form the basic infrastructure required for hosting Virtualized Network Functions (VNF) and interfacing to Management and Network Orchestration (MANO).

The first OPNFV release “Arno” became available in June. Arno is a developer-focused release that includes the NFVI and VIM components. The combination offers the ability to deploy and connect VNFs in a cloud architecture based on OpenStack and OpenDaylight. The next release “Brahmaputra” is planned as the first “lab-ready” release, incorporating numerous enhancements in areas such as installation, installable artifacts, continuous integration, improved documentation and sample test scenarios.

It’s worth noting that neither Arno nor Brahmaputra incorporate any features that contribute to delivering Carrier Grade reliability in the NFVI platform. This is an example of an area where a company like Wind River, with extensive experience in delivering six-nines (99.9999%) infrastructure, continues to add critical value. Solutions such as Titanium Server build on community-driven reference code and enhance it with functionality that is an absolute requirement for platforms deployed in live service provider networks, while remaining fully compatible with all the applicable open standards.

So what does it mean for an NFV solution to be “fully compatible” in this context? Our experience since launching Titanium Server has been that we need to address this question from three angles:

First and perhaps most obvious, it’s important for any NFV vendor to be fully aware of the NFV standards that have been defined by the ETSI initiative, and that continue to evolve during phase 2. Beyond just understanding the standards though, our experts have participated extensively in working groups where our experience of Carrier Grade reliability, platform testing and VNF performance optimization have enabled us to make informed contributions to the definition of the standards.

Second, we find that the “compatibility” challenge is increasingly about demonstrating interoperability with other companies in the NFV ecosystem. From the service providers’ point of view, open standards avoid the risk of vendor lock-on by encouraging the development of compatible and interoperable solutions by multiple companies. But service providers typically incorporate products from more than one vendor in the complete solution that they deploy, so they need proof that products that should work together seamlessly actually do so. In our case, we launched the Titanium Cloud ecosystem in accelerate NFV deployments and minimize our customers’ schedule risk. Through Titanium Cloud, we work closely with our partners at an engineering level to make sure that their products work correctly with Titanium Server, while leveraging whatever optimizations are appropriate to ensure Carrier Grade reliability and maximum performance. This is an in-depth, engineering-centric program that results in validated, end-to-end solutions, not just a logo chart or a marketing tool.

Finally, it’s interesting to consider what will happen once the OPNFV project results in a stable code base leveraged by multiple vendors to create NFV solutions. We would expect that at this point OPNFV becomes a de facto standard against which all NFV vendors will have to test their solutions. Companies providing VNFs, for example, will need to verify the correct operation of those VNFs when running on the basic OPNFV code, just as they also validate them on NFVI platforms like Titanium Server that are actually deployed by their customers.

So in the near future, we would expect that the verification of “compatibility” will actually involve three distinct activities. Companies will need to make sure they develop their products in full awareness of all the relevant ETSI standards, confirm that they run correctly on the OPNFV reference platform and also verify interoperability with ecosystem partners’ products that comprise a complete, deployable end-to-end solution.

From the perspective of the service providers who are actually deploying NFV-based services in their networks, the benefits of compatible, interoperable solutions are significant. Seeing proof that the various elements of their end-to-end solution have been pre-validated to work together correctly accelerates their overall deployment time, while also reducing their schedule risk and enabling their program managers to get a little more sleep at night.

At the same time, compliance with open standards compels vendors to develop solutions that are interoperable and replaceable. This is key to avoiding the vendor lock-in that existed in the “bad old days” of physical network infrastructure, which after all was one of the main motivations that drove service providers worldwide to collaborate on NFV in the first place.

At Wind River, we’re seeing widespread adoption of the Titanium Server NFV infrastructure platform because it solves critical business challenges for both TEMs and service providers. We’ve been active participants in the ETSI NFV initiative from Day 1, helping to define the specifications and ensuring that our solutions are fully compatible with these open standards. Through the Titanium Cloud ecosystem, we work with suppliers of OSS/BSS solutions, orchestrators, VNFs and server hardware to validate complete interoperability between our products and theirs. Now, as an active participant in OPNFV, we’re able to contribute high-value code to the community and leverage the OPNFV platform to provide our customers with Carrier Grade NFV infrastructure that’s ready to deploy and 100% compatible with open standards.