Co-Packaged Optics Market Growth is Driven by AI - GlobeNewswire

Skyler: Hey, welcome back to Line Rate — the show about datacenter fabric, A I interconnect, and the hardware that moves data at the speed that modern A I actually demands. I'm Skyler Monroe, and if you care about what's happening inside the rack, between the racks, and across the datacenter, this is your show. Big thanks to our sponsors — Ada, who helps organizations actually integrate A I into their workflows in a real way, and Zen Semiconductor, an umbrella company with a portfolio of companies across the silicon industry, with Ada in the mix for A I deployment. Alright, today we've got co-packaged optics getting a serious market tailwind from A I, Equinix dropping a new product called Fabric One, a massive market sizing report on datacenter networking through 2035, Cisco making a case for converged north-south networks, and — the one I'm probably most excited about — a deep dive into U E C's credit-based flow control spec. Let's get into it. Skyler: So let's start with co-packaged optics, or CPO if you're abbreviating. There's a new market report out via GlobeNewswire flagging that the CPO market is being significantly driven by A I demand, and honestly, if you've been following this space, that's not a surprise — but the scale of the growth projections is worth talking about. So what is CPO and why does it matter? The traditional way to do optical interconnect in a switch or a router is what's called pluggable optics — you have a transceiver module that plugs into a cage on the front panel of your switch. That's been the model for decades. It works, but it has real limitations around power consumption, signal loss, and density at very high speeds. Co-packaged optics flips that model. Instead of plugging optics in from the outside, you integrate the optical engines directly onto the same package as the switch ASIC — or very close to it on the substrate. What you get is dramatically shorter electrical traces between the silicon and the optical engine, which means lower insertion loss, lower power, and the ability to run at much higher aggregate bandwidth without the signal integrity headaches that come with long PCB traces at high speeds. Now why is A I the driver here? It comes down to bandwidth and power density. A I clusters — whether you're talking about GPU pods or custom accelerator pods — are moving enormous volumes of data between nodes, and they're doing it continuously. The interconnect fabric is not a background concern anymore; it is a primary constraint on training throughput. When you're building out a 100,000-GPU cluster and every switch in that spine layer needs to move multiple terabits per second, the power budget and signal integrity of your optics starts to really bite. CPO addresses both. The leading datapoints from analysts suggest the CPO market could be worth several billion dollars by the early 2030s, growing at a compound annual rate somewhere in the high double digits depending on who you ask. And the companies jockeying for position here include the big optical engine vendors — Marvell, Intel, Broadcom on the silicon side — and specialized optical component makers working on silicon photonics integration. The manufacturing complexity of CPO is still a real challenge. You're integrating optical and electronic components at the package level, which means your assembly yield and thermal management story has to be really tight. But the trajectory is clear — as switch bandwidth targets move past 51 terabits per second and toward 100 terabits and beyond, pluggables start to look like they're fighting physics, and CPO starts to look like the path of least resistance. Skyler: Okay, next up — Equinix. They've announced something called Fabric One, and it's pitched as a simplified connectivity product for A I and cloud workloads. Now Equinix is one of those companies that sits at a really interesting intersection in the datacenter world — they're not a hyperscaler, they're a colocation and interconnection provider, which means their value proposition is about being the neutral meeting point where different networks and clouds come together. Fabric One, from what's been reported, is essentially a unified connectivity layer that lets customers connect to multiple cloud providers, partners, and their own infrastructure through a single Equinix interface. Think of it as abstracting away the complexity of managing separate connections to AWS, Azure, Google Cloud, and so on — you go through Equinix Fabric and they handle the routing and the provisioning. Now for our audience, the interesting angle here is what this means for A I workloads specifically. A I training and inference are increasingly distributed — you might have your raw data sitting in one cloud, your compute in another environment, and your model serving layer somewhere else entirely. That's a lot of data movement across a lot of different interconnection points, and each of those hops adds latency, cost, and operational complexity. What Equinix is betting on with Fabric One is that enterprises and A I-native companies will pay a premium for a cleaner, more unified way to manage that connectivity fabric at the edge of their infrastructure. This is less about raw bandwidth innovation and more about the orchestration and operational layer — the control plane, if you want to think about it that way. From a competitive standpoint, Equinix is doing what colocation providers have to do to stay relevant as more compute migrates to hyperscaler clouds — they're adding a software-defined networking layer that makes their physical interconnection assets more programmable and more useful for modern A I architectures. Whether Fabric One gains traction will depend heavily on how well the API and management experience holds up at scale, and whether enterprise customers actually want a neutral broker for this kind of connectivity or whether they'd rather manage it directly through each cloud's native tooling. But the announcement signals clearly that even the neutral interconnection layer of the internet is feeling the A I pull. Skyler: Alright, let's talk about the market sizing report from Global Market Insights on the datacenter networking market through 2035. I always approach these reports with a healthy dose of skepticism — market research firms have a long history of projecting growth curves that look suspiciously linear and suspiciously large — but they're worth engaging with because they force you to think about what the assumptions actually are. The headline number here is that the global datacenter networking market is expected to reach a very significant valuation by 2035, driven by A I adoption, cloud expansion, and the rollout of 400G and 800G Ethernet infrastructure. Let me unpack what's actually going on in the market that would justify that kind of growth. First, the speed migration cycle. Datacenter networking has been in a pretty relentless upgrade cycle — 10G to 25G, 25G to 100G, 100G to 400G, and now the industry is actively deploying 800G and scoping out 1.6 terabit links. Each of these transitions requires new switches, new NICs, new cables or optics, new ASICs — it's a massive capital refresh cycle, and A I is compressing the timelines. Hyperscalers who might have stretched a switch generation for four or five years are now refreshing faster because the bandwidth demands of A I clusters don't wait. Second, the sheer scale of new datacenter construction. The A I buildout is driving datacenter capacity additions at a pace we haven't seen since the early cloud era. Every new datacenter needs a full networking stack — top-of-rack switches, spine switches, fabric interconnects, out-of-band management networks — and at 800G or 1.6T speeds, the per-port cost is substantial. Third, software-defined networking and the management layer. The networking market isn't just hardware anymore — there's a significant and growing software component around orchestration, telemetry, and intent-based networking that's expanding the total addressable market. The competitive dynamics here favor companies like Broadcom who have a strong position in both merchant silicon for switches and in custom A I accelerator ASICs, but also create opportunities for newer entrants like Marvell on the optical DSP side and startups in the programmable switch space. The 2035 timeframe is useful mostly as a forcing function to think about what the architectural assumptions will be — will we still be on Ethernet, or will something like U E C or UALink have changed the fabric topology significantly? My bet is Ethernet wins the volume game, but the proprietary fabric layer for tightly coupled A I compute clusters remains a contested space for years. Skyler: Now let's get into Cisco's blog post on what they're calling converged north-south networks as the critical path for A I success. This one is interesting because it's a vendor perspective, which means you have to read it with awareness that Cisco has a product agenda here — but the underlying technical argument is worth taking seriously. So quick refresher on the terminology. In datacenter networking, east-west traffic is traffic between servers or racks within the datacenter — that's the traffic your A I training cluster is generating constantly as GPUs talk to each other. North-south traffic is traffic flowing in and out of the datacenter — user requests coming in, data flowing to end users or other datacenters. Historically, these two traffic flows have been managed by somewhat different infrastructure and different teams. What Cisco is arguing is that for A I workloads, this separation is increasingly a liability. The argument goes something like this: A I inference serving — actually running a trained model to respond to user requests — requires very low latency on both the inference compute side and the delivery side. If your inference cluster is sitting behind a network boundary that adds unnecessary hops or policy enforcement points between it and the north-south edge, you're adding latency that degrades the user experience. Conversely, as A I models get larger and serving architectures get more complex — think mixture of experts models, retrieval-augmented generation, multi-modal pipelines — the traffic patterns between inference nodes and the outside world become more dynamic and harder to predict. Cisco's pitch is that converging the management and potentially the physical infrastructure of north-south and east-west networks gives you better traffic engineering across the whole path. From a product standpoint, this plays right into Cisco's portfolio — they sell both the datacenter spine-leaf fabric and the edge and WAN gear, so convergence is a natural upsell story. But the engineering substance is real. The teams I talk to at hyperscalers are absolutely thinking about how A I inference traffic patterns are going to stress the north-south edge in ways that traditional CDN and load-balancing architectures weren't designed for. Whether Cisco's specific implementation is the answer is a different question, but the problem statement is legitimate. Skyler: Okay, and now for the story I've been looking forward to all episode — U E C's credit-based flow control, covered in a really solid piece from Semiconductor Engineering. So let me set the stage. The Ultra Ethernet Consortium — U E C — was formed in 2023 with backing from AMD, Arista, Broadcom, Cisco, Eviden, HPE, Intel, Meta, Microsoft, Oracle, and others. The mission is to define extensions and enhancements to Ethernet specifically optimized for A I and HPC workloads. And one of the core problems they've been attacking is transport behavior — how do you move data reliably and efficiently across a large-scale Ethernet fabric when you're running all-to-all collective operations across thousands of nodes? Traditional Ethernet with TCP was not designed for this. You get congestion, you get tail latency, you get incast problems — where hundreds of senders all try to write to the same destination simultaneously and the buffers blow up. RDMA over Converged Ethernet, or RoCE, helped with latency but has its own congestion management challenges. So what is credit-based flow control, or U E C dash C B F C? At a high level, it's a mechanism where a sender cannot transmit data to a receiver until the receiver has explicitly granted credits — essentially saying "I have buffer space for you, go ahead." This is fundamentally different from the Ethernet model you're used to, where you just send and hope the downstream buffer can absorb it, relying on back-pressure or packet drops to signal congestion after the fact. Credit-based flow control makes the permission to send explicit and proactive. The receiver advertises available buffer capacity, the sender tracks those credits, and transmission only happens when credits are available. This sounds simple but the engineering devil is in the details — how do you manage credit granularity? How do you handle multipath routing where packets from the same flow can arrive out of order across different paths? How do you prevent head-of-line blocking where a stalled credit path for one flow holds up others? The U E C CBFC spec is tackling all of these questions, and the Semiconductor Engineering piece does a good job walking through the architectural choices. What makes this particularly important for A I fabric is that collective operations — AllReduce, AllGather, ReduceScatter — have very specific traffic patterns where you need near-simultaneous high-bandwidth transfers between large numbers of nodes. Getting the flow control right at the protocol level can make a substantial difference in how efficiently those collectives complete, which translates directly into training throughput. Now it's worth being clear — U E C specs are still evolving. This is a consortium working through the engineering tradeoffs in real time. We're not at the point where you go buy a U E C switch and plug it in. But the technical direction is serious, the membership is serious, and the fact that companies like Meta and Microsoft are in the room means the requirements are grounded in actual A I cluster operational experience. The competitive context here is that InfiniBand — specifically NVIDIA's NDR and XDR InfiniBand — has had a dominant position in the tightly-coupled A I cluster market precisely because its transport layer was designed for this kind of workload. U E C is essentially the industry's answer to "what does Ethernet need to look like to compete on equal terms?" And CBFC is one of the core mechanisms that closes that gap. UALink is a related but distinct effort — that's focused on the ultra-short-range chip-to-chip and chip-to-switch links within a rack or pod, where the scale is smaller but the bandwidth density requirements are even more extreme. U E C and UALink are complementary pieces of the same puzzle — getting away from NVIDIA proprietary lock-in on the fabric layer. The progress on CBFC specifically is a meaningful technical milestone. Watch this space. Skyler: Alright, that's a wrap on today's episode of Line Rate. We covered a lot of ground — CPO getting a serious market push from A I, Equinix trying to simplify multi-cloud connectivity with Fabric One, a look at where the datacenter networking market is headed through 2035, Cisco's argument for converging north-south traffic management, and the U E C credit-based flow control spec which is one of the most technically important things happening in A I fabric right now. Thanks so much for listening. Line Rate, brought to you by Ada and Zen Semiconductor — Ada helps businesses integrate A I into their workflows, and Zen Semiconductor is an umbrella company with a portfolio across the silicon industry. If you got value out of this episode, please subscribe wherever you get your podcasts, and share it with the people in your orbit who care about this stuff — the interconnect and silicon community is the right audience and we'd love to grow it. Show notes with links to all the stories we discussed today are at the usual spot. I'll see you next time on Line Rate.