New Oracle Acceleron Converged NIC design for Gen AI demand

Gen-2 Oracle Cloud Infrastructure (OCI) has been at the forefront of cloud computing, starting with the industry’s first off-box virtualization that marked a new chapter in how the industry thought about cloud security. 

The relentless pace of innovation in AI cloud infrastructure demands a matching pace of innovation in network architecture — one that delivers on security, performance, and energy efficiency. The Oracle Acceleron Converged NIC (CNIC), the latest evolution of Oracle Cloud Infrastructure’s Gen2 network architecture, represents a monumental leap forward by integrating the host Network Interface Card (NIC) and Cloud Control Computer (CCC) on a single silicon chip with hardware-enforced, static, hardware-level isolation. 

This technical blog explores the motivations behind Oracle Acceleron’s CNIC design, how it reimagines secure and high-performance networking, and the unique benefits it provides to Oracle’s cloud customers. 
 


Brief History 

The first generation of cloud computing adopted a conventional approach to virtualization to enable a multi-tenant environment, implementing virtualization at the OS hypervisor level. However, OS hypervisor-based isolation suffered from a broad attack surface, and hypervisor-level virtualization came with significant performance limitations. 

The OS hypervisor hosted network and storage virtualization components, as well as the cloud control agent. Hypervisor-based network and storage virtualization layers introduced complex attack surfaces and co-hosting the security-sensitive cloud control agent created opportunities for attackers to exploit vulnerabilities in the virtualization layer to gain access to the cloud control plane. 

Recognizing these challenges, Oracle took a security-first approach and introduced the Gen2 network architecture, anchored by a highly isolated hardware component, the off-box Cloud Control Computer (CCC), positioned outside the server to provide storage and network virtualization functionality. 

The cloud control computer is managed by OCI, while the OCI compute instance and host NIC are under the customer’s control. The compute instance and host NIC communicate with the cloud control computer via a simple ethernet cable or equivalent interface. The ethernet cable provides a standard packet interface and nothing more. Packet processing in the CCC is limited to simple and standard packet header parsing, switching, and header rewriting – no dangerous pointer dereferencing and no possibility for the payload to be executed as code. 

The simplicity of the Ethernet interface is central to OCI’s security posture — after all, even the most malicious firmware, malware, or rootkits remain harmless as long as they are treated purely as raw bytes. 

The Gen2 network architecture became the foundation of OCI’s security model and enabled the launch of OCI’s industry-first bare-metal compute instance, allowing customers full access to the physical compute server along with its performance advantages. 

OCI VMs were also built on top of the Gen2 architecture, with off-box virtualization providing an additional layer of security. Even in the rare instance of a VM jailbreak, an attacker cannot reach OCI’s control plane infrastructure because the cloud control computer remains beyond the reach of the hypervisor. 

Challenges with off-box virtualization

Figure 1: Communications between Host NIC and CCC
Figure 1: Communications between Host NIC and CCC. 

Offloading virtualization functions to an off-box cloud control computer (CCC) comes with a few trade-offs: every packet must traverse the host NIC and the cloud control computer.

The host NIC’s chip includes MAC/PHY/SerDes components to send and receive Ethernet packets to and from the cloud control computer. The cloud control computer’s hardware includes two sets of MAC/PHY/SerDes components, one block facing the host NIC and one block facing the network. Essentially, every packet had to go through three sets of MAC/PHY/SerDes blocks.

The MAC/PHY/SerDes layers, combined with the associated transceivers, add additional ASIC footprint and power consumption that scale with bandwidth. These additional ASIC blocks also introduce a small increase in network latency.

Introducing Oracle Acceleron Converged NIC

What if we could preserve the simplicity and narrow attack surface of the Ethernet interface, but without the overhead of extra PHY/MAC/SerDes blocks?

Figure 2: Oracle Acceleron Converged NIC
Figure 2: Oracle Acceleron Converged NIC

The Oracle Acceleron Converged NIC introduces a novel architecture that unifies the host NIC and cloud control computer on a single chip, while preserving the robust, static, hardware-level isolation between the customer-managed NIC and the Oracle-controlled CCC.

With Oracle Acceleron, the host NIC and CCC components are physically on the same hardware chip, and the chip’s resources are hard-partitioned and statically assigned to one of the components at boot time. A minimal, immutable firmware is responsible for statically assigning resources, including memory and compute blocks, to each component. Once bootup is complete, no reallocation or modification is possible; the separation is immutable and enforced by hardware. This ensures a high degree of operational certainty and security assurance.

A key aspect of integrating the NIC and CCC onto the same silicon is the design of the on-chip communication path. Here, the traditional Ethernet cable is replaced by an on-chip Ethernet interface that maintains the same packet-based model but with vastly reduced physical and energy overhead. By refactoring the MAC/PHY into a minimal on-chip channel, Oracle reduces silicon footprint and power consumption, while freeing up resources to deliver significantly higher network bandwidth – currently 400G to 800G for compute and GPU hosts, with plans for even higher speeds.

The on-chip Ethernet interface exposes a minimal attack surface, restricted to header-only packet inspection, simple switching, and header rewriting – no dangerous pointer dereferencing and no way for the payload to be executed as code. With Converged NIC, the Gen2 security posture is preserved: even if an attacker gains control of the host NIC component, they cannot compromise cloud control access.

Additionally, Oracle integrates Root of Trust (RoT) based secure boot and hardware wipe capabilities, ensuring each critical component is securely validated and wiped at startup or decommissioning. This measure protects both Oracle and customer environments from persistent malware or rootkits.

The Oracle Acceleron Converged NIC also enables automatic and secure NIC configuration for native NVMe device presentation to OCI block volumes – directly benefiting customer workloads in high I/O environments.

It further enables automatic firmware validation and seamless, secure updates to the host NIC, strengthening operational resilience and customer trust.

Energy efficiency at hyperscale

Data center energy consumption is under global scrutiny. By consolidating network and control logic into a single silicon platform with optimized power delivery, Oracle Acceleron allows a greater proportion of the total power budget to be directed toward GPUs and AI accelerators.

Reduced data path length, lower peripheral logic overhead, and static resource allocation all contribute to superior power efficiency — without compromising network throughput or security isolation.

Key takeaways

The Oracle Acceleron Converged NIC represents a deep architectural evolution of OCI’s Gen2 network fabric. It collapses the boundary between the host NIC and the Cloud Control Computer into a single piece of silicon – not as a convenience, but as a deliberate engineering decision to improve performance, isolation, and energy efficiency without compromising OCI’s foundational security model.

  • On-Chip Convergence:
    The host NIC and Cloud Control Computer (CCC) are integrated onto a single chip, eliminating the external Ethernet link and multiple sets of MAC/PHY/SerDes components. This reduces latency, silicon area, and transceiver power while maintaining the same packet-based interface semantics.
  • Immutable Resource Partitioning:
    A minimal, immutable firmware initializes the chip and statically partitions all compute, memory, and I/O blocks between the customer-managed NIC domain and the Oracle-managed CCC domain. After boot, no reallocation is possible, ensuring deterministic performance and hardware-level isolation.
  • On-Chip Ethernet Channel:
    The traditional cable interface is replaced by a lightweight on-die Ethernet channel that supports header parsing, switching, and rewriting only. The path remains non-programmable and non-executable, ensuring that payload data cannot cross trust zones as code.
  • Root of Trust Security Framework:
    Integrated RoT logic enforces secure boot, firmware attestation, and hardware wipe on reset or decommissioning. This ensures the integrity of both domains and protects against persistent firmware attacks or rootkits.
  • Performance and Bandwidth Scaling:
    The simplified signal path and reduced transceiver count enable sustained 400G–800G throughput per host, with lower latency and headroom for future link-speed scaling in AI and GPU clusters.

Conclusion

The Oracle Acceleron Converged NIC extends OCI’s Gen2 security model into a new era of integrated, high-performance networking. By merging the host NIC and Cloud Control Computer on a single, immutably partitioned chip, Acceleron eliminates redundant hardware, shortens the data path, and preserves strict hardware-level isolation.

This convergence delivers lower latency, higher bandwidth, and greater power efficiency, all without compromising OCI’s foundational security principles. It embodies OCI’s first-principles approach: secure by design, efficient by architecture, and built for AI-scale performance. 

References