OpenStack in 2019: Steady Progress and New Directions
by Curtis Collicutt on May 28, 2019
Predictions for Edge Computing in 2019
by Curtis Collicutt on March 12, 2019
Kubernetes Persistent Volumes with NetApp Trident
by Curtis Collicutt on February 11, 2019
Layer 1 SFC with BigSwitch
by Curtis Collicutt on February 4, 2019
100,000 Carrier Clouds Coming Online
by Curtis Collicutt on January 28, 2019
OpenBaton is an open source MANO that has most, if not all of the required features of a MANO system, and yet it is quite different in size, scope, and community when compared to a project like ONAP.
Currently OpenBaton is used by the OPNFV project as part of its software collection that is utilized for the purposes of integration testing. As of the Euphrates release, OpenBaton is used as the MANO system, and in the image below we can see that the MANO system sits above and oversees a large part of the underlying NFV system.
OpenBaton is a relatively small project that is supported by European Union public funds. Ultimately what is great about OpenBaton is that it has some interesting features and concepts that are more easily understood and conceptualized when compared against other MANO solutions, which typically are large and (overly?) complex pieces of software that grow over time to subsume almost all functionality of a complete NFV solution. For many MANO systems, everything but the VIM and NFVi are essentially fair game. This is somewhat problematic in terms of things like lock-in.
OpenBaton, which is small in size and complexity, is refreshing in terms of its ease of deployment, and it is obvious why OPNFV chose it as part of its integration testing (of course the fact that ONAP is not completely finished yet also enters the equation). Given that OPNFV is performing continuous integration testing, in order to keep the amount of time for each test low it’s important that components of that testing be fairly light weight.
As mentioned, OpenBaton comes with some interesting features and components:
OpenBaton is relatively lightweight. It is quite possible to run all of OpenBaton on a virtual machine with just 8GB of memory. Currently ONAP, and many other commercial solutions, require 5 to 10 times the resources of OpenBaton, if not more.
Some type of centralized store of Virtual Network Function (VNF) definitions and Network Service Definitions will be required in any large NFV system. Currently in OpenBaton the Marketplace is used to more easily provide example VNFs, but at some point it should be possible for operators to deploy their own marketplaces.
When entering information for a Point of Presence (or perhaps more simply, a VIM) one can also enter Longitude and Latitude details. This is an important point because many NFV systems will have hundreds, maybe even thousands, of PoPs. Geographic location will play a major part in where and how VNFs and Network Services are deployed.
In the image below the form for entering a new PoP is shown, and there are inputs for latitude and longitude. The physical location, as well as other various parameters such as available resources, latency, etc, will be extremely important to the automated provisioning of network services.
Autoscaling is an important part of any “cloud native” solution. Elasticity is a requirement in modern deployment scenarios, and thus OpenBaton supports that functionality with an autoscaling service. Currently there is a Zabbix based plugin provided by OpenBaton.
Network slicing is an important feature that 5G systems will likely require. Network slicing can mean a lot of things, but in short it is QoS–quality of service.
Network slicing allows operators to segment the network to support particular services and deploy multiple logical networks for different service types over one common infrastructure. – Ericsson
Using QoS technologies we can implement varying compartmentalized network resources with the same underlying infrastructure. Certainly there are those that do not believe QoS is truly possible, but as someone who has run a public cloud based on OpenStack, I can tell you it is important and possible, even if it just stays within the VIM.
Currently OpenBaton only supports Network Slicing using OpenStack Neutron’s QoS.
OpenBaton also supports two VNF packaging methods:
Most MANO systems will also support these VNF packages and thus potentially OpenBaton could be used in an end-to-end CI testing framework, with VNF packages eventually loaded into other environments utilizing differing MANO solutions.
OpenBaton can be used in situations where a lightweight MANO is beneficial. Also, because of its smaller size and codebase it may be a good place to perform research and development and create proof of concept systems by implementing new services and plugins.
Ultimately OpenBaton is a small project that does not have anywhere near the community support that something like ONAP has. Neither is OpenBaton meant for production use. However, it is important to have other options and implementations of NFV systems such as the MANO tier in order to develop ecosystem diversity.