Executive MBA alumnus Swamy Vasudevan talks virtualization architecture with open interfaces and protocols in VanillaPlus, UK
VanillaPlus, UK, one of the key magazines in telecommunications globally, recently published an interview with Swamy Vasudevan (Rutgers EMBA, 2015) about framework architecture necessary to deploying virtualization technologies.
Swamy Vasudevan is the chief technology officer of strategy and business development for software defined networks (SDN), network functions virtualisation (NFV) and cloud at Ericsson North America. Here he tells VanillaPlus that, as virtualisation technologies are deployed, a framework architecture that encompasses analytics and policy management in addition to orchestration and management is required. Such an architecture is vital to enable communications service providers to unleash the benefits of virtualisation regardless of whether they take a holistic, hybrid or step-by-step approach to their transformation.
VanillaPlus: What is the importance big data analytics and policy in the management and orchestration of hybrid networks?
Swamy Vasudevan: Policy and analytics have always been an integral part of managing and securing communications networks. However, technological innovations such as network functions virtualisation (NFV), software defined networking (SDN) and cloud technologies now allow policy and analytics to serve mission-critical roles in managing and securing dynamic, autonomic, programmable networks. For example, with CSP looking to deploy hybrid networks – composed of both physical and virtual network functions, the focus is not only on management and orchestration (MANO), but also on control, policy and analytics (COMPA) to realize the complete benefit of NFV in the hybrid world.
There are two ways to approach this opportunity: at the network level or the customer level. Applying network level policy means, for example, that if a particular network function exceeds more than 90% utilisation of its CPU, the CSP is alerted that it might fail. In the traditional world if something fails the alert goes to the network operations centre (NOC), but with a VNF, you need the intelligence – and remember there will be millions of VNFs – taken from the tons of data to automate bringing up a new network function to alleviate the issue.
At the customer level, let’s suppose a customer is watching Netflix and the CSP notices the level of bandwidth they are using is causing capacity to be constrained. The CSP can then use analytics and apply policies – such as applying new compression techniques or spinning up new capacity – to optimise the increase in bandwidth availability.
Analytics and policy allows the CSP to go beyond MANO and employ adaptive automation and dynamic governance. These capabilities are important to efficiently meet the challenges of a cross layer, multidomain infrastructure and provide the full benefits of network and service automation to the CSP and the end user. Adaptive policies can change in response to dynamic infrastructure.
VP: What is the appropriate level of management and control for a hybrid network – should the approach be centralised, distributed or hierarchical?
SV: This is highly dependent upon the CSP’s specific architecture and objectives. You centralise for efficiency and distribute for responsiveness – that’s the ongoing trade-off. So migrating an existing network to an NFV/SDN-based architecture requires hybrid operational modes that apply SDN-based control capabilities onto the existing transport infrastructure. Therefore, the capabilities that are included depend on the level of centralisation versus distribution of functions that the CSP chooses for its network domain.
The appropriate level of management and control clearly depends on the type of service as well. Once the network functions are virtualised, they can move to locations where demand is likely to be high. For example, with a video content service it makes sense distribute some of the management and control functions. However, situations of peak demand such as large events can be tricky, so control and management functions need to be close to where the traffic is coming from.
VP: How do you prepare for the future while balancing current needs to deliver against return on investment (ROI) expectations and minimising business disruption?
SV: This is a challenge every CSP is facing. We recognise that CSPs don’t want yet another separate network isolated from other parts of the infrastructure. Strategic architectural planning will integrate, federate, consolidate and rationalise to work towards a holistic infrastructure that can be managed as one entity for simplicity and costs savings. Of course, this is done over time and in phases according to the target architecture.
There are two ways to approach this. First a lot of technological evolution is happening because of cloud, SDN and NFV. CSPs that want to prepare for the future by offering any blend of services in an agile manner and with relatively low time to market will invest in complete transformation. This all in approach involves creating standard frameworks, like an architecture, to enable the step-by-step evolution while reaching business goals associated with each deployment. As mentioned earlier, Ericsson’s architecture for this is called COMPA – control, orchestration, management, policy and analytics.
CSPs will decide on the distribution and hierarchy of individual COMPA units across a network, based on their unique circumstances and specific objectives. To support the individual CSP’s objectives, Ericsson’s flexible COMPA approach relies upon the underlying concepts of cross-layer federation, hierarchical control loop and policy cascading. Cross-layer federation provides a controlled way to coordinate distributed, dynamic COMPA elements operating at different parts of the network.
When we look at a CSP’s processes and network, we’re looking from the transport layer – the network and access platforms and the OSS and BSS on top. Each of those layers have common themes. In transport you need a control mechanism for provisioning a particular transport layer. From an orchestration perspective, if you’re setting up an end-to-end transport path, it needs to be managed.
All the things that apply in the transport layer also occur in the infrastructure layer, the scope of a cloud service or whatever the situation is, so the need for things to be controlled and orchestrated is common, and analytics is also required. CSPs therefore don’t have to focus on one specific business case but can build an architecture that will be applicable as they move through NFV and other transformations.
By the way, the second approach for CSPs is not to completely boil the ocean but instead to identify a specific business need for virtualisation and address that in a relatively contained way. For example, a CSP that wants to provide services to an enterprise customer can look to a specific deployment to accelerate the time it takes to provision a service to an enterprise.
VP: What are the migration steps for operationalising hybrid networks?
SV: Tying into the ROI question earlier, you break down the steps and define migration phases according to the target architecture; so the first steps are to determine a target architecture, assess your current position towards that target and then identify the milestones to get to the goal. As you proceed, you will need to federate data and abstract from existing network elements to make them available to SDN controllers or NVI managers. This will allow you to bridge from your current infrastructure to avoid disruptions in your existing services and operations.
If we had a greenfield deployment situation, life would be easy. Unfortunately that won’t be the case as CSPs have so many legacy technologies deployed. The ETSI model therefore has to be extended to cover all the different technical principles and help the industry move seamlessly to a hybrid model.
One way to approach this is to understand what is in the CSP’s existing network. To begin, CSPs typically will have a multi-vendor, multi-technology environment, so analysis is required as a first step. The second step in this migration is to ensure the processes are set in place correctly. In physical networks these processes are well defined through years of development; but NFV and SDN are completely disruptive, so the processes and management need to be addressed. This involves creating a thin layer on top of the infrastructure that hooks into not just the element management systems of the physical network vendors, but also the VNF managers – and talks to both in a hybrid manner.
With NFV, the whole point is about how all the different resources can be shared in a multi-tenant approach so multiple customers can be supported just by partitioning the network into different slices. This will certainly happen, but will take place gradually for each domain depending on the complexity involved. The key thing here is to have the framework that sits on top of both the physical and virtual infrastructure.
VP: How realistic a scenario is autonomous automation of network management?
SV: It’s absolutely realistic. When we talk about traditional automation – as we have done for 20 years – most CSPs are trying to handle their capabilities in the OSS and BSS domains. However, processes such as provisioning a new network service have remained largely manual, sometimes taking a CSP weeks to complete. A key barrier is that you can’t really automate truck roll in the physical network, but with SDN and NFV you can automate effectively. There are so many proofs of concepts going on across the world that I think zero touch provisioning – not just from the B/OSS perspective but right up to the network – is real.
To be sure, there still will be obstacles to overcome, particularly in the way we adapt processes and functions as a result of this network management organisation. But the telecoms industry has always solved seemingly impossible challenges and I have no doubt we’ll continue to do so as we fully utilise these new technologies.
VP: Does joining up all the cloud-SDN-NFV innovation needed for next generation management of the network imply years of systems integration/transformation effort?
SV: That all depends on the service provider’s target architecture, how quickly they want to reach that target and their ability to efficiently manage through the transition. There are lots of benefits to combining all of these technologies. Cloud has been in existence for more than a decade and enables resource pooling and rapid elasticity. NFV takes that cloud principle and applies it to VNFs to create much greater agility on the network side. SDN, on top of that, drives programmability in the network to enable faster introduction of new services.
Due to the impact on CSP processes and potentially even the business ecosystem, it is likely that this transformation will take place in a stepwise manner over a significant period of time – with different parts of the network evolving at different rates.
Having said that, we need to remember that this isn’t a greenfield situation; but if we create the right network architectures that have exposure and abstraction, coordinated integration between the different administrative domains can be achieved. The COMPA architecture defines how you can set up interoperability between domains using industry standard protocols so the integration effort will be minimised.
That will massively reduce the time it takes to implement new services or elements. I don’t think this transformation is going to involve years and years of complex management and systems integration. I’m much more optimistic that open interfaces and protocols will reduce the time required for migration and integration. I see COMPA as a key enabler of this integration, as well as the main driver in the resulting Ericsson reduction in the time taken to transform.
Press: For all media inquiries see our Media Kit