Our exploration of CNFs comes from their use in deploying traditional telecommunications functions. In Anatomy of a CNF – Part 1 and Part 2 of the series, we discuss the term CNF and the container image, a vital subcomponent of a CNF. Part 3 of Anatomy of a CNF focuses on container image storage, and we discuss supporting resources in Part 4 of the CNF series. Finally, in Part 5, we saw how Helm and Help Charts enable the setup and deployment of considerable resources. Beyond container images and Helm Charts, we need to obtain one more key file from a CNF vendor before deployment. The key file is a Virtualized Network Function Descriptor (VNFD) packaged in a Cloud Service Archive (CSAR) file.
A key challenge in cloud-native network services is the packaging, distribution, and deployment across different cloud platforms and infrastructures. CSARs and VNFDs are standard formats and specifications that define packaging and describe cloud-native network services and their components, enabling interoperability and portability across different vendors and platforms.
CSAR is a file format that contains all the artifacts needed to instantiate a cloud service on a cloud platform. The CSAR file is an archive, think zip file, that will store many elements depending on the needs of the CNF vendor. For example, a CSAR file can include executable code, configuration files, scripts, metadata, licenses, and documentation. A CSAR file can also contain nested CSAR files for sub-services or components.
VNFD stands for Virtual Network Function Descriptor. Within ETSI, the name CNF is not used how we use it, and a VNF is the only defined type of software-based network function. Therefore, if we look at the ETSI documentation, we will only see VNFDs. However, some vendors continue to use the term, some call it a Containerized Network Function Descriptor (CNFD), and others call it a Network Function Descriptor (NFD). For simplicity, I will use NFD. The NFD is a specification that defines the structure and characteristics of a containerized network function or cloud-native network function, which is a software implementation of a network function that can run on a virtualized infrastructure. A NFD describes the CNF's requirements, capabilities, dependencies, interfaces, lifecycle events, and policies. A NFD can also reference one or more CSAR files that contain the actual implementation of the VNF.
The NFD is a critical component of the CSAR package, and the NFV Orchestrator (NFVO) uses it to deploy and manage the CNF. In practice, I have seen that a NFD will point to the Helm Chart or charts needing deployment. In addition, the Helm Charts will have references to the specific container images needing deployment. All three are required to deploy the CNF successfully, and the CNF vendor must provide all three.
In the final blog in this series, Anatomy of a CNF – Part 7 will look at the NFD in more detail and focus on the language used to write the NFD. Topology and Orchestration Specification for Cloud Applications (TOSCA) and YAML Ain't Markup Language (YAML) help us write the descriptor that describes how to deploy and manage a CNF.
Chris Reece, Technologist, Award Solutions, Inc.
Chris Reece works with leading global service providers, transforming networks and empowering individuals in 5G, Virtualization/Containerization, and Machine Learning/Artificial Intelligence. Service providers rely on Chris to paint both the big picture and the business impact of technology and appreciate his enthusiasm for getting into deep, detailed discussions when needed. You may have seen Chris on Award Solutions' YouTube Channel. In addition, Chris is featured at leading telecom conferences worldwide, including MWC, and in publications like IEEE Spectrum and DZONE.
Chris holds a master's degree in Computer Science Telecommunications from the University of Missouri at Kansas City and a bachelor's degree in Computer Science and Mathematics from Cameron University. He also holds four patents in wireless technologies.