Flexible designer and orchestrator
5G RAN PNF In-place software upgrade
5G - PNF Software Update
5G - PNF Software Update Test Status
Change schedule optimizer
M4 is GREEN for all Change Management Functionalities.
For Casablanca release, we propose the following functionalities.
1) Flexible workflow designer and orchestrator COMMITTED M4READY
- Impacted components: SDC, SO, and VID (nice-to-have)
- Contributors: AT&T, Amdocs, Huawei (?)
- Catalog in SDC for meta-data about the building blocks – completed by Amdocs
- Designer/editor in SDC for creating workflow – committed to develop by Amdocs
- Convert already existing building blocks/activities to be workflow designer ready
- Move workflow out of service model to independent artifact – priority nice to have
- Distribution of workflow to SO – preferably with workflow as independent artifact
- Deployment of workflow in SO
- User interface (VID) to select workflow and input parameters for execution
- Execute workflow in SO
- Rainy day handling for unsuccessful workflow steps
- Visualize the execution results on VID dashboard
- Ability to cancel workflow execution (VID)
Flow Designer Orchestration High Level Diagram
Run-time support of User Designed Workflows
2) Traffic migration building block COMMITTED M4READY
- Impacted components: SDNC, APPC
- Contributors: AT&T, Orange, Intel
- Traffic to one or multiple (V)NFs is distributed by a Traffic Distribution/Balancing Entity
- For Casablanca, we will focus on the LCM action necessary for traffic migration. For Dublin and beyond, we will create a workflow within SO for traffic migration
- New LCM action to control traffic distribution (to achieve traffic migration) - will also have to update CDT Design tool
- DistributeTraffic LCM action (Alternative is ConfigModify LCM action if PTLs recommend to push DistributeTraffic LCM to Dublin)
- Anchor point ID (VNF ID in action identifier)
- Traffic distribution weights for all nodes covered by the anchor point that require changes - this will be in the payload section in the form of "ConfigFileName" The config file (json) would be stored in the Ansible docker.
- The playbook would read a Traffic Distribution Configuration file associated with the DistribConfigName value sent by the Controller
- If we want to test/try various traffic distributions (many tests), we could have many Traffic Distribution Configuration files, each with it own DistribConfigName.
The Playbook could also include a step to take a backup of the Traffic Distribution/Balancing Entity current traffic distrib/configuration and save it locally at some dir path. If the new traffic distribution action is rejected/failed then the playbook can restore previous traffic distribution/config. The Playbook can offer lots of flexibility and it is up to the entity SME to decide what he/she wants to do upon a DistributeTraffic action request.
- Mechanisms for traffic migration - implemented by controller
- Assessment report on commonalities/differences across VNF types – e.g., IP based redirection, DNS based or load balancer
- For Casablanca, we will demonstrate traffic migration across 2 vFWs using traffic source as the anchor point
- Ansible playbook for adjusting the traffic weight on the traffic source (anchor point)
- Traffic weight before migration: 100,0 and traffic weight after migration: to 0,100
- Second test case would be traffic migration (quiesece / resume) on vGW/vCPE
User → DMAAP → SDNC/APPC → Ansible → VNF(s)
User uploads Ansible playbook into CCSDK
For the LCM action :
If the payload contains pnf-flag and it is set to true then that indicates request for PNF.
If it is set to false, then the request is for VNF, and we will use vnf-id in input and nf-naming-code in payload.
nf-naming-code = vgw for example.
SDNC will look up nf-naming-code in AAI if not passed in payload.
For PNF, we will use the following in payload: pnf-name and ipaddress-v4-oam
3) 5G RAN PNF Software upgrade COMMITTED M4READY
- Impacted components: SDNC, Ansible (CCSDK)
- Contributors: AT&T, China Mobile, Huawei
Leverage in-place software upgrade Beijing use case (minor changes) to demonstrate application to 5G RAN PNFs
Complete generic building blocks for flexible upgrade workflow design
Enhance precheck and postcheck steps with vendor specific rules
External controller would receive instructions from Ansible SDNC
PNF ID, Expected Software Version, Controller Type, EC type, Rule Name and corresponding parameters can be specified at run time
Update A&AI entry with new PNF software version, as ‘active version’
Support Batch software upgrade operations (stretch goal)
- More details: 5G - PNF Software Update
4) Change Management Scheduler COMMITTED M4READY
- Impacted components: OOF
- Contributors: AT&T
- Discover schedule based on the change management constraints
- Time-based - e.g., execute the change activity during the maintenance window and weekdays
- Concurrency of how many NF instances to change at a time - this is concurrency within a single user request
- NF conflicts (if time permits) - avoid work scheduled at the same time on the same NF instance
- List of NF instances - request details as depicted in the Beijing script
- Start/end times
- Expected duration
- Type of change (workflow name)
- Concurrency value
- Schedule - time and instance at which the workflow would be executed
Use Beijing vGW in-place software upgrade to demo execution based on the schedule output by OOF
Dear Ajay Mahimkar, and ONAP experts?
As the statements in Casablanca Platform Enhancements to Support 5G Use Case, the PNF SW management and Change management is one of the features in rel3. And I have prepared a material to illustrate the requirement of PNF SW management. In my personal view, both VNF and PNF Change management all relate to the CM operation, and from the PPT title ONAP CM C Functional Requirement I interpreated PNF whould be included.
So, do you think is a wiseble way that add PNF Chang management in ONAP CM C Functional Requirement?
The material is the attachedment.
Hi Li - very good thought!! We definitely have PNF software upgrade and change management in scope - we should discuss more about how to bring it in the next ONAP release. Along with execution, i believe careful co-ordination and scheduling is important for deployment.
Great idea and I would propose to go further.
Why not targeting more openess with an OSS replacement by the SDN-C? (The sofware upqrade and configuration change should be SDN-C driven).
Hi Olivier Augizeau:
Thanks for your suggestion, I’d like to study your proposal, and would you like provide some detailed illustrations on this?
According to your proposal, I have a little question that does the SDN_C has the capability to configure and manage NFs?
So far as I know SDN_C provides the capability of transport network configuration and management, and routing tables and address of layer2~3 could be identified by SDN_C, so I wonder that could the SDN_C understand/identify tele-communication network elements? How does the SDN trigger the changing and management work flow?
Li Xiang - would you like to add PNF software upgrade use case for 5G? If possible, we can experiment with the Ansible approach to managing software upgrades. We can add this in the Casablanca proposal (either in CM functional requirement or 5G use case)
How PNF SW management will be different from SW management of plethora of VNFs that we need to handle as well? For each PNF or VNF there are some specific procedures or native mechanisms on VNFM/EMS level. We talk here about generalization of change management functionality so we should talk about general mechanisms that would support SW management of any NFs. Nevertheless, PNFs should be supported by this mechanisms as well. As I mentioned on one of the telcos - having variety of use cases we would work on in the same time would help to identify common and generic mechanisms for change management of any NF.
Will Weidong Chen
I would add one possible feature to be considered for 1) Build-and-replace software upgrade. Shall we consider roll-back feature in case that it needs to be reversed? Thanks.
Yes, we should consider roll-back in the workflow. We actually discussed this recently and we would need different policies/strategies for different steps in the workflow.
We need to think about relation with scali'ing enhancements for Casablanca and some synchronization with this activity is required. Some operations for change management are similar to what has to be performed when scale-in or scale-out is performed (migration of traffic or configuration, creation or removing of VNF instance, rollback can be a combination ). Rollback operation also could be a combination of reconfiguration with traffic migration and scale-out. Maybe we should arrange some meeting with team responsible for scaling enhancements in order to discuss about common point and to identify what we can deliver together for R3.
Below is summary of long term requirements that we were discussing about during last conf-call:
Lukasz/all - should we add sample VNF types for Casablanca CM use case?
Ajay/all, as I mentioned some time before we should put some effort to identify types of VNFs and requirements for their proper change management. This analysis would help to identify missing mechanisms in ONAP and some change scenarios will be identified and it will be a strong outcome of Casablanca release. Maybe this analysis would be helpful also for Casablanca use case, but definitely this step is required for proper identification of changes for CHM for future releases. We could create some new change flow diagrams for different VNFs. We can create some document and work on it over gerrit like it is done for example in multicloud project https://gerrit.onap.org/r/#/c/30027/ What do you think about it?
Regarding the VNFs for Casablanca we can target rather L2-L3 VNF - the question is which ones. Maybe one for Delete and Build and other one for Build and Replace.
For Casablanca we propose two different scenarios and workflow execution with workflow designer. Regarding the scenarios I understand that some work is required around SDN-C or APP-C and some Ansible/Chef scripts must be created (for config migration, traffic migration). In order to start this task some concrete VNFs must be identified. But what about workflows? Is it certain that both workflows in SO and workflows designer in SDC will be available for Casablanca? It would be great that somebody responsible for workflows will tell how they will work for Casablanca and what is schedule for delivery of that functionality because change management use case for Casablanca is strongly dependent on it. Some interesting discussion about workflows can be found here https://wiki.onap.org/display/DW/Workflow+Management and here https://wiki.onap.org/pages/viewpage.action?pageId=29786347 . We should also clarify how VNF delete and VNF create will be performed by SO as both functions are crucial for two proposed scenarios.
On the traffic migration, there are three different ways I can think of way this can be done
Which method is being followed in initial version? Or Is there 4th method?
Viewing these as mechanisms for traffic migration. Yes, one of the focus in Casablanca would be defining some sample mechanisms - e.g., vLB for vFW would be one of the specific cases we would begin with.
Next, and equally important is the API - input/output parameters.
Is buildandreplace VNF sw upgrade supported? If so, are both the Vn and Vn+1 versions of the VNF running in the Service at the same time? Or is a separate Vn+1 Service actually created too? I'm having trouble finding details on this....