Fact-checked by Grok 2 weeks ago

Management Component Transport Protocol

The Management Component Transport Protocol (MCTP) is a media-independent transport protocol developed by the (DMTF) to enable efficient communication of messages among intelligent devices, controllers, firmware, and other components within a platform's subsystem. It supports the exchange of control, monitoring, and configuration data across diverse physical media, such as SMBus/ and PCIe Vendor Defined Messaging (VDM), using a compact, byte-efficient packet format optimized for low-cost microcontrollers. First outlined in a white paper (version 1.0.0a) in July 2007 by the DMTF's Platform Management Component Intercommunications (PMCI) working group, with the formal base specification (version 1.0.0) released in July 2009, MCTP aligns with broader DMTF standards like the Common Information Model (CIM) to promote interoperability in enterprise and systems management. The protocol's architecture relies on Endpoint Identifiers (EIDs) for logical addressing, with bus owners responsible for EID allocation and discovery, and bridges facilitating routing across multiple buses or networks. Key features include support for message types such as control commands (e.g., Resolve Endpoint ID, Allocate Endpoint IDs) and vendor-defined payloads, along with mechanisms for hot-plug device handling, rate limiting, and multi-packet message assembly. The current version of the base specification, 1.3.3, was published on March 25, 2024; as of 2025, development of MCTP 2.0 is underway, and the MCTP Host Interface Specification version 2.0.0 was released in April 2025 to improve host software discoverability. MCTP has seen adoption in environments for high-bandwidth tasks, such as updates and , often integrated with protocols like Security Protocol and Data Model (SPDM) for authentication and Platform Level Data Model (PLDM) for device control. For instance, in Unified Computing System (UCS) M6 generation servers, MCTP over PCIe VDM provides up to 4000 Mbps throughput—far exceeding traditional rates—enabling secure, sideband communications without host downtime. Its implementation in the via an AF_MCTP further supports open-source ecosystems for MCTP message handling.

Introduction

Definition and Purpose

The Management Component Transport Protocol (MCTP) is a media-independent protocol developed by the (DMTF) to support communications between intelligent hardware components within a platform management subsystem. It defines a communication model that enables reliable message exchange among management controllers, such as baseboard management controllers (BMCs), and managed devices, including sensors and network interfaces, without reliance on specific underlying physical transport layers. The primary purpose of MCTP is to facilitate the , , and of computer systems by allowing these endpoints to exchange structured messages for tasks like status reporting, configuration updates, and event notification. This protocol addresses the need for a standardized, low-overhead mechanism in managed environments, ensuring efficient firmware-level operations across diverse platforms while promoting among components from different vendors. MCTP's scope encompasses intra-system communications in environments such as servers, workstations, and devices, emphasizing a that minimizes and resource usage for functions. It supports bindings to multiple , including SMBus/ and PCIe, to adapt to various system architectures without altering the core messaging semantics. First outlined in the DMTF's Platform Management Component Intercommunications (PMCI) working group efforts starting in 2007, MCTP has evolved as a foundational standard for platform-level manageability.

Key Features

The Management Component Transport Protocol (MCTP) is designed as a media-independent protocol, allowing it to operate over diverse physical links such as SMBus/, PCIe Vendor Defined Messages (VDM), and serial interfaces without modifications to its core specification; this enables seamless reuse across different bus technologies in platform management environments. MCTP employs an 8-bit Endpoint ID (EID) scheme for addressing, supporting up to 255 unique s per bus (with values from 0x00 to 0xFF, reserving specific codes like 0xFF for broadcast and 0x00 for unassigned); this logical addressing facilitates identification of devices and accommodates bridges for messages across interconnected media segments. The protocol defines a range of message types, including control messages for , updates, and basic management operations (e.g., Set Endpoint ID and Get Message Type Support), alongside vendor-defined extensions using (0x7E) or IANA (0x7F) formats to accommodate proprietary functions without disrupting interoperability. To ensure efficiency in resource-constrained environments like microcontrollers, MCTP features a compact, byte-efficient packet structure with a baseline transmission unit of 64 bytes, complemented by fragmentation mechanisms using Start of Message (SOM), End of Message (EOM) flags, and sequence numbers to handle payloads exceeding single-packet limits. Security in MCTP incorporates built-in header fields for tags and optional integrity checks to detect tampering or corruption during transit, although comprehensive protection against advanced threats depends on overlying protocols like those in the Platform Level Data Model (PLDM). A distinctive aspect of MCTP is its support for hot-plug detection and dynamic endpoint discovery, achieved through control commands such as Endpoint Discovery, Prepare for Endpoint Discovery, and Discovery Notify, which enable automatic adaptation to topology changes like device insertion or removal in managed platforms.

History and Development

Origins in DMTF

The Management Component Transport Protocol (MCTP) originated within the (DMTF), a focused on promoting in enterprise and . It was initiated by the Platform Management Component Intercommunications (PMCI) sub-team under the DMTF's Pre-OS Workgroup, which aimed to standardize intercommunications among management components in computing platforms. This effort addressed the fragmented landscape of interfaces prevalent in server hardware during the early , where diverse proprietary protocols hindered efficient monitoring, control, and across subsystems like controllers and peripherals. By developing a unified, media-independent transport protocol, the PMCI sub-team sought to enable seamless communication that supports higher-level DMTF standards, such as Common Information Model (CIM) profiles, without reliance on specific physical buses. Key milestones in MCTP's foundational development include the release of the first overview , DSP2016 version 1.0.0, on July 8, 2007, which outlined the 's conceptual framework and rationale. This informational document laid the groundwork by describing MCTP as a packet-based for endpoint discovery, message routing, and within managed systems. Shortly thereafter, the base specification, DSP0236 version 1.0.0, was formalized as a DMTF on July 28, 2009, providing the detailed mechanics while remaining aligned with the white paper's vision. These early publications marked the transition from conceptual planning to a structured , emphasizing low-level to complement existing DMTF architectures. Development involved collaboration among DMTF members, with significant contributions from industry leaders such as , , and , who participated through the PMCI sub-team to drive in . These contributors drew from the broader DMTF , including efforts like the Systems Management Command Line Protocol (SM CLP) and (WS-Man), to address gaps in intra-platform hardware communications that higher-level protocols could not fully cover. This integration ensured MCTP filled a critical niche in pre-OS environments, promoting consistent manageability across diverse hardware .

Standards Evolution

The Management Component Transport Protocol (MCTP) base specification, documented as DSP0236, was first published in version 1.0.0 on July 28, 2009, establishing the foundational protocol for transporting management messages across platform components. Subsequent versions introduced progressive enhancements, including improved routing mechanisms through commands like Resolve UUID in version 1.2.0 and better error handling via in version 1.3.0, culminating in version 1.3.3 released on March 25, 2024, which refined address filtering and definitions. Key releases marked significant expansions in protocol capabilities. Version 1.2.0, published on February 4, 2013, incorporated support for the PCIe Vendor Defined Messages (VDM) transport binding (DSP0238), enabling MCTP over high-speed PCIe links. Similarly, version 1.3.1, released on September 4, 2019, aligned with updates to the MCTP IDs and Codes specification (DSP0239), refining message types, endpoint identifiers, and completion codes for greater . Recent developments have extended MCTP's scope beyond core platforms. The MCTP Host Interface (MCHI) specification (DSP0256) reached version 2.0.0 on April 17, 2025, enhancing host software discoverability of MCTP endpoints and supporting integration with emerging interfaces such as USB through complementary bindings. Meanwhile, MCTP 2.0 remains in development as of 2025, focusing on advanced features for Open Compute Project (OCP) platforms, including expanded security and endpoint support. Binding specifications have also evolved to accommodate diverse transports. The serial transport binding (DSP0253) was introduced in version 1.0.0 on July 21, 2010, providing low-overhead communication over serial links. Ongoing efforts include bindings for network-related management, as evidenced by the NC-SI over MCTP binding (DSP0261) version 1.3.1 from August 29, 2024, which encapsulates NC-SI traffic for network controller management. In 2025, new bindings further expanded capabilities, including the PCIe Management Interface over MCTP Binding Specification (DSP0291 version 1.0.0, released June 12, 2025) for PCIe-MI transport and the MCTP PCC Transport Binding Specification (DSP0292 version 1.0.0, released September 8, 2025) for platform component communications. Over more than a decade, MCTP specifications have adapted to emerging technologies, such as NVMe management messages via the binding specification (DSP0235) version 1.0.1 released on August 3, 2018, while DMTF's public review processes have incorporated industry feedback to ensure broad adoption.

Protocol Architecture

Message Format

The Management Component Transport Protocol (MCTP) employs a structured packet format to ensure reliable communication between management components in a platform fabric. The core of each MCTP packet is a fixed 32-bit (4-byte) transport header that encapsulates essential metadata for routing, integrity, and assembly. This header includes a 4-bit Header Version field (set to 0001b for version 1.x compatibility), followed by a 4-bit Reserved field (set to zero). The Destination Endpoint ID (EID) occupies 8 bits (e.g., 0xFF for broadcast), while the Source EID, also 8 bits, identifies the originator (e.g., 0x00 for null source). Additional fields include Start of Message (SOM, 1 bit), End of Message (EOM, 1 bit), Packet Sequence Number (2 bits, increments modulo 4 for fragments), Tag Owner (TO, 1 bit, indicating source-originated tag), and Message Tag (3 bits, for message identification and matching). Following the header, the payload carries the message body, with size limited by the binding (e.g., minimum 64-byte message support, but per-packet limits apply). It begins with an 8-bit Message Type field; value 0x00 denotes MCTP control messages, while 0x01-0x7D are for standardized types (e.g., 0x01 for PLDM), and 0x7E-0xFF are reserved for vendor-defined messages (0x7E for , 0x7F for IANA). For control messages (type 0x00), the body includes a 1-bit Check (IC) flag (1 if integrity data like is present), an 8-bit Command Code, and an 8-bit Completion Code in responses. The message body then carries command-specific data; for instance, the Get Endpoint ID command (command code 0x02) queries an endpoint's assigned ID, and the Set Endpoint ID command (code 0x01) allocates EIDs. Other key commands include Get Message Type Support (code 0x03) for capability queries and Prepare for Endpoint Discovery (code 0x0B) for . These elements enable EIDs to support addressing within the fabric, integrating seamlessly with higher-level mechanisms. MCTP supports fragmentation to handle payloads exceeding transport-specific limits, such as bus transaction sizes, through multi-packet assembly. Each packet includes a 2-bit packet sequence number that increments 4 across fragments of the same message, ensuring ordered reassembly. The SOM and EOM flags (1 bit each) mark the first and last packets, respectively, while an 8-bit byte count field in the first (SOM) packet's message body specifies the total message body length in bytes. This mechanism allows reliable reconstruction even over unreliable or low-bandwidth transports. Control messages, identified by message type 0x00, form the foundation for operations like and configuration. Key examples include the Get Message Type Support message (command code 0x03) for endpoint capability , Set (command code 0x01) to dynamically allocate EIDs during initialization, and fabric messages like Prepare for Endpoint (command code 0x0B), (0x0C), and Notify (0x0D) for topology updates and routing changes. These messages typically follow a request-response pattern, with the response carrying completion status. A distinctive aspect of MCTP's design is the use of SOM/EOM flags combined with the byte count field, which enables robust reassembly of fragmented messages without requiring end-to-end acknowledgments on underlying transports. This approach minimizes overhead while ensuring that incomplete or out-of-order packets can be discarded efficiently, promoting in multi-hop fabrics. Error handling in MCTP responses is standardized through completion codes in control message replies. The Success code (0x00) indicates normal , while the generic code (0x01 for invalid command) signals failures such as unsupported commands or invalid parameters. Additional codes, like 0x02 for invalid data length or 0x05 for unsupported commands, provide granular feedback to aid diagnostics and . Packets failing checks (via IC if present or ) or sequencing are silently dropped to maintain protocol efficiency.

Addressing and Routing

In the Management Component Transport Protocol (MCTP), endpoints are identified using Endpoint IDs (EIDs), which are 8-bit values: 0x00 for null, 0x01-0x07 reserved, 0x08-0xFE for assignable addresses, and 0xFF for broadcast messages. These EIDs are managed by bus owners to ensure uniqueness across the entire MCTP network, with static assignments persisting indefinitely while dynamic ones are reclaimed upon device removal after a timeout period known as T_RECLAIM (transport-binding specific, e.g., 10 seconds for SMBus). Routing in MCTP relies on bridges that forward packets based on the destination EID and the header's Message Tag (3 bits) combined with Tag Owner bit and Source EID, enabling navigation across diverse media types in a multi-bus . This mechanism supports hierarchical fabric topologies, where each segment can accommodate up to 255 endpoints, allowing for scalable multi-hop paths through interconnected buses and bridges. For efficient delivery, tables maintained by bridges map destination EIDs to physical addresses and bus identifiers, facilitating route-to-endpoint resolution without requiring global knowledge of the entire fabric; the tag helps detect loops by ensuring unique message tracking. The uses control messages (type 0x00) for : bus owners initiate by sending Prepare for Endpoint Discovery (command 0x0B) to reset discovery flags, followed by Endpoint Discovery (0x0C) broadcast to query undiscovered endpoints, which respond to request EID assignments if needed. Get Message Type Support (command 0x03, often called "Hello") queries capabilities of known endpoints. Dynamic EIDs are then allocated via commands like Set Endpoint ID (0x01) or Allocate Endpoint IDs (0x04) to integrate new devices seamlessly. Discovery Notify (0x0D) announces changes. This ensures that only valid, responsive receive unique identifiers, supporting initial network configuration as well as ongoing maintenance. To handle hot-plug events such as device insertions or removals, MCTP employs fabric control messages under type 0x00, including Discovery Notify (0x0D) and Get Endpoint ID (0x02), to update endpoint status and trigger re-enumeration. Upon insertion, a new endpoint may respond to Endpoint Discovery broadcasts to request an , while removals are detected through bus owner validation via periodic queries; unclaimed dynamic EIDs are reclaimed after T_RECLAIM, allowing the fabric to adapt dynamically without disrupting ongoing communications.

Transport Bindings

SMBus and I²C Binding

The SMBus and I²C binding for the Management Component Transport Protocol (MCTP) is defined in the DMTF specification DSP0237, with the current version 1.2.0 published on April 6, 2020. This binding maps MCTP packets to SMBus Block Write and Block Read protocols or equivalent I²C transactions, enabling short-range, low-speed communications between management components on a shared bus within a platform, such as servers or embedded systems. In terms of packet encapsulation, the SMBus Block Write transaction begins with the 7-bit slave address (R/W bit set to 0 for write), followed by the Command Code (0x0F for MCTP), Byte Count (indicating the number of bytes following, excluding PEC), then the MCTP header and payload, and ends with the Packet Error Code (PEC). For reads, a Block Read transaction is used similarly. The (EID) is mapped into the source and destination fields of the MCTP header (bytes 6 and 7), allowing up to 255 endpoints per bus while adhering to the 7-bit . Due to SMBus and protocol constraints, each transaction is limited to a maximum of 32 bytes of payload data (including the MCTP header and optional Packet Error Code), encapsulated within a single block transfer. The core MCTP message format is preserved without alteration during this encapsulation. The binding operates on a strict master-slave model, where the Baseboard Management Controller (BMC) typically serves as the bus owner and master, initiating transactions to slave endpoints. Bus ownership ensures coordinated access, with arbitration supported through the mandatory Packet Error Code (PEC), a appended to each transaction for detecting transmission errors and maintaining . Key limitations of the underlying SMBus and buses are addressed through specific adaptations in the . For multi-master configurations, the protocol incorporates fairness to prevent bus contention, while clock stretching—where a slave holds the clock line low to delay the master—is permitted but limited to 250 microseconds per byte to avoid excessive delays. Larger payloads exceeding the 32-byte per-transaction limit are handled via fragmentation, splitting the MCTP message across multiple consecutive SMBus block transactions using start-of-message (SOM) and end-of-message (EOM) flags in the header. Performance-wise, the binding supports bus speeds up to 400 kHz in fast mode (with 1 MHz mode added in version 1.1.0), aligning with SMBus and specifications, which results in transaction latencies suitable for non-time-critical operations. This low-speed profile makes it ideal for in-board control applications, such as adjusting fan speeds based on thermal readings or monitoring voltage levels across components.

PCIe Vendor Defined Messages Binding

The Management Component Transport Protocol (MCTP) PCIe Vendor Defined Messages (VDM) binding, specified in DSP0238 version 1.3.1 published on July 7, 2025, by the (DMTF), defines the embedding of MCTP packets within PCIe Transaction Layer Packets (TLPs) using Vendor Defined Messages for transport over PCIe links. (Earlier version 1.1.0 was published November 29, 2018.) This binding enables management communication in environments by leveraging the PCIe without requiring separate management buses. In this encapsulation, MCTP packets, including the MCTP header and , are placed in the VDM payload field immediately following the standard PCIe TLP header, which includes fields such as the Vendor ID (e.g., 0x8086 for implementations). The binding requires support for a baseline transmission unit of 64 bytes, with optional larger sizes up to PCIe maximum payload limits (e.g., 256 bytes), accommodating the MCTP format while adhering to PCIe TLP constraints, and includes optional elements like the TLP Digest for error checking. Routing in the PCIe VDM binding combines PCIe routing mechanisms—such as Requester ID and Completer ID based on Bus/Device/Function numbers—with MCTP Endpoint Identifiers (EIDs) to direct messages across the fabric. Messages can be routed via the , switches, or bridges, which translate between PCIe segments and handle EID-to-PCIe ID mappings, enabling endpoint discovery and targeted delivery in multi-device topologies. This binding offers significant advantages by utilizing PCIe link speeds, up to Generation 5 rates of 32 GT/s (with support added in version 1.3.0), to facilitate large data transfers such as updates, far exceeding the capabilities of lower-speed bindings. It incorporates native PCIe flow control through credit-based mechanisms, ensuring reliable delivery without additional protocol overhead. The PCIe VDM binding was first implemented in hardware in 2012 with Intel's Ethernet Controller I210 series network interface cards (NICs), allowing over existing in-band PCIe links for enhanced platform control. Extensions of this binding support NVMe for devices, enabling commands over PCIe VDMs as defined in the NVMe Management Interface specification. It also facilitates power state control in environments through integration with protocols like PLDM, allowing efficient of device power profiles across PCIe-connected components.

Applications and Implementations

Platform Management Use Cases

In server environments, MCTP facilitates communication between the Baseboard Management Controller (BMC) and Network Interface Cards (NICs) in Unified Computing System (UCS) M6 generation rack servers, such as the C220M6 and C240M6 models introduced in 2021. This enables efficient platform monitoring and control, including thermal telemetry collection and functions like capping to optimize energy usage across the . As of 2024, UCS M7 rack servers, such as the C220 M7 and C240 M7, extend this support with MCTP over PCIe VDM for enhanced , including with Security Protocol and Data Model (SPDM) for certificate handling and proactive security alerting. In embedded and (OCP) platforms, MCTP supports rack-level management in data centers by enabling fan speed control, LED status indication, and aggregation of sensor data from multiple components. These capabilities allow for centralized oversight of environmental conditions and operational states, improving reliability in high-density deployments. As of October 2024, projects like Caliptra in OCP environments incorporate MCTP with PLDM and SPDM for reference implementations in silicon root-of-trust and device manageability. MCTP provides pathways, permitting the host operating system or firmware to query hardware health metrics, such as temperature and fan speeds, without disrupting primary compute operations. This separation ensures continuous monitoring even during system boot or runtime, leveraging independent hardware resources for robust diagnostics. Through integration with the Platform Level Data Model (PLDM), MCTP handles firmware-level interactions for inventory management and event alerting in hyperscale environments, such as OCP-based data centers. PLDM over MCTP delivers structured data models for discovering and reporting component details, including field-replaceable units, while generating alerts for anomalies like thermal thresholds. In H3C G6 servers, MCTP is deployed via the HDM2 management module to support component discovery in blade systems, where the BMC broadcasts discovery commands over PCIe to identify and assign endpoint IDs to devices like RAID adapters and Fibre Channel host bus adapters. This process spans multiple PCIe root complexes, enabling seamless enumeration across complex topologies. A key benefit of MCTP in these scenarios is the reduction in physical cabling requirements, achieved by management traffic over existing buses such as PCIe Vendor Defined Messages (VDM). This approach leverages high-bandwidth links for efficient data exchange while minimizing infrastructure complexity in dense setups.

Software and Hardware Support

The provides native support for the Management Component Transport Protocol (MCTP) starting with version 5.15, enabling communication through a using the address family AF_MCTP for user-space applications, with SOCK_DGRAM s for message-based transfers. This integration includes a for endpoint discovery and management, facilitating device handling and protocol operations within server environments. As of 2025, enhancements include drivers for MCTP over USB transport (DMTF DSP0283, added February 2025) and over Platform Communication Channel (, DMTF DSP0292, implemented in 2025), expanding support for and ARM-based systems. Hardware implementations of MCTP are prominent in network interface controllers and server platforms. Intel's Ethernet Controller E810 series supports MCTP over SMBus for sideband , including integration with for network controller communication. Cisco's UCS M6 generation servers, released in 2021, incorporate MCTP over both PCIe and SMBus bindings to enable in-platform device and configuration. Broadcom's application-specific integrated circuits (ASICs) in (OCP) NIC 3.0 adapters utilize MCTP for manageability features, supporting protocols like over MCTP to handle Ethernet adapter control within environments. Software tools for MCTP development and testing include open-source libraries such as libmctp, a portable C implementation of the protocol that adheres to DMTF standard DSP0236 for message encoding, decoding, and transport abstraction. The DMTF provides conformance testing programs to validate MCTP implementations, ensuring compatibility across devices through standardized interoperability checks. As of 2025, DMTF has released new bindings including PCIe VDM 1.3.1 (July 2025), PCC Transport (September 2025), and Memory-Mapped Buffer Interface (MMBI, October 2025), enabling broader applications in high-performance and memory-constrained platforms. Vendor ecosystems have adopted MCTP for enhanced platform . Dell's iDRAC and HPE's iLO management controllers integrate MCTP to extend APIs, allowing direct communication with server components for and tasks. Additionally, and firmware leverage the MCTP Interface specification for endpoint discovery, enabling host software to identify and interact with management devices during boot processes. The MCTP Interface 2.0 specification, released as a work-in-progress in May 2024 with targeted expansions in 2025, further improves host-side interactions for modern platforms. Interoperability remains a key challenge, with the DMTF emphasizing rigorous testing to verify compliant implementations and prevent integration issues in multi-vendor environments.

References

  1. [1]
    [PDF] MCTP Overview White Paper - DMTF
    Jul 24, 2007 · The Management Component Transport Protocol (MCTP) supports the PMCI goals by defining a media-independent transport protocol that enables ...
  2. [2]
    [PDF] Management Component Transport Protocol (MCTP) Base ... - DMTF
    Mar 25, 2024 · DMTF is a not-for-profit association of industry members dedicated to promoting enterprise and systems. 14 management and interoperability.
  3. [3]
    MCTP-Based Server Configuration and Management in Cisco UCS ...
    Sep 20, 2021 · Management Component Transport Protocol (MCTP) is a media-independent protocol for intercommunications among intelligent devices in the ...
  4. [4]
    Management Component Transport Protocol (MCTP)
    The core code provides a socket-based interface to send and receive MCTP messages, through an AF_MCTP, SOCK_DGRAM socket.
  5. [5]
    [PDF] Inside the DMTF this month: Message from the President: 15 Years ...
    Sep 20, 2007 · The PMCI Subgroup of the Pre-OS Working Group also prepared a preliminary release 1.0.1a of MCTP IDs and Codes (DSP0239). DSP0239 provides a ...
  6. [6]
    All Published Versions of DSP2016 - DMTF
    All Published Versions of DSP2016. Version, Title, Date, Comments. 1.0.0, Management Component Transport Protocol (MCTP) Overview White Paper, 8 Jul 2007 ...
  7. [7]
    [PDF] Management Component Transport Protocol (MCTP) Base ... - DMTF
    Jul 28, 2009 · DSP0236. 40. DMTF Standard. Version 1.0.0. The internal format that a device uses for organizing the routing table is implementation dependent ...
  8. [8]
    [PDF] Management Component Transport Protocol - (MCTP) Base ... - DMTF
    Jan 24, 2013 · DMTF is a not-for-profit association of industry members dedicated to promoting enterprise and systems. 14 management and interoperability.
  9. [9]
    [PDF] Management Component Transport Protocol (MCTP) Base ... - DMTF
    Sep 4, 2019 · DMTF is a not-for-profit association of industry members dedicated to promoting enterprise and systems. 14 management and interoperability.
  10. [10]
    DMTF Releases MCTP Host Interface 2.0 Specification
    Apr 17, 2025 · DMTF announces the public release of its Management Component Transport Protocol (MCTP) Host Interface Specification version 2.0.0 (DSP0256).
  11. [11]
    [PDF] 2023 Year-in-Review SPDM Releases Updates to its ... - DMTF
    Additionally, PMCI continued their work on MCTP 2.0. This will greatly expand the features, endpoints, and security posture of MCTP, allowing it to be ...
  12. [12]
    MCTP Serial Transport Binding Specification - DMTF
    Jul 21, 2010 · MCTP Serial Transport Binding Specification. DSP #:. DSP0253. Version: 1.0.0. Comments: .pdf file, DMTF Standard. Document Type: Specification.
  13. [13]
    [PDF] NC-SI over MCTP Binding Specification - DMTF
    Jul 24, 2024 · ... Ethernet encapsulation used over RMII. When Ethernet. 687 packets are sent over other mediums, the medium specific error recovery mechanisms ...Missing: ongoing | Show results with:ongoing
  14. [14]
    [PDF] NVMe" (NVM Express") Management Interface over MCTP Binding ...
    Aug 3, 2018 · The specific NVMe. 118 management message contents will be documented outside of DMTF directly by the NVMe Management. 119. Interface working ...
  15. [15]
    [PDF] Management Component Transport Protocol (MCTP) IDs and Codes
    Apr 30, 2021 · DMTF is a not-for-profit association of industry members dedicated to promoting enterprise and systems. 14 management and interoperability.
  16. [16]
    [PDF] Management Component Transport Protocol (MCTP) SMBus/I2C ...
    Jul 28, 2009 · 2. Command Code Command Code: SMBus Command Code. All MCTP over SMBus messages use a command code of 0x0F. Page 20. MCTP SMBus/I2C Transport ...
  17. [17]
    [PDF] MCTP PCle VDM Transport Binding Specification - DMTF
    Nov 29, 2018 · Figure 1 – MCTP over PCI Express Vendor Defined Message ... transport binding for PCI Express™ using PCIe Vendor Defined Messages (VDMs).
  18. [18]
    [PDF] Management Component Transport Protocol (MCTP) PCIe® VDM ...
    Jul 7, 2025 · MCTP PCIe VDM Transport Binding Specification. DSP0238. 4. Published. Version 1.3.1. Figures. 79. Figure 1 – MCTP over PCI Express Vendor ...
  19. [19]
    https://www.pcisig.com/specifications
  20. [20]
    Intel® Ethernet Controller I210-AT - Product Specifications
    $$4.27Intel® Ethernet Controller I210 Series. Code Name. Products formerly Springville. Marketing Status. Launched. Launch Date. Q4'12. Expected Discontinuance. 1H'35.Missing: MCTP | Show results with:MCTP
  21. [21]
    [PDF] Intel® Ethernet Controller I210/I211: Frequently Asked Questions
    Dec 8, 2016 · The I210 supports MCTP in the following combinations: • MCTP over SMBus/I2C Binding. • MCTP over PCIe VDM Binding. • NC-SI over MCTP. 2.13. What ...
  22. [22]
    [PDF] NVM Express Management Interface Specification, Revision 1.2d
    Jan 10, 2024 · In the MCTP Base Specification, the smallest unit of data transfer is the MCTP packet. One or more packets are combined to create an MCTP ...
  23. [23]
    [PDF] PLDM Support in Marvell QLogic Fibre Channel Adapters
    Jun 10, 2025 · document number DSP0236. ▫. Management Component Transport Protocol (MCTP) SMBus/I2C Transport Binding Specification, document number DSP0237.<|control11|><|separator|>
  24. [24]
    [PDF] MCTP and PLDM Enhancements for Advanced OCP Use Cases
    Sep 24, 2024 · DMTF's PMCI specifications provide an extensible, common architecture for standardized communication between management subsystem components ...
  25. [25]
    H3C G6 Servers HDM2 MCTP Technology White Paper-6W101
    Management Component Transport Protocol (MCTP) is a physical media-independent protocol for information exchange among components in a computer system.<|control11|><|separator|>
  26. [26]
    MCTP on Linux introduction - Code Construct
    Jan 18, 2022 · MCTP is a lightweight protocol for server communication. Linux has MCTP support since kernel 5.15, enabling communication via standard sockets.
  27. [27]
    mctp: Add device handling and netlink interface - linux-dev
    Jul 29, 2021 · This change adds the infrastructure for managing MCTP netdevices; we add a pointer to the AF_MCTP-specific data to struct netdevice, ...
  28. [28]
    [PDF] OCP NIC 3.0 Management with NC-SI 1.2 - Rackcdn.com
    The RBT+MCTP management interface supports both the RBT and MCTP standards. This is the preferred implementation. Page 6. OCP NIC 3.0 Manageability Features.
  29. [29]
    openbmc/libmctp - GitHub
    This library is intended to be a portable implementation of the Management Component Transport Protocol (MCTP), as defined by DMTF standard "DSP0236".Missing: compliance | Show results with:compliance
  30. [30]
    Conformance Programs: Supporting Interoperable ... - DMTF
    DMTF conformance programs enable IT vendors to improve interoperability with other products by testing that their products conform to DMTF standards.Missing: MCTP | Show results with:MCTP
  31. [31]
    iDRAC: Redfish API with Dell integrated Remote Access Controller
    This article provides guidance on using the Redfish API with Dell integrated Remote Access Controller.Missing: HPE iLO MCTP UEFI BIOS MCHI
  32. [32]
    Configuring MCTP discovery | HPE iLO 5 User Guide
    MCTP is the industry standard technology iLO uses to communicate directly to options installed in the server. MCTP discovery is enabled by default.Missing: Dell iDRAC Redfish MCHI