PNF PnP FRANKFURT WORK ITEM

DESCRIPTION

VID1 Migration of Sub-worksflows

(Post-poned to R7)

Migration of existing PNF PnP sub-workflows to a new BB approach (probably we will be creating 4-5 new BBs).

VID Impact:

Within “old” VID macro orchestration pages, a special field to provide a pnf-id parameter (shall be actually called “correlationID” or “PNF correlationID”) has been displayed under the following conditions:

1. Service Model contains a PNF resource type.

When we migrate to BB approach, we`d keep the possibility to provide this parameter (PNF correlationID) to the SO API call as input.

How this will change with SO/BB approach, and with new VID GUI targeted at macro (GR) flows – we`d see exactly, after we execute some tests with new VID UI, and updated SO PNF BB code.
We`d have to check, what capabilities and conditions could be applied to display and process this “PNF Correlation ID parameter”.

Can the same BBs could be re-used in “standard” vCPE use-case.
We`re looking at a generic solution, and we`d probably display this additional field, when we figure out, that there is a PNF resource used in a Service Model.

In R6: only accessible via SO API not the VID GUI, E2E tests prepare environment cover case w/ SO API.

PnP R6 WORK ITEM

DESCRIPTION

CTL1: Controller PNF Interaction

[CONTROLLER] Controller definition (SDN-C) came so late in Casablanca, we had defined some additional optional parameter for the step37 Service Configuration but likely more evolution needs to be done. SDN-C was not the theoretical proper controller and people objected as this is conceptually the L0-L3 controller.

[STEP 35-37] - The SO to SDN-C and Controller to PNF exchange (Ansible or NetConf) was a carry-over item from R3. This requires that an API between SO to SDN-C is in place to support this. It requires that SDN-C support the appropriate Ansible Playbook and Directed Graph. Generic API. CDS has its own API to SO. The work being done with the CDS work is re-used for PnP U/C, so no new development needs to be done.

ASSOCIATED DEVELOPMENT:

(Jira)

Controller Design Studio (Design Time) - to customize configuration. This might be used to set the values of parameters that might be send down to a PNF.

NetConf - see the NetConf 5G U/C Wiki: 5G - Configuration with NETCONF

[A&AI] IP address or association with the External Manager. Is the ESR concept sufficient?

https://onap.readthedocs.io/en/beijing/submodules/aai/esr-server.git/docs/

During PnP, the IP address of the External Manager would saved/stored or set by user or by the PNF. Where would that be stored? would it be in A&AI. Information about the External Manager is discovered & stored. Note: The External Manager info is optional

[A&AI] Tracking the Cloud Home Server (CLLI, Cloud ID); is the association with the COMPLEX Object sufficient?

How-To: Register a VIM/Cloud Instance to ONAP

LOW PRIORITY

A&AI / Model

MODELING

[A&AI] GeoLocation information for the PNF reported via pnfRegistration VES Event

This will ONLY be modeling work in R6, functionality it moved to future release

MODELING WORK ONLY

A&AI4: A&AI pnf-id as INDEX for PNF

CANCELED

[Modeling] GeoLocation alignment in Modeling with RFC 6225 and the PNFD, A&AI schema, and SDC AID Data model.

(Sept 5) "Place" object (off of the Root) platform ONAP info-model. GB922 Location standards

Latitude/ Longitude / Altitude (RFC 6225) > TMF GB922 > ONAP > Complex & Place object.

LOW PRIORITY (Nice to have)

Presentation for Epic #4:

Secure Communication

between xNFs & ONAP