Overview
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.
More Information (Intel-specific)...
- https://software.intel.com/en-us/articles/openstack-epa-feature-breakdown-and-analysis
- https://docs.openstack.org/nova/pike/admin/cpu-topologies.html
- https://networkbuilders.intel.com/network-technologies/enhancedplatformawareness
- http://events17.linuxfoundation.org/sites/events/files/slides/High%20performance%20VMs%20using%20OpenStack%20Nova.pdf
Business Requirements
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.
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.
Participating Companies
- AT&T, Intel, Cloudify, China Mobile, Orange, ARM
Terminology Introduced
| 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. |
Enabled HPA Functionality
Release
R2
Specification and validation of VNF hardware platform requirements and dependencies as part of the VNF package (TOSCA).
R2
Use of hardware platform requirements (VNFD) at on-boarding time to verify that infrastructure is capable of supporting VNF instantiation and operation.
R3
R2
Discussion Pages
| Child pages (Children Display) | ||
|---|---|---|
|
Legend:
Status title N/A Status colour Green title CommiTTED Status colour Yellow title In Progress Status colour Red title
R2
Use of VNF hardware platform requirements as constraints for optimized homing and resource placement of VNF components during VNF instantiation.
R2
Use of hardware platform health information in determination of the VNF instance health.
R3
Use of VNF hardware platform dependencies as constraints for operation and remediation of running VNF instances.
R3
R3
R3
Discovery of hardware platform capabilities exposed by different VIMs.
R2
Modeling and persistence of discovered platform capabilities in the AA&I database.
R2
R3
R3
R2/R3
Discussion Pages
| Child pages (Children Display) | ||
|---|---|---|
|
TBD
Showcase Use Cases
Projects that enable HPA
| Project | PTL | |
|---|---|---|
| 1 | VNFSDK | |
| 2 | SDC | |
| 3 | SO | |
| 4 | AAI (impact) | |
| 5 | Multi-Cloud | |
| 6 | Policy | |
| 7 | OOF |
Projects that document HPA guidelines, use cases, requirements & test cases
Project
PTL
Project
PTL
Legend:
Limitations
| 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 discozzzvery of HPA capabilities. |
| 9 | HPA capabilities are not under monitoring. |
Projects that make use of HPA
HPA Functional Requirement JIRA Board
HPA Epics & Stories
Jira Legacy server System Jira columns key,summary,status,resolution maximumIssues 1000 jqlQuery filter = HPA_Filter ORDER BY project ASC serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176
| server | System Jira |
|---|---|
| columns | key,summary,status,resolution |
| maximumIssues | 1000 |
| jqlQuery | filter = HPA_Filter ORDER BY project ASC |
| serverId | 4733707d-2057-3a0f-ae5e-4fd8aff50176 |
Overview
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.
More Information (Intel-specific)...
- https://software.intel.com/en-us/articles/openstack-epa-feature-breakdown-and-analysis
- https://docs.openstack.org/nova/pike/admin/cpu-topologies.html
- https://networkbuilders.intel.com/network-technologies/enhancedplatformawareness
Business Requirements
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.
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.
Participating Companies
- AT&T, Intel, Cloudify, China Mobile, Orange, ARM
Terminology Introduced
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 |
Internal HPA Documentation
Project | PTL | |
|---|---|---|
| 1 | VNFRQTS |
External HPA Documentation
Organization | Contact | |
|---|---|---|
| 1 | ETSI NFV SOL |
Enabled HPA Functionality
| Functionality | MVP | Projects Involved | ONAP Release | Status | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Modeling of VNF hardware platform requirements and dependencies as part of the VNFD information model and TOSCA data models. | Yes | Modeling Subcommittee | R2 |
|
In R2, HPA requirements for each VDU (VNFC) of VNF are represented as a policy. Though policy driven HPA will continue to be there in R3, our intention is to auto-create HPA policies from VDU model of the service. Intention is to avoid creation of policies outside of model. Since TOSCA, industry standard, is chosen to represent model, even VNF vendors can provide the VNF HPA requirements.
Model driven HPA needs following enhancements:
- Creation of HPA policies dynamically from the VNFD/VDUD
- Verification of HPA requirements defined in the VNFD/VDUD during service creation
| |||||||||||||||||||
| 2 | Specification and validation of VNF hardware platform requirements and dependencies as part of the VNF package (TOSCA). | Yes | VNFSDK | R2 |
| ||||||||||||||
| 3 | Use of hardware platform requirements (VNFD) at on-boarding time to verify that infrastructure is capable of supporting VNF instantiation and operation. | No | SDC | R3 |
| ||||||||||||||
| 4 | Translation of VNF hardware platform requirements (VNFD) into OOF homing and placement policies. | Yes | SDC, Policy | R2 |
| ||||||||||||||
| 5 | Manual specification of OOF homing and placement policies based on hardware platform requirements (Policy Portal). | Yes | Policy | R2 |
| ||||||||||||||
| 6 | Use of VNF hardware platform requirements as constraints for optimized homing and resource placement of VNF components during VNF instantiation. | Yes | OOF, SO, Policy | R2 |
| ||||||||||||||
| 7 | Use of hardware platform health information in determination of the VNF instance health. | No | AAI, DCAE | R3 |
| ||||||||||||||
| 8 | Use of VNF hardware platform dependencies as constraints for operation and remediation of running VNF instances. | No | VF-C, APP-C | R3 |
| ||||||||||||||
| 9 | Use of VNF hardware platform dependencies as constraints for VNF autoscaling. | No | Scaling FR | R3 |
| ||||||||||||||
| 10 | Use of VNF hardware platform dependencies as constraints for VNF change management. | No | Change Management FR | R3 |
| ||||||||||||||
| 11 | Discovery of hardware platform capabilities exposed by different VIMs. | Yes | Multi-Cloud | R2 |
| ||||||||||||||
| 12 | Modeling and persistence of discovered platform capabilities in the AA&I database. | Yes | Multi-Cloud, AAI | R2 |
| ||||||||||||||
| 13 | SRIOV Discovery. | No | Multi-Cloud | R3 |
| ||||||||||||||
| 14 | SRIOV Day 0 Configuration. | No | TBD | R3 |
| ||||||||||||||
| 15 | VF-C/HPA integration. | No | VF-C | R2/R3 |
|
Testing Plan
Use of TOSCA based resource orchestration is a stretch goal.
There is no dynamic discovery of HPA capabilities.
HPA capabilities are not under monitoring.
HPA JIRA
HPA Functional Requirement JIRA Board
HPA Epics & Stories
| Gliffy |
|---|
| all | true |
|---|
Projects That Enable HPA
VNFSDK
SDC
SO
(impact)
Projects that document HPA guidelines, use cases, requirements & test cases
Project
PTL
`Projects that make use of HPA
Project
PTL
Legend:
R2 Limitations
Specification of VNF's hardware platform capability requirements is limited to TOSCA based VNFD's.
Specification of VNF's hardware platform capability requirements using HEAT is not supported.
Supported capabilities are limited to the ones discoverable via OpenStack APIs.
Use of container based VNF placement is not supported.
Specification of capability requirements is bounded by the set of capabilities discovered in #2.
Implementation of southbound (Multi-Cloud) facing SO workflows is limited to HEAT only.
|