IPMI was designed in the late 1990s. Its binary protocol, weak authentication, and vendor-specific extensions had accumulated significant technical debt by the 2010s. Redfish is the DMTF's answer: a RESTful API over HTTPS that replaces IPMI for modern platforms.

{
  "@odata.type": "#ServiceRoot.v1_15_0.ServiceRoot",
  "Id": "RootService",
  "Name": "Root Service",
  "RedfishVersion": "1.15.0",
  "Systems": { "@odata.id": "/redfish/v1/Systems" },
  "Managers": { "@odata.id": "/redfish/v1/Managers" },
  "Chassis": { "@odata.id": "/redfish/v1/Chassis" },
  "UpdateService": { "@odata.id": "/redfish/v1/UpdateService" }
}

Redfish is fundamentally different from IPMI in its architecture:

Transport: HTTPS on port 443, not UDP on port 623. Standard TLS with certificates. No custom session negotiation -- standard HTTP session cookies or OAuth 2.0 tokens.

Data model: JSON responses with a self-describing schema. The API root tells you what resources exist. Resources are navigable via URIs. You do not need to know command opcodes; you traverse a resource tree.

Discovery: GET /redfish/v1/ returns the ServiceRoot, which links to Systems, Managers, Chassis, and other top-level collections. No SDR catalogue needed -- the resource tree itself is the schema.

The Redfish API tree for a DGX H100 looks like this:

GET /redfish/v1/
  -> Systems/               (host CPU, memory, storage inventory)
     -> Systems/1/          (the DGX host system)
        -> Processors/      (Intel Xeon CPUs)
        -> Memory/          (DRAM DIMMs)
        -> NetworkInterfaces/ (the CX7 NICs visible to the host)
        -> Storage/         (NVMe drives)
        -> Actions/
           -> ComputerSystem.Reset  (POST here to power cycle)
  -> Managers/              (BMC management)
     -> Managers/1/
        -> EthernetInterfaces/ (BMC's own 1GbE port IP config)
        -> LogServices/       (event logs)
        -> VirtualMedia/      (ISO mounting)
  -> Chassis/               (physical chassis)
     -> Chassis/1/
        -> Thermal/          (temperature sensors, fan RPM)
        -> Power/            (power supplies, watt readings, efficiency)
        -> PCIeDevices/      (PCIe topology as seen by BMC)

In practice, the transition from IPMI to Redfish is not complete in most DGX deployments. IPMI is still the primary tool for scripted power control and sensor polling because the tooling (ipmitool, Ansible IPMI module, monitoring exporters) is more mature. Redfish is preferred for firmware updates (no IPMI firmware update is reliable for a package the size of a DGX BMC image) and for integration with modern orchestration tools that speak REST natively.

# Redfish examples using curl
# Get system overview
curl -sk -u admin:pass https://10.0.1.10/redfish/v1/Systems/1 | python3 -m json.tool

# Power off (GracefulShutdown keeps OS integrity)
curl -sk -u admin:pass -X POST \
  https://10.0.1.10/redfish/v1/Systems/1/Actions/ComputerSystem.Reset \
  -H 'Content-Type: application/json' \
  -d '{"ResetType": "GracefulShutdown"}'

# Hard power cycle (use when host is hung)
curl -sk -u admin:pass -X POST \
  https://10.0.1.10/redfish/v1/Systems/1/Actions/ComputerSystem.Reset \
  -H 'Content-Type: application/json' \
  -d '{"ResetType": "PowerCycle"}'

# Read all temperature sensors
curl -sk -u admin:pass https://10.0.1.10/redfish/v1/Chassis/1/Thermal | \
  python3 -c "import sys,json; d=json.load(sys.stdin); \
  [print(t['Name'], t['ReadingCelsius']) for t in d['Temperatures']]"

# Firmware update via Redfish MultipartHttpPush
curl -sk -u admin:pass -X POST \
  https://10.0.1.10/redfish/v1/UpdateService/Actions/UpdateService.SimpleUpdate \
  -H 'Content-Type: application/json' \
  -d '{"ImageURI": "http://10.0.1.1/firmware/dgx-bmc-v24.1.bin", "TransferProtocol": "HTTP"}'