Resumen

  • RFC 3020 ofrecía cuatro reglas para declarar activo un haz Multilink Frame Relay: al menos un enlace, todos los enlaces, un umbral numérico o una condición específica de la implementación.
  • Por eso, ifOperStatus=up demostraba que se había satisfecho aquella regla; no demostraba capacidad completa, ausencia de pérdidas y desorden, ni recepción útil en el extremo remoto.

El panel mostró una recuperación. La planta física no había cambiado.

Había cuatro enlaces configurados y solo dos activos. El operador bajó el umbral de tres a dos. El haz lógico pasó de down a up y emitió la notificación correspondiente. No era un falso positivo: la nueva política se había cumplido exactamente. Pero describirlo como la reparación de un circuito habría confundido dos hechos diferentes.

RFC 3020, publicado en diciembre de 2000, definió la MIB para controlar y observar la función Multilink Frame Relay en interfaces UNI y NNI. El mecanismo reunía varios enlaces físicos en un único haz lógico, ofrecía una interfaz a la capa Q.922 y conservaba el orden de las tramas después de repartirlas entre caminos distintos.

Su interés histórico está en una decisión aparentemente pequeña: el estándar hizo visible que el estado del agregado dependía de una regla de activación. El color verde no llegaba directamente de la fibra o del cobre. Era el resultado de evaluar una población de componentes con un predicado configurado.

El haz no heredaba sin más la identidad de un enlace

Cada enlace físico aparecía en la Interface MIB con un ifIndex. El haz también aparecía como interfaz, porque para las capas superiores funcionaba como una unidad lógica. Sin embargo, la tabla específica de MFR utilizaba mfrBundleIndex.

La diferencia repartía autoridad. Al crear una fila, el gestor elegía el índice MFR; el agente seleccionaba el ifIndex genérico. RFC 3020 incluyó tablas de traducción en ambos sentidos. Un inventario que guardara solo uno de los dos identificadores podía perder la continuidad entre configuración especializada, alarmas genéricas y contadores del interfaz.

La creación también tenía etapas. Un SET de createAndGo sobre mfrBundleRowStatus creaba el haz y obligaba al agente a crear su interfaz. Una implementación podía admitir createAndWait. Para añadir un miembro, la fila de enlace usaba el ifIndex de la interfaz física y mfrBundleLinkConfigBundleIndex señalaba el haz ya existente. Sin una asociación válida, la fila quedaba notReady.

La existencia de la fila probaba que el objeto de configuración había sido aceptado. Aún faltaban el estado del protocolo del miembro, la evaluación del agregado, la integridad de las tramas y el resultado en el receptor.

La palabra “activo” tenía cuatro gramáticas

mfrBundleActivationClass elegía la condición.

En clase A, bastaba con que un enlace estuviera operacionalmente up. En clase B, todos tenían que estarlo. En clase C, el número mínimo se tomaba de mfrBundleThreshold. La clase D era personalizada y dependía de la implementación. El valor predeterminado era la clase A.

Cuando se usaba la clase C, llegar al umbral hacía que el haz pasara a up/active; caer por debajo lo devolvía a inactivo. En clases donde el umbral no se aplicaba, el objeto debía devolver -1. En clase D, el uso del campo dependía del producto.

Las notificaciones de subida y bajada del haz seguían la misma lógica. El trap linkUp se enviaba cuando ifOperStatus cambiaba a up porque había un número suficiente de miembros activos según clase y umbral. LinkDown se enviaba cuando ese número dejaba de ser suficiente.

Guardar la notificación sin guardar su regla eliminaba la explicación. Con cuatro miembros, una sola línea podía bastar en clase A. Tres podían ser insuficientes en clase B. En clase C con umbral dos, el segundo miembro cambiaba el estado binario y los siguientes solo cambiaban capacidad. En clase D, la reconstrucción exigía conocer la versión y la conducta del código.

Así, dos paneles que mostraban up podían representar reservas de capacidad radicalmente distintas. La etiqueta no era comparable sin su denominador.

Contar miembros no medía el servicio recibido

La MIB separaba mfrBundleLinksConfigured de mfrBundleLinksActive. También exponía el ancho de banda disponible del haz. Esta división impedía, al menos en el modelo, convertir un estado binario en una declaración de capacidad nominal.

Un haz de cuatro líneas podía estar activo con una. El ancho de banda reportado podía mostrar la reducción, pero seguía siendo un valor del agente, no una medición de rendimiento de una aplicación. No contenía carga ofrecida, intervalo de la prueba, congestión, retransmisiones, recepción remota ni finalización de una transacción.

La agregación añadía otro problema: los miembros podían tener retardos distintos. RFC 3020 incluía el máximo diferencial de retardo, la longitud de los números de secuencia, la fragmentación y el tamaño de fragmento. Cada miembro podía exponer su retardo de ida y vuelta.

La condición para mantener conectividad mínima y la condición para cumplir una promesa de capacidad eran contratos distintos. Si compartían una sola alarma, el sistema podía estar técnicamente disponible y comercialmente incumplido.

Un evento de reordenamiento podía ocultar varias pérdidas

mfrBundleResequencingErrors no contaba tramas perdidas. Contaba eventos de error de reordenamiento. El propio RFC puso el ejemplo: si se reciben 56, 59 y 60 y se decide que 57 y 58 se perdieron, el contador aumenta en uno.

Por tanto, un incremento demostraba que el agente registró un episodio, no cuántas tramas faltaron. Tampoco un contador quieto demostraba entrega perfecta. Había que conocer reinicios, discontinuidades, wrap, frecuencia de lectura y qué fallos quedaban fuera del contador.

Las filas de enlace añadían contadores de tramas de control inválidas, expiraciones de temporizador, loopback sospechado, secuencias inesperadas y discrepancias de nombre de haz. El estado del miembro procedía de la máquina de estados FRF.16, no de una lectura eléctrica aislada.

El trap de mismatch mostraba nombres locales configurados, nombres remotos vistos antes y nombres remotos informados en ese momento. RFC 3020 advertía que incluso los elementos “configurados” podían haberse configurado automáticamente. La alarma demostraba una divergencia entre vistas; no identificaba por sí sola si el origen era el gestor local, el extremo remoto, una automatización o un dato antiguo.

Estos indicios podían explicar una degradación dentro de un haz aún activo. Ninguno sustituía una observación en el destinatario.

Cambiar quién cuenta como suficiente también era una operación de red

La clase, el umbral, los temporizadores, la fragmentación y la longitud de secuencia tenían acceso máximo read-create. El gestor también podía crear, modificar o eliminar filas y decidir a qué haz pertenecía cada enlace.

El máximo de la definición no obligaba a todo agente a permitir escritura. Las declaraciones de conformidad reducían a solo lectura el acceso mínimo de varios objetos, aunque exigían informar el valor utilizado. El esquema, la capacidad implementada y el permiso concedido al principal eran pruebas distintas.

Cuando la escritura estaba disponible, una modificación de política podía producir el siguiente linkUp. La infraestructura seguía degradada, pero el nuevo mínimo se había alcanzado. Por eso la cronología de disponibilidad debía contener también la cronología de configuración.

La sección de seguridad advertía que los SET sin protección podían perjudicar las operaciones. SNMPv1 no resolvía qué persona o proceso podía leer, cambiar, crear o borrar objetos, incluso si la red se protegía con IPsec. RFC 3020 recomendaba USM y VACM de SNMPv3 y dejaba al operador la correcta asignación de derechos.

Autenticar una orden contestaba quién la envió. Autorizarla contestaba si podía modificar ese objeto. Ninguna respuesta establecía que el nuevo umbral fuera compatible con el objetivo del servicio.

El RFC documentó una semántica, no una implantación

RFC 3020 fue publicado como Proposed Standard. RFC 9141 lo actualizó años después para retirar referencias al antiguo servicio FTP del IETF. Esa actualización no cambió las clases de activación ni la relación entre miembros y haz.

Las fuentes prueban el diseño documental. No prueban que un fabricante aplicara todos los objetos, que un operador desplegara MFR, que una red alcanzara una disponibilidad concreta o que existiera una avería real. El artículo conserva esa incertidumbre.

Reality Layers, de Lu Heng, ayuda a separar la fila, la política, el estado del miembro, la interfaz agregada, los contadores de integridad y el resultado recibido. Running-Code Primacy es especialmente importante para la clase D, definida deliberadamente por la implementación. Minimum Initial Specification explica por qué un contrato de gestión limitado podía coordinar operaciones sin pretender ser una prueba de extremo a extremo.

Son lentes analíticas declaradas. Lu Heng no escribió ni respaldó RFC 3020.

La frase completa era más larga que el indicador: “el haz está activo según esta regla, sobre este conjunto de miembros y en esta época de configuración”. Solo después podía empezar la pregunta por la capacidad y la entrega.

Fuentes