NFV Service Chaining Orchestration for Any Network Topology & Architecture

It’s a well-known pain point for Telecom companies that provisioning new services into their networks is a time and resource consuming process, as well as cost intensive. Until now, introducing new services would take months to years and was done with physical proprietary devices that took a long time just to procure – let alone introduce into the network. For those who aren’t very familiar with this sort of process, it basically involves the need to provision all of the different components of that service (i.e. the different apps – and there are many), to configure each according to the network topology, and then make a chain out of them. This is what the industry refers to as service chaining.

With the onset of the cloud, which is as one can imagine dynamic in nature and offers new capabilities around elasticity – it is only natural for Telecom vendors to make a shift in this direction, and this what NFV introduced to this industry (which we’ve discussed in the past). By separating apps that used to run on one “black box” to different VMs or even data centers and creating a virtual counterpart for what were formerly physical devices and then making it possible for all of these to now run on commodity hardware, a whole new world of cost savings was introduced. The next step in this shift, was virtualizing what was once physical chaining into virtual chaining as well. To make this possible, a service needs to be created.
<!–

NFV Orchestration + TOSCA for your cloud with Cloudify 3.2!  Go

This is what is now called dynamic service chaining (if you haven’t done so, you should listen to this podcast where Axel Clauberg, of Deutsche Telekom – one of those who coined the term NFV, discusses service chaining in detail). This is essentially the ability to take VNFs, virtual network functions, (AKA the virtual apps in an NFV environment – some common examples: router, firewall, DNS, IMS etc.) and tie them together into a service, ultimately ensuring packets go through the new service with a policy, usually at runtime, as well as ensure this is done in the proper order, e.g. router before firewall. This is particularly complex because the VM configurations are dependent on what function they serve in the service, therefore, if you change the service chain you need to change each components individual configuration.

However, it doesn’t end there. There are always dependencies, which is why you need an orchestrator in this process that is aware of all of the other services in the chain and is able to tie them together intelligently and in the order they need to be configured. So let’s take an example of a load balancer in a service chain, the orchestrator serves to configure the load balancer properly while being aware of the IP addresses of the VM for which it manages the load, and then making sure it goes through the chain in the correct order.

This is where NFV orchestration has infinitely simplified this process by enabling Telecoms to do this now in an automated and even repeatable manner – which has introduced unprecedented cost and resource savings to these organizations.

NFV orchestration through TOSCA, has made dynamic service chaining on any infrastructure now possible as well – across data centers and clouds, and even environments built around heterogeneous technologies. So for those running data centers with diverse VMware technology or across different clouds from OpenStack to public cloud, what once took time to provision, configure and introduce in just one network – can now be done seamlessly anywhere, anytime.

We have chosen to demonstrate just a few examples of how to leverage this kind of new capability using Cloudify’s TOSCA blueprints. Through these, all of the operational aspects and know how required for each VNF is captured. On top of this, we can also capture what the service chain is (i.e. the order along with the networking aspects, e.g. that the packet should first go through firewall, then the load balancer, next the router, and finally the DNS and IMS).
Let’s take CPE, as an example of a commonly used Telecom service. It’s complex as it has many endpoints – making it difficult to orchestrate this entire operation. Introducing new apps and services also requires reconfiguring the entire distributed chain, making the orchestration a serious undertaking.

In the code snippet below, you’ll see how we created a demo of a vCPE service where we actually connect distributed offices in an organization to a vRouter, we then added a firewall to this chain, and even a web application gateway as an added security measure to add URL filtering. What once entailed reconfiguring the entire service chain, can now be done in a simple blueprint by defining the router, connecting to the firewall, concatenating the router firewall, and then connecting it to internet.

Another common use case is when traveling abroad and needing a route to the home office. This many times requires a DNS service and router. Technically to do so, you need to bring up the VNF, which involves actually spinning up a VM, bringing up the VNF software, and then configuring it with the right rules, e.g. security rules for the firewall, policy rules for the router, zoning rules for DNS and so forth.

TOSCA blueprints have the combination of declarative descriptions of the network topology with all its components – including the load balancer, network, the compute resources, software and everything else, along with an imperative set of workflows to describe the logic of any process we need to automate. What this means from an NFV orchestration perspective, is that with the TOSCA topology each application component has lifecycle hooks, that enable the adding of more hooks to cope with new processes on the fly – essentially a game changer for the entire Telecom industry.
In our next post, we will demo a new and improved IMS example on VMware vCloud Air.