NFV FAQ

Will VNFs be soon replaced with CNFs?

No. The question should not be put in these terms. The VM-based VNF deployments will be complemented with Container-based deployments. This will give VNF designers and network operators more choice while still making use of a common management system. CNF stands for Cloud-native Network Function. A CNF is a particular type of VNF. It’s a VNF that is designed, deployed and managed using cloud native technologies. This in practice means that the VNF is deployed using container technologies. This also implies that the VNF is designed according to cloud-native design patterns. In ETSI GS NFV-EVE 011, such a VNF is simply known as a Cloud Native VNF.

Is it true that VNFs are monoliths running in virtual machines while CNFs are made of small independent components running in containers?

No. Most VNFs are made of multiple components, known as VNFCs, irrespective of whether these components are running in virtual machines or containers. It should be observed that NFV specifications do not make any assumption on the size of a component in terms of code and/or functional scope. However, container-based technologies are an incentive for creating smaller components as the overhead per component is less than for VMs (e.g no OS replication).

Is it true that NFV in general and NFV-MANO in particular have not been designed for deploying network functions at the edge?

NFV specifications do not make any assumption on the location of NFVI-PoPs (Points of Presence) and in many cases an NFVI is implemented as a distributed multi-site cloud infrastructure. The seminal White Paper published in 2012 goes even further by stating that VNFs could even be hosted in customer premises.

Is it true that NFV-MANO is too complex?

By separating things that were traditionally integrated by network functions vendors, NFV makes some aspects of network management and operations more complex by nature (e.g. fault correlation), irrespective of the purported NFV-MANO complexity itself. However, the increase in complexity is expected to be alleviated through increased automation of management tasks and processes, as already alluded to in the seminal White Paper published in 2012. In addition, having more dynamic lifecycle of software functions instead of being bound to hardware lifecycles, makes the management more complex by nature.

Clause from First NFV White Paper, Oct 2012

“Network Functions Virtualisation will only scale if all of the functions can be automated”

Furthermore, it should be observed that the NFV architectural framework is a functional view of an NFV system. NFV specifications do not preclude simple implementation scenarios where multiple functional blocks (e.g. NFVO, VNFM and EM) are combined into a single software package integrated by a single vendor or software community.

What's the role of SDN with NFV?

The terms NFV and SDN have very often been used jointly and that might give the impression that SDN is a basic element in the NFV Architecture. The mindset of SDN and NFV are quite common and both contribute to a software-centric and automated approach to network management, with the aim to make it more agile and cost effective, however, technically they are different. They both contribute to pushing a software-centric and automated approach to network management, with the aim to make it more agile and cost effective. They both contribute the disaggregation of network functions on different axes: control and user plane separation for SDN, hardware and software for NFV.

SDN is an important concept and derived technology that greatly improves the control and management of the NFV infrastructure network. Conversely, the functional blocks of an SDN architecture can be deployed in the form of virtualised network functions hosted in an NFV infrastructure. However, SDN is not a mandatory technology to fulfil NFV.

Clause from First NFV White Paper, Oct 2012 “NFV is highly complementary to Software Defined Networking (SDN), but not dependent on it (or vice-versa). NFV can be implemented without an SDN being required, although the two concepts and solutions can be combined and potentially greater value accrued.”

What is the difference between NFVO Vs VNFM?

NFVO and VNFM are both functional blocks of the NFV-MANO, Management and Orchestration Architectural Framework.

The VNFM is responsible for the Life Cycle Management (LCM) of VNF(s). This includes supporting interface operations and execution of workflows for:

• Instantiate VNF (create a VNF using the VNF on-boarding artefacts).
• Scale VNF (increase or reduce the capacity of the VNF).
• Heal VNF (corrective actions to repair a faulty VNF, and/or its VNFC instances and internal VNF Virtual Link(s))
• Change VNF flavour (changing the flavour, i.e., the deployment options, of a already deployed VNF)
• Operate VNF (changing the state of a VNF instance)
• Modify VNF information (support VNF configuration and information changes).
• Change external VNF connectivity (changing the external connectivity of a VNF instance)
• Terminate VNF (release VNF-associated NFVI resources and return it to the NFVI resource pool).

The VNFM is also responsible of VNF performance, fault and configuration management.

The NFVO is responsible for managing the Network Service (NS) lifecycle, in conjunction with VNF lifecycle (supported by the VNFM), and orchestrating NFVI resources (supported by the VIM) to ensure an optimized allocation of the necessary resources and connectivity. As a result, NFVO functions can be classified into two main categories: End-to-end resource orchestration, and Network Service orchestration. NFVO is also responsible of NS performance and fault management as well as VNF package management. Similarly as with VNF LCM, NS lifecycle is related to a number of supported operations and execution of workflows, such as those used to instantiate, scale, heal and terminate an NS, as well as diverse type of updates, e.g., adding/removing VNF instances to/from an NS, etc.

Can NFVO & VNFM be combined in a single entity?

NFVO and VNFM are functional blocks providing different functionalities as specified in the NFV Architectural Framework. However, actual implementations can, as with many functional architectures, subsume both functionalities into one single entity.

What is the best practice for VNF deployment? Is it VM based or Container based?

Most of the current Telco NFV deployments are based on VMs, and that suits most of the VNF implementations currently provided in the market.

However, more recent implementations are starting to introduce VNFs based on containers. The use of container-based virtualisation is getting more consideration, due to the industry momentum introduced by the requests for cloud-native VNFs.

One benefit of using container technologies is that it is possible to run more VNFC instances on the same physical host and these instances start quicker, since there is less overhead compared to VM-based technologies.

Can EM and VNFM be combined in a single entity?

EM and VNFM are functional blocks providing different functionalities as specified in the NFV Architectural Framework. However, actual implementations can, as with many functional architectures, subsume both functionalities into one single entity.

What is the difference between VNFM and EM?

On the one hand, the VNFM is responsible for the lifecycle management of the VNF from a resource viewpoint, like instantiation, scaling, etc. (refer also to Q2). On the other hand, the EM is responsible of FCAPS (fault, configuration, accounting, performance, and security) management of the actual network application residing in the VNF.

What is the difference between horizontal and vertical scaling?

Scaling can be categorized into two classes: horizontal scaling and vertical scaling. In turn, scaling, as it relates to the capacity of a managed entity, is used to increase or decrease such a capacity.

Taking the example of a VNF, horizontal scaling can be classified into two types

• Scale out: relates to increasing capacity, and it refers to a process where one or more VNFC instances are added to an existing application.
• Scale in: relates to decreasing capacity, and it refers to a process where one or more VNFC instances are removed from an existing application.

Following the example of a VNF, vertical scaling can be classified into two types

• Scale up: relates to increasing capacity, and it refers to a process where resources (e.g., CPU/Memory) are added to an existing VNFC instance.
• Scale down: relates to decreasing capacity, and it refers to a process where resources (e.g., CPU/Memory) are released from an existing VNFC instance.

Scaling can be triggered automatically whenever a certain pre-configured policy (e.g. regarding to CPU utilization) is activated, or by an explicit request, e.g., by an operator.

For example, an auto scale policy in the NFV ecosystem may imply that the system should scale out if CPU utilization exceeds 70% and scale in if CPU utilization goes below 20%.

VNF scaling can be triggered from several sources:

• NFVO
• VNFM
• VNF/EM (Element Manager)
• OSS/BSS
• Manually by an operator

A lot of packet processing solutions such as DPDK features work on specialized HW. How can VNF implementers assure the performance on commodity HW but not on proprietary?

DPDK requires compatible HW, namely compatible Network Interface Cards (NIC) and CPU models. However, unlike some other acceleration technologies, DPDK does not require specialized processors.

Moreover, although initially designed for the x86 ecosystem, DPDK is not a vendor-specific feature and recent versions are not related much to a specific hardware. Nowadays, DPDK is an open source community-driven software solution (software libraries) for enhancing packet processing. DPDK has evolved into a large ecosystem, with lots of different NIC cards and processors being supported, thus not tied to a certain HW or vendor solution. Despite the availability of DPDK for a variety of platforms, guaranteeing the performance requires joint lab/testing work between the VNF implementers and infrastructure providers along with the vertical NFV stack.

Besides DPDK, other acceleration solutions include adding specialized processors to a commodity server (e.g. SmartNIC with embedded processor) to enable off-loading part of the traffic processing from the main general-purpose processor to these specialized or programmable processors.

How do you evaluate the operators’ contributions in NFV and in open-source initiatives?

The first NFV White paper published in Oct 2012 was a result of a cooperation of Tier-1 Operators (ref. Network Functions Virtualisation – Introductory White Paper).

Since that time, the ecosystem has expanded to reach more than 300 companies/organizations, including 39 network operators, in the ETSI NFV ISG. NFV ISG was spun as an operator-led industry initiative to raise awareness and foster all industry stakeholders to provide interoperable solutions following the NFV vision. Operators’ contribution has extended to participate directly in upstream communities like OpenStack and mid-stream communities such as OPNFV. Operators have also spun other market-leading open-source initiatives such as OSM, and ONAP, in addition to the standardization efforts done by all in ETSI NFV and other SDOs.

What is the exact role of hypervisors in NFV?

A hypervisor is a piece of software that partitions the underlying HW physical resources (CPU, memory, storage, networking cards), generates virtual machines, and allocates the portioned resources to them.

A virtual machine, on the other hand, behaves typically as a physical server that has all the ingredients needed for a physical server (CPU, memory, storage, NIC).

In NFV, the hypervisor is the “virtualisation layer” enabler of the NFVI for the case when virtualised compute resources are delivered in the form of VMs.

Can operator reuse existing hardware/infrastructure that is near end of life to be part of NFVI, e.g. 2G infrastructure if the operator is decommissioning it?

Most of the old telco platforms are special-purpose hardware that can’t be used decoupled from their application software, which is actually one of the main concepts and drivers behind NFV.

Whether specific hardware can be reused may depend on a case-by-case basis, upon analysis by the operator and equipment suppliers.

Why is NFV for the Mobile Core only now being introduced (e.g. LTE/EPC) and not earlier, particularly for the CDMA PS Core (PDSNs) and other Network Functions such as BSC/RAN?

The selection of the network functions that are to be virtualised is subject to many criteria, either from the operator side or the vendor side. Factors that can influence what network functions are delivered as virtualised include: the network function software readiness to be run on a virtualised platform, market demand, end of life of existing hardware, and others. One of the other factors is the network function goal itself. For example, if it is a heavy transcoding workload, the virtualisation of such function could impact the performance of the network function, and its virtualisation thus be delayed until the virtualised infrastructure is capable to deliver the needed performance.

In the standard, there are two reference points, one between VNFM and VNF, and another one between VNFM and the EM for VNF. Are both reference points carrying the same type of functionality?

The Ve-Vnfm-em reference point is used for exchanges between EM and VNF Manager. The Ve-Vnfm-vnf reference point is used for exchanges between VNF and VNF Manager. They share some common functionalities, for example, the VNF Indicator interface which is the information supplied by the VNF or the EM to provide some indication of the VNF behavior. VNFM can use these indicators in conjunction with virtualised resource data to perform auto-scaling decisions. Also, both reference points share most of the operations of the VNF Lifecycle Management interface produced by the VNFM and consumed by the EM and/or VNF.

One of the differences is the VNF Configuration interface which is available only on the Ve-Vnfm-vnf. The VNF Configuration interface on the Ve-Vnfm-vnf reference point supports setting or updating virtualisation-related configuration parameters for a VNF/VNFC instance.

Can we have independent and multi-vendor VIM, VNF Manager and NFV Orchestrator in a real deployment?

Yes, such a multi-vendor setup is possible. In this case, system integration efforts need to consider all three reference points between VIM, VNFM and NFVO. The REST APIs that ETSI NFV is specifying are intended to enable multi-vendor solutions.

See: http://www.etsi.org/blog-subscription-information/entry/one-more-step-towards-nfv-mano-interoperability.and https://nfvwiki.etsi.org/index.php?title=SOL_OpenAPI_Representations.

Is the VNF Manager a kind of cloud management platform?

The VNF Manager is the entity responsible mainly for the VNF lifecycle management, as well as for some fault management, performance management and configuration management functionality.

In the context of NFV, the cloud management platform is represented by the VIM (Virtualised Infrastructure Manager).

Both the VNFM and the VIM focus on managing virtualised resources, although the VNFM exposes management services at a higher level of abstraction and granularity than the VIM (i.e. VNF/VNFC instances vs. individual virtualised resources).

Does NFV focus only on virtualising the telecom network functions?

Any enterprise or environment that share the same characteristics and the requirements of NFV (for example, carrier-grade performance, high availability, telco-like workloads) can leverage the potentials of NFV and the framework defined by ETSI NFV.

Why do we need to use SDN, if NFVO can perform the same functions?

This is not correct. The two entities have different roles. NFVO is mainly responsible for resource orchestration and Network Service orchestration while the SDN in an NFVI PoP (a.k.a. DC SDN) is typically responsible for DC networking.

When it comes to the networking part of the network service; the inter-VNF paths or links are defined as part of Network Service Descriptor and are processed by the NFVO. This information is used to derive the contents of the requests sent to VIM, which in turn can delegate the configuration of the infrastructure routers and switches to SDN.

So, we may say the definition comes from NFVO and configuring the agents/hosts is being done by VIM/SDN.

From a performance point of view, is it enough to monitor the application layer KPIs or is it a must to monitor cloud layer performance as well?

From a FM/PM perspective, an operator needs to perform E2E monitoring for the whole vertical stack for NFV. Therefore, getting the application counters and alarms from an EM is not enough. SW/HW faults and counters need to be monitored by introducing the relevant infrastructure monitoring tools.

Having the right set of tools at hand will allow operators to have an efficient root-cause analysis (RCA) solution for the network services and VNFs. Faults and performance reports related to virtualised resources should be sent by the NFVI to the VIM and propagated/correlated by the VNFM and NFVO up to the OSS and/or the EM or the VNF itself. The NFVO and the VNFM may also take some immediate actions on some events.

Is it true that NFV-MANO does not take into account physical network functions?

No. The NFVO can manage hybrid network services combining VNFs and PNFs. However, NFV-MANO does not manage the lifecycle of PNF resources. From an NFVO viewpoint, PNFs are black-box entities exposing a number of connection points.

Is it true that NSs can be nested but only one level of nesting is permitted?

No. There is no theoretical limit to the number of nesting levels. Although in practice this number is expected to be low.

ETSI specifies REST APIs enabling multi-vendor interoperability at some of the reference points of the NFV Architectural Framework. Can I use these APIs if my architecture differs from the NFV architectural framework?

It all depends on how significant are the differences. For example, the APIs specified in ETSI NFV-SOL 003 for the or-Vnfm reference point can hardly be used if the functional split between the NFVO and the VNFM does not comply with ETSI standardization or if the two functional blocks are subsumed into a single entity. However, this does not prevent using the APIs specified in ETSI GS NFV-SOL 002 for the Ve-Vnfm reference point. Moreover, the APIs specified in an ETSI GS are independent from each other’s. For example, different APIs specified in ETSI GS NFV-SOL 005 can be consumed by different OSS components.

Does PNF dependability differ from VNF resiliency?

The two terms cover the same concept, which is the ability to limit disruption and return to normal or at a minimum acceptable service delivery level when facing a fault, failure, or an event that disrupts the normal operation.

---

Acknowledgement: The Q&A (No.5-22) were originally contributed by STC (Saudi Telecom Company).

---

Link

Go to NFV Solutions page

Go to NFV wiki main page

Go to ETSI ISG NFV page