Resumen

  • Demand RIP sustituyó las emisiones periódicas sobre X.25 e ISDN por intercambios activados y confirmados. Así podía cerrar llamadas inactivas, mientras las rutas aprendidas por una respuesta activada quedaban normalmente permanentes.
  • El gestor del circuito podía informar que no había logrado abrir una conexión real; entonces las rutas pasaban por envejecimiento, retención y retirada. Un acuse probaba que llegó una actualización o un fragmento, no que el destino fuese alcanzable ni que el servicio funcionara.
  • RFC 1581 registró una sola implementación terminada, probada contra sí misma en dos tecnologías WAN. RFC 1264 separaba ese recibo de la interoperabilidad entre implementaciones independientes.

La actualización rutinaria impedía ahorrar la llamada

RFC 1582, la especificación compañera de Standards Track publicada en febrero de 1994 según su ficha oficial, partía de una economía concreta. En una red pública orientada a conexión, el router podía abrir un circuito virtual cuando había datos y soltarlo al terminar. El tráfico de usuario podía ser breve y poco frecuente.

RIP, en cambio, volvía a contar su tabla cada cierto tiempo aunque nada hubiera cambiado. En una LAN, una emisión alcanzaba el medio compartido. En una WAN sin difusión, el router debía enviar una copia a cada destino conocido. El RFC formuló la escala: N routers podían producir N × (N - 1) actualizaciones por periodo a través de N × (N - 1) / 2 conexiones. Además, una interfaz podía conocer más vecinos de los que era capaz de llamar simultáneamente; el ejemplo de ISDN básico ofrecía dos canales.

Alargar el periodo reducía gasto, pero retrasaba la reacción. Mantenerlo conservaba rapidez a costa de ocupar circuitos y colas. Demand RIP cambió la causa del mensaje: se enviaría ante una petición, una modificación de la base de rutas o una transición de circuito caído a recuperado.

El silencio dejó de borrar la última afirmación

El documento compañero, RFC 1581, figura como análisis Informational en el registro de RFC Editor. Resumía la apuesta: en los circuitos WAN bajo demanda habría actualizaciones activadas, retransmitidas hasta ser acusadas; la información recibida no caducaría en el funcionamiento normal. En las LAN y en los enlaces punto a punto fijos seguía operando RIP ordinario con su actualización periódica.

RFC 1582 distinguió dos clases de entrada. Una ruta aprendida mediante respuestas periódicas en la LAN era temporal y expiraba sin refresco. Una ruta recibida mediante una respuesta activada en la WAN era normalmente permanente.

Permanente no quería decir verdadera para siempre. Quería decir que el sistema seguía usando el último estado aceptado hasta que apareciera una refutación reconocida: una ruta marcada como inalcanzable, su ausencia en una respuesta completa, la caída de la interfaz, demasiados intercambios sin acuse o un intento real de llamada que el gestor del circuito no pudiera establecer.

Por eso “no llegó ninguna actualización” y “intenté abrir el circuito y falló” eran pruebas distintas. La primera era el silencio que el diseño buscaba. La segunda podía iniciar la retirada. La ausencia de mensajes dejó de ser un reloj y pasó a ser una condición normal.

El gestor del circuito entró en la máquina de estados de ruta

RFC 1582 situaba un gestor debajo de IP, IPX y sus tareas de encaminamiento. Traducía la dirección lógica del siguiente salto a la dirección física necesaria para X.25 o ISDN. Si llegaba un datagrama sin circuito disponible, trataba de abrir uno; tras un tiempo inactivo podía cerrarlo.

Cuando fallaba un intento durante el tráfico normal, el gestor emitía circuit down. Las rutas por ese siguiente salto dejaban su condición permanente, empezaban a envejecer, se anunciaban como inalcanzables durante hold-down y finalmente podían eliminarse. Si el gestor restablecía contacto antes, podían volver a estado permanente. Si ya habían expirado, las aplicaciones intercambiaban la base completa para reconstruirla.

La señal circuit up tampoco certificaba la tabla vieja. Solo afirmaba que el gestor había recuperado la conexión según su procedimiento. De ahí la necesidad de reponer información completa. Una llamada abierta, una ruta aprendida, una entrada elegida para reenvío, un paquete entregado y una aplicación útil son comprobaciones diferentes.

El proceso interno de recuperación quedó fuera del alcance de la especificación. Agotamiento de canales, mapa físico erróneo, rechazo remoto y fallo del medio podían terminar en la misma señal. Era una entrada válida para una decisión prudente, no un diagnóstico universal.

El acuse probaba entrega, no verdad

Eliminar el ciclo periódico hacía peligrosa la pérdida de un único cambio. Una actualización podía desaparecer por falta de circuito virtual, una cola llena, la reasignación de un canal o un error de trama. RFC 1582 añadió petición, respuesta, confirmación y retransmisión.

Las respuestas grandes se fragmentaban. Cada fragmento tenía acuse propio y el receptor no modificaba su base hasta reunirlos todos. Si vencía el intervalo de reensamblado, descartaba el conjunto incompleto y solicitaba otra actualización total. La llegada de una secuencia nueva desplazaba los fragmentos incompletos de la anterior.

Así se obtenían recibos precisos. El ACK demostraba la recepción de una respuesta concreta. El conjunto completo permitía aplicar una versión de la base. El número de secuencia separaba generaciones. Ninguno demostraba que la ruta anunciada correspondiera al mundo, que el FIB la eligiera, que un paquete de usuario cruzara la WAN o que la aplicación obtuviera el resultado esperado.

La lista de pares también tenía un alcance definido: servía como lista de envío y de aceptación, y una actualización procedente de fuera debía descartarse. RIP-2 podía añadir autenticación. Pero identificar al emisor autorizado no convertía sus métricas en una observación del servicio.

Menos coste de línea, más deuda de estado

Las rutas permanentes no podían confiar en el olvido. RFC 1582 exigía conservar todas las alternativas o guardar un subconjunto y recordar que se habían desechado otras, para pedirlas antes de quedarse sin opciones. Lo que el refresco reconstruía de forma repetida ahora debía permanecer en memoria o recuperarse de manera deliberada.

La reducción de llamadas compró una obligación mayor. Hacían falta retirada exacta, retransmisión, reensamblado completo, coordinación entre capas y reglas de reinicio. La factura de telecomunicaciones bajaba; la responsabilidad sobre estado duradero subía.

El RFC hizo visible una dependencia de implementación. En el producto descrito, gestor y aplicación estaban estrechamente unidos. En un sistema Unix, uno podía vivir en el núcleo y la otra como proceso; otro router podía alojar el gestor en una tarjeta separada. Si sus vidas eran independientes, debían mantener keepalive y resincronizar tablas tras una caída. Que un componente siguiera funcionando no probaba que el otro compartiera la misma época de estado.

La prueba contra uno mismo no era una prueba entre dos autores

RFC 1581 dijo que se creía terminada una sola implementación. La de Spider Systems soportaba IP RIP-1, IPX RIP e IPX SAP, pero aún no RIP-2. La función nueva se probó contra sí misma sobre X.25 e ISDN; en Ethernet convivió con implementaciones ordinarias. Otros dos desarrollos solo para Novell seguían en curso.

Ese registro demostraba código y dos entornos WAN. No demostraba que una implementación independiente interpretara igual los fragmentos, los temporizadores, el reinicio o las señales de circuito.

RFC 1264 y su ficha explicaban por qué. Los protocolos de ruta son algoritmos distribuidos en tiempo real. Que uno funcione en un entorno no garantiza otro entorno con varios fabricantes. Implementaciones independientes, prueba de todas las funciones y demostración de los mecanismos de seguridad eran pruebas distintas.

La historia se deforma si “implementado” se vuelve “interoperable”, pero también si una prueba propia se trata como nada. El recibo es útil precisamente porque RFC 1581 declaró su límite.

El sucesor cambió el transporte del cambio, no la frontera

En enero de 1997 apareció RFC 2091, con su registro oficial. Describía ventajas de eficiencia frente a RFC 1582: después de un intercambio total enviaba solo cambios, reducía memoria y tráfico y eliminaba el tope de 255 fragmentos al no usar aquella fragmentación.

Sin embargo, mantuvo la presunción esencial. Las rutas de respuestas activadas seguían siendo normalmente permanentes. El gestor seguía emitiendo down y up. Peticiones y respuestas seguían llevando acuse y retransmisión. Un periodo excesivo sin ACK podía convertir la presunción en inalcanzable. Recuperar o reiniciar seguía exigiendo flush e intercambio completo.

La publicación de un diseño posterior no demuestra su adopción ni borra el anterior. El cambio muestra otra forma de implementar la misma responsabilidad. Si el silencio se vuelve normal, hay que separar estado retenido, evidencia que lo invalida, entrega del mensaje, reenvío y resultado del servicio.

Fuentes