TABLE OF CONTENTS

PNF SOFTWARE UPGRADE FLOW

Software upgrade flow to be tested for Casablanca:

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

LADDER FLOW DIAGRAM FOR PNF SOFTWARE UPGRADE:

DETAILED STEP DESCRIPTION

STEP 5: Pick W/F, Execute Work-flow

The Operator at the VID can select an appropriate work-flow which uses PNF Software Upgrade and execute the work-flow

STEP 6: Request ONAP Controllers & A&AI Query

SO identifier the appropriate PNF Controller

SO verifies and queries A&AI for the appropriate PNF entry

STEP 7: PNF Software Upgrade Pre-Check

SDN-C working with the External Controller performs Software upgrade Pre-Checks.

STEP 8: PNF Software Upgrade Precheck

[Vendor Specific] Apply checking rules, collect necessary data for pre-checking.

STEP 9: Retrieval Request/Response

[Vendor Specific] External Controller retrieves information from PNF.

STEP 10: Software Upgrade

Software upgrade command is issued via Ansible exchange to the External Controller

STEP 11: S/W Download & Activate

[Vendor Specific] Software download and software activation is performed between external controller and PNF.

STEP 12: Post Check

Post checks are requested by Controller to the External Controller via an Ansible exchange.

STEP 13: Check Rules

[Vendor Specific] Checking rules are applied. Information is collected and comparisons are done.

STEP 14: Result Notification

Success or fail result notifications are sent from external controller to SDN-C

STEP 15: Update A&AI Entry

A&AI Entry of the PNF is updated with the appropriate software versions.

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.

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 IN SDN-C:

• 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 SUPPORT:

• This is an emulator that support vendor specific instructions.

JIRA ITEMS FOR PNF SOFTWARE UPGRADE IN CASABLANCA:

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

QUESTIONS & ANSWERS:

• 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