Initiatives toward Multiple Vendor-sourced Composable Servers in DCI Technology Development

1. Introduction

NTT Software Innovation Center is developing Data-Centric Infrastructure (DCI) toward the implementation of NTT’s Innovative Optical and Wireless Network (IOWN). In the overall architecture defined by the IOWN Global Forum, DCI is positioned as a fundamental layer that enables highly efficient data processing in both distributed datacenter and heterogeneous computing environments. It is one of the essential foundations in the overall architecture of IOWN. We have previously introduced work on the documentation of reference implementation models of DCI functional architecture and compute clusters at the IOWN Global Forum [1] as well as work on the efficient use and power-consumption reduction of hardware resources using DCI as demonstrated at the NTT Pavilion at Expo 2025 Osaka, Kansai, Japan [2]. At NTT, DCI consists of hardware that connects multiple composable servers, graphics processing unit (GPU) servers, etc. via a network and a DCI controller that optimally allocates these interconnected central processing units (CPUs), GPUs, and other resources.

This article focuses on a DCI architecture using composable servers that can flexibly combine and use devices (Fig. 1). A composable server connects a host server and a Peripheral Component Interconnect Express/Compute Express Link (PCIe/CXL) expansion box (resource box) by using a PCIe/CXL fabric switch enabling CPUs, GPUs, storage, and CXL memory to be combined and used with a high degree of freedom (Fig. 2).

Fig. 1. DCI configuration using composable servers.

Fig. 2. Composable server overview.

We at NTT have collaborated with various vendors of composable server products and demonstrated the design and operation of systems that combine products from multiple vendors. We aim to build multiple vendor-sourced composable servers that combine products from multiple vendors and enable the operation of a container infrastructure via DCI controller software.

This article specifically introduces a management standard and framework for multiple vendor-sourced composable servers, including background on their establishment, and notes that are being studied for use in implementing DCI controller software. It also discusses the issues involved in developing multiple vendor-sourced composable servers at NTT. We first introduce a management standard, called Redfish interface, specified by the Distributed Management Task Force (DMTF) [3] for controlling datacenter infrastructure [4], the functions of which are now implemented in servers and network devices. As a framework proposed by the Open Fabrics Alliance (OFA) [5], we then describe in detail the Sunfish framework [6]. This framework can manage composable-server hardware (servers, memory, accelerators, etc.) from different vendors in an integrated and uniform manner via a standard management interface such as Redfish. Since Sunfish provides logical models that enable the management and dynamic composition (lifecycle management) of computing resources independent of a physical configuration, it can be thought of as a service framework that can also be used in the DCI controller software developed by NTT. As of December 2025, the Sunfish version is 0.5, and OFA is working vigorously to release the next set of specifications as version 1.0.

2. Trends in the standardization of multiple vendor-sourced composable servers

We introduce the design of a standard management interface and framework for building and operating multiple vendor-sourced composable servers.

Given the spread of cloud computing, virtualization, and hyperscale environments, the need to automate the management of a large number of servers through a unified application programming interface (API) has grown. At the same time, the Intelligent Platform Management Interface (IPMI) has become widely used as a management interface for servers and other products. However, IPMI is an old standard, drafted in 1998, and has had problems such as being unable to handle a large number of servers via representational state transfer (REST) APIs and being weak in extensibility. Against this background, DMTF standardized Redfish in 2015. Redfish features include a foundation in RESTful API, JSON (Java­Script Object Notation), and HTTPS (Hypertext Transfer Protocol Secure), enhanced security, provision of structured hardware configuration information, and a design that supports scale-out management. The Redfish data model has a tree structure (resource tree) that can be accessed via a hierarchical URI (uniform resource identifier).

Major vendors have adopted Redfish, which is now used for overall management of modern datacenters. A new demand arose for pooling devices within servers and PCIe/CXL expansion boxes in a datacenter (resource pooling), as in the case of composable servers, and for using those devices during dynamic reconfigurations. To meet this demand, DMTF began to add the concept of “composability” to standard specifications in 2017; thus, Redfish became applicable to the control of composable servers [7].

In addition to specifying an interface such as Redfish, OFA Sunfish is another initiative that defines a framework to make it easier to operate composable servers. Sunfish is an open architecture for operating and managing composable servers. It provides a framework for connecting devices such as CPUs, memory, storage, and GPUs over the network and for flexibly combining those devices to configure a logical server. The Sunfish architecture is shown in Fig. 3.

Fig. 3. Sunfish architecture overview.

Sunfish has the following three features:

We first explain the vendor-neutral feature. When each vendor product provides Redfish, the possibility exists that the namespace of each will be duplicated. Sunfish addresses this problem by assigning unique identifiers (IDs) to products within the Sunfish management space. To support products that provide vendor-native APIs or tools, Sunfish provides a layer (Sunfish Agent) to convert these interfaces to Redfish. This corresponds to a repository service design that can manage multiple vendor products in an integrated and uniform manner.

We next explain the second feature, the abstracted resource representation model. In the Sunfish Service, Sunfish abstracts and manages information on servers, storage, and fabric configuration collected via a Sunfish Agent as a Redfish resource tree. In this way, the Sunfish Service is designed so that a system manager or management tool can pool, allocate, and reconfigure resources at the logical level without having to worry about physical matters, such as which servers have GPUs or which memory is connected to which servers.

The third feature is a standards-based open management interface. In this regard, APIs make use of DMTF Redfish and SNIA Swordfish [8]. To enable resource management and logical server configuration through the RESTful APIs that these standards provide, Sunfish is designed to support future extensibility and the integration of heterogeneous hardware.

We now explain the Sunfish management method. The Redfish resource tree that manages the Redfish resource trees of each device is integrated and configured (Fig. 4). When registering with the Sunfish Service, each device is assigned a unique ID within the Sunfish management space. This mechanism prevents the duplication of namespaces in the Redfish resource trees of each device. The client can thus operate on the integrated resource tree based on the IDs assigned by the Sunfish Service. The Sunfish Service also maintains an ID correspondence table, so that when operating on any composable server product under a Sunfish Agent, it requests the operation after converting that product to a namespace ID managed by that Sunfish Agent.

Fig. 4. Resource integration and management by Sunfish Service.

Finally, we explain the flow of creating a logical server using Sunfish. For simplicity, it is assumed that information on the resources required to configure a logical server is already known.

• The client requests the Sunfish Service to create a logical server using the namespace IDs managed by the Sunfish Service.
• On the basis of the client’s request, the Sunfish Service requests a Sunfish Agent having the stated resources to secure those resources for configuring a logical server. At this time, the resource IDs are converted to the namespace IDs managed by the Sunfish Agent.
• Now, based on the request from the Sunfish Service, the Sunfish Agent requests the composable server product to secure those resources.
• The composable server product secures resources according to the Sunfish Agent’s request.
• The Sunfish Service updates the configuration information of its own Redfish resource tree.

In Sunfish, work is also being done on reference implementations, which will include the above device registration function. To implement the above flow for creating a logical server, however, it is necessary to define how the resources held by a Sunfish Agent will be recognized and incorporated into the Redfish resource tree of the Sunfish Service, etc. In terms of architecture, it is necessary to determine which units the Sunfish Agent layer should be configured in.

3. Issues in achieving multiple vendor-sourced composable servers

We believe that we need to address the following two key issues to achieve multiple vendor-sourced composable servers.

4. Future developments

As an initiative toward multiple vendor-sourced composable servers in DCI technology development, we introduced Sunfish, which is currently considered a powerful framework for integration and management. We described its design and pointed out issues in the actual operation of composable servers.

Going forward, we will boost our research and development efforts toward the DCI-2 [9] scheduled for commercialization in FY2026. Specifically, we plan to integrate multiple vendor-sourced composable servers into the DCI-2 system while incorporating the design philosophy of Sunfish. We will also propose functions that are lacking in the current Sunfish specification and its reference implementations to OFA Sunfish and promote the integration and management standard for multiple vendor-sourced infrastructure. On top of that, we will work to enable operations that link multiple vendor-sourced composable servers and a container infrastructure. Since Kubernetes, the de facto standard container infrastructure, has provided a dynamic resource allocation function, work has also begun to integrate with this function to dynamically allocate devices within the resource box of a composable server to a worker node [10], for example. NTT is also participating in this effort. Finally, with the aim of expanding DCI’s operational functions, we plan to develop technologies for mobility use cases that require AI and video processing, as well as other use cases, while pursuing technology development for DCI controller software and proposing system references to the IOWN Global Forum.

References

[1]	K. Ninokata and C. Schumacher, “Data-centric Infrastructure for Enabling Practical Use of IOWN,” NTT Technical Review, Vol. 23, No. 7, pp. 36–42, July 2025. https://doi.org/10.53829/ntr202507fa4
[2]	J. Oka, X. Shi, S. Mizuno, S. Suzuki, Y. Nakazawa, and M. Takagi, “A Pavilion Clad in Emotions: Harmonized Communication Experiences between People and Objects,” NTT Technical Review, Vol. 23, No. 10, pp. 45–50, Oct. 2025. https://doi.org/10.53829/ntr202510fa5
[3]	DMTF, https://www.dmtf.org/
[4]	Redfish, https://www.dmtf.org/standards/redfish
[5]	OFA, https://www.openfabrics.org/
[6]	Sunfish Framework, https://www.openfabrics.org/openfabrics-management-framework/
[7]	Redfish Composability White Paper (DSP2050), https://www.dmtf.org/dsp/DSP2050
[8]	SNIA Swordfish, https://www.snia.org/forums/smi/swordfish
[9]	S. Kinoshita, “IOWN INTEGRAL,” NTT Technical Review, Vol. 23, No. 3, pp. 26–35, Mar. 2025. https://doi.org/10.53829/ntr202503fa2
[10]	CoHDI (Composable Hardware in Disaggregated Infrastructure), https://github.com/CoHDI