Skip to end of metadata
Go to start of metadata

Flexible designer and orchestrator

Traffic migration

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.

SDC SOSDNCAPPCCCSDK [Ansible playbooks]OOFA&AIPolicyDCAETest CaseStatus
Flexible designer/orchestratorAmdocs


SO-838 - Getting issue details... STATUS

SO-829 - Getting issue details... STATUS

Lead: Elena Kuleshov (


vGW in-place software upgrade


Traffic management


SDNC-421 - Getting issue details... STATUS

Lead: Ruchira Agarwal



APPC-1150 - Getting issue details... STATUS

Lead: Lukasz Rajewski  


Orange, Intel

CCSDK-449 - Getting issue details... STATUS

Lead: Lukasz Rajewski  


CCSDK-465 - Getting issue details... STATUS

Lead: Eric Multanen


vFW migrate traffic and vGW quiesce/resume traffic


5G PNF in-place software upgrade


SDNC-424 - Getting issue details... STATUS

SDNC-425 - Getting issue details... STATUS

Lead: Ruchira Agarwal


China Mobile, Huawei

CCSDK-464 - Getting issue details... STATUS

SDNC-426 - Getting issue details... STATUS

Lead: Yaoguang Wang


5G PNF in-place software upgrade (emulator)

INT-629 - Getting issue details... STATUS

INT-630 - Getting issue details... STATUS


Change schedule optimization


OPTFRA-309 - Getting issue details... STATUS

Lead: Jerry Flood


trigger vGW in-place software upgrade at scheduled time


API FreezeM323-Aug-18
Code FreezeM420-Sep-18


1)  Flexible workflow designer and orchestrator  COMMITTED M4READY

  1. Impacted components: SDC, SO, and VID (nice-to-have)
  2. Contributors: AT&T, Amdocs, Huawei (?)
  3. Functionalities
    1. Catalog in SDC for meta-data about the building blocks – completed by Amdocs
    2. Designer/editor in SDC for creating workflow – committed to develop by Amdocs
    3. Convert already existing building blocks/activities to be workflow designer ready
    4. Move workflow out of service model to independent artifact – priority nice to have
    5. Distribution of workflow to SO – preferably with workflow as independent artifact
    6. Deployment of workflow in SO
    7. User interface (VID) to select workflow and input parameters for execution
    8. Execute workflow in SO
    9. Rainy day handling for unsuccessful workflow steps
    10. Visualize the execution results on VID dashboard
    11. 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

  1. Impacted components: SDNC, APPC
  2. Contributors: AT&T, Orange, Intel
  3. Functionalities
    1. Traffic to one or multiple (V)NFs is distributed by a Traffic Distribution/Balancing Entity
    2. 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
    3. New LCM action to control traffic distribution (to achieve traffic migration) - will also have to update CDT Design tool
    4. DistributeTraffic LCM action (Alternative is ConfigModify LCM action if PTLs recommend to push DistributeTraffic LCM to Dublin)
      1. Anchor point ID (VNF ID in action identifier)
      2. 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.
      3. The playbook would read a Traffic Distribution Configuration file associated with the DistribConfigName value sent by the Controller
      4. If we want to test/try various traffic distributions (many tests), we could have many Traffic Distribution Configuration files, each with it own DistribConfigName.
      5. 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.

    5. Mechanisms for traffic migration - implemented by controller
      1. Assessment report on commonalities/differences across VNF types – e.g., IP based redirection, DNS based or load balancer
  4. Integration/testing
    1. For Casablanca, we will demonstrate traffic migration across 2 vFWs using traffic source as the anchor point
    2. Ansible playbook for adjusting the traffic weight on the traffic source (anchor point)
    3. Traffic weight before migration: 100,0 and traffic weight after migration: to 0,100
    4. Second test case would be traffic migration (quiesece / resume) on vGW/vCPE

Execution flow:

Traffic Migration

User → DMAAP → SDNC/APPC → Ansible → VNF(s)

Design flow:

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

  1. Impacted components: SDNC, Ansible (CCSDK)
  2. Contributors: AT&T, China Mobile, Huawei
  3. Functionalities
    1. Leverage in-place software upgrade Beijing use case (minor changes) to demonstrate application to 5G RAN PNFs

    2. Complete generic building blocks for flexible upgrade workflow design

    3. Enhance precheck and postcheck steps with vendor specific rules

    4. External controller would receive instructions from Ansible SDNC

    5. PNF ID, Expected Software Version, Controller Type, EC type, Rule Name and corresponding parameters can be specified at run time 

    6. Update A&AI entry with new PNF software version, as ‘active version’

    7. Support Batch software upgrade operations (stretch goal)

  4. More details: 5G - PNF Software Update

4) Change Management Scheduler COMMITTED M4READY

  1. Impacted components: OOF
  2. Contributors: AT&T
  3. Functionalities
    1. Discover schedule based on the change management constraints
    2. Constraints
      1. Time-based - e.g., execute the change activity during the maintenance window and weekdays
      2. Concurrency of how many NF instances to change at a time - this is concurrency within a single user request
      3. NF conflicts (if time permits) - avoid work scheduled at the same time on the same NF instance
    3. Input
      1. List of NF instances - request details as depicted in the Beijing script
      2. Start/end times
      3. Expected duration
      4. Constraint/policy
      5. Type of change (workflow name)
      6. Concurrency value
    4. Output
      1. Schedule - time and instance at which the workflow would be executed
  4. Integration/Testing plan

    1. Use Beijing vGW in-place software upgrade to demo execution based on the schedule output by OOF

CM scheduling

CM execution with schedule

  • No labels


  1. 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. 




    1. 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.


      • Ajay
    2. 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).

      1. 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? 

        Best Regards

        Li Xiang

        1. 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)


          • Ajay
    3. 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.

  2. 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.

    1. 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.

  3. 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.

  4. Below is summary of long term requirements that we were discussing about during last conf-call:

    • Flexible design and execution of update and upgrade workflows – BPMN designer + BPMN execution engine
    • Possibility of update and upgrade that will not stop services that are handled by VNF (end-user sessions will not be dropped)
    • VNF rollback after unsuccessful deployment – may need snapshot mechanisms (VM image snapshot or configuration only snapshot)
    • Automatic scheduling of update and upgrade based on information from A&AI, VF-C etc. (e.g. to consider VNF dependencies, VNF chaining)
    • Traffic & configuration migration – how to migrate state of L4-L7 statefull VNFs?
    • Generalization of LCM operation implemented now as Chef/Ansible scripts. Some of them should be shared across some or all VNF types – now each VNF will have its own LCM scripts.
    • Native ONAP functions for change management – to generalize mechanisms that could be the same for different VNF types
    • Any generalization requires to work on different use cases (update/upgrade scenario for one VNF type) in the same time – it is impossible to identify truly generic mechanisms from only one use case
    1. Lukasz/all - should we add sample VNF types for Casablanca CM use case?

      1. 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 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.

  5. 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 and here . We should also clarify how VNF delete and VNF create will be performed by SO as both functions are crucial for two proposed scenarios.

  6. Ajay,

    On the traffic migration, there are three different ways I can think of way this can be done

    1. Via creating flows in vSwitch of the NFVI node to redirect the traffic to new VM.
    2. Via the front-end load balancer : This requires configuration of load balancer (either virtual or physical).  I guess this requires creation of load balancer VM in the beginning (even before first VM is instantiated) and  configuration of load balancer VM via APP-C.
    3. Via mutual configuration of VNFs: Source of the traffic knowing about destination VM and accordingly redirecting the traffic.

    Which method is being followed in initial version? Or Is there 4th method?


    1. 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.

  7. 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....