I came across few recent Opensource projects which I found them to be interesting. In this blog, I will cover some details on OPNFV, Openconfig, ONOS. There is no relation between the 3 projects, the common thing is all the 3 projects are focussed on Networking and Cloud and all are relatively new.
OPNFV is an Opensource project under Linux foundation. The goal is to create a Opensource reference platform for developing NFV applications. In 1 of my earlier blogs on NFV, I covered overview of NFV and the ETSI NFV model. The goal of the OPNFV project is to create a reference implementation using the model proposed by ETSI. OPNFV’s plan is to leverage the work done in other Opensource projects like Openstack, Opendaylight, Openvswitch, KVM, Linux kernel, DPDK. Even though OPNFV can work with other Cloud OS and SDN controllers, the goal for the first release is to use the most popular Cloud OS, SDN controller and hypervisor mentioned above. Following picture from OPNFV illustrates the blocks that OPNFV will focus on from ETSI NFV reference model.
As can be seen, the initial goal is to focus on the Infrastructure layer.
Following picture shows the layers of Opensource software that OPNFV is planning to use.
OPNFV wiki lists the initial set of projects that OPNFV will focus on. The uniqueness of OPNFV is that the software will utilize multiple other Open source projects and the software bundle will be a collection of software. Also, lot of the projects under OPNFV will be additions to existing Opensource projects and OPNFV will drive these projects. The projects are classified into following areas, I have also put the projects that I saw in the wiki.
- Requirements – Policy requirements(Openstack/ODL), Resource management for future resources (Openstack), Fault monitoring(Openstack), VNF HA
- Collaboration – Openstack disaster recovery, DPDK performance monitoring, Telecom data model
- Integration and testing
Initial software for download is planned early 2015.
Openconfig is not actually an Opensource project. It is currently a closed group project with members like Google, Microsoft, AT&T, and BT Group focussed on building an open, vendor-neutral model for network configuration and policy. I have covered Netconf, Yang, Network automation, Cloud policy in my previous blogs which would help to get more context on Openconfig project. There is limited documentation on Openconfig, this is what I understood:
- Once Network device configuration can be expressed in a modeling language, it should be possible to configure any network device as long as they adhere to the model. The initial plan for Openconfig is to stick to Yang model.
- Use a declarative policy model where the Operator tells the network what to do rather than how to do.
- Extend configuration to all layers of the protocol stack.
- Openconfig group has published a BGP configuration model for configuring BGP using Yang. This gives a good example of how other protocol and device configuration can also be modeled.
ONOS is a project initially developed by ON.lab along with few major Service providers. Based on what I see in their website, the plan is to opensource the project from December 5, 2014. ONOS calls it a SDN Operating system targeted for Service providers. Following is the architecture block diagram that I got from their whitepaper.
- Adapter layer is the abstraction layer that hides the southbound protocols from the api needed for the core. Southbound protocols can be Openflow, Netconf.
- Northbound api can either directly be api or could be an intent based on policy.
- The core layer contains all intelligence that’s needed to maintain the Network state. ONOS claims the following differentiators: distributed core to achieve scale and HA, policy based northbound api, support for different southbound protocols and modular software.
I see a lot of similarities between Opendaylight project and ONOS. Adapter layer of ONOS is equivalent to SAL layer of ODL, Intent based api of ONOS is equivalent to ODL Group based policy, Distributed core is similar to ODL Clustering feature in Helium release. Its not clear to me if there is room to have multiple Opensource SDN controllers, but choice is always good.