Resumen

  • RFC 3037 recomendó LDP a los dispositivos que realizaban reenvío MPLS por caminos normalmente calculados por el enrutamiento de destino; no impuso LDP a todo equipo MPLS ni documentó una instalación.
  • La declaración distinguió la distribución básica salto a salto de la ingeniería de tráfico explícita y dejó una secuencia comprobable desde el descubrimiento hasta el paquete observado.

Una recomendación puede parecer un hecho cuando se lee muchos años después. El estándar dice qué conviene implementar; una ficha de producto dice qué código existe; la configuración dice qué está encendido; el protocolo dice qué estado coordinaron dos nodos; un contador o una captura dice qué ocurrió. RFC 3037 ocupaba deliberadamente el primero de esos lugares.

Publicado en enero de 2001 como RFC Informational, delimitó la aplicabilidad de LDP entre varias formas posibles de distribuir etiquetas MPLS. Recomendó implementarlo para una función concreta: reenvío sobre rutas normales elegidas por protocolos basados en destino. No informó de ningún despliegue.

El LDP básico seguía al enrutamiento, no lo sustituía

Dos Label Switching Routers necesitaban entender del mismo modo las etiquetas que usaban entre ellos. LDP permitía que uno anunciara al otro una asociación entre FEC y etiqueta. La ruta subyacente, en el caso central del documento, provenía del cálculo ordinario de siguiente salto.

La independencia de un protocolo autónomo tenía ventajas. Junto con un plano IP y software capaz de programar tablas cross-connect, podía llevar IP por conmutadores ATM o Frame Relay sin superposición ni direccionamiento propio de esas tecnologías. Tampoco exigía que cada salto compartiera un protocolo de enrutamiento ampliado para transportar etiquetas.

Pero una propiedad arquitectónica no observa el sistema. Que LDP pudiera unir esos componentes no demostraba que el software estuviera instalado, que las tablas se programasen o que los paquetes cruzaran el camino. La declaración reducía dependencias; no emitía recibos operativos.

La ingeniería de tráfico comenzaba fuera de esa frontera

Un LSP explícitamente enrutado podía apartarse del camino normal. RFC 3037 situó esa función en extensiones: CR-LDP o RSVP-TE. En aquel momento declaró que no existía consenso sobre la superioridad técnica de una y dejó a los administradores elegir según necesidad y situación.

La extensibilidad del LDP básico no convertía una función futura en capacidad presente. Un formato para nuevos mensajes y TLV solo establecía cómo evolucionar y cómo reaccionar ante elementos desconocidos. La extensión concreta todavía debía especificarse, implementarse, habilitarse y acordarse entre pares.

Dos años después, RFC 3468 registró una decisión distinta en el tiempo: el grupo MPLS y el IESG concentrarían el nuevo esfuerzo en RSVP-TE y no abrirían más trabajo de grupo sobre CR-LDP. Conservaron los estados de los RFC existentes y no prohibieron contribuciones individuales. Esa decisión prueba una asignación de trabajo normativo en 2003, no una migración universal ni un ganador ya instalado en enero de 2001.

“Recomendado” tenía sujeto y condición

El nivel de requisito se aplicaba a dispositivos que ya cumplían una descripción funcional: reenviar MPLS por rutas normales y basadas en destino. No decía que cualquier dispositivo relacionado con MPLS tuviera que usar LDP. Tampoco decía que disponer del código acreditara su uso.

Un equipo puede implementar LDP y dejarlo desactivado. Puede activarlo sin descubrir un vecino. El descubrimiento puede no conseguir TCP. TCP puede abrirse y fracasar la negociación. Una sesión operacional puede carecer de la asociación necesaria. Una asociación puede quedar fuera de la tabla de reenvío. Una tabla puede no recibir tráfico.

La recomendación viaja bien porque no pretende controlar esos hechos locales. El error aparece al convertirla en una columna de “cumple y funciona” que borra todas las transiciones.

La fiabilidad de TCP no era la fiabilidad del servicio

RFC 3037 describió el orden. Primero se descubría un par potencial. Después se establecía la conexión TCP y se negociaban parámetros como el método de distribución. Solo tras el acuerdo la sesión se consideraba operacional y se utilizaba para distribuir etiquetas.

TCP entregaba los mensajes de sesión de forma fiable, por lo que las asociaciones y el estado del LSP no necesitaban refresco periódico. Eso ahorraba tráfico, pero la garantía pertenecía al transporte. No decía que el receptor hubiese aceptado el significado pretendido, que el siguiente salto siguiera vigente, que el ASIC tuviera la entrada o que un paquete alcanzara el destino.

Precisamente porque el estado podía durar sin renovarse, una investigación necesitaba historia. La mera presencia de una asociación no revelaba cuándo se creó, qué sesión la sustentaba ni si la ruta había cambiado.

Cada modo compraba una propiedad y pagaba otra

Downstream Unsolicited permitía anunciar asociaciones al estar listo para la FEC; Downstream on Demand respondía a una petición concreta. La retención liberal guardaba todas las etiquetas aprendidas; la conservadora soltaba las innecesarias. El control independiente anunciaba según criterio local; el ordenado esperaba al siguiente salto de la FEC o a ser egreso.

Para enlaces con etiquetas escasas, como ATM y Frame Relay, el documento consideró apropiada la combinación bajo demanda, conservadora y ordenada. Si las etiquetas abundaban, anuncio no solicitado, retención liberal y control independiente podían conservar alternativas útiles para cambiar de siguiente salto sin redistribuir.

No era una orden de configuración única. El protocolo aceptaba otras combinaciones y variantes híbridas. Ahorrar etiquetas reduce estado sobrante, pero puede exigir más señalización al cambiar la ruta. Retenerlo ocupa recursos, pero acelera ciertos cambios. Anunciar pronto acorta una dependencia temporal y a la vez adelanta una afirmación. La topología y las mediciones deciden si el intercambio compensa.

Lo obligatorio de implementar podía ser opcional de usar

La detección de bucles mostró la diferencia sin ambigüedad. Un LSR compatible con LDP debía implementar el mecanismo destinado a LSP que cruzaban nubes sin decremento de TTL. Sin embargo, la configuración podía desactivarlo.

La afirmación “el equipo soporta detección” no implicaba “la red está protegida”. Hacían falta configuración local, coherencia en el dominio, atributos propagados, ruta vigente y observación del plano de datos. Una capacidad binaria en inventario no capturaba esa cadena.

El mismo cuidado se aplicaba a seguridad. El TCP MD5 opcional reducía la posibilidad de insertar segmentos falsificados en el flujo de una sesión. No legitimaba una FEC, no autorizaba una ruta, no demostraba la exactitud de una asociación y no protegía por sí mismo el servicio de usuario.

La escalabilidad seguía dependiendo de cantidades observadas

El documento relacionó decisiones con costes: distribución incremental sin refresco periódico; menor consumo de etiquetas con modos conservadores; menos redistribución con retención liberal; límite de pares según conexiones TCP soportadas; más memoria, proceso y tráfico al usar vectores de camino para bucles.

Son mecanismos causales, no cifras de capacidad. Para conocer la escala real había que medir pares, etiquetas, memoria, CPU, mensajes, convergencia y reenvío. La RFC señalaba dónde mirar, no lo que marcaría el instrumento.

La lectura histórica correcta conserva esa modestia. RFC 3037 recomendó una herramienta para un trabajo definido y reconoció elecciones alrededor. El código, la configuración, el estado acordado y los paquetes pertenecían a otros actores y a otras pruebas.

Fuentes

Lu Heng no escribió ni avaló RFC 3037 ni los estándares relacionados. Sus ensayos se usan aquí como marcos analíticos expresamente declarados.