It has taken fewer than 20 years for the Intelligent Platform Management Interface (IPMI) to become the standard for managing corporate computer hardware. In the near future, the platform will be known by the name of its successor, Redfish. Thanks to its simplified structure, Redfish will enjoy even more support. The primary goal envisioned is to supersede IPMI over the network (IPMI over LAN). Knowledge gained from the myriad of proprietary IPMI extensions is being incorporated into Redfish so that it can offer a defined extension mechanism for company-specific modules.

The IPMI

Redfish is being developed by the Scalable Platforms Management Forum (SPMF) of the Distributed Management Task Force (DMTF). Version 1.0 of the standards was released in August 2015, followed by version 1.0.2 in December 2015. The Redfish Scalable Platforms Management API Specification version 1.0.2 appeared in May 2016 [1]. Jeff Autor from Hewlett Packard Enterprise (HPE) and Paul Vancil from Dell were in charge of creating these standards. As a result, it is no accident that HPE, or HP as it was then known, began offering a management interface that was conceptually similar to Redfish. Going by the name "HPE RESTful API," the interface sat on ProLiant servers by 2014. In addition to HPE and Dell, many other manufacturers also are on board with the new platform standards, including Cisco, EMC, VMware, Microsoft, IBM, Fujitsu, Huawei, NetApp, and Intel.

Web Technology Grounds

The standard sits on tried and true protocols and formats that come from the world of the Internet. The architecture follows the REST model, which uses the verbs in the HTTP protocol for reading and modifying data (i.e., GET, POST, PATCH, and PUT). Corresponding structures for URLs are also required that reflect the structures of the management information. HTTP with TLS encryption is the transport protocol used for data, which is coded in JSON format in a nested JavaScript data structure.

The Open Data Protocol (OData), another component, prescribes the structure of the data coded in JSON format. The following example is an excerpt from a JSON answer by a Redfish server specifying the URL (OData ID) for the system interface:

"Systems": {
    "@odata.id": "/redfish/v1/Systems"
}

Thanks to the OData structure, software with OData capabilities can interact with Redfish firmware, even in the absence of special Redfish support. Windows PowerShell and Excel Power Query allow for simple debugging so that the JSON format data delivered by the firmware is easy to see in the browser. Extensions like JSONView, with line breaks and indentations that make JSON easier to read, make for even more convenient interactions. The Redfish resources that originate with OData include Systems, Managers, Chassis, Tasks, and Sessions plus an AccountService and an EventService (Figure 1).

Figure 1: An overview of some of the resources specified in Redfish (source: dmtf.org).

Redfish relies on the HTTP verb GET to read data from the system. Both PUT and PATCH can be used to modify data, the difference being that PUT always replaces a dataset completely, whereas PATCH only changes the updated data incrementally, making it more error tolerant and therefore the preferred method for updates. Some implementations do not support PUT at all. Listing 1 shows how easy it is to acquire data.

01 import requests
02 import json
03 system = requests.get("http://172.17.0.2/redfish/v1/Systems/1").json()
04 print( system['SerialNumber'] )
05 serial = requests.get("http://172.17.0.2/redfish/v1/Managers/1/SerialInterfaces/1").json()
06 print( serial['BitRate']

The management software can use Redfish to register itself for notification of incoming events with HTTP server push, which requires a Redfish-capable HTTPS server as a receiver. In the future, additional technologies will be added to handle events. For example, Super Micro firmware currently permits registration for a maximum of 16 events.

Two Methods of Authentication

The platform design includes two authentication methods, including HTTP basic authentication and session-based authentication. Basic authentication requires a username and password that are passed along with each HTTP request. The alternative is to log in with credentials at the beginning of a session (POST redfish/v1/SessionService/Sessions/) and get a session token (X-Auth-Token) that will serve as authentication for further requests. Depending on the implementation, local user data, LDAP, and Active Directory can each serve as a back end.

In spite of the relatively recent appearance of Redfish, hardware platforms already exist for the new standard. HPE supports Redfish with version 2.30 of the iLO 4 firmware and the Chassis manager in the modular Moonshot system. Super Micro intends to offer Redfish on its X10 generation boards and future models. All Baseboard Management Controllers (BMCs) starting with version 3 are supposed to support the interface. Intel is therefore working on support for UEFI 2.5 HTTP Boot.

Dell customers can start experiencing Redfish with version 2.30.30.30 of the integrated Dell Remote Access Controller (iDRAC). The Open Compute Project is also working on integrating Redfish into open hardware. Users who do not yet have Redfish-capable hardware can acquaint themselves with the interface in simulated environments or mock-ups offered online by the DMTF [2], or they can take a look at the Python library [3], which includes the code for these simulations.

Every manufacturer has the option of programming Redfish-compliant extensions and then integrating them into their system from a well-defined interface. For example, in addition to the basic functions, HPE offers extensions for iLO 4 management that include a UEFI system configuration, S.M.A.R.T. storage status, and other actions.