5G - PNF Plug and Play (Casablanca carry-over items)

PnP DUBLIN WORK ITEM

DESCRIPTION

SO1: Controller Association

[SDC/SO] The PNF controller caused quite a stir in Casablanca, the tension between Design/Platform Model vs Run-Time/Deployment Model.
As a result the SO controller design was sub-optimal and should be addressed in Dublin.

SO2: SO support of A&AI creation

SO3: SO support for already existing PNF A&AI entries

[SO] Support of SO for updated AAI PNF instance model.
PNF-ID is going to be used as unique PNF idenitifcator, instead of PNF-Name, used in ONAP/Casablanca.
PNF PnP sub-flow might need modifications related to how PNF instance objects are created.

ASSOCIATED DEVELOPMENT:

See task A&AI1 and PRH1.

PnP DUBLIN WORK ITEM

DESCRIPTION

AAF1: Security Enhancement

[AAF] Security enhancements slated for Dublin will need to be working for PnP Use Case. Discussing with DCAE about supporting TLS authentication just with Certificate without Username & Password. If the NF already uses the UN&P for the HTTP connection (that should still work).

Certificate use should be working in Dublin to setup the HTTPS connection.

PROPOSAL: Thus, both Certificate & Username & Password will be supported. (This is suggested for backward compatibility). i.e. there are already existing deployment.

PROPOSAL: It is recommended to use the Certificate.

Certificates as part of the authorization? Subject of the certificate is something that can be used as authorization, the proposal to DCAE is that there is a list of authorized users/subjects. Initially it could be manually configured, but the objective is that this would come from AAF.

Start with Certificates local check: subjects against a list (w/ wildcards). Agree w/ appropriate interface w/ AAF then integrate w/ AAF. If identity not found use basic authentication a second check w/ username & password. otherwise access is rejected (HTTP return code).

PnP DUBLIN 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.

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.

[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

[SO] Support of SO for an already existing PNF (active) A&AI Entry

(use case with a deleted & recreated service or instantiating 2nd service using the same PNF)

In Step #19B SO would exit and service creation would continue

PnP DUBLIN WORK ITEM

DESCRIPTION

VID1: VID Enhancements

WORK ORDER (Optional) – Supporting Work Order. Supported with service specific  applications. Inventory systems (optional). Future extension to ONAP. Interface w/ BSS-OSS systems (API).

ACTION: Error cases (check if SDC model parameters != A&AI PNF entry)