General Flow
| 1 | VNF developers use the VNFSDK tools to create VNF descriptors based on the TOSCA YAML templates. VNF hardware platform capability requirements, if any, are captured in the VNF descriptor. |
| 2 | VNF developers use the VNFSDK tools to create VNF packages and upload them to the VNF marketplace. Uploaded packaged are validated and made available for use by ONAP operator(s). |
| 3 | VNF packages are downloaded from the VNF marketplace using SDC tools and on-boarded into the SDC catalog for use by ONAP service designers. |
| 4 | Service designers use SDC design tools to build and maintain network services. Network services are stored in the SDC catalog and made available to service consumers. |
| 5 | Service consumers browse the SDC catalog and choose services for instantiation. |
| 6 | Requests for instantiation are passed to the SO. The SO obtains NSD and VNFD information from the SDC. Hardware platform capability requirements are downloaded as part of the VNFD data. |
| 7 | SO at present has 2 possible options to take over from here
Hardware platform capability requirements are passed to the OOF. |
| 8 | The OOF uses the resource information stored in the AAI inventory database to obtain resource topology and capabilities data. It them makes use of placement policies to determine optimal homing and placement of a given network service. |
| 9 | Infrastructure providers register VIMs with the Multi-VIM layer, as part of the resource on-boarding process. |
| 10 | During the VIM registration process, resource topology and capabilities data is discovered and persisted in the AAI inventory database. From the HPA perspective, the AAI acts as the system of record for all HPA related information. |
| 11 | Any "day 2" operations that require VNF (re)instantiation, are performed by calling the SO and OOF components. Therefore, no changes to the "day 2" controllers is required in support of HPA. |
General Assumptions
This proposal does not require changes to the ONAP architecture and makes use of the existing ONAP management components. The following diagram identifies the ONAP components affected by this project:
ONAP Project Dependencies
Project | Dependencies |
|---|---|
| VNFSDK | Specification of VNF hardware platform requirements and dependencies as part of the VNF descriptor. |
| SDC | Infrastructure validation during VNF on-boarding, based on ingested VNF hardware dependencies. Propagation of ingested VNF hardware platform dependencies. |
| POLICY | Definition of HPA centric constraint policies as they apply to VNF instantiation, VNF resource optimization and VNF instance operation. |
| SO | Use of hardware platform requirements as input into the resource homing and optimization process. |
| OOF | Use of hardware platform requirements as constraints for VNF component homing and resource placement. |
| DCAE | Use of hardware platform telemetry in determination of network service and VNF instance health. |
| APP-C | Use of hardware platform requirements as constraints for VNF instance operation and remediation. |
| VF-C | Use of hardware platform requirements as constraints for VNF instance operation and remediation. |
| AAI | Modeling and persistence of hardware platform capabilities as part of the inventory information. |
| Multi-VIM | Dynamic discovery of hardware platform capabilities during VIM on-boafding and operation. |
Alignment with external standards and specifications
This project is dependent on use of the folliowing information and data model specifications:
- ETSI NFV IFA011 v2.3.1 - VNFD Information Model
- ETSI NFV SOL001 - VNFD TOSCA Data Model
- OASIS TOSCA SImple YAML Profile v1.2
- OASIS TOSCA NFV Profile (WD5)
Dependencies on other open source projects
None.
2 Comments
Viswanath Kumar Skand Priya
Question : Step 9 & 10 can happen anytime asynchronously right ? Doesn't need to happen "only" after Step 8 i.e VNF Placement decision by OOF
Alexander Vul
You are correct. The numbers are not meant to indicate a sequence. They are simply workflow labels...