NFVI Platform Capability Registry: Difference between revisions
No edit summary |
No edit summary |
||
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. | This is the ETSI NVS SOL registry for key/value pairs used to represent EPA requirements and settings, as part of NFV VNF descriptors. | ||
= Specifying EPA Capability Requirements using TOSCA-based NFV VNF Descriptors = | |||
= Specifying EPA | |||
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. | 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. | ||
Revision as of 07:46, 4 October 2018
This is the ETSI NVS SOL registry for key/value pairs used to represent EPA requirements and settings, as part of NFV VNF descriptors.
Specifying EPA Capability Requirements using TOSCA-based NFV VNF Descriptors
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.
EPA Requirements | Attribute Name | Defined in... | Used in... |
---|---|---|---|
CPU | vdu_cpu_requirements | tosca.datatypes.nfv.VirtualCpu | tosca.nodes.nfv.VDU.Compute |
Memory | vdu_memory_requirements | tosca.datatypes.nfv.VirtualMemory | tosca.nodes.nfv.VDU.Compute |
NIC | network_interface_requirements | tosca.datatypes.nfv.VirtualNetworkInterfaceRequirements | tosca.nodes.nfv.VduCp
tosca.nodes.nfv.VnfExtCp |
Storage | vdu_storage requirements | map | tosca.nodes.nfv.VDU.VirtualStorage |
NUMA | logical_node_requirements | tosca.datatypes.nfv.LogicalNodeData | tosca.nodes.nfv.VDU.Compute |
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:
Array Entry | Values | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
<key> | A string specifying the name of a given EPA capability. | ||||||||||||||||||
<value> | A map of key-value pairs describing the configuration value of a given capability, where the key-value pairs are defined as follows | ||||||||||||||||||
| |||||||||||||||||||
... | 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. |
Supported EPA Capability Requirements
VDU CPU Requirements
Capability Name | Capability Value | Generic Capability | Descriptiopn |
---|---|---|---|
cpuModelSpecificationBinding | strictBinding
equalOrBetterBinding |
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. | |
instructionSetRequirements | aes, sse, avx, cat, cmt, mbm, ddio, smt, rdrand, etc etc | Long list of instruction set extensions. | |
simultaneousMultiThreading | Enabled
disabled |
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 |
Long list: High Precision Event Timer configuration, memory compaction, kernel samepage merging, etc. | |
computeRas | pciDetectedAndCorrectedErrors pciDetectedAndUncorrectedErrors | Reliability, Availability, Serviceability (RAS)
Long list of values: pciDetectedAndCorrectedErrors, pciDetectedAndUncorrectedErrors | |
cpuModel | List of model identifiers | The CPU model for which the VDU has been developed, compiled for, optimized on, validated on or preferred for some reason. | |
directIoAccessToCache | Values – TBD | Descriptions related to cache functions – TBD | |
accelerator | Values – TBD | Descriptions related to accelerator functions – TBD | |
measuredLaunchEnvironment | Values – TBD | Descriptions related to boot environment functions – TBD | |
secureEnclave | Values – TBD | Descriptions related to secure region functions – TBD | |
numVirtualCpu | 1-N | Number of virtual CPUs | |
virtualCpuClock | 0-N | 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 |
Determines if CPUs from the host platform should be committed to the VDU or shared between VDUs. | |
logicalCpuThreadPinningPolicy | require
isolate prefer |
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
Capability Name | Capability Value | Descriptiopn |
---|---|---|
memoryPageSize | ANY, 4KB, 2MB, 1GB | 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
Capability Name | Capability Value | Descriptiopn |
---|---|---|
storageIops | 0..N | Required storage characteristics (e.g. speed), including Key Quality Indicators (KQIs) for performance and reliability/availability |
storageResilencyMechanism | Erasure
tripleReplication |
Erasure code based back-end, triple replication based back-end for ensuring data resiliency. |
Logical Node Compute Requirements
Capability Name | Capability Value | Descriptiopn |
---|---|---|
numberCpu | 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. |
Logical Node Memory Requirements
Capability Name | Capability Value | Descriptiopn |
---|---|---|
localNumaMemorySize | 0..N | The amount of memory that needs to be collocated with this specific logical (NUMA) node. |
Logical Node i/O Requirements
Capability Name | Capability Value | Descriptiopn |
---|---|---|
pciVendorId | PCI-SIG vendor ID for the device | |
pciDeviceId | PCI-SIG device ID for the device | |
pciNumDevices | Number of PCI devices required. | |
pciAddress | Geographic location of the PCI device via the standard PCI-SIG addressing model of Domain:Bus:device:function | |
pciDeviceLocalToNumaNode | required
notRequired |
Determines if I/O device affinity is required. |
Network Interface Requirements
Capability Name | Capability Value | Description |
---|---|---|
nicFeature | LSO, LRO, RSS, RDMA | Long list of NIC related items such as LSO, LRO, RSS, RDMA, etc. |
dataProcessingAccelerationLibrary | Dpdk | Name of the data processing acceleration library required. Orchestration can match any NIC that is known to be compatible with the specified library. |
dataProcessingAccelerationLibraryVersion | Version | Version of the data processing acceleration library required. Orchestration can match any NIC that is known to be compatible with the specified library. |
interfaceType | Virtio, PCI-Passthrough, SR-IOV, E1000, RTL8139, PCNET | Network interface type |
vendorSpecificNicFeature | TBA | List of vendor specific NIC related items. |
WORK IN PROGRESS
To register VIM connection information, the following template must be filled and submitted to NFVsupport@etsi.org: template