Blog

Over the past year and half, OCP is going through some transitions, including the addition of Google as a Board member.

 

The following will provide you with a summary of the changes that the Incubation Committee has undergone in the past year as the Community prepares for the next 10 years.

 

Current OCP Structure:

 

The Incubation Committee (IC) interfaces between the Foundation and the Project Leads. The IC comprises one or more Co-chairs who are appointed members. Individual Project IC members are elected.

Evolving Role of OCP Incubation Committee (IC)

Traditionally, the OCP IC has been primarily responsible for following key activities:

• Reviewing and voting on the disposition of each contribution to the OCP Foundation
  • Participate in IC Meetings (every 6 weeks) & vote on new contributions
  • Review contributions for technical completeness and adherence to OCP tenets
• Community support activities
  • Participate in all events where their Project Community has a presence.
  • Provide guidance and feedback to the incubated projects
  • Help shape new projects & encourage the Project Leads and Community to bring new contributions forward.
• Adherence to the Charter of the Foundation
  • Create/update project charters that set guidelines & limits for activity & scope of the project work

In the past year, the OCP IC has gone through a refresh of sorts, with multiple new members joining, including Jia Ning and Steve Mills who have moved from leading projects to becoming IC representatives. Additionally, three new IC Co-Chairs have been appointed: Dharmesh Jani (DJ)  from FB, Jeff Catlin from Edgecore and Jessica Gullbrand from Intel.

 

With this changing composition of the IC, we also expanded the OCP IC role to include focus on solving common industry problems and needs of the OCP Community. The following have been incorporated as key additional activities of the IC team, apart from the traditional roles:

• Identify the common industry problem sets in front of the OCP Community members
• Drive the solution discovery process within the Community
• Crystalize and define the roadmap for OCP Community to focus on
• Communicate the progress to the Community via regular updates

Details of the OCP IC team activities are available in the wiki here.

Motivation for OCP IC role expansion

You may be wondering what are the reasons for expanding the role of the OCP IC? As OCP enters its 2nd decade, there is a general need emerging across the OCP Community to look at OCP as a way to address some of the industry challenges going forward. The IC represents their Community to the Foundation and across other communities. This puts them in a unique position to make an impact and bring about change in a more efficient, rapid and scalable way.

 

Additional motivation for this change was to bring a balanced approach to the IC role as the new IC members were on-boarded. With several decades of collective experience, IC members also have something to offer to the Community beyond the traditional work. Strategic elements provide a complementary balance to the current administrative structure and encourage a broader range of involvement from the IC team. The additional scope of activities also allows for a proactive approach to new technologies.

 

Defining new directions for OCP for the next 2-3 years requires a coordinated effort involving all constituents, with the OCP IC team playing a key role. Ensuring focus on the industry problems allows for forward-looking work that many IC representatives are motivated to do as well.

 

But the biggest motivation is to find ways to serve the needs of the Community. The OCP Community primarily is made of two major camps: engineers, developers and builders that seek to solve complex problems and the end users who are interested in deploying OCP gear in their data centers. Most of the companies, vendors and suppliers would fall in one of the two camps listed above. In the past, OCP came out with systems, designs and contributions driven by end users such as Facebook and Microsoft that subsequently became part of OCP solutions used by others. As the OCP Community grows, the added focus on identifying problems and pain points helps us tap into the energy of the vast Community of engineers and builders who are creative problem solvers. The major motivator of the OCP IC is to shepherd the Community by identifying key problems to be solved.

 

New Direction setting for the IC

There are three areas on which OCP IC responsibilities have expanded.

 

With different skills represented across the OCP IC team, additional activities are not expected to be evenly distributed across all the IC members. However, the expectation from the IC team is to identify ways to move conversations in each of these three spheres over the coming year.

 

Beginning in 2019, the OCP IC team worked closely with the OCP Foundation to identify and prioritize a set of problem areas to address major pain points in front of the industry. 15 major pain-points or technology areas were identified that could be brought in front of the open source community to accelerate solutions for 4 key verticals:-

• Hyperscaler
• Large enterprises
• Telco
• Edge

The OCP IC team went through a democratic selection process to identify the top 4 areas which they could dedicate time to work on. In case anyone is interested in seeing all of the 16 areas identified in the 2019-2020 time frame, you can find them here under the technology roadmap heading. Summary table is shown below:

 

2019 Rank	OCP Problem Areas for Exploration
1	COMMON PLATFORMS
2	MODULARIZATION
3	PLATFORM SECURITY
4	COMMON PROFILES ACROSS OCP
5	CONSUMPTION OF HYPERSCALE HW
6	DATA STORAGE
6	INTEGRATED SOLUTIONS
8	GRANULAR POWER MANAGEMENT
8	TRANSITION to 400Gbs
10	PON/OLT & CPE DISAGGREGATION
10	NEW PLATFORM INITIALIZATION ARCHITECTURE
12	CLOUD SERVICE MODEL
13	DC ENERGY EFFICIENCY
14	SCALE OUT OF LIQUID COOLING/ IMMERSION
15	OUTSIDE PLANT COMPLIANT OFFERINGS
16	GREEN INITIATIVES

 

Technology roadmap areas for OCP community for  2019-2020

Following 4 key areas were identified for OCP to focus in the coming year.

Area 1: Common Platforms (led by Steve Mills)

As we continue to grow the OCP Community, we want to focus on converging designs and platforms to avoid OCP SKU proliferation in the marketplace. This is the key motivation for starting work on developing common design requirements across platforms. A common platform approach provides scalable, efficient designs for all users and adopters, and is especially well-suited for large enterprise and telecom operators (those providing private cloud services) that benefit from leveraging the technology and products developed by the world’s biggest service providers. The common platform concept would ideally support modularity, standardization of hardware management and security, and open system firmware.

 

The Common Platforms Initiative team is working to support OCP’s goal of achieving the economies of scale needed by hyperscale customers while supporting OCP adoption by a broad set of customers. This project will build awareness about all of the existing work developed by the OCP Community to encourage reuse and interoperability of future OCP contributions. Steve Mills is leading this initiative for OCP and both Dharmesh Jani (DJ) and Jia Ning are active team members.

 

The OCP Community benefits from incorporating and building upon existing technological developments. Thanks to OCP’s success, there are now many specifications and protocols available to create new solutions. Many of the new specifications that are emerging also have impact across multiple OCP Projects. For example, the Hardware Management Project is developing protocols that impact everything from storage systems to immersion cooling tanks.  This makes it difficult for a Community member that is interested in building an OCP solution to incorporate all of the existing specifications available into their product.

 

Without awareness of what specifications are available from OCP, Community members may develop custom interfaces or protocols rather than taking advantage of existing OCP technologies that:

• Reduce OCP scalability by generating more OCP product SKUs
• Result in competing specifications for similar technologies creating adoption friction
• Hinder interoperability between OCP components from different community members

The team is developing a matrix of requirements for new OCP Accepted^TM contributions. This matrix will allow an OCP member to quickly identify all of the possible interfaces, protocols, and specifications that might interact with a new product developed for contribution. Identifying such opportunities early in the design process makes it much easier to integrate existing OCP technologies into designs, rather than finding out during product submission to the IC at the end of the process. Nobody wants to find out at the end of the design process that they should have integrated OCP’s NIC 3.0 into their design rather than using a proprietary solution.

 

The team hopes the IC will be able to start using these new requirements later this year. The IC will begin using the matrix to build awareness of what technologies already exist for the Community and put the most basic expectations of requirements in place. However, this tool will be used to communicate future intent of the IC to the community as features move from Desired to Highly Desired to Requirements.

 

Here is a small snippet of the matrix as an example of what it will look like.

Once approved by the IC, OCP will begin to communicate this out to the broader community.

Area 2: Modularization (led by Jia Ning)

Modularity and standardization of interfaces protects HW and SW investments and accelerates adoption and deployment of the hardware technology. Data center operators are always seeking consistent management command and control with CPU agnostic root-of-trust support from discrete devices and/or embedded functions.

 

Drivers for focusing on modularization are many. AI, ML, DNN and video transcoding applications are driving demand for hardware accelerators for delivering 10x to 1000x performance improvement versus GP processors or software solutions. New domain/workload specific HW accelerators will place new requirements on the baseboard (new IO interfaces and memory buses, different mechanical and power envelopes for mezzanine and option cards). Similarly, growing bandwidth demands, especially due to machine to machine traffic growth, are creating network transitions that are driving new interface standards and time of deployment configuration needs.

The accelerators, IO, & NW functions can be implemented as modules. Standardization (electrical, mechanical, power, protocol) of module interfaces will protect HW and SW investments, allow late configuration decisions, and accelerate adoption of HW technology.

 

Best example of a modular solution in OCP is the OCP Mezzanine card which today has become the de facto standard for IO options. Similarly OCP Accelerator Module (OAM) is another standard modular form factor being developed by the OCP Community. @Jia Ning is leading this workstream on behalf of the OCP IC team.

 

Specific functions that are candidates for module standards are:  NW modules (e.g. NIC 3.0 spec, smart NIC modules), AI/ML modules (e.g. OAM), device to module interface (e.g. ODSA), possibly a Core CPU/memory module (nothing today), Memory modules,  an Enclosure and baseboard for rack scale(e.g. openRACK), 19" equipment, and edge appliances and could extend outside of the enclosure, transformation functions, 

 

These hardware solutions, such as NIC and accelerators, are implemented as modules, allowing a common platform to provide host services (electrical interconnect, mechanical, cooling, power, protocol). The goal of this workstream is to promote modularity at the device and sub-assembly level to prevent proliferation of form factors, such as ones seen in storage devices. Here is the current map of modularization efforts around various use cases.

 

Opportunities in front of us are as follows:

• Break the silos across different communities within OCP & in the industry
• Increase reuse and avoid reinventing or duplication

Major deliverable for phase 1 identified are:

• Mapping of the modularization inside and outside of OCP, considering definition of modularization, and provide structured categories
• Raise awareness across OCP in modularization efforts through communication and education, in order to reduce silo and enable collaboration.

Area 3: Platform Security  (led by Elaine Palmer, IBM)

Threat landscape grows with the growth of programmable devices throughout the network and data center. Proprietary software deployed on these devices creates opportunities for malicious threats. There are points of vulnerability across the supply base chain of custody from component manufacturing, through deployment and decommissioning. 

 

This workstream addresses platform security across OCP devices with the following opportunities:  

• Accelerate "open source" root of trust device availability and common SW API
• Accelerate availability of open source firmware and products

OCP can influence availability of open source content by requiring open sourced FW stack for OCP Accepted recognition.

 

Next Steps:

• The Security project has four documents: Attestation, Secure Boot, Threats and Recovery that are complete or nearly complete. Together, they provide a set of recommendations and requirements for future OCP Accepted devices. They are targeted at devices, not platforms.  
• Begin work on Platform Security, or the "other end" of the attestation protocol, and its requirements for Secure Boot, Threats, and Recovery mechanisms.
• Coordinate with other OCP projects in which the security documents will apply in the future, present the documents, and answer questions.

Currently the team has looked at the attestation document in detail and discussed how to create an attestation checklist similar to the one OSF has. In order to minimize re-work, the team has decided to take out the required and recommended “blue lines” of the attestation document to a check-list document. The work has already been started and the expected update would be available by 2H of 2020.

 

Area 4: Common Profiles across OCP  (led by John Leung, Intel)

Hyperscale providers have implemented proprietary APIs for remote management. Availability of interoperable API to replace IPMI is not forthcoming and the gap between hyperscale capabilities and non-hyperscale is disproportionate and growing. System Management needs to be standardized starting with OCP, TIP, and ONF communities. 

 

This workstream addresses common profiles across OCP devices with the following opportunities:  

• Standardization and adoption of management APIs and specs across OCP, TIP and ONF communities.  
• Adopt open source BMC FW and initialization FW as a requirement for all OCP recognized products, thereby driving support for Redfish

Currently, the OCP Baseline HW management profile v1.0.0, OpenRMC profile, OCP server management profiles v0.2.4 has been finalized and posted.

 

Next Steps: 

• Finish the OCP Profiles for all devices to allow for support from OCP Inspired and Accepted products in the future
• Designs and specifications to enable management interoperability for Open Compute platforms provides a common foundation of providing manageability for other Open projects
• SNIA has discussed 5 profiles with the Community. Similar work is going on with the Rack and Power project to streamline rear door exchanger profiles and power shelf profiles.
• Work in progress on the following prime requirements:
  • Platform should/shall support Redfish interface
  • Platform shall support OCP HW baseline profile
  • Platform shall support OCP <platform> profiles, when it exists
  • Highly desired Redfish support on Servers (Sled, Monolithic, Chassis) and on OpenEdge (server, storage and RMC) as shown in the figure below
  • Desired Redfish support on Storage, Network, Rack frame and power & shelf as shown in the figure below.

 

All the Redfish JSON files created would be read by DMTF’s Redfish interop validator henceforth guaranteeing conformance as shown in the diagram below:

 

Next Steps for OCP IC Team

Currently the IC team is starting a refresh on the set of industry problems that can be brought in front of the OCP Community. We started the process last year with a goal to revisit the list of priorities on an annual basis, as our industry needs are also constantly changing.

 

To help us with this effort, we encourage all of you to either reach (Dharmesh Jani, Steve Mills or Jia Ning or share your thoughts in the comments section for technology problems which you feel the OCP Community should work on.

How can we support all of you more?

As we seek your input on problem sets for the OCP Community to work on, we also request any other thoughts you may have that you want to bring in front of the OCP Incubation Team. Following summarizes some ideas which if you want to hear more about, please reach out to us.

• No fall Summit
  • Is there a need for internal OCP participants to provide readouts to the community via some forum. If you have any needs or ideas please reach out
• Any upcoming contributions please inform ahead of time to any of the IC team for any support they need for the process
• And of course as mentioned previous section: Refresh of the industry challenges and problem statements which OCP should be looking at over the next 1 year

 

Looking forward to engaging with many of you here on various OCP areas of interest.