OPNFV: Systems integration for NFV as a community effort

Can OPNFV (Open Platform for Network Function Virtualization) become the base infrastructure layer for running virtual network functions, much like Linux is the base operating system for a large number of network devices?

The first step has been taken: “Arno” – the first release of the OPNFV project came out today. What does it provide – and, more importantly, what’s in it for you?

Virtual network functions (VNF) like virtual routers, virtual firewalls, virtual web security appliances, etc. require a base infrastructure to run on – the NFV infrastructure. For this at a minimum, you need a combination of a hypervisor, a virtual forwarder to connect individual VNF instances, a network controller to control all of the virtual forwarders the physical network, and a VM manager to lifecycle-manage the VNFs.

Most, if not all, of the individual components you need to piece together the infrastructure to run VNFs are in existence today. Many individual NFV infrastructure components are built and developed by a series of community-driven open source projects, like, for example KVM, OpenVSwitch, OpenDaylight, and OpenStack. But a collection of individual components does not automatically give you a working system. Creating a NFV infrastructure means creating a whole that is greater than sum of the parts. Or, put simply, creating a working NFV infrastructure layer translates into a systems integration effort.

While the individual NFV infrastructure components are all created in open community efforts, the actual integration has so far remained a “private” task. You either had to do it yourself, contract someone to do it for you, or buy a readily integrated system from some vendor. On top of that, the systems integration effort isn’t a one-time task. Virtualization is a quickly evolving technology area. Every other month new revisions or alternate options of components become available, requiring an ongoing evaluation and additional investment into systems integration to maintain the NFV infrastructure layer.

OPNFV set out to change this by turning this ongoing integration effort from a private task into an open community task. With OPNFV, the goal is to do it once, in the open, for everyone – NFV infrastructure as a commodity.  If successful, OPNFV will provide for NFV infrastructure what Linux provides so well for network elements today: a base operating environment which is common across vendors and deployments enabling you to run the set of functions you require for your service.

With this background in mind, it is no surprise that the first release, Arno, focuses on getting the infrastructure in place to allow for continuous integration, test, and enhancement of NFV infrastructure components as an automated system. OPNFV continuously and automatically retrieves a set of components from upstream projects (details on the target system state for Arno are found on the OPNFV wiki), integrates them, installs the system on a set of reference hardware, and runs a set of automated test suites against this reference deployment. Through OPNFV, developers who are active in upstream projects get their code tested at system level.

Even though for now the “Arno” release is a developer focused, experimental release with limited functionality, you can already leverage Arno and the OPNFV project in multiple ways. The diagram shows several ways to leverage and interact with OPNFV – even if you’re not contributing code:

“Run your VNF”

• Leverage OPNFV reference and community labs: Besides the OPNFV build and test environment, hosted by the Linux Foundation (which is based on Cisco UCS-B hardware), a series of OPNFV test labs are available to users to test-drive OPNFV and run their selected VNFs. Details on the existing community labs can be found on the “pharos wiki”.
• Continuously deploy OPNFV to your own lab: If you’re interested in continuously deploying OPNFV in your own lab, you can choose to hook your lab up to the OPNFV continuous integration infrastructure. Details on how to connect your Jenkins slave to the OPNFV Jenkins master can be found here. The current list of labs connected to the OPNFV master is found here.

“Add your component”

• Like any other open source system, you can choose to use OPNFV as a foundation that you customize for your own needs. Depending on your requirements, you could for example choose to switch one of the OPNFV components for your own one, e.g. replace the OpenDaylight controller with Cisco’s hardened version, the “Cisco Open SDN Controller”.

 “Your requirements reflected by OPNFV”

• OPNFV to reflect your test cases: By engaging with one of OPNFV test projects (e.g. the FuncTest project, which provides for functional testing) you could get your test cases generalized and included into the test suites that OPNFV continuously runs. From then on, your requirements, articulated through your test cases, will be part of every test run. And even if some of those tests cases might fail initially, tests are a good way to portray requirements and highlight required code changes to developers.
• Articulate your requirements: While tests are an indirect, though very efficient way to articulate requirements, OPNFV also provides for a direct way to articulate requirements: OPNFV requirements projects.

Interested in learning more about OPNFV? The OPNFV website and wiki provide a lot of additional information. Details on the first release are found on the Arno release website.
Or join me at CiscoLive in San Diego (June 7-11), attend my session “DEVZONE-0119: OPNFV – The foundation for running your virtual network functions” (Thursday at 12.30pm in DevNet Classroom 2) or visit the DevNet demo zone to see OPNFV at work – running CSR1000v. The Open Networking Summit in Santa Clara (June 14-18) is another great opportunity, where OPNFV will host a mini-summit.