Contributors:
user-7493f , Vamshi Namilikonda <VN00480215@TechMahindra.com>, Thamlur Raju
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
Helm Package:
- CCSDK-2919Getting issue details... STATUS
- POST: Instantiation, Day0 and Day1 (will update the snssai value in CNF while creation/Instantiation) will perform.
- 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:
- Instantiation, day0 & day1
- Base helm package amf_cloudtech_k8s_charts.tgz for instantiation contains following resources.
b. Profile artifact template-profile.tar.gz contains the following resources.
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
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.
- 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.
- resource-assignment
- Day2
- config-assign-day-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:
Instantiation of slice, day-0 configurations:
Process:
- 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.
- 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.
- 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.
- SO triggers config-assign workflow in CDS. CDS processes config-assign workflow.
- 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.
- SO updates A&AI with vf-module status as Activated.
- 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.- Script invokes A&AI and fetch vf-modules details
- From each vf-module response it retrieves heat-stack-id which is actually k8splugin instance id.
- With instance-id, invokes K8splugin /instance API to fetch ConfigMap name information.
- Updates the ConfigMap name in config-template artifact.
- Executes Create template API of K8splugin
- Uploads the config-template artifact by invoking Upload config template content API of K8splugin.
- SO updates A&AI with VNF status as Active.
- 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:
Modify-Config flow of slice (Day-2):
Process:
- SO triggers PUT request for day2 configuration.
- SO triggers config-assign-day-2 workflow of CDS. CDS executes the workflow.
- 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.
- Script invokes A&AI and fetch vf-modules details
- Resolve snssai array
- 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.
6 Comments
Yukihiro Kishimoto
Hi, I'm really impressed with this great job and would love to try this use case.
Can you give us some advice on how to deploy CBA and Helm after it has been successfully distributed?
Yukihiro
Thamlur Raju
Hi Yukihiro Kishimoto, sorry for late response
Please follow the below demos for Design Time and Run Time.
E2E Network Slicing Meeting Notes for Oct 12, 2020 – DT Demo (32:00 - 58:00)
E2E Network Slicing Meeting Notes for Nov 9th, 2020 – RT Demo (21:42 - 39:00)
Yukihiro Kishimoto
Hi, Thamlur Raju
Thank you for your answer. I will check that recording again.
By the way, I am keen to try Day 0, 1, and Day 2 of CN domain NSSI. Do you intend to use this Core-NF-Simulator as part of the Slicing demonstrations? I assume that we will be able to create the NSI not only by NBI but also by UUI, Core-NF-Simulator would deploy as an NSSI. Also activating NSI, the snaai in the Simulator would be changed. My understanding is correct?
Thamlur Raju
Hi Yukihiro Kishimoto,
Yes, As per R6 UUI triggering the NBI for NSI instantiation and later on it will handover to External Core-simulator to create the NSSI. As per R7 the Core-simulator was added to the SO (newly introduced), which will create the NSSI and trigger the NBI/Ex-API for Core Service (like, AMF, SMF and UPF) instantiation through Macro flow (using SO, SDNC, CDS and Multi-cloud).
Modify workflow will trigger direct SO Macro flow (for PUT operation).
Yukihiro Kishimoto
Hi, Thamlur Raju
Thanks to your explanation and this wiki, I understand that Day 1, 2, 3 operation of Core-sim in R7. But, Would you mind elaborating to clarify what is the trigger to do Day 0, 1, 2 of AMF/SMF/UPF in R7 from the Operator viewpoints?
Can I instantiate the Core-sim CNF by activating the NSI from the UUI operation?
Also, Can I modify the parameters of Core-sim CNF such as supportNssai modify the NSI from the UUI operation?
Sebastiano DePani
The master overrides file now has an entry that overwrites the tenant id to 1234, which takes effect when the NBI pod is updated or deployed. There's also been a change in the structure of the NBI files. The default deployment.yaml updates can be omitted if the values.yaml sets the tenant id to whatever it needs to be, and the values for cloud owner and cloud region are set to your k8s values for both the LCP and k8s. What worked for us is below.
# application configuration
config:
loglevel: INFO
logstashServiceName: log-ls
logstashPort: 5044
cloudOwner: k8scloudowner4
k8sCloudRegionId: k8sregionfour
k8sCloudOwner: k8scloudowner4
ecompInstanceId: OOM
openStackRegion: k8sregionfour
openStackVNFTenantId: aaaa