Resumen

  • Los HELLO de RFC 891 producían una demora de ida y vuelta para escoger rutas y propagaban el desfase asociado, aunque cada uso tenía condiciones de aceptación propias.
  • El camino de menor demora transportaba el dato horario; no nombraba al reloj maestro, cuya identidad procedía del parámetro configurado CLOCK-HID.
  • Una corrección grande podía invalidar temporalmente las marcas de tiempo, y longitudes de paquete distintas podían permitir una ruta nueva sin aceptar un desfase nuevo.

Supongamos que llega un HELLO correcto y mejora la ruta hacia un host. ¿Debe cambiar también el reloj? En la RFC 891, la respuesta podía ser no. Si las longitudes del último HELLO enviado y recibido no coincidían, la información servía para actualizar el camino, pero no para reemplazar el desfase horario.

Esa asimetría resume el diseño mejor que la frase “ruteo y tiempo iban juntos”. Viajaban juntos, pero no adquirían autoridad juntos.

La red DCN para la que fue escrito el documento era local y pequeña: hasta 256 hosts y gateways, con Fuzzballs PDP-11 o LSI-11 enlazados por medios punto a punto y multipunto. Cada equipo podía conmutar paquetes, ser gateway y prestar servicios. No existía un líder de ruteo local separado.

Una tabla local reunía dos memorias

La Host Table guardaba, para cada host, el proceso de salida, la demora medida, el desfase del reloj, la hora de actualización y un contador de vida. Una máquina física podía contener varios hosts virtuales. Para redes externas existía otra Net Table, normalmente configurada y solo modificada dinámicamente por procesos como GGP o EGP.

Los HELLO entre miembros de la misma red usaban el protocolo IP 63 y llevaban entradas de demora y desfase. El registro de números de protocolo de IANA conserva hoy el 63 con la descripción “any local network”. Es continuidad administrativa, no una medición de uso contemporáneo.

El cálculo combinaba el estado de un HELLO recibido con el siguiente enviado. La RFC destacaba que no dependía de relojes ya sincronizados ni de intervalos constantes de emisión, y que toleraba pérdidas y mensajes reflejados. Por eso podía arrancar antes de que el sistema tuviera una hora común.

Formato y checksum descartaban mensajes defectuosos. Después venían pruebas más específicas. La coincidencia de longitudes protegía la estimación precisa del desfase; la decisión de ruta podía avanzar sin ella. Recibir, medir, enrutar y corregir eran cuatro verbos.

La métrica seleccionaba un conducto

Para valorar una ruta, el receptor sumaba la demora de ida y vuelta hacia el vecino y la demora que este anunciaba para el destino. Un nuevo camino tenía que superar al actual por un margen configurado. En la implementación descrita aparecen unos 100 milisegundos de umbral, 120 segundos de retención y 30 segundos como demora máxima de camino. No deben proyectarse como constantes universales.

Al aceptar el camino, el receptor almacenaba también el desfase que venía con él. Esto hacía que la mejor ruta fuese el conducto natural para la observación temporal. Pero la identidad del maestro no surgía de la competencia entre métricas: estaba fijada en CLOCK-HID.

Un vecino rápido no podía coronarse reloj. Incluso un desfase procedente del host configurado debía acompañarse de fecha válida y pasar por la lógica del reloj local. La arquitectura separaba alcance, identidad y efecto.

Devolver una ruta a su origen exigía envenenarla

Si un host anunciaba por el mismo enlace una ruta que había aprendido allí, podía ayudar a formar un bucle. RFC 891 sustituía esa demora por MAXDELAY. Mucho después, RFC 2453 describió con vocabulario familiar split horizon, poisoned reverse, actualizaciones disparadas y conteo al infinito.

La comparación ilumina un problema común, pero no demuestra descendencia directa entre Hellospeak y RIP. La observación segura es que una métrica pierde significado cuando se borra el enlace del que fue aprendida.

El contador de vida y el intervalo de retención también impedían tratar una desaparición como una hoja en blanco instantánea. La ruta podía caducar, reaparecer o mantenerse mientras la información horaria seguía otra validez.

A veces corregir obligaba a dejar de medir

La RFC separaba reloj físico, aparente y efectivo. Las diferencias pequeñas se absorbían de forma gradual, transfiriendo una fracción de la corrección acumulada. Los parámetros sugeridos limitaban el ajuste a menos de unos dos milisegundos por segundo.

Una diferencia grande podía producir un salto. Entonces comenzaba un intervalo de espera en el que las marcas temporales no eran válidas. El sistema reconocía que una discontinuidad local podía falsificar la siguiente medición aunque los paquetes siguieran llegando.

Además, la representación del reloj aparente volvía a cero a medianoche UT. Por ello era necesaria al menos una actualización diaria válida de fecha y hora desde el maestro. Tener ruta hacia CLOCK-HID no equivalía a poseer fecha vigente.

La RFC 778 ya había usado tres marcas temporales en ICMP y GGP para un servicio de reloj DCNET. RFC 891 convirtió esa clase de observación en estado continuo compartido con el ruteo.

NTP heredó una idea, no el mismo protocolo

La RFC 1059 llamó “Hellospeak” al protocolo Fuzzball, afirmó que incorporar tiempo al ruteo influyó fuertemente en NTP y aclaró que el diseño no era apropiado fuera de su ambiente local.

RFC 958 propuso NTP sobre UDP con jerarquía y formato de mensajes, pero dejó fuera algoritmos de sincronización y filtrado, descubrimiento de pares y autenticación. RFC 1305 desarrolló después selección y filtrado entre varios servidores, cotas de error y un reloj lógico derivado del trabajo Fuzzball.

La influencia está documentada; la identidad no. Hellospeak resolvía conjuntamente dos necesidades de una red local. NTP convirtió la evaluación del tiempo en una superficie propia y más amplia.

Fuentes y límites

Este análisis usa RFC 778, RFC 891, RFC 958, RFC 1059, RFC 1305, RFC 2453 y el registro IANA. No demuestra despliegue actual de DCN, autenticación del maestro, simetría de la demora, uniformidad de parámetros, linaje directo hacia RIP ni que la menor demora de ida y vuelta produzca siempre el menor error horario.