Resumen

  • Un par TALI 2.0 debía tratar el otro extremo como versión 1.0 hasta recibir un moni que identificara la versión 2.0; los nuevos opcodes dependían de esa señal.
  • RFC 3094 era una propuesta Informational de Tekelec. La nota del IESG decía expresamente que competía con trabajo SIGTRAN en curso y que el IETF no había revisado su solidez técnica ni su integridad.

La frontera aparece antes de intercambiar cualquier mensaje SS7. RFC 3094 describe TALI, la Transport Adapter Layer Interface propuesta por Tekelec para transportar señalización entre una red de conmutación de circuitos y una red IP. Una Signaling Gateway podía llevar por TCP/IP mensajes SCCP, ISUP y relacionados con MTP, además de funciones de gestión y registro dinámico de circuitos. El documento define formatos, temporizadores, estados de pares y comportamientos separados para TALI 1.0 y 2.0. Esa precisión no convierte la propuesta en estándar ni demuestra que se desplegara.

La nota del IESG la sitúa junto al trabajo normativo que desarrollaba entonces el grupo SIGTRAN del IETF. Indica que el IETF no había evaluado la solidez técnica ni la integridad de TALI y recomienda que los posibles usuarios examinen SIGTRAN antes de decidir. No afirma que el IETF considerara defectuosa la tecnología, que la rechazara ni que jamás se implementara. Delimita la revisión realizada y señala qué alternativa conviene comparar.

El mecanismo más revelador de TALI resuelve la compatibilidad hacia atrás. La versión 1.0 no ofrecía una forma sencilla de identificar la versión remota. La 2.0 reutiliza el mensaje de monitorización moni: reserva 12 octetos para una etiqueta fija de versión y deja el resto de los datos para usos propios de cada implementación. El campo de datos debe seguir sin superar 200 octetos. moni conserva, además, su función de eco para medir el tiempo de ida y vuelta u otros fines locales.

Al abrir una conexión, TALI 2.0 inicializa far_end_version como 1.0. Puede anunciar su propia versión, pero no debe suponer que el par tiene las mismas capacidades. Debe examinar un moni recibido y reconocer la etiqueta. Si no llega un mensaje identificador o la cadena no coincide con una versión conocida, el otro extremo sigue siendo v1.

Ese estado controla tres opcodes nuevos: mgmt, xsrv y spcl. Un receptor v1 los consideraría inválidos y cerraría inmediatamente el socket. Por eso, un nodo v2 solo puede enviarlos tras identificar al otro lado como v2 o posterior. Si el par es v1, debe volver a las funciones v1. El texto también prevé que un receptor v1 ignore los datos añadidos a moni y continúe con su intercambio ordinario de monitor y acuse. La compatibilidad no garantiza que ambos lados entiendan todas las funciones; evita que el emisor envíe una operación que el receptor antiguo rechazaría.

No es una consigna abstracta sobre versiones, sino un límite operativo concreto. La implementación local anuncia; el par aporta una señal observable; la máquina de estados guarda esa observación; y el control del opcode decide qué puede cruzar el socket. Ni el número de versión impreso en la RFC ni una opción local reemplazan la declaración recibida del extremo remoto.

La historia normativa circundante exige la misma cautela. RFC 2719 ya había descrito la arquitectura SIGTRAN. Documentos posteriores de la vía de estándares definieron adaptaciones como M2UA, M3UA y SUA, y SCTP pasó a ser un transporte usado en ese trabajo. RFC 3094 también contempla una pila alternativa con SCTP. Todo ello acredita actividad de especificación relacionada, no que TALI fuera sustituido, que una red concreta migrara o que dos implementaciones interoperaran.

RFC 3094, fechado en abril de 2001, está clasificado como Informational y declara que no define un estándar de Internet. Publicación, reglas especificadas y límite de revisión son hechos distintos. Ni una máquina de estados extensa ni una advertencia institucional resuelven por sí solas la calidad o el despliegue. Para esas conclusiones hacen falta implementaciones, pruebas, registros operativos o tráfico observado.

Fuentes