The linkage of network functions to form a service is often a very complex procedure. We were asked to validate service function chaining on a Virtual Network Function (VNF) using Cloudify.
The Challenge
As part of a recent PoC (Proof of Concept) exercise, one of our Customers asked us to validate the operation of a Service Function Chaining concept by deploying Telco workloads on a private cloud. By definition, Service Function Chaining (SFC) is the instantiation of multiple service functions to form an end-to-end chain and steering the traffic through them, thereby creating a Service Function Path.
The Aptira Solution
To demonstrate SFC functionality, we used two Network Services, available as Virtual Network Functions (VNFs): Clearwater Virtual Infrastructure Managers (VIMs) as well as F5 VNFs vFirewall and a Virtual Logic Traffic Manager (vLTM) load balancer.
The end-to-end service objective was to enable SIP calls between SIP clients on different infrastructure. For validation purposes the configuration simulated two data centers using one OpenStack cloud instance at each site. This configuration enables SIP traffic between SIP clients to pass through the F5 VNFs deployed in one data center and vIMS deployed in another data centre via SDN-WAN network.
The SDN-WAN topology to connect these two data centres was simulated using a set of OpenVSwitch controlled by an SDN Controller (i.e. OpenDayLight).
A high-level diagram is shown below.
Cloudify was configured as the Network Functions Virtualisation Orchestrator (NFVO) to model and control the entire configuration, which was modelled using a TOSCA template. The TOSCA template includes the node types and node template definitions for each VIM resource such as – Subnet, Floating IP, VM, Security groups.
Once these VNFs are orchestrated using Cloudify as NFVO, it uses the deployment proxy mechanism/plugin to setup an SFP path to enable the SIP traffic. Another TOSCA blueprint manages the establishment of the SFP. The SFP is modelled using a TOSCA blueprint that includes the deployment details of service functions that are to be chained:
- Deployment details (or ids) of F5 VNFs and vIMS
- Traffic policies to allow SIP traffic
- Waypoints of the Software Defined Networking Wide Area Network (SDN-WAN) topology
The SFP blueprint also has details of the traffic type/rule classifiers based on which the SIP traffic must be routed. Using the deployment proxy plugin, Cloudify performs resource discovery by fetching the deployment/infrastructure level details of the service functions.
Cloudify performs the following functions using the SFP blueprint:
- Publishes the traffic rules in F5 VNFs to allow SIP traffic on a specific domain
- Configures the network in such a way all the outgoing SIP packets are routed to SDN-WAN network
- Configures the OpenFlow rules in the SDN-WAN topology so that traffic is routed to vIMS instance
Aptira’s specialist technical team designed and implemented the TOSCA blueprints which were set up in the PoC environment and tested for compliance with the validation requirements. Various tweaks and improvements were made before a final configuration was established.
The Result
The configuration was executed in the PoC environment and validated all the required functions for the Virtual Network Function Service Chaining. This configuration was a very good illustration of the breadth and depth of Cloudify capabilities and the strength of TOSCA as a modeling language.
The result is also a reusable SFP TOSCA model that can not only be used to orchestrate complex services and chain them but also allow run-time decision making for operators to steer the traffic seamlessly without any manual intervention thereby demonstrating zero touch orchestration.
