5. Hardware Delivery and Configuration Requirements

5.1. Introduction

must: Requirements that are marked as must are considered mandatory and must exist in the reference implementation and implemented by installer. The same applies to must not.

may: Requirements that are marked as may are considered optional. The same applies to may not.

5.2. Requirements

As we known, the NFVi software builds upon a set of hardware resources. For the operator(user) having a set of hardware resources, there is an inevitable step to examine it before deployment of the software. If there is only limited nodes for lab demonstration or something like this, it’s acceptable to do it manually, however it would be a time consuming process especially there are large scale of hardware nodes, for example 1000 node. Also,adding the different provider’s factor, that’s much complicated to validate it and a headache thing if doing it in manual. In order to resolve this issue of how to validate hardware efficiently , we call on here to build up a common data model for describing the hardware data, which is extensible to large scale and can be recognized by some automated check tool (Let’s call it checker). Let’s also name it to description file, which is align with the one for software deployment definition already commited in another chapter. The description file defines the same information data model accross the hardware vendor provider. At present, in the first release,only the “readable” hardware parameter can be focused, in future release, “writable” parameter might add also. Besides, we also collect the common hardware check requiremnt here, most of which are origially from Prague meeting. We are expecting that by utilizing the common hardware description file, the check tool will perform all the neccessary hardware check point automatically. We believe this is a mutual interest for all operators having such needs.

5.2.1. General

A Descriptor File defines the configuration required by the checker in a common schema. The “checker tool” validates the current hardware against the descriptor file, listing mismatches or differences, as failures, allowing the user to quickly identify and correct any errors in hardware, network wiring, or configuration. If failures are detected, the process can be rerun after corrective actions are taken. This checking process must be completed before the software stack deployment.

Ref #	sub-category	Description
req.gen.chk.01	Checker	Checker must accept a descriptor file to finish hardware delivery validation.
req.gen.chk.02	Checker	Checker must report the checking result of success or failure with reason.
req.gen.des.01	Descriptor	Descriptor file must include neccessary information to remote access hardware resource
req.gen.des.02	Descriptor	Descriptor file may automate to generate from a user defined rule of how to generate asset name, IP address, gateways, VLAN ID, etc

Table 5-2-1: Check tool requirements

5.2.2. Check point

Till now, following the check point requirements are collected: (#5.4.1)

Test Type #	Purpose	Example	Check when
BIOS Settings	Verifies all applicable BIOS settings per hardware model.	Boot mode/Boot Sequence Retry/AC Power Recovery/Power Setting (balanced / performance)/Virt. Technology/Simultaneous Multithreading/Trusted platform module
Firmware Settings	Verifies all applicable Firmware settings.	BIOS/Storage Array Controller/NIC (e.g.Intel X710)/PXE Enabled Ports
Boot Order	Verifies applicable boot order settings.	First boot, Second boot.
Hardware Health	Queries Intelligent Platform Management Interface (IPMI) is for all hardware components and their health status.	Raid/System Board/CPU temp/Power Supply
PCI Slot Status & MAC	Which cards are in which slot, which slot is assigned to which CPU, slot type	card(s) in slot/port/PCI partition /Slot speed / type / CPU / Slot assignment
NIC	Validates that all NICs are in the correct slots, with a healthy status (per IPMI), have correct MAC addresses, and are detecting a cable connection (or not).	Correct LLDP neighbor MAC Addresses.
IPMI Logs	Check for existence of logs.	Physical event logged. E.g. chassis open on power up.
IPMI Users	Check for existence of user accounts.	Check if IPMI is available, if IPMI account is existing, if IPMI default credentials.
Hardware Inventory	Inventory of h/w on platform.	CPU and count, NUMA topology, CPU Freq, RAM, speed, size, model, etc.
Physical Disk Configuration	Verifies storage / disk config (type, size)	Physical disk type, card/port location,capacity
SRIOV Port Validation	Verifies global and NIC level enabled.	Confirm setting is enabled (or none)
Hardware Check	Verifies basic OS config attributes (i.e. Linux running on the host and reporting these values).	RAM size/number of cores.
Cabling Connection check	Verifies the wired connection between server NIC port and switch port, or the between switches.	Check if cabling is plugin correct as expected design data
Redfish interface	Verifies that support classic interface.	system service/Manager service/ChassisService/SessionService/AccountService/EventService etc.

Table 5-2-2: Hardware check point.

5.3. Descriptor file definition

As mentioned at the beginning, the description file is used to define the common hardware data which are used by the checker implementation The entry information must be included in the description file,which are the remote access parameter settings.

5.3.1. Resource pool

Resource pool is the conception which a NFV resource is planned to build up. It consists hardware server device, network device and cabling among them. It is referenced by other resource type to introduce later.

Field #	type	mandatory	Instruction
serial_no	String	Yes
resource_pool_name	String	Yes	resource name, e.g: NFV-RP-HZZZ-03A_0
type	String	Yes	TOCHECK: OTHER

Table 5-3-1: Resource pool.

5.3.2. NIC template

NIC Template defines network interface card parameters, it includes the crucial port number on the NIC, which is used as the reference in the cabling data and check.

Field #	type	mandatory	Instruction
serial_no	String	Yes
vendor	String	Yes	vendor name: ZTE,HUAWEI
server_type	String	Yes	ZTE “R5300 G4”, HUAWEI “TaiShan200-2280”
customized_model	String	No	customized model: C2,C21
nic_vendor	String	Yes	nework interface card vendor: intel
nic_type	String	Yes	Intel “x520”
rootbdf	String	Yes	e.g “00:03:01:00”
slot_id	String	Yes	the slot id number of card plugged-in
connect_type	String	Yes	plugin
port_quantity	Number	Yes	port quantity on the card. e.g. 2
port_bandwith	String	Yes	bandwith of port. e.g. 10G
cabling_ports	Number	Yes	port name used in the cabing data. corresponding the quantity e.g: 1_1;1_2 or Slot3/Port1;Slot3/Port2

Table 5-3-2: NIC template.

5.3.3. Cabinet

Cabinet is the rack holder for the server and network devices. The data will be referenced by server and network device data.

Field #	type	mandatory	Instruction
serial_no	String	Yes
room	String	Yes	room number, e.g: 2201
column	String	Yes	column number in the room: e.g. “J”
cabinet	String	Yes	cabinet number in the column: e.g. “01”

Table 5-3-3: Cabinet.

5.3.4. Server

The server device data defines key information about how to access the server remotely, for example remote IP address, user, and credentials. There are many ways to validate the hardware by remote interface verification, for example IPMI and redfish. Considering the number of servers, the user can choose to validate the server interface in a distributed way or in a centralized way. Distributed validation means that the server connects to the hardware management device (for example, BMC and IPMI) to validate the connection. Centralized validation means that the hardware management device connects to the server to validate the connection. The best practice is to use centralized validation when the number of servers is small (for example, storage servers), and use distributed validation when the number of servers is large (for example, generic servers).

Field #	type	mandatory	Instruction
serial_no	String	Yes
server_name	String	Yes	server name, e.g: NFV-D-HZZZ-03A-2201-0J01-M-SRV-01
vendor	String	Yes	vendor name “ZTE”,”HUAWEI” etc
server_type	String	Yes	ZTE “R5300 G4”, HUAWEI “TaiShan200-2280”
customized_model	String	No	customized model: C2,C21
server_sn	String	Yes	server serial number
resource_pool_name	String	Yes	resource pool name which belongs to
cabinet	String	Yes	cabinet which belongs to, in format room-column-cabinet, e.g. “2201-J-01”
position	String	Yes	the server position located in the cabinet.
remote_ip	String	Yes	BMC/iLO/IPMI ip for remote access, e.g “2409:8086:8313:81::1”
gateway	String	Yes	gateway of remote ip, e.g “2409:8086:8313:81::ffff”
outband_netmask	String	Yes	e.g. “64”
subnet	String	Yes	e.g. “2409:8086:8313:81”
remote_user	String	Yes	e.g. “Administrator”
remote_password	String	Yes	e.g. “password”
inband_ip	String	No	temporary inband_ip e.g “2409:8086:8313:f::24”
inband_gateway	String	No	gateway of inband ip, e.g “2409:8086:8313:f::ffff”
inband_netmask	String	No	e.g. “64”
group	String	Yes	network assignment “service/management/storage”
is_bmc_configured	String	Yes	TOCHECK

Table 5-3-4: Server.

5.3.5. Network device

network device data defines the key data about how to remote access the network device, such as switches and routers.

Field #	type	mandatory	Instruction
serial_no	String	Yes
device_name	String	Yes	device name, e.g: “NFV-D-HZZZ-03A-2201-0F01-DM-TOR-01”
vendor	String	yes	vendor name “ZTE”,”HUAWEI” etc
device_model	String	Yes	maipu “S4320”, HUAWEI “CE6856”
device_sn	String	No	vendor name “ZTE”,”HUAWEI” etc
device_type	String	Yes	“EOR”,”TOR”
resource_pool_name	String	Yes	resource pool name which belongs to , e.g. “NFV-RP-HZZZ-03A_0”
cabinet	String	Yes	cabinet which belongs to, in format room-column-cabinet, e.g. “2201-J-01”
position	String	Yes	the server position located in the cabinet.
remote_ip	String	Yes	BMC/iLO/IPMI/redfish ip for remote access, e.g “2409:8086:8313:81::1”
gateway	String	Yes	gateway of remote ip, e.g “2409:8086:8313:81::ffff”
netmask	String	Yes	e.g. “64”
mac_address	String	Yes	mac address
protocol	String	Yes	ssh/telnet/redfish etc.
user	String	Yes	e.g. “Administrator”
password	String	Yes	e.g. “password”
enable_password	String	Yes	e.g. “password”
group	String	Yes	network assignment “service/management/storage”

Table 5-3-5: Network device.

5.3.6. EOR card

EOR card data.

Field #	type	mandatory	Instruction
serial_no	String	Yes
eor_device_name	String	Yes	EOR device name
card_model	String	Yes	card model
slot	String	Yes	slot e.g. “01”

Table 5-3-6: EOR Card.

5.3.7. Cabling

Cabling records the physical cable connection information between the ports of server and switch, or switches. Check tool will verify the correctness according to the cabling data.

Field #	type	mandatory	Instruction
serial_no	String	Yes
source_cabinet	String	Yes	source cabinet which belongs to, in format room-column-cabinet, e.g. “2201-J-01”
source_device_name	String	yes	server,switch device name e.g “NFV-D-HZZZ-03A-2201-0G12-DM-TOR-01”
source_device_type	String	Yes	switch or server
source_port	String	Yes	e.g “gigabitethernet0/2”
target_cabinet	String	Yes	source cabinet which belongs to, in format room-column-cabinet, e.g. “2201-J-02”
target_device_name	String	yes	server,switch device name e.g “NFV-D-HZZZ-03A-2201-0G12-DM-TOR-01”
target_device_type	String	Yes	switch or server
target_port	String	Yes	e.g “gigabitethernet0/2”
cabling_type	String	Yes	e.g “SV-TOR”,”TOR-TOR”,”ST_TOR-ST_EOR”,”S_TOR-S_EOR”,”S_TOR-M_EOR”,”M_TOR-M_EOR”,”EOR-EOR”

Table 5-3-7: Cabling.

5.3.8. Server model

The server model describes processor, memory, harddrive, raid,manufacturer, model etc. server model will be referenced by servers.

Field #	type	mandatory	Instruction
name	String	Yes	model name will referenced by server
manufacturer	String	Yes
model	String	Yes
processor	String	Yes
memory	String	Yes
hard_drive	String	Yes
raid	String	Yes
network_card_infos	List	No	interface list definition
network_card_bond_infos	List	No	NIC bonding, might not be always the case.

Table 5-3-8: Server model.

5.3.9. Network device model

The network device model describes processor, memory,manufacturer, model etc. network device model will be referenced by network device.

Field #	type	mandatory	Instruction
name	String	Yes	model name will referenced by network device
manufacturer	String	Yes
model	String	Yes
processor	String	Yes
port_type	String	Yes	port type
port_quantity	String	Yes	total number of port
memory	String	Yes
version	String	Yes

Table 5-3-9: Network device model.

5.4. Appendix

5.4.1. HDV original collection.

CNTT Hardware Delivery Validation (01-2020 DDF)