5GC Instantiation and Modify Config flow through CDS

Owned by Thamlur Raju (Unlicensed)
Last updated: May 09, 2022 by Sebastiano DePani
10 min read

Contributors:

@Former user (Deleted) , Vamshi Namilikonda <VN00480215@TechMahindra.com>, @Thamlur Raju (Unlicensed)



Introduction / Background:

As part of the 5G slicing use case, the core NSSMF shall be instantiating a 5G core service which typically would comprise of AMF, SMF and UPF CNFs.

In order to demonstrate this use case, a dummy AMF, SMF and UPF helm charts are created. The configurations applied to these CNFs during instantiation and later as part of day 2 configurations comprise of S-NSSAI and the configuration mechanism is assumed to be configmap type of k8s. 

This page provides all the details on how to design a typical 5G core NS in SDC, provides helm charts for dummy AMF, SMF, UPF and CBA packages for day 0, day 1 and day 2 configurations. These artifacts could form as a base template / seed artifacts using which interested people could build upon it and try onboarding specific vendor 5G core CNFs and design the configurations for the same. The CDS package has distinct workflows to handle day 0, day 1 and day 2 configurations.  

The Network service could be instantiated through EXT-API component or by invoking SO Macro flow. In the E2E slicing use case this would be invoked by core NSSMF. 

Using the Frankfurt release one could try NS instantiation invoking the SO APIs to validate the CNF instantiation and configurations.



Features:

  • Core NS instantiation using the Macro flow through NBI Automation.

  • Instantiation, Day0, Day1 and Day2 configuration with help of SO, SDNC, Multicloud (k8s-plugin) and CDS.

  • There are two E2E workflows involved i.e Macro POST (Instantiation) and PUT (Modify Config) operations.

CBA package Download:

Original Upload

https://gerrit.onap.org/r/c/ccsdk/cds/+/113518 (obsolete)

https://gerrit.onap.org/r/gitweb?p=ccsdk/cds.git;a=commit;h=a8fecedef955a594716d96a4c5b5c2564385db1c (obsolete)

Current Repository

https://git.onap.org/ccsdk/cds/tree/components/model-catalog/blueprint-model/service-blueprint/5GC_Simulator_CNF_CDS



Helm Package:





CCSDK-2919: 5G Core Network Service CBA packageClosed

  1. POST: Instantiation, Day0 and Day1 (will update the snssai value in CNF while creation/Instantiation) will perform.

  2. PUT: Day2 can perform (will update the snssai value for Modify Config flow).



Description:

Realize the 5G Slicing CNF instantiation of dummy AMF, SMF and UPF network components as PODs in the k8s cluster and applying slicing configurations via ConfigMap k8s resource.

The following pre-requisites are required on ONAP Frankfurt instance to execute the usecase.

· Dummy Helm Charts to instantiate AMF, SMF & UPF

  • CBA package

  • NBI – NBI image 7.0.2

  • SO – SO image 1.7.1

  • Multicloud/K8splugin – Multicloud image latest



Helm artifacts for AMF, SMF & UPF:

  1. Instantiation, day0 & day1

    1.  Base helm package amf_cloudtech_k8s_charts.tgz for instantiation contains following resources.

AMF package:

amf/

amf/Chart.yaml

amf/values.yaml

amf/templates/

amf/templates/configmap.yaml

amf/templates/deployment.yaml

  

                 b. Profile artifact template-profile.tar.gz contains the following resources.

Profile package:

manifest.yaml

override_values.yaml



profile artifact carries snssai parameters for the day0 slice configurations inside override_values.yaml

Day2:

Config templates for each AMF, SMF & UPF instances as helm package for the day2 configurations contains the following resources. For instance the amf config template amf-config-template.tar.gz for AMF instance contains following resources



AMF Config Template :

amf/

amf/Chart.yaml

amf/values.yaml

amf/templates/

amf/templates/configmap.yaml

Config template helm package will be placed inside CBA package along the side profile artifact.

The day2 config-templates will be modified from the Kotlin script before uploaded to multicloud with the ConfigMap name already instantiated. This is to ensure that config-template would update the same ConfigMap which is existing already.



CBA package impacts:

The following new workflows introduced in the CBA along with the existing workflow “resource-assignment” compare to firewall CNF usecase from the Frankfurt.

  1. Instantiation, Day0 & Day1

    • resource-assignment
                This CDS workflow executes kotlin script K8sProfileUpload.kt – responsible to upload profile artifact.

    • config-assign

    • config-deploy
                This CDS workflow executes kotlin script DayOneConfig.kt – responsible to update the config-template with appropriate(instantiated configmap) ConfigMap name and upload it using K8splugin config template API. This is being invoked
      from SO POST api.

  2. Day2

    1. config-assign-day-2

    2. config-deploy-day-2

                     This CDS workflow executes kotlin script KotlinK8sUpdateConfig.kt – responsible to execute K8splugin Values API for day2 configurations. This is being invoked from SO PUT api.

Design time activities:

POST Operation Process:

In SDC vf Design --> create a property as "snssai" and declare it as input in Properties Assignment section, Even in service design refer that same VF and declare it as input.



SDC:

VSP:


VF:
Set below properties values at VF level in SDC

Service:

Instantiation Type = Macro

Set below properties values at Service level in SDC

  • Set “skip_post_instantiation_configuration = false” in SDC to enable post

  • controller_actor = CDS

  • Add cba package details in sdnc properties

    • sdnc_artifact_name

    • sdnc_model_name

    • sdnc_model_version



NBI Updates:

WARNING:  The default override values file supplied with your distribution likely has this entry for nbi.

nbi: enabled: false config: # openstack configuration openStackRegion: "Yolo" openStackVNFTenantId: "1234"



This entry will cause changes you make to configure NBI to be overwritten when the NBI pod is updated and that portion from config: and the succeeding lines must be removed.

path: oom/kubernetes/nbi/templates/deployment.yaml 

The default values can remain as is as the values are specified in a values.yaml file.  Prior instructions added k8s config variables but that as of Istanbul is no longer needed.

- name: ONAP_LCPCLOUDREGIONID value: {{ .Values.config.openStackRegion }} - name: ONAP_TENANTID value: {{ .Values.config.openStackVNFTenantId | quote }} - name: ONAP_CLOUDOWNER value: {{ .Values.config.cloudOwner }} - name: ONAP_K8SCLOUDREGIONID value: {{ .Values.config.k8sCloudRegionId }} - name: ONAP_K8SCLOUDOWNER value: {{ .Values.config.k8sCloudOwner }}


path: oom/kubernetes/nbi/values.yaml

The Values that come with the deployment are as below.

# application configuration config: loglevel: INFO logstashServiceName: log-ls logstashPort: 5044 cloudOwner: CloudOwner k8sCloudRegionId: k8sregionfour k8sCloudOwner: k8scloudowner4 ecompInstanceId: OOM openStackRegion: RegionOne openStackVNFTenantId: aaaa

Two of these values (cloudOwner and openStackRegion need to be set to the k8s values;

# application configuration config: loglevel: INFO logstashServiceName: log-ls logstashPort: 5044 cloudOwner: k8scloudowner4 k8sCloudRegionId: k8sregionfour k8sCloudOwner: k8scloudowner4 ecompInstanceId: OOM openStackRegion: k8sregionfour openStackVNFTenantId: aaaa

Note: In the NBI clode, there is an if statement for a variable public_net_id  which if null selects  RegionOne/CloudOwner, and k8sregionfour/k8scloudowner if not null.  Overwriting ClowdOwner adn openStackRegion to the k8s values ensures NBI will orchestrate on the k8s cloud.

To recap, update the values in the confg section of the NBI values..yaml.

  • openStackRegion = the k8s region

  • cloudOwner = value for k8s cloud owner

  • openStackVNFTenantId = the same tenantid value for the k8s cloud.

SO Maria DB:

orchestration_flow_reference
MariaDB [catalogdb]> select * from orchestration_flow_reference; | 429 | Service-Macro-Create | 1 | AssignServiceInstanceBB | 1 | 102 | NULL | NULL | | 432 | Service-Macro-Create | 2 | CreateNetworkCollectionBB | 1 | 102 | NULL | NULL | | 435 | Service-Macro-Create | 3 | AssignNetworkBB | 1 | 102 | NULL | NULL | | 438 | Service-Macro-Create | 4 | AssignVnfBB | 1 | 102 | NULL | NULL | | 441 | Service-Macro-Create | 5 | AssignVolumeGroupBB | 1 | 102 | NULL | NULL | | 444 | Service-Macro-Create | 6 | AssignVfModuleBB | 1 | 102 | NULL | NULL | | 447 | Service-Macro-Create | 7 | ControllerExecutionBB | 1 | 102 | vnf | config-assign | | 450 | Service-Macro-Create | 8 | AssignPnfBB | 1 | 102 | NULL | NULL | | 453 | Service-Macro-Create | 9 | WaitForPnfReadyBB | 1 | 102 | NULL | NULL | | 456 | Service-Macro-Create | 10 | ActivatePnfBB | 1 | 102 | NULL | NULL | | 459 | Service-Macro-Create | 11 | CreateNetworkBB | 1 | 102 | NULL | NULL | | 462 | Service-Macro-Create | 12 | ActivateNetworkBB | 1 | 102 | NULL | NULL | | 465 | Service-Macro-Create | 15 | CreateVolumeGroupBB | 1 | 102 | NULL | NULL | | 468 | Service-Macro-Create | 16 | ActivateVolumeGroupBB | 1 | 102 | NULL | NULL | | 471 | Service-Macro-Create | 17 | CreateVfModuleBB | 1 | 102 | NULL | NULL | | 474 | Service-Macro-Create | 18 | ActivateVfModuleBB | 1 | 102 | NULL | NULL | | 477 | Service-Macro-Create | 19 | ControllerExecutionBB | 1 | 102 | vnf | config-deploy | | 480 | Service-Macro-Create | 20 | ActivateVnfBB | 1 | 102 | NULL | NULL | | 483 | Service-Macro-Create | 21 | ActivateNetworkCollectionBB | 1 | 102 | NULL | NULL | | 486 | Service-Macro-Create | 22 | ActivateServiceInstanceBB | 1 | 102 | NULL | NULL |



SO cloud_sites table
Check if cloud details are present in cloud_sites table. If does not exists then insert the same insert into cloud_sites(ID, REGION_ID, IDENTITY_SERVICE_ID, CLOUD_VERSION, CLLI, ORCHESTRATOR) values("k8sregion", "k8sregion", "DEFAULT_KEYSTONE", "2.5", "clli2", "multicloud");



Instantiation of slice, day-0 configurations:







Process:

  1. NBI receives 5G Slice order request to process. SO creates the service instance and updates service instance information to A&AI. SO further triggers SDNC to create service instance info in MD-SAL. SDNC further triggers CDS to execute resource assignment workflow.

  2. SO creates VNF and updates VNF information to A&AI. SO further triggers SDNC to create VNF info in MD-SAL. SDNC further triggers CDS to execute resource assignment workflow.

  3. SO creates vf-module and updates vf-module information to A&AI. SO further triggers SDNC to create VNF info in MD-SAL. SDNC further triggers CDS to execute resource-assignment workflow. The workflow triggers kotlin script KotlinK8sProfileUpload.kt which updates profile artifact with snssai parameters and create profile in K8splugin.

  4. SO triggers config-assign workflow in CDS. CDS processes config-assign workflow.

  5. SO invokes infra-workload API of Multicloud which further invokes K8splugin. Before processing of instantiating helm charts, the K8splugin retrieves profile artifact and updates the ConfigMap with snssai information from override.yaml of profile artifact.

  6. SO updates A&AI with vf-module status as Activated.

  7. SO triggers config-deploy workflow of CDS. CDS processes the config-deploy workflow. The workflow would execute kotlin script KotlinDayOneConfig.kt. The script performs the following activities in sequence. Steps from b) to f) will be executed for
    all the vf-modules except base.

    1. Script invokes A&AI and fetch vf-modules details

    2. From each vf-module response it retrieves heat-stack-id which is actually k8splugin instance id.

    3. With instance-id, invokes K8splugin /instance API to fetch ConfigMap name information.

    4. Updates the ConfigMap name in config-template artifact.

    5. Executes Create template API of K8splugin

    6. Uploads the config-template artifact by invoking Upload config template content API of K8splugin.

  8. SO updates A&AI with VNF status as Active.

  9. SO updates A&AI with Service Instance status as Active.



Notes:

  • Updated slice information on the ConfigMap and inside pod supportedNsssai inside ConfigMap:

  • Inside the AMF, SMF & UPF pods the slice details updated in the following location like below.



PUT Operation Process:



service_recipe
MariaDB [catalogdb]> select * from service_recipe; insert into service_recipe (id,ACTION,VERSION_STR,DESCRIPTION,ORCHESTRATION_URI,SERVICE_PARAM_XSD,RECIPE_TIMEOUT,SERVICE_TIMEOUT_INTERIM, CREATION_TIMESTAMP,SERVICE_MODEL_UUID) Values(500,'updateInstance','1.0','Gr api recipe to update service-instance','/mso/async/services/WorkflowActionBB',NULL,180,NULL,'2020-09-01 16:08:35','d88da85c-d9e8-4f73-b837-3a72a431622b');



northbound_request_ref_lookup



orchestration_flow_reference



Modify-Config flow of slice (Day-2):





Process: 

  1. SO triggers PUT request for day2 configuration.

  2. SO triggers config-assign-day-2 workflow of CDS. CDS executes the workflow.

  3. SO triggers config-deploy-day-2 workflow of CDS. CDS processes config-deploy-day-2 workflow. The workflow would execute kotlin script KotlinK8sUpdateConfig.kt. The script performs the following activities in sequence. Steps from b) to c) will be executed for all the vf-modules except base.

    1. Script invokes A&AI and fetch vf-modules details

    2. Resolve snssai array

    3. Execute Config Values API of K8splugin by passing



Notes:
     Kotlin processing of snssai array from

SO PUT request SO PUT api would apply slice configurations on AMF, SMF and UPF instances. The PUT request carries the slice details which further been updated on the k8s cluster on the configmap.
The following json structure represents the configurations received from SO PUT for a VFModule.
The sNssai array would be resolved from the CBA to make it available to Kotlin

  • Kotlin invocation of values api of K8splugin 

  • The following configuration api from the multicloud/k8splugin would be invoked to process configurations. It takes configuration template as input in the payload which essentially contains helm package that carries configurations like
    ConfigMap in this case.

POST https://<IP>:30283/api/multicloud-k8s/v1/v1/rb/definition/<rbname>/<rb-version>/profile/<profile-name>/config

  • Updated slice information on the ConfigMap and inside pod
         supportedNsssai inside ConfigMap:



Inside the AMF, SMF & UPF pods the slice details updated in the following location like below.