Hardware Platform Capability Requirements

Hardware platform capabiity requirements describe VNF component-specific dependencies on the underlying hardware platform capabilities. Capability requirements are specified as part of the VNF descriptor (VNFD) templates, created during VNF packaging and containing all information needed for initial instantiation and subsequent operation of a given VNF. Capability requirements are expressed as arrays of tuples, where each tuple fully defines a single HPA requirement. 

Each requirement tuple has the following format:

(<version-spec>, <hardware-architecture>, <capability-name>, <capability-value>, <need-level>)

where the tuple elements are defined as follows:

<version>
stringThe tuple schema version
<hardware-architecture>
stringThe hardware platform architecture identifier associated with a given capability. A value of "*" indicated a normative capability applicable to all hardware platforms.
<capability-name>
stringThe capability name.
<capability-value>
stringThe capability value. May be a single value.
<requirement-level>
enumIndicates whether a given capability is mandatory or optional. Has two values - "mandatory" or "optional"


Hardware Platform Capabilities

Hardware platform capabilities describe the underlying compute, storage and network hardware platform capabilities. Platform capabilities are obtained from each on-boarded VIM and are persisted as part of the AAI inventory database.  Platform capabilities are expressed as arrays of tuples, where each tuple fully defines a single capability. 

Each requirement tuple has the following format:

(<version-spec>, <hardware-architecture>, <capability-name>, <capability-value>)

where the tuple elements are defined as follows:

<version>
stringThe tuple schema version.
<hardware-architecture>
stringThe hardware platform architecture identifier associated with a given capability. A value of "*" indicated a normative capability applicable to all hardware platforms.
<capability-name>
stringThe capability name.
<capability-value>
stringThe capability value.


Requirement/Capability Matchmaking

During network service and VNF instantiation, required capabilities, specified in the VNFD, are matched against the capabilities of available compute resources. If all "mandatory" capabilities have been matched, the instantiation continues. If one or more mandatory capabilities have not been matched, the instantiation fails.

NOTE - The names of required and available capabilities are the same. The values of required capabilities express a subset of the available capability values.


  • No labels

4 Comments

  1. Adolfo Perez-Duran

    Alexander Vul While I fully support the use of tuples (i.e. multidimensional data points) because it offers computational conveniences, it would present challenges to some applications that rely on the Key-Value pair paradigm. A compromise solution, IMHO, is to flatten the tuples and preserve the information content by adding a basic namespace to the keys. Here's a couple of options to ponder:


    HPA Tuple ElementHPA Key (Option 1)HPA Key (Option 2)
    <version>hpa.schema.versionHPA_SCHEMA_VERSION
    <hardware-architecture>hpa.hardware.architectureHPA_HARDWARE_ARCHITECTURE
    <capability-name>hpa.<capability-name>**HPA_<CAPABILITY NAME>**
    <requirement-level>
    		hpa.requirement-levelHPA_REQUIREMENT_LEVEL

    **Use a KV pair per HPA capability data point. 

    Thoughts?

  2. Viswanath Kumar Skand Priya

    Hello,

    I have a query. Does the feasiblity / availablity check will happen based on discovered values, discovered during initial registration of VIM or based on real-time availablity ?

    i.e A&AI tracks available resources base don previous network instantiations, scale-up / down etc ?

    BR,

    Viswa

  3. Alexander Vul

    This is more of an OFF question...  Shankaranarayanan Puzhavakath Narayanan, Sastry Isukapalli, Sarat Puthenpura - you want to take a stab at it?


  4. Shankaranarayanan Puzhavakath Narayanan

    Viswanath Kumar Skand Priya, The capabilities are expected to be discovered by MultiCloud during the registration, which in turn would be associated with the respective VIMs and tracked in A&AI. The resource availability being dynamic, is a little bit more challenging to be tracked in AAI. The current thinking in R2 is that the availability would be exported directly by MultiCloud through a push/pull mechanism to OOF for consumption. That way, OOF can filter candidate VIMs based on the capabilities first (which are static), and then subsequently apply the feasibility/availability filter. This would alleviate the volume of dynamic capacity information that needs to be ingested during homing.