PNF Software upgrade flow to be tested for Casablanca:

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

Flow Diagram of Software Upgrade

Image Added

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

DmaapListener  ←  (REST) →  LcmAPI  - DirectedGraph – AnsibleAdapter ←  (REST) → Ansible Server

Interface in the southbound of SDNC

SDNC (i.e., Ansible Server) ← (ssh) → External Controller ← (ssh or netconf) → 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) (playbooks come prepackaged with SDNC and should be committed before code freeze)
    • Q: how do we associate playbooks with the PNF? (In Casablanca playbook names will reside in SDNC configuration file. In Dublin this can be refined as below)
      • 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)
• ipaddress-v4-oam : string (IPv4 ( IPv6 will use separate field?) 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 ipaddress-v4-oam as parameters)
• Post result on DMaaP

Ansible module  and Ansible Server on SDNC:

• Ansible module passes PlaybookName and EC_IPaddr to Ansible Server over restconf interface
  • ipaddress-v4-oam comes from NB API payload, PlaybookName is constructed from pnf-name during DG process (need to double check this)
• Ansible server playbacks the ansible playbook and issues ssh commands to External Controller
  
  

External Controller:

• Receives ssh commands regarding software management and sends vendor specific instructions to PNF. 

PNF:

• This is an emulator that support vendor specific instructions.

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