)
At the Paris Summit, Akhila Chetlapalle and Partha Pratim Datta, from Tata Consultancy Services, discussed the NFV Orchestration framework they are contributing to OpenStack. They’ve been building solutions in NFV Orchestration since OpenStack’s Grizzly release and have evolved their solutions as they identified and addressed issues.
For background, consumers of NFV are mostly service providers and telecoms that want to speed up the deployment of new network services by getting rid of slow renewal cycles of hardware appliances. With NFV, they can deploy services rapidly because of virtualization and automation, and they can also reduce capital expenditure because organizations have full hardware instead of specific hardware for specific network functions. In addition, organizations want the advantage of scalability depending on demand, rather than pre-planning and provisioning beforehand.
While we all want the benefits of NFV, Chetlapalle said getting them can often be a long journey.
“We are used to a stable system and ecosystem which has been proven, and we’re trying to get into a space where things are pretty uncertain and new.”
For this session, they discussed the architecture changes that they’ve made to OpenStack NFV, the current features they’ve implemented, and looked ahead to the next road map features they’d like to contribute to OpenStack.
First Attempt
When Chetlapalle and her team built their first solution, there was no firewall API in OpenStack. In those early days, the typical way to achieve the solution was to build agents and plugins to achieve the orchestration. So they wrote their own firewall API.
Their solution had a firewall agent running on every compute host. However, they needed their firewall agent to interface with the virtual network function over the NETCONF interface. Thus, they built a standard API to interface with the NVF.
Everything looked pretty good until they put the solution through their test framework.
It didn’t scale to their expectations. They saw bottlenecks everywhere. Their firewall agenda was consuming lots of resources monitoring and communicating with the OpenStack controller.
Second Attempt
They began to build their next solution to address the limitations discovered in their first attempt. They used OpenContrail to help with VNF orchestration. They added a VNF catalog and a VNF manager — all made possible through OpenContrail, and config and control components.
Furthermore, they enhanced the config component to be able to handle API firewall orchestration requests. They also built a south-bound plug-in based on Netcon so they could configure their firewall.
The team was glad to see this solution scaled pretty well. They tested it in an emulated environment for the number of VNFs that it can handle or what happens when you try to bring down any VNF, and how quickly the system can respond. Overall the results of the second solution were quite good.
However, provisioning was an issue. Every time a user was looking to deploy a firewall, the administrator had to do that for the user.
Shortly after this second solution, the ETSI Specification came into picture.
Latest Solution
The team’s latest solution is built on the Juno release and is based on the ETSI specifications and the Tacker API in OpenStack. In addition, they used the SCVCM API in order to be able to orchestrate the firewall.
Here’s how it works:
Orchestration is divided into two parts. The first part where the firewall itself is created, and the second where the administrator creates the device and maps to a user’s interface. The tenant has the flexibility to configure policies and rules on this firewall. And the team ensured that whatever configuration they want to provision, it can be done through heat templates.
In the current solution, there is just one VNF manager, no agents, and they’ve created a management interface on the firewall through which one can push the policies or the configuration onto the firewall.
In the ideal scenario, a firewall is created with just the management interface and in order to provision more logical instances on that, or when the tenant requests to provide them with the firewall, it is possible to dynamically add the interfaces.
Next, they showed the typical flow that happens when trying to provision a VNF, based on the ETSI specification.
The VNF manager is pre-configured with the templates for all the functions that it is supposed to handle. When a request comes for instantiating a VNF, the user makes the required validations. However, not all VNFs can be managed with a single VNF manager. Thus, they separated functionality into two buckets. In the first bucket is generic functionality common for most of the VNFs. The second kind of functionality is more specific, configured functions that talk directly to the VNF.
To create a device, the infrastructure manager creates the VNF, and the VNF manager translates whatever information it has into a Nova boot call. This includes adding a management interface — one interface in the management network to the virtual network function — and the rest of the dummy interfaces. Then when services are provided to a tenant, the system only maps the network interfaces onto the device that has already been created. This prevents the solution from spawning virtual machines every time a tenant requests the creation of a firewall.
Next Steps — Roadmap features to be supported
Chetlapalle acknowledged that even with all the progress made, there are some gaps in making this a full fledged solution. Specifically, areas that need development are:
- Scheduling
- High Availability
- Policy Driven Orchestration
- Scaling
These challenges are distributed across the different components of the solution, and are what they are trying to address in the subsequent work.
Watch the full talk from the Paris Summit here:
- Exploring the Open Infrastructure Blueprint: Huawei Dual Engine - September 25, 2024
- Open Infrastructure Blueprint: Atmosphere Deep Dive - September 18, 2024
- Datacomm’s Success Story: Launching A New Data Center Seamlessly With FishOS - September 12, 2024
