Resumen

  • RFC 1315 definió objetos de gestión para Frame Relay DTE y trató Frame Relay como una interfaz física hacia una red con varias conexiones virtuales o vecinos.
  • DLCMI define intervalos de consulta, una ventana de eventos y un umbral de consultas sin respuesta antes de declarar la interfaz down; circuitos y errores tienen grupos propios.
  • El estado resultante pertenece a la interfaz administrada. No acredita que todos los VC, destinos, paquetes o aplicaciones hayan fallado.

Una superficie compartida

El modelo del RFC no ve Frame Relay como muchas conexiones físicas punto a punto. Ve un medio de acceso múltiple: una conexión física hacia la red y muchas relaciones virtuales encima. El gestor puede agrupar las conexiones virtuales por la interfaz física correspondiente y ganar un mapa más útil para diagnóstico.

Pero agrupar no equivale a fundir. La MIB separa DLCMI, circuitos y errores. Una fila de circuito describe un DLCI y un circuito determinado; un objeto de interfaz describe parámetros de gestión; un contador describe una observación. Que comparten una superficie física no permite que una fila hable por las otras.

Una fila de circuito no prueba tráfico. Una interfaz declarada down no cuenta el destino de cada VC. Un contador no identifica un usuario ni una aplicación. La MIB hace consultables esas diferencias y, por eso, también impide que se pierdan en una frase como «la red se cayó».

Un silencio contado, no una explicación total

RFC 1315 especifica el intervalo entre consultas de estado, el intervalo de consulta completa, el número máximo de consultas sin respuesta aceptado antes de marcar down y el número de intervalos en que se cuentan los errores. El agente no convierte una respuesta perdida en una historia total: observa una clase particular de ausencia dentro de una ventana y aplica una regla configurada a una interfaz.

La evidencia permite decir que el agente hizo esa declaración bajo esos parámetros. No permite afirmar por qué faltaron respuestas, que falló el proveedor, que todos los VC cambiaron de estado, que ningún paquete llegó o que un servicio de usuarios quedó indisponible. frDlcmiState registra el esquema de gestión activo e implica el DLCI usado en la interfaz; no es una identidad de toda la ruta ni una garantía para cada circuito.

RFC 1293 de esta serie se ocupa del DLCI conocido y la dirección de protocolo remota desconocida; RFC 1294, de la asignación VC-encapsulación y del rótulo de una trama. RFC 1315 se limita al modelo de observación de la interfaz compartida.

Los cambios necesitan su propio tiempo

Los circuitos virtuales pueden añadirse, eliminarse o cambiar de disponibilidad en operación normal. El RFC define además un trap de Frame Relay como complemento de Link Up y Link Down. Un trap es una notificación de un evento administrado; no es una auditoría de todas las tramas ni prueba de que una alerta llegó o de que una aplicación sufrió un efecto.

Una reconstrucción responsable conserva transición de interfaz, consultas sin respuesta, ventana y umbral, instantánea de circuitos, trap, mensajes de gestión, contadores de tráfico y sonda de servicio por separado. Cada registro tiene un alcance: decisión del agente, conteo, representación de la MIB o resultado posterior. Correlacionarlos puede explicar un incidente; sustituirlos unos por otros fabrica certeza.

Fuentes y límites de evidencia

La fuente es RFC 1315, Management Information Base for Frame Relay DTEs (abril de 1992). Sustenta el modelo una-interfaz/muchas-conexiones-virtuales, grupos DLCMI/circuitos/errores, intervalos, umbral, ventana, cambios de VC y trap. No demuestra interfaz real, operador, par remoto, caída de VC, paquetes, impacto de cliente, reparación ni restauración.