NFV nearly five years on

• October 2012 saw the birth of NFV
• Just five years later implementation is under way
• But NFV has developed into a different animal than first envisaged

Can it really be nearly five years since the publication of what already looks to be the most important single technical treatise in telecoms since…  well, for at least the 30 years or so that I’ve been covering telecoms.

I’m talking, of course, about the White Paper on NFV, (sometimes called ‘The ETSI White Paper’) which was published in October 2012. Download here.

 It was on the face of it a modest sort of affair and laid out thus:

Network Functions Virtualisation

An Introduction, Benefits, Enablers, Challenges & Call for Action

OBJECTIVES This is a non-proprietary white paper authored by network operators.

“The key objective for this white paper is to outline the benefits, enablers and challenges for Network Functions Virtualisation (as distinct from Cloud/SDN) and the rationale for encouraging an international collaboration to accelerate development and deployment of interoperable solutions based on high volume industry standard servers.”

A long list of authors followed, all top telco people.  

Over the subsequent five years that core group steered the ETSI process to where it is today, with SDN/NFV now widely accepted as the desired underpinning to the next generation of telecommunications services - in particular to 5G mobile where its network slicing capabilities are expected to come to the fore.

But not just 5G - SDNFV is seen as the ultimate way of managing diverse services on a single infrastructure while saving money and increasing ‘agility’. Most importantly, an NFV transformation puts the network on a fast churn -  new services and huge increases in capacity which, before the arrival of the ‘white box’, would have presented a brick wall to the telco business model will change the rules. White box servers might be written off in a few short years and new ones at half the price, twice the power and half the power consumption brought in as replacements. What’s not to like?

Two things stand out when re-reading the introduction to the white paper above. First, it was unashamedly operator-driven. Today, with accusations that the whole movement has stalled, that operators are wringing their hands over an apparent lack of interoperability and dreaming of a return to old-fashioned standards setting, it might be worth reminding ourselves that this was and is, a telco initiative. So, while some telcos may be finding the going slower and harder than at first envisaged, the real hand-wringers are more likely to be found in the vendor community.

Secondly, the words ‘open source’ don’t appear at all in the document (I’ve searched it).

There is a very obvious reason for this.

As our first TelecomTV interviews on the initiative made clear, part of the motivation here was lock-in avoidance (in fact a very large part of the motivation from the telcos was lock-in avoidance) and so the NFV advocates had to draw a fine line so that the vendors wouldn’t flounce off in a huff, convinced the telcos were getting them into a corner to squeeze their margins to nothing. So while there was talk of vendors “stepping up to the plate” and “playing nice” with each other to get the NFV interoperability working properly, the paper itself also emphasised NFV's advantages to the mature equipment vendors. It said…

“The Changing Telecoms Industry Landscape

Although Network Functions Virtualisation brings many advantages to the telecommunications industry it is likely to transform the vendor landscape. Each player will need to position/re-position itself in the new Network Functions Virtualisation market. This is not as disruptive as it may seem because network equipment vendors already implement some of their solutions by combining their proprietary software with industry standard hardware and software components, but in a proprietary way.

"Enabling their proprietary software to run on industry standard hardware in a standardised way may be a significant opportunity for existing players because their software and networking know-how is where the real value is in many cases. Some major industry players are already moving in this direction by offering virtualized versions of their products. The challenge for network operators is how to migrate their operations and skill base to a software based networking environment while carefully re-targeting investment to maximise reuse of existing systems and processes.”

So all that applications software development wouldn’t be nixed with NFV - you just had to virtualise it and business would continue as usual. As the ETSI NFV process developed, however, it soon became clear that interoperability between these ‘monolithic’ applications was a problem, and, as a consequence, so too was lock-in.

So the answer (or one of them) was ‘decomposition’ and, one step further, the introduction of the concept of  ‘cloud native’ applications. These were telecommunications applications written from scratch to operate in an NFV environment in a 'telco cloud'.

At the same time, open source initiatives designed to propel the space forward, were also gaining ground.

As a result, step by step, the NFV vision, as originally conceived, was altered into a much more open and open source effort, but it was done it in stages as part of the collaboration that the ETSI group fostered.  Whether the originators of the group had an idea that an open source environment would be the most likely outcome once the process got properly under way is another question…  which I will touch on tomorrow with Part Two.