OCP 2026: Open Networks Deepen
From switch-chip adaptation to endpoint co-design and platform management
One important past gain of open networking was letting one software stack adapt to different switch silicon. OCP 2026 pushes the route two steps further: host endpoints begin participating much more deeply in traffic distribution, and switch platform management is seeking common interfaces. Bandwidth still matters, but the question most worth tracking this year is, after hardware choice widens, how much of the co-design and management work can be reused with it.
This article reads the changes along three layers. The hardware layer covers how IcePack and IceCube fit more switching capacity into liquid-cooled racks; the fabric-and-endpoint layer uses the FPF multi-plane design as its core to explain why more paths need smarter endpoints; the platform-management layer covers how OSPA reduces repeated adaptation for new equipment. MetaRoCE, UE 1.1, and Falcon are placed back into their respective slots — implementation, standard, and future hardware support — rather than run as one race. [1][2][3][4]
One network software stack now supports more switch hardware
Meta's IceCube switch blade, published this year, provides 102.4 Tbps — double its 51.2T predecessor — inside the IcePack liquid-cooled network rack. It comes in Broadcom Tomahawk6C and NVIDIA Spectrum-6 silicon versions, both running FBOSS and OCP SAI. SAI provides a common interface for software to control switch hardware, keeping a cleaner boundary between silicon choice and upper-layer software. [1]
NVIDIA calls its Spectrum-6 version N-IceCube and confirms it enters the IcePack platform. [2] This is more concrete than "open networking supports multiple chips" in the abstract: operators are trying to organize different switch hardware around one software stack. Public materials support the platform and collaboration judgment, but full delivery cadence, volume, and field-reliability data across all configurations are not disclosed.
More capacity can connect more endpoints under a suitable topology, or reduce the devices and tiers needed for the same scale. It does not automatically accelerate GPU jobs: if endpoint injection capability, optical modules, or uplinks do not move with it, extra switching capacity may sit idle for a while. 102.4T therefore states the connectivity the product acquired; the real gain still has to be traced forward along the data path — to the host endpoints sending the data.
Liquid cooling pulls other conditions into network delivery as well. Blade replacement, manifold maintenance, and cooling faults all have blast radii that must be considered together with network redundancy. Interfaces once handled separately by network and facilities teams now appear in one configuration. Higher thermal density is thus both a scale-up opportunity and a demand for repeatable system design in heat, power, and serviceability.
FPF makes endpoints and fabric jointly decide effective bandwidth
FPF is the most direct case for the second layer. Meta's Flattened Planar Fabric gives each GPU eight independent links into eight network planes, has the NIC distribute packets in hardware, and collapses the original three-tier Clos into two tiers. Meta says the design already runs in its infrastructure and that operational experience is being shared with cloud partners. [1] This is production experience from a real system; link specifics are in the technical notes.
The point is not plane count but that traffic-distribution responsibility moves to the host. Switches provide paths; NICs take part in choosing at send time; hosts need visibility into path state. If one plane withdraws, continuing to spread load evenly onto it wastes working bandwidth; if a plane merely slows, the system cannot cope with "up or down" as the only states. Endpoints and switches must recognize these changes together to actually use the surviving capacity.
An illustrative scenario: one path's capacity drops while others stay healthy. If the network keeps splitting equally, data piles up on the slow path; if senders rebalance the split, the remaining headroom becomes usable. The example shows the co-design problem — it is not a measured FPF failover result. How quickly degradation is detected, and whether rebalancing creates new congestion, both depend on the implementation.
Multipath also changes what receivers see. Packets of one operation may traverse different paths and arrive out of order; some may be lost and retransmitted. The transport must sustain reliable completion under these conditions while applications keep a well-defined, stable communication interface. Topology, transport, and application semantics connect here: different layers that cannot each pick their individually ideal behavior.
This explains why merely adding switch paths is not enough to productize multi-plane fabrics. How the NIC sprays, how switches feed back state, and how the transport handles reordering and loss must be validated in one configuration. For an operator, the comparison that matters is effective communication time at equal GPU scale and load — and behavior after partial path degradation. Line rate under health is one piece of evidence among several.
Transport openness advances on implementation, standards, and hardware support separately
This year's transport news should be read after the co-design needs FPF represents. MetaRoCE's mechanics were public in August 2026; at this summit Meta officially announced the implementation's open-sourcing. Its design centers on per-path state, out-of-order reception, and reliable transport over lossy networks — answering how endpoints use multiple, not-always-perfect paths. [1][5]
The open-sourcing announcement gives adopters a direction for inspecting the implementation; actual adoption still requires confirming code location, version, license, and hardware support. An implementation being available does not make it apply to any NIC; drivers, firmware, test environments, and application completion and error semantics can all become porting work. This article's basis for MetaRoCE's progress is the official announcement — it does not extend to a verified repository or deployable release.
On October 12, UEC formally released Ultra Ethernet Specification 1.1, advancing the common standard. New capabilities cover application-interface compatibility, network participation in collectives, congestion-information passing, and programmable control, plus scale-up-oriented optimizations. It is published by the Ultra Ethernet Consortium and is a different specification from OCP's ESUN; the two organizations' collaboration must not be read as the two version names being interchangeable. What each mechanism does, and its performance boundaries, is in the technical notes — the body text keeps to ecosystem impact: more implementations can build against shared semantics and interfaces. [3]
Falcon represents future hardware cooperation. Google and NVIDIA announced that future ConnectX-10 SuperNICs and BlueField DPUs will support Falcon Transport, combining hardware acceleration with DOCA software and aiming to preserve standard RDMA programming interfaces. This is a product roadmap — it cannot be written as current shipping support across the relevant devices. [2]
None of this proves the transport ecosystem has converged on one protocol. Each item advances implementation availability, common specification, or future hardware support, and each leaves different adaptation work. For teams adopting open networking, the right next step is not picking a name first, but stating which semantics the application depends on, which mechanisms the target endpoints can execute, and then checking what gaps remain between standard and product.
OSPA takes openness into switch platform management
The third layer of change happens outside data forwarding. Meta, Microsoft, and Alibaba initiated OSPA, attempting a common reference architecture for switch platform management. OCP marked its Revision 1.0.0 candidate on October 8 as a contribution under foundation review; it remains a candidate specification, not a finally approved version. [4]
The motive is a specific, repeated cost. Interfaces like SAI help software adapt across switch ASICs, but once the same ASIC lands in different whole machines, power, sensors, device enumeration, and firmware maintenance can still behave differently. Every new hardware model means software teams re-integrate those platform functions. The faster silicon refreshes, the more these seemingly peripheral tasks drag on onboarding speed.
OSPA attempts to unify platform interfaces for power management, hardware access, asset enumeration, environmental control, firmware recovery, and diagnostics. It does not cover routing protocols or forwarding-table control, so it does not replace a network OS like FBOSS. Read it as completing the device-management boundary outside the data-plane interface: software must not only know how to forward, but also reliably identify, monitor, upgrade, and recover the machine carrying the function. [4]
This means different things to different participants. OEMs and ODMs can reuse platform designs and cut per-customer rework; operators gain a chance to onboard more hardware with consistent logging, telemetry, and recovery flows. Whether the benefit lands depends on implementations, testing, and version governance after the candidate stage. An SAI-supporting product is not automatically OSPA-compliant, and a vendor listed among the drafters has not thereby shipped it everywhere.
The practical test of such an open interface is how much work remains when you change suppliers: what software survives, what tests must be redone, which incident procedures need adjusting. Several hardware vendors on the procurement list is only the start; if every swap still takes heavy one-off adaptation, supply choice never converts into operating resilience. OSPA is worth tracking precisely because it targets what sits outside the spec sheet yet repeatedly consumes engineering time.
BAG marks how far open networking still has to go
Larger local fabrics can also extend across buildings and campuses through aggregation layers like BAG. Meta published BAG in February 2026; this summit continued describing its operation and regional backbone — it should be read as extended experience with an existing architecture. Campus, metro, and wide-area must each be discussed separately; sharing the label "scale-across" does not erase differences of distance and control domain. [1][6]
Endpoint control can use existing paths more fully but cannot remove fiber propagation time; multiple planes offer alternative paths but do not guarantee physically independent fiber routes. High-frequency synchronization belongs inside a suitably low-latency range, with cross-domain traffic scheduled by the model's actual communication needs. BAG provides structure for scale; cross-domain effective output still has to be validated under capacity, contention, and failure conditions.
Meta's shared cloud-partner point-to-point and collective testing also shows that consistent interfaces still require joint delivery baselines. [1] Endpoint behavior, congestion policy, telemetry, and version combinations must be repeatedly verifiable before capacity from different sources can be used reliably as one. That requirement applies equally to cross-campus extension and to changing a local network supplier.
The next step is cutting repeated adaptation at endpoints and platforms
The main line of this year's network openness is pushing the reusable boundary outward from switch silicon. IceCube shows one software stack productized across different hardware; FPF shows host endpoints and fabric working together; the transport releases advance implementation, standard, and future hardware support separately; OSPA targets repeated adaptation in whole-machine management. The shared opportunity is that hardware change no longer forces upper layers to start over everywhere.
Builders should therefore define openness as verifiable migratability. After a chip generation or a box vendor change: whether application interfaces stay stable, whether reliable completion survives path degradation, and whether device enumeration and firmware recovery follow common procedures each matter more than counting supported protocols. Releases at different maturity can all be worth tracking — but they enter pilots, product selection, and long-term planning separately.
OCP 2026 does not declare every network layer unified. It makes the next work clearer: keep hardware choice wide while lowering the integration cost of endpoint co-design and platform management. Whoever can prove that portability with clean interfaces, versions, and tests is the one whose open-network solution gets deployed again and again.
Technical notes
Hardware capacity and public-validation caveats
IceCube publishes 102.4 Tbps, 128×800G, in Tomahawk6C and Spectrum-6 versions; IcePack builds on ORV3-HPRv1. The official design image cannot be used to judge that both versions share every structural detail, nor does it prove production volume. [1][2]
Meta's disclosed FPF configuration is eight 100G links per GPU into eight planes — 800G of connectivity in total, not 800G from every plane to that GPU. The topology collapses a three-tier Clos to two tiers, with hosts and switches jointly handling failure control; this operating experience does not by itself guarantee performance for arbitrary customer configurations. [1]
The August 2026 MetaRoCE material disclosed 64-node AMD GPU hardware validation and multi-plane failure scenarios. They support judgment about the mechanism; they do not by themselves prove production metrics at million-GPU or arbitrary wide-area scale. This year brought the official open-sourcing announcement; this article has not verified the repository, version, license, or deployability. [1][5]
What each new UE mechanism solves
UET Verbs compatibility improvements aim to cut application migration cost. Interface compatibility does not mean zero change underneath — the semantics, resource model, and error-handling range an implementation supports still need checking. [3]
In-network collectives (INC) move operations such as reductions into the network. UEC uses reduction and broadcast communication volume to show some processes can move less data, and gives an example of up to 2× communication benefit; that is not a 2× speedup of training or inference as a whole. How much time the application spends on the relevant operations, which operations the switches implement, and whether numerical and failure semantics fit all change the final benefit. [3]
Congestion signaling (CSIG) carries bottleneck information along the path to endpoints, letting control algorithms act on more specific network state; programmable congestion management (PCM) provides a common programming interface for building control policy around workloads. The former improves visibility; the latter improves the expressiveness and portability of control logic — implementing one does not implement all of UE 1.1. [3]
UE 1.1 also includes scale-up-oriented optimizations. It is published by UEC, whose scope and version progress differ from OCP ESUN; the UEC announcement notes the two sides are coordinating the next ESUN release and related endpoint work. ESUN's product and specification progress is covered in the scale-up article of this series. [3]
Compatibility boundaries to pin during adoption
MetaRoCE's official open-sourcing announcement, UE 1.1's formal publication, and the Falcon future-hardware cooperation are different classes of evidence. Similar application interfaces do not replace on-the-wire protocol-compatibility testing, and a published specification does not replace an implementation list for a specific NIC, firmware, and driver. [1][2][3]
OSPA is in candidate review, scoped to switch platform management; routing protocols and forwarding control are out of scope. At the hardware layer, confirm ports, power, thermal, and software versions; at the endpoint-co-design layer, spraying, congestion, and failure handling; at the platform layer, onboarding, upgrade, and rollback. Testing holds workload and reliability targets constant so different combinations can be compared. [4]
Sources and caveats
Information as of October 17, 2026. IceCube is a product platform published this year; FPF is described per Meta's disclosed operating experience; MetaRoCE distinguishes the August mechanics post from this year's official open-sourcing announcement, and this article has not verified code or license; UE 1.1 is released but is not an OCP-owned standard; OSPA is a candidate specification under review; Falcon support is a future product plan. Integration, procurement, and economic judgments in the text are the author's analysis, not vendor performance promises.
[1] Meta, OCP Summit 2026 Powering AI with Open Innovations in Scale-Up Scale-Out and Scale-Across Networks, October 12, 2026.
https://engineering.fb.com/2026/10/12/open-source/ocp-summit-2026-powering-ai-with-open-innovations-in-scale-up-scale-out-and-scale-across-networks/
[2] NVIDIA, Amid Ecosystem Adoption NVIDIA Opens Vera Rubin Architecture to Help Scale AI Factories Worldwide, October 12, 2026, Spectrum-6 and Falcon sections.
https://blogs.nvidia.com/blog/ocp-global-summit-vera-rubin-scale-ai-factories/
[3] Ultra Ethernet Consortium, Ultra Ethernet Consortium Releases Specification 1.1 Advancing AI and HPC Networking, October 12, 2026.
https://ultraethernet.org/ultra-ethernet-consortium-releases-specification-1-1-advancing-ai-and-hpc-networking/
[4] OCP, Introducing OSPA Unifying the Switch Platform Layer for Open Networking, October 8, 2026.
https://www.opencompute.org/news/introducing-ospa-unifying-the-switch-platform-layer-for-open-networking/
[5] Meta, MetaRoCE A New RDMA Transport Built for AI-Scale Ethernet, August 24, 2026.
https://engineering.fb.com/2026/08/24/networking-traffic/metaroce-rdma-transport-ai-ethernet/
[6] Meta, Building Prometheus How Backend Aggregation Enables Gigawatt-Scale AI Clusters, February 9, 2026.
https://engineering.fb.com/2026/02/09/data-center-engineering/building-prometheus-how-backend-aggregation-enables-gigawatt-scale-ai-clusters/