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