1# OpenBMC platform communication channel: MCTP & PLDM 2 3Author: Jeremy Kerr <jk@ozlabs.org> <jk> 4 5## Problem Description 6 7Currently, we have a few different methods of communication between host and 8BMC. This is primarily IPMI-based, but also includes a few hardware-specific 9side-channels, like hiomap. On OpenPOWER hardware at least, we've definitely 10started to hit some of the limitations of IPMI (for example, we have need 11for >255 sensors), as well as the hardware channels that IPMI typically uses. 12 13This design aims to use the Management Component Transport Protocol (MCTP) to 14provide a common transport layer over the multiple channels that OpenBMC 15platforms provide. Then, on top of MCTP, we have the opportunity to move to 16newer host/BMC messaging protocols to overcome some of the limitations we've 17encountered with IPMI. 18 19## Background and References 20 21Separating the "transport" and "messaging protocol" parts of the current stack 22allows us to design these parts separately. Currently, IPMI defines both of 23these; we currently have BT and KCS (both defined as part of the IPMI 2.0 24standard) as the transports, and IPMI itself as the messaging protocol. 25 26Some efforts of improving the hardware transport mechanism of IPMI have been 27attempted, but not in a cross-implementation manner so far. This does not 28address some of the limitations of the IPMI data model. 29 30MCTP defines a standard transport protocol, plus a number of separate physical 31layer bindings for the actual transport of MCTP packets. These are defined by 32the DMTF's Platform Management Working group; standards are available at: 33 34https://www.dmtf.org/standards/pmci 35 36The following diagram shows how these standards map to the areas of 37functionality that we may want to implement for OpenBMC. The DSP numbers 38provided are references to DMTF standard documents. 39 40 41 42One of the key concepts here is that separation of transport protocol from the 43physical layer bindings; this means that an MCTP "stack" may be using either a 44I2C, PCI, Serial or custom hardware channel, without the higher layers of that 45stack needing to be aware of the hardware implementation. These higher levels 46only need to be aware that they are communicating with a certain entity, defined 47by an Entity ID (MCTP EID). These entities may be any element of the platform 48that communicates over MCTP - for example, the host device, the BMC, or any 49other system peripheral - static or hot-pluggable. 50 51This document is focused on the "transport" part of the platform design. While 52this does enable new messaging protocols (mainly PLDM), those components are not 53covered in detail much; we will propose those parts in separate design efforts. 54For example, the PLDM design at [pldm-stack.md]. 55 56As part of the design, the references to MCTP "messages" and "packets" are 57intentional, to match the definitions in the MCTP standard. MCTP messages are 58the higher-level data transferred between MCTP endpoints, which packets are 59typically smaller, and are what is sent over the hardware. Messages that are 60larger than the hardware Maximum Transmit Unit (MTU) are split into individual 61packets by the transmit implementation, and reassembled at the receive 62implementation. 63 64## Requirements 65 66Any channel between host and BMC should: 67 68- Have a simple serialisation and deserialisation format, to enable 69 implementations in host firmware, which have widely varying runtime 70 capabilities 71 72- Allow different hardware channels, as we have a wide variety of target 73 platforms for OpenBMC 74 75- Be usable over simple hardware implementations, but have a facility for higher 76 bandwidth messaging on platforms that require it. 77 78- Ideally, integrate with newer messaging protocols 79 80## Proposed Designs 81 82The MCTP infrastrcuture in OpenBMC is implemented in two approaches: 83 84- A userspace-based approach, using a core library, plus a demultiplexing 85 daemon. This is described in [MCTP Userspace](mctp-userspace.md). 86 87 This is in use by a few platforms, but should be avoided for new designs. 88 89- A kernel-based approach, using a sockets API for client and server 90 applications. This approach is recommended for new designs, and is described 91 in [MCTP Kernel](mctp-kernel.md) 92 93Design details for both approaches are covered in their relevant documents, but 94both share the same Problem Description, Background and Requirements, 95Alternatives and Impacts sections as defined by this document. 96 97## Alternatives Considered 98 99There have been two main alternatives to an MCTP implementation in OpenBMC: 100 101Continue using IPMI, but start making more use of OEM extensions to suit the 102requirements of new platforms. However, given that the IPMI standard is no 103longer under active development, we would likely end up with a large amount of 104platform-specific customisations. This also does not solve the hardware channel 105issues in a standard manner. 106 107Redfish between host and BMC. This would mean that host firmware needs a HTTP 108client, a TCP/IP stack, a JSON (de)serialiser, and support for Redfish schema. 109While this may be present in some environments (for example, UEFI-based 110firmware), this is may not be feasible for all host firmware implementations 111(for example, OpenPOWER). It's possible that we could run a simplified Redfish 112stack - indeed, MCTP has a proposal for a Redfish-over-MCTP channel (DSP0218), 113which uses simplified serialisation format and no requirement on HTTP. However, 114this may involve a large amount of complexity in host firmware. 115 116## Impacts 117 118Development would be required to implement the MCTP transport, plus any new 119users of the MCTP messaging (eg, a PLDM implementation). These would somewhat 120duplicate the work we have in IPMI handlers. 121 122We'd want to keep IPMI running in parallel, so the "upgrade" path should be 123fairly straightforward. 124 125Design and development needs to involve potential host, management controllers 126and managed device implementations. 127
