Compliance codes: bytes 3–10, 36 & extended tables

A host does not know what a module is from its vendor name — it knows from the compliance codes: bit fields that say "I am 10GBASE-LR" or "I am a 1000BASE-T copper SFP", plus a single extended code for everything invented after the bit fields ran out of room. Hosts use them to name the module type, decide which speeds to offer, choose FEC and breakout, and — on strict platforms — to refuse a module whose codes do not match the port. Getting them right is the single most important part of coding a module.

Two generations of coding

A 25G or 100G module leaves most classic bits clear and puts its identity into byte 36 or 192; a 10G/1G module does the opposite. Dual-rate 10G/25G modules use both.

SFF-8472 bytes 3–10 (SFP family)

Byte 62 (Fibre Channel speed 2) continues the speed list for 64GFC and above. Byte 36 holds the extended code. Byte 12 gives the nominal rate in ×100 Mb/s (FFh → byte 66 in ×250 Mb/s), byte 11 the encoding, byte 13 the rate identifier for rate select.

Typical SFP codings

The length bytes 14–19 must agree: an SR module declares OM3/OM4 reach, an LR module kilometres, a DAC metres in byte 18.

SFF-8636 bytes 131–138, 164 (QSFP family)

Typical: 40GBASE-SR4 → byte 131 = 04h, byte 192 = 00h; 100GBASE-SR4 → byte 131 = 80h (extended), byte 192 = 02h; 100G CWDM4 → 80h / 06h; 100GBASE-CR4 DAC → 80h / 0Bh with connector 23h.

CMIS — applications instead of bits

A CMIS module lists up to 15 applications, each pairing a host electrical interface with a media interface (both SFF-8024 codes) and stating lane counts. A 400G DR4 module might advertise 400GAUI-8 ↔ 400GBASE-DR4 (8:4) and 100GAUI-2 ↔ 100GBASE-DR (2:1, for 4×100G breakout). The host selects one per data path; whatever is not advertised cannot be configured. Details and the selection flow: CMIS.

How hosts use the codes

• Naming — the type string on the CLI (10GBASE-LR, QSFP-100G-SR4) is derived from these bytes, often the first set bit found in a fixed order.
• Speed offering — a host lists only rates whose code is present; a 25G module with byte 36 = 02h but no byte 3 bit will not be offered 10G (Speed & rate).
• FEC selection — extended codes carry the FEC assumption (CA-25G-L/S/N; CAUI-4 with or without RS-FEC) and some hosts set FEC from them (FEC & link training).
• Copper vs optical — byte 8 bits 2–3, connector 23h and byte 147 copper technologies switch the host to DAC handling (auto-negotiation, link training).
• Policy — strict platforms compare codes with the port's mode and with their compatibility database; a mismatch yields unsupported or speed and type not supported even when the vendor block is accepted (Vendor lock).

Coding rules

1. Set only bits the hardware truly satisfies; declaring 10GBASE-LR on an SR module turns "no link" into "link with errors".
2. Keep the whole identity consistent: compliance ↔ wavelength ↔ lengths ↔ encoding ↔ nominal rate ↔ connector ↔ transmitter technology.
3. For 25G+ fill byte 36 / 192 and set byte 12 / 140 to FFh with the ×250 Mb/s rate in byte 66 / 222.
4. For DAC, code the cable technology bits, the length in metres, connector 23h and the attenuation/compliance bytes instead of a wavelength.
5. Recalculate the checksums afterwards (Checksums).

In CodingBox

The Check transceiver screen decodes every bit above into plain names and lists CMIS applications; the EEPROM editor edits the code bytes field by field, shows the resulting type string, and fixes CC_BASE and CC_EXT on write.