Orchestrating the virtual – making NFV a reality

VENDOR SPOTLIGHT

Telecoms.com recently partnered with Amdocs to discuss its work in NFV in the telecoms sector, particularly focussing on how NFV orchestration will become increasingly influential on the delivery of next generation content, converged and enterprise services.

The telecoms industry is in a perpetual state of longing for the next big thing. Today, you’ll find Telecoms.com awash with talk of IoT, 5G, software defined networking and network functions virtualization. While it would be fairly argued the first half of that list is still some way off of becoming a tangible reality, SDN and particularly NFV have begun showing promising signs during early live deployments.

NFV, in general, takes existing functions performed on hardware in the network, abstracting the functionality and instead storing it on high capacity compute servers. The benefits have been well-documented on multiple occasions, but one of the biggest barriers to adoption experienced during the development of NFV methodologies and topologies, has been orchestration. Orchestration pertains to the organisation, interoperability and management of various virtual network functions, in order to expedite service creation and delivery to customers; made all the more complex by the open nature of the technology and the variety of vendors offering up solutions.

Last year, OSS specialist Amdocs launched the Network Cloud Service Orchestrator, which it claims is an open, catalogue-driven solution designed to pave the road between physical networks and cloud for operators. Justin Paul, who is the head of marketing for Amdocs’ OSS division, reckons NFV is starting to evolve from its basic roots towards a more sophisticated option for operators building more complex virtualized architectures.

“For Amdocs, we made our first public announcement about NFV last year when we launched the Network Cloud Service Orchestrator, our NFV orchestration solution,” he says. “The feedback we’re getting is that this is a very high end orchestrator, and if you look at the market today we’re actually really at Phase 1 – which I believe is the engineering level trying to figure out if they can virtualize their existing network equipment. You take a switch, and it sits in a switch room with a dedicated team looking after it. You then virtualize that onto a dedicated server in the same switch room and with the same team looking after it. That’s pretty much where we are today, it’s about taking a physical box and make it an application on a computing server, with no other benefits around it.”

Paul then explains how the evolution is starting to take shape, starting with how NFV is encouraging a shift away from traditional business silos and buying powers, as well as from the traditional relationship between customer and vendor.

“I think the challenge with Phase 1, and what is interesting from our point of view, is the shift in buying centres from the engineering teams and engineering activities,” he says. “When you want to do more complex virtualization, there’s a fundamental shift, because NFV orchestration appears to be in the domain of the IT teams within an organisation. We’ve done some recent research which found there’s no practical reason for linking your VNF vendor choice with your orchestration vendor choice, that is not a linked decision, or at least it shouldn’t be.

“From a network equipment vendor perspective, they’re keen to say ‘stick with us for everything’; which is an easy solution for engineering teams, but totally goes against the concept of NFV in the first place,” Paul says. “The problem with Phase 1 is that if you just virtualize the physical network and don’t change anything else, you don’t get any of the benefits you’d expect to get from virtualization. You’re not efficiently using hardware, you’re not tearing up and tearing down services in response to a planned or unplanned event; so effectively you dimension your virtual network in the same way you did your physical network, and you don’t get the capex savings or the organisational benefits. It’s worth noting that a big pull of NFV for service providers is that it will help to start breaking down organisational silos with a virtualized network.”

The question remains of how orchestration requirements of NFV will change as service providers become more ambitious with their virtualization objectives. ETSI’s NFV ISG has developed working groups tasked with solving the specific challenges associated with the management and orchestration (MANO) of a virtualized environment, and a number of cross-industry collaborative efforts have focussed on real-world applications. Such processes help bring commercial, carrier-grade NFV-based services to fruition sooner rather than later, Paul suggests.

“We’re starting to see some trials and proof of concepts where complex orchestration is coming in to play,” he says. “What’s interesting is that if one moves away from traditional residential or business services and into the enterprise domain, you’ll see a much higher level of NFV adoption today. Case in point, there are three or four companies that would definitely say they’ve commercially launched NFV services in their networking domain today.

“We’ve also been involved with a number of PoC trials where we’ve been orchestrating VNFs and virtual instances from third parties in the way of an enterprise solution. Virtual firewalling and WAN optimisation are good enterprise use cases where we’re starting to see quite interesting NFV orchestration coming into play. Particularly in the enterprise domain, the ability to cut out a lot of cost and complexity is a real winner. If a company were to construct a new building today, there’s the ability to very quickly, or even instantly, replicate the services in place at all other sites by using virtualization. Of course, that’s once internet connectivity is established; but that’s a great use case right there on how customer premises equipment virtualization is beneficial – to the tune of something in the region of 47% cost reduction.”

Cost reduction is the long-fabled dream outcome of NFV, and a tangible reduction in both capex and opex makes the business-case for investment in virtualization all the more compelling. However, the cost of investment is still one of the biggest barriers to broad-scale carrier adoption of NFV, according to Paul.

“SPs today have a big challenge, and it’s their barrier to innovation; it costs so much to develop services, to test those services and to then roll them out,” he says. “There’s a lot of talk about whether telcos are competing with OTTs or not, but regardless, there’s still the aspiration to have the same level of innovation and service development that companies like Google, Facebook or Amazon have. A lot of the challenges are to do with the way they’re structured and tested, and how they build in the resilience to those solutions, and it’s still what telcos aspire to.

“The false assumption is that NFV will make all these challenges go away, and it will to some extent but it’s not the case for all of them,” Paul says. “Having a function is not the same as having a service, there’s more to do to deliver an end-to-end service and this is something that various segments of the industry still haven’t grasped. There’s more to service than just having function, you need to be able to bill that service, package it and manage it appropriately. Today, that process is hugely manual and is very costly, and takes a lot of time and effort.”

Operators appear confined by a notoriously long service creation lifecycle, which until now has left them several steps behind OTTs in terms of new service development and delivery. Paul then goes on to describe his utopia for telco service innovation.

Justin Paul, Head Of Oss Marketing For Amdocs

“What I do think is necessary is a service design and creation capability that will allow operators to, in an automated way, take a very visual approach to service creation; to drag and drop, and build services and workflows and policy, and then launch those in an NFV orchestrator,” he says. “This ties together perfectly as service chaining. Typically, it takes 9-12 months to rollout a new service, while 24 months is not atypical. An NFV orchestrator is able to instantiate those services in minutes rather than months, but of course it still takes time to develop those services in the first place, and this is the problem we’re working on.”

Naturally, new network configurations and topologies will require new ways of managing operation systems, and Paul concludes by discussing the requirements of a new and more agile OSS as operators continue to diversify product offerings, and as more merger and acquisition activity occurs in the telecoms industry.

“A big driver for cross-domain orchestration is the consolidation and merger and acquisition activity we’re seeing in the industry,” he says. “That is bringing together multiple customer bases and saying ‘how can I sell the products and services from Group A to Group B, and vice versa?’. There’s one other domain intrinsically related to all of this. In response to SDN and NFV networks, the operational support systems have to become more real-time and more aware. They have to become more dynamic to manage these real-time components, because SDN and NFV elements will change reasonably regularly – so operators need to be able to see how the network is operating at any given point in time. We call the approach to meeting these diverse needs, Agile OSS”