Merge pull request #81822 from aireilly/TELCODOCS-1684-RAN-and-Core-4.17-RDS

TELCODOCS-1684 - RAN and Core 4.17 RDS updates

Author: stevsmit

_attributes/common-attributes.adoc

@@ -1,3 +1,4 @@
+:_mod-docs-content-type: SNIPPET
 // The {product-title} attribute provides the context-sensitive name of the relevant OpenShift distribution, for example, "OpenShift Container Platform" or "OKD". The {product-version} attribute provides the product version relative to the distribution, for example "4.9".
 // {product-title} and {product-version} are parsed when AsciiBinder queries the _distro_map.yml file in relation to the base branch of a pull request.
 // See https://github.com/openshift/openshift-docs/blob/main/contributing_to_docs/doc_guidelines.adoc#product-name-and-version for more information on this topic.
@@ -44,6 +45,7 @@ endif::[]
 :product-mirror-registry: Mirror registry for Red Hat OpenShift
 :rh-storage-first: Red Hat OpenShift Data Foundation
 :rh-storage: OpenShift Data Foundation
+:rh-rhacm-title: Red Hat Advanced Cluster Management
 :rh-rhacm-first: Red Hat Advanced Cluster Management (RHACM)
 :rh-rhacm: RHACM
 :rh-rhacm-version: 2.11

edge_computing/policygentemplate_for_ztp/ztp-advanced-policy-config.adoc

@@ -47,6 +47,8 @@ include::modules/ztp-using-pgt-to-configure-performance-mode.adoc[leveloffset=+2
 
 include::modules/ztp-using-pgt-to-configure-high-performance-mode.adoc[leveloffset=+2]
 
+* xref:../../edge_computing/ztp-reference-cluster-configuration-for-vdu.adoc#ztp-du-configuring-host-firmware-requirements_sno-configure-for-vdu[Configuring host firmware for low latency and high performance]
+
 include::modules/ztp-using-pgt-to-configure-power-saving-mode.adoc[leveloffset=+2]
 
 [role="_additional-resources"]

images/313_OpenShift_SR-IOV_NIC_sharing_0323.png

@@ -0,0 +1,26 @@
+// Module included in the following assemblies:
+//
+// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-design-components.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="telco-core-agent-based-installer-abi_{context}"]
+= Agent-based installer
+
+New in this release::
+* No reference design updates in this release
+
+Description::
+You can install telco core clusters with the Agent-based installer (ABI) on bare-metal servers without requiring additional servers or virtual machines for managing the installation.
+ABI supports installations in disconnected environments.
+With ABI, you install clusters by using declarative custom resources (CRs).
++
+[NOTE]
+====
+Agent-based installer is an optional component. The recommended installation method is by using {rh-rhacm-title} or {mce}.
+====
+
+Limits and requirements::
+* You need to have a disconnected mirror registry with all required content mirrored to do Agent-based installs in a disconnected environment.
+
+Engineering considerations::
+* Networking configuration should be applied as `NMState` custom resources (CRs) during cluster installation.

images/openshift-5g-core-cluster-architecture-networking.png

@@ -1,27 +1,36 @@
 // Module included in the following assemblies:
 //
-// * telco_ref_design_specs/core/telco-core-ref-design-components.adoc
+// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-design-components.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="telco-core-cluster-network-operator_{context}"]
-= Cluster Network Operator (CNO)
+= Cluster Network Operator
 
 New in this release::
-
 * No reference design updates in this release
 
 Description::
-
-The CNO deploys and manages the cluster network components including the default OVN-Kubernetes network plugin during {product-title} cluster installation. It allows configuring primary interface MTU settings, OVN gateway modes to use node routing tables for pod egress, and additional secondary networks such as MACVLAN.
-+
-In support of network traffic separation, multiple network interfaces are configured through the CNO. Traffic steering to these interfaces is configured through static routes applied by using the NMState Operator. To ensure that pod traffic is properly routed, OVN-K is configured with the `routingViaHost` option enabled. This setting uses the kernel routing table and the applied static routes rather than OVN for pod egress traffic.
-+
-The Whereabouts CNI plugin is used to provide dynamic IPv4 and IPv6 addressing for additional pod network interfaces without the use of a DHCP server.
+The Cluster Network Operator (CNO) deploys and manages the cluster network components including the default OVN-Kubernetes network plugin during {product-title} cluster installation. It allows configuring primary interface MTU settings, OVN gateway modes to use node routing tables for pod egress, and additional secondary networks such as MACVLAN.
 
 Limits and requirements::
-
 * OVN-Kubernetes is required for IPv6 support.
+
 * Large MTU cluster support requires connected network equipment to be set to the same or larger value.
 
+* MACVLAN and IPVLAN cannot co-locate on the same main interface due to their reliance on the same underlying kernel mechanism, specifically the `rx_handler`.
+This handler allows a third-party module to process incoming packets before the host processes them, and only one such handler can be registered per network interface.
+Since both MACVLAN and IPVLAN need to register their own `rx_handler` to function, they conflict and cannot coexist on the same interface.
+See link:https://elixir.bootlin.com/linux/v6.10.2/source/drivers/net/ipvlan/ipvlan_main.c#L82[ipvlan/ipvlan_main.c#L82] and link:https://elixir.bootlin.com/linux/v6.10.2/source/drivers/net/macvlan.c#L1260[net/macvlan.c#L1260] for details.
+
+* Alternative NIC configurations include splitting the shared NIC into multiple NICs or using a single dual-port NIC.
++
+[IMPORTANT]
+====
+Splitting the shared NIC into multiple NICs or using a single dual-port NIC has not been validated with the telco core reference design.
+====
+
+* Single-stack IP cluster not validated.
+
+
 Engineering considerations::
 * Pod egress traffic is handled by kernel routing table with the `routingViaHost` option. Appropriate static routes must be configured in the host.

images/telco-ran-du-reference-design-components-417.png

@@ -0,0 +1,29 @@
+// Module included in the following assemblies:
+//
+// * scalability_and_performance/telco_ref_design_specs/core/telco-core-rds-overview.adoc
+:_mod-docs-content-type: REFERENCE
+[id="telco-core-cluster-service-based-architecture-and-networking-topology_{context}"]
+= {rds-caps} cluster service-based architecture and networking topology
+
+The {rds-caps} reference design specification (RDS) describes a platform that supports large-scale telco applications including control plane functions such as signaling and aggregation. It also includes some centralized data plane functions, for example, user plane functions (UPF). These functions generally require scalability, complex networking support, resilient software-defined storage, and support performance requirements that are less stringent and constrained than far-edge deployments like RAN.
+
+.{rds-caps} cluster service-based architecture and networking topology
+image::openshift-5g-core-cluster-architecture-networking.png[5G core cluster showing a service-based architecture with overlaid networking topology]
+
+The telco core cluster service-based architecture consists of the following components:
+
+* Network data analytics functions (**NWDAF**)
+* Network slice selection functions (**NSFF**)
+* Authentication server functions (**AUSF**)
+* Unified data managements (**UDM**)
+* Network repository functions (**NRF**)
+* Network exposure functions (**NEF**)
+* Application functions (**AF**)
+* Access and mobility functions (**AMF**)
+* Session management functions (**SMF**)
+* Policy control functions (**PCF**)
+* Charging functions (**CHF**)
+* User equipment (**UE**)
+* Radio access network (**RAN**)
+* User plane functions (**UPF**)
+* Data plane networking (**DN**)

modules/telco-core-agent-based-installer-abi.adoc

@@ -1,16 +1,16 @@
 // Module included in the following assemblies:
 //
-// * telco_ref_design_specs/core/telco-core-ref-design-components.adoc
+// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-design-components.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="telco-core-cpu-partitioning-performance-tune_{context}"]
 = CPU partitioning and performance tuning
 
 New in this release::
-* In this release, {product-title} deployments use Control Groups version 2 (cgroup v2) by default. As a consequence, performance profiles in a cluster use cgroups v2 for the underlying resource management layer. 
+* No reference design updates in this release
 
 Description::
-CPU partitioning allows for the separation of sensitive workloads from generic purposes, auxiliary processes, interrupts, and driver work queues to achieve improved performance and latency. The CPUs allocated to those auxiliary processes are referred to as `reserved` in the following sections. In hyperthreaded systems, a CPU is one hyperthread.
+CPU partitioning allows for the separation of sensitive workloads from generic purposes, auxiliary processes, interrupts, and driver work queues to achieve improved performance and latency.
 
 Limits and requirements::
 * The operating system needs a certain amount of CPU to perform all the support tasks including kernel networking.
@@ -42,4 +42,5 @@ Engineering considerations::
 * Hardware without Interrupt Request (IRQ) affinity support will impact isolated CPUs. To ensure that pods with guaranteed CPU QoS have full use of allocated CPU, all hardware in the server must support IRQ affinity.
 * OVS dynamically manages its `cpuset` configuration to adapt to network traffic needs.
 You do not need to reserve additional CPUs for handling high network throughput on the primary CNI.
-* If workloads running on the cluster require cgroups v1, you can configure nodes to use cgroups v1. You can make this configuration as part of initial cluster deployment. For more information, see _Enabling Linux cgroup v1 during installation_ in the _Additional resources_ section.
+* If workloads running on the cluster require cgroups v1, you can configure nodes to use cgroups v1 as part of the initial cluster deployment.
+For more information, see "Enabling Linux cgroup v1 during installation".

modules/telco-core-cluster-network-operator.adoc

@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// *
+// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-crs.adoc
 
 :_mod-docs-content-type: REFERENCE
 [id="networking-crs_{context}"]
@@ -10,23 +10,23 @@
 [cols="4*", options="header", format=csv]
 |====
 Component,Reference CR,Optional,New in this release
-Baseline,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-network-yaml[Network.yaml],No,No
-Baseline,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-networkattachmentdefinition-yaml[networkAttachmentDefinition.yaml],Yes,Yes
+Baseline,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-network-yaml[Network.yaml],Yes,No
+Baseline,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-networkattachmentdefinition-yaml[networkAttachmentDefinition.yaml],Yes,No
 Load balancer,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-addr-pool-yaml[addr-pool.yaml],No,No
 Load balancer,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-bfd-profile-yaml[bfd-profile.yaml],No,No
 Load balancer,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-bgp-advr-yaml[bgp-advr.yaml],No,No
 Load balancer,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-bgp-peer-yaml[bgp-peer.yaml],No,No
-Load balancer,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-community-yaml[community.yaml],No,Yes
+Load balancer,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-community-yaml[community.yaml],No,No
 Load balancer,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-metallb-yaml[metallb.yaml],No,No
-Load balancer,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-metallbns-yaml[metallbNS.yaml],Yes,No
-Load balancer,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-metallbopergroup-yaml[metallbOperGroup.yaml],Yes,No
+Load balancer,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-metallbns-yaml[metallbNS.yaml],No,No
+Load balancer,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-metallbopergroup-yaml[metallbOperGroup.yaml],No,No
 Load balancer,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-metallbsubscription-yaml[metallbSubscription.yaml],No,No
-Multus - Tap CNI for rootless DPDK pod,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-mc_rootless_pods_selinux-yaml[mc_rootless_pods_selinux.yaml],No,No
-NMState Operator,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-nmstate-yaml[NMState.yaml],No,Yes
-NMState Operator,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-nmstatens-yaml[NMStateNS.yaml],No,Yes
-NMState Operator,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-nmstateopergroup-yaml[NMStateOperGroup.yaml],No,Yes
-NMState Operator,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-nmstatesubscription-yaml[NMStateSubscription.yaml],No,Yes
-SR-IOV Network Operator,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-sriovnetwork-yaml[sriovNetwork.yaml],Yes,No
+Multus - Tap CNI for rootless DPDK pods,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-mc_rootless_pods_selinux-yaml[mc_rootless_pods_selinux.yaml],No,No
+NMState Operator,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-nmstate-yaml[NMState.yaml],No,No
+NMState Operator,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-nmstatens-yaml[NMStateNS.yaml],No,No
+NMState Operator,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-nmstateopergroup-yaml[NMStateOperGroup.yaml],No,No
+NMState Operator,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-nmstatesubscription-yaml[NMStateSubscription.yaml],No,No
+SR-IOV Network Operator,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-sriovnetwork-yaml[sriovNetwork.yaml],No,No
 SR-IOV Network Operator,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-sriovnetworknodepolicy-yaml[sriovNetworkNodePolicy.yaml],No,No
 SR-IOV Network Operator,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-sriovoperatorconfig-yaml[SriovOperatorConfig.yaml],No,No
 SR-IOV Network Operator,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-sriovsubscription-yaml[SriovSubscription.yaml],No,No