Cni

1 Registration information

Name	cni
Category	Network
Permitted values	Per schema
Version	1.0
Schema	See below
Type	Generic
Description	This capability represents the realization of a secondary container cluster network interface. The expression of the related requirements allows the selection of a suitable CNITM and configuration of the Network Attachment Definition (NAD) or NADs accordingly.

2 JSON schema

cni

{   "$schema": "http://json-schema.org/draft-07/schema#",   "title": "cni",   "description": "Realization of a secondary container cluster network interface",   "additionalProperties": false,   "required": [      "interfaceType"   ],   "type": "object",   "properties": {     "interfaceType": {       "type": "string",       "enum": [         "kernel.netdev",         "direct.userspace",         "direct.kernel",         "bond",         "userspace"       ],                  "description": "Type of network interface"     },     "nicOptions": {       "type": "array",       "items": {         "type": "object",         "properties": {           "nicType": {             "type": "string",             "enum": [ "i710", "e810", "mlx-cx5", "mlx-cx6"],             "description": "Nic types the driver is verified to work with in a direct.userspace interface."           },           "speeds": {             "type": "array",             "items": {               "type": "integer"             },             "description": "List of speeds in bps the driver is verified to work with in a direct.userspace, direct.kernel or bond interface. If nicType is present, the speeds are applicable to that nicType."           },         },           "minProperties": 1       },         "description": "For direct.userdriver interface nic types and/or speeds the driver is verified to work with. For direct.kernel and bond speeds the driver is verified to work with"     },     "interfaceOptions": {      "type": "array",       "items": {         "type": "string",         "enum": [ "memif", "virtio"]       },             "description": "For userspace vnic configurations the network interface is verified to work with "     },     "interfaceRedundancy": {       "type": "string",       "enum": [ "infraProvided", "left", "right", "activeActiveBond", "activePassiveBond", "activeActiveL3" ],       "description": " Switchplane redundancy management method "     }   },   "allOf": [     {      "if": {        "properties": {            "interfaceType": {              "enum": [ "direct.userspace", "direct.kernel" ]             }          }        },        "then": {          "required": ["interfaceRedundancy" ],          "properties": {            "interfaceRedundancy": {              "enum": [ "activePassiveBond", "activeActiveBond", "activePassiveL3", "Left", "Right", "infraProvided" ]           }          }       }     },     {        "if": {          "properties": {            "interfaceType": {              "enum": ["kernel.netdev", "userspace" ]             }          }      },       "then": {         "properties": {           "interfaceRedundancy": {             "enum": ["infraProvided" ],             "default": "infraProvided"           }                }       }      },     {          "if": {          "properties": {            "interfaceType": {              "enum": ["bond"]             }          }      },        "then": {          "required": ["interfaceRedundancy" ],          "properties": {            "interfaceRedundancy": {            "enum": ["activePassiveBond", "activeActiveBond" ]          }        }       }     }   ]   }

3 Detailed description

The interfaceType can take one of the following values:

kernel.netdev	Linux kernel or vSwitch based. It is supported by CNIsTM like: OVS, MACVLAN, IPVLAN, BRIDGE, PTP, etc.
direct.userspace	Provides direct access to network PCIe, typically an SR-IOV VF, but could also be a PF. Uses application specific driver contained in the image. The device is bound to a driver by the cloud provider which supports user space control by the application (e.g. vfio_pci, igb_uio). It is supported by the following CNIsTM: SRIOV, HOST-DEVICE.
direct.kernel	Similar to direct.userspace but device is bound to a kernel driver by the cloud provider and can be consumed in the same way as a kernel netdev. It is supported by the following CNIsTM: SRIOV, HOST-DEVICE.
bond	Based on the BOND CNITM. Requires the existence of a mated pair of direct kernel network attachments prior to the creation of the bond. Thus, when this interface type is indicated, three attachments definitions to the secondary container cluster network are expected: two providing the direct kerneldriver  functionality and one with the BOND CNITM
userspace	Based on the userspace CNITM. requires infrastructure to support a DPDK-OVS or VPP based vSwitch.

The nicOptions can take one of the following values:

e710	Intel® Corporation Ethernet Controller 710 product family.
e810	Intel® Corporation Ethernet Controller E810 product family.
mlx-cx5	NVIDIA® Mellanox® ConnectX®-5 adapters product family.
mlx-cx6	NVIDIA® Mellanox® ConnectX®-6 adapters product family.

The interfaceRedundancy can take one of the following values:

infraProvided	The application sees one vNIC but the infrastructure provides redundant access to the network via both switch planes. For interface of type kernel.netdev the redundancy is provided by the vSwitch or Linux bonding. For interfaces of type direct, it requires that the physical NIC is connected to both switch planes (a.k.a. smartNIC). Thus it imposes hardware requirements on the infrastructure. For interface of type userspace redundancy handled by a DPDK-OVS or VPP vSwitch
left	A vNIC connected non-redundantly to the network via one specific (left) switchplane. Valid for interfaces of type direct.userdrive or direct.kernel. Redundancy is implemented by having two connection points, indicating different values (left/right) in the descriptor.
right	A vNIC connected non-redundantly to the network via one specific (right) switchplane. Valid for interfaces of type direct.userdrive or direct.kernel. Redundancy is implemented by having two connection points, indicating different values (left/right) in the descriptor. NOTE: left and right switch planes are logical terms that refer to physically disjoint switching resources.  They can for example be implemented as two independent sets of ethernet switches or a set of switches connected so that no single switch failure would cause end to end connectivity over the switching infrastructure to fail.
For the following cases the infrastructure provides for the single VduCp a mated pair of vNICs connected to the same network, one via left switchplane, the other via the right switchplane:
activeActiveBond	Requires a static multi-chassis LAG in active-active mode from the infrastructure. Typically corresponds to bonding mode-2 “balance-xor”
activePassiveBond	The interfaces are bonded in active-passive mode in the application with move of bond MAC address. No specific requirements on DC fabric. Typically corresponds to bonding mode-1 “active-backup”
activeActivel3	Application moves its IP address by attaching it to one of the two MACs by use of GARP messages.

The valid combinations of values for the interfaceType and the interfaceRedundancy properties as well the applicability of the nicOptions and interfaceOptions are shown in the following table:

interfaceType	nicOptions	interfaceOptions	interfaceRedundancy
kernel.netdev	Not applicable	Not applicable	infraProvided (default, no need to indicate)
direct.userspace	Applicable	Not applicable	left, right, activeActiveBond, activePassiveBond, activePassiveL3, infraProvided
direct.kernel	Applicable (only speeds)	Not applicable	left, right, activeActiveBond, activePassiveBond, activePassiveL3, infraProvided
bond	Applicable (only speeds)	Not applicable	activeActiveBond, activePassiveBond
userspace	Not applicable	Applicable	InfraProvided (default, no need to indicate)

An invalid combination of interfaceType and interfaceRedundancy shall be rejected.

An invalid use of nicOptions or interfaceOptions can be ignored.