Resumen

  • RFC 3034 definió como segmento sin TTL una cadena de LSR Frame Relay que cambiaba DLCI sin reducir el TTL MPLS; una frontera debía cobrar de una vez los saltos que el núcleo no cobraba.
  • El Hop Count distribuido por LDP podía alimentar esa resta en la entrada unicast, pero seguía siendo una afirmación del plano de control, no una observación de cada paquete ni un recibo de entrega.

La anomalía empezaba con una capacidad desigual. Un conmutador Frame Relay era muy bueno en su tarea esencial: leer un identificador de conexión, sustituirlo y enviar la trama a la interfaz correspondiente. Sin embargo, el circuito que hacía esa operación normalmente no podía modificar el TTL MPLS. Convertir aquel conmutador en LSR dejaba intacta una pregunta: ¿quién cuenta el salto?

RFC 3034, publicado en enero de 2001 como Proposed Standard, respondió sin fingir una función inexistente. Agrupó esos dispositivos en un «segmento sin TTL» y trasladó la contabilidad a sus extremos. Así preservó la semántica de alcance de MPLS adaptándola al hardware disponible.

La etiqueta que decidía estaba en el DLCI

La etiqueta MPLS actual viajaba en el campo DLCI de la cabecera Frame Relay. Las etiquetas adicionales y los demás campos de la pila MPLS se codificaban con la encapsulación genérica. En el interior, el FR-LSR consultaba el DLCI, lo reemplazaba por el de salida y reenviaba la trama.

El estado lógico quedaba repartido. El valor que gobernaba la conmutación estaba en la cabecera de enlace; el TTL y el resto de la entrada superior continuaban siendo significativos en la pila. Al cruzar a otra encapsulación, un LSR tenía que decodificar la pila lógica, operar sobre ella y volver a expresarla. El mismo LSP podía presentar formas distintas en dos enlaces consecutivos.

Si en la salida se retiraba la última etiqueta, la pila no decía explícitamente qué protocolo de red seguía. La asociación de etiqueta debía aportar esa interpretación. Por tanto, la asignación servía para seleccionar tratamiento dentro de un dominio acotado; no autenticaba al emisor, no autorizaba una ruta y no demostraba que una trama hubiese cruzado el circuito previsto.

Los saltos que no tocaban el contador seguían existiendo

El TTL tenía que limitar tanto los bucles como el alcance. Si una sucesión de cinco conmutadores contase como cero, el paquete saldría con más vida de la que habría conservado al atravesar una secuencia equivalente de routers. Una conmutación local correcta no bastaba para mantener la propiedad global.

El RFC formuló el cálculo como TTL de salida = TTL de entrada - d. El valor de d dependía de las encapsulaciones de entrada, reenvío y salida. Dentro de un segmento Frame Relay al mismo nivel era cero, porque el cargo se hacía en el borde. En el reenvío MPLS genérico solía ser uno. Al entrar en el tramo sin TTL podía ser la longitud completa propagada para ese tramo.

En unicast, esa longitud se llevaba hacia la entrada y se descontaba antes de admitir el paquete. En multicast, se propagaba hacia la salida para que allí se aplicara el cargo pertinente. No era una licencia para ignorar saltos, sino una reubicación del momento en que se reflejaban en el contador.

La entrada resolvía el vencimiento antes del núcleo

El débito anticipado podía impedir una travesía inútil. Si la resta indicaba que el TTL vencería antes de alcanzar la salida, el FR-LSR de entrada no debía introducir el paquete unicast etiquetado en el segmento.

Debía intentar devolver el error ICMP previsto en las reglas de pila de etiquetas o reenviar el paquete sin etiqueta con el TTL propio del reenvío IP. Cuando el TTL entrante era uno, únicamente quedaba la vía de error.

Cada verbo marca un límite probatorio. Intentar generar ICMP no demuestra que el origen lo recibió. Entregar el paquete al reenvío sin etiqueta no demuestra que llegó a su destino. El recibo de frontera acredita la decisión y sus operandos, no el desenlace posterior.

LDP propagaba un número, no una traza

El objeto Hop Count de LDP podía proporcionar la longitud usada en el cálculo. Un FR-LSR que recibía un valor conocido desde abajo lo incrementaba antes de anunciar la asociación hacia arriba. Lo desconocido seguía marcado como desconocido. Si el incremento rebasaba el máximo, la asociación no podía propagarse y debía notificarse el error.

Con control ordenado, el nodo esperaba una asociación descendente antes de responder al ascendente y podía incluir el número ya incrementado. Con control independiente, podía anunciar antes una asociación con cuenta desconocida y corregirla después. Si LDP no aportaba cuenta o la declaraba desconocida, el algoritmo de RFC 3034 usaba uno como valor por defecto.

Ese uno no era un descubrimiento topológico. Permitía proceder de manera definida cuando faltaba el dato. Y una cuenta conocida tampoco era telemetría: se había construido a partir de estado de enrutamiento y mensajes de distribución. No probaba que todos los equipos continuaran activos ni que un paquete concreto recorriera precisamente esa secuencia.

El cambio de ruta cambiaba también la deuda

Una asociación ya distribuida no congelaba el mundo. La llegada de una respuesta descendente o la elección de otro siguiente salto podía alterar la cuenta. RFC 3034 exigía propagar la corrección hacia la entrada. Si la nueva longitud superaba el máximo, las etiquetas de la FEC tenían que retirarse a los vecinos ascendentes para no ocultar un bucle detrás de una cifra inválida.

Los fallos imponían más retiradas. Si una solicitud descendente no se podía satisfacer, la asociación provisional creada por una petición ascendente debía destruirse y notificarse. La pérdida de una sesión LDP invalidaba todas las asociaciones aprendidas por esa conexión. La retención liberal permitía reutilizar estado solo bajo las condiciones coincidentes de ruta y Hop Count descritas en el texto.

De ahí que una entrada en la base de etiquetas no equivalga a un camino operativo. Su fecha, su sesión de origen, la dependencia descendente y la cuenta que acompañaba a la ruta elegida forman parte de su validez.

La adaptación no borró las fronteras de autoridad

Un conmutador usado como LSR debía asignar y mantener etiquetas y participar como par en el protocolo de enrutamiento de red. Aun así, el control Frame Relay tradicional y el control de conmutación por etiquetas podían coexistir de forma independiente en el mismo equipo, compartiendo solo recursos limitados como la división del espacio DLCI. La operación conjunta quedaba fuera del alcance del RFC.

Ese diseño no convirtió el símbolo en ejecución. La ruta seleccionaba una dependencia, LDP comunicaba una cuenta, la entrada hacía una resta y el núcleo cambiaba identificadores. El paquete y el TTL de salida eran recibos distintos. RFC 3034 hizo compatible una garantía con un hardware limitado; no convirtió la cifra anunciada en la realidad del trayecto.

Fuentes

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