 Hi, good evening everyone. Thanks for joining the presentation. I know the last three days has been quite hectic a lot of information has been coming through There's a lot of interactive sessions and discussions going on So what we would like to do today is go through the last presentation that we have as part of today's session Which is more about the NFV orchestration framework that we are contributing to OpenStack We will discuss what is the architecture change that we have done What are the current features that we have implemented as well as we'll try to see what are the next roadmap features that we have Where we like to collaborate or even submit into OpenStack a brief overview of who we are We are part of the Tata group the TTCS Tata consultative services We are a group which is in telecom practice What we do is we submit into open source contributions, which includes open stack Open Daylight and in the data plane for open VSwitch And I have with me my colleague Akhila who is an architect on OpenStack and with that I will hand it over to my architect who will walk you through today's presentation Over to you Akhila Good evening as Partha summarized what we are trying to present today is our journey in building Solutions on NFV orchestration with OpenStack as the base There are multiple options that we had tried out and these solutions have evolved one after the other The next one based on the issues that we have identified in the previous solution So we'll walk you through whatever we have done so far in the NFV orchestration space starting from the open stack grizzly to set the context we'll start with a A Background on NFV We know that the key drivers for NFV are reduced capital expenditure because you have full hardware now instead of specific hardware for specific network functions and You are able to deploy services rapidly because you have Virtualization and automation as the drivers which enable you to quickly deploy your services and You are also looking at scalability as an advantage and you are able to scale depending on the demand rather than pre-planning and Provisioning things well beforehand This is a good part of NFV. We all like the benefits, but how do we reach there? It is a long journey because we are used to a stable system an ecosystem which has been proven and we're trying to get into a space where Things are pretty uncertain new In order to get some clarity on how we should go about it What are the different aspects that you should consider? ETSI NFV ISG has come up with a reference architecture In this reference architecture, I mean it's a very good start point They identify the different areas that need to be focused on for us to reach the final goal of The NFV this is a high-level architecture for the whole ecosystem as such We have different components here Starting bottom up. We have the infrastructure itself where we are talking about hardware Which has which and the virtualization layer which enables you to create pools of virtual compute storage and network You have your virtual network functions running on top of this infrastructure and the traditional OSS and BSS systems Which help you manage And you also have a very interesting component, which is the NFV management and orchestration Framework which has three key components now This is the part that we are trying to focus on to build because as we saw earlier among the other things Automation is also a key to achieve rapid service delivery and you need to have Well-defined ecosystem to be able to automate things if we look a little bit deeper into the Mano Architecture, which is our focus. We see that we have NFV orchestrator which looks at the network services Orchestration of the services so when you have a request to provision say a VOLT kind of a service and If a component of that is something that you want to achieve with NFV your OSS systems request your orchestrator to provision that Service that is a granularity which the network service orchestrator looks at It has inputs in terms of the service catalogs as well as the network function catalogs Which define what is it that it can provide to the users either be the OSS or any other systems consuming its northbound It also interacts with the virtual infrastructure manager VIM where we typically position open stack To get an overview of what are the NFV I resources that it has at its dispense and what are the different Instances that it is trying to run on this infrastructure now the interfaces that that are Marked up for standardization as part of the specifications are indicated in bold lines And the dotted lines are some things that indicate that they are not in the scope of standardization at least in this first release So we are talking about interfacing between the network service orchestrator and the VNF manager as well as the VNF manager and the infrastructure manager and Also between the VNF manager and the virtual network functions themselves If you look at this a bit closely You will understand that a very critical role is played by the VNF manager component It is interfacing between the network service orchestrator and the lower layers where Infrastructure provisioning is happening. It is also talking to your VNF So we'll what we will focus on is how this can be achieved and how we have implemented this Solution in open stack using the tacker API, but before going there We have built solutions around achieving firewall as a service starting with open stack grizzly as the base So we'll walk you through the very first solution that we have built Yes When we built this solution, we really didn't have the firewall API in open stack, so we wrote our own API and At that point of time for people who are familiar with this release the typical way to achieve solutions was to build agents and plugins to achieve the orchestration and This solution typically follows that trend So we had built this solution with a firewall agent that runs on every compute host And because we wanted a standard API to interface with the VNF So that the solution can be used across multiple solutions the firewall agent also interfaces with the virtual network function over the net conf interface Now we built this solution. It was running fine And when we put this through our test framework what we realized was it really doesn't Scale to the expectations there are bottlenecks and there are resource consumptions going on I mean the resource consumption is high when you look at The firewall agent when it is trying to monitor or when it is trying to communicate with the open stack controller So with these limitations in mind the next solution that we looked at Yeah This is the next generation solution that we built We had used open contrail to help us with the VNF orchestration You can see that there is a VNF catalog and a VNF manager these are achieved through the open contrails config and control components We enhance the config component to be able to handle the firewall API firewall orchestration requests and the controller we have built a Southbound plug-in based on net conf so that you are able to configure the firewall this solution in Terms of scalability it scales pretty well. Of course, we have tested it in an emulated environment for the number of VNF's that it can handle or What happens when you try to bring down any VNF? How quickly does the system respond? So the results were quite good And there were no not many issues in this but after this is when the ETSI specification came into picture one One thing that we need to know about this solution and the previous one is it is the administrator Who's trying to provision the firewall as well as the policies? So every time you you are looking for deploying a firewall the administrator Will have to do that for you Moving to the next solution that we built on the latest Juno release Yes, this is something that is based on the attacker API in OpenStack What we have done here is we have built a separate component you have the SVC VM API in Which is not part of the main stream release in OpenStack But we have used the SVC VM API in order to be able to orchestrate the firewall Now this orchestration is divided into two parts the first thing where you create the firewall itself as a device as it is typically done in your In the environments where you have a physical device the administrator creates the device for you and he also maps your interfaces and The tenant has the flexibility to configure policies and rules on this firewall and We have ensured that whatever configuration we are trying to provision here. We are able to do it through heat templates so and I also have a demonstration for this which I might not be able to run right now But we are available in the design summit for the next two days So we can surely run it through for anyone who's interested in that and wants to have a deeper understanding of this solution So here we just have one VNF manager no agents and we create a management interface on the firewall through which we are trying to push the policies or the configuration onto the firewall and The ideal scenario is when you have a firewall created with just the management interface and when you want to provision more logical instances on that when the tenant requests you To provide them with a firewall you dynamically add the interfaces This hot plug functionality is available in the Linux latest Linux kernels But we don't have a test VNF on which we can actually try this out things that are dynamic to this extent So there are some workarounds which we have come out come up with Mapping some Dummy interfaces and then trying to change that interface to the real networks I know they are workarounds, but and this is and that is what keeps us as a proof of concept solution currently But to be able to address that we need Enhancements on the virtual network function side on the VNF side where you have VNF which are capable of this hot plug feature This is that this is what we have taken from the specification. I'm not sure you might not be able to read the text Apologies But what we are trying to show here is the typical flow that happens when you're trying to provision a VNF You have your VNF manager, which is a plug-in component that we have built and You have the network function itself and you have your existing open stack implementation, which is your infrastructure manager So when a request comes for instantiating a VNF you make the required validations The virtual network function manager or the VNF manager is Pre-configured with the templates for all the virtual network functions that it is supposed to handle Now there is a catch here because not all VNFs can be managed with a single VNF manager So what we have tried to do here is separate this functionality into two buckets where you have the generic functionality that is Common for most of the virtual network functions as well as something that is specific for One another another set of virtual network functions the the way you configure and and directly talk to the VNF and Then the typical flow goes on when you try to create a device is when you talk to the infrastructure manager to create a VNF The VNF manager translates Whatever information it has into a nova boot call Including adding a management Interface one interface in the management network to the virtual network function and the rest the dummy interfaces for reasons Which we have discussed and after that when we are trying to provide The service to a tenant We try to only map the network interfaces on to the device that has already been created So you don't go and spawn virtual machine every time a tenant requests you For a creation of a firewall This is a key difference between the solutions that we have done before Where every request you go create a firewall with whatever networks have been asked for Yeah, while we were talking about what we have done there are There are some gaps in Making this a full-fledged solution in the areas of scheduling high availability policy-driven orchestration and scaling These challenges are distributed Across the different components of the solution and these are what we are trying to address as in the subsequent I mean a subsequent work on what we have done already and as I mentioned if You're interested in taking a look at the demo you can reach out to me or partha will be available in the Design summit for the next two days Yeah, with that we come to the end of whatever we wanted to present as I mentioned We have the demo laptop in which the complete POC is running live So sometime tomorrow day after tomorrow anytime when you are interested you can contact us and we can run the demo in the killer summit We are open to questions now if no questions. Thank you for your time. Have a good day Thank you. Thank you