Resumen

  • RFC 3033 definió cómo representar identificadores de sesiones y recursos, y cómo transportar mensajes de configuración, dentro de Q.2941 Generic Identifier y Q.2957 User-to-user Signaling.
  • La asignación resolvía qué significaban los campos, no si el nuevo circuito se había creado, la capa IP había trasladado la sesión, la reserva había sido admitida o el servicio funcionaba.

La escena histórica tiene dos circuitos y una sola conversación. Al principio, la sesión comparte un circuito virtual predeterminado con otras. Un router decide que durará bastante y solicita otro VC. Entre ambas situaciones aparece un identificador capaz de decir a la señalización remota qué sesión debe tratar. Es tentador leer ese dato como el movimiento mismo. RFC 3033 no lo hizo.

Publicado en enero de 2001 con estado Proposed Standard, el documento asignó valores para dos elementos opcionales de señalización B-ISDN. Se presentó como un marco indispensable para sesiones prolongadas y sensibles a la calidad sobre ATM, pero añadió que quizá no especificara el protocolo completo necesario para una implementación interoperable. Su producto normativo era un vocabulario compartido y unas reglas de transporte, no una garantía de resultado.

La condición estaba escrita antes del verbo mover

El ejemplo de sesión prolongada comienza sobre el VC predeterminado. Tras detectar la duración, el router configura un VC nuevo. RFC 3033 condiciona el paso siguiente: si el nuevo VC se establece con éxito, la sesión se traslada.

En el extremo llamado, la entidad de señalización B-ISDN debe detectar la correspondencia entre la llamada entrante y una sesión del protocolo Internet. Después informa a la entidad IP, que ejecuta el movimiento. El identificador permite que ambas capas se refieran al mismo sujeto. No detecta la sesión, no completa la llamada, no entrega por sí solo la notificación y no cambia las tablas de reenvío.

Por eso una recepción correcta solo acredita un punto de la cadena. El VC puede fallar después. El VC puede existir y la notificación no llegar. La capa IP puede actualizarse y los paquetes continuar por el camino anterior. La evidencia operacional debe seguir esa secuencia en vez de bautizarla entera con el primer acuse.

Dos elementos parecidos dividían identidad y datos

Q.2941 Generic Identifier estaba diseñado para trasladar identificadores entre planos de control. La red ATM podía examinar su contenido y cada elemento podía contener varios identificadores. Q.2957 User-to-user Signaling trasladaba información del usuario mediante esos planos, y la red no revisaba su contenido. Sus reglas de excepción e interoperabilidad también diferían. Sus tamaños máximos eran 63 y 133 octetos, respectivamente.

La palabra “transparente” describía cómo atravesaba la red un elemento sin errores de codificación. No certificaba que el receptor compartiera la semántica, que el emisor estuviera autenticado ni que se hubiera ejecutado la petición. Un contenedor de control puede llegar intacto y seguir siendo una propuesta, no un hecho de datos.

El tipo acotaba la interpretación

RFC 3033 asignó valores de aplicación a IPv4 (0x03), ST2+ (0x04), IPv6 (0x05) y MPLS (0x06). En el campo de tipo, 0x01 significaba Session y 0x02 Resource. Otras franjas quedaban para IANA o para experimentos de una organización.

La sesión IPv4 se construía con origen, destino, protocolo y dos puertos, trece octetos en total. La forma IPv6 ocupaba treinta y siete. Ambas se reservaban para asociaciones explícitas; un comodín requeriría otro tipo. El VCID de MPLS se clasificaba como recurso de cuatro octetos. Esas etiquetas impedían ciertas confusiones sintácticas, pero no decían quién tenía autoridad sobre la sesión ni si la reserva existía.

El documento también marcó lo que no resolvía. No definió el orden de varios identificadores, el significado de varios del mismo tipo ni el de un elemento vacío. Si SETUP o ADD PARTY llevaba Generic Identifier, la respuesta CONNECT o ADD PARTY ACK debía incluir al menos uno, aunque no necesariamente el mismo. Así se habilitaba una negociación cuyo procedimiento detallado quedaba sin especificar.

Si una red no soportaba el elemento, podía liberar la llamada, desechar solo el elemento o desechar el mensaje. La inscripción en un espacio de nombres no compraba transporte universal. Solo daba una lectura estable allí donde el dato sobrevivía.

UUS podía llevar RSVP sin otorgar la reserva

En User-to-user Signaling, el discriminador 0x06 anunciaba una aplicación Internet y 0x02 identificaba un mensaje RSVP. Resv podía viajar con SETUP, ResvConf con CONNECT y ResvErr o ResvTear con RELEASE. Era una forma de aproximar la conversación de reserva a la conversación de llamada ATM.

RFC 3033 distinguía un método secuencial, en el que el protocolo de configuración iba sobre un VC y los estados se establecían uno después del otro, y otro simultáneo, en el que el mensaje acompañaba a la señalización B-ISDN. El segundo podía simplificar control de admisión y temporizadores, pero no cubría al menos el uso de un PVC. No existía una ruta única que la asignación volviera universal.

Tampoco existía una equivalencia entre mensaje y efecto. Un Resv transportado no prueba admisión. Un CONNECT no prueba que los parámetros solicitados estén instalados. Un VC levantado no prueba que el flujo lo use. La reserva, el circuito, el reenvío y la experiencia de la aplicación son registros diferentes.

La especificación mínima preservó la incertidumbre

La agregación de sesiones, los comodines, el flow label de IPv6 y las clases de tráfico quedaron como problemas abiertos. El espacio reservado para futuras asignaciones de IANA era capacidad de gobierno, no evidencia de valores posteriores ni de adopción. Incluso la nota de seguridad limitaba la autenticación posible a información adicional, como un número llamante verificado; el identificador de sesión no se convertía en credencial.

Visto desde el presente, es fácil narrar ATM como un camino que Internet abandonó. Eso perdería la aportación más precisa de RFC 3033. El documento enseñó a compartir un nombre entre sistemas con estados distintos y, al mismo tiempo, dejó visible la distancia entre ese nombre y el cambio que pretendía coordinar. Una especificación puede ser útil precisamente porque no finge haber ejecutado la realidad.

Fuentes

Lu Heng no escribió ni respaldó RFC 3033, las recomendaciones de ITU-T ni los RFC contextuales. Sus ensayos se emplean aquí como lentes analíticas declaradas.