OCP Modularization Scoping Task Force OCP Server Project

OCP Modularization Scoping Task Force OCP Server Project and Sub Projects OCP Incubation committee

Background 2018 2019 Orde r r 1 1 Title COMMON PLATFORMS Description of industry challenge General list of ideas and proposals on what is needed. This list is potential opportunities for OCP Common Platforms Concept. Need for “operationally similar” variations of compute platforms where the physical and interface operations are the same, but offer options for different processors, NUMA (or non) designs, and common peripherals. A 'few' common platforms would be necessary to provide scalable, efficient packaging for various DC's and operators (rack scale, 19" compatible, and edge appliances). A. Create common platform(s) that achieve scale and economics of the hyperscale customer while supporting adoption by a broad set of consumers, and secondary markets. The common platform concept could support or use MODULE standardization efforts, drive standardization of hardware management and security, and become an early adopter of open systems firmware. C. Rather than create designs more or less with no thought to anyone else or to what will happen to the servers after they have been used, create server designs that still are mega. Core count, memory capacity, and IO bandwidth improves in either, 1) economical, but also cater to use and management by a broad set of consumers – both as new devices and as second hand equipment. Olympus began this. incremental, evolutionary steps or 2) disruptive & revolutionary phases. D. Creation of an 'open chassis' with defined abstractions. supported by major releases of the operating systems. Standardized interfaces protect investments and support technology adoption. Operators need consist remote management command control with CPU agnostic root-of-trust support from discrete devices and/or embedded functions. AI, ML, and DNN applications are driving demand for hardware 4 2 B. The goal is to minimize the # of different designs for any generation of CPU/memory, and to maintain platform consistency across CPU suppliers. Roadrunner and Decathlete's initial projects tried to achieve this, but too many variations were allowed. The bulk of server demand will continue to be general-purpose servers. GPU/AI-oriented workloads represent a niche in overall DC capacity. Performance improvements from general purpose servers and cloud availability will limit the need for specific workload-optimized hardware for most users. But for niche workloads and resource pooling, deployment of some % of servers with HW accelerator, or pools of resources, is a reasonable practice. The accelerators, IO, & NW functions can be implemented as modules. Standardization (electrical, mechanical, power, protocol) of module interfaces will protects HW and SW investments, allows late configuration decisions, and accelerates adoption of HW technology. Specific functions that are candidates for module standards are: MODULARIZA accelerators delivering 10 x to 1000 x performance improvement versus a. NW modules (e. g. NIC 3. 0 spec, smart NIC modules) TION GP processors or software solution. New domain/workload specific HW b. AI/ML modules (e. g. OAM) accelerators will place new requirements on the baseboard (new IO c. device to module interface (e. g. ODSA) interfaces and memory buses, different mechanical and power d. possibly a Core CPU/memory module (nothing today) envelopes for mezzanine and option cards). Ongoing network transitions - Memory modules driving new i/f standards, & time of deployment configuration needs. e. An Enclosure & baseboard for rack scale(e. g. open. RACK), 19" equipment, and edge appliances f. could extend outside of the enclosure g. transformation functions, encoder/decoders, 3 3 PLATFORM SECURITY Growing threat landscape scales with growth of programmable devices A. Accelerate "open source" root of trust device availability and common SW API. Verifiable designs: being able to verify product to design and to secure any number of interfaces, throughout the network and ITE. Proprietary software deployed on these protocols, and features/modules. devices creates opportunities for malicious threats. Vulnerability of the B. Accelerate availability of open source firmware and products. OCP can influence adoption of o/s by requiring open sourced FW stack for OCP Accepted recognition. supply base chain of custody from component manufacturing, thru deployment and decommissioning. C. AT&T has added a requirement for 2 -factor authentication extremely broadly across our business. These requirements will trickle down into the equipment and protocols, and OCP can lead in this space. Hyperscale providers have implemented proprietary API's for remote management. Availability of interoperable API to replace IPMI isn't 5 4 A. Finish the OCP Profiles for all ingredients and establish a plan to require support from OCP Inspired and Accepted products. COMMON forecoming and the gap between hyperscale capabilities and non. B. Designs and specifications to enable interoperable manageability for Open Compute platforms, provides a common foundation from providing manageability for other Open projects. PROFILES hyperscale is disproportionate and growing. System Management needs Standardization and adoption of these API's and specs across OCP, TIP, and ONF communities. ACROSS OCP to be standardized starting with OCP, TIP, and ONF communities. C. Adopt open. BMC (or other open source repo) as a requirement for all OCP recognized products, thereby driving support for redfish

Scope and Goals ▪ Capturing status quo of modularization efforts inside / outside of OCP, across technology domains ▪ Collecting the benefits and tradeoffs that modularization brings to our industry ▪ Summarizing the possible scope(s) of a typical modularization effort ▪ Identifying challenges of modularization works ▪ Identifying key design principles to consider across technology domain, for common modularization be applied across some domains. ▪ Expanding / converge existing modularization efforts.

Status quo (not a complete list) Memory Host networking High power accelerators DDR 4/5 DIMM Open Memory Interface OCP NIC OAM Gen-Z UBB PCIe CEM Dual M. 2 Low Power accelerators M. 2 Flash Drive Management and security Optical NF 1 EDSFF DC-SCM QSFP-DD TPM Run BMC CXL

Scope and Challenges Function Thermal Security Electrical Management and side band Sideband / In band Utility Mechanical Testing and Compliance Protocol Complexity Versatility Bifurcation Use case optimization Spec Dev leadtime … … Typical scopes, differs across modularization efforts Challenges

Next steps & Call to Action ❑ Creating framework for discussion and documentation ❑ Involving Informing communities ❑ Starting from informal discussion, and evolving to workshop Open to All - Includes OCP projects, and Standards organizations beyond OCP We are reaching out to potential collaboration partners Please reach out to us if you want to learn more John Stuewe john. stuewe@ocproject. net Siamak Tavallaei siamak. tavallaei@ocproject. net Jia Ning jia. ning@ocproject. net