This is page is being used to track the realization of the Hardware Platform Awareness (HPA) functional requirement defined in support of VoLTE, vCPE and 5G use cases. The requirement calls for enablement of hardware platform feature awareness (HPA) inside the ONAP management platform, or means by which knowledge about underlying compute hardware platform capabilities is exposed to VNFs running on top of the platform in order to optimize, accelerate and/or otherwise augment their execution. In ONAP, HPA enablement focuses on discovery, health monitoring and configuration of hardware platform capabilities within the NFV infrastructure, and their consumption by the virtual network functions and network services deployed on top of the infrastructure.
This requirement is required in support of commercial VNF implementations, that are used as part of vCPE, VoLTE and 5G use cases, and require hardware assisted acceleration. This requirement is also needed by the ONAP Optimization Framework (OOF) project in order to optimize homing and placement of hardware assisted VNFs.
Term | Definition |
---|---|
Hardware Platform Awareness (HPA) | The means by which the underlying NFV-I hardware platform capabilities are exposed to the network service orchestration and management functionality, for the purpose of fulfilling VNF instantiation-time hardware platform requirements. |
HPA Enablement | The implementation of HPA awareness in ONAP. |
Scope
The scope of this requirement is limited to consumption of hardware platform capabilities for the purpose of VNF performance acceleration and optimization. Other uses of HPA are not in scope.
1 | Specification of VNF's hardware platform capability requirements is limited to TOSCA based VNFD's. |
2 | Specification of VNF's hardware platform capability requirements using HEAT is not supported. |
3 | Supported capabilities are limited to the ones discoverable via OpenStack APIs. |
4 | Use of container based VNF placement is not supported. |
5 | Specification of capability requirements is bounded by the set of capabilities discovered in #2. |
6 | Implementation of southbound (Multi-Cloud) facing SO workflows is limited to HEAT only. |
7 | Use of TOSCA based resource orchestration is a stretch goal. |
8 | There is no dynamic discovery of HPA capabilities. |
9 | HPA capabilities are not under monitoring. |
Enabled Functionality
Discussion Pages
Project | PTL | Committed for R2 | M1 | M2 | MVP | HPA Epics | |
---|---|---|---|---|---|---|---|
1 | VNFSDK | Yes | |||||
2 | SDC | Conditional commitment, based on 2 Intel resources | Yes | ||||
3 | SO | Conditional commitment, based on 2 Intel resources | Yes | ||||
4 | AAI (impact) | Yes | |||||
5 | Multi-Cloud | Yes | |||||
6 | Policy | Yes | |||||
7 | OOF | Conditional on on availability of HPA requirement (VNFD) and HPA capability (AAI) information. | Yes |
Project | PTL | Committed for R2 | MVP | HPA Epics | Notes | |
---|---|---|---|---|---|---|
1 | VNFRQTS | Yes |
Project | PTL | Notes | |
---|---|---|---|
1 | APP-C | There is no direct impact on APP-C, given that all instantiation actions are "outsourced" to the SO/OOF. | |
2 | VF-C | Changes to VF-C will be required in order to incorporate use of HPA into instantiation and operation. | |
3 | DCAE |