General Flow
| 1 | VNF Developers use VNF SDK tools to create VNF descriptors based on TOSCA YAML templates. If a given VNF has hardware platform capability dependencies, they are included in the VNF descriptor. |
| 2 | VNF Developers use V.NF SDK tools to create VNF packages and upload them to the VNF marketplace. VNF marketplace validates uploaded VNFs and makes them available for download. |
| 3 | The SDC downloads VNF packages from the VNF marketplace and on-boards them into the catalog for use by Service Designers. |
| 4 | Service Designers use SDC design tools to create network services and make them available in the catalog for use by Service Consumers. |
| 5 | Service Consumers browse the SDC catalog and choose a service for instantiation. |
| 6 | The SO downloads appropriate NSD and VNFD definitions from the SDC. If hardware platform capability requirements were present, they are downloaded as well. |
| 7 | The SO decomposes the service and calls OOF to optimize its homing and placement. Hardware platform capability requirements are passed to the OOF as well. |
| 8 | The OOF consults the AAI inventory database to obtain resource topology and capability information. 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. |
| 10 | As part of the registration process, resource topology information and hardware platform capabilities are discovered and persisted in the AAI inventory database for subsequent use by the OOF. |
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.