Resumen

  • PROPOSE y PROPOSE ACK compartían un VCID y comprobaban un Dedicated-VC entre vecinos; OFFER y READY eran el paso posterior que vinculaba un flujo IPv4 específico a esa conexión.
  • La aceptación era local y temporal: podían intervenir rechazos, pérdidas, caducidad y fallos silenciosos. No equivalía a entrega extremo a extremo, capacidad sostenida ni calidad de servicio.

La pausa entre dos mensajes

Un router aguas arriba escogía primero una conexión virtual dedicada. Por ella enviaba PROPOSE con el VCID y la dirección IP del vecino de destino. La respuesta PROPOSE ACK regresaba por el Default-VC, la vía que también seguía disponible para el encaminamiento IP salto a salto. Con ese intercambio, ambos extremos compartían una manera de identificar la conexión y se probaba que la conexión y el vecino funcionaban. Nada allí nombraba todavía el flujo que debía usarla.

El siguiente intercambio cambiaba el objeto de la decisión. Por el Default-VC, el router enviaba OFFER con el VCID, el flow-ID y el intervalo propuesto para las respuestas de renovación. READY indicaba que el vecino aceptaba ese flujo y podía recibir sus paquetes por el Dedicated-VC. El RFC 2129 separaba así la prueba de una conexión de la admisión de un flujo. Una oferta transmitida no era una respuesta recibida; una respuesta de un vecino no obligaba a todos los routers del camino.

Toshiba presentó FANP en un memorando Informational, sin establecer un estándar de Internet. Su objeto era el estado de cut-through entre nodos adyacentes. En el ejemplo de tres routers, el segundo salto repetía el proceso con independencia del primero. El Default-VC conservaba el tratamiento habitual de paquetes IP; el Dedicated-VC podía permitir que un router de conmutación de celdas reenviase las celdas de un flujo seleccionado sin volver a analizar cada cabecera IP. Esta distinción de escala importa: un atajo en un salto no es una ruta global prometida.

El precio de tener una vía disponible

La elección de iniciar el atajo dependía de una política local. El RFC describía como ejemplo los puertos TCP/UDP de sesiones largas o voluminosas. También permitía dos estrategias para conseguir un circuito: reservar de antemano conexiones inactivas o crearlas mediante señalización ATM cuando aparecía la necesidad. La primera ahorraba espera y consumía recursos ociosos; la segunda evitaba parte de esa reserva y añadía tiempo de establecimiento. La especificación exponía un dilema de diseño, no una cuenta de ahorro observada.

El flow-ID definido entonces comprendía solo las direcciones IPv4 de origen y destino. No era el identificador de flujo IPv6. El VCID distinguía la conexión entre vecinos aunque sus valores VPI/VCI locales no coincidieran en ambos extremos. Ni uno ni otro demostraba la identidad autenticada del emisor. Los flujos agregados, la multidifusión, la señalización IP de QoS y IPv6 quedaban expresamente pendientes de trabajo futuro.

Aceptar no significaba conservar para siempre

El vecino podía denegar PROPOSE por política, tipo desconocido o falta de recursos. También podía rechazar OFFER si no conocía el VCID o el tipo de flow-ID, no aceptaba el flujo o el intervalo de renovación, o carecía de recursos. Ante la falta de respuesta, el emisor retransmitía; tras las cinco retransmisiones recomendadas sin el acuse pertinente, debía liberar la conexión elegida. Los números describían un procedimiento recomendado, no una garantía universal.

Después, el estado tampoco se convertía en perpetuo. Mientras recibía paquetes por la conexión dedicada, el vecino aguas abajo enviaba periódicamente READY. Si no llegaban paquetes, dejaba de hacerlo. Aguas arriba se retiraba la asociación al superar el intervalo de espera sin renovación; aguas abajo se retiraba tras un periodo mayor sin paquetes, incluso si el otro nodo había fallado sin avisar. Los valores de ejemplo de dos, seis y veinte minutos ordenaban esos plazos, pero no prometían una duración contractual. La eliminación explícita y la liberación ATM ofrecían otras salidas según el tipo de conexión.

El valor histórico de FANP está en esta contabilidad de pruebas. Seleccionar un VC, recibir PROPOSE ACK, recibir READY y observar una renovación son hechos diferentes. No demuestran por sí solos autenticación, coherencia entre todos los saltos, entrega, capacidad estable, QoS o beneficio económico. El RFC 2098 describía el contexto de la arquitectura de bypass; RFC 2129 mostraba cuánto mantenimiento local requería hacer creíble un tramo de ese atajo.

Fuentes