Resumen

  • RFC 1953 asignó al extremo aguas abajo la gestión de las etiquetas que recibiría en un sentido del enlace. Ese extremo enviaba Redirect al vecino aguas arriba, que podía ignorar cualquiera o todas las propuestas sin emitir acuse.
  • La asociación era un arrendamiento: un Redirect idéntico renovaba el plazo; una etiqueta distinta para el mismo flujo anulaba la optimización y restablecía el estado predeterminado; la desincronización de la adyacencia obligaba a descartar mensajes.
  • Instalar el atajo era opcional, pero liberar una etiqueta para reutilizarla exigía Reclaim Ack. El documento no abordó problemas de seguridad, de modo que sus números de instancia no equivalían a autenticación.

Cuando el reloj dejó de sostener la etiqueta

El paquete anterior cruzó el enlace con una etiqueta corta. Para el siguiente ya había terminado el lifetime. El vínculo entre flujo y etiqueta dejó de existir, pero el paquete no cayó en un vacío: volvió a llevar la información y el tratamiento del reenvío IP ordinario.

El detalle parece administrativo —un temporizador que llega a cero—, pero define la relación de poder. El camino acelerado dependía del camino normal; no ocurría al revés. La optimización podía evaporarse sin apropiarse de la identidad del flujo.

RFC 1953 apareció en mayo de 1996 con el título Ipsilon Flow Management Protocol Specification for IPv4 Version 1.0 y categoría Informational. La nota del IESG advirtió que documentaba un protocolo privado, no surgido de un grupo de trabajo de la IETF, ajeno al standards track y no necesariamente sometido a su amplitud habitual de revisión.

Esa advertencia impide presentar el texto como estándar universal o como balance de adopción. Tampoco prueba rendimiento comercial, despliegue extenso ni interoperabilidad. Que otros sistemas posteriores emplearan etiquetas no crea por sí solo una genealogía directa hacia MPLS.

Una clasificación creada para reenviar

Para IFMP, un flujo era una secuencia de paquetes relacionada por decisiones de ruta o por una política lógica de tratamiento. El Flow Type especificaba qué campos invariantes del encabezado componían la clave. Los tipos mantenían relaciones de subconjunto y superconjunto para escoger la coincidencia más específica.

La primera versión incluía un tipo nulo, un tipo TCP/UDP con direcciones, protocolo y puertos, y otro más amplio que omitía puertos y ciertos campos. Era una taxonomía de ejecución. No identificaba de forma autenticada a una persona, una aplicación, un propietario ni una autorización.

La etiqueta abreviaba una decisión guardada. Esa abreviatura funcionaba mientras ambos vecinos compartieran el mismo contexto. Si el enlace había renacido o uno de los pares recordaba una sesión distinta, el mismo número podía designar otra cosa.

Por eso, antes de redirigir, IFMP sincronizaba la adyacencia. Sender Instance debía cambiar cuando un nodo o enlace regresaba después de caer, ser único en el pasado reciente y nunca valer cero. Peer Instance y Peer Identity registraban la visión local del vecino. La secuencia de redirección avanzaba módulo 2^32 y se reiniciaba con el enlace.

No se podían enviar mensajes de redirección antes de ESTAB. El receptor comparaba dirección de origen, sender instance y peer instance con su estado; cualquier diferencia exigía descartar. Era continuidad de una encarnación reciente, no autenticación criptográfica. La sección de seguridad fue explícita en su vacío: los problemas de seguridad no se discutían.

El número pertenecía abajo; la decisión seguía arriba

Cada dirección del enlace se trataba por separado. El extremo aguas abajo, que recibiría el tráfico etiquetado, gestionaba el espacio de etiquetas. Elegía una y, mediante Redirect, pedía al extremo aguas arriba que la adjuntara a los paquetes del flujo indicado.

El reparto seguía la ubicación del recurso: quien interpreta la etiqueta escoge su valor. Sin embargo, la propuesta no imponía ejecución. El vecino aguas arriba podía ignorar cualquier elemento Redirect o todos ellos. No había respuesta de confirmación. Haber transmitido un Redirect solo demostraba la solicitud, nunca la instalación ni el resultado del tráfico.

Label Range comunicaba un mínimo y un máximo inclusivos que el enlace podía manejar. Era evidencia de capacidad local, no registro global. Una cifra idéntica podía ser válida con otro significado en la dirección opuesta o en otro enlace.

Ante dos verdades comprimidas, volver a la ruta

Cada Redirect llevaba una duración positiva en segundos. El vínculo debía desecharse como máximo al vencer. Una propuesta idéntica renovaba el arrendamiento; la misma etiqueta sobre un flujo ya redirigido reiniciaba el contador.

Si aparecía una etiqueta distinta para ese flujo, IFMP no trataba de adivinar cuál orden era más reciente o conveniente. Ignoraba la nueva propuesta y devolvía el flujo al estado predeterminado. La contradicción no se resolvía escogiendo el atajo más atractivo, sino abandonando la compresión.

La propiedad importante de un acelerador no es solo cuánto reduce la latencia cuando todo coincide. También es si puede desaparecer sin cambiar el significado del sistema. Expiración, reinicio, salto de secuencia, vecino distinto o reasignación contradictoria debían contraer la incertidumbre hacia el reenvío normal.

RFC 1954 trasladó las etiquetas a valores VPI/VCI de ATM. Ciertos formatos redirigidos omitían campos IPv4 repetidos y, en un tipo, los primeros campos de puertos TCP o UDP. La información no se eliminaba: pasaba al estado compartido. El tráfico de control y la vía predeterminada conservaban la encapsulación de base.

Una solicitud abre; un recibo permite reutilizar

Redirect no tenía acuse porque el rechazo era seguro: el flujo seguía su ruta. Reclaim afrontaba una consecuencia distinta. Pedía desvincular el flujo, restaurar el reenvío predeterminado y soltar la etiqueta. Reutilizarla antes de que el cambio terminara podía mezclar datos en cola con un significado nuevo.

Cada Reclaim debía recibir Reclaim Ack una vez completada la operación. Incluso un flujo desconocido obtenía respuesta. Si el flujo conocido estaba asociado a otra etiqueta, el receptor eliminaba la asociación real y reconocía el valor que de verdad había liberado. Cuando fuera posible, esperaba primero a enviar los datos en cola que aún usaban esa etiqueta.

El acuse probaba una transición delimitada entre vecinos: flujo desvinculado y etiqueta libre en el estado de IFMP. No certificaba cada cola física ni la entrega final. Pero impedía tratar una intención de retirada como disponibilidad consumada.

La asimetría es valiosa fuera de IFMP. Crear una mejora puede ser especulativo cuando negarse no rompe nada. Reciclar un identificador escaso después de destruir una asociación requiere evidencia de terminación.

Comparar arquitecturas sin inventar una línea de sangre

IFMP formó parte de los intentos por combinar decisiones IP con conmutación ATM. GSMP, documentado en RFC 1987, describió un controlador maestro que instalaba conexiones en un switch, administraba puertos y obtenía estadísticas. Tag Switching separó también control y reenvío y contempló asignaciones impulsadas por la topología además de la granularidad de flujo.

La arquitectura MPLS y LDP posteriores muestran que las asociaciones de etiquetas y la separación entre control y reenvío se volvieron una familia duradera. No demuestran que IFMP causara cada mecanismo, ni autorizan a leer las reglas posteriores dentro de un documento de 1996.

La comparación responsable conserva preguntas comunes: ¿quién administra el identificador corto?, ¿quién propone usarlo?, ¿quién puede negarse?, ¿cuándo vence?, ¿qué ocurre si los estados divergen?, ¿qué prueba habilita su nueva asignación?

La etiqueta escrita no era la acción realizada

La primacía del código en ejecución de Heng Lu separa cuatro capas de evidencia. Una especificación define Redirect. Un mensaje capturado prueba que alguien lo envió. Una tabla interna puede probar que el receptor almacenó algo. Solo el comportamiento observado de los paquetes demuestra la ejecución del atajo. El símbolo no trae consigo el resultado.

La especificación inicial mínima ayuda a explicar la autonomía de IFMP. Los vecinos compartían claves de flujo, instancias, secuencias, plazos, rangos y recibos de liberación. No necesitaban una autoridad global de etiquetas ni una obligación de aceptar. Un borde coordinado podía seguir albergando dos decisiones locales.

También conviene separar las capas de realidad. Una etiqueta puede aparecer sin vínculo vigente; el vínculo puede existir en un equipo y faltar en el otro; la adyacencia puede parecer estable hasta que un reinicio la vuelve antigua. Inscripción, estado compartido y reenvío efectivo están relacionados, no son equivalentes.

El conmutador ofreció una vía más corta. El router conservó la posibilidad de rechazarla. Gracias a ese no, la ruta rápida siguió siendo una opción y no un nuevo soberano.

Fuentes y límites

La identidad histórica se verifica en la ficha de RFC 1953 y el mecanismo en el texto de RFC 1953. La realización ATM está delimitada por RFC 1954 y el contexto de encapsulación de RFC 1483. Para el control del switch se usa la ficha de RFC 1987. Las comparaciones sin causalidad lineal son RFC 2105 sobre Tag Switching, RFC 3031 sobre MPLS y RFC 5036 sobre LDP. El análisis sigue Running-Code Primacy, Minimum Initial Specification y Reality Layers.

Estas fuentes sustentan el protocolo y comparaciones acotadas. No prueban adopción universal, rendimiento medido, éxito comercial, interoperabilidad general, seguridad criptográfica ni una descendencia única hasta MPLS.