NFVI Platform Capability Registry: Difference between revisions

From NFVwiki
No edit summary
(Updated text based on NFVSOL(18)000731r2)
Line 1: Line 1:
This is the ETSI NVS SOL registry for key/value pairs used to represent EPA requirements and settings, as part of NFV VNF descriptors. <blockquote>'''<big>DISCLAIMER: The contents of this WIKI page is under developement and has not yet been reviewed by the ETSI NFV SOL Working Group</big>'''</blockquote>
This is the ETSI registry for key/value pairs used to represent hardware platform capabilities and settings, as part of NFV VNF descriptors (VNFD).  
= Introduction =
Some VNF suppliers make use of the underlying hardware platform capabilities in order to accelerate performance and optimize throughput of their VNF products. In order to ensure proper instantiation and operation of such VNFs, the VNF Descriptor is used to describe VNF-specific  hardware platform capability requirements that will be matched against the capabilities of the underlying hardware infrastructure resources, in order to ensure that appropriate resources are used for instantiation.


= Specifying EPA Capability Requirements using TOSCA-based NFV VNF Descriptors =
This registry is defined to specify capabilities that are generic to all hardware vendors, as well as capabilities that are hardware vendor specific. There are five different categories that can be specified in the VNFD: CPU, memory, storage, network and logical node requirements. They are defined in terms of data model (i.e. TOSCA, YANG) neutral attributes within information elements<ins> </ins>specified in ETSI GS NFV-IFA 011 version 2.5.1 and beyond. The attribute "type" is defined as a map of strings that contains a set of key-value pairs.
Some VNF suppliers make use of the underlying hardware platform capabilities in order to accelerate performance and optimize throughput of their VNF products. In order to ensure proper instantiation and operation of such VNFs, the VNF descriptor (VNFD) is used to describe VNF-specific EPA capability requirements that will be matched against the capabilities of the underlying hardware infrastructure resources, in order to ensure that appropriate resources are used for instantiation.
 
== Specifying EPA requirements ==
There are five different types of EPA capability requirements that can be specified in the VNFdescriptor - CPU, memory, storage, network and NUMA. Each requirement type is specified using a TOSCA hash map containing a list of capabilities and their corresponding desired configuration values. The following table describes where within the VNFD the EPA requirement hash maps are defined and where within the VNFD they are used.  
{| class="wikitable"
{| class="wikitable"
!EPA Requirements
!EPA Requirements
!Attribute Name
!IFA011 Information Element
!Defined in...
!Attribute
! colspan="1" |Used in...
|-
|-
|CPU
|CPU
|vdu_cpu_requirements
|VirtualCpuData
|tosca.datatypes.nfv.VirtualCpu
|vduCpuRequirements
| colspan="1" |tosca.nodes.nfv.VDU.Compute
|-
|-
|Memory
|MEMORY
|vdu_memory_requirements
|VirtualMemoryData
|tosca.datatypes.nfv.VirtualMemory
|vduMemRequirements
| colspan="1" |tosca.nodes.nfv.VDU.Compute
|-
|-
|NIC
|STORAGE
|network_interface_requirements
|BlockStorageData
|tosca.datatypes.nfv.VirtualNetworkInterfaceRequirements
|vduStorageRequirements
| colspan="1" |tosca.nodes.nfv.VduCp
 
tosca.nodes.nfv.VnfExtCp
|-
|-
| colspan="1" |Storage
| colspan="1" |NETWORK
| colspan="1" |vdu_storage requirements
| colspan="1" |VirtualNetworkInterfaceRequirements
| colspan="1" |map
| colspan="1" |networkInterfaceRequirements
| colspan="1" |tosca.nodes.nfv.VDU.VirtualStorage
|-
|-
| colspan="1" |NUMA
| colspan="1" |LOGICAL NODE
| colspan="1" |logical_node_requirements
| colspan="1" |LogicalNodeRequirements
| colspan="1" |tosca.datatypes.nfv.LogicalNodeData
| colspan="1" |logicalNodeRequirementDetail
| colspan="1" |tosca.nodes.nfv.VDU.Compute
|}Each attribute represents a table in the registry, with the entries in each table specifying the hardware platform capabilities. Each entry contains the following information:
|}
 
== EPA Requirement Key/Value Pair Entry Format ==
EPA capability requirements are specified using a set of TOSCA hash maps within the VNFD. Each entry in the hash map fully defines a single EPA capability requirement. Within a given hash map entry, the "key" portion of the entry contains the EPA capability name and the "value" portion contains structured data representing the the attributes of the corresponding configuration value.
 
The "key" portion of each array entry contains a string specifying a particular EPA capability name. The "value" portion of each array entry is a structured field containing information used to interpret the requested capability configuration. The capability values are defined as TOSCA strings, and their content can vary from a single attribute to complex permutations of simple attributes, lists and hash maps. Content and structure of capability values are defined using JSON schemas that can be used to parse the capability value strings in order to determine the desired state of EPA capabilities.
 
All capability value strings contain a set of pre-defined attributes that are used refine the how the requirements should be treated and what configuration value schema should be used for its interpretation. The following table describes that pre-defined attributes and their purpose:
{| class="wikitable"
{| class="wikitable"
!Array Entry
|+
!Values
|Name
|The name of  the capability specified in lower camel case, for example memoryPageSize.
|-
|-
|<key>
|Permitted Value
|A string specifying the name of a given EPA capability.
|One  or more permitted values used to configure the capability specified in lower camel case
|-
|-
|<value>
|Version
|A map of key-value pairs describing the configuration value of a given capability, where the key-value pairs are defined as follows
|The version of the capability specified as a decimal (X.X). There may be multiple  versions supported. The versioning shall begin with 1.0 and be increased every time there is a change to the capability.
|-
|-
|
|Schema
|
|The schema used to validate and configure the associated value.  
{| class="wikitable"
!key
!type
! colspan="1" |value
|-
|schemaVersion
|string
| colspan="1" |A string describing the version the schema to be used for validation and interpretation of the <configuration-value>.
|-
| colspan="1" |schemaSelector
| colspan="1" |string
| colspan="1" |An Identifier for the particular schema to use.
|-
|-
| colspan="1" |hardwarePlatform
|Hardware
| colspan="1" |string
|If the capability is supported on all hardware platforms then this takes a value of "Generic". if not, it will be vendor specific such as Intel or ARM,<ins> </ins>etc.  
| colspan="1" |A string describing what hardware platform associated with a given EPA capability. For vendor-neutral EPA capabilities, a value of "generic" is used.
|-
|-
| colspan="1" |mandatory
|Description
| colspan="1" |string
|A short description of the capability, such as “memory page size.
| colspan="1" |A boolean value expressed in string type specifying whether the requested capability is mandatory for for proper operation of the VNF. The value of "true" indicated that a given EPA capability must be present. The value of "false" indicates that the VNF can function with or without the capability.
|-
| colspan="1" |configurationValue
| colspan="1" |string
| colspan="1" |A string describing the configuration value of a given capability, as defined by the schema.
|}
|-
| colspan="1" |...
| colspan="1" |Structured data representing the EPA capability configuration value-specific attributes. Can vary from a single attribute to complex permutations of simple attributes, lists and hash maps.
|}
|}
The process for creating entries in this registry is subject to a governance process described in (link to governance wiki page).
== The Registry ==


== Supported EPA Capability Requirements ==
The entries in the tables below represent hardware capabilities supported by hardware vendors. When a capability is identified as "Generic" it implies the capability is supported by all hardware vendors. Otherwise the hardware is specified as vendor specific and thus is only supported by hardware provided by that vendor.


=== '''VDU CPU Requirements''' ===
== CPU Requirements – Example entry in the Registry ==
{| class="wikitable"
{| class="wikitable"
! colspan="1" |Capability Name
|'''Name'''
! colspan="1" |Capability Value
|'''Value'''
! colspan="1" |Generic Capability
|'''Version'''
! colspan="1" |Descriptiopn
|'''Schema'''
|'''Hardware'''
|'''Description'''
|-
|-
|cpuModelSpecificationBinding
|cpuModelSpecificationBinding
Line 101: Line 68:


equalOrBetterBinding
equalOrBetterBinding
| colspan="1" |
|1.0
|VDUs may be developed, compiled, optimized or validated on particular CPU models. Some deployments may wish to permit the VDU to be deployed on a platform with the specified CPU only, or with an alternative CPU with the same architecture, instruction set, and if specified, instruction set extensions, or with a CPU of equivalent or greater capability.
|
|-
|Generic
|instructionSetRequirements
|VDUs may be developed, compiled, optimized or validated on particular CPU models. Some deployments may wish to permit the VDU to be deployed on a platform with the specified CPU only, or with an alternative CPU with the same architecture, instruction set, and if specified, instruction set extensions, or with a CPU of equivalent or greater capability.
|aes, sse, avx, cat, cmt, mbm, ddio, smt, rdrand, etc etc
| colspan="1" |
|Long list of instruction set extensions.
|-
|simultaneousMultiThreading
|Enabled
 
disabled
| colspan="1" |
|The use of Simultaneous Multi-Threading HW is an efficient way to increase the compute capacity of a platform. SMT HW threads share some CPU core resources. In some VDU implementations, it may be necessary to very explicitly control the HW thread allocation on a platform. This could be to help ensure locality in data caches or as a mechanism to enhance determinism
|-
|hypervisorConfiguration
|HPET
 
memoryCompaction
 
kernelSamepageMerging
| colspan="1" |
|Long list: High Precision Event Timer configuration, memory compaction, kernel samepage merging, etc.
|-
|computeRas
|pciDetectedAndCorrectedErrors pciDetectedAndUncorrectedErrors
| colspan="1" |
|Reliability, Availability, Serviceability (RAS)
 
Long list of values: pciDetectedAndCorrectedErrors, pciDetectedAndUncorrectedErrors
|-
|cpuModel
|List of model identifiers
| colspan="1" |
|The CPU model for which the VDU has been developed, compiled for, optimized on,  validated on or preferred for some reason.
|-
| colspan="1" |directIoAccessToCache
| colspan="1" |Values – TBD
| colspan="1" |
| colspan="1" |Descriptions related to cache functions – TBD
|-
|accelerator
|Values – TBD
| colspan="1" |
|Descriptions related to accelerator functions – TBD
|-
|measuredLaunchEnvironment
|Values – TBD
| colspan="1" |
|Descriptions related to boot environment functions – TBD
|-
|secureEnclave
|Values – TBD
| colspan="1" |
|Descriptions related to secure region functions – TBD
|-
| colspan="1" |numVirtualCpu
| colspan="1" |1-N
| colspan="1" |
| colspan="1" |Number of virtual CPUs
|-
|virtualCpuClock
|0-N
| colspan="1" |
|Minimum virtual CPU clock rate (e.g. in
 
MHz). The cardinality can be 0 during the allocation request, if no particular value is requested.
|-
|logicalCpuPinningPolicy
|dedicated
 
shared
| colspan="1" |
|Determines if CPUs from the host platform should be committed to the VDU or shared between VDUs.
|-
|logicalCpuThreadPinningPolicy
|require
 
isolate
 
prefer
| colspan="1" |
|Determines the manner in which CPU (HW) threads are allocated to VDUs. Require means CPU (HW) thread siblings should be allocated
 
Isolate means allocate CPU (HW) threads from different execution units.
 
Prefer means ideally allocate CPU HW threads from the same physical execution units but if not available, continue with allocation.
|}
|}


=== '''VDU Memory Requirements''' ===
== Memory Requirements – Example entry in the Registry ==
{| class="wikitable"
{| class="wikitable"
! colspan="1" |Capability Name
|'''Name'''
! colspan="1" |Capability Value
|'''Value'''
! colspan="1" |Descriptiopn
|'''Version'''
|-
|'''Schema'''
| colspan="1" |
|'''Hardware'''
| colspan="1" |
|'''Description'''
| colspan="1" |
|-
|-
|memoryPageSize
|memoryPageSize
|ANY, 4KB, 2MB, 1GB
|ANY, 4KB, 2MB, 1GB
|1.0
|
|Generic
|Memory page size
|Memory page size
|-
|numberOfPages
|0..N
|Number of pages of this specific page size.
Note, The size of memory requested in all instances of the vduMemRequirements must be less than or equal to the virtualMemSize attribute of the virtualMemoryData information element.
|-
|memoryAllocationPolicy
|strictLocalAffinity
preferredLocalAffinity
|Strict Local (to node) Affinity or Preferred local (to node) affinity
|-
|memoryType
|
|Type of memory
|-
|memorySpeed
|
|Agreed unit of memory speed
|-
|memoryRas
|ECC, SDDC, thermalThrottling, demandAndPatrolScrubbing
|Long list of memory technologies
|-
|memoryBandwidth
|0..N
|Agreed unit of memory bandwidth where 0 is unspecified.
|-
|processorCacheAllocationType
|Values – TBD
|Agreed type of processor cache allocation
|-
|processorCacheAllocationSize
|0..N
|Agreed unit of processor cach
|}
|}


=== '''VDU Storage Requirements''' ===
== Storage Requirements – Example entry in the Registry ==
{| class="wikitable"
{| class="wikitable"
! colspan="1" |Capability Name
|'''Name'''
! colspan="1" |Capability Value
|'''Value'''
! colspan="1" |Descriptiopn
|'''Version'''
|'''Schema'''
|'''Hardware'''
|'''Description'''
|-
|-
|storageIops
|storageLops
|0..N
|0..N
|Required storage characteristics (e.g. speed), including Key Quality Indicators (KQIs) for performance and reliability/availability
|1.0
|
|Generic
|Required storage characteristics (e.g. speed), including Key Quality Indicators (KQIs) for performance and reliability/availability
|-
|-
|storageResilencyMechanism
|storageResilencyMechanism
Line 255: Line 111:


tripleReplication
tripleReplication
|Erasure code based back-end, triple replication based back-end for ensuring data resiliency.
|1.0
|
|Generic
|Erasure code based back-end, triple replication based back-end for ensuring data resiliency.
|}
|}


=== '''Logical Node Compute Requirements''' ===
== Network Requirements – Example entry in the Registry ==
{| class="wikitable"
{| class="wikitable"
! colspan="1" |Capability Name
|'''Name'''
! colspan="1" |Capability Value
|'''Value'''
! colspan="1" |Descriptiopn
|'''Version'''
|'''Schema'''
|'''Hardware'''
|'''Description'''
|-
|nicFeature
|LSO, LRO, RSS, RDMA
|1.0
|
|Generic
|Long list of NIC related items such as  LSO, LRO, RSS, RDMA, etc
|}
 
== Logical Node Requirement Detail ==
The logical node requirements are broken-out into three types: Compute, Memory, and I/O.
 
=== Logical Node Compute Requirements – Example entry in the Registry ===
{| class="wikitable"
|'''Name'''
|'''Value'''
|'''Version'''
|'''Schema'''
|'''Hardware'''
|'''Description'''
|-
|-
|numberCpu
|numberCpu
|0..N
|0..N
|Number of CPU cores for this logical node. The cumulative number of CPU requests per node must equal the VDU level numVirtualCpu requirement.
|1.0
|
|Generic
|Number of CPU cores for this logical node. The cumulative number of CPU requests per node must equal the VDU level numVirtualCpu requirement.
|}
|}


=== '''Logical Node Memory Requirements''' ===
=== Logical Node Memory Requirements – Example entry in the Registry ===
{| class="wikitable"
{| class="wikitable"
! colspan="1" |Capability Name
|'''Name'''
! colspan="1" |Capability Value
|'''Value'''
! colspan="1" |Descriptiopn
|'''Version'''
|'''Schema'''
|'''Hardware'''
|'''Description'''
|-
|-
|localNumaMemorySize
|localNumaMemorySize
|0..N
|0..N
|The amount of memory that needs to be collocated with this specific logical (NUMA) node.
|1.0
|
|Generic
|The amount of memory that needs to be collocated with this specific logical (NUMA) node.
|}
|}


=== '''Logical Node i/O Requirements''' ===
=== Logical Node I/O Requirements – Example entry in the Registry ===
{| class="wikitable"
{| class="wikitable"
! colspan="1" |Capability Name
|'''Name'''
! colspan="1" |Capability Value
|'''Value'''
! colspan="1" |Descriptiopn
|'''Version'''
|'''Schema'''
|'''Hardware'''
|'''Description'''
|-
|-
|pciVendorId
|pciVendorId
|
|
|1.0
|
|Generic
|PCI-SIG vendor ID for the device
|PCI-SIG vendor ID for the device
|}
= '''Mappings to Specific Data Models''' =
== Mapping to ETSI NFV-SOL 001 data model (TOSCA<ins>)</ins> ==
=== Mapping Table ===
For each of the five platform capability categories - CPU, memory, storage, network and logical node - the associated attribute defined in ETSI GS NFV-IFA 011 is mapped to a property of type “map of string” of a TOSCA data type specified in ETSI NFV-SOL<ins> </ins>001. The following table describes for each attribute defined in ETSI GS NFV-IFA 011 and representing one of these five categories, the corresponding TOSCA property, the TOSCA data type where this property is used and the TOSCA node type where this data type is used, in accordance with ETSI GS NFV-SOL<ins> </ins>001 v2.5.1 and beyond.
{| class="wikitable"
|'''Category'''
|'''IFA011 Attribute'''
|'''As Property'''
|'''Data Type Defined in SOL001'''
|'''Used in SOL001'''
|-
|-
|pciDeviceId
|CPU
|
|vduCpuRequirements
|PCI-SIG device ID for the device
|vdu_cpu_requirements
|<ins>tosca.datatypes.nfv.VirtualCpu</ins>
|tosca.nodes.nfv.Vdu.Compute
|-
|-
|pciNumDevices
|Memory
|
|vduMemRequirements
|Number of PCI devices required.
|vdu_mem_requirements
|<ins>tosca.datatypes.nfv.VirtualMemory</ins>
|tosca.nodes.nfv.Vdu.Compute
|-
|-
|pciAddress
|Network
|
|networkInterfaceRequirements
|Geographic location of the PCI device via the standard PCI-SIG addressing model of Domain:Bus:device:function
|network_interface_requirements
|<ins>tosca.datatypes.nfv.VirtualNetworkInterfaceRequirements</ins>
|tosca.nodes.nfv.VduCp
 
tosca.nodes.nfv.VnfExtCp
|-
|-
|pciDeviceLocalToNumaNode
|Storage
|required
|vduStorageRequirements
|vdu_storage_requirements
|<ins>tosca.datatypes.nfv.VirtualBlockStorageData</ins>
|tosca.nodes.nfv.Vdu.VirtualBlockStorage


notRequired
<ins> </ins>
|Determines if I/O device affinity is required.
|-
|Logical Node
|logicalNodeRequirementDetail
|logical_node_requirements
|<ins>tosca.datatypes.nfv.LogicalNodeData</ins>
|tosca.nodes.nfv.Vdu.Compute
|}
|}


=== '''Network Interface Requirements''' ===
=== Key/Value Pair Entry Format ===
Each entry in the hash maps defined above fully defines a single hardware platform capability. Within a given hash map entry, the "key" portion of the entry contains the capability name (as defined in the registry) and the "value" portion contains structured data representing the attributes of the corresponding configuration value.
 
The "key" portion of each array entry contains a string specifying a particular capability name. The "value" portion of each array entry is a structured field containing information used to interpret the requested capability configuration. The capability values are defined as TOSCA strings, and their content can vary from a single attribute to complex permutations of simple attributes, lists and hash maps. Content and structure of capability values are defined using JSON schemas that can be used to parse the capability value strings in order to determine the desired state of platform capabilities.
 
All capability value strings contain a set of pre-defined attributes that are used refine the how the requirements should be treated and what configuration value schema should be used for its interpretation. The following table describes that pre-defined attributes and their purpose:
{| class="wikitable"
|'''Array Entry'''
|'''Values'''
|-
|<key>
|A string specifying the name of a given  hardware platform capability as defined in the "name" column of a  given registry table.
|-
|<value>
|A map of key-value pairs describing the  configuration value of a given capability, where the key-value pairs are  defined as follows
|-
|
|
{| class="wikitable"
{| class="wikitable"
! colspan="1" |Capability Name
|'''key'''
! colspan="1" |Capability Value
|'''type'''
! colspan="1" |Description
|'''value'''
|-
|-
|nicFeature
|schemaVersion
|LSO, LRO, RSS, RDMA
|string
|Long list of NIC related items such as LSO, LRO, RSS, RDMA, etc.
|A string describing the version the    schema to be used for validation and interpretation of the    <configuration-value>. This is taken from the "version"    column of a given registry table.
|-
|-
|dataProcessingAccelerationLibrary
|schemaSelector
|Dpdk
|string
|Name of the data processing acceleration library required. Orchestration can match any NIC that is known to be compatible with the specified library.
|An Identifier for the particular schema    to use. This is taken from the "schema" column of a given    registry table.
|-
|-
| colspan="1" |dataProcessingAccelerationLibraryVersion
|hardwarePlatform
| colspan="1" |Version
|string
| colspan="1" |Version of the data processing acceleration library required. Orchestration can match any NIC that is known to be compatible with the specified library.
|A string describing what hardware    platform associated with a given capability. For vendor-neutral    capabilities, a value of "generic" is used, otherwise a specific    vendor (i.e. Intel, ARM, etc) is used. This is taken from the   "hardware" column of a given registry table.
|-
|-
|interfaceType
|mandatory
|Virtio, PCI-Passthrough, SR-IOV, E1000, RTL8139, PCNET
|string
|Network interface type
|A boolean value expressed in string    type specifying whether the requested capability is mandatory for proper    operation of the VNF. The value of "true" indicates that a given    hardware platform capability must be present. The value of    "false" indicates that the VNF can function with or without the    capability. Note: this is not taken from the registry and is defined on a    per NFV vendor basis.
|-
|-
|vendorSpecificNicFeature
|configurationValue
|TBA
|string
|List of vendor specific NIC related items.
|A string describing the configuration    value of a given capability, as defined by the schema. This shall be among    the permitted values specified in the "value" column of a given    registry table.
|}
|-
|...
|Structured data representing the hardware  platform capability configuration value-specific attributes can vary from a  single attribute to complex permutations of simple attributes, lists and hash  maps.
|}
|}


WORK IN PROGRESS
=== <ins> </ins> ===
 
=== Examples ===
 
==== CPU Hardware Capabilities ====
Usage of vdu_cpu_requirements key-value pairs as specified in tosca.nodes.nfv.Vdu.Compute. Note in this example that there is one  hardware capabilities being defined: simulatenousMultiThreading. This is  the “key”. The  associated “value” is composed of a specification of: schemaVersion, schemaSelector, hardwarePlatform, mandatory, and configurationValue as a complex value.
 
<some entity>
 
...
 
        properties:
 
                  vdu_cpu_requirements:
 
                       simultaneousMultiThreading:
 
                           schemaVersion: 0
 
                           schemaSelector: " "
 
                           hardwarePlatform: "<ins>G</ins><s>g</s>eneric"
 
                           mandatory: true
 
                           configurationValue: "enabled"
 
...
 
==== Memory Hardware Capabilities ====
Usage of vdu_mem_requirements key-value pairs as specified in tosca.nodes.nfv.Vdu.Compute. Note in this example that there are two hardware capabilities being defined: memoryPageSize and numberOfPages. These are the “keys”. Each associated “value” is composed of a specification of: schemaVersion, schemaSelector, hardwarePlatform, mandatory, and configurationValue as a complex value.
 
<some entity>
 
...
 
         properties:
 
                  vdu_mem_requirements:
 
                        memoryPageSize:
 
                            schemaVersion: 0
 
                            schemaSelector: " "
 
                            hardwarePlatform: "Generic"
 
                            mandatory: true
 
                            configurationValue: "2 MB"
 
                        numberOfPages:
 
                            schemaVersion: 0
 
                            schemaSelector: " "
 
                            hardwarePlatform: "Generic"
 
                            mandatory: true
 
                            configurationValue: "1024"
 
...
 
...
 
==== Storage Hardware Capabilities ====
Usage of vdu_storage_requirements key-value pairs as specified in tosca.nodes.nfv.Vdu.VirtualBlockStorage. Note in this example that there is one hardware capability being defined: storageResiliencyMechanism. This is the “key”. The associated “value” is composed of a specification of: schemaVersion, schemaSelector, hardwarePlatform, mandatory, and configurationValue as a complex value.
 
<some entity>
 
...
 
         properties:
 
                  vdu_storage_requirements:
 
                        storageResiliencyMechanism:
 
                            schemaVersion: 0
 
                            schemaSelector: " "
 
                            hardwarePlatform: "Intel"
 
                            mandatory: true
 
                            configurationValue: "tripleReplication"
 
...
 
...
 
==== Network Hardware Capabilities ====
Usage of network_interface_requirements key-value pairs as specified in tosca.nodes.nfv.VduCp or tosca.nodes.nfv.VnfExtCp. Note in this example that there is one hardware capability being defined: dataProcessingAccelerationLibrary.  This is the “key”. The associated “value” is composed of a specification of: schemaVersion, schemaSelector, hardwarePlatform, mandatory, and configurationValue as a complex value.
 
<some entity>
 
...
 
         properties:
 
                  network_interface_requirements:
 
                        dataProcessingAccelerationLibrary:
 
                            schemaVersion: 0
 
                            schemaSelector: " "
 
                            hardwarePlatform: "<ins>G</ins><s>g</s>eneric"
 
                            mandatory: true
 
                            configurationValue: "dpdk"
 
...
 
...
 
==== Logical Node Hardware Capabilities ====
Usage of logical_node_requirements key-value pairs pairs as specified in tosca.nodes.nfv.Vdu.Compute. Note in this example that there are three hardware capabilities being defined: numberCpu, localNumaMemorySize, and pciDeviceLocalToNumaNode. These are the “keys”. Each associated “value” is composed of a specification of: schemaVersion, schemaSelector, hardwarePlatform, mandatory, and configurationValue as a complex value.
 
<some entity>
 
...
 
         properties:
 
                  logical_node_requirements:
 
                        numberCpu:
 
                            schemaVersion: 0
 
                            schemaSelector: " "
 
                            hardwarePlatform: "Intel"
 
                            mandatory: true
 
                            configurationValue: "1"
 
                        localNumaMemorySize:
 
                            schemaVersion: 0
 
                            schemaSelector: " "
 
                            hardwarePlatform: "Intel"
 
                            mandatory: true
 
                            configurationValue: "4096"
 
                         pciDeviceLocalToNumaNode:
 
                            schemaVersion: 0
 
                            schemaSelector: " "
 
                            hardwarePlatform: "Intel"
 
                            mandatory: true
 
                            configurationValue: "required"
 
...


...


To register VIM connection information, the following template must be filled and submitted to NFVsupport@etsi.org: [https://nfvwiki.etsi.org/images/tobeprovided template]
== Mapping to ETSI NFV-SOL 006 data model (YANG) ==
To be defined

Revision as of 10:03, 30 April 2019

This is the ETSI registry for key/value pairs used to represent hardware platform capabilities and settings, as part of NFV VNF descriptors (VNFD).

Introduction

Some VNF suppliers make use of the underlying hardware platform capabilities in order to accelerate performance and optimize throughput of their VNF products. In order to ensure proper instantiation and operation of such VNFs, the VNF Descriptor is used to describe VNF-specific  hardware platform capability requirements that will be matched against the capabilities of the underlying hardware infrastructure resources, in order to ensure that appropriate resources are used for instantiation.

This registry is defined to specify capabilities that are generic to all hardware vendors, as well as capabilities that are hardware vendor specific. There are five different categories that can be specified in the VNFD: CPU, memory, storage, network and logical node requirements. They are defined in terms of data model (i.e. TOSCA, YANG) neutral attributes within information elements specified in ETSI GS NFV-IFA 011 version 2.5.1 and beyond. The attribute "type" is defined as a map of strings that contains a set of key-value pairs.

EPA Requirements IFA011 Information Element Attribute
CPU VirtualCpuData vduCpuRequirements
MEMORY VirtualMemoryData vduMemRequirements
STORAGE BlockStorageData vduStorageRequirements
NETWORK VirtualNetworkInterfaceRequirements networkInterfaceRequirements
LOGICAL NODE LogicalNodeRequirements logicalNodeRequirementDetail

Each attribute represents a table in the registry, with the entries in each table specifying the hardware platform capabilities. Each entry contains the following information:

Name The name of the capability specified in lower camel case, for example memoryPageSize.
Permitted Value One or more permitted values used to configure the capability specified in lower camel case
Version The version of the capability specified as a decimal (X.X). There may be multiple versions supported. The versioning shall begin with 1.0 and be increased every time there is a change to the capability.
Schema The schema used to validate and configure the associated value.
Hardware If the capability is supported on all hardware platforms then this takes a value of "Generic". if not, it will be vendor specific such as Intel or ARM, etc.  
Description A short description of the capability, such as “memory page size.

The process for creating entries in this registry is subject to a governance process described in (link to governance wiki page).

The Registry

The entries in the tables below represent hardware capabilities supported by hardware vendors. When a capability is identified as "Generic" it implies the capability is supported by all hardware vendors. Otherwise the hardware is specified as vendor specific and thus is only supported by hardware provided by that vendor.

CPU Requirements – Example entry in the Registry

Name Value Version Schema Hardware Description
cpuModelSpecificationBinding strictBinding

equalOrBetterBinding

1.0 Generic VDUs may be developed, compiled, optimized or validated on particular CPU models. Some deployments may wish to permit the VDU to be deployed on a platform with the specified CPU only, or with an alternative CPU with the same architecture, instruction set, and if specified, instruction set extensions, or with a CPU of equivalent or greater capability.

Memory Requirements – Example entry in the Registry

Name Value Version Schema Hardware Description
memoryPageSize ANY, 4KB, 2MB, 1GB 1.0 Generic Memory page size

Storage Requirements – Example entry in the Registry

Name Value Version Schema Hardware Description
storageLops 0..N 1.0 Generic Required storage characteristics (e.g. speed), including Key Quality Indicators (KQIs) for performance and reliability/availability
storageResilencyMechanism Erasure

tripleReplication

1.0 Generic Erasure code based back-end, triple replication based back-end for ensuring data resiliency.

Network Requirements – Example entry in the Registry

Name Value Version Schema Hardware Description
nicFeature LSO, LRO, RSS, RDMA 1.0 Generic Long list of NIC related items such as LSO, LRO, RSS, RDMA, etc

Logical Node Requirement Detail

The logical node requirements are broken-out into three types: Compute, Memory, and I/O.

Logical Node Compute Requirements – Example entry in the Registry

Name Value Version Schema Hardware Description
numberCpu 0..N 1.0 Generic Number of CPU cores for this logical node. The cumulative number of CPU requests per node must equal the VDU level numVirtualCpu requirement.

Logical Node Memory Requirements – Example entry in the Registry

Name Value Version Schema Hardware Description
localNumaMemorySize 0..N 1.0 Generic The amount of memory that needs to be collocated with this specific logical (NUMA) node.

Logical Node I/O Requirements – Example entry in the Registry

Name Value Version Schema Hardware Description
pciVendorId 1.0 Generic PCI-SIG vendor ID for the device

Mappings to Specific Data Models

Mapping to ETSI NFV-SOL 001 data model (TOSCA)

Mapping Table

For each of the five platform capability categories - CPU, memory, storage, network and logical node - the associated attribute defined in ETSI GS NFV-IFA 011 is mapped to a property of type “map of string” of a TOSCA data type specified in ETSI NFV-SOL 001. The following table describes for each attribute defined in ETSI GS NFV-IFA 011 and representing one of these five categories, the corresponding TOSCA property, the TOSCA data type where this property is used and the TOSCA node type where this data type is used, in accordance with ETSI GS NFV-SOL 001 v2.5.1 and beyond.

Category IFA011 Attribute As Property Data Type Defined in SOL001 Used in SOL001
CPU vduCpuRequirements vdu_cpu_requirements tosca.datatypes.nfv.VirtualCpu tosca.nodes.nfv.Vdu.Compute
Memory vduMemRequirements vdu_mem_requirements tosca.datatypes.nfv.VirtualMemory tosca.nodes.nfv.Vdu.Compute
Network networkInterfaceRequirements network_interface_requirements tosca.datatypes.nfv.VirtualNetworkInterfaceRequirements tosca.nodes.nfv.VduCp

tosca.nodes.nfv.VnfExtCp

Storage vduStorageRequirements vdu_storage_requirements tosca.datatypes.nfv.VirtualBlockStorageData tosca.nodes.nfv.Vdu.VirtualBlockStorage

Logical Node logicalNodeRequirementDetail logical_node_requirements tosca.datatypes.nfv.LogicalNodeData tosca.nodes.nfv.Vdu.Compute

Key/Value Pair Entry Format

Each entry in the hash maps defined above fully defines a single hardware platform capability. Within a given hash map entry, the "key" portion of the entry contains the capability name (as defined in the registry) and the "value" portion contains structured data representing the attributes of the corresponding configuration value.

The "key" portion of each array entry contains a string specifying a particular capability name. The "value" portion of each array entry is a structured field containing information used to interpret the requested capability configuration. The capability values are defined as TOSCA strings, and their content can vary from a single attribute to complex permutations of simple attributes, lists and hash maps. Content and structure of capability values are defined using JSON schemas that can be used to parse the capability value strings in order to determine the desired state of platform capabilities.

All capability value strings contain a set of pre-defined attributes that are used refine the how the requirements should be treated and what configuration value schema should be used for its interpretation. The following table describes that pre-defined attributes and their purpose:

Array Entry Values
<key> A string specifying the name of a given hardware platform capability as defined in the "name" column of a given registry table.
<value> A map of key-value pairs describing the configuration value of a given capability, where the key-value pairs are defined as follows
key type value
schemaVersion string A string describing the version the schema to be used for validation and interpretation of the <configuration-value>. This is taken from the "version" column of a given registry table.
schemaSelector string An Identifier for the particular schema to use. This is taken from the "schema" column of a given registry table.
hardwarePlatform string A string describing what hardware platform associated with a given capability. For vendor-neutral capabilities, a value of "generic" is used, otherwise a specific vendor (i.e. Intel, ARM, etc) is used. This is taken from the "hardware" column of a given registry table.
mandatory string A boolean value expressed in string type specifying whether the requested capability is mandatory for proper operation of the VNF. The value of "true" indicates that a given hardware platform capability must be present. The value of "false" indicates that the VNF can function with or without the capability. Note: this is not taken from the registry and is defined on a per NFV vendor basis.
configurationValue string A string describing the configuration value of a given capability, as defined by the schema. This shall be among the permitted values specified in the "value" column of a given registry table.
... Structured data representing the hardware platform capability configuration value-specific attributes can vary from a single attribute to complex permutations of simple attributes, lists and hash maps.

Examples

CPU Hardware Capabilities

Usage of vdu_cpu_requirements key-value pairs as specified in tosca.nodes.nfv.Vdu.Compute. Note in this example that there is one  hardware capabilities being defined: simulatenousMultiThreading. This is  the “key”. The  associated “value” is composed of a specification of: schemaVersion, schemaSelector, hardwarePlatform, mandatory, and configurationValue as a complex value.

<some entity>

...

        properties:

                  vdu_cpu_requirements:

                       simultaneousMultiThreading:

                           schemaVersion: 0

                           schemaSelector: " "

                           hardwarePlatform: "Ggeneric"

                           mandatory: true

                           configurationValue: "enabled"

...

Memory Hardware Capabilities

Usage of vdu_mem_requirements key-value pairs as specified in tosca.nodes.nfv.Vdu.Compute. Note in this example that there are two hardware capabilities being defined: memoryPageSize and numberOfPages. These are the “keys”. Each associated “value” is composed of a specification of: schemaVersion, schemaSelector, hardwarePlatform, mandatory, and configurationValue as a complex value.

<some entity>

...

         properties:

                  vdu_mem_requirements:

                        memoryPageSize:

                            schemaVersion: 0

                            schemaSelector: " "

                            hardwarePlatform: "Generic"

                            mandatory: true

                            configurationValue: "2 MB"

                        numberOfPages:

                            schemaVersion: 0

                            schemaSelector: " "

                            hardwarePlatform: "Generic"

                            mandatory: true

                            configurationValue: "1024"

...

...

Storage Hardware Capabilities

Usage of vdu_storage_requirements key-value pairs as specified in tosca.nodes.nfv.Vdu.VirtualBlockStorage. Note in this example that there is one hardware capability being defined: storageResiliencyMechanism. This is the “key”. The associated “value” is composed of a specification of: schemaVersion, schemaSelector, hardwarePlatform, mandatory, and configurationValue as a complex value.

<some entity>

...

         properties:

                  vdu_storage_requirements:

                        storageResiliencyMechanism:

                            schemaVersion: 0

                            schemaSelector: " "

                            hardwarePlatform: "Intel"

                            mandatory: true

                            configurationValue: "tripleReplication"

...

...

Network Hardware Capabilities

Usage of network_interface_requirements key-value pairs as specified in tosca.nodes.nfv.VduCp or tosca.nodes.nfv.VnfExtCp. Note in this example that there is one hardware capability being defined: dataProcessingAccelerationLibrary.  This is the “key”. The associated “value” is composed of a specification of: schemaVersion, schemaSelector, hardwarePlatform, mandatory, and configurationValue as a complex value.

<some entity>

...

         properties:

                  network_interface_requirements:

                        dataProcessingAccelerationLibrary:

                            schemaVersion: 0

                            schemaSelector: " "

                            hardwarePlatform: "Ggeneric"

                            mandatory: true

                            configurationValue: "dpdk"

...

...

Logical Node Hardware Capabilities

Usage of logical_node_requirements key-value pairs pairs as specified in tosca.nodes.nfv.Vdu.Compute. Note in this example that there are three hardware capabilities being defined: numberCpu, localNumaMemorySize, and pciDeviceLocalToNumaNode. These are the “keys”. Each associated “value” is composed of a specification of: schemaVersion, schemaSelector, hardwarePlatform, mandatory, and configurationValue as a complex value.

<some entity>

...

         properties:

                  logical_node_requirements:

                        numberCpu:

                            schemaVersion: 0

                            schemaSelector: " "

                            hardwarePlatform: "Intel"

                            mandatory: true

                            configurationValue: "1"

                        localNumaMemorySize:

                            schemaVersion: 0

                            schemaSelector: " "

                            hardwarePlatform: "Intel"

                            mandatory: true

                            configurationValue: "4096"

                         pciDeviceLocalToNumaNode:

                            schemaVersion: 0

                            schemaSelector: " "

                            hardwarePlatform: "Intel"

                            mandatory: true

                            configurationValue: "required"

...

...

Mapping to ETSI NFV-SOL 006 data model (YANG)

To be defined

Retrieved from "https://nfvwiki.etsi.org/index.php?title=NFVI_Platform_Capability_Registry&oldid=3514"