Resumen

  • SSP combinó rutas unicast de vector distancia con un solo árbol de broadcast y multicast, calculado desde el Virtual Source Switch de menor número alcanzable.
  • Al carecer de dirección de origen y TTL, una trama MAPOS atrapada en un bucle transitorio no podía señalar de dónde venía ni agotarse por sí sola.
  • Por eso, un next hop, una métrica menor que 16 o un bit marcado eran datos del plano de control; el reenvío seguro y la entrega necesitaban evidencia posterior.

El problema no estaba en encontrar un camino

RFC 2174 podía encontrar caminos. Cada diez segundos, por defecto, los conmutadores intercambiaban tablas completas. Sumaban el coste del enlace, comparaban métricas y guardaban el puerto por el que había llegado la mejor ruta. Si una interfaz caía o una ruta empeoraba, un triggered update podía avisar sin esperar al siguiente ciclo.

La dificultad aparecía después. El broadcast no se dirigía a un solo destino. Debía recorrer un árbol que todos los conmutadores interpretaran de forma compatible. Y la propia trama MAPOS no llevaba dos recursos habituales para contener un error: no tenía dirección de origen y tampoco TTL.

Sin origen, el receptor no podía construir un árbol distinto para cada emisor real. Sin TTL, una copia que entrara en un circuito de reenvío no llevaba una cuenta regresiva que acabara destruyéndola. La convergencia dejó de ser una optimización. Se convirtió en una condición previa para permitir la difusión.

La raíz era una ficción útil

SSP introdujo VRPB y fingió que todo broadcast o multicast nacía bajo un único conmutador: el Virtual Source Switch. El VSS era el conmutador válido con el número más pequeño de la red MAPOS.

Cada equipo buscaba ese número en su propia tabla unicast. Desde allí calculaba el camino inverso más corto. Un conmutador no raíz tenía un puerto aguas arriba y podía tener varios aguas abajo. La raíz no tenía puerto superior. Así surgía un solo árbol activo para todo el segmento.

La ficción resolvía una carencia del formato, pero no fabricaba acuerdo instantáneo. No existía una votación aparte en la que todos confirmaran la misma raíz. Cada conmutador aplicaba la misma regla a información que podía llegar en momentos distintos. Durante un cambio de topología, dos vistas podían ser internamente razonables y, sin embargo, incompatibles.

Cuando aparecía un nuevo VSS o el anterior se volvía inalcanzable, se invalidaba toda la tabla de broadcast y multicast. Cambiar solo un descendiente tenía menos alcance. Esta diferencia de impacto importa: no todos los cambios de puerto justifican el mismo reinicio ni el mismo riesgo.

El bit marcado todavía podía estar cerrado

La tabla de difusión era un mapa de bits. Cada posición representaba un puerto. Un uno indicaba que la trama debía salir hacia un nodo o hacia otro conmutador del árbol. Si no había ningún bit activo, la trama se descartaba en silencio.

Pero el bit no era un recibo. No mostraba que el canal transmitiera, que el vecino recibiera, que el árbol remoto coincidiera o que el destinatario procesara la carga. Tampoco bastaba para autorizar el envío en el momento en que nacía.

Un poisoned reverse recibido por un puerto permitía inferir que detrás había un conmutador descendiente. Entonces empezaba el FORWARD_DELAY_TIMER, treinta segundos por defecto. Hasta que expiraba, quedaba prohibido enviar broadcast o multicast por ese puerto. La relación estaba aprendida y representada, pero aún no estaba habilitada.

Otro reloj, el PORT_EXPIRATION_TIMER, vigilaba la continuidad del descendiente. Cada nuevo poisoned reverse lo reiniciaba. Si pasaban treinta segundos sin esa evidencia, el bit se borraba. Si el antiguo descendiente empezaba a enviar actualizaciones ordinarias, el borrado debía ser inmediato: había elegido otra ruta o una nueva raíz.

La misma posición del bitmap pasaba así por estados que un panel binario no puede explicar: candidato, en espera, habilitado, renovado, invalidado y retirado.

La métrica 16 no contaba toda la historia

En el lado unicast, tres intervalos sin actualización convertían una ruta en inalcanzable. También lo hacía una publicidad con métrica 16. La entrada no desaparecía enseguida: permanecía treinta segundos más para que el conmutador pudiera anunciar a sus vecinos la ruta muerta antes de recogerla como basura.

La práctica venía de la familia RIP. RFC 1058 había descrito el problema de contar hasta infinito y el uso de 16 como infinito operativo. Split horizon con poisoned reverse rompe ciertos bucles rápidamente, y las actualizaciones disparadas aceleran la mala noticia. Ninguna de esas técnicas es un commit distribuido. Una actualización puede cruzarse con otra periódica basada todavía en la ruta antigua.

Por eso los relojes expresaban afirmaciones diferentes. La expiración decía «esta creencia local envejeció». La recolección decía «la retengo para comunicar que ya no sirve». El forward delay decía «esta relación nueva aún no puede transportar difusión». La expiración del puerto decía «dejé de recibir la evidencia que mantenía a este descendiente».

Llamar a todo simplemente timeout borra el motivo de control.

El agujero negro podía escuchar

RFC 2174 añadió una advertencia de implementación que impide confundir señal de control con entrega. Un puerto tenía canal de transmisión y canal de recepción. El receptor podía seguir funcionando mientras fallaba la salida. El conmutador oía actualizaciones SSP y mantenía fresca la tabla, pero sus propias tramas caían en un agujero negro.

La realimentación de overhead SONET/SDH podía revelar el estado del canal transmitido visto desde el extremo remoto. Sin embargo, algunos servicios no conservaban esa transparencia. Una tabla renovada demostraba recepción de control en una dirección, no transporte útil en ambas.

El documento era Informational, no producto de un grupo de trabajo IETF ni Standards Track. Suponía pocos conmutadores. No midió despliegues, interoperabilidad, tormentas reales ni tiempos de convergencia observados. Tampoco discutió seguridad.

Su aporte histórico fue más preciso. RFC 2174 hizo visible un estado que los sistemas modernos suelen ocultar: la infraestructura puede saber adónde querría enviar y, aun así, decidir correctamente que todavía no debe hacerlo.

Fuentes

  1. RFC 1058 — Routing Information Protocol
  2. RFC 2171 — MAPOS Version 1
  3. RFC 2173 — Node Switch Protocol
  4. RFC 2174 — Switch-Switch Protocol
  5. RFC 2176 — IPv4 over MAPOS Version 1