Resumen

  • La RFC 3479 numeraba operaciones LDP protegidas y hacía que un ACK acumulativo señalara el prefijo que el receptor había guardado de forma recuperable.
  • La reconexión reemitía el sufijo incierto; un checkpoint forzaba la confirmación y tres intercambios Cork detenían ambas direcciones en el mismo límite.

Dos routers podían recordar versiones distintas del último segundo de una sesión. Uno había enviado una solicitud de etiqueta; el otro quizá la recibió, quizá la procesó o quizá la perdió con la conexión. Abrir otro TCP no resolvía esa diferencia. La aportación particular de la RFC 3479 fue dar a los pares una forma de comparar memoria duradera en lugar de suponer continuidad.

El FT Session TLV delimitaba el libro. El bit S habilitaba operaciones con número de secuencia; A podía exigirlas para todas las etiquetas; C activaba checkpoints y podía existir sin S. Esa negociación definía qué operaciones serían recuperables. Guardar un ACK sin conservar los bits deja indeterminada la población que el ACK pretendía cubrir.

Cada mensaje protegido llevaba FT Protection TLV y un número propio de la sesión. El receptor debía asegurar el mensaje o el estado resultante antes de emitir FT ACK. Podía almacenar el mensaje entero o su consecuencia; la representación era local. La obligación común era que la prueba sobreviviera al tipo de fallo para el que se diseñaba la recuperación.

El ACK era acumulativo. Confirmar cuatro cubría el prefijo del uno al cuatro, no las operaciones posteriores. Se podían agrupar confirmaciones y retrasarlas; se toleraban duplicados; se prohibía enviarlas fuera de orden. Si el par demoraba demasiado, el espacio de secuencias sin confirmar podía agotarse y bloquear nuevas operaciones FT. La eficiencia tenía una cola visible.

Al volver TCP, cada extremo indicaba el último número que había asegurado. El emisor reexpedía lo que quedaba después de esa frontera, y el receptor lo procesaba como nuevo. No se reconstruía el flujo de bytes desaparecido. Se reconstruía la parte de la historia cuyo efecto no estaba dentro del prefijo duradero del otro.

La norma permitía compactar dos parejas net-zero: Label Request con Label Abort y Label Mapping con Label Withdraw. Pero no autorizaba a cancelar a ciegas. Una mitad podía haber llegado antes de la caída. La confirmación del par establecía primero qué había cruzado; solo después podía omitirse una pareja cuyo efecto conjunto era realmente nulo.

Address y Address Withdraw también requerían protección. De otro modo, tras reconectar un lado podía considerar vigente una dirección que el otro había retirado. Una dirección ya inválida exigía un Withdraw explícito. Si ambos no afirmaban conservación, el conjunto anterior se daba por retirado y se anunciaba de nuevo.

El checkpoint operaba con otra granularidad. Un Keepalive protegido pedía guardar todos los mensajes check-pointable anteriores y devolver la frontera. Con C sin S, los mensajes ordinarios no llevaban números activos individuales y el checkpoint sincronizaba el conjunto. Con S, cubría etiquetas secuenciadas y direcciones. El nombre no definía el alcance: lo hacía la negociación.

Para una parada controlada, una confirmación unilateral era insuficiente. El nodo que solicitaba detenerse también debía confirmar que había guardado la historia enviada por su vecino. El FT Cork TLV produjo un saludo de tres pasos: petición, terminación y quietud del otro extremo, y cierre inverso. Solo entonces las dos bitácoras terminaban en el mismo punto.

La recuperación podía rechazarse. Un par incapaz de conservar o poner en espera las operaciones debía borrar FT Reconnect Flag. Si cualquiera lo hacía, ambos soltaban el estado antiguo. Un cambio de parámetros, como los límites del espacio de etiquetas, también invalidaba la continuidad porque la operación anterior podía tener otro significado.

La nota del IESG evita convertir el mecanismo en leyenda. Señaló que faltaba orientación adecuada para temporizadores y reintentos, advirtió sobre failovers prematuros y dijo que la especificación no debía ser modelo general para futura tolerancia a fallos TCP. Había reglas para conciliar, no una configuración universalmente segura.

Este ángulo no repite los artículos vecinos. La pieza sobre RFC 3478 posee el estado de reenvío obsoleto y sus ventanas temporales. La de RFC 3612 posee la diferencia entre estado retenido, ACK y verdad del reenvío. Aquí el objeto es la mecánica de la bitácora: alcance, secuencias, frontera duradera, reemisión, net-zero, checkpoint y Cork.

La disciplina de Heng Lu exige reconstruir dos columnas. Para cada par: identidad de sesión vieja y nueva, bits S/A/C/R, parámetros, secuencias enviadas, estado asegurado y ACK transmitidos. En el fallo: operaciones enviadas sin confirmar, recibidas sin asegurar y pendientes. En la recuperación: cada reemisión y cada cancelación. En el cierre: los tres Cork y el instante en que cada lado dejó de producir trabajo.

Así se evitan cuatro atajos. Un ACK no cubre números futuros. Un checkpoint no es una instantánea fuera de su población. Un Cork no equivale a quietud bilateral. Y ningún recibo de control demuestra entrega a una aplicación. Todos responden algo anterior: hasta dónde comparten historia demostrable los dos pares.

La RFC 3479 ocupa un lugar histórico porque trató la recuperación como reconciliación entre memorias parciales. La secuencia acotó la disputa, el ACK señaló el pasado común, la reemisión reconstruyó el sufijo y Cork creó un punto final compartido. Cayó la sesión TCP; el registro tuvo que cuadrar.

Fuentes