CNF requirements

Copy link

You must package the CNF components as a set of containers and deploy them by using Kubernetes-native constructs. You must manage the CNF by using an Operator or a Helm chart that meets Red Hat certification requirements and supports the Deep Insights or Auto-Pilot capability levels to handle complex telco-grade configurations.

Ensure that the CNF follows these cloud-native principles:

• Containerized deployment
• Declarative configuration
• Automated lifecycle management
• Scalability and resiliency within Kubernetes

You must configure the CNF to support non-root execution and comply with OpenShift restricted Security Context Constraints (SCC). If you need specialized kernel access for technical reasons, you must clearly document that requirement.

OpenShift interoperability requirements

Copy link

Verify that the CNF operates correctly on supported OpenShift versions and underlying operating systems (Red Hat Enterprise Linux and Red Hat Enterprise Linux CoreOS). You must validate all components on these platforms.

Integrate the CNF with relevant OpenShift platform capabilities, such as:

• Kubernetes networking, including Multus when required
• Storage services
• Monitoring and logging frameworks
• OpenShift Virtualization, if applicable

You must identify and verify dependencies on specific cluster features or operators, such as the Node Tuning Operator, Precision Time Protocol (PTP), SR-IOV Network Operator, or Performance Add-on Operators (for example, CPU pinning and HugePages), during certification.

You must document any limitations, prerequisites, or unsupported scenarios in your product documentation.

CNF lifecycle management requirements

Copy link

The CNF must support highly available or hitless upgrade patterns to maintain network traffic continuity. The lifecycle management mechanism must manage the state of the network function during both minor and major updates.

You must provide automated installation, upgrade, scaling, and rollback through a supported lifecycle management mechanism, such as an Operator or Helm-based workflow, consistent with the CNF’s packaging and operational model. Upgrades must minimize service disruption, and you must document any required maintenance windows or manual steps and the expected behavior of network traffic during CNF pod restarts or node failures.

Certification applies to the tested OpenShift minor release. You must recertify the CNF for each OpenShift minor release to ensure continued compatibility with the underlying kernel and real-time capabilities.

CNF test compliance

Copy link

The workload must pass applicable functional verification tests through the Red Hat Best Practices Test Suite for Kubernetes, demonstrating correct operation on OpenShift, including networking, platform compatibility, performance, resiliency, operator, and lifecycle scenarios relevant to telecom and network workloads.

If the CNF uses technologies such as SR-IOV or DPDK, the CNF must undergo mandatory performance testing to verify that it maintains throughput, latency, and packet processing requirements within the OpenShift environment.

Depending on the CNF use case, you might require additional certification programs or test suites.

Multi-architecture requirement

For CNF certification, you must perform testing for each supported architecture under a single functional certification.

• Produce separate test results for each supported architecture.
• Submit the test results and credit them to the same functional certification.
• If you add architectures later, submit them through a new supplemental certification. You must link this supplemental certification to the original functional certification for display in the Red Hat Ecosystem Catalog.