Last month we published a post titled “Will OPNFV become the de facto standard for NFV compatibility?”, in which we discussed how to demonstrate compatibility with NFV’s open standards while also asking whether the Open Platform for NFV (OPNFV) project will become the de facto standard against which vendors’ solutions are measured.
A couple of weeks later, I had a conversation with an Engineering Director at one of our customers who felt that he was facing a dilemma in terms of his product strategy. He was clearly concerned that management pressure to develop NFV solutions completely based on open-source software would limit his ability to be early to market with his next product, while at the same time constraining his options for adding value through differentiation.
This post will summarize the discussion that I had with this customer and explain why adopting open-source platforms by no means prevents you from beating your competitors to market with highly differentiated solutions. As long as you select the right platform of course.
First, it’s important to acknowledge that our customer had a very valid concern about the schedule for the acceptance of code into open-source communities in general. And even though the OPNFV project is new, we certainly expect the normal open-source patterns to apply. Wind River is one of several companies contributing code to OPNFV, both directly in certain workgroups and indirectly through the various upstream projects which comprise the overall initiative. We believe that it will take at least a year for our submissions to vetted, reviewed and debated before being accepted by the maintainers, subsequently becoming part of a new version that’s actually released anywhere up to two years after we made the initial contribution.
At least this is better than the situation with OpenStack. Since OpenStack is primarily focused on enterprise applications, we find that many of our telecom-based submissions never get accepted into the mainline distribution at all. This prevents other OpenStack users from automatically benefitting from these patches and means that we have to continue maintaining them indefinitely. But with OPNFV being completely focused on network virtualization, our expectation is that the majority of contributions that add real value to the standard platform will be accepted in due course and thereby become generally available to the community.
At Wind River, our Titanium Server NFV Infrastructure (NFVI) platform is based on open-source projects such as Carrier Grade Linux, KVM, OpenStack, Ceph Storage and Intel® DPDK. Our team therefore has extensive, proven experience in adding critical telecom features to all components of the OPNFV platform, while at the same time maintaining 100% compatibility with the relevant NFV standards, originally specified by the ETSI Industry Specification Group (ISG) and now being augmented by the OPNFV initiative.
Our experts are frequent contributors to all these open-source projects. In addition to upstreaming hardened versions of a wide range of Open Stack and Linux components, we recently published the source code for the Accelerated Virtual Port (AVP) Kernel Loadable Module (KLM) and DPDK Poll Mode Driver (PMD) that allow developers to fully leverage the Accelerated vSwitch in Titanium Server. This code is available at no charge from our open-source repository and we recently published a post that explains the benefits it provides.
Wind River has also participated actively in both ETSI and OPNFV since the inception of each of these initiatives. On the ETSI front, we contributed to the MANO and RELAV specs in Phase 1 and more recently the new IFA Acceleration Use Cases spec being developed in Phase 2.
Fortunately, you can benefit from the telecom-focused bug fixes, patches and enhancements that we submit to open-source projects without waiting for them to be accepted and incorporated into future releases. They’re all available today in Titanium Server. In fact Titanium Server allows us to verify that the enhancements we develop do in fact address important problems for our customers, so that we can ensure we’re upstreaming code with proven value. And as we continue to develop enhancements that provide additional security, reliability and performance features, we’ll follow the same process of verifying them with our customers and then submitting them to the appropriate project.
So if you’d like to take advantage of our open-source patches, knowing that they’re fully-compatible with the ETSI and OPNFV patches, you have a couple of options:
If you prefer to integrate and maintain your own NFVI platform based on open-source software, you can wait for our patches to be accepted by the community and then receive them automatically as part of the next open-source release. That probably takes one to two years, likely quicker for OPNFV and slower for OpenStack which focuses on enterprise applications. Then once you have the open-source code you can start integrating, verifying and productizing your own NFVI platform. Based on our experience, that takes a couple more years. So you’ll actually be deploying your Roll-Your-Own NFVI platform, incorporating the patches that we released recently, in 2018 or 2019.
Of course there’s a faster option. Give us a call today, we’ll have our experts chat with you tomorrow and you could have your own copy of Titanium Server in your lab in a few days. That’s the approach that our current customers have taken and that’s why they’re successfully bringing solutions to market early that are fully-compatible with all the appropriate open standards, while leveraging VNFs, orchestration solutions and servers from our Titanium Cloud ecosystem partners.
Disruptive technology changes like NFV represent a rare opportunity for aggressive companies to grab market share from their competitors, thereby growing revenues and increasing their profitability. Solutions like Titanium Server, fully compatible with all the relevant open standards, allow our customers to achieve that boost to their business while leveraging open-source solutions and avoiding any risk of vendor lock-in.