It’s very difficult to deliver multi-vendor VNFs on a variant of open source-derived NFV infrastructure because of the tweaks and modifications necessarily undertaken to get the solution working. VMware sees the underlying issue here is operational complexity. So the tendency has been to simplify the deployment by building a ‘vertical stack’ or ‘software silo’. This leads to dependencies up and down the stack which leads, in turn, to the same siloed business model, complete with lock-in, as we saw in the past. It might therefore be of little or no benefit and even possibly more expensive.

At this point, Honore’ points out that what looked like a divergent choice 5 years ago between opensource and VMware, is now converging on a best of both worlds solution for customers, with VMware’s proven virtualisation capabilities now accessible via VMware’s recently released OpenStack Carrier Edition’.

So given those snakes, ladders and the accompanying complexity around choosing vendor approaches, what does VMware offer and what sort of NFV ambitions does it best serve?

“We think we’ve a way forward which steers a path designed to win the advantages of rapid innovation through a DevOps operating model, and the rapid iteration and agility it confers on the CSP, with a solid NFVi (NFV Infrastructure) base,” claims Honoré. “With such a structure everything still gets the valuable iteration, but the CSP starts with a well-defined, tried and tested NFV infrastructure framework. Most importantly, CSPs can build a single infrastructure with a single operating team that can deliver NFVi as a service to multiple, internal, telecoms services’ teams.”

This approach strikes a useful balance between the imperative to provide the appropriate service level agreement for the customer, ranging from best efforts to five 9s, easy platform servicing and operations, low operating costs, and service flexibility.

In addition, VMware produces, tests and releases a pre-integrated NFVi platform. This simplifies installation, enables easy upgrades and provides what VMware refers to as intelligent operations with 360° visibility. With this approach, VMware claims its CSP customers can generate ‘repeatable’ deployments that can be put into production, operated and supported more easily. The result is a prescriptive (and hence deployable and scalable) but not restrictive NFVI platform. VMware’s VNF accreditation program already lists over 50 certified VNFs for the platform to provide multi-vendor choice when it comes to higher level service deployments.

“But the big ‘thing’ – the killer gain from a successful NFV transformation – is not that the CSP can build the ultimate set of VNFs, or bear down on capital and operational costs” says Honore’, “but that it has established an iterative development process and a clear path to the software defined, data driven, automated environment that that will eventually signal its complete digital business transformation.”

So what’s changed since the publication of the NFV white paper?
“Five years ago we didn’t comprehend the need for CSP culture change to enable transformation,” says Andrew. “But things have changed greatly with SDNFV over the past four years especially. The industry has had to move from a science project through to ‘available in the lab’ and then to something that could be deployable. In the great scheme of things I think we’ve moved remarkably quickly on the open source side of things to make that happen.”
Most importantly it’s turned out that the industry wasn’t – as it perhaps at first thought – introducing a new technical framework and, ‘Oh by the way, you might have to change how you do things a little’. It now looks as though we’re introducing new ways of engaging with customers software, services and suppliers with some necessary and useful technology coming along for the ride. Culture change in other words, has become the prize, not the price.

There’s no doubt the process has been slower than thought. Why?
Andrew thinks “a lot of stuff got stuck in the labs and there was a feeling that everything had to be new.” In too many cases that appeared to mean white boxes needed to replace legacy hardware and there was a feeling that “before we can adopt this technology we need to put data centres in,” Andrew maintains.
“Actually, on the SDN side it’s predominantly all about the existing equipment. So not about replacing, but making the ‘physical’ equipment work with the new virtual environment,” he says.
The ‘stay in the lab’ problem may also be compounded by the tendency for CSPs to use the white box threat to negotiate costs down with their current vendor.
Another reason software might stay in the lab might be a pervasive fear of ‘failure’ on the part of many CSPs, somewhat at odds with the IT “fail fast” credo. Allied to this can be a reluctance to upgrade the network – in sharp contrast to the constant upgrading undertaken by the hyperscale players many carriers would like to emulate.
“What happens is that a lot of telcos try to dodge the upgrades: they will ask, “find me some patches; give me a configuration change, anything that means I don’t have to upgrade the software,” says Andrew.
Overcoming the upgrade phobia would help the new software ‘escape the lab’ on a more timely basis says Andrew.

What is Lumina’s perfect customer? “We’re looking for customers who have captured this technology and understand what it is they want to do. Typically they have stuff in the labs and they now want to get it out and they need a partner to help them do that. They don’t want to hand the task off to an outsourcing company because they’ll lose the learnings that they have and they won’t be in control of the outcomes. So they want to keep doing it but they know they need some expertize to help them with that process.”

Service assurance is key – why now?

There has traditionally been an almost one-to-one mapping between a service and its underlying technology. So, for instance, a landline data service used to go across a PSTN network and was multiplexed at 56 or 64kbit/s: to hijack Marshall McLuhan, the technology WAS the service.

But increasingly services are much more complicated, mostly IP-based, and able to be carried over almost any network. As a result they are ‘best effort’ rather than deterministically guaranteed and that means the provider must put its own best effort into engineering them to deliver what has been promised.

On top of that, the measurements must relate to what the customer experiences, not what the provider thinks the network is delivering. Given the above it’s hardly surprising that most of the ‘issues’ customers present to technical support/helpdesk are about quality (for instance, my video keeps buffering; every now and then my voice quality drops way below par) rather than straight-forward ‘my link has disappeared’ events.

Amdocs believes this environment changes things greatly. It means the new network technology’s main task today, it’s make-or-break measure of success in the never-ending quest to improve the end-user experience, is one of service assurance: of pitting the growing intelligence invested in the network against its propensity to get things wrong as conditions change. For instance, when links congest, when unexpected conditions arise and low level network faults occur.

The journey to the service driven autonomous network

In preparation for the journey to a full service-driven network, however, the existing OSS assurance infrastructure needs to start its own journey to ‘NFV ready’: able to collect alarm and performance events from the existing data center infrastructure as well as the new infrastructure. Issues here include the problem of where to site probes given that data collection for assurance purposes needs to move away from being physical and network centric to being more service centric.

“With today’s ‘top down’ services, the service quality as perceived by the customer is largely being derived in very complex ways from the network experience, so it’s possible to have a situation where the network is saying everything is on ‘green’ (fully operational) but there’s still a problem with the service.

“That means the service experience needs to start to be monitored natively at a service layer via active probing and active testing and true KPIs around the service experience,” Angela says.

So what are the key points?

“The operational processes can’t simply be automated on day one,” Angela concludes. “I think what happens as you move towards the DevOps model is that the operations teams still need to have visibility over the process. And more than this they need to have the ability to configure and interact with the process giving what we call human guided operations – incrementally moving towards autonomous operations.

“One important thing to recognize is that there’s not one starting point and there’s not one journey toward a service-driven network and autonomous operations. It’s about us having the right components – which we have – and the partner CSP being clear about its objectives – and together executing the journey to get there.”

Faster, tactical, adoption may suit some
So will the faster adoption exhibited by the tier 2s and tier 3s give them an advantage so that that they grow their share of the total telecoms and networking market against the tier ones?
“Where we see people winning it tends to be in more niche areas like unified communications. If you’re trying to offer a large enterprise a complex system then often the tier 1s are just not very good at marketing and selling.
“On the voice side we’re seeing innovative ways of building networks and supplying services, particularly by MVNOs [mobile virtual network operators].”
Martin says the network operator provides the mobile access but the virtual operator provides all the componentry behind it – the evolved packet core, IMS and voice services, so perfect customers for Metaswitch.
Rather than just white labeling an MNO services, there’s lots of scope for innovation in that model, he says. And there is even the possibility that some of those operators might behave a little bit more like web scale players, leveraging the public cloud to get going with a very small capital base and working on a pay as you grow basis. “It’s early days but we’re seeing some encouraging stirrings in that space,” he claims.

So how did Martin think the market developed has there been a ‘stall’?
“Well, it has been a bit frustrating as we’ve watched the telcos wrestling with the complexities of OpenStack and orchestration – and then feeling they can’t move ahead with NFV. In some ways they’ve been making a bit of a meal with it.
“The normal telco view is to think everything through and plan everything in detail. That’s simply not the software way of doing things. Instead, you make progress by taking baby steps and learning along the way.”
So it’s not surprising, he says, that the most ambitious and ‘strategic’ telcos visions seem to be struggling the most. But the ones that have approached the task in a tactical way are doing better and moving faster.
“The tacticians tend to say things like, ‘OK we need to build out this bit of network where we need a new function and additional capacity – either we can go and buy a box like usual or we can start doing this in software and tap some network virtualization.’ Those ones are making the most progress.
”The strategy advocates will say, ‘Yeah, yeah yeah, but they’re missing the point.’ That may be true, but they’re learning along the way about what’s important and what’s not and they’re not investing in a ton of stuff that may turn out not to be all that important in retrospect.”

The software telco
“You can argue that not trying to plan every little thing in advance is the way software operators do things,” he says, “while telco people have the idea that everything will plug together and will work if you have standards.
“So when they try to deploy virtual network functions and they don’t plug together very well and don’t work, their answer is always that we don’t have strong enough standards. But that’s NOT the answer.
“You can build VNFs properly, with properly engineer APIs, so that they are completely portable across different cloud environments with no dependencies with the underlying hardware. And all without standards.
So the idea that you can get completely clean, plug and play compatibility with the right amount of standardisation is a chimera – there are always new dependencies likely to emerge at any interface?
“Exactly!” says Martin. “SIP (The Session Initiation Protocol which sets up voice and video calls across an IP network) has been around for 20 years and we still meet SIP interoperability issues every day.”