Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Description

PNF Software upgrade includes:

  1. Support in-place software upgrade for PNF.
  2. Define generic building blocks, which can be used for workflow design in the design time.
  3. Identify gaps and amend ONAP components to support different flows for software management and configuration (e.g., with/without external controller, different ONAP controller options, different adaptors in ONAP controllers).
  4. Support External Controller (e.g., EMS) as the main entity responsible for carrying out the detailed vendor-specific software upgrade steps.
  5. Enhance precheck and postcheck steps in the upgrade process by vendor-specific rules. Define procedures involved in the design time and run time for specifying these rules. 
  6. Enhance PNF modeling needed for PNF software upgrades (e.g., expected software version) and define processes in ONAP components (e.g., SO, A&AI, DCAE, and ONAP Controllers) for successful/unsuccessful software upgrades. 
  7. Demonstrate single PNF upgrade and batch upgrade. 

Presentations:

  1. 5Guc-RAN Operations (SW upgrade)-Casablanca-Huawei&CMCC 05112018v1.pptx
  2. Change Management for life-cycle support from hybrid PNF and VNF management perspective_201806BeijingForum

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-vendorequip-modelsw-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

#Test Case DescriptionTest Status

1 EC registration test

Ensure ONAP controller can find out the EC

NOT TESTED

2 PreCheck test

Ensure the EC can receive the precheck command from ONAP controller

NOT TESTED

3 SwUpgrade test

Ensure the EC can receive the software upgrade command from ONAP controller

NOT TESTED

4 PostCheck test

Ensure the EC can receive the postcheck command from ONAP controller

NOT TESTED

5 New SW version report test

Ensure the software upgrade completion event can be reported to DCAE

NOT TESTED

6 New SW version update test

Ensure the new software version can be updated in A&AI

NOT TESTED

7 E2E Workflow execution test

Ensure the e2e software upgrade workflow can be executed at run time

NOT TESTED