Resumen

  • La RFC 3478 conservaba entradas de reenvío MPLS y asociaciones label-FEC como estado obsoleto mientras LDP reconstruía su significado.
  • Los tiempos de reconexión, presencia, recuperación y retención, más la prohibición de reutilizar pronto una etiqueta, convertían la continuidad en un préstamo limitado y no en prueba de recuperación.

“Reinicio ordenado” parece prometer que el sistema vuelve entero. La RFC 3478 describía un pacto más frágil: el componente LDP del plano de control podía reiniciarse y volver a aprender, mientras el plano de reenvío seguía aplicando reglas instaladas antes del corte. Los paquetes podían sobrevivir a la explicación que justificaba su ruta.

La suposición era deliberadamente mínima. Un LSR capaz de preservar estado de reenvío MPLS no debía guardar todo el estado de LDP. Bastaba con mantener la correspondencia de etiqueta entrante a etiqueta saliente y siguiente salto, o en ingreso, de FEC a etiqueta saliente y siguiente salto. Eso evitaba perturbar de inmediato un LSP, pero no demostraba que el control recordara el significado de cada etiqueta.

Tras reiniciar, las entradas conservadas quedaban marcadas como obsoletas. Un nuevo Label Mapping podía confirmarlas si coincidían la etiqueta de salida y un siguiente salto aprendido del vecino. Los casos de Implicit NULL, penultimate hop y egress añadían condiciones sobre pop y FEC. Solo la evidencia reconstruida quitaba la marca stale.

El procedimiento alternativo permitía incluso dos asociaciones locales para una FEC durante la recuperación: una retenida del proceso anterior y otra creada después. Compartían etiqueta de salida y siguiente salto, y la antigua desaparecía al terminar. La continuidad no equivalía a una verdad única del plano de control en cada instante.

El tiempo gobernaba el acuerdo. El FT Session TLV del mensaje Initialization llevaba FT Reconnect Timeout y Recovery Time. El primero indicaba cuánto quería el emisor que el vecino mantuviera el estado antiguo tras perder comunicación. El segundo indicaba cuánto estaba dispuesto el LSR reiniciado a conservar el reenvío que realmente había podido preservar.

El cero tenía consecuencias claras. FT Reconnect Timeout cero decía que el emisor no preservaría su propio reenvío, aunque podía ayudar a un vecino que sí lo hiciera. Recovery Time cero decía que el estado previo no estaba disponible. En tal caso, el vecino debía eliminar asociaciones stale, no esperar indefinidamente.

La política local acortaba la solicitud remota. Antes de reconectar, el estado duraba el menor valor entre FT Reconnect Timeout y Neighbor Liveness Timer. Después de reconectar con Recovery Time no nulo, la retención quedaba limitada por el menor entre ese tiempo y Maximum Recovery Time local. En el router reiniciado, MPLS Forwarding State Holding timer eliminaba las entradas que aún seguían stale al vencer.

No eran relojes duplicados. El vecino pedía una duración, el operador local fijaba cuánto confiar y el equipo reiniciado limitaba sus restos. La ventana efectiva era la intersección de controles, no el número más alto del mensaje.

La RFC recomendaba completar el intercambio de mappings antes de la mitad de Recovery Time. Sin embargo, recuperar la sesión TCP/LDP no probaba que toda la LIB hubiera llegado. El texto original no contenía una señal explícita de finalización. RFC 5919 añadió más tarde End-of-LIB Notification. Ese documento muestra la carencia probatoria, pero no puede proyectarse como campo del contrato de 2003.

La cuarentena de etiquetas protegía el límite. Si un LSR de salida liberaba un número y le daba un significado nuevo mientras el vecino de entrada seguía enviando con el anterior, los paquetes podían ir al destino equivocado. Por eso una etiqueta liberada no debía reutilizarse hacia un vecino con graceful restart durante al menos FT Reconnect Timeout más Recovery Time. Se aislaba el significado, no solo la cifra.

La sección de seguridad mostraba que el tiempo era atacable. Un impostor o interceptor podía fijar Recovery Time en cero y provocar liberaciones. Al contrario, una etiqueta de ámbito plataforma reutilizada demasiado pronto podía encontrarse con un upstream que aún mantenía la asociación antigua. La autenticación ayudaba, pero la auditoría debía reconstruir lo que cada lado creyó y cuándo.

Que el tráfico no se interrumpa es un comprobante estrecho. Demuestra que algunas entradas sobrevivieron y funcionaron para los paquetes observados. No demuestra que todas las FEC se refrescaran, que la sesión nueva reconstruyera la LIB, que se conservara la propiedad de etiquetas creadas también por BGP o RSVP-TE, ni que el significado fuera seguro después del último temporizador.

La disciplina de capas de Heng Lu empieza por identificar las sesiones antigua y nueva, los eventos TCP, el TLV y todos los temporizadores. Separa forwarding, LIB y procedencia de protocolo. Registra cuándo cada entrada quedó stale, qué Mapping y dirección del vecino la refrescaron, si cambió la etiqueta, cuándo se borró y si la cifra cumplió su cuarentena.

Solo entonces se unen los datos de tráfico. Una gráfica sin pérdidas no es un registro de reconstrucción. Una sesión verde no es End-of-LIB. Recovery Time no nulo declara retención; no la mide. Una entrada capaz de reenviar sigue obsoleta hasta que el control aporta la prueba para renovarla.

La RFC 3478 merece un lugar en la historia de Internet porque apoyó la continuidad en la duda disciplinada. El plano de datos podía vivir un poco más que su relato de control, pero el pasado no se convertía en verdad permanente. Las etiquetas reenviaban con tiempo prestado; el protocolo decidía quién concedía el préstamo, quién lo acortaba y cuándo debía terminar.

Fuentes