Will ETSI’s NFV 4 rescue the technology from redundancy?

ETSI has started work on the next release of NFV (network function virtualization), the key specifications which underpin telco virtualized networks – just as the platform is under fire like never before.

Some telcos have increasingly been criticizing NFV for being too cumbersome and so failing to deliver the key targeted benefits of virtualized networks – agility, low cost and flexibility. Early deployments of virtualized network elements, such as packet cores or gateways, have often relied on virtual machines (VM), while the cloud world has been moving rapidly to the more agile containers and microservices – which allow the functions to be broken up into very small elements that can be easily reconfigured and recombined.

Now,  a report from Gartner warns that enterprises are adopting architectures that entirely sideline NFV, and telcos may follow.

This, then, is a make-or-break release of the ETSI NFV group’s specifications and its authors claim they will bring the platform into line with “recent technological advances, including ways to simplify its usage in line with current network transformation trends”.

According to Joan Triay, technical manager of the NFV ISG (industry specification group): “The technical topics comprising the Release 4 scope exemplify well how the NFV framework is continuously being enhanced to consider existing and new technology trends and provide the demanded support by network operators and network function providers for deploying current and future network generations.”

And the key issues to be addressed do reflect awareness of the newer trends in the cloud platform, which threaten to make NFV redundant. They include:

  • Evolution of the NFV framework to support the most recent cloud, software and virtualization techniques
  • Novel management architectural styles and operationalization aspects, leveraging virtualization characteristics to simplify deployments
  • Increased support for automation.
  • Service-based architecture (SBA) design for NFV
  • Virtual network function (VNF) generic operations, administration and management (OAM) functions
  • Enablers for autonomous management in NFV management and orchestration (NFV-MANO).

Most importantly perhaps, work has started to enhance NFV framework support for container-based deployment of VNFs, with a focus on service interfaces for OS container management and orchestration, as well as the requirements for the MANO in container cluster nodes.

ETSI has a parallel multi-track approach to its specs. It is still maintaining and testing  NFV Release 2 specs and is developing protocols and data models for supporting Release 3 features in commercial networks.

Release 3 was important for introducing some 5G-specific elements, but Release 4 will be more significant still, representing a potential lifeboat for NFV as organizations start to demand a new generation of cloud-based services. According to Gartner, these are already threatening SD-WAN in the enterprise wide area network and doing the same for NFV in the telco world. It labels the new approach the ‘Secure Access Service Edge’ (SASE), which addresses the fact that applications live in many locations, not just the data center, and are consumed anywhere, because of mobile devices – but still need to be secured, tracked, updated and so on.

Analyst Joe Skorupa says the trend “represents an existential threat to NFV” because NFV still tends to run on expensive boxes (even though they are x86-based) and so it has not delivered the promised cost benefits. In addition, it has been over-complex and telcos have taken a long time to make it work effectively, and while they were doing so “application consumption patterns changed and … a solution that was non-scalable and hard to maintain and expensive and complex winds up being obsoleted by something that is elastic and easy to maintain and it’s cloud-delivered,” Skorupa added in an interview with LightReading.

It is particularly difficult to implement NFV in a multivendor environment. Most early deployments have been single-vendor, with a few exceptions like packet cores at NTT Docomo and SK Telecom. Even Telefónica, which is wedded to a multivendor NFV strategy, has initially gone with single-vendor solutions to save time and effort in the first phase of its UNICA cloud deployment. Analysys Mason estimates that 73% of VNFs are deployed as single-vendor stacks, down from 83% 18 months ago, indicating some slow but measurable progress.

While the large vendors use fear uncertainty and doubt to warn operators against the complexities of multivendor NFV, some are getting more subtle in their approach. Huawei still just argues that the resulting system will be less reliable, manageable and secure, but Ericsson proposes that, instead of breaking apart vendors’ NFV stacks, operators can use different stacks in different slices, to avoid being over-reliant on one supplier.

Huaweis argument centers on cost. In a single-vendor environment, virtualization will eventually reduce operating costs to about 91% of the original level (after a period of higher costs when the systems are being deployed); but in a multivendor virtualized platform operating costs will end up 46% higher, at the same stage, the company claims. It also claims that time to market is six times greater with a multivendor virtualization project than a single-vendor one.

Telefónica’s Blanco agrees that multivendor deployment will not save money in the short to medium term, but will bring other benefits such as agility and access to the best innovations, now and in future. “It is easier to do with a single vendor in a single core and it will be cheaper,” he told attendees at the recent 5G Core Summit in Madrid. But for the operator’s 5G core, single-vendor proposals are being rejected out of hand.

So it remains to be seen whether NFV 4 will be too little too late, or really will restore the technology to its old position as the foundation of network virtualization. Its progress started to stall as the industry’s efforts fragmented at higher layers, notably with the stand-off between separate ETSI and Linux Foundation efforts to set standards for management and orchestration (MANO). In addition, early deployments were seen as expensive and cumbersome, and operators started to hold out for cloud-native systems.

Earlier this year, ETSI announced closer ties between NFV and 5G, to make Release 3 more appealing to MNOs. This makes sense – a radio-neutral approach might have been preferable in the early days, but now very few operators, contrary to expectations when NFV was first released, are embarking on major standards-based virtualization roll-outs in 4G. There are proprietary systems, especially in China; some virtualized 4G cores in operation, though mainly for smaller-scale or greenfield applications; a couple of MNOs planning cloud-native 4G, notably Rakuten.

However, for most, large-scale virtualization of key network elements will come with 5G – and often, especially in the case of the vRAN, only in a second phase of 5G build-out, when the business case demands that the operator makes the complex migration to the 5G core, and to a significantly different RAN platform, which can support all the 5G capabilities including those for Industrial IoT, rather than just faster broadband.

So ETSI has been working more closely with 3GPP to ensure that its new NFV updates have more intrinsic 5G support in areas like resource management, orchestration and network slicing within a dynamic, virtualized mobile environment. Its NFV Industry Specifications Group (ISG) has been collaborating with 3GPP’s SA5 Working Group on the network and application management aspects of NFV, so that the 3GPP-defined management system interacts with ETSI NFV MANO.

The first two of the new updates are being layered on top of NFV Release 2, first published in 2016. They will ensure interoperability between a 3GPP-defined management system and ETSI’s NFV MANO system. This will support resource management for virtualized core networks, virtualized RAN and network slicing. They will join a release that was focused more broadly on management of virtualized resources; lifecycle management of network services and VNFs; performance management; and virtualized resource capacity management. At the time, there was no mention of 5G, since those standards were too immature to be fully integrated.

More recently, ETSI added the first specs within Release 3, which does include specific 5G focus. This added support for network slicing in NFV, management over multi-administrative domains, and multi-site network connectivity.

“These features are essential to address the variety of applications expected to run on top of a 5G system, whether using distributed resources over multiple sites, centralized or a combination of both,” ETSI said. These features will not, however, be ‘backported’ to Release 2.

In addition, NFV network slicing was defined as a composite element of the 3GPP SA5 network slice subnet architecture, which will make it easier to deploy the 3GPP SA5 Network Resource Model and the ETSI NFV Information Model together.