Resumen

  • En el SDP de RFC 3108, forward se alejaba del nodo ATM descrito; en la señalización de bearer, forward partía del extremo que iniciaba el establecimiento. Con un SVC iniciado en sentido inverso, el mismo parámetro cambiaba de dirección al cruzar de capa.
  • eecid enlazaba uno a uno el contexto de llamada con la petición de bearer posterior. Era una clave local de correlación, no identidad, autenticación, circuito mundial ni prueba de tráfico.

El dato era correcto; el marco era otro

Una pasarela puede describir como forward el tráfico que sale de ella. La red ATM puede llamar backward a ese mismo tráfico si la petición de establecimiento llegó desde el otro extremo. No hay contradicción dentro de cada sistema. El problema aparece cuando un valor cruza la frontera sin llevar consigo el punto desde el que fue nombrado.

Ese fue el centro operativo de RFC 3108, publicado en mayo de 2001 en Standards Track. El documento extendió el SDP de RFC 2327 para describir conexiones ATM y AAL2: direcciones, capas de adaptación, descriptores de tráfico, calidad de servicio, tipos de bearer, canales y opciones de servicio. Las descripciones podían circular junto con SIP, MGCP o Megaco/H.248.

La llamada de servicio y la conexión que transportaba el medio eran procesos independientes. Quien originaba la llamada no tenía por qué originar el SVC. RFC 3108 fijó la dirección SDP respecto del nodo ATM considerado: alejarse del nodo era forward y acercarse era backward, sin importar quién hubiera iniciado la llamada o el bearer.

La señalización ATM/AAL2 usaba el origen del establecimiento. Forward iba desde quien enviaba setup hacia quien lo recibía. En el modelo backward, la pasarela que originaba el servicio recibía el setup del bearer. Un PCR que salía de ella era forward en SDP y backward en ATM. La pasarela debía intercambiar las direcciones al traducir.

Copiar sin cambiar una cifra podía ser más peligroso que perderla. La línea seguía siendo legal, el número seguía intacto y dos registros podían parecer coincidentes. Sin embargo, capacidad, retardo o tolerancia a pérdida se aplicaban al flujo opuesto.

El indicador de dirección formaba parte del estado

Los atributos atmQOSparms y atmTrfcDesc incluían directionFlag: f, b o fb. El indicador siempre debía aparecer. Otros valores podían usar cuando no estaban especificados, eran irrelevantes, se inferían o procedían de otra fuente.

Los parámetros podían expresar tasas de celda, ráfagas, variación de retardo, demora acumulada y pérdida admisible. Por eso no bastaba con validar campos. Había que conservar el nodo de referencia, el iniciador de la llamada, el iniciador del bearer y la convención activa. La palabra forward sin esos cuatro datos no constituía un hecho completo.

El comodín $ transfería una elección al receptor en determinados campos. La descripción demostraba que el receptor podía escoger; no decía qué escogió, si el recurso existía ni si una política lo admitió. La gramática validaba una propuesta. La configuración y el estado en ejecución debían observarse aparte.

Correlacionar sin convertir la clave en identidad

Un controlador podía crear primero el contexto de servicio. Más tarde, la petición ATM llegaba directamente desde la otra pasarela. Para unir ambas secuencias, RFC 3108 definió eecid, end-to-end connection identifier, equivalente al bnc-id de cuatro octetos en los contextos citados.

En establecimiento forward, la pasarela que terminaba la llamada elegía el valor, lo enviaba por SDP al lado de origen y lo recibía después dentro del setup iniciado desde allí. En establecimiento backward, la pasarela de origen de la llamada elegía el valor, lo mandaba al lado terminal y lo recuperaba cuando ese lado iniciaba el bearer.

En ambos casos, el nodo que iba a recibir setup escogía una clave con la que reconocerlo. La unicidad se exigía dentro de ese nodo, no globalmente. El asignador decidía cuándo liberar y reutilizar; el RFC aconsejaba mantener la clave hasta terminar la conexión.

Su función limitada importa. Un eecid coincidente indicaba qué contexto correspondía a la petición. No identificaba a una persona, no autenticaba al peer, no creaba el circuito y no medía el medio. Setup y connect aportaban evidencia del bearer; los paquetes de ida y vuelta y la aplicación aportaban evidencia del resultado.

El propio documento dejó la codificación en el mensaje de bearer a los protocolos de señalización correspondientes. Indicó mecanismos posibles, pero no convirtió SDP en autoridad sobre cada elemento ATM. Dos registros podían compartir la misma clave y conservar ámbitos distintos.

Una cadena de descripciones no era una cadena de ejecución

Las secuencias de ejemplo separaban controladores, pasarelas y red ATM. Primero se intercambiaba información de servicio. Después una pasarela enviaba el setup con eecid; la receptora encontraba el contexto y respondía connect. Solo entonces el medio podía circular.

Cada hito tenía alcance propio. SDP registraba intención descriptiva. Un acuse de control confirmaba una orden recibida. Setup registraba intento. Connect registraba una conexión lógica. Ninguno demostraba por sí solo tráfico bidireccional, latencia real o calidad para el usuario.

El atributo chain permitía enlazar descripciones SDP consecutivas cuando representaban capas distintas de una misma conexión, por ejemplo IP y ATM, y distinguirlas de alternativas. Así cada capa conservaba un documento limpio. El enlace afirmaba relación, no materialización: que dos descripciones estuvieran encadenadas no probaba que ambas capas funcionaran.

Tampoco conviene leer 2001 con reglas posteriores. RFC 3264 formalizó offer/answer en 2002. RFC 4566 y RFC 8866 revisaron SDP después. Son continuidad normativa, no estadísticas de despliegue de RFC 3108 ni prueba de un único flujo histórico.

La seguridad estaba fuera de la descripción

RFC 3108 reconoció que el cifrado de bearers ATM/AAL2 no tenía una convención comparable a la de payloads RTP y que tampoco estaba convencionalizada la autenticación de su señalización. La línea k= podía representar una clave o cómo obtenerla, pero describir protección no significaba haberla aplicado.

SDP podía originarse en equipos de abonado situados en entornos no confiables. La seguridad dependía del protocolo envolvente o de capas inferiores. SIP, MGCP y Megaco podían usar autenticación IPsec y, opcionalmente, cifrado. El verbo «podían» obliga a comprobar cada asociación; no autoriza a inferirla.

Una investigación completa necesita conservar por separado el SDP original, emisor y nodo de referencia; roles de llamada y bearer; valores antes y después de traducción; asignador, ámbito y vida de eecid; mensajes setup/connect/release; protección del envolvente; QoS instalada; contadores; paquetes de ambos sentidos y resultado de aplicación.

La lección sobrevivió a ATM

Lo duradero no es una sintaxis de transporte, sino el riesgo de las palabras portátiles. Los sistemas distribuidos reutilizan «local», «activo», «primario», «dueño» o «forward». El término conserva su forma mientras cambia su coordenada. Una firma puede asegurar que nadie alteró el valor y aun así dejarlo semánticamente invertido.

La pasarela no podía declarar vencedor a uno de los documentos: ambos eran autoridad en su capa. Debía traducir y guardar la procedencia, usar la clave solo para unir registros y esperar observación de código y tráfico para saber qué ocurrió.

Las dos capas dijeron forward. No discutían sobre la fibra; empezaban a medir desde lados distintos. La historia de RFC 3108 consiste en no perder esa diferencia entre descripción, correlación, conexión y servicio real.

Fuentes

  1. https://www.rfc-editor.org/rfc/rfc3108.html
  2. https://www.rfc-editor.org/info/rfc3108
  3. https://datatracker.ietf.org/doc/rfc3108/
  4. https://www.rfc-editor.org/rfc/rfc2327.html
  5. https://www.rfc-editor.org/info/rfc2327
  6. https://datatracker.ietf.org/doc/rfc2327/
  7. https://www.rfc-editor.org/rfc/rfc2543.html
  8. https://www.rfc-editor.org/info/rfc2543
  9. https://www.rfc-editor.org/rfc/rfc2705.html
  10. https://www.rfc-editor.org/rfc/rfc2805.html
  11. https://www.rfc-editor.org/rfc/rfc3015.html
  12. https://www.rfc-editor.org/rfc/rfc3264.html
  13. https://www.rfc-editor.org/rfc/rfc4566.html
  14. https://www.rfc-editor.org/rfc/rfc8866.html