Resumen

  • La RFC 3474 propuso un CALL_ID constante durante la vida de una Call ASON, con una forma específica del operador y otra diseñada para ser globalmente única.
  • La identidad pertenecía a la relación: las Connections, el estado RSVP, las etiquetas locales, los recursos, la señal, el tráfico y el servicio seguían necesitando pruebas separadas.

Poner nombre a algo no lo hace material. En marzo de 2003, la RFC 3474 llevó esa verdad al control de redes ópticas. El documento apareció como Informational, no como Internet Standard, y planteó extensiones de GMPLS RSVP-TE para requisitos de ASON. Su estatuto limita lo que la historia puede afirmar: documentó una propuesta, no una adopción universal.

La arquitectura distinguía dos objetos que una interfaz mal diseñada podría reducir a una sola fila. Una Call era una relación entre extremos, mantenida por un controlador de Call. Una Connection era la realización que utilizaba recursos y era manejada por un controlador de Connection. Una relación podía durar mientras sus caminos cambiaban. El expediente y el circuito compartían contexto, pero no existencia.

CALL_ID daba continuidad a ese expediente. La variante específica del operador servía dentro de un ámbito acordado. La forma global combinaba código de país ISO, código de operador de la UIT, un código de punto de acceso bajo control de la organización, dirección del LSR de origen e identificador local. Los 64 bits de este último debían conservarse durante toda la Call.

La lista parece sólida porque reúne varias autoridades de nombres. Sin embargo, cada componente aportaba distinción, no conectividad. El identificador ayudaba a saber qué Call mencionaba un mensaje. No reservaba una longitud de onda, no programaba un conmutador, no garantizaba continuidad óptica ni entregaba tráfico. Además, una dirección del LSR válida solo dentro del operador no otorgaba por sí sola alcance mundial a la forma específica del operador.

El proceso de asignación mostraba dónde nacía la autoridad. Un usuario inicial podía enviar CALL_ID igual a cero. El primer nodo de la red asignaba un valor nuevo o verificaba el valor no nulo existente. Los nodos de tránsito debían conservarlo, incluso si no interpretaban la extensión ASON. Path, Resv, PathTear, PathErr y Notify podían transportar el mismo referente. Esa persistencia conectaba registros; no sincronizaba automáticamente el estado que describían.

En la separación básica, una Call tenía normalmente una o más Connections. Durante una restauración break-before-make podía quedar transitoriamente con cero: se retiraba el camino anterior antes de completar el nuevo. CALL_ID permanecía mientras abajo no había una Connection activa. Si el sistema de operaciones mostraba la Call como “conectada” por conservar su ID, ocultaba precisamente el intervalo que más interesaba investigar.

La separación completa opcional era aún más clara. CALL_OPS permitía establecer o sincronizar una Call sin crear a la vez una Connection. En régimen estable podía haber cero, una o muchas Connections. El diseño no trataba el cero como una contradicción. Expresaba que una relación admitida y un transporte efectivo tienen ciclos de vida diferentes.

También SPC_LABEL mantenía una frontera. En una soft permanent connection, podía asociar un segmento de entrada aprovisionado de modo permanente con otro conmutado. La forma de efectuar esa asociación era política local, fuera del alcance del documento. Al cruzar subredes no GMPLS, las etiquetas eran locales al nodo de control y podían provenir de configuración manual o descubrimiento previo. Una asociación correcta en un límite no demostraba el recorrido completo.

Después de un reinicio, el controlador podía recurrir a almacenamiento persistente, inferencia del vecino o instrucciones de gestión. Recuperar CALL_ID probaba memoria del vínculo lógico. No probaba que el vecino coincidiera, que RSVP hubiese convergido, que el equipo mantuviera la programación o que siguiera llegando señal. Cada fuente necesitaba conservarse con su procedencia.

Notify tampoco convertía la identidad en resultado. Una notificación podía llevar sesiones ligadas a CALL_ID, y una sola envoltura podía incluir sesiones de varias Calls. Mensaje, relación y estado de Connection eran entidades correlacionables, no intercambiables.

Las normas posteriores deben leerse en su tiempo. La RFC 4139 desarrolló requisitos y aplicabilidad de ASON. La RFC 4974, ya Standards Track en 2007, definió procedimientos de Call más completos y explicó que una Call no proporcionaba por sí misma conectividad de tráfico; podía tener cero, una o muchas Connections. La RFC 6004 añadió extensiones UNI. Esa trayectoria evidencia refinamiento, no demuestra que la propuesta Informational de 2003 operara en una red concreta.

La disciplina de Heng Lu ofrece una forma útil de auditar el sistema. CALL_ID es un símbolo coordinador. La admisión del controlador de Call es una decisión. La señalización del controlador de Connection es otra. La programación de recursos, la señal física, el tráfico bidireccional y el servicio son capas observables. Una clave común permite unirlas, pero no autoriza a saltarse ninguna.

El registro correcto conserva quién asignó CALL_ID, su forma, su ámbito de unicidad, la dirección de origen y las fechas de la Call. Luego mantiene cada Connection con identidad, periodo de asociación, mensajes RSVP, etiquetas, recursos y cierre propios. Por último incorpora mediciones de señal, tráfico y aplicación. Así puede contar continuidad de relación sin inventar continuidad de servicio.

Fuentes