designs/mctp/mctp.md

8 BMC. This is primarily IPMI-based, but also includes a few hardware-specific
9 side-channels, like hiomap. On OpenPOWER hardware at least, we've definitely
14 provide a common transport layer over the multiple channels that OpenBMC
19 ## Background and References
27 attempted, but not in a cross-implementation manner so far. This does not
31 layer bindings for the actual transport of MCTP packets. These are defined by
40 ![](mctp-standards.svg)
43 physical layer bindings; this means that an MCTP "stack" may be using either a
48 that communicates over MCTP - for example, the host device, the BMC, or any
49 other system peripheral - static or hot-pluggable.
54 For example, the PLDM design at [pldm-stack.md].
58 the higher-level data transferred between MCTP endpoints, which packets are
68 - Have a simple serialisation and deserialisation format, to enable
72 - Allow different hardware channels, as we have a wide variety of target
75 - Be usable over simple hardware implementations, but have a facility for higher
78 - Ideally, integrate with newer messaging protocols
84 - A userspace-based approach, using a core library, plus a demultiplexing
85   daemon. This is described in [MCTP Userspace](mctp-userspace.md).
89 - A kernel-based approach, using a sockets API for client and server
91   in [MCTP Kernel](mctp-kernel.md)
94 both share the same Problem Description, Background and Requirements,
104 platform-specific customisations. This also does not solve the hardware channel
109 While this may be present in some environments (for example, UEFI-based
112 stack - indeed, MCTP has a proposal for a Redfish-over-MCTP channel (DSP0218),