Telecoms.com periodically invites expert third parties to share their views on the industry’s most pressing issues. In this post Charlie Ashton, Senior Director of Business Development at Wind River, explores the importance of ‘openness’ in the effective deployment of NFV.

Exponential growth in data traffic such as from video streaming as well as the expansion of new connections for the Internet of Things (IoT) means there is an ever-larger challenge for service providers to handle the massively increasing demand for bandwidth. In addition, service providers are looking at ways to reduce their capital and operating expenses while also deploying the new services that will generate future revenue streams.

Historically, the telecommunications network infrastructure has been based upon proprietary software running on dedicated single-function and purpose-built hardware. Now, however, telecom carriers and network service providers are looking toward NFV to modernize and transform their networks. The primary concept of NFV is to design, deploy and manage services by decoupling network functions from their underlying proprietary hardware, thereby virtualizing multiple applications or network functions and running them in software on standard server platforms, while also enabling the scalability of applications.

Importantly, one of the critical requirements to deploy NFV effectively is ‘openness.’ Open and/or interoperable solutions can significantly increase the number of software suppliers, which increases innovation, and using an open strategy means that TEMs can develop new solutions faster, while potentially lowering development costs.

OPNFV

Launched in September 2014, the Open Platform for NFV (OPNFV) project is an open-source reference platform intended to accelerate the introduction of NFV solutions and services. OPNFV operates under the Linux Foundation with its primary goal being to implement the ETSI specifications for NFV. Wind River is a highly active member company of OPNFV, along with major telecom and cable service providers and many NFV application software vendors.

Two of the fundamental concepts for the OPNFV project (see figure 1) are: collaboration between companies operating throughout the NFV ecosystem in an open-source environment, which should result in high-quality reference software that can be incorporated into commercial solutions; and solutions leveraging OPNFV code that will then be made available to the market significantly faster than those developed either from the ground-up or those that begun in enterprise projects. An overview of the OPNFV platform is shown in figure 1.

The OPNFV project has its initial focus on NFV Infrastructure (NFVI) and Virtualized Infrastructure Management (VIM) software. This can be implemented by integrating components from various projects including: OpenDaylight, OpenStack, Ceph Storage, KVM, Open vSwitch and Linux. Along with APIs (Application Programmable Interfaces), the NFVI and VIM software components will form the basic infrastructure required for hosting Virtualized Network Functions (VNF) and interfacing to Management and Network Orchestration (MANO). The primary beneficiaries of OPNFV are expected to be telecom service providers, but it will also benefit VNF software developers with standardized interfaces, which promotes portability and interoperability.

The first OPNFV release became available in June 2015. Codenamed ‘Arno,’ the release includes NFVI and VIM components and is very focused upon VNF developers. The combination also offers the ability to deploy and connect VNFs in a cloud architecture based on OpenStack and OpenDaylight. The second release, codenamed ‘Brahmaputra’, was the first ‘lab-ready’ release. It incorporates numerous enhancements in areas such as installation, installable artifacts, continuous integration, improved documentation and sample test scenarios.

Challenges

A recent independent survey (conducted by Telecom TV) asked TEMs, CSPs and software vendors what considerations were most important when deploying NFV in a commercial network. The upshot from the survey was that the two most important considerations were interoperable solutions from multiple vendors and the requirement for carrier-grade availability and reliability.

To ensure solutions are interoperable with those from others, NFV vendors need to be fully aware of the NFV standards that have been defined by the ETSI initiative, as compatibility is increasingly about demonstrating interoperability with other companies in the NFV ecosystem. Although open standards avoid the risk of vendor lock-on by encouraging the development of compatible and interoperable solutions from multiple companies, service providers will typically incorporate products from more than one vendor in the complete deployable solution. This means that service providers will require proof that products will work together seamlessly.

Looking at the second point – providing carrier-grade availability and reliability is a significant issue. The industry requires OPNFV to be based on open source. However, the open-source community does not yet have all of the high availability and performance capabilities that are necessary for a carrier-grade platform, delivering the necessary minimum five nines (99.999%) or six nines (99.9999%) of uptime. NFV implementations will require carrier-grade virtualization software to deliver real-time traffic capability, as well as scalability to handle billions of newly connected devices and generation of increasing amounts of data traffic.

Performance, scalability, and security requirements are more stringent for virtual switching in a carrier network. For example, the Open vSwitch (OVS) currently has design limitations that result in inferior scalability and performance efficiency. Furthermore, neither Arno nor Brahmaputra releases incorporate any features that contribute to delivering carrier grade reliability in the NFVI platform.

A third key issue is that there is an industry need for flexibility and differentiation in platforms, in terms of meeting carrier grade requirements and performance and not just the requirements of the NFV application. Vendor-specific software will sometimes be superior to, or provide features not available in, open source software. Proprietary software can therefore provide service providers and TEMs with competitive advantage.

Hybrid Approach

In summary, it should be clear that there are many advantages of ensuring de facto open standards for NFV. OPNFV provides high-quality reference software that can be incorporated into commercial solutions; it also means that solutions leveraging OPNFV can be made available to the market significantly faster. However, in general, enterprise server and computing technologies based on 100% open-source solutions are not designed to meet the rigorous demands of carrier networks. The open-source community simply does not have all of the high availability and performance capabilities necessary for carrier grade.

In addition, it is important that there is a capability for TEMs and CSPs to differentiate their platforms. All of this means the optimum solution must be a hybrid approach based on OPNFV/ETSI open standards and specifications, while also taking the best from vendor-specific solutions to promote innovation in the market. When choosing NFV solutions, TEMs and CSPs seriously need to consider those software vendors that embed this hybrid approach in their NFV product offerings.

In an ideal world, what is required is a VNF-ready NFV platform that includes industry-leading hardware and software products that have been pre-integrated, validated and are 100% compliant with all relevant API standards such as ETSI MANO, OpenStack and KVM. It should also employ an open ‘plug-in’ architecture for OpenStack to support the interoperability of standard open-source components and API-compliant custom software.

On this point, ideally this platform should also come from a vendor that is part of the ETSI NFV initiative and has helped to define and shape the specifications. In addition, the platform also has to address the necessary performance requirements demanded by telecom carrier-grade switching in key areas that are not met by open-standard based solutions such as the Open vSwitch (OVS). Also, proprietary products that address the limitations of OVS, while providing higher scalability and performance efficiency also need to negate the possibilities of vendor lock-in and deliver openness via the use of APIs and OpenStack for example to provide the required level of abstraction.

Software vendors that can build upon the fundamentals of ‘the open’ with the levels of performance delivered by ‘the proprietary’ are the ones that can enable CSPs and TEMs to deliver the next generation of open high-performance NFV networks and systems.

Charlie Ashton is an accomplished marketing and business development executive with extensive experience in the embedded systems industry. At Wind River, Charlie is responsible for business development activities for the networking and telecommunications industries. A prolific writer and commentator, his frequent blog posts and trade articles can be found throughout the embedded and software communities’ literature.