Close
Close

Published

ETSI issues NFV templates to ease deployment, but has the ship sailed?

The large-scale commercial deployment of systems based on NFV (Network Functions Virtualization) may have been disappointing in its pace, but the ETSI specifications remain the bedrock of telcos’ transition to software-driven platforms – at least until the operator world moves forward and fully embraces the cloud-native approach coming from the cloud industry.

The standards body has lost the momentum to open source groups in some areas, notably in management and orchestration (MANO) of virtualized networks, where its own Open Source MANO (OSM) is competing with the Linux Foundation-hosted ONAP (Open Network Automation Protocol). But ETSI is also making significant moves to enhance NFV’s deployability and keep its hand on the steering wheel.

Last week, it published the first release of two specifications to standardize the structure and format of virtual network functions (VNFs) – an important project which will help make it easier to create and deploy VNFs, and for operators to adopt multivendor strategies. The idea is to offer deployment templates which mean any VNF can be implemented with any MANO system because the formats will be common to all.

ETSI said these new specs provide “the foundation of an open ecosystem”. One addresses NFV descriptors, basing these on the TOSCA specifications (ETSI GS NFV-SOL 001); the other covers the structure and format of a VNF package (GS NFV-SOL 004).

The aim will be to prevent VNFs going the same way as other attempts to open up the telco platform, which have ended with semi-proprietary implementations and new lock-ins. One of the factors which has delayed large-scale NFV adoption has been operators’ complaint that VNF suppliers – particularly the large OEMs seeking to protect their pole position in the value chain – have created their own VNF flavors. This limits interoperability and involves effort to configure, scale and rebuild the VNFs since they all work in different ways.

The risk to ETSI’s power over NFV, and more broadly in the telco industry, is that these issues will be addressed by open source alternatives, as MANO may be if ONAP wins out over OSM. ONAP itself, as well as OpenDaylight, have been addressing issues of creating and deploying VNFs in a standardized way, but ETSI says it is going a step further by offering deployment templates. These enable VNFs to be onboarded and managed “by independently developed MANO systems”.

Bruno Chatras, vice chair of the ETSI NFV group, told FierceTelecom: “It provides a standard way to describe VNFs, so they can be deployed and managed by NFV orchestrators. This has already been exercised in some early (ETSI) plugtests. ONAP, the open source community, uses it as one of the VNF descriptor formats accepted for its platform.”

BT’s chief architect, Neil McRae, supported ETSI’s model-based approach, which chimes in with BT’s own work on common service models based on TOSCA. “BT has been pushing a model-based architecture and approach, leveraging TOSCA and YANG models, for some time and we have done a lot of work on this at TM Forum. We welcome this,” he said in a statement supporting the NFV templates.

But others think NFV has been left behind before it even reached the big time, because its monolithic approach has been superseded by cloud-native approaches, pioneered in the cloud world. Last autumn, Vodafone’s Fran Heeran (now returning to Nokia) said that operators should move from NFV to cloud-native to get a wider range of benefits and far greater agility.

Close