For Casablanca release, we propose the following functionalities.
SDC | SO | SDNC | APPC | CCSDK [Ansible playbooks] | OOF | A&AI | Policy | DCAE | Test Case | Status | |
Flexible designer/orchestrator | Amdocs | vGW in-place software upgrade | GREEN | ||||||||
Traffic management | Orange | vFW migrate traffic and vGW quiesce/resume traffic | GREEN | ||||||||
5G PNF in-place software upgrade | AT&T | China Mobile, Huawei | 5G PNF in-place software upgrade (emulator) | GREEN | |||||||
Change schedule optimization | trigger vGW in-place software upgrade at scheduled time | GREEN |
API Freeze | M3 | 23-Aug-18 |
Code Freeze | M4 | 20-Sep-18 |
Integration | RC0 | 11-Oct-18 |
RC1 | 25-Oct-18 |
1) Flexible workflow designer and orchestrator COMMITTED
- Impacted components: SDC, SO, and VID (nice-to-have)
- Contributors: AT&T, Amdocs, Huawei (?)
- Functionalities
- 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
- Impacted components: SDNC, APPC
- Contributors: AT&T, Orange, Intel
- Functionalities
- 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.
- MigrateTraffic LCM action (Alternative is ConfigModify LCM action if PTLs recommend to push MigrateTraffic 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
- 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
- Integration/testing
- 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
Execution flow:
User → DMAAP → SDNC/APPC → Ansible → VNF(s)
Design flow:
User uploads Ansible playbook into CCSDK
3) 5G RAN PNF Software upgrade
- Impacted components: SDNC, Ansible (CCSDK)
- Contributors: AT&T, China Mobile, Huawei
- Functionalities
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
Integrate the external controller into ONAP controller, and the EC will handle temporary states retrieval/storage/analysis of PNFs
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)
4) Change Management Scheduler COMMITTED
- Impacted components: OOF
- Contributors: AT&T
- Functionalities
- Discover schedule based on the change management constraints
- 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
- Input
- List of NF instances - request details as depicted in the Beijing script
- Start/end times
- Expected duration
- Constraint/policy
- Type of change (workflow name)
- Concurrency value
- Output
- Schedule - time and instance at which the workflow would be executed
Integration/Testing plan
Use Beijing vGW in-place software upgrade to demo execution based on the schedule output by OOF