Resumen

  • RFC 3475 exigía que el procesamiento de Call Release iniciara la liberación de todas las Connections asociadas.
  • Cada rama conservaba sus procedimientos Label Withdraw y Label Release, por lo que la confirmación superior no demostraba finalización simultánea, limpieza física ni cierre del servicio.

Un botón de cierre puede iniciar más trabajo del que termina. En marzo de 2003, RFC 3475 mostró esa diferencia en el control ASON.

El documento era Informational, no Internet Standard. Registraba asignaciones IANA para extensiones CR-LDP elegidas por el trabajo ASON de la UIT-T y dejaba su uso normativo en documentos de esa organización. Era una propuesta de maquinaria, no evidencia de adopción.

La arquitectura separaba la Call, relación entre partes, de las Connections que consumían recursos. Una sola Call podía tener varias. Call Setup y Call Release actuaban sobre el objeto superior; los mensajes de etiquetas seguían actuando sobre cada realización.

Call Release llevaba Source ID, Destination ID y CALL_ID. Cualquier entidad de la red podía enviarlo para terminar una Call establecida. Una Notification con el código correspondiente confirmaba la liberación al iniciador. Sin embargo, ese recibo solo describía la operación superior.

Procesar el mensaje debía activar la liberación de todas las Connections asociadas. Para cada una, RFC 3475 remitía a los procedimientos CR-LDP ordinarios de Label Release y Label Withdraw. Una orden se convertía en un conjunto de transiciones distribuidas.

RFC 3036 explicaba su secuencia. El LSR descendente retiraba un mapeo mediante Label Withdraw y el receptor respondía con Label Release. Un LSR ascendente también liberaba cuando ya no necesitaba el mapeo. Eran recibos por par, FEC y etiqueta, no una confirmación universal.

Así, tres Connections podían estar terminada, pendiente y activa al mismo tiempo. La obligación de liberar todas no creaba atomicidad. La Notification de la Call y el cierre probado de cada rama eran resultados distintos.

La lista asociada debía capturarse en el instante de la liberación. Consultar después una lista vacía no mostraba cuántas ramas existieron, cuáles reintentaron ni si una desapareció del inventario antes de devolver recursos físicos.

CALL_ID unía el relato, pero no certificaba su desenlace. No probaba procesamiento de cada Withdraw, eliminación de etiquetas, liberación de cross-connects, caída de señal, cese de tráfico o cierre comercial.

Las soft permanent connections añadían otra frontera: sus segmentos usuario-red podían seguir aprovisionados aunque se desmontara el segmento conmutado. La desaparición de una Connection controlada no describía toda la infraestructura.

Crankback ofrecía el espejo durante el establecimiento. Una Notification con ER-HOP localizaba la escasez para recalcular una ruta. Saber dónde falló la primera solicitud no probaba que la alternativa tuviera recursos ni que la siguiente tuviera éxito.

Los textos posteriores, incluido RFC 4974 para procedimientos RSVP-TE, no cambian retroactivamente el alcance ni el estatus de RFC 3475. Tampoco demuestran una implementación concreta.

Con las capas de realidad de Heng Lu, Call Release es instrucción, su procesamiento es decisión, cada mensaje de etiqueta es recibo limitado y la limpieza de estado, hardware, señal, tráfico y servicio son observaciones sucesivas. Un sistema responsable conserva la foto de Connections, cierra cada rama con evidencia propia y solo entonces declara cerrada la Call.

Fuentes