The Changing Face of Telecommunications

  Insight Research, in its recent report “The VNFO…Ripe for change” has broken down the market by product profile. We consider two profile categories – Direct Open Source and Proprietary. Let us look closely at the categories. Insight Research has a very categorical definition for direct open source NFVOs - those that traverse the development journey directly from the open source community to the end-user. Thus open source offering that are internalized by OEMs and offered as proprietary NFVOs are not covered under direct open source. Open source initiatives have played a pivotal role in the journey of the orchestrator. ONAP, OSM, Nephio and Kubernetes are some of the prominent contributions of the open source community to the VNFO development; and have been therefore profiled at length in the report. What then is ‘direct’ open source? Open source initiatives have been utilized by various stakeholders in different ways. While in some cases have been used “as-is”; they have also be

The answer is yes. Our recent report “ The VNFO – Ripe for Change ” says this loudly and clearly. Pardon the atrocious image. But I hope it encapsulates the dilemma appropriately. It is important to reiterate the reasons for including containers under VNF and in essence, Kubernetes under VNFO. Both VMs and containers are virtualization methodologies. Thus, network functions synthesized using VMs and containers qualify as VNFs. In VNFs orchestrated by containers are sometimes referred to as cloud-native NFs (CNFs). Insight Research has also employed this term as early as 2020. Over time however, we have observed that the usage of CNFs is neither consistent nor uniform. Most ‘traditional’ MANOs such as ONAP, OSM and all proprietary offerings now support containers and Kubernetes. Containers are thus one more means towards achieving the end-objective of VNFs. In such situations, Insight Research finds it more appropriate to use VNF as an umbrella term and under this term, refer to VM or c