Summary

The physical machine is a type of computing machine to provide physical resources. Since all cloud services have to reside and operate on physical machines, it is important for the cloud service providers as well as for the manufacturers to identify specific functional requirements of the physical machine.

Recommendation ITU-T Y.3507 provides an introduction to the physical machine including the physical machine components, physical machine types, virtualizations in the physical machine as well as the scalability of components in the physical machine.

In addition, this Recommendation provides functional requirements for the physical machine derived from various use cases described in Appendix II. The relationship with other related specifications developed in other Standards Development Organizations (SDOs) has is introduced in Appendix I.

History

Edition	Recommendation	Approval	Study Group	Unique IDa)
1.0	ITU-T Y.3507	2018-12-14	13	11.1002/1000/13812
a) To access the Recommendation, type the URL http://handle.itu.int/ in the address field of your web browser, followed by the Recommendation's unique ID. For example, http://handle.itu.int/11.1002/1000/11830-en.

Recommendation ITU-T Y.3507

Cloud computing - Functional requirements of physical machine

1. Scope

This Recommendation provides the functional requirements of the physical machine for cloud computing based on cloud computing infrastructure requirements presented in [ITU-T Y.3510]. This Recommendation addresses the following:

Overview of the physical machine;
Functional requirements of the physical machine. The functional requirements provided in this Recommendation are derived from use cases.

NOTE 1 – This Recommendation does not advocate, imply, or assume the use of any specific set or sets of technical specifications. Examples of such sets of technical specifications can be found in Appendix I.

NOTE 2 – This Recommendation addresses a set of use cases which are included in Appendix II.

2. References

The following ITU-T Recommendations and other references contain provisions which, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the editions indicated were valid. All Recommendations and other references are subject to revision; users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of the currently valid ITU-T Recommendations is regularly published. The reference to a document within this Recommendation does not give it, as a stand-alone document, the status of a Recommendation.
[ITU‑T X.1601]	Recommendation ITU-T X.1601, Security framework for cloud computing, 2nd edition.
[ITU‑T Y.3100]	Recommendation ITU-T Y.3100, Terms and definitions for IMT-2020 network, 1st edition.
[ITU‑T Y.3500]	Recommendation ITU-T Y.3500 \| ISO/IEC 17788, Information technology – Cloud computing – Overview and vocabulary, 1st edition.
[ITU‑T Y.3510]	Recommendation ITU-T Y.3510, Cloud computing infrastructure requirements, 2nd edition.
[ITU‑T Y.3521/M.3070]	Recommendation ITU-T Y.3521/M.3070, Overview of end-to-end cloud computing management, 1st edition.

3. Definitions

3.1. Terms defined elsewhere

This Recommendation uses the following terms defined elsewhere:

3.1.1. cloud computing: [ITU-T Y.3500] Paradigm for enabling network access to a scalable and elastic pool of shareable physical or virtual resources with self-service provisioning and administration on-demand.

3.1.2. cloud service: [ITU-T Y.3500] One or more capabilities offered via cloud computing invoked using a defined interface.

3.1.3. cloud service customer: [ITU-T Y.3500] Party which is in a business relationship for thepurpose of using cloud services.

3.1.4. cloud service provider: [ITU-T Y.3500] Party which makes cloud services available.

3.1.5. physical resource: [ITU-T Y.3100] A physical asset for computation, storage and/or networking.

NOTE – Components, systems and equipment can be regarded as physical resources

3.2. Terms defined in this recommendation

This Recommendation defines the following terms:

3.2.1. physical machine: A type of computing machine providing physical resources.

NOTE – A computing machine provides allocation and scheduling of processing resources. Types of computing machine are physical or virtual [ITU-T Y.3510].

4. Abbreviations and acronyms

This Recommendation uses the following abbreviations and acronyms:

AC: Alternating Current
AI: Artificial intelligence
API: Application Programming Interface
ATA: AT Attachment
CD: Compact Disc
CPU: Central Processing Unit
CSC: Cloud Service Customer
CSP: Cloud Service Provider
DC: Direct Current
DRAM: Dynamic Random Access Memory
ECC: Error Correcting Code
FSC: Fan Speed Control
GPU: Graphics Processing Unit
HDD: Hard Disk Drive
I2C: Inter-Integrated Circuit
IDE: Integrated Development Environment
IaaS: Infrastructure as a Service
IPMI: Intelligent Platform Management Interface
IT: Information Technology
I/O: Input/Output
iSCSI: Internet Small Computer System Interface
NIC: Network Interface Card
NFV: Network Function Virtualization
NGFF: Next Generation Form Factor
mSATA: Mini-Serial AT Attachment
OPEX: Operational Expenditure
OS: Operating System
PCI: Peripheral Component Interconnect
PCI-E: Peripheral Component Interconnect Express
PDU: Power Distribution Unit
PMBus: Power Management Bus
PWM: Pulse Width Modulation
RAID: Redundant Array of Independent Disks
RPM: Revolutions Per Minute
ROM: Read-Only Memory
SAS: Serial Attached SCSI
SATA: Serial AT Attachment
SCSI: Small Computer System Interface
SEL: System Event Log
SoC: System-on-a-Chip
SRAM: Static Random Access Memory
TCP: Transmission Control Protocol
UART: Universal Asynchronous Receiver/Transmitter
USB: Universal Serial Bus
VGA: Video Graphics Array
VM: Virtual Machine

5. Conventions

In this Recommendation:

The keywords "is required to" indicate a requirement which must be strictly followed and from which no deviation is permitted if conformance to this document is to be claimed.

The keywords "is recommended" indicate a requirement which is recommended but which is not absolutely required. Thus this requirement need not be present to claim conformance.

The keywords "is not recommended" indicate a requirement which is not recommended but which is not specifically prohibited. Thus, conformance with this specification can still be claimed even if this requirement is present.

The keywords "can optionally" indicate an optional requirement which is permissible, without implying any sense of being recommended. This term is not intended to imply that the vendor's implementation must provide the option and the feature can be optionally enabled by the network operator/service provider. Rather, it means the vendor may optionally provide the feature and still claim conformance with the specification.

6. Overview of the physical machine

6.1. Introduction to the computing machine

Cloud infrastructureincludes processing, storage, networking and other hardware resources, as well as software assets, for more information see clause 6 in [ITU-T Y.3510]. Processing resources are used to provide essential capabilities for cloud services and to support other system capabilities such as resource abstraction and control, management, security and monitoring.

A computing machine provides allocation and scheduling of processing resources. Types of computing machine are physical or virtual [ITU-T Y.3510]. The capability of a computing machine is typically expressed in terms of configuration, availability, scalability, manageability and energy consumption [ITU-T Y.3510].

The requirements of the virtual machine, as one of categories of the computing machine, have been specified in [ITU-T Y.3510]. Those requirements include virtualization technologies that can be applied to resource types such as the central processing unit (CPU), memory, input/output (I/O) and network interfaces. Several requirements regarding virtual machine management have alsobeen identified, e.g., duplication of a virtual machine (VM) dynamic/static migration of aVM and management automation.

For the physical machine, [ITU-T Y.3510] defines three requirements as follows.

It is recommended to support hardware resource virtualization.
It is recommended to support horizontal scalability (e.g., adding more computing machines) and vertical scalability (e.g., adding more resources with a computing machine).
It is recommended to use power optimization solutions to reduce energy consumption.

It is inferred from the requirements that the physical machine supports scalable resources with consideration of energy consumption.

Figure 1 shows the conceptual diagram of a computing machine in [ITU-T Y.3510].

Figure 1 — Concept of a computing machine in [ITU-T Y.3510]

A virtual machine provides virtualized resource pools using virtualization technologies specific to physical resource types like CPU, memory, I/O and network from a physical machine. The virtual machine also covers management issues.

Since all cloud services have to reside and operate on physical machines, it is important for the cloud service providers and especially for the infrastructure as a service (IaaS) cloud service provider (CSP) who will build the cloud infrastructure, as well as for the manufacturer who will sell the cloud infrastructure, to identify specific requirements of the physical machine.

6.2. Introduction to the physical machine

The physical machine is a type of computing machine in which the cloud services must reside and operate and that provides physical resources, such as processing, storage, networking, etc.

Figure 2 depictsan overview of the physical machine. The scope of this Recommendation focuses on the physical machine.

Figure 2 — Overview of the physical machine

The physical machine is composed of multiple components, which are described as follows:

Processing units: A processing unit has CPUs, memories, storages and I/O devices. These sub-components in a processing unit are physically implemented on a motherboard. The processing unit is the basic element as a hardware processing resource and normally multiple processing units are involved to provide capacity of resources. Processing units is a mandatory component for the physical machine. A single processing unit type physical machine has only one processing unit, while a multi-processing unittype physical machine has two or more processing units.
Interconnect network: An interconnect network has a role of connecting multiple processing units aiming to be used to share resources in individual processing units through virtualization. In addition, the interconnect network provides a communication interface to other external physical machines. An interconnect network is an optional component only for multi-processing unit type physical machines.
Enclosure: An enclosure includes multiple processing units and other components such as power supply, cooling and interconnect network (in some cases) by providing the form factor with metal apparatus that specifies the physical dimensions of a physical machine. The enclosure also shields the electromagnetic components and helps to dissipate heat of other components. An enclosure is a mandatory component for a physical machine.
Power supply: A power supply provides electrical power to all components in an enclosure. The power supply converts AC power into DC power which all components use to operate and provides redundancy to ensure that the stability and operability of a physical machine is maintained even in the case that a physical machine's power goes out. Power supply is a mandatory component for the physical machine.
Cooling: A cooling system is for maintaining a certain range of temperature in an enclosure by cooling heat generated due to operation of the physical machine. The implementation type can vary depending on cooling materials (e.g., air-cooled or a water-cooled type) and form factors (e.g., air flow or water pipes) of an enclosure. Cooling is a mandatory component for the physical machine.
Management component: A management component monitors and controls all components in a physical machine, by analyzing the gathered status information from the components. A management component is a mandatory component for the physical machine.

NOTE – Standard interfaces (e.g., I2C, PMbus, Ethernet, UART, PWM) are normally used to communicate between the management component and others.

Beside these components, the following are needed to manage and operate the physical machine:

I/O interface is used for I/O device to communicate with other physical machines or CSC/CSP. The I/O interface has two capabilities (i) capability to provide the channel for data input and output of the physical machine, (ii) capability to provide the channel for CSP/CSC to access the physical machine. The I/O interface follows industrial standards so that the CSP could select and replace the components from multiple vendors. The cloud computing management system communicates with the physical machines without any other development by the standard management interface.
Physical machine operation reports and maintains its running information, as well as environment condition periodically to the cloud computing management system [ITU-T Y.3521/M.3070]. In addition, the administrator can operate the physical machine with operation capabilities.
Scalability of components in the physical machines allows the physical machines to extend their resources elastically in the processing units, power supply and cooling system.
Security of the physical machine provides access control of the processing units.
Reliability of the physical machine is to keep physical machine consistently performing as expected. To provide reliability, when some components fail, the physical machine needs to support, detect and locate the faulty components.

6.3. Types of physical machine

6.3.1. Single processing unit type

The single processing unit type of physical machine has one processing unit, a single management component as well as one or more power supplies and cooling components. Since a single processing unit type has only one processing unit, no interconnect network component is involved in this type.

NOTE – An example of single processing unit type is a rack server [b-OCP BS].

Figure 3 — Example of single processing unit type

6.3.2. Multi-processing unit type

The multi-processing unit type has two or more processing units, as well as one or more power supplies, cooling components and a single management component and a single interconnect network.

NOTE – Examples of a multi-processing unit type are blade servers [b-OCP OSR] and rack scale servers [b-OCP OCSC].

Figure 4 — Example of a multi-processing unit type

6.4. Virtualization in physical machines

This clause identifies different types of virtualization of the components in processing units such as CPUs, memory and I/Os. The mode of virtualization in each component can be software based mode or hardware-assisted mode. The requirements in this Recommendation only consider the hardware‑assisted mode for virtualization.

6.4.1. CPU virtualization

CPU virtualization technology makes a single CPU act as if it was multiple individual CPUs. There are different ways to implement CPU virtualization. CPU virtualization can be implemented in software-based mode and in hardware-assisted mode:

In software based mode, the privileged instructions are simulated by software.
In hardware-assisted mode, the privileged instructions can be directly run by the physical CPU to achieve higher performance. Hardware-assisted mode requires the CPU to support a virtualization instruction set.

NOTE – The difference between the two modes is in the execution of privileged instructions in VM's operating system (OS).

6.4.2. Memory virtualization

Memory virtualization abstracts physical memory to a divided virtual memory for use by a virtual machine. There are two modes of memory virtualization: software-based and hardware-assisted memory virtualization:

Software-based mode builds a software based memory mapping table.
In hardware-assisted mode, a memory mapping table is implemented in hardware with better performance.

NOTE – The difference between the two modes is the mapping between virtual memory and physical memory.

6.4.3. I/O virtualization

I/O virtualization refers to dividing a single physical I/O into multiple isolated logical I/Os. There are two modes of I/O virtualization: software based and and hardware-assisted I/O virtualization:

Software based mode simulates I/O devices based on software.
The hardware-assisted mode provides better performance by reducing a hypervisor's participation in I/O processing by using hardware.

A network adapter is an I/O device specifically for data transmission. A network adapter provides an isolated logical I/O based on a single physical I/O toreceive and send data packets inside and outside of a physical machine as virtual network interfaces in order to improve interface utilization.

6.5. Scalability of components in the physical machine

Scalability of components in a physical machine allows enhancing the processing unit, power supply and cooling components of the physical machine.

6.5.1. Scalability of the processing unit

Scalability of the processing unit allows the processing units of a physical machine to be expanded. Scalability of the processing unit provides more hardware processing resources in order to meet potential growth needs, such as providing more CPU and memory resources to host more VMs with the growth of business needs.

There are several ways to expand processing units as shown hereafter with availability of motherboard interfaces and enclosure:

Replacing components of a processing unit with other components with higher capability, such as a CPU, memory, storage and I/O devices;
Adding components to a processing unit, such as a CPU, memory, storage and I/O devices;
Replacing processing units with other processing units with higher capability;
Adding processing units to the physical machine.

6.5.2. Scalability of power supply

Scalability of power supply allows the power supply of a physical machine to be expanded. Scalability of power supply provides more power in future for the potential increasing power consumption needs of the physical machine, such as providing more power for additional processing units.

There are several ways to expand power supply as shown hereafter with availability of enclosure:

Replacing power supplies of a physical machine with other power supplieswith higher capability;
Adding power supplies to the physical machine.

6.5.3. Scalability of cooling

Scalability of cooling allows the cooling capability of a physical machine to be increased. Scalability of cooling provides a higher cooling capability to meet the potential increasing cooling needs of the physical machine.

There are several ways to expand cooling capability as shown hereafter with availability of enclosure:

Replacing cooling components of a physical machine with other cooling componentswith higher capability;
Adding cooling components to the physical machine.

7. Functional requirements for a physical machine

7.1. Component requirements

7.1.1. Processing unit requirements

7.1.1.1. CPU requirements

Virtualization instruction set: It is recommended that a physical machine supports a CPUvirtualization instruction set to improve the performance of CPU virtualization.
CPU replacement: It is recommended that a physical machine supports substitution of CPU with other CPUs to allow CPU upgrade or replacement of faulty CPUs.
Multiple CPUs: It is recommended that a physical machine supports multiple CPUs to achieve higher performance.
Low power consumption of CPU: It is recommended that a physical machine supports low power consumption of CPU to reduce the operational expenditure (OPEX).

7.1.1.2. Memory requirements

Hardware-assisted memory virtualization: It is recommended that a physical machine supports hardware-assisted memory virtualization to improve the performance of memory virtualization.
Memory replacement: It is recommended that a physical machine supports substitution of memory with other memories to allow memory upgrade or replacement of faulty memory.
Memory reliability: It is recommended that a physical machine supports memory reliability using memory redundancy and memory error correction technologies.

NOTE 1 – Memory reliability refers to technologies to improve the reliability of the physical machine by preventing permanent loss of data or downtime caused by memory failure. One example is memory mirroring, as one implementation of memory redundancy. Memory mirroring replicates and stores data on a different physical memory within different channels simultaneously. If the primaryphysical memory failure occurs, subsequent read and write will use the backup memory.

Supporting various types of memory: It is recommended that a physical machine provides various types of memory such as non-volatile and volatile memory depending on the CPU's memory usage.

NOTE 2 – Examples of CPU's memory usage with non-volatile and volatile types are booting up and storing temporary data as main memory, respectively. Non-volatile type includes ROM and volatile type is classified into static random access memory (SRAM) and dynamic random access memory (DRAM).

7.1.1.3. Storage requirements

Multiple interfaces for storage: It is recommended that a physical machine supports interfaces of storage for different media, such as magnetic storage, optical storage and semiconductor storage.

NOTE 1 – Examples of interfaces include integrated development environment (IDE), serial AT attachment (SATA), serial attached SCSI (SAS), small computer system interface (SCSI), AT attachment (ATA), M.2 (formerly known as NGFF), peripheral component interconnect express (PCI-E) and mini-serial AT attachment (mSATA).

Storage replacement: It is recommended that storage in a physical machine supports substitution of storage with other storages to allow external storage upgrade or replacement of faulty external storage.
Storage redundancy hardware: It is recommended that a physical machine supports storage redundancy hardware.

NOTE 2 – An example of storage redundancy hardware is RAID card. RAID card is to support data storage virtualization technology that combines multiple physical disk drive components into one or more logical units for the purposes of data redundancy, performance improvement, or both.

Storage hibernation: It is recommended that a physical machine supports hibernation of storages without I/O for a long time to reduce energy consumption.

NOTE 3 – An example of storage hibernation is hard disk drive (HDD) hibernation. The HDD spins continuously at 5400/7200 revolutions per minute (RPM) consuming lots of power. During HDD hibernation, the HDD stops spinning to reduce power consumption.

7.1.1.4. I/O device requirements

Hardware-assisted I/O virtualization: It is recommended that a physical machine supports hardware-assisted I/O virtualization to improve the performance of I/O virtualization.
I/O devices direct accessing: It is recommended that a physical machine supports I/O devices direct accessing so that a virtual machine can directly access hardware I/O devices.

NOTE 1 – I/O devices direct accessing refers to technologies supporting VM's native accessing of physical I/O devices. One example of I/O devices direct accessing is I/O devices pass-through. I/O devices pass-through is an I/O device assigned directly to a VM. The VM can access the I/O devices without a hypervisor's participation.

Workload offload: It is recommended that a physical machine support offloading workload to I/O devices to reduce the load of the CPU.

NOTE 2 – In offloading workload, hardware I/O devices execute workload instead of software on a CPU in order to relieve the CPU's overhead. An example of offloading workload is checking transmission control protocol (TCP) checksum in a network interface card (NIC) and not in a CPU.

Hardware acceleration: It is recommended that a physical machine supports application‑specific hardware acceleration to perform specific applications more efficiently.

NOTE 3 – Application-specific hardware is customized for a particular use, rather than intended for general‑purpose use. An example of application-specific hardware is a graphics processing unit (GPU).

7.1.2. Power supply requirements

Power supply replacement: It is recommended that a physical machine supports substitution with other power supplies to allow power supply upgrade or replacement of a faulty power supply.
Supporting power redundancy: It is recommended that a physical machine supports redundant power supply to keep powered on in case of main power supply failure.

NOTE 1 – N+1 redundancy of power supplyis widely used (N: number of power supplies based on total power budget).

Minimum energy consumption: It is recommended that a physical machine provides minimum energy consumption.
Interface for monitoring power: It is recommended that a physical machine supports an interface to a management component for monitoring status of the power supply.

NOTE 2 – An example of the interface for monitoring power is a power management bus (PMBus).

7.1.3. Cooling requirements

Cooling component replacement: It is recommended that a physical machine supports substitution with other cooling components to allow substitution of a faulty cooling component.
Cooling component redundancy: It is recommended that a physical machine supports cooling component redundancy to maintain temperature in case of main cooling component failure.
Interface for controlling fan speed: It is recommended that a physical machine supports an interface to a management component to control fan speed.

NOTE – An example of an interface for controlling fan speed is a pulse width modulation (PWM) management component.

7.1.4. Enclosure requirements

Monitoring status of the physical machine: It is recommended that a physical machine provides a status panel to check whether components of the physical machine are installed and working correctly.
Visual indications: It is recommended that a physical machine provides visual indications of working state (e.g., starting, running, stopped, faulty), suitable for administrators of the physical machine to understand.
Equipment for mounting and removal: It is recommended that a physical machine supports safe mounting and easy removal of all components in the enclosure.
Circulation of air flow: It is recommended that a physical machine supports circulation of enough air flow to minimize the heat generated inside the enclosure with cooling components.

7.1.5. Interconnect network requirements

This functional requirement is applied for multi-processing unit types.

Interconnect network supports: It is recommended that a physical machine supports a non‑Ethernet based interconnect network as well as an Ethernet based interconnect network among the multiple processing units.

NOTE 1 – For this non-Ethernet based interconnect network, a CSP:cloud operations manager employs a CPU I/O (e.g., PCI Express) of processing units to construct the interconnect network.

Sharing process unit component: It is recommended that a physical machine provides a sharing component in the processing unit in other processing units by an interconnect network.

NOTE 2 – Examples of sharing components are memory, storage and I/O.

Network topology: It is recommended that a physical machine supports various types of network topology (e.g., Ring, Tree, Mesh, Cube, etc.) for multiple processing units.
Configuration of multiple processing units: It is required that a physical machine provides configuration of multiple processing units.

7.1.6. Management component requirements

Providing running information:It is recommended that a physical machine provides running information in all components of the physical machine.

NOTE 1 – Examples of running information are CPU temperature, CPU utilization, memory utilization, storage read/write load, fan speed and the traffic load of interconnect network.

Automatically power operation: It is recommended that a physical machine supports automatically managing for power on, power off and restart operations for automatic scheduling according to the load of the physical machine.
Monitoring of environment conditions: It is recommended that a physical machine provides monitoring of environment conditions, such as air temperature,air humidity, etc.
Self-checking mechanism: It is recommended that a physical machine supports self‑checking to ensure the stability of the physical machine after power on.

NOTE 2 – Self-checking is a process to verify CPU and memory, to initialize BIOS and to identity booting devices after a physical machine is powered on.

7.2. I/O interface requirements

Provide I/O interface to administrator: A physical machine can optionally provide an I/O interface to administrators for I/O devices such as a monitor, a mouse and a keyboard.

NOTE 1 – Examples of I/O interface to administrators are a video graphics array (VGA) and a universal serial bus (USB).

Provide I/O interface to external storage device: A physical machine can optionally provide an I/O interface for an external storage device to install the hypervisor, operating system and/or other software applications.

NOTE 2 – Examples of external storage device are CD ROM and USB flash disk.

Network interface virtualization: It is recommended that a physical machine supports network interface virtualization to improve interface utilization.

NOTE 3 – Network interface virtualization is sharing a network interface into multiple virtual network interfaces.

Device driver and API supports: It is required that a physical machine supports device drivers and APIs for I/O interface.

7.3. Operation requirements

Processing unit operation: It is recommended that a physical machine provides operations for processing units, such as power operation, monitoring configuration information of each processing units.

NOTE 1 – The power operation for a processing unit is to control the power status (e.g., power on, power off and restart) of each of the processing units. The monitoring configuration information of processing units is to collect and report the parameters of the processing units (e.g., CPU type, CPU clock speed, memory frequency and storage capacity).

Remote management: It is recommended that a physical machine supports to be managed remotely through network.

NOTE 2 – Examples of remote management of physical machine are power operation, firmware update and log querying for the physical machine remotely.

Diagnostic of physical machine:It is recommended that a physical machine supports diagnostic to analyze before and after a hardware fault as well as firmware and components of physical machine changes.

NOTE 3 – The fault prediction is accomplished by software.

7.4. Scalability requirements

Expansion of interconnect network: It is recommended that a physical machine provides external expansion of the interconnect network among multiple physical machines to meet required computing performance level from a CSU.
I/O interface for device extensions: It is recommended that a physical machine provides an I/O interface for device extensions that can be used to extend high performance network cards, graphics card and so forth.
Processing unit replacement: It is recommended that a physical machine supports substitution with other processing units to allow processing unit upgrade.
Adding processing units: It is recommended that a physical machine supports the addition of more processing units to the physical machine.
Adding components of processing units: It is recommended that a physical machine supports the addition of more components to the processing units, including CPU, memory, storage and I/O device.
Adding power supply: It is recommended that a physical machine supports the addition of more power supply components to the physical machine.
Adding cooling component: It is recommended that a physical machine supports the addition of more cooling components to the physical machine.

7.5. Security requirements

No additional ports: It is recommended that a physical machine does not expose network ports that are not used.
Authorized access: It is recommended that a physical machine supports an authorized access.

7.6. Reliability requirement

Support fault location: It is recommended that a physical machine supports fault location, so that the operator can easily replace the failing components.
Hot-plug support: A physical machine can optionally support hot-plug without damage.

NOTE – Hot-plug is plugging in and out some components of the physical machine while it is running. An example of hot-plug support is hot-plug disk. Hot-plug disk refer to the disks supporting plug in to or plug out from the physical machine without damage while the physical machine is running.

8. Security considerations

Security aspects for consideration within the cloud computing environment are addressed by security challenges for the CSPs as described in [ITU-T X.1601]. In particular, [ITU-T X.1601] analyses security threats and challenges and describes security capabilities that could mitigate these threats and meet the security challenges.

Appendix I

Comparison between functional requirements and other specifications

(This appendix does not form an integral part of this Recommendation.)

I.1. Specifications and other SDOs

I.1.1. Open Compute Project

The Open Compute Project (OCP) is a rapidly growing community of engineers around the world whose mission is to design and enable the delivery of the most efficient server, storage and data centre hardware designs available for scalable computing.

The OCP Server Project provides standardized server system specifications for scale computing. Standardization is key to ensure that the OCP specification pool does not get fragmented by point solutions that plague the industry today. The Server Project collaborates with the other OCP disciplines to ensure broad adoption and achieve optimizations throughout all aspects from validation, to manufacturing, deployments, data centre operations and de-commissioning.

Table I.1 lists OCP related specifications.

Table I.1 — OCP related specifications

Family	Specification	Summary	Published
OpenRack V2	Twin Lakes 1S Server Design Specification V1.00 [b-OCP 1S]	This specification describes the design of the Twin Lakes 1S server based on the Intel Xeon Processor D-2191 System-on-a-Chip (SoC).	2018
	Facebook 2S Server Tioga Pass Specification V1.0 [b-OCP 2S]	This specification describes Facebook dual sockets server Intel Motherboard v4.0 (Project name: Tioga Pass) design and design requirement to integrate Tioga Pass into Open Rack V2.	2018
	Big Basin-JBOG Specification V1.0 [b-OCP JBOG]	This document describes technical specifications for Facebook's Big Basin-JBOG for use in Open Rack V2.	2018
	Inspur Server Project San Jose V1.01 [b-OCP SJ]	This document defines the technical specification for San Jose Motherboard and chassis used in Open Compute Project Open Rack V2.	2017
	Facebook Multi-Node Server Platform: Yosemite V2 Design Specification V1.0 [b-OCP Yose]	This specification describes the design of the Yosemite V2 Platform that hosts four One Socket (1S) servers, or two sets of 1S server/device card pairs.	2017
	Facebook Server Intel Motherboard V4.0 Project Tioga Pass V0.30 [b-OCP TP]	This specification describes Facebook dual sockets server Intel Motherboard v4.0 (Project name: Tioga Pass) design and design requirement to integrate Intel Motherboard v4.0 into Open Rack V2.	2017
	Facebook Server Intel Motherboard V3.1 [b-OCP MB]	This specification describes Intel Motherboard v3.0 design and design requirement to integrate Intel Motherboard v3.0 into Open Rack V11 and Open Rack V2.	2016
	Open Rack- Intel Motherboard Hardware V2.0 [b-OCP IMBH]	This document defines the technical specifications for the Intel motherboard used in Open Compute Project servers.	2016
OpenRack v1	Open Rack- AMD Motherboard Hardware V2.0 [b-OCP AMBH]	This document defines the technical specifications for the AMD motherboard used in Open Compute Project servers.	2012
OpenRack v1	Facebook server Fan Speed Control Interface Draft V0.1 [b-OCP FSCI]	This document describes Facebook's FSC algorithm and its update methodology. Using the OpenIPMI fan speed control (FSC) is an intelligent method for controlling server fans to provide adequate cooling while managing thermal constraints and power efficiency. This document will help to manage FSC settings and FSC updates by using intelligent platform management interface (IPMI) commands to vary the fan control profile on either local or remote systems.	2017
Olympus	Project Olympus AMD EPYC Processor Motherboard Specification [b-OCP OAPM]	This specification describes the Project Olympus AMD Server Motherboard. This is an implementation specific specification under the Project Olympus Universal Motherboard Specification.	2017
	Project Olympus Cavium ThunderX2 ARMx64 Motherboard Specification [b-OCP OCTAM]	This specification focuses on the Project Olympus Cavium ThunderX2 ARMx64 Motherboard. This is an implementation specific specification under the Project Olympus Universal Motherboard Specification.	2017
	Project Olympus 1U Server Mechanical Specification [b-OCP O1USM]	This specification focuses on the Project Olympus full-width server mechanical assembly. It covers the mechanical features and supported components of the server, as well as the interfaces with the mechanical and power support structure.	2017
	Project Olympus 2U Server Mechanical Specification [b-OCP O2USM]	This specification focuses on the Project Olympus 2U server mechanical assembly. It covers the mechanical features and supported components of the server, as well as the interfaces with the mechanical and power support structure.	2017
	Project Olympus Intel Xeon Scalable Processor BIOS Specification [b-OCP OBIOS]	The System BIOS is an essential platform ingredient which is responsible for platform initialization that must be completed before booting of an operating system. Thus, the BIOS execution phase of the boot process is often referred to as pre‑boot phase.	2017
	Project Olympus Intel Xeon Scalable Processor Motherboard Specification [b-OCP OMB]	This specification describes the Project Olympus Intel Server Motherboard. This is an implementation specific specification under the Project Olympus Universal Motherboard Specification.	2017
OCS	Open CloudServer OCS Programmable Server Adapter Mezzanine Programmables V1.0 [b-OCP OCSPSAM]	This document defines physical and interface requirements for the programmable NIC mezzanine card that can be installed on an Open Cloud Server (OCS) server blade. This server adapter is programmable and provides CPU offload for Host‑based SDN, virtual switch data path and tunneling protocols.	2016
	Open CloudServer OCS Chassis Manager Specification V2.1 [b-OCP OCSCM]	This specification is an addendum to the OCS Open CloudServer Chassis Management v2.0 specification. It defines the requirements for the upgrade to the Chassis Manager v1.0 made necessary by end of production of the CPU.	2016
	Open CloudServer OCS Blade Specification V2.1 [b-OCP OCSB]	This document is intended for designers and engineers who will be building blades for an OCS system.	2016
	Open CloudServer OCS Solid State Drive V2.1 [b-OCP OCSSSD]	This specification, Open CloudServer Solid State Drive, OCS SSD, describes the low-cost, high‑performance flash-based storage devices deployed first in the Open CloudServer OCS Blade V2 specification. The OCS Blade V2 supports four PCI-Express riser cards and eight Open CloudServer Solid State Drive M.2 modules. The Table 1 briefly describes the required features.	2015
	Open CloudServer OCS Power Supply V2.0 [b-OCP OCSPS]	This specification, Open CloudServer Chassis Power Supply Version 2.0, describes the power supply family requirements for the Windows Cloud Server system. The mechanical interface and electrical interface is identical between power supply options to enable a common slot, universal, modular foundation power supply system to enable the Microsoft Windows Cloud Server systems.	2015
	Open CloudServer SAS Mezzanine I/O specification V1.0 [b-OCP OCSSAS]	This document outlines specifications for the Open CloudServer Storage Attached SCSI (SAS) mezzanine card.	2015
	Open CloudServer JBOD specification V1.0 [b-OCP OCSJBOD]	This document provides the technical specifications for the design of the 6G half-width JBOD blade for the Open CloudServer system.	2015
	Open CloudServer OCS Tray Mezzanine Specification V2.0 [b-OCP OCSTRAY]	This specification, Open CloudServer OCS Tray Mezzanine Version 2.0, describes the physical and interface requirements for the Open CloudServer (OCS) tray mezzanine card. The mezzanine card will be installed on the tray backplane and will have a Peripheral Component Interconnect Express (PCIe) x16 Gen3 interface. This interface can either be used as one x16, two x8, or four x4 channels.	2015
	Open CloudServer Chassis Specification V2.0 [b-OCP OCSC]	Describes the hardware used in the Version 2.0 (V2.0) OCS system, including the chassis, tray and systems management.	2015
	Open CloudServer OCS NIC Mezzanine Specification V2.0 [b-OCP OCSNIC]	This specification, Open CloudServer NIC Mezzanine Version 2.0, describes the physical and interface requirements for the Open CloudServer (OCS) NIC mezzanine card that to be installed on an OCS blade.	2014
OCP Mezzanine	Mezzanine Card 2.0 Design Specification V1.0 [b-OCP MEZZ]	Mezzanine card 2.0 specification is developed based on original OCP Mezzanine card. It extends the card mechanical and electrical interface to enable new uses cases for Facebook and other users in OCP community. The extension takes backward compatibility to existing OCP platforms designed for original OCP Mezzanine card specification V0.5 into consideration and some tradeoffs are made between backward compatibility and new requirements.	2016
OCP Mezzanine	Mezzanine Card for Intel v2.0 Motherboard [b-OCP MEZZMB]	This document describes the mezzanine card design for use with Open Compute Project Intel v2.0 motherboards. The mezzanine card is installed on an Intel v2.0 OCP motherboard to provide extended functionality, such as support for 10GbE PCI-E devices.	2012
19" Server	QCT Big Sur Product Architecture Following Big Sur Specification V1.0 [b-OCP BS]	The QCT Big Suris 4OU/21 "chassis which using IA-64 based dual-socket servers that support the Grantley–EP processors in combination with the Wellsburg PCH to provide a balanced feature set between technology leadership and cost. QCT Grantley platform will be 16DIMMsand supports 8 GPGPU cards and Max. 8x2.5" HDDs.	2017
	Hyve Solutions Ambient Series-E V1.2 [b-OCP HSAS]	This document defines the technical specifications for the Hyve Solutions Ambient Series-E server, including motherboard, chassis and power supply.	2017
	QuantaGrid D51B-1U V1.1 [b-OCP QGD]	The Quanta Grid D51B-1Uwill be IA-64 based dual-socket servers that support the Grantley–EP processors in combination with the Wellsburg PCH (PCH) to provide a balanced feature set between technology leadership and cost.	2015
	Decathlete Server Board Standard V2.1 [b-OCP DSBS]	This standard provides board-specific information detailing the features and functionality of a general purpose 2-socket server board for adoption by the Open Compute Project community. The purpose of this document is to define a dual socket server board that is capable of deployment in scale out data centres as well as traditional data centres with 19" rack enclosures.	2013
SOC Boards	Panther+ Micro-Server Card Hardware V0.8 [b-OCP PMSCH]	This document describes the technical specifications used in the design of an Intel Avoton SoC based Micro-Server card for Open Compute Project, known as the Panther+.	2016
SOC Boards	Micro-Server Card Hardware V1.0 [b-OCP HSCH]	This specification provides a common form factor for emerging micro-server and SOC (System-On-Chip) server designs.	2016
Barreleye	Barreleye G2 Specification [b-OCP G2]	This document describes the specifications for: Zaius POWER9 motherboard, Barreleye G2 server – 2OU, Zaius server – 1.5OU	2017
	Barreleye G1 Specification [b-OCP G1]	This document describes the specification of Barreleye, an OpenPOWER-based Open Compute server, with a mechanical and electrical package designed for Open Rack.	2016
	Facebook, Microsoft, M.2 Carrier Card Design Specification V1.0 [b-OCP M2]	This specification provides the requirements for a PCIe Full Height Half Length (FHHL) form factor card that supports up to four M.2 form factor solid-state drives (SSDs). The card shall support 110mm (Type 22110) or 80mm (Type 22080) dual sided M.2 modules.	2018
	Facebook PCIe Retimer Card V1.1 [b-OCP PCIRC]	This specification describes the design and design requirements for a PCIe add-in card that converts an internal PCIe connection to an external PCIe connection.	2017
	Add-on-Card Thermal Interface Spec for Intel Motherboard V3.0 [b-OCP ACTI]	The goal of this document is to define a standard interface for Facebook Intel motherboard V3.0 to poll thermal data from an add-on-card including Mezzanine card.	2017
Debug Card	OCP debug card with LCD spec V1.0 [b-OCP Debug]	The specification defines the OCP Debug Card with LCD for a server system debug.	2018
Mezz Card	25G Dual Port OCP 2.0 NIC Mezzanine Card V1.0 [b-OCP 25GDual]	This document specifies a technical design implementation to define 25G Ethernet card which meets the requirements of OCP Mezzanine card 2.0 type-A design and the heat sink design could let this card to be able to deployment in OCP server or standard server.	2018
Mezz Card	OCP NIC 3.0 Design Specification V0.8 [b-OCP NIC]	The OCP NIC 3.0 specification is a follow-on to the OCP Mezz 2.0 rev 1.00 design specification. The OCP NIC 3.0 specification supports two basic card sizes: Small Card and Large Card. The Small Card allows for up to 16 PCIe lanes on the card edge while the Large Card supports up to 32 PCIe lanes.	2018

I.1.2. DMTF

The Distributed Management Task Force (DMTF) is an industry standards organization working to simplify the manageability of network-accessible technologies through open and collaborative efforts by leading technology companies. DMTF creates and drives the international adoption of interoperable management standards, supporting implementations that enable the management of diverse traditional and emerging technologies including cloud, virtualization, network and infrastructure.

DMTF has developed specifications related to management interface, which are related to the management of physical machines.

Table I.2 — DMTF related specifications

Specification	Summary	Published
Redfish Scalable Platforms ManagementAPI Specification [b-DMTF RFAPI]	This specification is to define the protocols, data model and behaviors, as well as other architectural components needed for an interoperable, cross-vendor, remote and out-of-band capable interface that meets the expectations of Cloud and web-based IT professionals for scalable platform management. While large scale systems are the primary focus, the specifications are also capable of being used for more traditional system platform management implementations.	2018-08-23
Redfish Host Interface Specification [b-DMTF RFHI]	This specification defines functional requirements for Redfish Host Interfaces. In the context of this document, the term "Host Interface" refers to interfaces that can be used by software running on a computer system to access the Redfish Service that is used to manage that computer system.	2017-12-11
Redfish Interoperability Profiles [b-DMTF RFP]	The Redfish Interoperability Profile is a JSON document that contains Schema-level, Property‑level and Registry-level requirements. At the property level, these requirements can include a variety of conditions under which the requirement applies.	2018-05-15

I.1.3. SNIA

The Storage Networking Industry Association (SNIA) is a non-profit organization made up of member companies spanning information technology. A globally recognized and trusted authority, SNIA's mission is to lead the storage industry in developing and promoting vendor-neutral architectures, standards and educational services that facilitate the efficient management, movement and security of information.

Table I.3 — SNIA related specifications

Specification	Summary	Published
SNIA Swordfish Specification V1.0.6 [b-SNIA SF]	The Swordfish Scalable Storage Management API ("Swordfish") defines a RESTful interface and a standardized data model to provide a scalable, customer-centric interface for managing storage and related data services. It extends the Redfish Scalable Platforms Management API Specification (DSP0266) from the DMTF.	2018-05-25

I.1.4. ETSI

The European Telecommunications Standards Institute (ETSI) is the recognized regional standards body – European Standards Organization (ESO) – dealing with telecommunications, broadcasting and other electronic communications networks and services.

The ETSI NFV EVE Working Group seeks to develop the necessary requirements to enable a common set of hardware elements and physical environments (e.g., data centres) that can be used to support network function virtualization (NFV) services [b-ETSI EVE007].

Table I.4 — ETSI related specifications

Specification	Summary	Published
Hardware Interoperability Requirements Specification [b-ETSI EVE007]	The document develops a set of normative interoperability requirements for the NFV hardware ecosystem and telecommunications physical environment to support NFV deployment.	2017-03

I.2. Relationship with related specifications from other SDOs

Table I.5 analyses the relationship between functional requirement introduced in this Recommendation and the related Specification from other SDOs. The major differences between this Recommendation and other related Specifications are as follows:

'Monitoring environment condition' (see clause 7.1.6) and 'No additional ports' (see clause 7.5) are not addressed in the specifications identified in clause I.1.
This Recommendation introduced the physical machine with functional requirements derived by use cases with general purpose; other deliverables from other SDOs are specific for server implementation or interface in detail.

Table I.5 — Relationship with related specifications from other SDOs

No.	Requirements in this recommendation	Relationship with related specifications from other sdos
1	Virtualization instruction set	[b-OCP 1S] provides virtualization instruction set as 'The Twin Lakes 1S server is designed to use Intel Xeon Processor D-2191 utilizing the performance and advanced Intelligence of Intel Xeon processors packaged into a dense, lowpower SoC' in clause 3. [b-OCP BS] provides virtualization instruction set as 'Intel Xeon Haswell/Broadwell-EP' in clause 2 table 2-1. [b-OCP HSAS] provides virtualization instruction set as 'The motherboard is designed to support dual Intel Xeon E5-2600 v3 and v4 series processors and up to 2048GB LRDIMM 3DS/1024GB LRDIMM/ 512GB RDIMM DDR4 memory. Leveraging advanced technology from Intel, the motherboard is capable of offering scalable 32- and 64- bit computing, high-bandwidth memory design and lightning-fast PCI-E bus implementation' in clause 7. [b-OCP IMBH] provides virtualization instruction set as 'The Efficiency Performance motherboard, built with the Intel Xeon E5‑2600 processor, was originally was code-named the Sandy Bridge‑EP motherboard' in clause 4. [b-OCP OAPM] provides virtualization instruction set as 'CPU: AMD EPYC processors' in clause 5. [b-OCP MB] provides virtualization instruction set as 'Intel Motherboard V3.1 (also referred to "motherboard" or "the motherboard" in this document, unless noted otherwise) is based on Intel Xeon Processor E5-2600 v3 (formerly code-named Haswell‑EP processor) product family CPU architecture' in clause 4.1
2	CPU replacement	[b-OCP 2S] provides CPU replacement as 'The motherboard supports all Intel Xeon Scalable processor family (aka Skylake-SP) processors with TDP up to 165W. The motherboard shall provision the support of all future CPUs in Intel Xeon Scalable processor Family Platform and the Next gen Intel Xeon Scalable processor Family Platform unless noted otherwise' in clause 5.3.1. [b-OCP HSAS] provides CPU replacement as 'The motherboard is designed to support dual Intel Xeon E5-2600 v3 and v4 series processors and up to 2048GB LRDIMM 3DS/1024GB LRDIMM/ 512GB RDIMM DDR4 memory. Leveraging advanced technology from Intel, the motherboard is capable of offering scalable 32- and 64‑bit computing, high-bandwidth memory design and lightning-fast PCI-E bus implementation' in clause 7. [b-OCP MB] provides CPU replacement as 'The motherboard uses Intel Xeon E5-2600 v3 (LGA2011-3) Product Family processors with TDP up to 145W. The features listed below must be supported by the motherboard: Support two Intel Xeon E5-2600 v3 (LGA2011‑3) Product Family processors up to 145W TDP and vendors should engage with Intel to ensure the design ready for future processors; Two full-width Intel QPI links up to 9.6 GT/s/direction; Up to 18 cores per CPU (up to 36 threads with Hyper-Threading Technology). Up to 45MB last level cache; Single Processor mode is supported' in clause 5.3.1.
3	Multiple CPUs	[b-OCP 2S] provides multiple CPUs as 'Support two Intel XeonScalable processor family (aka Skylake-SP) processors up to 165W TDP and vendors should engage with Intel to ensure the design ready for future processors' in clause 5.3.1. [b-OCP AMBH] provides multiple CPUs as 'The motherboard supports two AMD G34 Magny Cours or Interlagos CPUs with a TDP (thermal design power) of 115W' in clause 4.3. [b-OCP DSBS] provides multiple CPUs as 'Support up to two processors with a thermal design point (TDP) of up to 135 W' in clause4. [b-OCP DSBS] provides multiple CPUs as 'Support up to two processors using LGA2011-3 (socket type R3) and VRD 12.5 and a thermal design point (TDP) of up to 145W' in clause 4. [b-OCP HSAS] provides multiple CPUs as 'The motherboard is designed to support dual Intel Xeon E5-2600 v3 and v4 series processors and up to 2048GB LRDIMM 3DS/1024GB LRDIMM/ 512GB RDIMM DDR4 memory. Leveraging advanced technology from Intel, the motherboard is capable of offering scalable 32- and 64‑ bit computing, high-bandwidth memory design and lightning-fast PCI-E bus implementation' in clause 7. [b-OCP IMBH] provides multiple CPUs as '2 Intel Xeon E5-2600 (LGA2011) series processors up to 115W' in clause 4.3. [b-OCP OAPM] provides multiple CPUs as 'Sockets: Dual socket operation' in clause 5. [b-OCP MB] provides multiple CPUs as 'The motherboard uses Intel Xeon E5-2600 v3 (LGA2011-3) Product Family processors with TDP up to 145W. The features listed below must be supported by the motherboard: Support two Intel Xeon E5-2600 v3 (LGA2011-3) Product Family processors up to 145W TDP and vendors should engage with Intel to ensure the design ready for future processors; Two full-width Intel QPI links up to 9.6 GT/s/direction; Up to 18 cores per CPU (up to 36 threads with Hyper-Threading Technology). Up to 45MB last level cache; Single Processor mode is supported' in clause 5.3.1.
4	Low power consumption of CPU	[b-OCP 2S] provides Low power consumption of CPU as 'Tuning CPU/Chipset settings to reach minimized power consumption and best performance in a data centre environment' in clause 6.3.1. [b-OCP 2S] provides Low power consumption of CPU as 'The vendor should implement BMC firmware to support platform power monitoring. To enable power limiting for processor, memory and platform, Intel Server Platform Services-NM is required' in clause 9.8. [b-OCP 2S] provides Low power consumption of CPU as 'CPU VR optimizations shall be implemented to remove cost and increase the efficiency of the power conversion system' in clause 15.3.2. [b-OCP G1] provides Low power consumption of CPU as 'The motherboard shall be designed to handle a processor with a maximum TDP of 190W CPU' in clause 7.3.1 [b-OCP DSBS] provides Low power consumption of CPU as 'Support up to two processors with a thermal design point (TDP) of up to 135 W' in clause 4. [b-OCP AMBH] provides Low power consumption of CPU as 'The CPU VRM is optimized to reduce cost and increase the efficiency of the power conversion system' in clause 9.1.5. [b-OCP DSBS] provides Low power consumption of CPU as 'Support up to two processors using LGA2011-3 (socket type R3) and VRD 12.5 and a thermal design point (TDP) of up to 145W' in clause 4. [b-OCP IMBH] provides Low power consumption of CPU as 'The motherboard uses next generation Intel Xeon processor E5-2600 product family CPUs with a TDP (thermal design power) up to 115W' in clause 4.3. [b-OCP IMBH] provides Low power consumption of CPU as 'Two to monitor temperatures for CPU0 and CPU1, retrieved through the CPU's temperature sensor interface (PECI)' in clause 6.1. [b-OCP MB] provides Low power consumption of CPU as 'The motherboard uses Intel Xeon E5-2600 v3 (LGA2011-3) Product Family processors with TDP up to 145W. The features listed below must be supported by the motherboard: Support two Intel Xeon E5‑2600 v3 (LGA2011-3) Product Family processors up to 145W TDP and vendors should engage with Intel to ensure the design ready for future processors; Two full-width Intel QPI links up to 9.6 GT/s/direction; Up to 18 cores per CPU (up to 36 threads with Hyper‑Threading Technology). Up to 45MB last level cache; Single Processor mode is supported' in clause 5.3.1. [b-OCP MB] provides Low power consumption of CPU as 'The BIOS should be tuned to minimize system power consumption and maximize performance. This includes: Disable any unused devices, such as unused PCI, PCIe ports, USB ports, SATA/SAS ports, clock generator and buffer ports. Tuning CPU/Chipset settings to reach minimized power consumption and best performance in a data centre environment' in clause 6.3.1.
5	Hardware-assisted memory virtualization	[b-OCP 2S] provides hardware-assisted memory virtualization as 'Setting for the watchdog timer: The default setting for EVT/DVT/PVT is disabled. The default setting for MP is enabled. The timeout value is 15 minutes and reset the system after the timer expires. The watchdog timer is always disabled after POST' in clause6.3.2. [b-OCP HSAS] provides hardware-assisted memory virtualization as 'The motherboard is designed to support dual Intel Xeon E5-2600 v3 and v4 series processors and up to 2048GB LRDIMM 3DS/1024GB LRDIMM/ 512GB RDIMM DDR4 memory. Leveraging advanced technology from Intel, the motherboard is capable of offering scalable 32- and 64- bit computing, high-bandwidth memory design and lightning-fast PCI-E bus implementation' in clause 7. [b-OCP IMBH] provides hardware-assisted memory virtualization as 'The Efficiency Performance motherboard, built with the Intel Xeon E5-2600 processor, was originally was code-named the Sandy Bridge‑EP motherboard' in clause 4. [b-OCP OAPM] provides hardware-assisted memory virtualization as 'AMD EPYC platform' in clause 5. [b-OCP MB] provides hardware-assisted memory virtualization as 'Intel Motherboard V3.1 (also referred to "motherboard" or "the motherboard" in this document, unless noted otherwise) is based on Intel Xeon Processor E5-2600 v3 (formerly code-named Haswell‑EP processor) product family CPU architecture' in clause 4.1.
6	Memory replacement	[b-OCP 2S] provides memory replacement as 'Besides traditional DDR4 DIMM, the motherboard shall support Non-Volatile DIMM (NVDIMM) on all DIMM slots' in clause 5.3.3. [b-OCP DSBS] provides memory replacement as 'Memory Expansion :16 sockets for un-buffered DDR3 and registered DDR3 DIMMS' and 'Provide 16 sockets for DDR4 DIMMS' in clause 4. [b-OCP G1] provides memory replacement as '4 DDR3 Memory channels per memory buffer; total 32 DDR3 RDIMMs, 1333 MHz (1DPC), 8/16/32GB' in clause 6.1. [b-OCP HSAS] provides memory replacement as 'The motherboard is designed to support dual Intel Xeon E5-2600 v3 and v4 series processors and up to 2048GB LRDIMM 3DS/1024GB LRDIMM/ 512GB RDIMM DDR4 memory. Leveraging advanced technology from Intel, the motherboard is capable of offering scalable 32- and 64‑ bit computing, high-bandwidth memory design and lightning-fast PCI-E bus implementation' in clause 7. [b-OCP MB] provides memory replacement as 'The motherboard has DIMM subsystem designed as below: DDR4 direct attach memory support on CPU0 and CPU1; 4x channels DDR4 registered memory interface on each CPU; 2x DDR4 slots per channel (total 16 DIMM); Support RDIMM, LRDIMM; Support SR, DR and QR DIMM; Support DDR4 speeds of 1600/1866/2133; Up to maximum 1024 GB with 64GB DIMMs; Follow updated JEDEC DDR4 specification with 288 pin DIMM socket' in clause 5.3.2.
7	Memory reliability	[b-OCP 2S] provides memory reliability as 'Setting for ECC error threshold: Available settings are 1, 4, 10 and 1000. The default setting is 1 for EVT, DVT and PVT and 1000 for MP. Setting for ECC error event log threshold: Available settings are disabled, 10, 50, 100. The default setting is 10' in clause 6.3.2. [b-OCP 2S] provides memory reliability as 'Both correctable ECC and uncorrectable ECC errors should be logged into SEL. Each log entry should indicate location of DIMM by CPU socket#, Channel # and slot #. Memory error reporting need to be tested by both XDP injection and reworked ECC DIMM' in clause 9.11.1. [b-OCP AMBH] provides memory reliability as 'Setting for ECC error threshold, available settings are 1, 4, 10 and 1000' in clause 5.5. [b-OCP AMBH] provides memory reliability as 'CPU/memory errors: Both correctable ECC and uncorrectable ECC errors should be logged into event log. Error categories include DRAM, HyperTransport Link and L3 Cache' in clause 5.10.1. [b-OCP HSCH] provides memory reliability as 'Memory Correctable ECC: The threshold value is 1000. When the threshold is reached, the BIOS logs the event and includes the physical DIMM location.' in clause 8.5.10. [b-OCP IMBH] provides memory reliability as 'DDR3 direct attached memory support on cpu0 and cpu1 with: 4 channel DDR3 registered memory interface on processors 0 and 1; 2 DDR3 slots per channel per processor (total of 16 DIMMs on the motherboard); RDIMM/LV‑RDIMM (1.5V/1.35V), LRDIMM and ECC UDIMM/LV-UDIMM(1.5V/1.35V); Single, dual and quad rank DIMMs ; DDR3 speeds of 800/1066/1333/1600 MHz; Up to maximum 512 GB memory with 32GB RDIMM DIMMs' in clause4.3. [b-OCP IMBH] provides memory reliability as 'CPU/Memory errors: Both correctable ECC and un-correctable ECC errors should be logged into the event log. Error categories include DRAM, Link and L3 cache' in clause 5.9.1. [b-OCP IMBH] provides memory reliability as 'Memory Correctable ECC: The threshold value is 1000. When the threshold is reached, the BIOS should log the event including DIMM location information and output DIMM location code through the debug card' in clause 5.9.2.
8	Supporting various types of memory	[b-OCP 2S] provides supporting of various types of memory as 'Besides traditional DDR4 DIMM, the motherboard shall support Non-Volatile DIMM (NVDIMM) on all DIMM slots' in clause 5.3.3. [b-OCP AMBH] provides supporting of various types of memory as 'DDR3 direct attached memory support on cpu0 and cpu1 with: o 4 channels DDR3 registered memory interface on each CPU; 2 DDR3 slots per channel per processor (total of 16 DIMMs on the motherboard); RDIMM/LV-RDIMM (1.35V/1.25V), LRDIMM and UDIMM/LV-UDIMM (1.35V/1.25V); SR, DR and QR DIMMs; DDR3 speeds of 800/1066/1333/1600; Up to maximum 512GB memory with 32GB RDIMMs' in clause 4.3. [b-OCP HSAS] provides supporting of various types of memory as 'DIMM Type: RDIMM DDR4, LRDIMM 3DS DDR4, LRDIMM DDR4' in clause 8. [b-OCP IMBH] provides Supporting various types of memory as 'DDR3 direct attached memory support on cpu0 and cpu1 with: 4channel DDR3 registered memory interface on processors 0 and 1; 2 DDR3 slots per channel per processor (total of 16 DIMMs on the motherboard); RDIMM/LV-RDIMM (1.5V/1.35V), LRDIMM and ECC UDIMM/LV-UDIMM(1.5V/1.35V); Single, dual and quad rank DIMMs ; DDR3 speeds of 800/1066/1333/1600 MHz; Up to maximum 512 GB memory with 32GB RDIMM DIMMs' in clause 4.3. [b-OCP OAPM] provides supporting of various types of memory as 'DIMM Type Double data rate fourth generation (DDR4) Registered DIMM (RDIMM) with Error-Correcting Code (ECC)' in clause 5. [b-OCP MB] provides supporting of various types of memory as 'The motherboard has DIMM subsystem designed as below: DDR4 direct attach memory support on CPU0 and CPU1; 4x channels DDR4 registered memory interface on each CPU; 2x DDR4 slots per channel (total 16 DIMM); Support RDIMM, LRDIMM; Support SR, DR and QR DIMM; Support DDR4 speeds of 1600/1866/2133; Up to maximum 1024 GB with 64GB DIMMs; Follow updated JEDEC DDR4 specification with 288 pin DIMM socket' in clause 5.3.2.
9	Multiple interfaces for storage	[b-OCP 1S] provides multiple interfaces for storage as 'The Twin Lakes 1S server implements primary and extension x16 PCIe edge connectors as defined in the 1S server specification. The primary x16 PCIe edge connector supports: • PCIe Gen3 ports • A 10GBase-KR • A SATA port • A USB 2.0 port • A Universal Asynchronous Receiver/Transmitter (UART)' in clause 3. [b-OCP 1S] provides multiple interfaces for storage as 'The Twin Lakes 1S server supports three on-card Solid State Drives (SSDs) in the 2280 or 22110 M.2 form factor' in clause 3. [b-OCP 1S] provides multiple interfaces for storage as 'The Twin Lakes 1S server supports three M.2 solid-state drives in 2280 or 22110 form factors. Boot M.2 slot is only available in 2280 form factor and it can be configured as either SATA or PCIe interface through BOM options, but not both. A minimum 256GB M.2 SATA or NVMe SSD is required as a boot device and for logging purpose. Two additional SSD drives are designed in to support applications that require high disk performance. These two M.2 slots only support PCIe X4 links but both support SSD drives in 2280 or 22110 form factors' in clause 9.4. [b-OCP 2S] provides multiple interfaces for storage as 'Following internal connectors should be placed as close as possible to front of the board in order to have easy front access: 1x vertical combo SATA signal and power connector; 1x 14-pin Debug card header; 1X right angle USB3 Type A connector; 1X SMD switch to enable/disable Intel Intel At Scale Debug; 1x M.2 connector with 2280 and 22110 support; 1x RJ45; 1x USB type C; 1X customized VGA connector' in clause 5.2. [b-OCP 2S] provides multiple interfaces for storage as 'The motherboard uses Intel PCH chipset, which supports following features: 4x USB 3.0/2.0 ports: one type A for front connector; one type C for front connector; one for BMC in-band firmware update; one to X32 riser connector; 1x M.2 connector; 1x individual SATA 6Gps port; 1x miniSAS HD x8 port or 1x miniSAS HD x4 port; 1x PCIe x4 ports to M.2 connector, colayout with SATA port to M.2 connector; SPI interface, mux with BMC to enable BMC the capability to perform BIOS upgrade and recovery; SPI interface for TPM header' in clause5.4. [b-OCP 2S] provides multiple interfaces for storage as 'The motherboard has Intel PCH on board. Intel PCH has a SATA controller support 8x SATA3 ports and an sSATA controller support 6x SATA3 ports' in clause 11.6. [b-OCP AMBH] provides multiple interfaces for storage as 'PCI-E x16 Slot/Riser Card; PCI-E Mezzanine Card; PCI-E External Connector; SATA' in clauses 10.1,10.2,10.3, 10.7. [b-OCP BS] provides multiple interfaces for storage as 'PCIe Expansion Slot; SATA hot-plug drives' in clause 2, Table 2-1. [b-OCP DSBS] provides multiple interfaces for storage as 'Storage: Two single port AHCI SATA connectors capable of supporting up to 6 Gb/sec; Two SCU 4-port mini-SAS connectors capable of supporting up to 3 Gb/sec SATA/SAS; Two 4-port mini HD connectors capable of supporting up to 6 Gb/sec SATA' and 'Support for PCI Express* 225W/300W High Power Card Electromechanical Specification 1.0' in clause 4, Tables 1 and 2. [b-OCP G1] provides multiple interfaces for storage as '15x 12Gb/s SAS or 6Gb/s SATA 2.5' drive slots, up to 15mm thickness, connected via SEB, to an onboard HBA. One M.2 SATA slot, also on board.' and '1 x 16 Gen3 FH/FL, 2 x8 Gen3 LP/HL, 1 x8 OCP Mez with front Panel access, 1 x8 PCIe OCP Mez in a non-front-accessible internal slot to support SAS HBA or Raid-on-Chip with SuperCap' in clause 6.1. [b-OCP HSAS] provides multiple interfaces for storage as '▪ Intel C612 Controller;▪ (2) discrete SATA 7pin for SATA4 and SATA5;▪ (2) MiniSAS SFF-8087 for SATA0-SATA3, sSATA0-sSATA3;▪ 6.0Gb/s speed;▪ SATA SGPIO supported;▪ RAID 0/1/10/5 (Intel RST);▪ (4) Internal MiniSASHD SFF-8643 connectors (Optional)' in clause 8. [b-OCP HSCH] provides multiple interfaces for storage as 'The SATA connections are a minimum of SATA2.0 (3Gb/s) and may be SATA3.0 (6Gb/s). The PCIe connection is a minimum of PCIe 2.0 and may be PCIe 3.0' in clauses 6.4 and 6.5. [b-OCP OAPM] provides multiple interfaces for storage as 'SATA, and PCI-Express Expansion' in clause 5. [b-OCP MB] provides multiple interfaces for storage as 'The motherboard uses Intel C610 series chipset, which supports following features: 3x USB 3.0/2.0 ports: one for front connector; one for optional vertical on board connector; one for BMC in-band firmware update; 1x mSATA connector from SATA port 4 co-layout with M.2 connector; 1x individual SATA 6Gps ports from SATA port 5; 1x miniSAS port from SATA port 0/1/2/3, 1x miniSAS port from sSATA0/1/2/3; 1x PCIe x4 ports to M.2 connector; SPI interface, connect to BMC to enable BMC the capability to perform BIOS upgrade and recovery; SMBUS interface (master and slave); Intel Server Platform Services (SPS) 3.0 Firmware with Intel Node Manager' in clause 5.4.
10	Storage replacement	[b-OCP 1S] provides storage replacement as 'The carrier assembly includes 2x ejectors which are used for card injection/ejection into the PCIe connectors' in clause 5.1. [b-OCP 1S] provides storage replacement as 'The Twin Lakes 1S server supports three M.2 solid-state drives in 2280 or 22110 form factors. Boot M.2 slot is only available in 2280 form factor and it can be configured as either SATA or PCIe interface through BOM options, but not both. A minimum 256GB M.2 SATA or NVMe SSD is required as a boot device and for logging purpose. Two additional SSD drives are designed in to support applications that require high disk performance. These two M.2 slots only support PCIe X4 links but both support SSD drives in 2280 or 22110 form factors' in clause9.4. [b-OCP 2S] provides storage replacement as 'The motherboard uses Intel PCH chipset, which supports following features: 4x USB 3.0/2.0 ports: one type A for front connector; one type C for front connector; one for BMC in-band firmware update; one to X32 riser connector; 1x M.2 connector; 1x individual SATA 6Gps port; 1x miniSAS HD x8 port or 1x miniSAS HD x4 port; 1x PCIe x4 ports to M.2 connector, colayout with SATA port to M.2 connector; SPI interface, mux with BMC to enable BMC the capability to perform BIOS upgrade and recovery; SPI interface for TPM header' in clause5.4. [b-OCP AMBH] provides storage replacement as 'PCI-E x16 Slot/Riser Card; PCI-E Mezzanine Card; PCI-E External Connector; SATA' in clauses 10.1,10.2,10.3 and 10.7. [b-OCP BS] provides storage replacement as 'PCIe Expansion Slot; SATA hot-plug drives' in clause 2, Table 2-1. [b-OCP DSBS] provides storage replacement as 'Storage: Two single port AHCI SATA connectors capable of supporting up to 6 Gb/sec; Two SCU 4-port mini-SAS connectors capable of supporting up to 3 Gb/sec SATA/SAS; Two 4-port mini HD connectors capable of supporting up to 6 Gb/sec SATA' and 'Support for PCI Express* 225W/300W High Power Card Electromechanical Specification 1.0' in clause 4, Tables 1 and 2. [b-OCP HSAS] provides storage replacement as '▪ Intel C612 Controller;▪ (2) discrete SATA 7pin for SATA4 and SATA5;▪ (2) MiniSAS SFF-8087 for SATA0~SATA3, sSATA0~sSATA3;▪ 6.0Gb/s speed;▪ SATA SGPIO supported;▪ RAID 0/1/10/5 (Intel RST);▪ (4) Internal MiniSASHD SFF-8643 connectors (Optional)' in clause 8. [b-OCP HSCH] provides storage replacement as 'The BIOS is tuned to minimize card power consumption. It has the following features: • Unused devices are disabled including PCIe* lanes, USB ports, SATA/SAS ports, etc;• BIOS setup menu;• SOC settings are provided to allow tuning to achieve the optimal combination of performance and power consumption' in clause 8.5.2. [b-OCP MB] provides storage replacement as 'The motherboard uses Intel C610 series chipset, which supports following features: 3x USB 3.0/2.0 ports: one for front connector; one for optional vertical onboard connector; one for BMC in-band firmware update; 1x mSATA connector from SATA port 4 co-layout with M.2 connector; 1x individual SATA 6Gps ports from SATA port 5; 1x miniSAS port from SATA port 0/1/2/3, 1x miniSAS port from sSATA0/1/2/3; 1x PCIe x4 ports to M.2 connector; SPI interface, connect to BMC to enable BMC the capability to perform BIOS upgrade and recovery; SMBUS interface (master and slave); Intel Server Platform Services (SPS) 3.0 Firmware with Intel Node Manager' in clause 5.4.
11	Storage redundancy hardware	[b-OCP HSAS] provides storage redundancy hardware as 'Storage: RAID 0/1/10/5 (Intel RST)' in clause 8. [b-OCP SJ] provides Storage redundancy hardware as 'SATA RAID KEY: 1x4' in clause 6.12.
12	Storage hibernation	[b-OCP 2S] provides storage hibernation as 'Disable any unused devices, such as unused PCI, PCIe ports, USB ports, SATA/SAS ports, clock generator and buffer ports' in clause 6.3.1. [b-OCP HSCH] provides storage hibernation as 'The BIOS is tuned to minimize card power consumption. It has the following features: • Unused devices are disabled including PCIe* lanes, USB ports, SATA/SAS ports, etc.; • BIOS setup menu; • SOC settings are provided to allow tuning to achieve the optimal combination of performance and power consumption' in clause 8.5.2. [b-OCP MB] provides storage hibernation as 'The BIOS should be tuned to minimize system power consumption and maximize performance. This includes: Disable any unused devices, such as unused PCI, PCIe ports, USB ports, SATA/SAS ports, clock generator and buffer ports. Tuning CPU/Chipset settings to reach minimized power consumption and best performance in a data centre environment' in clause 6.3.1.
13	Hardware-assisted I/O virtualization	[b-OCP OBIOS] describes how Intel Virtualization Technology (Intel VT) must be supported via platform BIOS policy variable, in clause 4.8.
14	I/O devices direct accessing	[b-OCP 25GDual] describes how QL41202 shall support single root I/O virtualization (SR-IOV), in clause .12.
15	Workload offload	[b-OCP 25GDual] describes how QL41202 shall support offload traffic types RDMA over Converged Ethernet (RoCE) on each of the ports and also support Internet wide area RDMA protocol (iWARP), in clause 12.
16	Hardware acceleration	[b-OCP OBIOS] describes key features for WCS Intel Xeon Scalable Platform, support 2 GP-GPU+1 PCIe card in 2U, in clause 2.2. [b-OCP BS] describes QCT Grantley platform will be 16 DIMMs and support 8 GPGPU cards and Max. 8x 2.5"HDDs' in clause 1.
17	Power supply replacement	[b-OCP OCSSSD] describes how OCS v2.0 servers shall support drives with volatile write caches by leveraging the server backup power supply in clause 11.3 Power-Loss Protection. [b-OCP OCTAM] Indicates that when PSU ALERT# signal occurs, the Olympus PSU has transitioned its power source from AC to battery backup, in clause 7.4.
18	Supporting power redundancy	[b-ETSI EVE007] provide power redundancy as 'Power supply redundancy may be achieved by installing more than one power supply unit' in clause 5.3.3.2. [b-OCP 1S] require platform designers to provide adequate power and cooling to properly handle the SoC's power and thermal requirements, in clause 3 overview. [b-OCP 1S] require Twin Lakes 1S Server to provide a standby 3.3V\_AUX power rail on the card to power the Bridge IC at all power states, in clause 8.1.2. [b-OCP HSAS] describe that the Hyve Solutions Ambient Series-E servers support single or redundant power supply, in clause 11.
19	Minimum energy consumption	[b-ETSI EVE007] provides minimum energy consumption as 'different forms of processors would be utilized for different types of services to improve power efficiency' in clause 5.2. [b-OCP 1S] describes that the Twin Lakes 1S server recommend a power-capping implementation to reduce the server's power consumption (cut off power in certain time) in clause 8.4. [b-OCP OAPM] describe that the motherboard supports Emergency Power Reduction mechanism (PWRBRK#) for the x16 PCIe slots in clause 7.5. [b-OCP OCTAM] describes how the motherboard supports Emergency Power Reduction mechanism (PWRBRK#) for the x16 and x32PCIe slots in clause 7.5. [b-OCP OMB] describes how the motherboard supports Emergency Power Reduction mechanism (PWRBRK#) for the x16 PCIe slots in clause 6.5, the main purpose is to provide a power reduction mechanism for GPGPU cards as part of the throttle and power capping strategy. [b-OCP HSCH] describes how the BIOS is tuned to minimize card power consumption. It has the following features: • Unused devices are disabled including PCIe* lanes, USB ports, SATA/SAS ports, etc.; • BIOS setup menu; • SOC settings are provided to allow tuning to achieve the optimal combination of performance and power consumption' in clause 8.5.2. [b-OCP HSCH] describes how each card must provide temperature sensors for the SOC, the SO-DIMM(s) (if they are used) and one ambient temperature sensor. All temperature readings for each sensor must be readable via the management sideband interface to the baseboard. Additionally, over-temperature thresholds are configurable and an alert mechanism is provided to enable thermal shutdown and/or an increase in airflow. The sensors are accurate to +/−3C' in clause 5.4.
20	Interface for monitoring power	[b-ETSI EVE007] provides interface for monitoring power as 'Each power supply unit should be capable of measuring and remotely reporting the following operational parameters' in clause 5.3.4.2. [b-OCP 1S] describes how the Twin Lakes 1S server shall uses power sensor to measure Card and SoC power consumption. The power data can be used by the platform for power management purposes. The Twin Lakes 1S server supports an Advanced Configuration Power Interface (ACPI)-compliant power button and reset signals from the platform, in clause 3 overview and clause 6.5. [b-OCP AMBH] describes how to use BMC to monitor power in clause 7.2 and use PMBUS interface to enable the BMC to report server input power in clause 8.6. [b-OCP DSBS] describes how Decathlete Server Board shall support power supply redundancy monitoring and support in clause 8.1.2. [b-OCP TP] requires vendors to implement BMC firmware to support remote system power on/off/cycle and warm reboot through In-Band or Out-of-Band IPMI commands in clause 8.4 and support platform power monitoring in clause 8.8.
21	Cooling component replacement	[b-OCP 2S] describes that if and only if one rotor in server fan fails, the negative or positive DC pressurization can be considered in the thermal solution in the hot aisle or in cold aisle respectively in clause10.2.4.
22	Cooling component redundancy	[b-OCP 2S] provides a description of fan redundancy which is one implementation of cooling redundancy – as 'the server fans at N+1 redundancy should be sufficient for cooling server components to temperatures below their maximum spec to prevent server shut down or to prevent either CPU or memory throttling' in clause 10.2.5. [b-OCP O1USM] requires fans to be N+2 redundant to optimize fan efficiency and server availability while eliminating the need for hot swap capability in clause 4.4. [b-OCP O2USM] requires fans to be N+2 redundant to optimize fan efficiency and server availability while eliminating the need for hot swap capability in clause 4.4. [b-OCP TP] describe how server fans should be N+1 redundancy to be sufficient for cooling server components to temperatures below their maximum spec to prevent server shut down or to prevent either CPU or memory throttling in clause 9.2.5. [b-ETSI EVE007] provides Cooling component redundancy as 'Redundancy within the rack cooling system shall provide appropriate levels of cooling to all the rack equipment while the rack cooling system is serviced' in clause 5.5.3.
23	Interface for controlling fan speed	[b-OCP 2S] requires vendors to enable fan speed control (FSC) on BMC. The FSC algorithm processes sensor data and drives two PWM outputs to optimized speed, in clause 9.12. [b-OCP AMBH] requires ODM to provide system access interface to retrieve hardware sensor readings and control fan speed, in clause 6. [b-OCP DSBS] describes how Decathlete Server Board shall support ACPI to control power and fan speed in clause 8.2. [b-OCP_SFCI] describes how server management controller like BMC use standard IPMI commands to manage SFC in whole document. [b-OCP OCSPS] describes that the PSU shall adjust internal fan speed based upon internal temperature sensor(s) in clause 4.3. [b-OCP TP] requires vendors to enable FSC on the BMC in clause8.12.
24	Monitoring status of physical machine	[b-OCP 1S] provides monitoring status set as 'There is also a blinking amber heartbeat LED on the Twin Lakes 1S server to indicate that the Bridge IC is in operating mode' in clause 9.8. [b-OCP 2S] provides system state monitor set as 'There are 4 states of Power/system identification LED depending on system power state and chassis identify status' in clause 9.6. [b-OCP Yose] provides monitor status set as 'On the Adapter Card of a Yosemite V2 sled, there is a power button, a reset button, an OCP debug card and a USB port attached to the current selected 1S server. There are four blue LEDs placed on the baseboard in the same order as 1S server slots to indicate server status' in clause 9.4. [b-OCP O1USM] provides visual indication set as 'A 3D mechanical drawing of the Front Panel is shown in Figure 2. The Front Panel supports the following mechanical features. Status LEDs o UID, Attention, Power Status' in clause 4.1.
25	Visual indications	[b-OCP JBOG] provides system event log (SEL) set as 'The BMC needs to support SEL capabilities. The following items are to be logged in the SEL' in clause 7.1. [b-OCP SJ] provides silk screen colour set as 'The colour of silk screen is white and the labels for the components are listed as below' in clause13.4. [b-OCP Yose] provides visual feedback set as 'The LED associated with the active 1S server blinks as visual feedback to the user. When a BMC is selected, all four LEDs blink as visual feedback to the user' in clause 9.4.1. [b-OCP OAPM] provides visual indication set as 'The motherboard supports a blue UID (unit ID) LED used to help visually locate a specific server within a data centre' in clause 6.11.1.
26	Equipment for mounting and removal	[b-OCP 1S] provides easy to remove set as 'The air baffle must be easy to service with the goal of requiring no tooling to remove' in clause 6.6. [b-OCP 2S] provides removal set as 'It is installed on a sheet metal panel with tool-less install and removal' in clause 12.2.5. [b-OCP IMBH] provides mounting and removal set as 'In order to remove and install one board without affecting the other board, the following internal connectors are placed as close as possible to front of the board in order to have easy frontal access' in clause 4.2 and "The PCIe* x4 connector can be hot inserted and removed" in clause10.2.
27	Circulation of air flow	[b-OCP 1S] provides air flow set as 'The card level air baffle must be designed to help maintain temperatures of all major components on the server card by reducing bypass air and increasing airflow through key components' in clause 6.6. [b-OCP 2S] provides airflow set as 'The unit of airflow (or volumetric flow) used for this spec is CFM (cubic feet per minute). The maximum allowable airflow per watt in the system must be 0.107' in clause10.2.26. [b-OCP JBOG] provides system airflow set as 'The unit of airflow (or volumetric flow) used for this spec is CFM (cubic feet per minute). The maximum allowable airflow per watt in the system must be 0.14 at sea level' in clause 8.2.3. [b-OCP SJ] provides cooling set as 'To meet thermal reliability requirement, the thermal and cooling solution should dissipate heat from the components when system operating at its maximum thermal power' in clause 11. [b-OCP Yose] provides airflow set as 'The unit of airflow (or volumetric flow) used for this spec is cubic feet per minute (CFM)' in clause 8.2.5.
28	Interconnect network supports	[b-ETSI EVE007] provide interconnect network supports as 'support links of types other than Ethernet' in clause 5.4.2. [b-OCP 1S] provides interconnect set as 'When the SoC's integrated network controller is used as a shared NIC, its SMBus is routed to Connector A as the sideband interface' in clause 7.9.1. [b-OCP 2S] provides interconnect set as 'High speed mid-plane is mid-plane with power delivery, plus high speed interconnect on mid‑plane' in clause 12.3. [b-OCP JBOG] provides interconnect set as 'For JBOG with 8x GPUs in SXM2 form factor, it shall support NVLINK interconnection shown below' in clause 4.3.
29	Sharing process unit component	[b-OCP 2S] provides share SPI bus set as 'A secondary identical BIOS chip is designed in sharing the same SPI bus with multiplexedCS pin' in clause 6.1. [b-OCP OBIOS] provides share io set as 'ATA controllers running in native mode use their PCI interrupt for both channels and can share this interrupt with other devices in the system, like any other PCI device' in clause 7.3.1.2.
30	Network topology	[b-OCP OCSB] provides topology set as 'CPU-to-tray backplane mezzanine PCIe link topology' in clause 7.1.
31	Configuration of multiple processing units	[b-OCP 1S] provides configuration set as 'Set Bridge IC configuration' in clause 9.7.10, Table 6. [b-OCP 2S] provides configuration set as 'Vendor should provide utility under CentOS to perform VR configuration change. Configuration change should take effect without AC cycling node' in clause 15.3.4. [b-OCP OBIOS] provides multi process configuration set as 'The Intel Xeon Scalable processor is implemented with 1 or more cores with each core capable of supporting Intel HT Technology. The result is multiple logical processors in a physical package' in clause 4.13.
32	Providing running information	[b-OCP 1S] provides temperature and power sensors set as 'Each card must provide following sensors: Temperature sensors for SOC, DIMM, voltage regulators and other critical chips' in clause 6.5. [b-OCP 2S] provides running monitor set as 'The vendor should implement BMC FW to support thermal monitoring, including processor, memory, chipset, VRs, PCIe card, Mezzanine cards, Inlet/outlet air temperature and airflow sensor' in clause 9.8. [b-OCP AMBH] provides memory reliability as 'Hardware health monitoring display' in clause 5.5. [b-OCP JBOG] provides monitor set as 'The BMC implemented is to have access to all analog sensors placed in the system and ensure that they are displayed in a sensor data record repository' in clause7.9.1.1. [b-OCP Yose] provides monitor set as 'During the entire hot-service process, the BMC shall monitor the thermal condition closely' in clause 5.2. [b-OCP AMBH] provides monitor set as 'The BMC can be used to monitor hardware and control fan speed' in clause 6. [b-OCP OBIOS] provides multi process configuration set as 'BIOS requirements for Intel NM enabled firmwareNM5 BIOS should implement processor utilization notifications support in ACPI tables' in clause 9.2.2.
33	Automatically power operation	[b-OCP 1S] provides power operation set as 'The Twin Lakes 1S server can throttle itself down to lowest possible power state as quickly as possible when the platform asserts the `FAST_THROTTLE_N` signal or it receives request from BMC, or over power event reported by on-card power monitor' in clause 8.4, and 'The BMC controls power on, off and reset directly via the signals defined in the pin-out' in clause 9.7.13. [b-OCP 2S] provides auto power on set as 'Motherboard should be set to restore last power state during AC on/off. This means that, when AC does on/off cycle, motherboard should power on automatically without requiring power button' in clause 15.9. [b-OCP JBOG] provides power operation set as 'Support power on policy to be last-state, always-on and always-off upon recovery from an AC power loss event. T' in clause 7.7. [b-OCP Yose] provides auto power set as 'Now the user can replace the failed unit with a new one, BMC would automatically resume power and boot the new card' in clause 5.2. [b-OCP OBIOS] provides power controller set as 'The following actions are available on expiration of the Watchdog Timer: • System Reset• System Power Off• System Power Cycle• Pre-timeout Interrupt (OPTIONAL)' in clause 9.2.2.
34	Monitoring environment condition
35	Self-checking mechanism	[b-OCP 2S] provides get selftest result set as 'Get Selftest Results (0x04) in clause 9.13. [b-OCP TP] provides selftest set as 'During system boot-up, POST (Power-On-SelfTest) codes will be send to port 80 and decoded by the BMC to drive the LED display as described in section 8.5. P' in clause8.2. [b-OCP OBIOS] provides selftest set as 'Built-In Self-Test (BIST) The `BIST_ENABLE` can be controlled by a BMC, GPO, strap or other mechanism. BIOS shall implement a platform policy to control BIST execution' in clause 4.12.
36	Provide I/O interface to administrator	[b-OCP 1S] provides 'The primary x16 PCIe edge connector supports: USB 2.0 port' in clause 3. [b-OCP 2S] provides 'support of GUI and KVM on hardware level to accommodate the OCP customers whose environment requires using of VGA and KVM' in clause 9.3. [b-OCP SJ] provides 'USB and VGA' in clause 4.2. [b-OCP Yose] provides 'supports a VGA interface' in clause 9.5. [b-OCP 1S] provides keyboard interface as 'Bridge IC provides ways to transfer messages between them via KCS interfaces. For in-band management, the Bridge IC can forward the SoC's Keyboard Controller Style (KCS) request to the BMC' in clause 9.7.3. [b-OCP AMBH] provides USB interface as 'The motherboard has two external USB ports located in the front of the motherboard. The BIOS supports the following USB devices: Keyboard and mouse' in clause10.6. [b-OCP TP] provides USB interface as 'The motherboard has one external Type-A, right angle USB 2.0/3.0 port and one USB 3.0. Type-C port located in front of the motherboard. The BIOS should support the following USB devices: USB keyboard and mouse' in clause 10.5. [b-OCP Yose] provides VGA support as 'The Yosemite V2 Platform supports a VGA interface. The original SATA interface on 1S server interface has been repurposed to be a x1 PCIe link' in clause 9.5. [b-OCP DSBS] provides USB support as 'The server board SHALL provide two external USB ports and the BIOS SHALL support the following USB devices: Keyboard and mouse ,Bootable USB flash drive, Bootable USB hard disk, Bootable USB optical disk' in clause6.2.
37	Provide I/O interface to external storage device	[b-OCP 1S] provides interface to external storage as 'Boot M.2 slot is only available in 2280 form factor and it can be configured as either SATA or PCIe interface through BOM options' in clause 9.4. [b-OCP AMBH] provides SATA port as 'The motherboard has SP5100 interfaces on board, which support up to six SATA ports' in clause 10.7. [b-OCP TP] provides SATA port as 'SATA port 0~7 can be connected to one vertical mini-SAS HD 8 ports connector. sSATA ports 2~5 can be connected to one mini-SAS HD 4 ports connector' in clause 10.6. [b-OCP O2USM] provides SATA port as 'Supports up to 12 SATA devices' in clause 4. [b-OCP DSBS] provides SATA port as 'The server board SHALL have support up to six SATA ports' in clause 6.3.
38	Network interface virtualization	[b-OCP 25GDual] provides network virtualization as 'Support receive side scaling (RSS), single root I/O virtualization (SR-IOV), VLAN tagging, Layer 2 priority encoding, link aggregation and full-duplex flow control 802.3 functions in the MAC' in Table 1.
39	Device driver and API supports	[b-ETSI EVE007] provide device driver and API supports as 'the network interface should be configurable to service either a management or production network' in clause 5.6.2. [b-OCP 1S] provides device driver support as 'The Twin Lakes 1S server supports three M.2 solid-state drives in 2280 or 22110 form factors' in clause 3. [b-OCP 2S] provides device driver support as 'All data network and management network should have this capability. This includes, but not limit to: DHCP and static IP setting, PXE booting capability, NIC and BMC firmware support, OS driver and utility in both IPv4 and IPv6' in clause 11.4.3. [b-OCP AMBH] provides device driver support as 'The x4 connector can be hot inserted and removed. A PCI-E re-driver is used for PCI-E external links and supports a miniSAS cable up to 2 meters long' in clause 10.3. [b-OCP TP] provides device driver support as 'It is recommended that PCB is planned with three vendors at EVT. EVT and DVT build plan should cover all possible combinations of key components of DC-DC VR including output inductor, MOSFETs and driver' in clause 18.9.
40	Processing unit operation	[b-OCP 1S] provides power operation as 'server shall have the power monitoring capability to read power consumption reliably and accurately and can report a one-second average power reading with 3% accuracy' in clause 8.4. [b-OCP 2S] provides monitoring information as 'BMC should implement thermal monitoring feature for PCIe card on riser and Mezzanine card. BMC reads the temperature of key components of PCIe and Mezzanine cards through its SMBus ports in the format as TMP421 temperature sensor. BMC' in clause 9.18. [b-OCP AMBH] provides monitoring information as 'The ODM needs to provide a system access interface and application to retrieve hardware monitoring sensor readings, including at minimum, lm\_sensors, a Linux application for the CentOS operating system and its driver' in clause 6. [b-OCP AMBH] provides power operation as 'The motherboard includes a power switch, reset switch, power LED, HDD activity LED and beep error LED' in clause 10.9. [b-OCP Yose] provides monitoring information as 'The BMC firmware shall support platform power monitoring. The BMC firmware shall support thermal monitoring' in clause 6.13. [b-OCP DSBS] provides monitoring information as 'The management controller SHALL support the following IPMI features: Sensor device and sensor scanning/monitoring' in clause 8.11. [b-OCP NIC] provides monitoring information as 'When the temperature sensor reporting function is implemented, the OCP NIC 3.0 card shall support PLDM for Platform Monitoring and Control (DSP0248 1.1 compliant) for temperature reporting' in Table 49: Temperature Reporting Requirements.
41	Remote management	[b-ETSI EVE007] provide Remote management as 'The BMC/service processor shall be accessible remotely via Ethernet network' in clause5.6.2. [b-OCP 1S] provides remote BIOS update as 'The BIOS can be updated remotely under these scenarios' in clause 9.6.8. [b-OCP 2S] provides remote BIOS update as 'Vendors should provide tool(s) to implement remote BIOS update function' in clause 6.3.6. [b-OCP AMBH] provides remote BIOS firmware update as 'The motherboard has SP5100 interfaces on board, which support up to six SATA ports' in clause 7.6. [b-OCP AMBH] provides remote power control as 'The BMC supports remote system power on/off and reboot through LAN or IPMB' in clause 7.4. [b-OCP Yose] provides remote BMC firmware update as 'Vendors should provide tool(s) to implement a remote BMC firmware update, which will not require any physical input' in clause 6.17. [b-OCP DSBS] provides remote machine management as 'A Revision 1.0 Decathlete server board SHALL implement the requirements of the OCP Open Hardware Management Specification for Remote Machine Management (Version 0.93)' in clause 10.
42	Diagnostic of physical machine	[b-ETSI EVE007] provide diagnostic of physical machine as 'the rack power subsystem should provide a means to report power system fault events' in clause 5.3.2.3. [b-OCP 2S] provides error log as 'Error to be logged' in clause 9.11.1. [b-OCP AMBH] provides system log as 'The BIOS logs system events through the baseboard management controller (BMC)' in clause 5.10. [b-OCP Yose] provides event log as 'The vendor should implement the BMC to support storing events/logs from each 1S server base board, device carrier card and mezzanine card' in clause 6.15. [b-OCP DSBS] provides log as 'The Decathlete server board standard will define a minimal set of error handling and alerts. These features may become a section of this standard, or may be a standalone specification authored by the OCP Hardware Management project' in clause 9.
43	Expansion of interconnect network	[b-OCP Yose] provides network connectivity as 'The network controller vendors offer Network Interface Cards (NICs) that support multi-host functions. These multi-host NICs provide network connectivity to multiple servers through a PCIe interface' in clause 5.7.6. [b-OCP DSBS] provides network connectors as 'The server board SHALL have one LAN device to support the RJ-45 network interface connectors' in clause 6.1. [b-OCP NIC] provides network interconnect as 'NC-SI over RBT capable OCP NIC 3.0 cards shall use a unique Package ID per ASIC when multiple ASICs share the single NC-SI physical interconnect to ensure there are no addressing conflicts' in clause 4.8.1.
44	I/O interface for device extensions	[b-OCP OCSB] provides I/O interface for device extensions as 'High‑Speed Interface Topologies' in clause 7. [b-OCP 2S] provides I/O interface for device extensions as 'PCIe x32 Slot/Riser Card' in clause 11.1. [b-OCP JBOG] provides I/O interface for device extensions as '8 x16 PCIE Gen3 slots for GPU' in clause 4.1. [b-OCP HSAS] provides I/O interface for device extensions as 'PCIe Port Assignments' in clause 8. [b-OCP QGD] provides I/O interface for device extensions as 'PCIe expansion slot' in clause 2. [b-OCP DSBS] provides I/O interface for device extensions as 'The server board SHALL provide support for one riser card and MAY provide support for two riser cards. The riser card slots can be configured to meet any range of usage models' in clause 6.4.
45	Processing unit replacement	[b-OCP Yose] provides processing unit replacement as 'The USB connections from all 1S servers are connected to the BMC's virtual hub port through a USB multiplexer so that a user could upgrade the BMC firmware via a USB interface from a 1S server. This method is much faster than going through the OOB' in clause 5.2. [b-OCP NIC] provides processing unit replacement as 'A multi-host capable OCP NIC 3.0 card shall gracefully handle concurrent in-band queries from multiple hosts and out-of-band access from the BMC for firmware component versions, device model and device ID information' in clause 4.7.3. [b-OCP OCSB] provide processing unit replacement as 'Tray Backplane Interface' in clause 9.1. [b-OCP OCSTRAY] provide Processing unit replacement as 'The connector interfaces between the tray mezzanine card and the tray backplane use the Samtec SEARAY solution' in clause 2.
46	Adding processing units	[b-OCP OCSC] provide adding processing units as 'support trays that house up to 24 individual OCS blades' as clause 2. [b-OCP Yose] provide adding processing units as 'support multi-host functions' in clause 5.7.6.
47	Adding sub‑components of processing units	[b-OCP 2S] provide adding memory of processing units as '2x DDR4 slots per channel 'In clause 5.3.2. [b-OCP IMBH] provide adding sub-components of processing units as 'two PCIe* x4 external connectors on the motherboard' in clause 10.2. [b-OCP AMBH] provide adding sub-components of processing units as 'motherboard's I/O features' in clause 10.
48	Adding power supply	[b-OCP OCSC] provide adding power supply as 'PDU placement' in clause 3.1.3. [b-OCP AMBH] provide adding sub-components of processing units as 'The motherboard includes a full server management solution and supports interfaces to an integrated or a set of rear-access 12V Power Supply Units (PSUs)' in clause 3.
49	Adding cooling component	[b-OCP OCSC] provide adding cooling component as 'Fan tray (includes six 140 x 140 mm fans in parallel)' in clause 4.2. [b-OCP O2USM] provide adding cooling component as 'A maximum of six 40 mm fans may be used to cool the components in a single U, with a maximum of twelve 40 mm fans* in a 2U server configuration.' in clause 4.4.
50	No additional ports
51	Authorized access	[b-DMTF RFAPI] provide authorized access as support both 'Basic Authentication' and 'Redfish Session Login Authentication' in clause 9.2. [b-DMTF RFHI] provide authorized access as 'Opening a Redfish session on the Host Interface may be accomplished by use of any authorized Redfish credentials' in clause 9. [b-SNIA SF] provide authorized access as 'Implement TLS version 1.2 or greater' in clause 8.1.
52	Support fault location	[b-ETSI EVE007] provide fault location support as 'hardware with fast failure detection' in clause 5.11. [b-OCP 1S] provide fault location as 'these errors must include the date, time and location information so that failing components can be easily identified' in clause 9.6.10. [b-OCP 2S] provide fault location as 'A power failure detection circuit needs to be implemented to initiate 3x actions related to data transferring' in clause 5.3.3. [b-OCP 2S] provide fault location as 'All POST errors, which are detected by BIOS during POST, should be logged into Event Log' in clause 9.11.1. [b-OCP Yose] provide fault location as 'Fan failure errors should be logged if the fan speed reading is outside expected ranges between the lower and upper critical thresholds. The Error log should also identify which fan fails' in clause 6.15.1.7.
53	Hot-plug support	[b-ETSI EVE007] provide hot-plug support as 'Supporting hot-plug for vulnerable components, including hard drive and optical modules' in clause 5.11. [b-OCP OCSPS] provide hot-plug support as 'The power supply shall be hot pluggable' in clause 1. [b-OCP OCSB] provide hot-plug support as 'The blade contains a NIC mezzanine card to provide small form-factor pluggable (SFP+) and Quad SFP (QSFP+) cable connectivity' in clause 7.2. [b-OCP 2S] provide hot-plug support as 'the x32 PCIe in riser slot shall support Standard PCIe signal hot swap' in clause 5.5.2. [b-OCP TP] provide hot-plug support as 'PCIe Hot Plug' in clause5.5.1.

Appendix II

Use cases of the physical machine for cloud computing

(This appendix does not form an integral part of this Recommendation.)

This appendix describes physical machine related use cases.

Table II.1 — Providing IaaS service with processing resource – use case

Title	Providing IaaS service with processing resource use case
Description	Infrastructure capabilities type, especially for providing VM, which is resided on a physical machine. The virtual machine provides a virtualized and isolated computing environment for each guest operating system (OS) with processing, storage, networking and other hardware resources. Usually a physical machine would carry more than one virtual machine and needs to provide more virtual CPU than physical CPU, so as the memory and I/O devices. Furthermore, the physical machine usually provides a management function for the CSP to manage and monitor the physical machines. The loading information would help the CSP to select which host to deploy the VMs and the fault location information could help the CSP easily replace the failure component. As more applications run in one physical machine, the reliability is required so that it could continue to run and bear the services without migrating when there are few failures. As some applications may require some other hardware components with special features, the physical machine would have to reserve one or more extended interfaces for adding cloud resources. To improve the VM's performance, the physical machines usually use CPUs with virtualization instruction set support. For situations with a lot of network traffic processing, physical machines can offload traffic processing to I/O devices to improve performance and reduce the load of CPUs.
Roles/sub-roles	CSP: cloud service operations manager
Figure
Pre-conditions (optional)	The virtual machine resides on the physical machine.
Post-conditions (optional)	CSP:cloud service operations manager wants to build or expand a resource pool to provide VM service.
Derived requirements	Virtualization instruction set (see clause 7.1.1.1) Hardware-assisted I/O virtualization (see clause 7.1.1.4) Hardware-assisted memory virtualization (see clause 7.1.1.2) Supporting various types of memory (see clause 7.1.1.2) Network interface virtualization (see clause 7.2) Provide I/O interface to administrator (see clause 7.2) Provide I/O interface to external storage device (see clause 7.2) I/O devices direct accessing (see clause 7.1.1.4) Monitoring status of physical machine (see clause 7.1.4) Automatically power operation(see clause 7.1.6) Processing unit operation (see clause 7.3) Remote management (see clause 7.3) Support fault location (see clause 7.6) Hot-plug support (see clause 7.6) Workload offload (see clause 7.1.1.4) Hardware acceleration (see clause 7.1.1.4) Interface for monitoring power (see clause 7.1.2)

Table II.2 — Preparing a physical machine – use case

Title	Preparing a physical machine
Description	A cloud service operations manager installs multiple processing units on the backplane of an enclosure to increase the computing resources of a physical machine. He or she also installs more than one storage device per CPU in a processing unit through standard storage interfaces. To connect all multiple processing units together, a cloud service operations manager mounts a switch device which is responsible for system interconnects and network topology to the backplane of the enclosure. In addition, the enclosure is equipped with a power supply to provide power to an entire physical machine and a cooling device to reduce heating. A cloud service operations manager should be able to check whether each device is installed in a physical machine correctly through a console panel on the enclosure. System software and operating systems are installed on corresponding devices or rebooted and consequently a physical machine completes to set up its operations. Based on the above steps to construct a physical machine, several physical machines are connected with each other by their external interfaces and can be installed in a standard rack.
Roles/sub-roles	CSP: cloud service operations manager.
Figure
Pre-conditions (optional)	CSP: cloud service operations manager wants to modify or expand the resources in a physical machine.
Post-conditions (optional)	A physical machine provides a cloud service.
Derived requirements	Hot-plug support (see clause 7.6) Configuration of multiple processing units (see clause 7.1.5) Monitoring status of physical machine (see clause 7.1.4)

Table II.3 — Cold data storage resource – use case

Title	Cold data storage resource use case
Description	Cold data means data that is stored but almost never read again. The cloud storage service for cold data provides almost no limit storage capacity at a very low cost and the physical machine for cold data storage requires the highest capacity and the lowest cost. The typical use case is a series of sequential writes, but random reads. As the physical machine is recommended to provide as much storage capacity as possible, it would have many large-capacity disks. To provide a highly durable storage service, the physical machine is recommended to provide management function for the CSP to manage and monitor the physical machine cluster and then the CSP can rebuild the data in time when some failures happen, also the hot plug function is needed. Physical machines usually support storage of different media to balance between cost and performance for different situations.
Roles/sub-roles	CSP: cloud service operations manager
Figure
Pre-conditions (optional)	The cloud storage service resides on the physical machine.
Post-conditions (optional)	CSP:cloud service operations manager wants to build or expand a resource pool to provide cloud storage service for cold data.
Derived requirements	Hot-plug support (see clause 7.6) Low power consumption of CPU (see clause 7.1.1.1) Supporting various types of memory (see clause 7.1.1.2) Provide I/O interface to administrator (see clause 7.2) Provide I/O interface to external storage device (see clause 7.2) Storage hibernation (see clause 7.1.1.3 ) Remote management (see clause 7.3) Diagnostic of physical machine (see clause 7.3) Multiple interfaces for storage (see clause 7.1.1.3) I/O interface for device extensions

Table II.4 — Using an interconnect network for high-performance service – use case

Title	Using interconnect network for high-performance service
Description	When a cloud service user requests a high performance computing service (e.g., parallel processing, Big data processing, etc.), a cloud service operations manager is responsible for setting up an interconnection network among processing units, because multiple computing resources are required to perform such a service. Ethernet is a widely used protocol for the interconnection network but the cloud service operations manager may provide other protocols. Therefore, depending on the protocols, the performance of the interconnect network is determined and the cloud service operations manager can select and provide the appropriate interconnect network to the cloud service user. For utilizing this interconnect network system, a cloud service user can employ socket based applications in the case of using Ethernet protocol. For other networks, a cloud service user is provided with applications per application program interfaces (API) from a cloud service operations manager. This is due to the fact that, a cloud operations manager also has a responsibility to provide a device driver and API for utilizing the propriety network. Occasionally, a cloud service user may request multiple physical machines for such a service. In this case, a cloud operations manager has a responsibility to support multiple shared resources through the network. Since the physical machines are independent of network devices, this network would be arranged as cabling in an interconnect network. When a cloud service operations manager makes this cabled network, it is constructed to support various topologies (e.g., ring, mesh, tree) to meet the different performance levels of the service requested from a cloud service user.
Roles/sub-roles	CSC: Cloud service user and CSP: Cloud service operations manager
Figure
Pre-conditions (optional)	CSC: Cloud service user wants to use a high performance computing application.
Post-conditions (optional)	Physical machines can run a high performance computing application through a system interconnect network and cabled network.
Derived requirements	Sharing process unit component (see clause 7.1.5) Interconnect network supports (see clause 7.1.5) Device driver and API supports (see clause 7.2) Expansion of interconnect network (see clause 7.4) Network topology (see clause 7.1.5)

Table II.5 — Physical machine for hyper-scale deployment – use case

Title	Physical machine for hyper-scale deployment
Description	This use case covers the situation where very large numbers of physical machines will be employed in multiple data centres around a region or around the world. In this case, a single physical machine will typically be implemented as a server blade that fits into a specially built rack. The rack will typically also include storage, management and networking equipment, which might or might not be implemented using similar blades.
Roles/sub-roles	CSP: cloud service operations manager.
Figure	In this type of deployment, physical machines are constructed for deployment in high-density racks specifically designed for the purpose. Each rack provides all the infrastructure required to support the machines, including power, network connectivity and ventilation/cooling. Individual physical machines are automatically initialised and provisioned with necessary software when plugged into an active rack. Once running, each machine is made available for the deployment of VMs or other functions requested by CSCs or CSP administrators. Fault tolerance is often provided by software across multiple machines, so an individual machine can fail without adverse effect on the overall system.
Pre-conditions (optional)	CSP: The CSP wishes to deploy many physical machines in two or more locations, using minimal staffing.
Post-conditions (optional)	A physical machine is plugged into a rack, configures itself to the local network and is automatically provisioned with all necessary software including the host operating system, network stacks and hypervisor. The data centre management system is then able to deploy workloads to the machine. In the event of failure, the machine can be removed from the rack and a replacement plugged in with minimal impact on deployed cloud services. A data centre can be left unmanned for several days or weeks at a time. When visited, the failed machines can be quickly removed and replaced by new or refurbished machines, which configure and provision themselves automatically.
Derived requirements	Minimum energy consumption (see clause 7.1.2) No additional ports (see clause 7.5) Authorized access (see clause 7.5) Hot-plug support (see clause 7.6) Visual indications (see clause 7.1.4)

Table II.6 — Physical machine for unmanned deployment – use case

Title	Physical machine for unmanned deployment
Description	This use case covers the situation where physical machines will be in places where physical access is extremely difficult or only available at infrequent intervals. In this case, a single physical machine will typically be implemented as a server blade that fits into a specially built rack. The rack will typically also include storage, management and networking equipment, which might or might not be implemented using similar blades.
Roles/sub-roles	CSP: cloud service operations manager.
Figure	In this type of deployment, physical machines are constructed for deployment in locations where physical access is very tightly constrained. These will typically be inside some form of self-contained "capsule" rather than a normal building. Examples are systems deployed in underwater containers for positioning close to coastal urban centres.
Pre-conditions (optional)	CSP: The CSP wishes to deploy physical machines in locations where human access will not be possible for the majority or operational time.
Post-conditions (optional)	The physical machines are left running without human access for periods of six months or more. The data centre management system can deploy workloads to the machine. In the event of failure, the machine can be taken off line, remote diagnostics can be run and the machine either returned to service or taken permanently offline.
Derived requirements	Minimum energy consumption (see clause 7.1.2) Cooling component replacement (see clause 7.1.3) Cooling component redundancy (see clause 7.1.3) Interface for controlling fan speed (see clause 7.1.3) Self-checking mechanism (see clause 7.1.6) Remote management (see clause 7.3) Diagnostic of physical machine (see clause 7.3)

Table II.7 — Physical machine for network edge – use case

Title	Physical machine for network edge
Description	This use case covers the situation where physical machines will be in network edge locations such as at 5G cell towers, telephone exchanges and cable TV head-end multiplexers. This is one use of the term "micro data centre". The primary reason for this is to minimise network latency between end users and the cloud services running at the network edge, or to concentrate network traffic at the edge to manage load on core network servers (e.g., for massive IoT telemetry applications).
Roles/sub-roles	CSP: cloud service operations manager.
Figure	In this type of deployment, physical machines are constructed for deployment at the edge of the network, usually co-located with access network transmission and/or multiplexing equipment. Examples of such locations include: Local telephone exchanges Street multiplexers (e.g., FTTC) Cellular towers Cable TV head-ends Airliner WiFi/Cellular network equipment.
Pre-conditions (optional)	CSP: The CSP wishes to deploy physical machines to support cloud services running at the edge of their (or a partner's) physical network.
Post-conditions (optional)	The physical machine(s) run co-located with other network equipment at the edge of the network. The CSP can deploy cloud services or service components to these network edge micro data centres. CSUs can access the cloud service within minimal network latency. The CSP can process large amounts of data from CSUs, without imposing heavy loads on the backhaul network or the core network cloud services.
Derived requirements	Supporting power redundancy (see clause 7.1.2) Adding power supply (see clause 7.4) Adding cooling component (see clause 7.4) Authorized access (see clause 7.5) Hot-plug support (see clause 7.6) Visual indications (see clause 7.1.4) Monitoring environment condition (see clause 7.1.6)

Table II.8 — Configurations of clustering processing units – use case

Title	A use case of configurations of clustering processing units
Description	When a CSC: cloud service user requests a cloud service, a CSP: cloud service operations manager is responsible for providing computing resources, which can run the cloud service. In this case, based on the multiple processing units in the physical machine, it is possible for the CSP: cloud operations manager to configure a clustering system which can distribute the computational loads among the multiple processing resources. Therefore, in order to utilize highly integrated computing resources efficiently, the CSP: cloud operations manager has a responsibility to configure the clustered processing units. The configuration can be changed dynamically and elastically according to the cloud service's requirements from the CSC: cloud service user. In other words, according to the required cloud service's characteristics (e.g., network usage ratio, computing capability, the proportion of memory intensive computation, an efficiency of distributed computing), the configuration of the cluster system can vary. In case of a cloud service based on distributed processing clustering configuration is suitable because data analysis work load can be divided into several processing units. On the other hand, when a CSC: cloud service user requests a cloud service, where data communications occur intensively among processing units, minimum numbers of processing units are recommended as a clustered resources. In addition, the networking between each processing unit for clustering can be basically based on a legacy network such as Ethernet. For a cloud service that is clustering-favourable but has high proportion of network usage among processing units, a proprietary network for clustering environment can be provided to eliminate the overhead of network communications.
Roles/sub-roles	CSP: cloud service operations manager, CSC: cloud service user
Figure
Pre-conditions (optional)	CSC: cloud service user wants to use a cloud service.
Post-conditions (optional)	Physical machines can run a cloud service efficiently and elastically according to the desired performance.
Derived requirements	Configuration of multiple processing units (see clause 7.1.5) Multiple CPUs (see clause 7.1.1.1) Adding processing units (see clause 7.4) Adding sub-components of processing units (see clause 7.4) Network topology (see clause 7.1.5) Interconnect network supports (see clause 7.1.5) Device driver and API supports (see clause 7.2)

Table II.9 — Replacing components of a physical machine – use case

Title	A use case of replacing components of physical machine
Description	This use case covers the situation where components of physical machine be replaced. After deployment and operation, a component of physical machine may need to be replaced with another new one due to component failure. In addition, a component could be replaced with component of other model to upgrade the performance. Typically, physical machine should support replacement of the main components, including CPU, memory, storage, power supply and cooling component.
Roles/sub-roles	CSP: cloud service operations manager
Figure	To support replacement, the components are not coupled to the physical machine so that the components can be installed or uninstalled dynamically. Typically, the components are designed to follow certain specifications to ensure compatible interface and shape.
Pre-conditions (optional)	CSP wishes to replace some components of physical machines to fix components failure or upgrade components.
Post-conditions (optional)	Physical machine can runs normally with the new components.
Derived requirements	CPU replacement (see clause 7.1.1.1) Memory replacement (see clause 7.1.1.2) Storage replacement (see clause 7.1.1.3) Processing unit replacement (see clause 7.4) Equipment for mounting and removal (see clause 7.1.4) Power supply replacement (see clause 7.1.2) Cooling component replacement (see clause 7.1.3)

Table II.10 — High reliability deployment – use case

Title	A use case for high reliability deployment
Description	This use case covers the situation where physical machine will be deployed with high reliability. To achieve high reliability, physical machine needs to be deployed with redundant main components, such as CPU, power supply and cooling component. In addition, physical machine needs to support technology to reduce data errors and data loss at work, such as memory error correction and RAID. Trough RAID technology, data of physical machine is distributed across multiple drives in different ways, referred to as RAID levels, depending on the required level of redundancy and performance. Take RAID1 as an example, as shown in below figure, RAID 1 consists of an exact copy (or mirror) of a set of data on two or more disks. The data of physical machine will not loss so long as at least one member drive is operational.
Roles/sub-roles	CSP: cloud service operations manager
Figure
Pre-conditions (optional)	CSP wishes to deploy physical machines withhigh reliability.
Post-conditions (optional)	Physical machines can still work when some components fail. The physical machine can reduce data errors and losses due to memory and storage failures.
Derived requirements	Multiple CPUs (see clause 7.1.1.1) Memory reliability (see clause 7.1.1.2) Storage redundancy hardware (see clause 7.1.1.3) Supporting power redundancy (see clause 7.1.2) Cooling component redundancy (see clause 7.1.3)

Bibliography

[b‑DMTF RFAPI]	b-DMTF RFAPI, Redfish Scalable Platforms Management API Specification.
[b‑DMTF RFHI]	b-DMTF RFHI, Redfish Host Interface Specification.
[b‑DMTF RFP]	b-DMTF RFP, Redfish Interoperability Profiles.
[b‑ETSI EVE007]	b-ETSI EVE007, Hardware Interoperability Requirements Specification.
[b‑OCP 1S]	b-OCP 1S, Twin Lakes 1S Server Design Specification V1.00.
[b‑OCP 25GDual]	b-OCP 25GDual, 25G Dual Port OCP 2.0 NIC Mezzanine Card V1.0.
[b‑OCP 2S]	b-OCP 2S, Facebook 2S Server Tioga Pass Specification V1.0.
[b‑OCP ACTI]	b-OCP ACTI, Add-on-Card Thermal Interface Spec for Intel Motherboard V3.0.
[b‑OCP AMBH]	b-OCP AMBH, Open Rack- AMD Motherboard Hardware V2.0.
[b‑OCP BS]	b-OCP BS, QCT Big Sur Product Architecture Following Big Sur Specification V1.0.
[b‑OCP DSBS]	b-OCP DSBS, Decathlete Server Board Standard V2.1.
[b‑OCP Debug]	b-OCP Debug, OCP debug card with LCD spec V1.0.
[b‑OCP FSCI]	b-OCP FSCI, Facebook server Fan Speed Control Interface Draft V0.1.
[b‑OCP G1]	b-OCP G1, Barreleye G1 Specification.
[b‑OCP G2]	b-OCP G2, Barreleye G2 Specification.
[b‑OCP HSAS]	b-OCP HSAS, Hyve Solutions Ambient Series-E V1.2.
[b‑OCP HSCH]	b-OCP HSCH, Micro-Server Card Hardware V1.0.
[b‑OCP IMBH]	b-OCP IMBH, Open Rack- Intel Motherboard Hardware V2.0.
[b‑OCP JBOG]	b-OCP JBOG, Big Basin-JBOG Specification V1.0.
[b‑OCP M2]	b-OCP M2, Facebook, Microsoft, M.2 Carrier Card Design Specification V1.0.
[b‑OCP MB]	b-OCP MB, Facebook Server Intel Motherboard V3.1.
[b‑OCP MEZZ]	b-OCP MEZZ, Mezzanine Card 2.0 Design Specification V1.0.
[b‑OCP MEZZMB]	b-OCP MEZZMB, Mezzanine Card for Intel v2.0 Motherboard.
[b‑OCP NIC]	b-OCP NIC, OCP NIC 3.0 Design Specification V0.8.
[b‑OCP O1USM]	b-OCP O1USM, Project Olympus 1U Server Mechanical Specification.
[b‑OCP O2USM]	b-OCP O2USM, Project Olympus 2U Server Mechanical Specification.
[b‑OCP OAPM]	b-OCP OAPM, Project Olympus AMD EPYC Processor Motherboard Specification.
[b‑OCP OBIOS]	b-OCP OBIOS, Project Olympus Intel Xeon Scalable Processor BIOS Specification.
[b‑OCP OCSB]	b-OCP OCSB, Open CloudServer OCS Blade Specification V2.1.
[b‑OCP OCSC]	b-OCP OCSC, Open CloudServer Chassis Specification V2.0.
[b‑OCP OCSCM]	b-OCP OCSCM, Open CloudServer OCS Chassis Manager Specification V2.1.
[b‑OCP OCSJBOD]	b-OCP OCSJBOD, Open CloudServer JBOD specification V1.0.
[b‑OCP OCSNIC]	b-OCP OCSNIC, Open CloudServer OCS NIC Mezzanine Specification V2.0.
[b‑OCP OCSPS]	b-OCP OCSPS, Open CloudServer OCS Power Supply V2.0.
[b‑OCP OCSPSAM]	b-OCP OCSPSAM, Open CloudServer OCS Programmable Server Adapter Mezzanine Programmables V1.0.
[b‑OCP OCSSAS]	b-OCP OCSSAS, Open CloudServer SAS Mezzanine I/O specification V1.0.
[b‑OCP OCSSSD]	b-OCP OCSSSD, Open CloudServer OCS Solid State Drive V2.1.
[b‑OCP OCSTRAY]	b-OCP OCSTRAY, Open CloudServer OCS Tray Mezzanine Specification V2.0.
[b‑OCP OCTAM]	b-OCP OCTAM, Project Olympus Cavium ThunderX2 ARMx64 Motherboard Specification.
[b‑OCP OMB]	b-OCP OMB, Project Olympus Intel Xeon Scalable Processor Motherboard Specification.
[b‑OCP OSR]	b-OCP OSR, Project Olympus Server Rack Specification.
[b‑OCP PCIRC]	b-OCP PCIRC, Facebook PCIe Retimer Card V1.1.
[b‑OCP PMSCH]	b-OCP PMSCH, Panther+ Micro-Server Card Hardware V0.8.
[b‑OCP QGD]	b-OCP QGD, QuantaGrid D51B-1U V1.1.
[b‑OCP SJ]	b-OCP SJ, Inspur Server Project San Jose V1.01.
[b‑OCP TP]	b-OCP TP, Facebook Server Intel Motherboard V4.0 Project Tioga Pass V0.30.
[b‑OCP Yose]	b-OCP Yose, Facebook Multi-Node Server Platform: Yosemite V2 Design SpecificationV1.0.
[b‑SNIA SF]	b-SNIA SF, SNIA Swordfish Specification V1.0.6.

FOREWORD

NOTE

INTELLECTUAL PROPERTY RIGHTS

Summary

History

1. Scope

2. References

3. Definitions

3.1. Terms defined elsewhere

3.2. Terms defined in this recommendation

4. Abbreviations and acronyms

5. Conventions

6. Overview of the physical machine

6.1. Introduction to the computing machine

6.2. Introduction to the physical machine

6.3. Types of physical machine

6.3.1. Single processing unit type

6.3.2. Multi-processing unit type

6.4. Virtualization in physical machines

6.4.1. CPU virtualization

6.4.2. Memory virtualization

6.4.3. I/O virtualization

6.5. Scalability of components in the physical machine

6.5.1. Scalability of the processing unit

6.5.2. Scalability of power supply

6.5.3. Scalability of cooling

7. Functional requirements for a physical machine

7.1. Component requirements

7.1.1. Processing unit requirements

7.1.1.1. CPU requirements

7.1.1.2. Memory requirements

7.1.1.3. Storage requirements

7.1.1.4. I/O device requirements

7.1.2. Power supply requirements

7.1.3. Cooling requirements

7.1.4. Enclosure requirements

7.1.5. Interconnect network requirements

7.1.6. Management component requirements

7.2. I/O interface requirements

7.3. Operation requirements

7.4. Scalability requirements

7.5. Security requirements

7.6. Reliability requirement

8. Security considerations

Appendix IComparison between functional requirements and other specifications

I.1. Specifications and other SDOs

I.1.1. Open Compute Project

I.1.2. DMTF

I.1.3. SNIA

I.1.4. ETSI

I.2. Relationship with related specifications from other SDOs

Appendix IIUse cases of the physical machine for cloud computing

Bibliography

Appendix I

Comparison between functional requirements and other specifications

Appendix II

Use cases of the physical machine for cloud computing