What’s the matter with NFV and how do we fix it?
Interoperability between operators needs to be a top priority for the NFV community. Standards must be in place before deployments can really take off.
Recently, the telecom business press has been filled with critiques of NFV and SDN. While most of these critiques involve typical ecosystem and deployment problems that occur when a technology transitions from the “Peak of Inflated Expectations” to the “Trough of Despair” in the Gartner Hype Cycle, Tom Nolle, a well-known consultant and analyst, pinpoints a more fundamental problem with NFV in his blog post “What Would the ‘Right’ Model for SDN, NFV, and Virtualization Look Like?”
Nolle argues that, so far, the industry has ignored the most important component of NFV in need of standardization and indeed any technical focus at all. This is the binding functionality between the abstract service structure represented as a topology graph and real resources in an operator network, and it is the most critical aspect of NFV. Binding requires standardization in order for two implementations of resource binding in two different operator networks to interoperate. Apart from those resource binding functions, other management processes can be spawned on-demand in a particular locality. The binding functions are, in a sense, where the rubber meets the road and where a service template is actually instantiated into a real, deployed service that can provide something of value to customers.
Virtual infrastructure management as a service
Ericsson Research began wrestling with this problem already in 2013 in the EU-FP7 Unifying Cloud and Carrier Networks project, which investigated resource orchestration, basically the embedding or resource binding function that Nolle identifies in his blog post. Our approach was to put the resource binding function into the center of the recurring orchestration framework design (see R. Szabo et al "Elastic Network Functions: Opportunities and Challenges"). Combined with clear interfaces to virtualization lifecycle management functions, the resulting prototype allowed multi-provider scenarios to be easily created with fully flexible ownerships of software, infrastructure, service management and virtualization lifecycle management in a multi-layer virtualization framework. At the very top and very bottom, the model is fully conformant with ETSI’s Network Services and the Virtualized Infrastructure Managers (VIMs) (see Horizon 2020, 5G-PPP, 5G Exchange project).
The basic insight that came out of the Unifying Cloud and 5G Exchange programs was that virtual infrastructure management can, itself, be viewed as a service. For example, a VIM manager can manage a collection of containers in Container as a Service (CaaS), while, at the same time, VMs are being managed as a Service (VMaaS). In the figure below, two VNF managers are running in two different network operators, shown in red and green, providing resources for a service through a resource orchestrator (indicated by RO). The RO plays a key role between operators in instantiating a service. The customer request for a service comes in through the red operator, which then needs to co-ordinate with the green operator to provide resources for the service, through the inter-RO interface. This suggests that the interfaces around the resource orchestrator need to be standardized, and standardization should include an interface for enabling interoperability between service providers.
What happens when operators need to interoperate?
The binding interface between the resource orchestrator and the service orchestrator is a critical area in which additional technical work is required, in particular for interoperability between different operators and between different resource orchestrator and service orchestrator implementations. Most operators are today dealing with virtualizing their own platforms and have yet to face the difficulty of interoperating with other operators. For NFV to succeed, the community needs to pay attention to standardizing these interfaces well before operators reach the point where they face having to interoperate with other operators.
Developing Tosca to handle operator needs
For enterprise systems, industry outside of the Big Three cloud providers has decided on Tosca as a standard for modelling complex virtualized information services. Tosca is also used in operator networks, for example, support for Tosca is part of the NFVi open source ONAP project. This makes Tosca a logical candidate for standardized modelling of end-to-end (edge-to-edge) network service lifecycle management (e.g., NSO) and service component lifecycle management (e.g., VNFM) between and within operators and/or third-party solution providers. The problem is that Tosca was developed primarily for enterprise cloud systems. Most enterprise systems have fairly simple resource orchestration needs and, in particular, don’t require service and resource orchestration between administrative domains, so Tosca in its current form isn’t up to the task.
As we’ve seen in other areas of cloud, systems developed for enterprise deployment typically need more work before they are suitable for network operators. For example, OpenStack required additional work prior to being suitable for network operator deployment, which is why the OPNFV group was formed. We hope to be able to bring our deep experience with modelling service and resource orchestration to developing extensions to Tosca that have enough power and depth to handle network operator needs.