Sponsored By
The next big thing for NFV is cloud-native VNFs, and while several large service providers have thrown their support behind the concept, there's still some heavy lifting that needs to take place.
In this Telco Transformation Q&A, Pål Grønsund, senior research scientist at Telenor Research, describes what cloud-native VNFs are, how there needs to be standardization, and the benefits cloud-native VNFs offer communications service providers. Grønsund joined Telenor ASA in 2007 and in his current role he is mainly focused on NFV, SDN, orchestration and hybrid clouds.
With more than 211 million subscribers across Europe and Asia, Norway's Telenor Group (Nasdaq: TELN) is one of the largest mobile service providers in the world. In addition to kicking the tires on cloud-native VNFs, Telenor is actively engaged in virtualizing its network as well as exploring how it will roll out IoT and 5G. (See Food for Thought With Telenor's Sandberg and Telenor's Sandberg Faces 5G, NFV Dilemma.)
Telco Transformation: Operators want cloud-native VNFs, BSS and OSS systems. What does this mean for operators, their IT support systems and their cloud infrastructure?
Pål Grønsund: When moving into cloud-native VNFs the cloud infrastructure must support light-weight containers as the virtualization technology. The cloud infrastructure must also support cloud services such as common state databases, load balancers and firewalls.
In defining a set of domains of functions, such as network, IT and digital services, the digital services are already moving towards cloud-native design. These are often using public clouds with support for containerization and micro-services design. Regarding VNFs the software design has some way to go before becoming cloud-native. Also, the container technologies have some way to go before being able to support container packaged VNFs, for example, support for networking/SDN and security. NFV infrastructures, management and orchestration also need to have support for containerization. On the IT side, many of the application software designs are not yet cloud-native.
TT: What does this mean for the companies service providers are working with?
PG: Operators need to work with other companies when defining the architecture, solutions and transitions and on how to achieve cloud-native VNFs, OSS and BSS systems. It is important to follow and contribute to standardization and open source in these areas to achieve interoperability and common architectural components to enable work with partner companies.
Common orchestration and application management architecture and solutions are important and need to be worked out across the industry and between companies. When moving toward cloud-native VNFs, it is very much about stateless designs, better performance and the reusability of components. This often requires a redesign of the VNF implementation and changes to the software architecture. Furthermore, this might lead to architectural changes where the VNF is decomposed into reusable and efficient components. This might involve architectural changes to network functions where we need to consider standardization in, for example, 3GPP to obtain interoperability on that level. The cloud infrastructure also needs support for cloud-native VNFs and sofware for application automation to obtain self-managed VNFs.
Examples of things we do in Telenor Research with companies include research involving lab work on experimentation and testing of new concepts and solutions. We work with companies in Open Source MANO (OSM) on orchestration and management, and we also work in international collaborative research projects on orchestration and control plane toward 5G with many companies.
TT: What is the relationship between cloud-native and popular new technologies such as SDN, NFV, containers and virtualization?
PG: NFV first uses virtual machine technology to realize the virtualization of network functions. The next step will be to use container packaging and the NFV platforms will also be able to manage and orchestrate container packaged VNFs. These are different technologies to virtualize the applications into functions that can run on a common cloud infrastructure as isolated applications. NFV platforms will be able to support both virtualization and container technologies. When it comes to networking, SDN also needs to support networking for containers as it does for virtual machines today.
TT: Like any new technology, cloud-native is defined a bit differently by different companies. What is your definition?
PG: Container-packaged, micro-service designed and self-managed. Most often state-less design.
TT: How will clouds for NFV be different than the cloud use we have today and where will they be located?
PG: When it comes to the distance of the cloud it is clear that the cloud for NFV has to be more distributed than many of today's clouds because of latency and regulatory concerns. For many of the VNFs, they must be present in the actual country they are serving because of regulatory and/or latency concerns. For the specific use case of Cloud-RAN, the vRAN VNFs might need to be even closer to the radio sites because of latency requirements. This will likely be a driver for also distributing other VNFs closer to the customers.
TT: How does cloud-native impact the actual programming? In other words, how does the actual app that is being developed -- as opposed to the process -- change?
PG: When moving toward cloud-native apps the apps are usually being decomposed into reusable and efficient components. For example, an app might be de-composed into load balancer, state database, control function and data plane function. The load balancer and state database might or might not be a service that the cloud infrastructure provides. The data plane function and control plane function might or might not be reusable across many different types of VNFs. This will require a re-design and new implementation of the VNF. Stateless VNF components must be considered where reasonable and possible.
TT: What steps is your organization taking for deploying cloud-native for VNFs?
PG: When deploying VNFs operators want them to be cloud-ready, which is optimizing the VNF design for running in the cloud when using virtual machine technology, such as state-less design. Cloud-native needs container technologies that are not ready yet for VNFs. We are doing research on cloud-native VNFs and work in labs.
TT: What advice would you give a telecom company that's just started to create applications using cloud-native?
PG: Look into state-less design to reduce the effect of VNF component failure and at the efficient redundancy model. Consider efficiency when decomposing the VNF into modular components. Consider re-usable components both on the data plane -- like the SDN switch -- and on control plane, such as authentication, session-database, load balancer and probe. Be aware of the standards for VNFs when doing this. When making light-weight components, consider the trade-off between efficiency, performance, complexity and re-usability.
— Mike Robuck, Editor, Telco Transformation
