Container Management — Critical for 5G success
Containers are the route to realize what is being promised by 5G technology, i.e. agility with newer services. Telecom operators should now evaluate and implement container management in 5G networks alongside the existing 4G VNFs (virtual network functions). When in doubt, refer to standardization bodies for guidance. This post reference what is being laid out in ETSI GR NFV-IFA 029 v3.3.1 along with other considerations.
5G NR, 5G CN and 5G OSS/BSS [3GPP TS 23.501] are all getting containerized, Telcos need to firm up their strategy for managing this new ecosystem of cloud-native network functions along with existing VNFs. Multiple options are available based on Telco’s current architecture, operations, market roll-out and organizational maturity.
ETSI introduces concept of CISM (Container Infrastructure Service Management) to enhance current MANO architecture so that the lifecycle of new container network functions can be managed. CISM has two main aspects:
Functionality A: The management of managed container infrastructure objects with dynamic service resource allocation
Functionality B: The management of virtualized resources exposed by container runtime environment
We assume the NFVI layer will provide functionality for running both VMs and containers. VM based VNFs management is in production for quite some time and is mature and established. Existing tools and processes can handle running containers inside the VMs, as the NFV-MANO entities are unaware of the Container Infrastructure Service and the Container Infrastructure Service Management.
Running containers on native OS demands new functionality for NFV-MANO.
There are various options of mapping CISM to NFV-MANO. We are going discuss two of them here:
1. CISM functionality embedded in VIM
Existing VIM provider should enable CISM functionality. Most of current VIM deployment supports only VM/hypervisor-based virtualization. Interactions between new CISM modules and existing VIM needs to be agreed.
2. CISM as a stand-alone functional block
It is suggested to introduce a new functional block in NFV-MANO, which will carry out CISM functionality. The current VIM functionality remains intact, taking care of VM based VNFs. For the new network functions which are based on containers, the VIM layer will not be involved. This approach provides clear architecture implementation supporting standard interfaces. However, duplication of functions needs to be resolved with respect to managing virtualized resource management.
Both the options require more deliberation from operators & standard bodies. Applicability of correct option will depend on how current systems are architected, vendor specific implementation, roadmap towards next generation of services and in-house skills availability.
However, there are many open aspects that still need to be addressed, like new APIs, NBI & SBI interfaces, responsibility of NFVI in containerized world, separation of concerns among various functional blocks, etc.
Irrespective of the option Telco pursue, there are few tenets that should not be comprised when designing the lifecycle management solution for containers, like availability of common and Open APIs, performance, resiliency, availability and security.
Apart from standards, Telcos needs to explore merits and de-merits of below options when deciding the final architecture:
1. NEPs (Network Equipment Provider) provides both containers and corresponding container orchestration systems for the respective container network functions.
2. Telcos can look for current VIM providers to provide container orchestration system and let NEPs provide containerized network functions only
3. Telcos can build their own container orchestration & management platform and run various network functions from different network vendors
