PNF Software upgrade flow to be tested for Casablanca:

Bold items on the right will be tested (steps 6, 7, 10, 12, 14, 15).

Overall Process for Casablanca:

• PNF upgrade process in Casablanca will follow the similar procedures used for VNF in-place upgrade in Beijing. Main differences:
  • Extended payload parameters for PNF in NB API for SDNC (e.g., PNF Identifier, PNF specific rules, External Controller info) 
  • PNF specific DG branches that are processed based on the presence of PNF specific parameters
  • PNF upgrade specific ansible playbooks
  • Ansible adaptor that accepts External Controller end point as a parameter from API calls on interface 6.
  • External controller that executes playbooks received from ansible adaptor.

More detailed process:

Interface in the northbound of SDNC:

SO (or test script) ↔ DMAAP ↔ SDNC

Interfaces within SDNC and southbound of SDNC

DmaapListener  ←  (REST) →  LcmAPI  - DirectedGraph – AnsibleAdapter ←  (REST) → External Controller ← (ssh) → PNF

Pre-conditions for testing: 

• DMaaP is up and running
• A&AI is up and running with valid PNF entry
• SDNC is up and running
  • Installed ansible playbooks for precheck, upgrade, postcheck on SDNC
    • Q: how do we install playbooks? (need link to the process)
    • Q: how do we associate playbooks with the PNF?
      • A: pnf_name → PlaybookName
        • PlaybookName := <equip-vendor, equip-model, sw-version>  
        • PlaybookName can be constructed via A&AI queries using pnf_name (globally unique identifier)
  • Installed DGs to SDNC for the NB API of SDNC about lifecycle management (need links to SDNC API and to the process of installing DGs here) 
• EM and PNF emulators are up and running at manually assigned IP addresses and ports (eventually PNF PnP use case emulator and this emulator should be merged to have a full picture)
• Test script is up and running (should be able to pub/sub to DMaaP)
  • Q: Is this homed at SO or as a separate test module?

LCM API payload:

• PNF_flag: boolean ("VNF" if PNF_flag == false, "PNF" if PNF_flag == true) 
  • Used to pick up the correct processing branch of DG
• pnf_name: string (globally unique PNF identifier that matches to the field name in A&AI for the PNF)
• EC_IPaddr: string (IPv4 or IPv6 address for External Controller)

 DG process:

• Detect PNF_flag to proceed to the PNF branch
• Map pnf_name to PlaybookName
• Execute ansible module (pass PlaybookName and EC_IPaddr as parameters)
• Post result on DMaaP

Ansible module on SDNC:

• Pass playbook to the External Controller over restconf interface
  • EC IP address and playbook name are passed from NB API call on SDNC to ansible module

External Controller:

• Acts as ansible server and executes playbook (i.e., execute ssh commands on remote PNF) 

PNF:

• This is an emulator that support CM commands

Links to JIRA Items for Casablanca:

https://jira.onap.org/browse/SDNC-424

https://jira.onap.org/browse/SDNC-425

https://jira.onap.org/browse/CCSDK-464

https://jira.onap.org/browse/INT-629

https://jira.onap.org/browse/INT-630

https://jira.onap.org/browse/SDNC-426

Q&A:

• Why not netconf?
  • For Casablanca, we are utilizing most of the workflows already exist in VNF in place upgrade. Eventually, netconf support will/might be needed.
• What happens if upgrade fails due to PNF, EM or even SDNC?
  • A rollback mechanism should be defined. Depending on where the failure is occurring, how to detect it, how to rollback and how to communicate the rollback (e.g., during failure or post-recovery) need more detailed analysis.
• Why doesn't ONAP (i.e., SDN controller) directly handle PNF configuration and upgrades?
  • There are too many complexities potentially involved in 5G PNF upgrades. EMS simplifies the processes in ONAP substantially and allows for easier adoption.
  • We plan to support various options including with External Controller, without External Controller, hybrid (e.g., some workflows with direct PNF access, some workflows with External Controller).

Test cases and status