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. |
Discussion Pages
- Blocking Issues to HPA Casablanca Integration
- Conversion from high-level TOSCA DM to low-level format
- Discovery of HPA related information in MultiCloud
- DRAFT ONAP Virtual Network Function Descriptor (VNFD) based on TOSCA Simple YAML Profile Specification
- FPGA and GPU support
- Gap between TOSCA DM and low level used
- HPA & Cloud Agnostic Intent - R3 Test Plan (In Progress)
- HPA Architecture & Design Considerations
- HPA Beijing Testing
- HPA Enhancements (For Casablanca Release)
- HPA Hardening Issues
- HPA Impact on the AAI Project
- HPA Impact on the SDC Project
- HPA impact on the SO project
- HPA Impact on the VNF SDK Project
- HPA Policies and Mappings
- HPA Related Personas
- HPA Release 4.0 focus
- HPA Requirement & Capability Specification
- HPA - SR-IOV NIC design
- HPA Telemetry Monitoring - Design
- HPA - Telemetry OOF and A&AI
- Persistence of HPA related information in AAI
- Specifying HPA Capability Requirements using TOSCA-based VNF Descriptors
- Success Criteria for HPA Enablement
- Supported HPA Capability Requirements(DRAFT)
- TOSCA VNFD Orchestration Issues and Limitations
- VF-C Casablanca HPA Design
Projects that enable HPA
| Project | PTL | |
|---|---|---|
| 1 | VNFSDK | |
| 2 | SDC | |
| 3 | SO | |
| 4 | AAI (impact) | |
| 5 | Multi-Cloud | |
| 6 | Policy | |
| 7 | OOF |
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 discovery of HPA capabilities. |
| 9 | HPA capabilities are not under monitoring. |
Projects that make use of HPA
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 |
|---|---|
| ETSI NFV SOL |
HPA Casablanca Enhancements
| Feature | Projects | Status | Notes | |
|---|---|---|---|---|
Support for vFW and vDNS use cases In R2, only the vCPE SO workflow was enhanced to call OOF for homing decisions. In R3, SO workflows for vFW and vDNS will also call OOF for homing decisions. | SO | GREEN | Most of code will be in by Wednesday. Test plan to ensure that both vFW and vDNS use cases are tested with HPA feature | |
Use of Multi-Cloud Service instead of SO for direct communication with OpenStack instances in cloud regions In R2, as part of the vCPE workflow, SO bypassed the Multi-Cloud service and called OpenStack directly.. In R3, this will no longer be the case and SO will call the Multi-Cloud Service. Multi-Cloud service will, in turn, communicate with OpenStack instances within different cloud regions. | SO | YELLOW | Code being integrated late on Wednesday. Test plan should ensure that SO is configured to work with Multi-Cloud Service. | |
Derivation of HEAT parameters from OOF homing decisions in the Multi-Cloud Service In R2, vCPE HEAT template parameters and their values were generated by SO, based on OOF homing decisions because SO was calling Openstack directly. In R3, communication with OpenStack is moved to the Multi-Cloud Service and SO will no longer generate HEAT template parameters. Instead, the Multi-Cloud API will accept directives from OOF and SDN-C, passed as API call parameters. Multi-Cloud service will generate HEAT template parameters based on these directives. | SO OOF Multi-Cloud | GREEN | Dependency on #2. Test plan should ensure that HEAT parameters and values generated by Multi-Cloud are as expected. | |
SRIOV-NIC HPA feature support SRIOV-NIC HPA feature is added in R3. | Multi-Cloud SO | GREEN | Dependency on #2 and #3. Test plan should ensure that OOF makes right decisions and right Openstack flavor is selected. | |
Cloud-region and flavor selection enhancements in OOF In R2, OOF always selected the first cloud region to satisfy all mandatory HPA requirements, even if multiple cloud regions were able to satisfy the requirements. In R3, OOF will use scoring to pick the right cloud region, such that the region with the highest score is always chosen. | OOF | GREEN | Test plan should cover to ensure that the right region with best score is selected in case of multiple regions. Missing E2E integration testing, can be done after M4 | |
Support for vCPE use case In R2, vCPE orchestration was only possible using SO and HEAT templates. In R3, vCPE orchestration will also be possible using VF-C and partially ETSI NFV SOL001 v0.6.0 compliant TOSCA templates. As part of this change, VF-C (NSLCM) will be enhanced to communicate with OOF and use OOF supplied recommendations for placement. | VF-C | Test plan should ensure that vCPE use case is tested using both VF-C and SO. In either case, the same OpenStack flavor and cloud region should be selected for VNF placement. | ||
HPA telemetry and HPA state based placement decisions Stretch goal, may not happen in R3 time frame | RED |
HPA Functionality Enablement Plan
| Functionality | MVP | Projects Involved | Availability | Status | |
|---|---|---|---|---|---|
| 1 | Modeling of VNF hardware platform requirements and dependencies as part of the VNFD information model and TOSCA data models. | Yes | Modeling Subcommittee | R3 | COMMITTED |
| 2 | Specification and validation of VNF hardware platform requirements and dependencies as part of the VNF package (TOSCA). | Yes | VNFSDK | R3 | COMMITTED |
| 3 | Use of VNFD supplied hardware platform requirements at on-boarding time to verify that infrastructure is capable of supporting VNF instantiation and operation. | No | SDC | R3 | STRETCHR3 |
| 4 | Translation of VNFD supplied VNF hardware platform requirements into HPA related OOF homing and placement policies. | Yes | SDC, Policy | R3 | COMMITTED |
| 5 | Manual specification of HPA related OOF homing and placement policies based on hardware platform requirements. | Yes | Policy | R2 | DONE |
| 6 | Use of VNF hardware platform requirements as constraint policies for optimized homing and resource placement of VNF components during VNF instantiation. | Yes | OOF, SO, Policy | R2 | DONE |
| 7 | Use of hardware platform telemetry in determination of the VNF instance health. | No | AAI, DCAE | R4 | SCHEDULED |
| 8 | Use of hardware platform telemetry to enhance OOF homing and placement decisions. | No | Multi-Cloud, AAI, OOF | R3 | COMMITTED |
| 9 | Use of VNF hardware platform dependencies as constraints for operation and remediation of running VNF instances. | No | VF-C, APP-C | R3 | DELAYEDR4 |
| 10 | Use of VNF hardware platform dependencies as constraints for VNF autoscaling. | No | Scaling FR | R3 | DELAYEDR4 |
| 11 | Use of VNF hardware platform dependencies as constraints for VNF change management. | No | Change Management FR | R3 | DELAYEDR4 |
| 12 | Discovery of hardware platform capabilities exposed by different VIMs. | Yes | Multi-Cloud | R2 | DONE |
| 13 | Modeling and persistence of discovered platform capabilities in the AA&I database. | Yes | Multi-Cloud, AAI | R2 | DONE |
| 14 | SRIOV Discovery. | No | Multi-Cloud | R3 | COMMITED |
| 15 | SRIOV Day 0 Configuration. | No | TBD | R3 | COMMITTED |
| 16 | VF-C/HPA integration. | No | VF-C | R3 | COMMITTED |
Casablanca Test Plan (DRAFT)
Please see this link: HPA & Cloud Agnostic Intent - R3 Test Plan (In Progress)
Assumptions
VolTE and vCPE use cases will be used to validate the function of HPA end-to-end. The HPA test plans for Casablanca make the following assumptions with respect to function of ONAP components affected by HPA enablement functional requirement.
- There are no changes to the HPA capability discovery process.
- There are no changes to how discovered HPA capabilities are persisted in AAI.
- There are no changes to specification of HPA constraint policies used by OOF.
- Existing VoLTE and vCPE tests are sufficient to perform the end-to-end HPA testing.
Based on the above assumptions, the scope of the testing effort is limited to the following:
VNF On-Boarding (VNFSDK/SDC)
| Test ID | Test Description | Status |
|---|---|---|
| 101 | Format and content of the VNFD, as supplied via the CSAR file are unaffected by VNF on-boarding. | TO BE DONE |
| 102 | HPA requirements are unaffected by VNF on-boarding. | TO BE DONE |
| 103 | On-boarding of VNFs with HPA requirements fails if appropriate ONAP components (e.g. HPA requirement interpreter plugin) are not found. | TO BE DONE |
| 104 | HPA requirement validation errors result in termination of the VNF on-boarding process. | TO BE DONE |
VNF Design (SDC)
| Test ID | Test Description | Status |
|---|---|---|
| 201 | VNFs with TOSCA-encoded VNFDs can be used to build network services. | TO BE DONE |
| 202 | VNFD and all of its content, HPA requirements included, remain immutable. | TO BE DONE |
VNF Distribution (SDC/SO/Policy)
| Test ID | Test Description | Status |
|---|---|---|
| 301 | Policy and SO components are able to register as SDC distribution clients. | TO BE DONE |
| 302 | VNFD can be distributed through the SDC distribution framework. | TO BE DONE |
| 303 | HPA requirement parsing errors result in termination of the VNF distribution process. | TO BE DONE |
VNF Instantiation (SO/VF-C/OOF)
| Test ID | Test Description | Status |
|---|---|---|
| 401 | VNFs with TOSCA-encoded VNFDs can be instantiated using VF-C. | TO BE DONE |
| 402 | VNFs with TOSCA-encoded VNFDs can be instantiated using SO. | TO BE DONE |
| 403 | The same VNF package can be used with all ONAP orchestrators. | TO BE DONE |
| 404 | HPA requirements are consistently interpreted by all orchestrators. | TO BE DONE |
SR-IOV NIC Support
| Test ID | Test Description | Status |
|---|---|---|
| 501 | VNFs including SR-IOV NIC requirements with TOSCA-encoded VNFDs can be instantiated using VF-C. | TO BE DONE |
| 502 | VNFs including SR-IOV NIC requirements with TOSCA-encoded VNFDs can be instantiated using SO. | TO BE DONE |
HPA Service Assurance (Platform Telemetry)
| Test ID | Test Description | Status |
|---|---|---|
| 601 | TO BE DONE |
9 Comments
Brian Hedstrom
Alexander Vul SDC, Policy, DCAE, APP-C and VNF-C projects will not require any HPA-related requirement changes? E.g., they are HPA-agnostic?
Alexander Vul
SDC and Policy projects require changes in order to enable use of HPA. DCAE, APP-C and VF-C are considered to be "consumers" of the HPA Awareness features, and may require changes in order to incorporate use of HPA into their respective functionalities.
Brian Hedstrom
Some review comments:
Add a Legend for the Green, Yellow, and Red meanings/usageAdolfo Perez-Duran
Can we get clarification on AAI's role. Does AAI require development or does it only make use of/store of HPA data?
Alexander Vul
Adolfo,
There is no material impact on the AAI project. Most of the work is cosmetic and focused on persistence of discovered HPA capabilities.
Alex
Viswanath Kumar Skand Priya
Hi Alexander Vul,
Question : HPA Enablement depends on HPA capabilities from underlying VIM. Or in other words, VIM has to be pre-configured with HPA/EPA parameters enabled right? For example, incase of Openstack, EPA/HPA specific flavours have to be pre-created and then get discovered by ONAP. Is my understanding correct ?
BR,
Viswa
Alexander Vul
Your understanding is correct. The expectation is that the flavors have been pre-configured within the VIM.
Viswanath Kumar Skand Priya
Thanks. Few follow-up questions :
Srinivasa Addepalli
On your question 1:
Many VIMs provide a way to read not only list of flavors, but also properties of each flavor. In case of Openstack:
I believe other VIMs such as Azure and AWS also has similar API to get flavor specific information.
On your question 2:
At least in today world, compute servers are fixed with set of HPA capabilities. Based on types of compute servers particular region has, administrator creates as many flavors. There is a movement in industry (OCP, RSD etc..) for reconfigurable/software-defined servers, where server can be composed with various discrete hardware components (accelerators, disk etc..) based on workload demands (https://www.intel.com/content/www/us/en/architecture-and-technology/rack-scale-design-overview.html). At that time dynamic flavor creation would be required.
Hi, Huang Haibin , Nate Potter and Ritu Sood
Please add if I missed any.