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

PNF

SOFTWARE UPGRADE FLOW

SOFTWARE UPGRADE FLOW FOR CASABLANCA

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

Overall Process for Casablanca

LADDER FLOW DIAGRAM FOR PNF SOFTWARE UPGRADE:

Image Added

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.

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:

, 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:

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

DUBLIN ENHANCEMENTS

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

R5 EL ALTO

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

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.

Image Added

Image Added

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

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