CMIS explicado: máquina de estados, VDM y firmware
Antes de CMIS, un módulo 400G era una caja negra con un sensor de temperatura atornillado. Después, el módulo es una máquina de estados documentada que puedes interrogar línea por línea.
Pide a tres proveedores «el mapa de registros» de un módulo 800G y obtendrás tres documentos, ninguno completo. Eso no es obstrucción del proveedor; es lo que pasa cuando un módulo contiene ocho líneas, dos imágenes de firmware, una ruta de datos programable y un protocolo de negociación de potencia, y la interfaz de gestión fue diseñada para un mundo de registros fijos. CMIS es la respuesta de la industria —una especificación mantenida junto a las enmiendas PMD IEEE 802.3— y leerla cambia cómo operas estos módulos: lo más concreto, convierte «¿está bien el módulo?» de un ticket de soporte en un script.
El problema que CMIS se creó para resolver
La generación anterior de interfaces de gestión mapeaba las funciones del módulo a direcciones de memoria fijas. Eso funcionaba cuando un módulo era: una ruta de láser de entrada, una de salida, un estado de potencia, quizá cuatro líneas. Un módulo 400G u 800G rompe cada uno de esos supuestos:
- Líneas multiplicadas. Ocho líneas eléctricas que pueden agruparse como un puerto 800G, dos puertos 400G, u otras divisiones, elegidas en software.
- La potencia se volvió negociada. El host debe saber qué consumirá un módulo antes de habilitarlo, por ranura, porque un chasis completamente poblado es un cálculo térmico (ver la guía de selección 800G para dónde muerde eso).
- Los diagnósticos se volvieron más ricos que los registros fijos. Los contadores de error por línea y las mediciones de señal no encajan limpiamente en un mapa estático.
- El firmware se volvió actualizable. Dos imágenes, en ejecución y confirmada, en un módulo pluggable que puede moverse entre chasis.
CMIS responde a las cuatro con un modelo: el módulo es una pequeña computadora con una máquina de estados documentada, y el host le habla en consecuencia.
La máquina de estados es el contrato
La parte de CMIS que explica la mayor parte del comportamiento de campo es el modelo de estados de módulo y ruta de datos. El módulo avanza por estados explícitos, y se espera que el host orqueste las transiciones, no que asuma que el módulo simplemente está «arriba».
| Estado | Qué está haciendo el módulo | Qué debe hacer el host |
|---|---|---|
| ModuleLowPwr | Apagado o inactivo de baja potencia tras inserción | Lee identidad, negocia clase de potencia |
| ModulePwrUp | Consumiendo potencia asignada completa | Espera; no emitas aún comandos de ruta de datos |
| ModuleReady | Listo para configuración de ruta de datos | Configura líneas, luego dispara init |
| Estados de ruta de datos (por grupo) | DPInit → Deinit → Initialized → TxTurnOn → TxTurnedOff → Ready | Sube solo cuando Ready; los fallos de init aparecen aquí primero |
| ModulePwrDn | Apagado solicitado por host | Desmonta antes de la extracción donde se soporte |
Dos consecuencias operacionales vale la pena internalizar.
Los fallos de init son una característica
Cuando un grupo de líneas no alcanza Ready, CMIS te dice en qué estado se quedó atascado. «Atascado en DPInit» es un síntoma muchísimo mejor que «sin enlace», porque usualmente significa una discrepancia de configuración —mapeo de líneas no soportado, tasa no soportada— en lugar de silicio muerto.
El comportamiento de desglose es negociado, no magia
Dividir un módulo 800G en 2x400G es un acto de configuración de ruta de datos. Si tu software de conmutador y el módulo discrepan sobre la asignación de líneas, la discrepancia aparece en estos estados, que también es por lo que el mismo par de piezas que funciona en un chasis puede rechazarse en otro con software más antiguo.
Clases de potencia: una negociación, no una etiqueta
CMIS define clases de potencia para que el host pueda presupuestar por ranura antes de habilitar un módulo. Las clases relevantes para los despliegues actuales:
| Clase | Potencia máxima | Rol en despliegues 2026 |
|---|---|---|
| Clase 5 | 7 W | Piezas de clase 400G, jaulas heredadas |
| Clase 6 | 10 W | Diseños 400G/800G de baja potencia |
| Clase 7 | 15 W | 800G DR8/FR4 convencional |
| Clase 8 | 20 W | Piezas de alta potencia; necesita flujo de aire por ranura verificado |
El mecanismo importa más que los números: el módulo anuncia su clase, el host otorga potencia, y los estados de ruta de datos no se completarán si la concesión nunca ocurrió. Un módulo que arranca en un banco pero se queda en ModuleLowPwr en un slot específico de chasis usualmente te está diciendo que el host se negó o no pudo otorgar la clase —una decisión de presupuesto de slot o de cualificación, no una falla de hardware. La misma telemetría es el pilar del diagnóstico de apagado térmico, donde la clase de potencia y la temperatura medida se leen juntas.
VDMs: la telemetría que detecta láseres que se degradan
Los Vendor Defined Mechanisms son la parte de CMIS con el nombre menos glamoroso y la más valiosa operacionalmente. Proporcionan una forma estándar de exponer mediciones más allá del conjunto obligatorio fijo, direccionadas por descriptor, con unidades y escalado definidos.
| Ejemplo VDM | Qué mide | Por qué te importa |
|---|---|---|
| Potencia TX por línea | Potencia de lanzamiento real por línea | Captura un driver que se degrada antes de que caiga el enlace |
| Potencia de entrada por línea | Potencia recibida por línea | Separa «luz débil» de «conector sucio» |
| Errores de bits pre-FEC / bits corregidos | Calidad del canal antes de la corrección de errores | La señal de desgaste cuantitativa más temprana en una línea |
| Margen señal-ruido | Estimación de calidad del lado del receptor | Predice qué enlaces fallan primero bajo pérdida añadida |
Los conteos de error pre-FEC merecen énfasis.
Los errores corregidos son silenciosos
Los errores corregidos son invisibles para el enlace (para eso sirve el FEC), lo que significa que una línea puede degradarse durante meses mientras el puerto reporta sano. Un script nocturno que muestrea deltas de bits corregidos por línea convierte esa degradación silenciosa en una línea de tendencia, y las líneas de tendencia son lo que te dejan reemplazar un módulo en tu horario en lugar del del enlace.
La disponibilidad de VDM es por pieza
No todos los módulos implementan todos los VDM —el estándar define el contenedor y el contrato de reporte, no una lista de mediciones obligatoria. Parte de la cualificación del módulo es anotar qué VDM expone un SKU dado, para que tu monitoreo no asuma telemetría que nunca estuvo ahí.
Firmware: dos imágenes y un bit de commit
La gestión de firmware CMIS sigue un modelo run/commit que te será familiar del software de conmutador:
- El módulo tiene dos slots de imagen. Una actualización escribe el inactivo, así que una actualización interrumpida deja la imagen en ejecución intacta.
- La activación hace que la nueva imagen esté en ejecución; el commit la hace sobrevivir a los ciclos de potencia.
- La interfaz reporta versiones por slot, que es lo que hace el inventario de flota scriptable.
La disciplina que evita problemas:
Inventario antes de tocar nada
Recolecta versiones en ejecución y confirmadas en toda la flota; las versiones mezcladas son más comunes de lo que nadie admite y son la causa habitual de «un estante se comporta distinto».
Canary, soak, commit
Actualiza en un grupo canario, activa y deja en remojo, haz commit solo después de un periodo de remojo que incluya al menos un reasentamiento y un ciclo de potencia de chasis. Hacer commit el mismo día que la activación es cómo un desajuste de imagen latente se vuelve una sorpresa en toda la flota.
Mantén familias de imagen uniformes por rail
Nunca mezcles familias de imagen a través de un rail —misma regla que mezclar proveedores de módulos, por la misma razón: los umbrales de alarma y el comportamiento de telemetría derivan entre versiones.
Lo que CMIS no resuelve
Tres fronteras vale la pena enunciar para que nadie lo sobrevenda:
- Interoperabilidad. CMIS define la conversación, no el resultado. Dos módulos conformes todavía pueden discrepar con un host de formas sutiles; para eso están las listas de módulos cualificados.
- Calidad física. Ninguna interfaz hace más limpio un conector MPO sucio. Los problemas ópticos siguen viviendo en la planta de fibra.
- Extensiones de proveedor. Todo lo propietario sigue viviendo detrás de páginas específicas del proveedor. CMIS estandariza el piso, no el techo.
Fuentes
- QSFP-DD MSA - CMIS documentation - la Common Management Interface Specification (historial de revisiones, máquina de estados y marco VDM).
- OSFP MSA - contexto de gestión y mecánica para módulos de familia OSFP que usan CMIS.
- OIF - CMIS-LT project - extensiones de link training basadas en CMIS para 800G y más allá.
- IEEE 802.3df Task Force - las enmiendas PMD 800G cuyos módulos gestiona CMIS; útil para ver dónde termina el estándar y empieza la interfaz de gestión.
Los detalles de implementación varían según la revisión CMIS y el proveedor. Verifica nombres de estado, disponibilidad de VDM y comportamiento de firmware contra la revisión exacta de la especificación que implementan tus módulos.
FAQ
- ¿Es CMIS lo mismo que el MSA QSFP-DD u OSFP?
- No. Los MSA definen el envolvente mecánico y eléctrico; CMIS es la especificación de interfaz de gestión publicada a través del mismo grupo de industria y usada en módulos QSFP-DD, OSFP y otros de 100G por línea. Un módulo tiene un factor de forma y corre CMIS: las dos responden a preguntas distintas.
- ¿Cuál es la versión mínima de CMIS que buscar al comprar?
- CMIS 4.0 es el piso práctico para compras 800G: maduró los controles de estado de ruta de datos y los diagnósticos de línea de los que dependen los desgloses y los diagnósticos scriptables. La versión 5.x añade refinamientos en telemetría y manejo de firmware. Las piezas 400G antiguas con implementaciones de era 3.x pueden comportarse de forma inconsistente entre proveedores.
- ¿Qué es un VDM en una frase?
- Un Vendor Defined Mechanism: un contenedor estandarizado para mediciones del módulo que el estándar no fija por adelantado —cosas como conteos de errores de bits pre-FEC por línea— para que los proveedores expongan diagnósticos reales sin romper la interfaz.
- ¿Puede fallar una actualización de firmware CMIS y dejar un módulo inservible?
- Una implementación correcta actualiza una imagen de firmware inactiva y cambia en el commit, así que una actualización interrumpida deja la imagen en ejecución intacta. El riesgo operacional no es dejar inservible un solo módulo; es empujar una imagen no comprometida o desajustada a una flota y darte cuenta solo en el próximo reasentamiento.
- ¿Aplica CMIS también a módulos 100G y 400G?
- Sí. CMIS es agnóstico a la velocidad y aparece en módulos de varios factores de forma de líneas de 100G. Importa más en 400G y superiores porque es donde las rutas de datos multi-línea, las clases de potencia y los desgloses hacen inoperable el modelo de registros fijos anterior.