Design Labs — Build the Whole Path

Client side = the 100GbE handoff from the customer router into the Ekinops (grey/short-reach optic). Line side = the DWDM-tuned wavelength from the Ekinops transponder/muxponder out onto the 40 km fiber. Same structure mirrored at both A and B: client Rx/Tx faces the router, line Rx/Tx faces the fiber.

Span loss ≈ fiber attenuation (order of ~0.25 dB/km at 1550 nm → ~10 dB for 40 km) plus connector and splice losses at each junction, plus any patch-panel hops. Sum the span loss and compare against the line optic's receiver sensitivity, keeping a margin (commonly a few dB) for aging and repair splices. If the budget closes with margin, 40 km is a passive span (likely no amplifier needed); if it does not, you add gain or pick a longer-reach optic. Verify exact attenuation and sensitivity numbers against the actual fiber and optic datasheets. The full worked numbers are in the reference solution below.

At 40 km for a single 100G wave, typically no — the span is short enough to be passive if the budget closes, and coherent 100G optics tolerate dispersion electronically. Confirm against the optic's reach spec; do not assume.

Key: λ1 = one DWDM wavelength on the ITU C-band grid. The pair is two strands — one Tx, one Rx — so the service is bidirectional. At 40 km the optical line system (OLS) is passive: mux/demux only, no amplifier. Tx at A must land on Rx at B and vice-versa; a crossed pair is the classic "power is present but link won't come up" fault.

Verdict: PASS. The path needs 18.5 dB (including 3 dB of built-in margin) against a 24 dB system, leaving 5.5 dB of headroom on top. That comfortably closes, so 40 km stays a passive span — no amplifier. Run the same table for B→A; on a symmetric pair the number is the same. Every figure here is a teaching approximation — verify attenuation, connector/splice loss, and the optic's real budget against the actual datasheets.

Slot/port labels are illustrative — read the real ones off the actual chassis. The point is that every physical hop has a named endpoint at both ends, so a tech can patch it and a NOC can reference it on a ticket. λ1 must be the same ITU channel provisioned at both A and B.

1. Fiber acceptance — OTDR/OLTS the pair both ways; confirm measured loss ≤ ~15.5 dB (18.5 budget minus the 3 dB margin) before touching gear.
2. Inspect & clean — scope every endface; both ends LC/APC; never mate APC↔UPC.
3. Install & cable — seat muxponders; patch client (C1) to router, line (L1) to mux/demux, COM to the outside pair. Verify Tx→Rx orientation.
4. Provision — set λ1 (same ITU channel both ends), line rate/format, and the service object in the NMS.
5. Verify power — read line Rx at both ends; confirm it sits inside the optic's expected Rx window and matches the budget prediction.
6. Verify quality — confirm pre-FEC is low/zero and there are no post-FEC errors; check both directions.
7. Confirm client — router link up, traffic passing error-free.
8. Baseline & document — record local/remote Tx/Rx (dBm), pre-FEC, λ1, slots/ports, and file the acceptance record.

Work from the fiber up: power present but out of window = span/optic loss; power in window but errors = quality; all optical-clean = the fault is above the transport layer.

A mux/demux at each end to combine the two wavelengths onto the one fiber (and split them at the far end). Assign the second service a distinct DWDM channel on the ITU grid that does not collide with the first. The fiber now carries two colors; the mux is what lets them share the strand.

You add the insertion loss of the mux and demux to every wavelength's budget. Re-run the budget with the added passive loss; confirm both channels still close with margin. If they no longer do, that is where amplification enters the design.

Pick λ2 from the same DWDM plan the mux/demux supports (ITU-T G.694.1 C-band, e.g. 100 GHz spacing), on a channel the filter actually passes to a distinct port — you can't just tune to any frequency, it must match a filter port. A collision means two services on the same channel (they'd interfere and neither works); adjacent channels are fine as long as each optic stays on its grid point and doesn't drift. Record λ1 and λ2 in the channel-plan register so the next person doesn't reuse a taken channel.

Use a muxponder / OTN grooming: multiplex the 10G clients into ODUs and carry them inside the 100G line container (an ODU4 can carry multiple lower-rate ODUs). The two 10G clients become client ports on a muxponder; their traffic rides the existing wavelength as separate ODU2 tributaries. No new fiber, no new wavelength.

You add two client ports (10G optics) at each end, and two new service objects in the NMS, each mapped to a tributary in the OTN structure of the existing line. The line side does not add ports; the multiplexing is logical.

The optical layer is unchanged — same λ1, same 40 km span, same ~18.5 dB budget — because you're adding logical tributaries inside the existing wave, not new light. The real constraint is container capacity: an OTU4/ODU4 carries ~100G of client. If a full 100GbE already fills it, there is no room for 2× 10G and you need a muxponder that grooms (e.g. 10×10G into the 100G) rather than a straight 100G transponder — or you go to Lab 3 and light a second wavelength. Always confirm the tributary-slot map before promising the capacity.

An OADM (fixed) or ROADM (reconfigurable) at C. It drops the chosen wavelength(s) to local client cards and expresses the remaining wavelengths through on the line. A ROADM lets you choose add/drop-vs-express per wavelength in software instead of re-patching.

The service destined for C is add/drop (terminates on a local client). The A–B services are express/pass-through (they transit C untouched on the line). Draw each wavelength and label it add/drop or express at C.

It adds the OADM/ROADM express insertion loss to every pass-through wavelength, on top of the (now split) fiber loss A–C plus C–B. Even though the total fiber distance is unchanged, the added node loss eats into your margin — re-run the express budget and confirm it still closes. If the added node pushes A–B under margin, that node is where an amplifier earns its place. Fixed OADMs generally add less loss than a full ROADM, which is a real trade-off vs the ROADM's software flexibility.

Ring (or 1+1 over the two ring directions). The service is bridged both ways around the ring; the receiver selects the healthy direction. On a span cut, traffic wraps/steers the other way and the receiver switches with minimal loss.

True physical diversity: the two directions must not share a conduit, handhole, or building entrance, or a single backhoe kills both. Also confirm the protect path's budget closes on its own — it is useless if it cannot actually carry the service.

The switch itself should complete on the order of ~50 ms — fast enough that most upper-layer sessions ride through. But once switched, the service is on its only remaining path with no protection left: the NMS must raise an alarm for "protection unavailable / running on protect path" so someone treats the still-broken working span as urgent. Protection that switches silently and no one repairs the cut is a single fault away from a hard outage. Decide revertive (auto-return when the working path heals) vs non-revertive up front.

Baseline optics (local/remote Tx/Rx in dBm), baseline PM (pre/post-FEC, errored seconds), the service ID, wavelength/channel, and module/slot/port at both ends — stored in the NMS and the acceptance record. Without the baseline, later degradation is un-diagnosable.

The NMS maps the service to its ports, wavelength, and spans, so one fiber alarm immediately tells you which customer services are affected and how big the blast radius is. You troubleshoot the service view, not dozens of raw card alarms — walk the "100G wave is down" steps from the Celestis page.

Run impact analysis on the node/card/span you plan to touch: the NMS lists every service that rides it, so you know the real blast radius before you pull anything, and can tell which customers to notify and which services are currently unprotected (Lab 5). Compare live optics against the captured baseline first, so you can prove the service was healthy going in — and detect if your change moved a power level or pre-FEC.