Resumen

  • RFC 2370 transportó datos específicos de aplicaciones en LSA opacas de tipos 9, 10 y 11, con alcances de enlace, área y sistema autónomo.
  • El bit O, la confirmación y la fila de la LSDB acreditaban capacidad y transporte del protocolo, no comprensión, vigencia, cálculo de camino, instalación ni entrega real.

La innovación no fue enseñar a OSPF una nueva clase de ruta. Fue enseñarle a llevar una carta sin apropiarse de su idioma. Detrás de un encabezado LSA normal —edad, opciones, tipo, identificador, router anunciante, secuencia, checksum y longitud— RFC 2370 dejó un cuerpo alineado a 32 bits para otra aplicación.

“Opaco” no significaba cifrado. Significaba que el mecanismo común conocía la envoltura y su ciclo de vida, mientras el consumidor conocía el contenido. Esa modestia permitía reutilizar una red de distribución madura sin convertir la especificación de 1998 en autoridad sobre todos los usos futuros.

Tres alcances, tres obligaciones

El tipo 9 quedaba en el enlace local; la implementación tenía que recordar la interfaz asociada. El tipo 10 se detenía en la frontera del área. El tipo 11 recorría el AS con restricciones parecidas a las LSA externas y no entraba en áreas stub.

La elección era operativa. Un objeto íntegro seguía siendo inválido para una interfaz situada fuera de su alcance. Un tipo 11 recibido dentro de un área stub debía rechazarse. Emisor y receptor compartían la obligación de no convertir una declaración local en una declaración global.

Los ocho bits superiores del Link State ID formaban el Opaque Type y los otros 24 identificaban la instancia dentro de esa familia. El nombre ayudaba a despachar el objeto. No probaba que el cuerpo fuera verdadero, que el anunciante tuviera autoridad material o que el receptor debiera actuar.

La capacidad del vecino no era la capacidad de todas sus aplicaciones

Durante el intercambio de Database Description, el bit O indicaba disposición para recibir y reenviar LSA opacas. Solo los vecinos capaces las incorporaban a sus listas de resumen y retransmisión. Un vecino no capaz podía oír un multicast y descartar el tipo desconocido.

El bit describía el transportador. No enumeraba consumidores locales. Un router podía propagar correctamente un Opaque Type que no interpretaba; una aplicación podía estar instalada y, sin embargo, recibir una topología incompleta por una discontinuidad de capacidad.

Por eso sincronizar la LSDB y hacer converger la aplicación son trabajos distintos. OSPF almacena un objeto válido dentro del alcance. Después, el consumidor escoge el tipo, analiza el cuerpo, evalúa origen y frescura, compara otros estados y aplica política. La fila de la LSDB es un recibo del portador, no del destinatario semántico.

Una instancia más nueva podía contener un hecho viejo

Las LSA opacas heredaron secuencia, checksum, LS age, MaxAge, límites de frecuencia, retransmisión y acuse. Cada elemento respondía una pregunta concreta. El checksum validaba bytes, no sentido. La secuencia ordenaba instancias, no fechaba la medición que originó el cuerpo. El acuse probaba recepción del vecino, no uso.

RFC 5250 sustituyó a RFC 2370 y expuso el problema más claro. Para un tipo 11, routers situados fuera del área de origen podían seguir usando durante cerca de una hora información de un anunciante ya caído. La revisión hizo visible al originador como ASBR y exigió dejar de usar sus LSA opacas cuando perdiera alcanzabilidad.

La corrección importa porque no reparó la inundación de paquetes: añadió una condición de validez que el sobre no podía expresar por sí solo. El estado del originador pasó a formar parte de la decisión del consumidor. Así, una base sincronizada podía seguir siendo insuficiente para actuar con seguridad.

El portador original podía cumplir sus reglas y aun así dejar un dato obsoleto en manos de la aplicación. Más alcance no producía más verdad; había que observar también al autor de la declaración.

La ingeniería de tráfico no confundió base recibida con camino instalado

RFC 3630 usó LSA opacas de tipo 10 para atributos de ingeniería de tráfico. Nodos sin lógica TE podían inundarlas como objetos opacos, mientras otros construían una base TE. Esa fue la ventaja del canal general: la aplicación no necesitaba inventar otro protocolo de distribución.

La norma también dijo que una LSA TE modificada actualizaba la base TE sin requerir un SPF normal. La forma de instanciar caminos quedaba separada, y una participación incompleta podía dejar huecos en la topología extendida. Recibir la LSA, comprenderla, calcular, instalar y observar tráfico seguían siendo hechos independientes.

RFC 7684 reutilizó después el canal para atributos extendidos de prefijo y enlace. El registro IANA conserva los tipos 9, 10 y 11 y sus espacios derivados. Registra identidad; no certifica despliegue.

La autenticación de OSPF tampoco certificaba el contenido de la aplicación. RFC 5709 reforzó el intercambio con HMAC-SHA, pero una clave identifica una relación protocolaria. El consumidor aún decide si el anunciante puede hacer esa afirmación, si concuerda con otras pruebas y si debe producir una acción. Muchas LSA distintas también pueden agotar memoria y proceso aunque lleguen por un intercambio autenticado.

El diseño encaja con la primacía del código operativo y la especificación inicial mínima de Heng Lu: el nivel común define solo lo necesario para interoperar; los usos posteriores adquieren realidad cuando se implementan y adoptan. Publicar una extensión abre una posibilidad. No crea por sí solo una ruta ni un resultado.

Fuentes