The Optical Module Says Ready. Which Data Paths Are Operational?

Two state machines describe different boundaries

A readiness statement needs an object. OIF's Common Management Interface Specification, version 5.3, distinguishes a Module State Machine from a Data Path State Machine. The first describes the module as a whole, including management-interface initialization and power mode. The second describes the configuration and initialization behavior of a particular data path.

A module has one module-level state machine. Depending on its configuration, it can have one or several data-path state machines. A module-wide ready indication therefore leaves a separate question: which intended data paths have reached their own operational state?

This explanation follows the paged-memory transmission-module model for system-interface applications in CMIS 5.3. Applicability matters: that version's simplified flat-memory model statically reports ModuleReady, and section 6.3.3 limits the data-path model to paged-memory modules. Optional client-encapsulation applications introduce separate Host Path treatment. An equipment report needs its actual module type and supported model identified before these state meanings are applied.

References: [CM1]

An application instance defines the data-path grouping

In CMIS, an Application means a transmission configuration between host-side electrical lanes and media-side lanes. It is typically characterized by a host-interface standard and a media-interface standard. An instance is one implementation of that configuration within the module. This use of Application is distinct from the workload software whose service a buyer ultimately wants to accept.

The data path consists of the host lanes, media lanes and internal module resources implementing that instance. Several lanes can belong to one path. A versatile module can also support several concurrent instances and therefore several paths. The applicable application advertisement and lane allocation establish which grouping is supported.

Neither a front-panel connector nor a host port label supplies that grouping by itself. CMIS can report the same path state on several associated lanes, so several lane entries do not automatically mean several independent paths. It also reports DPDeactivated for unused lanes. Establish membership in the intended application instances before turning a list of lane states into a path count.

References: [CM1]

Read each state at its defined scope

Section 6.3.2.5.6 defines ModuleReady as a steady state. In the paged-memory model, the module is in High Power mode and the host may initialize or deinitialize data paths. ModuleReady establishes the module-level condition that permits those path activities; it does not say that every intended path has completed initialization.

Section 6.3.3.9 defines DPActivated as a steady operational state for a data path. The path has completed initialization and is ready for transmission. Keep the accompanying qualification: Tx outputs can still be automatically squelched, overriding their host-configured output status. Automatic squelching can suppress an output while the path remains in this state.

This qualification fits the broader distinction in section 6.3.3: a data-path state represents configuration realization and should be read separately from current signal conditions and reported output status. DPActivated is meaningful evidence about that local path, but it cannot substitute for evidence of the signal currently presented or received.

DPDeactivated has a different meaning. Section 6.3.3.4 says that no data path is initialized on the indicated lanes. That state does not identify why initialization is absent or diagnose the external fiber.

References: [CM1]

One ready module can contain two different path states

Consider a wholly fictional paged-memory module M. Stipulate a supported system-interface configuration with two intended application instances on separate, nonconflicting lane groups, called paths A and B. These names are teaching labels, not connector numbers, CMIS identifiers or a proposed product mapping.

At one stipulated observation, M reports ModuleReady, path A reports DPActivated and path B reports DPDeactivated. The statements are compatible. M has reached its module-level ready state; A has reached its operational data-path state, with the output qualification described above; B has no initialized data path on its assigned lanes.

The population is one module and two intended paths, with one of those paths activated. Calling the whole module ready preserves only the first fact. Reporting both intended paths as activated would contradict B's stipulated state. Counting the repeated state entries of A's constituent lanes would likewise misrepresent the path population.

One activated path out of two is a state count. It supplies no measured throughput percentage: the example assigns no path rates, traffic load or delivered data. It also provides no evidence of a broken fiber, defective module or failed remote receiver. No transition is attempted, and no cause or corrective action follows from these stipulated labels alone.

References: [CM1]

Carry the local result into the complete connection question

Reading a module identity through its management interface answers an inventory question. It does not select a compatible transmission application. Even a ModuleReady report leaves the exact module, host support, operating mode and optical channel to be reconciled. The related optics-selection guide covers those compatibility decisions; a state label cannot replace them.

An activated local path also leaves the other end unresolved. Remote reception, completion of the host's physical coding sublayer (PCS) and forward error correction (FEC) requirements, traffic delivery and workload behavior need evidence appropriate to those functions. CMIS's local configuration state alone establishes none of those outcomes. The applicable equipment and network owners must define what demonstrates the required connection.

Waveform quantities form another evidence question. A state label supplies neither an average optical-power measurement nor an optical modulation amplitude result. The related average-power and OMA article explains their different meanings. Keep any required quantity, method and acceptance criterion attached to its own result rather than using readiness as a general pass.

For module M, a useful return would preserve the module-level state and the separate A and B states, together with the intended application/lane mapping and observation time. The equipment owner can then compare that return with the required configuration and identify the unresolved question. This retains the evidence without turning an unexplained state into a physical fault diagnosis.

References: [CM1]

Bring the remaining physical question to the service inquiry

If the unresolved question concerns accessible cable identity, labeling or physical connections, Leviathan's Physical-Layer Testing & Installation Verification service is the relevant scope discussion. Identify the affected endpoints and the physical evidence needed so the proposed checks address a defined installation question.

For the project inquiry, share a nonconfidential outline of the affected links, available endpoint and connection records, permitted access and requested physical return. Identify the appointed equipment/network owner who will interpret the module and path states. Formal instrument measurements require confirmed equipment, qualified personnel, method, coverage and acceptance criteria for the engagement.

Use the service and project-inquiry links below to discuss that physical scope. Physical verification returns its agreed observations or measurements; CMIS configuration, fabric bring-up and end-to-end service acceptance remain with their appointed owners. This article explains reported states and does not authorize changes to equipment or a live optical link.