Resumen

  • RFC 2333 dejó claro que NHRP usaba una selección previa del enrutamiento; no sustituía al protocolo de rutas ni comprobaba alcance extremo a extremo.
  • La decisión de crear un atajo dependía de la topología, el coste, la necesidad de la aplicación, la participación NHRP y la seguridad frente a bucles.
  • Un ACK de registro, una respuesta autoritativa y una entrada de caché eran evidencias de control distintas, con origen, política y caducidad propios.
  • En ATM, resolver una dirección seguía siendo anterior a señalizar un circuito virtual; después aún quedaban el plano de datos, el retorno, el servicio y la aplicación.
  • Un sistema fiable debía comprobar cada transición y conservar el camino enrutado como alternativa, sin convertir una optimización en una afirmación de éxito.

La pantalla verde ocultaba demasiadas etapas

Una fila de caché parece concreta.

Muestra una dirección IP, una dirección NBMA, quizá una marca de autoridad y un tiempo restante. La precisión visual invita a resumirla como “siguiente salto disponible”. Sin embargo, RFC 2333 no describía NHRP como un sensor de disponibilidad.

Era una declaración de aplicabilidad. Preguntaba en qué entorno tenía sentido resolver un atajo sobre una red de acceso múltiple sin difusión, y bajo qué límites podía hacerse sin confundir funciones.

Que NHRP fuese apropiado no implicaba que el cliente hubiese enviado una solicitud. Una respuesta válida no implicaba que el medio orientado a conexión hubiese aceptado un circuito. Un circuito no implicaba reenvío IP correcto. Y ni siquiera un intercambio de paquetes demostraba que el servicio final cumpliera el objetivo de la aplicación.

La caché describía una pieza del mapa. El resto del viaje exigía otras pruebas.

NHRP heredaba una decisión de ruta

El orden empezaba con el enrutamiento de capa de red.

La estación origen elegía el próximo salto hacia el destino con su proceso normal. Si ese salto era accesible por una interfaz NBMA y faltaba la correspondencia necesaria, podía emitir una solicitud NHRP. Para un destino dentro de la red NBMA lógica, la respuesta podía señalar a la propia estación. Para uno exterior, podía señalar al router de salida actual.

NHRP no calculaba por sí mismo qué salida era la correcta. Cuando se apoyaba en rutas dinámicas, reflejaba la selección del sistema de enrutamiento. Ese sistema podía reducir los saltos del camino original, pero no certificaba necesariamente latencia, congestión, precio, diversidad o continuidad.

Una entrada aprendida tampoco congelaba la época que la produjo. Si cambiaban las métricas o la topología, el atajo podía quedar desalineado. RFC 2333 advirtió que las rutas inestables podían crear atajos efímeros y, en ciertos casos entre routers, bucles persistentes.

La dirección resolvía dónde intentar; no renovaba la autoridad de la ruta indefinidamente.

El modelo clásico hacía visible el beneficio

En IP clásico sobre ATM, una LIS delimitaba quién podía comunicarse directamente mediante ATMARP. Dos estaciones de LIS diferentes utilizaban un router IP aunque el mismo tejido ATM permitiera, físicamente, abrir un circuito directo.

NHRP amplió ese modelo. Podía resolver una dirección más allá del límite de una LIS y permitir un camino directo dentro de la red NBMA lógica. La reducción de saltos era real y podía aprovechar características del medio, incluso opciones de calidad de servicio.

Pero el beneficio no anulaba el coste.

Crear y conservar circuitos consumía señalización, memoria y capacidad de interfaz. Para una transferencia breve sin requisitos especiales, el camino enrutado podía terminar antes de que el atajo justificara su estado. RFC 2333 situó esa elección cerca de la aplicación y la política operativa.

Por eso, “se puede usar NHRP” y “conviene crear este atajo ahora” eran proposiciones diferentes.

Controlar quién pedía el atajo evitaba duplicarlo

Un paquete podía recorrer varios routers antes de que existiera un camino directo. Si todos los nodos capaces reaccionaban al mismo flujo, podrían aparecer varios atajos superpuestos.

La declaración de aplicabilidad proponía una regla: autorizar al host origen, al primer router cuyo próximo salto fuese alcanzable por la interfaz NBMA o a un router de política que el tráfico tuviera que atravesar.

Esa lista no era una prueba de éxito. Era una asignación de autoridad para crear estado.

El diseño reconocía que un atajo no era gratuito ni neutral. Elegir el iniciador afectaba cuántos circuitos existían, qué equipo soportaba la carga y qué política seguía siendo visible en el camino.

Una implementación que reaccionara a cada indicio de tráfico podía convertir una optimización en multiplicación de estado.

Entre routers, la topología debía hablar más fuerte

El uso entre routers mostraba el límite más delicado.

NHRP básico no conservaba necesariamente toda la información que el enrutamiento necesitaba para suprimir bucles. Un cambio de métricas entre sistemas autónomos podía dejar al atajo con una visión insuficiente.

RFC 2333 identificó un caso estable: el destino estaba directamente adyacente a la interfaz no NBMA del router de salida. Si una solicitud con bit Q procedía de un router y esa adyacencia era estable, la salida podía responder.

En ausencia de esa condición, un NAK era una respuesta segura. Obligaba al tráfico a seguir la ruta ordinaria.

La negativa no destruía conectividad; protegía al plano de datos de una afirmación que NHRP no podía sostener. Era mejor conservar un camino con autoridad clara que instalar uno más corto con semántica de bucle incierta.

El registro no era una sonda

RFC 2332 permitía que un cliente registrara su correspondencia con uno o varios NHS.

El servidor examinaba la solicitud, realizaba comprobaciones y aplicaba política. Podía no servir esa dirección, carecer de recursos, prohibirla administrativamente o detectar un conflicto de unicidad. Una respuesta positiva significaba que el servidor había aceptado la información.

Nada en ese acto obligaba al servidor a verificar una aplicación remota.

El ACK tampoco establecía automáticamente un SVC ATM. No demostraba que el cliente conservara el mismo estado físico al minuto siguiente. No decía que todos los servidores vecinos hubiesen recibido la actualización.

El registro tenía un Holding Time. Para que la entrada no desapareciera, el cliente debía renovarla con suficiente frecuencia incluso frente a pérdidas. Esa necesidad de refresco convertía el tiempo en parte del significado.

Un registro sin su edad y su historial de renovación estaba incompleto como evidencia operativa.

Autoritativo significaba responsable de la correspondencia

Un cliente podía preferir una respuesta del NHS que sirviera al destino. También podía recibir, cuando se permitía, una respuesta no autoritativa desde la caché de un servidor de tránsito.

La distinción importaba porque revelaba quién respondía y con qué relación con el destino.

No extendía el ámbito de la respuesta.

Incluso una respuesta autoritativa era autoridad sobre una correspondencia de direcciones. No podía prometer que la señalización ATM tuviera recursos, que un grupo cerrado permitiera el circuito, que el MTU coincidiera, que el retorno funcionara o que el servicio remoto escuchara.

Llamar “autoritativa” a la respuesta sin nombrar su objeto fomentaba una lectura excesiva. La pregunta seguía siendo dónde estaba el siguiente salto NBMA, no qué resultado tendría la sesión.

La caché conservaba procedencias distintas

Un NHS podía obtener entradas de registros, intercambios de resolución, tablas configuradas, ARP o fuentes fuera del documento. Un NHC también podía usar una respuesta, una configuración manual u otro mecanismo.

Una vista unificada podía ocultar estas diferencias.

RFC 2677 definió objetos para observar tipo, origen, uso, MTU y tiempo de conservación. Una entrada aprendida con Holding Time válido debía eliminarse al llegar a cero. Una fila administrativa podía tener una duración indefinida porque su respaldo era configuración no volátil.

La misma pareja de direcciones podía aparecer por caminos con grados de confianza distintos. Un dato manual podía sobrevivir a una mudanza. Una respuesta negativa en caché podía reducir solicitudes repetidas sin convertir la ausencia temporal en imposibilidad perpetua. Una copia sincronizada podía ser coherente y antigua a la vez.

La presencia era solo el primer campo del diagnóstico.

La sincronización resolvía coherencia interna

SCSP permitía que varios servidores reconciliaran y difundieran sus bases. RFC 2335 detalló su aplicación distribuida a NHRP.

Este mecanismo mejoraba la consistencia del servicio. Si una solicitud llegaba a un NHS distinto, la respuesta podía basarse en información común del grupo.

Pero sincronizar no era sondear.

Los servidores podían coincidir exactamente en una correspondencia que ya no describía el endpoint actual. Su acuerdo demostraba que el protocolo de replicación había realizado su trabajo, no que el plano de datos hubiese sido observado.

RFC 2332 conservó mensajes Purge y códigos de error precisamente porque las entradas debían ser revisables. Bucles, direcciones inalcanzables, respuestas inválidas, fallos de autenticación y límite de saltos podían interrumpir la cadena de control.

Resolver no abría el circuito

La distinción era explícita en medios orientados a conexión.

Después de recibir la dirección NBMA, una estación ATM podía tener que establecer una conexión con el ancho de banda requerido. Solo entonces llegaba la prueba del reenvío. Un medio sin conexión permitía una secuencia distinta, pero tampoco convertía la resolución en entrega.

El circuito podía fallar por recursos o política. Podía establecerse con parámetros insuficientes. Podía transportar tráfico en un sentido y fallar en el retorno. El host podía contestar a IP mientras el proceso de aplicación estaba detenido.

Cada uno era un evento posterior con un observador diferente.

El camino enrutado preservaba el servicio

Mientras esperaba una resolución, el origen podía descartar, conservar o reenviar el paquete por la ruta normal. RFC 2332 recomendó este último comportamiento por defecto.

Además, un router no compatible con NHRP podía descartar silenciosamente la solicitud. El atajo no se formaba, pero la conectividad salto a salto podía continuar.

Ese diseño evitaba que una optimización se convirtiera en requisito oculto del servicio.

Un fallo de NHRP podía coexistir con tráfico sano. Y un estado NHRP sano podía coexistir con una aplicación rota. El tablero debía ser capaz de representar ambas combinaciones.