Resumen

  • RFC 1595 organizó la evidencia por Section, Line, Path y VT, por extremo cercano o lejano y por intervalo actual o completado. El entero aislado no conservaba su objeto de medida.
  • La indisponibilidad empezaba con el primero de diez SES consecutivos. Si la secuencia atravesaba el cambio de cuarto de hora, dos lecturas del intervalo anterior podían devolver distribuciones diferentes de SES y UAS.
  • RFC 2558 y RFC 3592 permitieron corregir los contadores expuestos en tiempo real o retener las observaciones en una línea de demora de diez etapas. Rapidez y primera lectura inmutable exigían políticas distintas.

La fila histórica que todavía esperaba nueve segundos

Pensemos en una secuencia grave que comienza poco antes del cambio de intervalo. Al llegar el minuto quince, el periodo pasa a ser el intervalo 1, el más reciente completado. Un gestor puede leerlo. Sin embargo, el agente aún no sabe si los segundos finales formarán una serie de diez SES.

Cuando llega el décimo, la indisponibilidad no empieza en ese instante: se sitúa en el primero de la serie. Si ese primer segundo pertenecía al periodo anterior, parte de la clasificación histórica debe cambiar. RFC 1595 advertía que GET sucesivos durante los primeros segundos de la ventana nueva podían producir valores distintos en SES y UAS de Path, Line o VT.

No cambió el pasado físico. Cambió la conclusión que podía extraerse de él. La equivocación sería conservar la primera respuesta sin hora de consulta ni versión y llamarla resultado final por el mero hecho de estar en la tabla histórica.

Un estado decidido por una secuencia

En Line, Path y VT, diez SES consecutivos declaran indisponibilidad desde el primer segundo, y los diez cuentan como UAS. Para recuperar disponibilidad hacen falta diez segundos seguidos sin SES; esos diez quedan fuera del tiempo indisponible.

Mientras la capa está disponible avanzan sus contadores de error. Durante la indisponibilidad, solo avanza UAS en esa capa. Por eso la espera no es un simple amortiguador de alarmas: decide a qué categoría pertenece cada segundo. El estado atraviesa la frontera de 15 minutos aunque los contadores cambien de fila.

Capa, extremo y byte de origen

No todo equipo SONET/SDH termina todas las capas. Un regenerador puede terminar solo Section; multiplexores add-drop y sistemas de conexión digital terminan Line; un multiplexor terminal puede alcanzar Path y VT/VC. La MIB representó esas superficies mediante entradas y una pila de interfaces.

Las violaciones de Section procedían de B1, las de Line de B2, las de Path de B3 y las de un VT flotante de V5. LOS, LOF, AIS, LOP y RDI también tenían capas propias. Un panel puede sumar “errores del circuito”, pero la suma no localiza dónde surgió la evidencia.

El estado down tampoco era una causa. La entrada combinada Medium/Section/Line dependía de defectos de Section o Line; una entrada Path dependía de su estado Path. La proyección servía para operar la tabla de interfaces, no para identificar por sí sola el componente averiado.

La separación continuaba entre extremos. Las estadísticas lejanas de Path se obtenían a través de la indicación FEBE en el byte G1. RFC 2558 indicó además que debían marcarse como ausentes los segundos remotos cuando un defecto entrante afectaba esa capa o una inferior. Ausente no significa cero. Sustituir uno por otro convierte la pérdida de visibilidad en una falsa prueba de limpieza remota.

Dos maneras de pagar la certeza

RFC 2558 detalló la primera opción: actualizar en tiempo real y poder ajustar retroactivamente ES, SES, SEFS, CV y UAS cuando termina la secuencia de diez segundos. Si la secuencia cruza el límite, la corrección alcanza la ventana previa.

La segunda opción usa una línea de demora de diez elementos. Las observaciones de cada segundo esperan hasta que su estado sea conocido y solo entonces alimentan los contadores. La historia sale estable desde la primera lectura, pero diez segundos por detrás del mundo físico. RFC 3592 mantuvo esta estructura en 2003.

Una plataforma seria no llama corrupción a la revisión ni lentitud accidental al retraso sin averiguar qué política implementa el agente. La forma rápida necesita versiones. La forma estable necesita declarar latencia.

RFC 2493 añadió información de integridad: tablas actuales, históricas y agregadas separadas, tiempo transcurrido, intervalos válidos e inválidos. Tras un reinicio o una laguna de proxy puede haber menos historia. Los 96 intervalos eran el máximo de 24 horas; RFC 1595 exigía al menos cuatro y usaba 32 como valor predeterminado.

Una notificación sobre un momento anterior

Los sucesores también exigieron que linkDown se enviara cuando el agente ya supiera con certeza que había entrado en indisponibilidad, pero con la hora efectiva del primer UAS, unos diez segundos antes. Para linkUp se aplicaba la misma idea.

La hora de emisión conserva cuándo se obtuvo conocimiento suficiente. La hora efectiva conserva dónde sitúa la máquina de estados la transición. Si se elimina cualquiera de las dos, se inventa o una detección inmediata o un comienzo tardío.

Hasta la palabra “grave” tenía procedencia

RFC 2558 documentó que distintas normas usaban umbrales SES diferentes y creó sonetSESthresholdSet. Un agente no estaba obligado a soportarlos todos. Cambiar el conjunto invalidaba las estadísticas SES anteriores.

La comparación histórica necesita, por tanto, capa, extremo, ventana, validez, hora de lectura y conjunto de umbrales. Un salto en el gráfico puede proceder de una nueva semántica y no de una señal peor.

Running-Code Primacy, de Lu Heng, obliga a unir el símbolo con lo que el sistema ejecutó y observó. Minimum Initial Specification reserva al contrato común el significado mínimo comparable, dejando visibles las decisiones locales de retención y respuesta. Why BTW.Media Exists impone la disciplina editorial de publicar ausencias, revisiones y retrasos antes que convertir el primer número en una tesis interesada.

La frontera de 15 minutos ordenó la medición. La metainformación de finalidad la convirtió en evidencia.

Fuentes y límites de la evidencia

La base técnica son las fichas y textos de RFC Editor para RFC 1595 (texto), RFC 2558 (texto), RFC 3592 (texto) y RFC 2493 (texto). Los ensayos de Lu Heng aportan criterio editorial, no hechos técnicos de SONET.

La secuencia documental es explícita: RFC 1595 se publicó en marzo de 1994 como documento del Standards Track; RFC 2558 la sustituyó en marzo de 1999 y RFC 3592 sustituyó a RFC 2558 en septiembre de 2003. También cambió el tratamiento de la seguridad: RFC 1595 no la examinó, mientras que RFC 2558 advirtió que los accesos GET y SET podían revelar información sensible de configuración y control.

Las fuentes no prueban una implantación, avería, impacto al cliente, conducta de un fabricante, recepción de una alarma, comportamiento de un recolector, postura de seguridad o reparación. La escena inicial es una demostración lógica del algoritmo, no una noticia.