Resumen

  • RFC 3332 colocó M3UA por encima de MTP3: la pasarela terminaba MTP2 y MTP3 y entregaba ISUP, SCCP y otros mensajes de usuario a la aplicación elegida por una Routing Key; el Routing Context nombraba esa regla dentro del protocolo.
  • Registrar la clave, activar un ASP y alcanzar un destino SS7 eran hechos independientes. Una respuesta positiva en uno no certificaba los otros. RFC 4666 sustituyó a RFC 3332 en 2006, de modo que el documento de 2002 debe leerse como historia de arquitectura.

El fallo que no rompía ningún cable

En RFC 3331, M2UA mantenía el enlace físico y MTP2 dentro de la pasarela. El MTP3 remoto utilizaba ese enlace mediante primitivas y un identificador de interfaz. RFC 3332 elevó la frontera. La pasarela de señalización terminó también MTP3 y ofreció a aplicaciones IP el servicio que esperaban sus usuarios: ISUP, SCCP y otros protocolos superiores, junto con determinados avisos de gestión de red.

La diferencia explica por qué M3UA no podía ordenar el tráfico solo con el nombre de una línea. Debía decidir qué aplicación lógica atendía qué conjunto de señalización. La Routing Key describía el conjunto con valores SS7: indicador de servicio, código de punto de destino, código de origen, rango de circuitos o subsistema SCCP. Un Application Server servía una clave; uno o más ASP ejecutaban ese servicio.

El Routing Context daba a la clave un valor compacto para intercambiarlo. Era útil, pero no autónomo. Un contexto solo significaba algo dentro de la coordinación entre pasarela y aplicación. Verlo en una captura no revelaba la clave completa ni la política que la había autorizado.

Así nació un fallo peculiar. La red IP podía transportar todo correctamente y la pasarela podía aplicar su tabla sin error, pero la tabla podía asignar el tráfico a la aplicación equivocada. No habría enlace caído que explicase el incidente. El defecto era una regla válida en sintaxis y falsa en alcance.

Una clave era una decisión, no un descubrimiento

RFC 3332 permitía configurar claves o registrarlas mediante mensajes de gestión. Si la pasarela aceptaba una solicitud, devolvía un resultado y un contexto. Ese intercambio probaba aceptación protocolaria, no autoridad sobre los códigos de punto ni titularidad del tráfico. Tampoco garantizaba que no existiera otra regla solapada.

Network Appearance mostraba por qué incluso los identificadores SS7 necesitan contexto. El mismo código podía reutilizarse en redes distintas. La apariencia ayudaba a diferenciar esos espacios, pero seguía siendo una referencia compartida localmente. No convertía el código en una identidad mundial ni autenticaba al solicitante.

Una investigación debe poder reconstruir la decisión original: todos los campos de la clave, la apariencia, la petición, la respuesta, el contexto asignado, la versión de configuración y la aprobación. Sin esa cadena, “el contexto coincidía” es una afirmación circular: coincidía con una tabla cuya corrección precisamente se está investigando.

Las claves amplias generan incentivos peligrosos. Simplifican la configuración y reducen el número de reglas, pero aumentan el radio de una equivocación. Un rango de circuitos demasiado grande puede enviar llamadas de varios dominios a un solo proceso. La eficiencia administrativa se convierte en concentración de autoridad.

El proceso estaba activo; el destino no

M3UA separó el estado del transporte, el de la aplicación y el de la red SS7. SCTP mantenía asociaciones y flujos. El protocolo clasificaba los ASP como DOWN, INACTIVE o ACTIVE, y organizaba servidores y modos de tráfico. Esos estados respondían a quién podía procesar mensajes, no a si cada destino seleccionado por la clave estaba disponible.

Para eso estaban los mensajes de gestión SSNM. DUNA anunciaba indisponibilidad; DAVA, disponibilidad; SCON, congestión; DUPU, indisponibilidad de una parte de usuario; DAUD pedía una comprobación. Cuando había varias pasarelas, M3UA debía conservar el estado de cada ruta y derivar de ellas la vista de destino mostrada a la aplicación.

Un ASP ACTIVE frente a un destino DUNA no era una anomalía lógica. Era una descripción honesta de dos planos. El proceso estaba autorizado y preparado para la clase de tráfico, pero la ruta SS7 no podía llevarla. Sustituir ambos hechos por “servicio verde” engañaba a operadores y automatismos.

Ni siquiera DAVA cerraba la historia. Indicaba disponibilidad según un observador y un instante. No demostraba que la llamada ISUP hubiera sido contestada o que la transacción SCCP llegara a su aplicación final. El resultado debía aparecer en las respuestas del protocolo superior.

El relevo podía heredar la clave y perder el mapa

La redundancia permitía varios ASP por servidor y varias pasarelas por aplicación. En Override un proceso podía tomar el papel principal; en Loadshare varios repartían tráfico; en Broadcast podían recibir copias. Cuando cambiaba el miembro activo, la Routing Key podía permanecer estable mientras el conocimiento de destinos quedaba atrasado.

Una nueva asociación no reconstruía por sí sola los DUNA, DAVA o avisos de congestión perdidos. Un ASP activado después de una interrupción necesitaba reconciliar la visión actual. DAUD servía para preguntar, aunque su respuesta también tenía fecha: un cambio posterior podía invalidarla.

La recuperación correcta tenía que unir cuatro pasos: verificar pertenencia y autorización de la clave, activar el proceso en el modo previsto, reconstruir las rutas por SGP y comprobar el resultado del usuario. Liberar una cola después del segundo paso podía convertir la recuperación en una oleada de mensajes mal encaminados.

El reparto de carga amplificaba además una política errónea. La resiliencia de procesos no corrige una clave amplia; la ejecuta desde más lugares. La disponibilidad del software y la calidad de la decisión no crecen necesariamente juntas.

La etiqueta «obsoleto» forma parte de la evidencia

RFC 3332 se publicó en septiembre de 2002. RFC 4666 lo sustituyó expresamente en septiembre de 2006. Para narrar el origen del modelo, el documento anterior es imprescindible. Para afirmar cómo debe funcionar M3UA hoy, el sucesor es la referencia. La fecha y el estado del RFC delimitan la conclusión.

RFC 2719 aporta la arquitectura SIGTRAN; RFC 9260 contiene el SCTP actual; RFC 3788 estudia seguridad; RFC 4165 ayuda a distinguir M2PA. Los registros IANA conservan clases y parámetros. Ninguno prueba que una organización use el protocolo, que una ruta esté en servicio o que un equipo cumpla la norma.

Autenticar una asociación tampoco autoriza automáticamente una clave. Identidad del par, permiso sobre el rango, corrección de configuración, disponibilidad de ruta y resultado final son controles distintos. La criptografía no corrige una política equivocada.

Cuatro recibos para no confundir selección con realidad

El recibo de selección conserva clave, apariencia, contexto y procedencia. El recibo de aplicación conserva asociación, ASP/AS, modo y miembro activo. El recibo de red conserva SGP, ruta, SSNM, congestión y reinicio. El recibo de resultado conserva respuesta, error o vencimiento de ISUP/SCCP.

La clave contestaba quién debía ver una señal. No garantizaba que el destino existiese detrás de la ruta ni que la operación concluyera. El legado útil de RFC 3332 es esta disciplina: una regla puede funcionar perfectamente y seguir describiendo la realidad equivocada.

Fuentes