The Tesla Model S has a mode called “Ludicrous mode” that allows the driver to reach 60 miles per hour (about 96 km/h) in just 2.8 seconds. That ability to wow drivers and passengers in 2.8 seconds is impressive, but then what? How do you get to 160 mph? On the German Autobahn, 60 miles per hour is considered slow and “please move over to the right lane” speed. The last time I was in a car on the Autobahn, my friend drove a BMW M5 at 260 km/h (around 160 miles per hour). That takes a completely different level of instrumentation, focus and capabilities than the first 2.8 seconds. If we had our way, we would have combined the acceleration of the Tesla, with BMWs reliability, comfort, high-end speed, availability (wait until next year for a car?) and the total control my driver friend had to maintain in order to drive the car for an hour at 160 mph.
Operator networks and the services they deliver are a lot like cars. For starters, we want to be able to deploy a new service quickly. This is part of the drive and the benefits of Network Functions Virtualization (NFV). Instead of physically rolling out boxes to a data center, connecting them to each other with cables, paying for their cooling and electricity for every new services we want to offer, if we just virtualize the network, we should be able to deploy new services with a few clicks. Obviously, once these services are deployed, we have to manage the virtualized network and provide high service reliability and availability. If something does go wrong, we’d like to rapidly identify the root cause and resume normal operations as quickly as possible.
At the OpenStack Summit in Barcelona, we are taking attendees on this ride. VMware is demonstrating deployment and 360-degrees monitoring of a Virtual IMS network with OpenStack on vCloud NFV.
We start by demonstrating an OpenStack deployment in a matter of minutes. In ETSI NFV lingo, this demonstration provides the Telco operator with an OpenStack-based Virtualized Infrastructure Manager (VIM) using VMware Integrated OpenStack (VIO), in a matter of minutes. As a side note, you can read this great blog about getting OpenStack up and running on just 15 minutes with VMware. We can do the same with our other VIM – vCloud Director — but as this is an OpenStack Summit blog, we’ll stay focused there.
Deploying a VIM is a necessity in order to consume virtualized resources such as compute, storage and networking. But the real telco operator interest is, of course, the ability to deploy NFV-based services. Together with one of our VMware Ready for NFV partners, Metaswitch, we demonstrate how with a few clicks, we can deploy an IMS solution. We build a HEAT template that included all the components needed to make VoLTE calls: Session Border Controller (SBC), Home Subscriber Server (HSS), as well as both I and S Call Session Control Functions (CSCF). With the HEAT template in hand, we easily install all the IMS components. At the end our service components look like the following topology:
In addition to deploying IMS, we also simulate subscribers registering and making SIP calls over the network, with the help of Spirent’s Landslide Virtual
At this point we went from 0 to 60 mph in 2.8 seconds. This type of a deployment would have been at least two projects counted in months of work. Yet we installed a complete DefCore-compliant OpenStack and deployed an IMS network in minutes. Here is the typical reaction we see when we demonstrate this.
We also heard from our customers that upgrading from one OpenStack installation to another is a time consuming project. In fact, sometimes it is so risky, that a whole new environment must be setup with a new version of OpenStack, and then the old environment is de-commissioned. I don’t think most of us would mind if every time when we took our car to the garage, we received a new car, but the likes of BMW and Tesla are likely to have a hard time paying for that. So, we also demonstrate how we can upgrade from an OpenStack Kilo-based environment to a newer Mitaka-based release, in a matter of minutes. During the upgrade, we validate with Spirent Landslide running that the IMS solution remains up and running and no calls are dropped during VoLTE calls.
At the end of the day, installing software, deploying a new service and upgrading infrastructure components, cannot be rocket science. They fall under the “of course” category. What really is exciting is the beautiful dashboard we build to allow our drivers to maintain complete control while driving at 160 mph.
When a network service moves into production, the network operations team is used to having the instruments to monitor the network service. Metaswitch for example, provides a great tool called Service Assurance Server to perform detailed diagnostics for all calls, over all protocols. After the service has been virtualized, the ability to understand all layers of the stack: from the service components all the way down to the physical server hosting the hypervisor and the virtual networking components as well as the storage, is what is needed.
At the OpenStack Summit in Barcelona, we demonstrate complete 360-degree visibility into all layers of the service. In fact, not only are we showing how VMware vRealize Network Insight can provide visibility into the complete stack: from VM through the overlay, underlay and back out, but we also show how using the same tool, when an error is simulated, we can identify with surgical precision, the location in our service supporting infrastructure where the error occurred. Using a second tool in our arsenal, VMware vRealize Log Insight, we can quickly find the cause of the error and fix it. You can see in the image below that vRealize Network Insight not only provides a fantastic view into all layers, but also provides a lot of statistics as well as a timeline you can use to play back and identify issues in the past.
Last but not least is the pane of glass I expect most operations departments to be using to monitor their services. VMware vRealize Operations Manager allow us to monitor the state of the IMS service, organizing our view into three panels: Health, Risk and Efficiency. This means that when the IMS service infrastructure is starting to become degraded or is facing a risk, we will be notified before the risk will turn into an issue.
This is such a powerful concept. The operations team is not just limited to a narrow view of a single isolated layer, but is empowered to view the complete stack. If there are indications that networking problems are on the horizon, the operator could switch her view to vRealize Network Insight and investigate further. If the issues are with the IMS, in our demonstration the operator could log into Metaswitch’s SAS to investigate further and if there are other indications of infrastructure risks…well…these are the tools the operations team has been using for so many years already anyway.
So there you have it. Going back to our analogy, not only are we able to accelerate on the road and increase the speed at which we are driving, we’re also upgrading the car’s control software on the Autobahn and are driving more safely than ever before with the help of preemptive notifications and constant health monitoring. With cars, this is still a dream, but with our NFV Infrastructure and VIM, this is already a reality.
Jambi
