You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/en/docs/network-architecture/o-ran-integration.md
+22-38Lines changed: 22 additions & 38 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,6 +8,7 @@ weight: 5
8
8
## Overview
9
9
10
10
The O-RAN Software Community (OSC) and Open Air Interface (OAI) and Nephio open source communities are working together to provide a reference implementation of the Open RAN (O-RAN) Alliance’s cloud-centric specifications using the Nephio enablers and capabilities in order to deploy and manage O-RAN NFs and xApps.
11
+
11
12
The focus of the O-RAN Integration within Nephio focuses on the Federated O-Cloud Orchestration and Management (FOCOM), Network Function Orchestration (NFO), Infrastructure Management (IMS) and Deployment Management (DMS) O-RAN services as depicted in the following figure:
@@ -28,20 +29,18 @@ The primary role of the FOCOM and IMS services is to provide for the lifecycle m
28
29
29
30
{{% alert title="Note" color="primary" %}}
30
31
31
-
In R3 Nephio use cases and component architectures have been defined for O-Cloud Cluster Lifecycle Management.
32
+
In R4 the Nephio implementation supports the O-Cloud Node Cluster creation as part of the-Cloud Cluster Lifecycle Management service.
32
33
33
34
{{% /alert %}}
34
35
35
-
As stated, the role of the FOCOM function is to provide federated orchestration and management across multiple O-Clouds using the O2ims interface between the O-Clouds as shown in the figure below:
36
+
As stated, the role of the FOCOM service is to provide federated orchestration and management across multiple O-Clouds using the O2ims interface between the O-Clouds as shown in the figure below:
Due to the standardized O2ims O-RAN interface, the functions that implement the FOCOM service can interact with O-Clouds IMSs that utilize the capabilities provided by Nephio or O-Clouds that use other non-Nephio capabilities and vice-versa.
40
41
41
42
### O-Cloud Cluster Lifecycle Management
42
43
43
-
#### Introduction
44
-
45
44
O-Cloud Clusters are the primary method of allocating cloud resources (e.g., O-Cloud Nodes, Networks) to be used during deployments of O-RAN NFs. O-Cloud Cluster Lifecycle Management services implemented using Nephio capabilities are described in the following use cases:
46
45
47
46
- Create O-Cloud K8s Cluster
@@ -50,57 +49,42 @@ O-Cloud Clusters are the primary method of allocating cloud resources (e.g., O-C
50
49
51
50
{{% alert title="Note" color="primary" %}}
52
51
53
-
In R3 Nephio use cases and component architectures have been defined for the Create O-Cloud K8s Cluster use case.
52
+
In R4 the Nephio implementation supports the O-Cloud Node Cluster creation use case.
54
53
55
54
{{% /alert %}}
56
55
57
-
The O-RAN WG6 O2ims Provisioning working group has now introduced the concept of an “O-Cloud cluster template” in O-RAN.WG6.O2-GA&P-R003-v06.00.docx. The intention is to abstract the O-Cloud implementation specific artifacts and HW configuration from the SMO/FOCOM layer and just expose a subset of the O-Cloud cluster template, describing high-level workload cluster characteristics, capacity, and additional metadata, that is sufficient for the SMO to be able to decide which O-Cloud cluster template that shall be used based on the CNF workload characteristics and capacity requirements. The O-Cloud cluster template also contain HW Compute Profile/Resource Type characteristics requirements that must be fulfilled by the O-Cloud Site Resources and the SMO will use the information in the cluster template in order to match towards available HW inventory resources exposed over the O2ims inventory API so that it can deduct whether there is available HW resource capacity to create a new cluster based on a certain O-Cloud cluster template in a specific target O-Cloud Site.
58
-
59
-
Within FOCOM a corresponding SMO-level cluster template record is kept. The role of the FOCOM is to support integration towards multiple O-Clouds, each with its own catalog of supported O-Cloud cluster templates that contain a reference to the supporting O-Cloud IMS end point, the unique id of the O-Cloud cluster template on the O-Cloud side as well as the characteristics/capacity and metadata information about the cluster template.
60
-
61
-
The expectation is that each O-RAN CNF vendor jointly defines O-Cloud cluster template blueprint for each O-Cloud infrastructure vendor that they plan to support, due to the need for specific tailoring of the cluster worker nodes to match the HW configuration requirements (bios settings, huge pages, SRIOV NIC configuration etc.) from specific O-RAN CNFs. These O-Cloud cluster template blueprints act as a reference design to be used by each operator running their specific O-Cloud and are expected to be tailored further for each operator. The resulting O-Cloud cluster templates are then discovered by the SMO/FOCOM component as part of the O-Cloud registration process.
56
+
The O-RAN WG6 O2ims Provisioning working group has now introduced the concept of a template for O-Cloud Node Cluster and Infrastructure deployment in O-RAN.WG6.O2-GA&P-R003-v06.00.docx. The intention is to abstract the O-Cloud implementation specific artifacts and HW configuration from the SMO/FOCOM layer and just expose a subset of the O-Cloud Template, describing high-level workload cluster characteristics, capacity, and additional metadata, that is sufficient for the SMO to be able to decide which O-Cloud Template that shall be used based on the CNF workload characteristics and capacity requirements. The O-Cloud Template also contain HW Compute Profile/Resource Type characteristics requirements that must be fulfilled by the O-Cloud Site Resources and the SMO will use the information in the O-Cloud Template in order to match towards available HW inventory resources exposed over the O2ims inventory API so that it can deduct whether there is available HW resource capacity to create a new cluster based on a certain O-Cloud Template in a specific target O-Cloud Site.
62
57
63
-
#### High-Level design of FOCOM using Nephio
58
+
Within FOCOM a corresponding SMO-level O-Cloud Template information record is kept. The role of the FOCOM is to support integration towards multiple O-Clouds, each with its own catalog of supported O-Cloud Templates. The FOCOM O-Cloud Template information record contains a reference to the supporting O-Cloud IMS end point, the name and version of the O-Cloud Template on the O-Cloud side, a schema for the instance specific input data accepted by the O-Cloud Template, as well as the characteristics/capacity and metadata information about the O-Cloud Template.
64
59
65
-
A FOCOM function that uses Nephio enablers uses a KPT-based cluster package management solution where:
60
+
The expectation is that each O-RAN CNF vendor defines O-Cloud Templates for each O-Cloud infrastructure vendor that they plan to support, due to the need for specific tailoring of the cluster worker nodes to match the HW configuration requirements (bios settings, huge pages, SRIOV NIC configuration etc.) from specific O-RAN CNFs. These O-Cloud Templates act as a reference design to be used by each operator running their specific O-Cloud and are expected to be tailored further for each operator. The exposed information about the O-Cloud Templates are then discovered by the SMO/FOCOM component as part of the O-Cloud registration process.
66
61
67
-
- The “Cluster template list” on the SMO is realized by a Git based cluster template repository where the KPT cluster packages are onboarded
68
-
- The SMO O-Cloud cluster templates refer one-to-one to a corresponding IMS-side O-Cloud cluster template in a specific O-Cloud IMS
62
+
### High-Level design of SMO FOCOM using Nephio in R4
69
63
70
-
FOCOM uses a concept of provider plugins to be used when communicating with an O-Cloud IMS. One identified option is for FOCOM to use the Cluster API (CAPI) framework to develop an O2ims provider plugin. An alternative option is to develop a native FOCOM O2ims specific operator without the use fo the CAPI framework. The O2ims CAPI manifest files will be part of the SMO cluster template package.
64
+
A FOCOM service implementation based on Nephio enablers uses a KPT-based cluster package management solution where:
71
65
72
-
The figure below depicts one implementation for the high-level design of the FOCOM:
66
+
- The stored O-Cloud Template information in FOCOM is realized by a Git based cluster template repository where each O-Cloud Template information record is realized with a KPT package blueprint
67
+
- Each FOCOM O-Cloud Template KPT package blueprint refer one-to-one to a corresponding IMS-side O-Cloud Template in a specific O-Cloud IMS
The Nephio based FOCOM implementation will use the Porch NBI for deployment of O-Cloud Node Clusters based on the O-Cloud Template. To trigger creation of a new Node Cluster, the applicable O-Cloud Template KPT package blueprint will be cloned into a new draft for a Node Cluster Provisioning Request instance package. Every O-Cloud Template KPT package blueprint will contain two manifest files, one with the O-Cloud Template information and one for a FOCOM Provisioning Request that will carry the instance specific input and be used by FOCOM to generate the O2ims Provisioning Request. Once the draft Provisioning Request instance package has been created the client shall update the FOCOM Provisioning Request manifest file inside the package to add the instance specific input. Finally the client will propose and approve the Provisioning Request instance package and this will trigger FOCOM to start the reconciliation process for the O2ims Provisioning Request towards the O-Cloud IMS.
75
70
76
-
#### Create O-Cloud K8s Cluster
71
+
Each O-Cloud Template KPT package blueprint will contain a reference to the id of the O-Cloud where this O-Cloud template is supported. Each O-Cloud has been previously registered in FOCOM, in the Nephio R4 implementation this is supported with a separate O-Cloud Registration CR that is manually created in the FOCOM Nephio management cluster. In coming Nephio releases this will be done as part of the O-Cloud registration user story.
77
72
78
-
The creation of an O-Cloud K8s Cluster is defined by an O2ims specific “Cluster Request” CR that is integrated with the Nephio “ClusterClaim” CR as depicted in the figure below:
The FOCOM Provisioning Request manifest file is created as a CR in the FOCOM Nephio management cluster and this will trigger a FOCOM O2ims operator to start the reconciliation towards the O2ims interface exposed by the IMS. The FOCOM O2ims operator will lookup the applicable O-Cloud registration CR to get the end point and credentials information for connection to the IMS. Then the input in the FOCOM Provisioning Request CR will be used to generate the O2ims Provisioning Request and submit it to the IMS.
83
76
84
-
- Models the request to create a cluster with a certain configuration while the current WorkloadCluster CR is used to model successfully deployed clusters and used as a target for NF Deployment
85
-
- Has a parameterRef to a Nephio-defined O2imsClusterParameters CR
86
-
- The o2imsClusterParameter CR has configRefs to both the O2ims standard input data as well as O-Cloud cluster template specific configuration data.
### High level design of O-Cloud IMS using Nephio in R4
89
80
90
-
- Supports installation of add-on features such as Multus networking that will require specific configuration handled through the configRefs CRDs. A configRef CR can contain both configuration that is fixed for the O-Cloud Cluster template as well as instance specific configuration that must be provided as user input.
91
-
- Is realized with a *KPT* package that contains the ClusterClaim CR manifest as well as the referred O2imsClusterParameters CR manifest and additional configuration data manifests
81
+
The support for the O2ims Provisioning interface is realized by an IMS using Nephio enablers through a Provisioning Request CRD over the Kubernetes API.
82
+
For Nephio R4 the existing “nephio-workload-cluster” blueprint is used as the O-Cloud Template so the O2ims Provisioning Request sent from FOCOM shall include a reference to the nephio-workload-cluster as the template.
92
83
93
-
As of this release, the O-RAN Alliance has not specified O2ims provisioning interface, as such this pre-standardization version of the O2ims provisioning interface is KRM/CRD based where the:
84
+
The Nephio based IMS implementation supports an IMS-side O2ims operator that will be triggered by the O2ims Provisioning Request CR instance and use the information provided in order to trigger the deployment of the nephio-workload-cluster blueprint through the Nephio Porch interface.
94
85
95
-
- Kubernetes API server is used to implement the O2ims provisioning interface.
96
-
- Cluster deployment operation is performed by applying an O2ims “ClusterRequest” CR in the IMS management cluster
97
-
- O2ims ClusterRequest CR contains the reference to
98
-
99
-
- the O-Cloud cluster template
100
-
- target O-Cloud Site
101
-
- instance specific input data (will be further defined, for R3 there isn’t any)
- IMS management cluster has an “O2ims operator” that picks up the ClusterRequest CR and triggers Porch cloning of the referred O-cloud cluster template/Nephio workload cluster package as a new “Cluster1” workload cluster package deployment in the Cluster management repository.
104
88
105
89
## Lifecycle management of deployments for O-RAN NFs
106
90
@@ -142,4 +126,4 @@ In R3 the O-RAN Cloudified NFs consist of a single NF Deployment.
142
126
143
127
The following sequence chart depicts the flow between the NFO and Workload Cluster’s DMS, highlighting the use of the Nephio enablers to deploy the NF Deployment from the NFO to the DMS.
0 commit comments