Provisioning & Onboarding — From New Node to Live Wave

This is the hands-on core of the operate track: bringing a node under management, letting the NMS discover what it is, and then turning up an actual end-to-end service — choosing endpoints, rate, and wavelength, mapping client tributaries into the line signal, activating, and verifying that the light is not just present but good. We walk the node-onboarding sequence, the service-provisioning sequence, and the OTN client-to-line mapping that trips up newcomers, with a worksheet and a verification checklist you can run on the job.

Mental model Provisioning has two halves that people conflate. Onboarding is teaching the management system that a node exists and reading back what hardware is in it — pure discovery, no service yet. Service provisioning is defining a customer's end-to-end path as an object and letting the NMS push the cross-connects and mappings down to the cards. Onboard the box first; provision the service second. You cannot provision onto a node the NMS cannot see.

Scope & accuracy note This page teaches the steps and their purpose, not a click-path. Exact Celestis/NMS menu names, wizard order, field labels, and CLI syntax change between releases — everything shown as a menu name, CLI line, worksheet value, or reading is representative/illustrative and uses a generic format, not captured data. Verify exact UI, workflow order, capacities, and compatibility against current official Ekinops / Celestis documentation. Functional card/optic terms are used deliberately in place of model names.

Track your progress

I can onboard a node: reachability, credentials, add, discover shelf/cards/ports I understand topology/link discovery and what it produces I can list the service-provisioning step sequence in order I can explain OTN client→ODU→line OTU mapping concretely I can fill in a provisioning worksheet before touching the NMS I can verify a new service on power, OSNR, and FEC — not just "link up"

Part 1 — Onboarding a node into the NMS

Onboarding is a strict prerequisite chain: you cannot add a node the NMS cannot reach, cannot manage a node whose credentials you do not have, and cannot provision onto a node whose shelf has not been discovered. Do them in order; each step gates the next.

#	Step	What you are establishing	Verify before moving on
1	Management reachability	IP/routing/DNS from the NMS to the node's management interface; firewall/ACL open for the management protocol.	Ping/management-protocol reachability from the NMS host succeeds.
2	Credentials	Management account/community/keys the NMS will use; role that permits read + provision.	A test session authenticates and can read inventory.
3	Add the node	Register the node object in the NMS with its address and credential profile.	Node appears, state transitions toward "managed/up".
4	Discover shelf / cards / ports	NMS enumerates slots, card types, serials, firmware, and per-port role/optic.	Discovered inventory matches the physical shelf (reconcile drift).
5	Topology / link discovery	NMS learns the fiber spans and neighbour relationships between managed nodes.	Expected spans/neighbours appear; unexpected/missing links investigated.

Illustrative The lines below are generic-format placeholders to show the shape of what you check — not real command output. Verify actual syntax and output against current official documentation.

1) reachability check from NMS host $ ping mgmt.node-a.example -> reply, low latency, no loss 2) credential test (generic) auth OK, role = provision, inventory readable 3) after "add node": node state node-a state: managed/up fw: vA.B.C 4) discovery result (shape only) node-a slot 1 100G muxponder SNXX-MXP-0114 C1(client) L1(line) slot 3 10G transponder SNXX-TXP-0231 C1(client) L1(line) slot 5 line amplifier SNXX-AMP-0077

Topology & link discovery — what it produces

Once two or more nodes are managed, the NMS builds the topology: the element view (nodes, shelves, cards, spans) and the ability to bind services onto it later. Link discovery infers the fiber spans between nodes — sometimes from the optical supervisory channel, sometimes from manual span definition. The output you care about is a correct map: every real span present, no phantom links, and neighbours matching the as-built. A wrong topology poisons everything downstream — correlation, impact analysis, and path selection during provisioning all trust it.

Key idea Onboarding ends when the NMS's picture matches reality: the right cards in the right slots, the right spans between the right nodes. Reconcile every discrepancy now. Provisioning a service on top of a wrong inventory or topology is building on sand.

Part 2 — Service & wavelength provisioning (step sequence)

With the nodes onboarded and the wavelength plan in hand (from the design/engineering track), a service turn-up is a repeatable sequence. Do not improvise the order — each step depends on the previous, and verification lives at the end where it belongs.

Select endpoints. Choose the A and Z nodes/cards/ports the service runs between. This defines the service object and its intended path across the topology.
Choose transport rate & optic. Pick the line rate/modulation and confirm the line optic supports it and the span reach. This is where the compatibility work from the BOM pays off.
Assign wavelength / channel from the plan. Set the line optic (tunable) or confirm the fixed channel to the specific wavelength the plan allocated, and confirm the OADM/ROADM/mux passes that channel end to end.
Configure client ports. Set the client-side rate/encoding to match what the customer presents, and confirm the client optic is the right grey type.
Map client to line (OTN). For muxponders, define which client tributaries map into which ODU into the line OTU (Part 3 below).
Activate. Push the configuration; the NMS realises the cross-connects/mappings on the cards and brings the service in-service.
Verify. Confirm optical power (Tx/Rx) within window, OSNR/Q where available, and FEC clean (pre-FEC within margin, zero post-FEC), plus zero errored seconds. Capture this as the turn-up baseline.

Illustrative Menu names and field labels for each step above vary by NMS release. Treat any specific screen/label you see in training material as representative — confirm the actual workflow against current official Celestis/Ekinops documentation before executing on a live network.

Part 3 — OTN client-to-line mapping, concretely

This is the concept newcomers stumble on. A muxponder takes several client signals and carries them across the line inside one higher-rate OTN wrapper. The mapping is a strict containment: each client tributary is wrapped into an ODU (Optical Data Unit) of the appropriate size, those ODUs are multiplexed into a higher-order ODU, and that is carried in the line OTU (Optical Transport Unit) on the assigned wavelength. Get the mapping right and the service is deterministic; get it wrong and clients cross-connect to the wrong tributary.

CLIENT SIDE OTN MULTIPLEX LINE SIDE (grey optics) (containers) (coloured optic) 10G client #1 --> ODU2 --\ 10G client #2 --> ODU2 ---\ 10G client #3 --> ODU2 ----+--> ODU4 (higher-order) --> OTU4 --> line 10G client #4 --> ODU2 ---/ wavelength (ch. from plan) 100G client --> ODU4 -----------------------------> OTU4 -----> line client tributary -> ODU (right size) -> multiplexed -> OTU on the wave

Illustrative mapping only — exact ODU types, multiplex structure, and line OTU capacity depend on the specific muxponder and standard. Verify against current official Ekinops documentation and the OTN standards. See the Engineer track's OTN Mapping page for the full container hierarchy.

Representative mapping table

The artifact you produce for a muxponder turn-up is a mapping table: every client tributary, the ODU it lands in, the tributary slot(s) it occupies in the line OTU, and the line wavelength. This is what you fill in on the worksheet and confirm after activation.

Client port	Client rate	ODU container	Line OTU	Trib slot(s)	Line wavelength
C1	10G	ODU2	OTU4	1–8	ch. λ-plan-12
C2	10G	ODU2	OTU4	9–16	ch. λ-plan-12
C3	10G	ODU2	OTU4	17–24	ch. λ-plan-12
C4	10G	ODU2	OTU4	25–32	ch. λ-plan-12

Representative/illustrative tributary-slot assignments in a generic format — not captured configuration. Exact trib-slot numbering and ODU multiplexing depend on the card and standard; verify against current official Ekinops documentation.

Key idea The mapping must be symmetric end to end: client C1 at site A must land in the same ODU/trib-slots that C1 at site Z expects to pull out. Mis-matched mapping is a subtle failure — light is present, FEC may be clean, but the client sees the wrong traffic or a mismatch alarm. Confirm both ends' mapping tables agree before you call it up.

Representative provisioning worksheet

Fill this in before you open the NMS. Walking up to the provisioning screen with an incomplete worksheet is how you assign the wrong wavelength or the wrong trib. Values below are illustrative.

Field	Value (illustrative)	Source / check
Service ID / customer	SVC-100G-A2Z-0007	service request
A endpoint (node/slot/port)	node-a / slot 1 / C1	design + inventory
Z endpoint (node/slot/port)	node-z / slot 1 / C1	design + inventory
Client rate / optic	100G / grey client optic	customer handoff spec
Transport rate / modulation	100G coherent line	design, reach-checked
Line optic (fixed/tunable)	tunable line optic	BOM
Assigned wavelength / channel	ch. λ-plan-12	wavelength plan (no clashes)
OTN mapping (client→ODU→OTU)	C1→ODU4→OTU4	mapping table, both ends agree
Expected line Rx / Tx	Rx ~ -18 dBm / Tx per spec	loss budget
Protected?	no (or scheme + backup path)	service request
Maintenance window	approved, customer notified	change control

Illustrative worksheet — all identifiers, channels, and readings are placeholders. Verify exact SKUs, capacities, wavelength plan, and compatibility against current official Ekinops documentation.

Verification — prove the wave is good, not just present

"Link up" is the weakest possible acceptance. A service can show up while running with almost no margin. Verify presence and quality at turn-up, and record every number as the baseline for future drift detection (see the Monitoring page).

Common mistake Accepting a service the instant the client interface blinks up. Do a soak — watch power, pre-FEC, and errored seconds over a real interval before you hand over. A marginal service (Rx a few dB low, pre-FEC near the limit) will pass a five-second glance and fail the customer a week later. The turn-up reading is also your only clean baseline; if you skip it you have nothing to compare against when it drifts.