...
PnP DUBLIN WORK ITEM | DESCRIPTION | ||||||||||||||||||||||||||||||
SO1: SO support of A&AI creation | [SO] A&AI UI can create an inactive PNF (inactive) A&AI entry. In Step #19A instead of EXITING, SO would go into WAIT STATE pending rehydration of RLF w/ pnfReady DEVELOPMENT STATUS:
| ||||||||||||||||||||||||||||||
| SO2: Service & NF Instance Association | Associating a xNF to a Service. Seen in the VID UI, after instantiation waiting for registration see only a Service instance, and beyond that a PNF resource instance associated with it. DEVELOPMENT STATUS: | ||||||||||||||||||||||||||||||
SO3: SO support for already existing PNF A&AI entries | [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) DEVELOPMENT STATUS: In ONAP/Casablanca this was updated, and irrespective of AAI entry existence for a PNF instance, the workflow execution always waits to receive a PNF registration event.
This is not planned to be changed in ONAP/Dublin release. | ||||||||||||||||||||||||||||||
[SO] Support of SO for updated AAI PNF instance model. Added March 13th 2019 → AAI team got a recommendation from architecutre committee to defer this item to ONAP/El Alto release. ASSOCIATED DEVELOPMENT: See task A&AI1 and PRH1. JIRA: (Depends on the A&AI work:
Epic Created: SO Dublin Page: Service Orchesrator Dublin Release | |||||||||||||||||||||||||||||||
| FUTURE (El Alto) | |||||||||||||||||||||||||||||||
SO-future: Controller Association [FUTURE MOVED TO EL ALTO] | [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. | ||||||||||||||||||||||||||||||
...
PnP DUBLIN WORK ITEM | DESCRIPTION | ||||||||||
Schema Adaptation | New A&AI schema adaptations: Chesla Wechsler found a discrepancy between PNFs and VNFs; VNFs are identified via VNF-ID (UUID), and PNFs - via PNF-name. PNF-id = UUID; PNF-name = Correlation ID. PRH use search API to find PNF instance based on PNF-name then get the PNF-id. pnfRegistration VES Event to get the Key to search A&AI. use "sourcename" (part of VES Common header). Take value of sourcename search A&AI to find a PNF entry. Added March 13th 2019 → AAI team got a recommendation from architecutre committee to defer this item to ONAP/El Alto release. ASSOCIATED DEVELOPMENT: See task A&AI1 and SO4.
| ||||||||||
| PRH2: Integration | [PRH] There might be more integration or development for the PRH in Dublin. | ||||||||||
| PRH3: PNF Registration Update the A&AI Entry | When the PNF registers, PRH should update the A&AI entry with the information in the VES event. PRH shall update A&AI with all fields from pnfRegistration VES event into all corresponding fields of A&AI entry. See the 5G - PNF Plug and Play wiki DEVELOPMENT STATUS:
| ||||||||||
| PRH4: PRH Re-Registration Support | PRH support for the Re-Registration Use Case in PNF PnP (for BBS Nomadic ONT PNF Re-registration Use Case). Which fields to compare in mapping field to determine a reregistration PNF. DEVELOPMENT STATUS:
|
...
A&AI IMPACTS
| DUBLIN ITEM | DESCRIPTION | ||||||||||||||||||||
[A&AI] Using the pnf-id (instead of pnf-name) as the index for PNF into A&AI. (discussion started in R3, socialized, Contact: Chesla Wechsler ). The URI will change, as a query parameter. API change in A&AI. No external API impacts. ACTIONS: Inform Clients of break in change & migration. ASSOCIATED DEVELOPMENT:
| |||||||||||||||||||||
| A&AI4: SO support of A&AI creation | [SO] A&AI UI can create an inactive PNF (inactive) A&AI entry. In Step #19A instead of EXITING, SO would go into WAIT STATE pending rehydration of RLF w/ pnfReady DEVELOPMENT STATUS: (Completed in ONAP/Casablanca -
| ||||||||||||||||||||
| A&AI5: SO support for already existing PNF A&AI entry | [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 | ||||||||||||||||||||
| MOVED TO R5 EL ALTO | |||||||||||||||||||||
| A&AI2: External Manager (EMS/NMS) [ESR] | [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 LOW PRIORITY | ||||||||||||||||||||
| A&AI3: Cloud Home Server (A&AI) | [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 | ||||||||||||||||||||
...