Resumen

  • RFC 2383 establecía un circuito virtual ATM por salto ST2+ y separaba los planos de usuario, control y gestión: el camino reservado para los datos no era la misma evidencia que el camino capaz de informar de su fallo.
  • Como la recuperación de ST2+ era incompleta y varios agentes podían recibir simultáneamente el aviso de ATM, la especificación exigía NoRecover. Un rechazo explícito era más interoperable que una promesa sin autoridad ni orden compartidos.

Reservar capacidad no equivale a reservar una vuelta desde el fallo.

Esa fue la frontera que dejó visible RFC 2383, publicado en agosto de 1998 como documento informativo para transportar ST2+ sobre ATM UNI 3.1. El mapeo era estrecho: un salto ST2+ utilizaba un circuito virtual ATM; el circuito no se compartía con otros saltos y el salto no se distribuía entre varios circuitos. La petición abstracta de recursos obtenía así un soporte concreto.

La recuperación, sin embargo, no obtuvo la misma precisión. Las implementaciones debían seleccionar NoRecover en CONNECT. Si una petición no lo hacía, el receptor debía responder con REFUSE y la razón NoRecover. El texto no llamó a esto recuperación automática limitada ni trató el aviso de ATM como sustituto de la semántica que faltaba en ST2+. Declaró que no admitía recuperación del flujo y que debía resolverla la aplicación.

La decisión importa porque el sistema ya tenía muchas piezas que podían confundirse con una recuperación. ATM podía señalar una conexión perdida. Los agentes ST2+ intercambiaban SCMP. Un FlowSpec reservaba recursos salto a salto. Era posible establecer otro circuito. Ninguna de esas verdades elegía al agente que debía actuar, evitaba intentos duplicados, vinculaba necesariamente el reemplazo al flujo original ni demostraba un resultado aceptado por la aplicación.

Un salto, un circuito, varias verdades

RFC 2383 distinguía los planos de usuario, control y gestión. Los datos ST2+ viajaban por la conexión ATM asignada al salto. Los agentes intercambiaban SCMP en el plano de control. La gestión local seleccionaba direcciones, establecía circuitos y observaba su estado.

Los tres planos no tenían que coincidir en una sola ruta. La especificación no fijaba el circuito virtual de SCMP: una implementación podía reutilizar un VC de IPv4 o establecer otro dedicado al control de ST2+. Los datos de un flujo y sus mensajes SCMP debían seguir la misma dirección de encaminamiento ST2+, pero la ruta IPv4 hacia la misma dirección IP podía ir en sentido contrario. El control podía seguir disponible mientras el circuito de datos reservado estaba roto, o fallar por separado.

Por eso, «la red es alcanzable» era una afirmación débil. ¿Había encontrado ruta un paquete IPv4? ¿Había llegado SCMP al agente? ¿Conservaba el conmutador el estado de la llamada? ¿Pasaban los datos de usuario por ese VC concreto? Cada respuesta pertenecía a una capa distinta y ninguna certificaba automáticamente las demás.

La regla de un VC por salto hacía más concreta la evidencia y, al mismo tiempo, limitaba su alcance. El circuito era el soporte de ese tramo. Un flujo de extremo a extremo dependía de varios saltos, circuitos y agentes. La pérdida de un VC identificaba un segmento roto; no reconstruía el flujo completo.

Detectar el fallo no coordinaba la recuperación

La función HELLO de ST2+ podía no estar soportada sobre ATM, porque se esperaba que ATM notificara adecuadamente el fallo de la conexión. Sin embargo, los datos y SCMP podían circular por VC distintos. Una señal de vida en uno no demostraba el estado del otro.

La separación se volvía peligrosa al intentar recuperar. RFC 1819 había descrito mecanismos de ST2+, pero RFC 2383 los consideró poco claros e incompletos para este entorno. ATM podía avisar a todas las partes afectadas. Así, varios agentes ST2+ podían detectar el mismo fallo casi al mismo tiempo.

Si cada uno actuaba de forma independiente, aparecía una carrera. Uno podía liberar el estado antiguo mientras otro lo reconstruía; podían surgir dos circuitos sustitutos; un segmento posterior podía unirse al intento equivocado. No bastaba con un disparador. Hacían falta una regla de autoridad, una identidad común de recuperación, un orden de operaciones y recibos separados para detectar, liberar, admitir, reconstruir y obtener la aceptación de la aplicación.

RFC 2383 no convirtió esos elementos en un contrato interoperable. NoRecover nombraba la superficie de control ausente. Un conmutador podía decir con verdad que el VC había desaparecido, un agente podía confirmar que recibió la alerta y un nuevo circuito podía acreditar su admisión. La aplicación todavía podía sufrir un hueco, una repetición o la falta total del flujo esperado.

La aplicación heredó la última obligación

Decir que la aplicación debía encargarse de la recuperación no le concedía una capacidad automática. Trasladaba el problema no resuelto a la capa que conocía el significado de la continuidad. Para una aplicación podía bastar con reanudar desde un número de secuencia. Otra debía empezar un flujo nuevo y descartar el resultado parcial. Una operación no repetible podía exigir una decisión humana.

La red podía ofrecer otro camino, pero no sabía si el camino viejo y el nuevo componían una única operación válida. Por tanto, el establecimiento de un VC de reemplazo no justificaba la etiqueta «recuperado». La prueba tenía que unir el aviso, las identidades de ambos circuitos, la liberación de la reserva anterior, la reconstrucción del salto, la identidad del flujo completo y el recibo de la aplicación.

La lente de capas de realidad de Heng Lu ayuda a ver el error. El estado físico, la llamada ATM, el agente ST2+, el intercambio SCMP, la sesión de aplicación y el resultado del usuario están relacionados, pero no son sinónimos. Comprimirlos en una luz verde da claridad visual a costa de las diferencias que hacen verdadera o falsa la afirmación. Quien nombra «recuperado» puede no ser quien soporte las consecuencias de la pérdida o la repetición.

La dirección de establecimiento también era política

Incluso antes del fallo, el circuito necesitaba un iniciador. Para los circuitos virtuales conmutados, RFC 2383 permitía elegir qué parte iniciaba la conexión ATM según la política operativa o de facturación. Esa dirección era independiente de la orientación emisor–receptor con la que se construía el flujo ST2+.

Podía iniciar la llamada quien pagaba; quien construía el flujo podía esperar una acción del siguiente salto; y el primer agente que viera el fallo podía carecer de autorización para crear un nuevo circuito facturable. Un diseño que ignore esos poderes e incentivos puede parecer coherente en el diagrama y ser imposible en operación.

El mapeo de FlowSpec a parámetros ATM tenía otro borde rígido. Las características de tráfico y la calidad de servicio se traducían tomando como referencia los modelos de RFC 2211 y RFC 2212 y la señalización de RFC 1755. UNI 3.1 no permitía modificar la QoS de una conexión ya establecida. Si un cambio admitido de FlowSpec requería otros recursos, la implementación debía liberar las conexiones ATM antiguas y crear otras nuevas.

No era una edición en el mismo lugar, sino un traspaso entre asignaciones. El momento en que cesaba el circuito anterior, el momento en que se admitía el nuevo y el estado que sobrevivía a un fracaso dependían de la implementación y de la política. La RFC definía el mapeo y la necesidad de reconstruir; no publicaba mediciones de transición sin pérdidas ni una prueba de continuidad de aplicación.

Ese límite separa esta historia de la de RFC 2380. En RFC 2380 el problema propio era cambiar una reserva, la reduced reservation y el compromiso entre la asignación antigua y la nueva. RFC 2383 trata otra incertidumbre: varios agentes pueden observar el fallo ATM, pero no existe una autoridad completa de recuperación.

El rechazo explícito también era interoperabilidad

Es fácil leer NoRecover como una función inacabada. También era una decisión positiva. Si una implementación ejecutaba una secuencia privada mientras la otra interpretaba el mismo estado de modo distinto, podían aparecer duplicados, reservas huérfanas o dos significados incompatibles del flujo.

La bandera obligatoria revelaba el límite durante el establecimiento. La petición recibía un REFUSE con una razón nombrada, en vez de esconder la divergencia hasta una futura avería. Una interfaz que falla con precisión es más segura que otra cuyos extremos no comparten la definición del éxito.

Desde la idea de especificación inicial mínima de Heng Lu, era una incompletitud disciplinada. Una especificación mínima no debe cubrir un terreno sin probar con palabras que se parecen a garantías. Define el núcleo compartido, localiza la decisión no compartida y deja espacio para que el código en funcionamiento demuestre un contrato más fuerte. Los circuitos dedicados, las direcciones, el establecimiento y el mapeo de recursos estaban en el núcleo; la recuperación del flujo no.

Eliminar NoRecover requeriría algo más que nuevo texto. Habría que entregar el mismo aviso ATM a varios agentes, demostrar la elección de una sola autoridad, suprimir duplicados, saldar la reserva anterior, establecer el sustituto, unirlo al flujo correcto y ofrecer un resultado inequívoco a la aplicación. Las pruebas deberían perder mensajes de control, invertir direcciones y hacer fallar por separado los VC de datos y control.

RFC 2383 no afirmó esos resultados. Su condición informativa también limita la lectura histórica: era una especificación de protocolo, no un estudio de despliegue. El historial del IETF Datatracker demuestra la trayectoria del documento, no una implantación amplia.

La seguridad protegía un borde de la cadena

La sección de seguridad también estaba acotada. Las extensiones mínimas de ATM y las correcciones no debían reducir la seguridad de ST2+ ni de UNI 3.1. Un número de la parte llamante suministrado y verificado por la red podía contribuir a la autenticación.

Contribuir no era completar. La identidad del llamante podía ayudar a reconocer al iniciador, pero no demostraba que el FlowSpec estuviera autorizado, que el nuevo VC perteneciera al flujo fallido o que la aplicación aceptara la sesión reconstruida. Identidad, recursos, estado y resultado necesitaban evidencias complementarias.

El documento tampoco prueba que un operador concreto desplegara el protocolo, que un circuito cumpliera cierta latencia, que una incidencia real se recuperara ni que una política de facturación eligiera una parte determinada. Son hechos operativos que requieren registros propios.

La frontera histórica sí es firme: reserva de recursos, detección de fallos, alcance del control, reconstrucción y éxito de aplicación son cinco afirmaciones diferentes. Las tres primeras pueden existir sin la cuarta; la infraestructura puede reconstruirse sin la quinta. En 1998, RFC 2383 preservó esa distinción con una bandera inequívoca: NoRecover.

No significaba que nada pudiera hacerse después del fallo. Significaba que la red no debía prometer una recuperación terminada antes de compartir su autoridad, su orden y su recibo final. El circuito reservaba los recursos. Los agentes podían saber que se había roto. El sentido de empezar de nuevo seguía perteneciendo a la aplicación.

Fuentes