TABLE OF CONTENTS

MEETING LOGISTICS

When:
7:00am to 8:00am
(GMT-07:00) America/Los Angeles
Repeats: Weekly on Thursday

Where:
ONAP4 https://zoom.us/j/519627903

OVERVIEW

PNF SOFTWARE UPDATE INTRODUCTION

PNF Software upgrade is one aspect of Software Management. The purpose is to modify the software running on the PNF. This could be used to update the PNF software to a newer or older version of software.

PNF SOFTWARE UPDATE TOPICS

PNF Software update includes:

Support in-place software update for PNF.
Define generic building blocks, which can be used for workflow design in the design time.
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).
Support External Controller (e.g., EMS) as the main entity responsible for carrying out the detailed vendor-specific software upgrade steps.
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.
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.
Demonstrate single PNF upgrade and batch upgrade.

BUSINESS DRIVERS

This section describes Business Drivers for this Use Case.

Executive Summary - PNF software updates are routine for network upgrades to support new features, improve efficiency or increase capacity on the field, and to eliminate bugs. This use case positions ONAP as a vantage point in orchestrating and managing PNF software upgrades inline with the business and service objectives.

Business Impact - Deployment and orchestration of new network services over both VNFs and PNFs in a model and software driven way simplifies the network management. As 5G networks will host a large number of PNFs from multiple vendors, streamlining service upgrades that involve PNF software changes through ONAP will reduce the OPEX substantially.

Business Markets - Carriers both in the mobile and fixed-line space host PNFs at the edge of the network. New 5G deployments as well as legacy 4G systems in the mobile carrier space should be considered as target markets.

Funding/Financial Impacts - Orchestrating PNF software updates via an ONAP deployment will enable better service planning, faster introduction of new network services over field-deployed PNFs, and reduce the operational costs.

Organization Mgmt, Sales Strategies - Harmonizing PNF and VNF software management in a model and workflow driven manner is essential in 5G systems where PNFs will continue to exist in large numbers and they are expected to have more frequent software upgrades (as they will have more capabilities that can be controlled or upgraded via software). Thus ONAP can be the "go-to" solution if this harmonization can be done successfully.

ASSOCIATED PRESENTATIONS:

PNF SOFTWARE UPGRADE FLOW

SOFTWARE UPGRADE FLOW 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)

Precheck payload	SoftwareUpgrade payload	Postcheck payload
"payload": "{\"pnf-flag\":\"true\", \"pnf-name\": \"5gDU0001\",\"pnfId\": \"5gDU0001\", \"ipaddress-v4-oam\": \"EC_ip\",\"oldSwVersion\": \"v1\", \"targetSwVersion\": \"v2\", \"ruleName\": \"r001\", \"Id\": \"10\", \"additionalData\":\"{}\"}"}}	"payload": "{\"pnf-flag\":\"true\", \"pnf-name\": \"5gDU0001\",\"pnfId\": \"5gDU0001\", \"ipaddress-v4-oam\": \"EC_ip\",\"oldSwVersion\": \"v1\", \"targetSwVersion\": \"v2\", \"Id\": \"10\", \"additionalData\":\"{}\"}"}}	"payload": "{\"pnf-flag\":\"true\", \"pnf-name\": \"5gDU0001\",\"pnfId\": \"5gDU0001\", \"ipaddress-v4-oam\": \"EC_ip\",\"oldSwVersion\": \"v1\", \"targetSwVersion\": \"v2\", \"ruleName\": \"r102\", \"Id\": \"10\", \"additionalData\":\"{}\"}"}}

Note that:
- 1) playbookname is not needed, since it is configured in sdnc_container:/opt/onap/sdnc/data/properties/lcm-dg.properties to your playbookname prefix
- 2) pnf-name is also not needed(recommend to keep it), since vnf-id is regarded as a pnf-name when pnf-flag is true
- 3) pnfId is needed (in huawei's playbook) , since playbook will use it
- 4) Id is needed (in huawei's playbook) , since playbook will use i
- 5) ipaddress-v4-oam is needed, it is the ip address of EC, since it will be translated into NodeList array in ansible server.

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.
Note that:
- 1) the remote access to EC must be configured in Ansible_Inventory
- 2) the ip address must be provided in the LCM payload

PNF SUPPORT:

This is an emulator that support vendor specific instructions.

DEVELOPMENT STATUS:

JIRA ITEM	DESCRIPTION
SDNC-424 - Getting issue details... STATUS	SDN-C 424: Create new directed graph (DG) for 5G PNF pre-check, upgrade and post-check
SDNC-425 - Getting issue details... STATUS	SDN-C 425: Create new module on SDNC to talk to EC (External Controller) using Ansible
CCSDK-464 - Getting issue details... STATUS	CCSDK-464 Create and push Ansible playbooks for 5G RAN PNF pre-check, software upgrade and post check
INT-629 - Getting issue details... STATUS	INT-629 Setup environment to integrate and test software upgrade for 5G RAN PNF
INT-630 - Getting issue details... STATUS	INT-630 Integrate emulator for EC and PNF into ONAP test environment
SDNC-426 - Getting issue details... STATUS	SDN-C 426 Define north bound API payload updates for EC/PNF

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).
Options for determining which Protocol the PNF supports (Ansible, NetConf, Chef)
- Option (1): Directed Graph per Protocol - for example, one dedicated directed graph for Ansible and a different DG for Netconf each with their own SO building blocks. Multiple SO building blocks could be used for operations (new SO building blocks would need to be developed). The SO to Controller to API. This would require multiple yang files to work. WORK-EFFORT: x. PROS/CONS: y. TECHNICAL DEBT: z.
- Option (2): LCM API based - In the LCM API for S/W Upgrade w/ one Directed Graph but the API payload has an optional parameter that specifies the DG which is executed. This was used for VNF vs PNF S/W upgrade. This was used in R3/Casablanca. Wanted to pass an Ext. Mgmt IP@ in the API payload. In the LCM API specify whether it is PNF/VNF. WORK-EFFORT: x. PROS/CONS: y. TECHNICAL DEBT: z.
- Option (3): Self-Service API - A self-service API is being developed by the CDS team. This API allows you to specify the work-flow to use when that API is used. The API remains the same, but a parameter indicates which work-flow should be used. WORK-EFFORT: x. PROS/CONS: y. TECHNICAL DEBT: z.
Alignment with VNF upgrades
- Harmonized Solution. One Workflow/One API for everything. VNF/PNF (different PNFs)

EVOLUTION OF PNF SOFTWARE UPGRADE

This section describes the potential evolution of PNF Software upgrade. There are many potential software management functions that could be introduced into the ONAP ecosystem. These functions represent potential future enhancements that could be explored.

SOFTWARE MANAGEMENT FUNCTIONS

The following table describes some of the Software Management Functions

FUNCTION	ICON	DESCRIPTION
Software Download		Software is downloaded to the NF (PNF or VNF) with the intention of updating or changing the currently running software on the NF.
Software Activation		After Software is downloaded, it is activated and becomes available to provider service.

DUBLIN ENHANCEMENTS

The following table summarizes some potential Dublin (R4) enhancements that will be developed and evaluated.

ENHANCEMENT	DESCRIPTION
PNF Reporting	PNF sends information regarding its Software Version directly to ONAP through a VES event.
Design Time Components	PNF software update workflow design, artifact onboarding (e.g., playbooks), upgrade rule list, utility of software version list.
PNF Package Update	A software update may require a change in the PNF Package before the software update or post update or both.
Software Update Coverage Analysis	Find out what services, control loops, etc. are impacted during and post software update before the PNF software update
Post/Pre PNF SW Update Event Workflows	Deregistration, re-registration
Coherence across VNF and PNF in-place software upgrade processes	Currently PNF and VNF entries in A&AI diverge that requires DG branching. Can we unify the process for both?

R5 EL ALTO

The following table summarizes some potential El Alto (R5) enhancements that will be developed and evaluated.

ENHANCEMENT	DESCRIPTION
PNF Reporting	PNF sends information regarding its Software Version directly to ONAP through a VES event.
Design Time Components	PNF software update workflow design, artifact onboarding (e.g., playbooks), upgrade rule list, utility of software version list.
PNF Package Update	A software update may require a change in the PNF Package before the software update or post update or both.
Software Update Coverage Analysis	Find out what services, control loops, etc. are impacted during and post software update before the PNF software update
Post/Pre PNF SW Update Event Workflows	Deregistration, re-registration
Coherence across VNF and PNF in-place software upgrade processes	Currently PNF and VNF entries in A&AI diverge that requires DG branching. Can we unify the process for both?
VID Support	Execute the e2e run time workflow starting from VID command. In Casablanca, the process exists starting from the SDNC Northbound.
NetConf Support	Current workflow is driven by Ansible playbooks.

SOFTWARE UPGRADE FLOW FOR DUBLIN

The following diagram shows another flow that is supported in the R4/Dublin release.

It compliments, the R3/Casablanca release PNF Software Upgrade Flow

A notable difference between the two flows is a focus on ONAP communicating directly with the PNF.

DETAILED STEP DESCRIPTION for R4/Dublin

STEP 1: 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 2: Request ONAP Controllers & A&AI Query

SO identifier the appropriate PNF Controller

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

STEP 3: PNF Software Upgrade Pre-Check

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

STEP 3b: Retrieval Request/Response

Retrieve information from PNF.

STEP 4: Software Upgrade

Software upgrade command is issued via PNF supported communication protocol and exchange to the PNF

SO: Requests S/W Upgrade

STEP 4b: S/W Download & Activate

Controller Performs software upgrade steps including download of SW to the PNF and then activates it.PNF.

STEP 5: Post Check

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

STEP 5a: Check Rules

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

STEP 5b: Result Notification

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

STEP 6: Update A&AI Entry

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

ROADMAP

This wiki page represents a "living" page and landing spot to learn about PNF Software upgrade. The roadmap captures developments that have been made and ones that are planned in future releases.

TEST CASES AND STATUS

#	Test Case Description	Test Status
1 EC registration test	Ensure ONAP controller can find out the EC	NOT NEEDED (Specify in Inventory and payload)
2 PreCheck test	Ensure the EC can receive the precheck command from ONAP controller	PASS
3 SwUpgrade test	Ensure the EC can receive the software upgrade command from ONAP controller	PASS
4 PostCheck test	Ensure the EC can receive the postcheck command from ONAP controller	PASS
5 New SW version report test	Ensure the software upgrade completion event can be reported to DCAE	DEFERRED (Moved to Dublin)
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	DEFERRED (Moved to Dublin)

NB LCM Test Result

1) UpgradePreCheck

Response Body
{
  "output": {
    "common-header": {
      "api-ver": "2.00",
      "originator-id": "664be3d2-6c12-4f4b-a3e7-c349acced203",
      "sub-request-id": "1",
      "request-id": "664be3d2-6c12-4f4b-a3e7-c349acced203"
    },
    "status": {
      "code": 400,
      "message": "Ansible Request  8200a38f-03d3-43ac-935e-2c43c9434872 finished with Result = success, Message = FINISHED"
    }
  }
}

Response Code
200

2) UpgradeSoftware

Response Body
{
  "output": {
    "common-header": {
      "api-ver": "2.00",
      "originator-id": "664be3d2-6c12-4f4b-a3e7-c349acced203",
      "sub-request-id": "3",
      "request-id": "664be3d2-6c12-4f4b-a3e7-c349acced203"
    },
    "status": {
      "code": 400,
      "message": "Ansible Request  73d59f55-f7b2-45c5-acf6-dbbc9b7ded73 finished with Result = success, Message = FINISHED"
    }
  }
}

Response Code
200

3) UpgradePostCheck

Response Body
{
  "output": {
    "common-header": {
      "api-ver": "2.00",
      "originator-id": "664be3d2-6c12-4f4b-a3e7-c349acced203",
      "sub-request-id": "2",
      "request-id": "664be3d2-6c12-4f4b-a3e7-c349acced203"
    },
    "status": {
      "code": 400,
      "message": "Ansible Request  e1b062c9-da8e-4606-b12a-723b7f57d558 finished with Result = success, Message = FINISHED"
    }
  }
}

Response Code
200

SUPPORTING FILES

Browser not supported