Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

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.

Participating Companies

  • AT&T, Intel, Cloudify, China Mobile, Orange, ARM

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

TermDefinition
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 EnablementThe implementation of HPA awareness in ONAP.
Enabled Functionality
.


Discussion Pages

Child pages (Children Display)
alltrue


Projects that enable HPA


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
1APP-CThere is no direct impact on APP-C, given that all instantiation actions are "outsourced" to the SO/OOF.
2VF-CChanges to VF-C will be required in order to incorporate use of HPA into instantiation and operation.
3DCAE

Internal HPA Documentation


Project

PTL

1VNFRQTS

External HPA Documentation

Organization

Contact

ETSI NFV SOL

Alex Vul, Intel

Thinh Nguyenphu (Unlicensed), Nokia

Bruno Chartras, Orange


Gliffy
bordertrue
size1200
nameHPA Enablement Flow Diagram
pagePin3


HPA Casablanca Enhancements





FeatureProjectsStatusNotes

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

Status
colourGreen

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
Multi-Cloud

Status
colourYellow

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 
Status
colourGreen

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 

Status
colourGreen

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

Status
colourGreen

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
SDC
Policy


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


Status
colourRed





HPA Functionality Enablement Plan


FunctionalityMVPProjects InvolvedAvailabilityStatus
1Modeling of VNF hardware platform requirements and dependencies as part of the VNFD information model and TOSCA data models.YesModeling Subcommittee

R3

Status
colourGreen
titleCommitted


2

Specification and validation of VNF hardware platform requirements and dependencies as part of the VNF

template

package (TOSCA).

YesVNFSDK

R3

Status
colourGreen
titleCommitted

3

Use of

VNF

VNFD supplied hardware platform

dependencies

requirements at on-boarding time to verify that infrastructure is capable of supporting VNF instantiation and operation.

NoSDC

R3

Status
colourYellow
titlestretch
Status
titleR3

4Translation of VNFD supplied VNF hardware platform requirements into HPA related OOF homing and placement policies.YesSDC, Policy

R3

Status
colourGreen
titlecommitted

5Manual specification of HPA related OOF homing and placement policies based on hardware platform requirements.YesPolicy

R2

Status
colourGreen
titleDone

6

Use of VNF hardware platform

dependencies

requirements as

constraints

constraint policies for optimized homing and resource placement of VNF components during VNF instantiation.

YesOOF, SO, Policy

R2

Status
colourGreen
titleDone

7

Use of hardware platform

health information

telemetry in determination of the VNF instance health.

NoAAI, DCAE

R4

Status
titlescheduled

8Use of hardware platform telemetry to enhance OOF homing and placement decisions.NoMulti-Cloud, AAI, OOFR3

Status
colourGreen
titlecommitted

9

Use of VNF hardware platform dependencies as constraints for operation and remediation of running VNF instances.

  • Discovery of hardware platform capabilities exposed by different VIMs.
  • Modeling and persistence of discovered platform capabilities in the AA&I database.
  • Discussion Pages

    Child pages (Children Display)
    alltrue

    HPA JIRA

    Jira Legacy
    serverSystem Jira
    columnskey,summary,assignee,status,resolution
    maximumIssues1000
    jqlQueryfilter = HPA_Filter
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176

    Projects That Enables HPA

    ProjectPTLCommitted for R2MVPHPA EpicsNotes1

    VNFSDK

    (impact)

    StatuscolourGreenYes

    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keyVNFSDK-152

    Creating JIRA stories2

    SDC

    (impact)

    StatuscolourGreenYes

    Pending

    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keySDC-180
    ?

    Michael Lando will add an Epic for HPA

    Conditional commitment, based on 2 Intel resources3SOSeshu Kumar Mudiganti

    No

    VF-C, APP-C

    R3

    Status
    colourRed
    titledelayed
    Status
    titler4

    10Use of VNF hardware platform dependencies as constraints for VNF autoscaling.NoScaling FR

    R3

    Status
    colourRed
    titledelayed
    Status
    titler4

    11Use of VNF hardware platform dependencies as constraints for VNF change management.NoChange Management FR

    R3

    Status
    colourRed
    titledelayed
    Status
    titler4

    12

    Discovery of hardware platform capabilities exposed by different VIMs.

    YesMulti-Cloud

    R2

    Status
    colourGreen
    titleDone

    13

    Modeling and persistence of discovered platform capabilities in the AA&I database.

    YesMulti-Cloud, AAI

    R2

    Status
    colourGreen
    titleDone

    14SRIOV Discovery.NoMulti-Cloud

    R3

    Status
    colourGreen
    titlecommited

    15SRIOV Day 0 Configuration.NoTBD

    R3

    Status
    colourGreen

    Yes

    title

    jiraConditional commitment, based on 2 Intel resources4AAI
    (impact) 

    committed

    serverSystem Jira
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keySO-390
    3DCAE

    Legend:

    StatustitleN/A StatuscolourGreentitleCommiTTED StatuscolourYellowtitleIn Progress StatuscolourRedtitleTBD
    16VF-C/HPA integration.NoVF-C

    R3

    Status
    colourGreen

    Yes

    Pending - Will add an Epic more specific than

    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keyAAI-466

    5Multi-Cloud StatuscolourGreen

    Yes

    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keyMULTICLOUD-157

    6Policy StatuscolourGreenYes

    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keyPOLICY-399

    7OOF StatuscolourGreen

    Depends on availability of HPA requirement (VNFD) and HPA capability (AAI) information.

    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keyOPTFRA-33

    Projects that document HPA guidelines, use cases, requirements & test cases

    Project

    PTL

    Committed for R2

    MVPHPA EpicsNotes1VNFRQTS StatuscolourGreenYes

    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keyVNFRQTS-159

    `Projects that make use of HPA

    Project

    PTL

    Notes1APP-CThere is no direct impact on APP-C, given that all instantiation actions are "outsourced" to the SO/OOF.2VF-CChanges to VF-C will be required in order to incorporate use of HPA into instantiation and operation.

    titlecommitted



    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.

    1. There are no changes to the HPA capability discovery process.
    2. There are no changes to how discovered HPA capabilities are persisted in AAI.
    3. There are no changes to specification of HPA constraint policies used by OOF.
    4. 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 IDTest DescriptionStatus
    101Format and content of the VNFD, as supplied via the CSAR file are unaffected by VNF on-boarding.

    Status
    titleTo be done

    102

    HPA requirements are unaffected by VNF on-boarding.

    Status
    titleTo be done

    103

    On-boarding of VNFs with HPA requirements fails if appropriate ONAP components  (e.g. HPA requirement interpreter plugin) are not found.

    Status
    titleTo be done

    104HPA requirement validation errors result in termination of the VNF on-boarding process.

    Status
    titleTo be done

    VNF Design (SDC)


    Test IDTest DescriptionStatus
    201

    VNFs with TOSCA-encoded VNFDs can be used to build network services.

    Status
    titleTo be done

    202

    VNFD and all of its content, HPA requirements included, remain immutable.

    Status
    titleTo be done

    VNF Distribution (SDC/SO/Policy)

    Test IDTest DescriptionStatus
    301

    Policy and SO components are able to register as SDC distribution clients.

    Status
    titleTo be done

    302VNFD can be distributed through the SDC distribution framework.

    Status
    titleTo be done

    303

    HPA requirement parsing errors result in termination of the VNF distribution process.

    Status
    titleTo be done

    VNF Instantiation (SO/VF-C/OOF)

    Test IDTest DescriptionStatus
    401VNFs with TOSCA-encoded VNFDs can be instantiated using VF-C.

    Status
    titleTo be done

    402VNFs with TOSCA-encoded VNFDs can be instantiated using SO.

    Status
    titleTo be done

    403The same VNF package can be used with all ONAP orchestrators.

    Status
    titleTo be done

    404HPA requirements are consistently interpreted by all orchestrators.

    Status
    titleTo be done

    SR-IOV NIC Support

    Test IDTest DescriptionStatus
    501VNFs including SR-IOV NIC requirements with TOSCA-encoded VNFDs can be instantiated using VF-C.

    Status
    titleTo be done

    502VNFs including SR-IOV NIC requirements with TOSCA-encoded VNFDs can be instantiated using SO.

    Status
    titleTo be done

    HPA Service Assurance (Platform Telemetry)

    Test IDTest DescriptionStatus
    601

    Status
    titleTo be done