This section outlines the CNF requirements and how CNF can be onboarded and instantiated in Telco Cloud Platform RAN.

HELM Charts

Helm is the default package manager in Kubernetes, and it is widely leveraged by CNF vendors to simplify container packaging. With Helm charts, dependencies between CNFs are handled in the formats agreed upon by the upstream community. This allows Telco operators to consume CNF packages in a declarative and easy-to-operate manner. With proper version management, Helm charts also simplify workload updates and inventory control.

Helm repository is a required component in the Telco Cloud Platform RAN. Production CNF Helm charts must be stored centrally and accessible by the Tanzu Kubernetes clusters. To reduce the number of management endpoints, the Helm repository must work seamlessly with container images. A container registry must be capable of supporting both container image and Helm charts.

CSAR Design

Network Function (NF) Helm charts are uploaded as a catalog offering wrapped around the ETSI-compliant TOSCA YAML (CSAR) descriptor file. The descriptor file includes the structure and composition of the NF and supporting artifacts such as Helm charts version, provider, and set of pre-instantiation jobs. RAN Network Functions have sets of prerequisite configurations on the underlying Kubernetes cluster. Those requirements are also defined in the Network Function CSAR. The summary of features supported by the CSAR extension is:

  • SR-IOV Interface configuration and addition, along with DPDK binding

  • NUMA Alignment of vCPUs and Virtual Functions

  • Latency Sensitivity

  • Custom Operating system package installations

  • Full GRUB configuration

The following table outlines those CSAR extensions:

Component

Type

Description

node_components

Kernel_type

Type of Linux Kernel and version.

Note: Based on the Kernel version and type, Telco Cloud Automation downloads and installs from VMware Photon Linux repo during Kubernetes node customization.

kernel_args

Kernel boot parameters.

Required for CPU isolation and so on. Parameters are free-form text strings. The syntaxes are as follows:

  • Key: the name of the parameter

  • Value: the value corresponding to the key

Note: The Value field is optional for those Kernel parameters that do not require a value.

kernel_modules

Kernel Modules are specific to DPDK. When the DPDK host binding is required, the name of the DPDK module and the relevant version are required.

custom_packages

Custom packages include lxcfs, tuned, and pci-utils.

Note: Telco Cloud Automation downloads and installs from VMware Photon Linux repo during node customization.

network

deviceType

Type of network device. Example: SR-IOV.

resourceName

The label in the Network Attachment Definition (NAD).

dpdkBinding

The PCI driver this device must use. Specify "igb_uio" or "vfio" for DPDK or any equivalent driver depending on the vendors.

count

Number of adapters required

caas_components

CaaS components define the CaaS CNI, CSI, and HELM components for the Kubernetes cluster.
CSAR files can be updated to reflect changes in CNF requirements or deployment models. CNF developers can update the CSAR package directly within the TCA designer or leverage an external CICD process to maintain and build newer versions of the CSAR package.

Design Recommendation

Design Justification

Design Implication

Deploy all containers using the TCA Manager interface.

Direct access to the Kubernetes cluster outside of the Kubernetes cluster admin is not supported.

Some containers may not be available with a CSAR package to be deployed through Telco Cloud Automation.

Define all CNF infrastructure requirements using the TOSCA CSAR extension.

When infrastructure requirements are bundled into the CSAR package, Telco Cloud Automation provides placement assistance to locate a Kubernetes cluster that meets CNF requirements.

If Telco Cloud Automation cannot place the CNF workload due to the lack of resources, it leverages the node Operator to update an existing cluster with the required hardware and software based on the CSAR file definition.

CNF developers must work closely with CNF vendors to ensure that the infrastructure requirements are captured correctly in the CSAR file.

Store the TOSCA-compliant CSAR files in a GIT repository.

  • GIT repository is ideal for centralized change control.

  • CSAR package versioning, traceability, and peer review are built into GIT when a proper git-flow is implemented and followed.

Git and Git-flow are outside the scope of this reference architecture guide.
For more information about configuring a CSAR package, see the Telco Cloud Automation User Guide.
Note:

VMware offers a certification program for CNF and VNF vendors to create certified and validated CSARs packages.