Optical circuit switching and photonics for AI clusters: field guide

The optical switching layer, and why AI is reaching for photonics

An optical circuit switch steers light from one fiber to another without ever turning it back into electricity. That single fact is what sets it apart from every switch most network people have worked on, and it is why the AI data center crowd keeps bringing it up. A normal switch receives light on a transceiver, converts it to an electrical signal, reads the packet headers, decides where the packet goes, and converts it back to light on the far side. An OCS does none of that for the connections it carries. It is closer to a robotic patch panel that re-cables itself on command than to a packet switch.

This guide covers the switching and photonics layer, the part that is changing fastest and is least settled. The topology, how leaf and spine switches form the packet fabric, lives in the spine-leaf guide. The pluggable optics and fiber that wire the GPUs together live in the GPU optics and cabling guide. This guide sits between and ahead of them: what an OCS actually does, why hyperscalers are building reconfigurable optical layers and co-packaged optics, and the hard limits that keep all of it out of the mainstream for now.

Be honest about maturity before you read further. Optical circuit switching in production is led by a handful of hyperscalers, co-packaged optics is shipping in the first vendor products, and most data centers, including most AI builds, still run packet switches with pluggable optics. This is the why and the how, not a buy list.

The problem: optics power and cost at 800G and beyond

The reason any of this is on the table is the optics, not the switches. Every high-speed link in an AI fabric needs a transceiver at each end, and at 800G and the emerging 1.6T those modules are expensive and each draws real power, commonly on the order of 14 to 20 watts or more for the longer-reach types. One module is nothing. An AI cluster carries tens of thousands of links, so the optics become a major line item and a large share of the network's power and heat. The GPU optics and cabling guide covers the per-module figures and the count in depth.

The pressure compounds with scale and rate. Each step up in lane rate tightens the optical margins and pushes more of the cost into the module, and a large share of a module's power goes into the digital signal processor that cleans the electrical signal. As clusters grow, the pluggable optics are becoming a limiting factor on cost and power rather than a detail in the bill of materials.

That pressure is the driver behind both ideas in this guide. Skip the optics entirely for some connections by steering light with an OCS, or move the optics closer to the silicon and strip out the power-hungry parts with co-packaged and linear-drive optics. The exact power and cost figures vary by reach type and generation, so confirm them against the transceiver datasheet, but the direction is not in doubt: the optics are the constraint, and that is what photonic switching is aimed at.

What is an optical circuit switch?

An optical circuit switch is a device that connects an input fiber to an output fiber as a physical light path, and holds that path until it is told to change. No optical-electrical-optical conversion happens inside it. No packet headers are read. The light that enters one port leaves another port as light, steered by a physical mechanism, usually an array of tiny mirrors. Picture a patch panel where the patch cords can be re-routed by software in milliseconds instead of by a technician with a ladder.

Because it carries light straight through, an OCS does not care what rate or protocol rides the fiber. 400G, 800G, InfiniBand, Ethernet, a future rate that does not exist yet, all pass the same way, since the switch never decodes them. That rate-and-protocol transparency is one of the real advantages, and it is why an OCS plant can outlive several generations of the optics plugged into it.

The cost of that transparency is total. An OCS cannot make any per-packet decision, cannot buffer, and cannot inspect traffic, because it never sees the traffic as data at all. It only sees fibers and the connections between them. Everything useful and everything limiting about the device comes from that one design choice.

How MEMS mirrors steer the light

Most production optical circuit switches steer the beam with a MEMS micro-mirror array. MEMS stands for micro-electro-mechanical systems, which here means an array of mirrors each a fraction of a millimeter across, etched in silicon, that tilt under electrical control. Google's published description maps an input port to an output port using two sets of MEMS mirrors that rotate in two dimensions, so a beam from any input can be aimed at any output. Change the mirror angles and you change the connection.

MEMS is not the only approach in the research literature, and other beam-steering and fast-switching schemes exist, but MEMS-based mirror switches are what the at-scale deployments have used. The mechanism sets the character of the device. Mirrors are physical, so they move in milliseconds, not nanoseconds, and once parked they hold a connection passively with no signal processing to run.

That tradeoff between a slow, stable mechanical switch and a fast electrical one is the whole story of where an OCS fits, which the limits section covers. Treat the specific port counts, the insertion loss, and the switching times as vendor figures to confirm against the datasheet, because they vary by device and they are exactly the numbers a sales deck rounds in its own favor.

What is the difference between circuit and packet switching?

An OCS is a circuit switch. It sets up a path and leaves it in place, the way an old telephone exchange connected two lines for the length of a call. A packet switch, the kind that builds a spine-leaf fabric, makes a fresh forwarding decision for every packet, thousands of times a second per port, and can send consecutive packets out different ports. The spine-leaf guide covers that packet fabric in depth.

The difference is not a detail. It decides what each one can do. A packet switch reacts to traffic instantly, balances load packet by packet, and buffers a burst. An OCS does none of that. It has no buffers, no queues, and no per-packet logic, because it is steering light, not forwarding frames.

What an OCS offers instead is a connection with no switching overhead, no transceiver power, and no added latency once the path is set. So the two are not competitors in the same slot. An OCS does not replace the packet fabric. It changes the wiring underneath the packet switches so the fabric can be re-shaped without anyone touching a cable. Read circuit and packet as different jobs, not better and worse versions of one job.

Why AI traffic suits a reconfigurable optical layer

AI training traffic is unusually predictable, and that is what makes an optical layer useful. A training job runs the same collective communication pattern over and over for hours or days: the same accelerators exchanging the same large flows in the same phases. That is the opposite of the bursty, unpredictable traffic a packet switch is built to absorb. When the traffic is known ahead of time and stays put, you can set up optical paths to match it and leave them.

That lets a reconfigurable optical layer do two things. It shapes the topology to the job, wiring the accelerators that actually talk to each other directly rather than forcing every flow up through a shared spine. And it carries the big, steady flows on direct light paths that skip the transceivers and packet silicon a spine layer would add. Google has published that an OCS layer let it remove the spine entirely and connect aggregation blocks in a direct mesh, reconfiguring the logical topology as a routine operation.

The catch is in the first sentence. This works because the traffic is predictable enough to schedule. A workload with unpredictable, latency-sensitive, short-lived flows gets little from an optical layer that takes milliseconds to re-aim, which is why this is an AI and high-performance-computing idea rather than a general data center one.

Where the power and cost savings come from

The savings come from the parts an OCS lets you delete. Every connection that rides a direct optical path instead of passing through a spine switch skips two transceivers and a slice of packet-switch silicon, and those are exactly the expensive, power-hungry parts. Remove a tier of packet switches and you remove their optics, their ASICs, their power draw, and their cooling load.

Google reported its OCS-based network ran roughly 40 percent less power and cost about 30 percent less than the electrical-switching design it replaced, with far less downtime. Those are Google's published figures for Google's network, so read them as a proof point, not a spec you will hit.

The mechanism behind them is sound and general: an optical path that carries light straight through is cheaper and lower power than an electrical hop that converts, switches, and converts back. How much you actually save depends on how much of your traffic is steady enough to live on a held path, which is the part that does not generalize from a hyperscaler to a typical build. The honest version is that the savings are real, the headline percentages belong to the operator who published them, and your number is whatever your traffic and your design produce.

Google's production OCS: Jupiter and the TPU fabric

Google is the clearest evidence that optical circuit switching works at scale, and the published work is worth knowing by name. In the Jupiter data center network, Google added an OCS layer built on its own MEMS switch and used it to remove the spine layer, connecting heterogeneous aggregation blocks in a direct mesh and reconfiguring that topology in software. Google has described moving beyond a static Clos topology as standard operating procedure in that network, which is a real departure from the spine-leaf design the topology guide covers.

The same idea shows up in the TPU machine-learning clusters. Google's TPU pods use OCS between groups of chips to wire a reconfigurable interconnect, so a job can be given a slice of the machine in a chosen topology, and traffic can be routed around a failed component by re-aiming the optical paths rather than by spare electrical switches.

Read these as evidence the approach is deployed and durable, not as a pattern an enterprise can copy off the shelf. The published numbers and the architecture are Google's, Google designs and builds its own switches, and it runs the software team needed to schedule the reconfigurations. That combination is what makes the results possible, and it is exactly what a smaller operator does not have.

The limits: slow to reconfigure, and not per-packet

Here is the part the hype skips. An optical circuit switch is slow to reconfigure compared to a packet switch, by orders of magnitude. A MEMS mirror takes on the order of milliseconds to move and settle, and once you add the control-plane overhead of deciding on a new topology and coordinating the change, the real reconfiguration time runs into the milliseconds and beyond. A packet switch makes a forwarding decision in nanoseconds, for every packet. That gap is not a tuning problem. It is the physics of moving a mirror versus flipping a transistor.

So an OCS cannot steer individual packets and cannot react to traffic in real time. It is for setting up connections that will stay in place long enough to be worth the reconfiguration cost, between jobs or between phases of a job, not for switching flows on the fly. Research into nanosecond-class optical switching exists, but it is not the MEMS OCS shipping in production today, so do not let a lab result set your expectation of a deployed product.

Take one thing from this guide if you take nothing else. An OCS reconfigures the topology, it does not switch the traffic. Anyone who treats it as a faster packet switch has misunderstood what it is, and that misunderstanding is the root of most bad expectations about the technology.

When you can reconfigure, and when you cannot

Because reconfiguration is slow and disruptive to anything riding the affected paths, the question is always when you change the optical layer, not whether you can change it mid-flight. The practical windows are between jobs, when a cluster is being re-partitioned for a new workload, and between phases of a long job, where the communication pattern shifts in a known way. In those windows the cost of a millisecond-scale reconfiguration is paid once and amortized over hours of steady traffic.

What you do not do is reconfigure under live, latency-sensitive flows expecting it to be transparent. Tearing down and rebuilding a path interrupts whatever was using it.

The hyperscaler systems handle this with a scheduler that plans topology changes around the workload, draining and re-routing traffic so the change lands cleanly, which is a substantial software effort in its own right. The slow switch is only half the system. The scheduling and control plane that decides when and how to reconfigure is the other half, and it is the harder half to build. An OCS without that software is a reconfigurable patch panel nobody knows when to reconfigure, so budget the control plane as a real part of the project, not an accessory to the hardware.

What is co-packaged optics?

Co-packaged optics, CPO, attacks the same optics-power problem from a different direction. Instead of plugging optical modules into cages on the front of a switch, CPO puts the optical engines inside the same package as the switch ASIC, right next to the silicon. The electrical signal travels millimeters to the optics instead of inches to a front-panel cage, which removes much of the electrical loss that the power-hungry DSP in a pluggable exists to overcome.

The reported efficiency gains are large. Vendors describe CPO cutting transceiver power sharply against conventional DSP optics, with figures on the order of an 80 percent reduction in transceiver power cited for a full transition, and NVIDIA has claimed several times better network power efficiency per port for its co-packaged photonics switches. The first products are real: Broadcom shipped co-packaged Tomahawk switches in volume, and NVIDIA brought co-packaged InfiniBand to market in early 2026 with Ethernet following later in the year.

This is the most concrete of the emerging shifts, but emerging is the operative word, and part of CPO's transceiver-power saving is offset by adding optical engines and external light sources to the switch. Treat the power figures as vendor claims for specific products and confirm them against the datasheet and your own workload before you plan around them.

What you give up with co-packaged optics

The catch with CPO is serviceability. A pluggable optic that fails is a two-minute swap by any technician: unlatch the module, slide in a new one, done, without touching the switch. When the optics are co-packaged with the ASIC, a failed optical engine is no longer a field-replaceable module. Depending on the design, it can mean pulling the whole switch, because the thing that broke is integrated next to the chip. For a fabric with tens of thousands of optical connections, the failure-and-repair model matters as much as the power number.

That is the open question the industry is still working through, along with multi-vendor supply, thermal design, and the optical coupling and test methods. The ecosystem is not settled. A pluggable optic has years of multi-vendor interoperability behind it. CPO does not yet, which is why the early deployments are at operators who design their own systems and can absorb a new service model.

For a build you are doing now, CPO is a direction to track, not a default. If a vendor pitches it, the questions to ask are blunt: what happens when one engine fails, who else makes a compatible part, and what is the test and acceptance method. If those answers are thin, the technology is not ready for your build yet, however good the power number looks.

Linear-drive optics (LPO): the middle step

Linear-drive pluggable optics, LPO, is the compromise between a normal pluggable and full co-packaged optics. An LPO module keeps the familiar hot-swappable, multi-vendor form factor, but removes the digital signal processor from inside it and lets the switch silicon drive the optics more directly. Since the DSP is a large part of a module's power, dropping it can cut module power meaningfully while keeping the easy field swap that CPO gives up.

Reported figures put LPO at roughly half the power of a conventional pluggable, with vendors describing transceiver-power reductions on the order of a third and a smaller cut to total network power when applied across the back-end fabric. The appeal is that it keeps the operational model the field already knows, so it asks less of the operator than CPO does.

The tradeoff is engineering margin. Without the DSP cleaning the signal, the link depends more tightly on the switch's electrical performance and the channel, so LPO has tighter reach and interoperability constraints than a conventional pluggable. It is best read as an incremental, emerging step rather than a finished standard. Confirm support against the specific switch and module, because an LPO link that works on one host and channel is not guaranteed on another.

Silicon photonics and where the integration is heading

Underneath CPO and much of the new optics is silicon photonics, the practice of building optical components, the waveguides, modulators, and detectors, directly in silicon using chip fabrication. The point is integration and volume. Optics made on a wafer can be packed densely, made in quantity, and placed close to the switching and compute silicon, which is what makes co-packaging and optical I/O practical in the first place.

This is the direction the field is pointed, with the major switch, GPU, and optics vendors all investing in it, but it is a long arc rather than a single finished product. Silicon photonics enables the integrated and co-packaged approaches in this guide, and it is what would eventually let optical connections reach all the way onto the GPU or switch package as optical I/O.

For now, take it as the underlying technology trend that explains why optics keep moving closer to the silicon. You do not specify silicon photonics on a job. You specify the switch or the optic that happens to be built on it. Confirm any specific capability against the vendor, since this part of the field moves fast and the marketing runs ahead of the shipping product.

Wavelength multiplexing and capacity per fiber

Wavelength-division multiplexing, WDM, carries several independent signals on one fiber by putting each on a different color of light. It is mature technology in long-haul telecom, and it matters here for two reasons. It multiplies the capacity of the fiber plant without adding fibers, and silicon photonics can build WDM directly into the waveguides, so more wavelengths per fiber means more bandwidth through the same connector and the same OCS port.

WDM and OCS combine in a useful way. An OCS steers a fiber, and that fiber can carry many wavelengths at once, so one reconfiguration moves a large block of capacity in a single action. WDM also stretches the value of the installed fiber, which matters because re-pulling fiber in a populated AI hall is the outcome everyone is trying to avoid.

How far WDM is used inside the AI fabric specifically, versus the front-end and campus links where it has long been common, depends on the design and the optics. Treat the specifics as design- and vendor-dependent rather than a given, and confirm what a particular optic and switch actually support before you assume the fiber count drops because WDM is in the picture.

An OCS still rides the fiber plant

An optical circuit switch does not remove the fiber, it depends on it. Every port on the OCS is a fiber that has to be run, terminated, cleaned, and tested like any other link in the building, and because the OCS steers whole fibers, the structured cabling underneath it has to be right before the switch can do anything useful.

The MPO connectors, the polarity, the loss budget, and the cleanliness discipline from the GPU optics and cabling guide all still apply, and arguably matter more. A dirty or mis-mapped fiber feeding an OCS port is a fault the switch will faithfully steer to the wrong place, and now you are chasing it through a layer of software indirection on top of the physical plant.

So the OCS is a layer added on top of a sound fiber plant, not a replacement for one. If anything, a reconfigurable optical layer raises the bar on the cabling records, because the physical fiber map and the logical connections the OCS makes are now two different things that both have to be documented and kept in sync. The structured cabling is what the whole scheme stands on, and it is built and tested the same disciplined way it always was.

Reliability, failure modes, and redundancy

An OCS has an appealing reliability story and a real failure mode, and you need both in view. The appealing part: once a MEMS mirror is parked on a connection, it holds that path passively, with no active per-packet processing to crash, and a well-built OCS can lose power without dropping the light path it was holding, depending on the design. Google reported far less downtime with its OCS layer than with the electrical switching it replaced. Fewer active components in the path is genuinely fewer things to fail.

The real part: an OCS is a shared piece of infrastructure that many links pass through, so a failure of the switch itself, or of its control plane, affects everything it carries. That is a concentration of risk a tier of packet switches spreads differently across many boxes.

The answer is the same as for any shared element. Build redundancy into the optical paths and the control so a single OCS or controller failure does not strand a partition. Do not treat the passive-when-parked behavior as a reason to skip redundancy on the optical path, because passive holding of a good path does nothing for you when the controller that sets the paths goes down. Design the failure domains deliberately, and confirm the specific failure behavior against the vendor rather than assuming the best case.

Where do OCS and CPO fit today, and where do they not?

Be blunt about this. Optical circuit switching in production is a hyperscaler technology. It pays off at the scale where a tier of packet switches and its optics is a budget and power line worth removing, and where there is a software team to build the topology scheduler that makes a slow switch useful. Co-packaged optics is shipping in the first vendor switches, mostly into the same class of operator.

For the large majority of data centers, including most enterprise AI builds, the standard packet fabric with pluggable optics is still the right answer, and will be for some time. The reason is not that the technology is bad. It is that the benefits scale with size and predictability, while the costs, the custom software, the new service model, the immature multi-vendor ecosystem, land hardest on smaller operators.

So draw the line by scale and workload. If you run a hyperscale fleet with steady, schedulable AI workloads and the engineering depth to operate a custom optical layer, OCS and CPO are worth serious evaluation. If you run a normal data center, build the packet fabric well, wire it with good pluggable optics, and track this layer as it matures rather than betting a build on it. Assuming photonic switching is a mainstream drop-in right now is the mistake that gets a project in trouble.

Maturity, standards, and the ecosystem

This whole area is emerging, and the standards reflect that. The Optical Internetworking Forum (OIF) is working on the common formats and benchmarks that interoperable optics need, the Open Compute Project (OCP) has published work on optical circuit switching for AI and hyperscale, and the Open Compute Interconnect (OCI) effort, founded by a group that includes AMD, Broadcom, NVIDIA, Meta, Microsoft, and OpenAI, is pushing to make optics the preferred interconnect for AI scale-up. The direction has industry weight behind it.

Weight is not maturity. Co-packaged optics does not yet have a settled, interoperable ecosystem. The mechanical interfaces, the thermal specifications, the optical attach methods, and the test standards are still being worked out. OCS in production is largely on vendor-specific and operator-designed hardware rather than a common standard you can buy from several sources.

This is exactly the stage where you proceed with the vendor, confirm every figure against their datasheet and your own testing, and avoid assuming any of it is a plug-and-play standard. The standards are coming and the consortia are serious. They are not all here yet. Until they are, an OCS or CPO design is a partnership with a specific vendor, with all the lock-in and roadmap risk that implies, and that should be priced into the decision.

The direction: optical I/O and AI scaling

The arc all of this is on is optics moving steadily closer to the silicon, ending at optical I/O, light coming off the GPU or switch package directly. The driver is simple and it is not going away. As AI clusters scale, the count, cost, and power of the interconnect grow faster than the compute, and electrical signaling and pluggable optics are running into limits at each rate step. Light is how the connections keep scaling without the power budget eating the build.

That is why the major vendors are converging on silicon photonics, co-packaged optics, and reconfigurable optical layers at the same time, and why the optical-interconnect market for AI is growing quickly. Whether the path runs through CPO, LPO, more OCS, or optical I/O on the package, the destination is the same: more of the network done in light, less in electricity.

For someone working in the field, the useful stance is to understand the direction, watch the vendor roadmaps and the standards, and not mistake an early product for the finished state. The technology that matters in five years is being built now. The technology you install this year is still mostly packet switches and pluggable optics.

The field reality for most builds today

For nearly everyone doing the work right now, the network is still packet switches and pluggable optics, and that is the right thing to be good at. The spine-leaf fabric in the topology guide and the 400G and 800G pluggable optics in the GPU optics and cabling guide are what you will actually install, test, and hand over on the overwhelming majority of jobs, including most AI clusters. OCS and CPO are coming, and the largest operators are already running them, but they are not what a typical project specifies.

So the practical move is to know this layer well enough to talk about it, plan a fiber plant that could accept it later, and not get sold a reconfigurable optical layer or a co-packaged switch on a build that does not have the scale or the software to use it.

Master the packet fabric and the pluggable optics first. Treat OCS, CPO, and LPO as the layer to understand and track, and to adopt deliberately when the scale, the workload, and the ecosystem all line up. Knowing what these are and where they fit is itself a skill that puts you ahead of the field, even on the jobs that will not touch them for years.

What to record: topology, OCS config, and the fiber map

A reconfigurable optical layer makes documentation harder and more important at the same time, because the physical fiber and the logical topology are no longer the same thing. The fiber map says which fiber is patched to which OCS port. The OCS configuration says which input is currently steered to which output. The active topology is what the packet switches see as a result. All three have to be captured, and the configuration changes whenever the layer reconfigures, so the record has to track the configuration, not just the cabling.

Capture it at the point of work and keep it tied to the physical plant. For each OCS, record the port-to-fiber map, the firmware and control version, the current and intended connection map, and the redundancy scheme. For the optics, keep the per-link records the cabling guide already calls for. A field tool such as FieldOS suits this: capture the OCS port map, the panel photo, and the link test at the cabinet, tie them to the device and the port, and the as-built stays current instead of drifting away from a topology that changes in software.

Common mistakes

• Expecting an OCS to switch packets or react to traffic in real time, when it only steers held light paths.
• Ignoring the millisecond-scale reconfiguration limit and planning to re-shape the topology mid-flow.
• Treating co-packaged optics as field-serviceable like a pluggable, when a failed engine can mean replacing the switch.
• Leaving no redundancy on the optical path, so one OCS or controller failure strands a partition.
• Assuming optical circuit switching or CPO is a mainstream, plug-and-play drop-in right now.
• Documenting only the fiber map and not the OCS connection map, so the logical topology drifts from the record.
• Betting an enterprise build on hyperscaler results without the scale or the topology scheduler that makes them work.

Field checklist

Standards and references

The standards for this layer are partly written and partly in progress, which is itself the headline. The Optical Internetworking Forum (OIF) is developing the common modulation formats, electrical interfaces, and benchmarks that interoperable co-packaged and linear-drive optics depend on. The Open Compute Project (OCP) has published work on optical circuit switching for AI and hyperscale data centers, and the Open Compute Interconnect (OCI) MSA, with members including AMD, Broadcom, NVIDIA, Meta, Microsoft, and OpenAI, is building consensus toward optics for AI scale-up networks. IEEE 802.3 and the InfiniBand specifications still define the Ethernet and fabric rates the optics carry, as the topology and optics guides cover.

The hyperscaler OCS work is documented in Google's published papers on the Jupiter network and its at-scale optical circuit switching for datacenter and machine-learning systems, and the switch and optics vendors, Broadcom, NVIDIA, Lumentum, and others, publish the device datasheets that govern any real design. Hedge the speeds, the reconfiguration times, the power figures, and the maturity to the vendor, the standard, and the emerging state of the field.

Three points hold across all of it. An OCS steers light and skips the optical-electrical-optical conversion for the paths it carries. It is circuit-switched and slow to reconfigure rather than a packet switch. Co-packaged and linear-drive optics cut optics power but are still emerging. Confirm the specifics against the vendor and the standard before any of it goes on a submittal.

Units and terms

This layer carries a dense vocabulary, and the same term can mean different things across a switch datasheet, a research paper, and a cabling submittal.

An OCS is rated by port count and by insertion loss in decibels, and by reconfiguration time in milliseconds. Optical power and loss are in decibels (dB). The transceiver power that CPO and LPO target is in watts per module. Reconfiguration time is the figure that separates an OCS, in milliseconds, from a packet switch, in nanoseconds, so keep the unit in mind whenever someone compares the two.

Optical circuit switch (OCS)

A switch that steers light from an input fiber to an output fiber as a held path, with no optical-electrical-optical conversion or packet processing

MEMS

Micro-electro-mechanical systems; here, an array of tiny tilting mirrors that steer the optical beam inside an OCS

Circuit vs packet switching

Circuit sets up a path and holds it; packet makes a fresh forwarding decision for every packet. An OCS is circuit, a spine-leaf fabric is packet

Co-packaged optics (CPO)

Optical engines integrated in the switch or NIC package next to the ASIC, instead of pluggable modules, for lower power

Linear-drive optics (LPO)

A pluggable optic with the DSP removed, driven directly by the switch silicon, for lower power while keeping the hot-swappable form factor

Silicon photonics

Optical components built directly in silicon by chip fabrication, the basis for dense optical integration and co-packaging

OEO conversion

Optical-electrical-optical conversion, turning light into an electrical signal and back; what an OCS skips and a packet switch must do

WDM

Wavelength-division multiplexing, carrying several signals on one fiber by using different colors of light

Related tools

Calculators and readiness checks for this work

Compare your options

FAQ

People also ask

• What is a spine-leaf network?
• What is the GPU back-end fabric?
• Why does AI need fast storage?
• What is data center interconnect (DCI)?
• What is the difference between open and closed transition transfer?