Résumé

  • Dans M3UA, la Routing Key sélectionne une plage de trafic, le Routing Context identifie cette clé et Network Appearance distingue un contexte de réseau SS7 local. Ces noms sont liés, mais non interchangeables.
  • Un ASP pouvait servir plusieurs Application Servers sur une même association SCTP, tandis que son état était tenu par AS. L’association active ne disait donc pas, à elle seule, quel ensemble de trafic était autorisé, si une destination SS7 était joignable ni si ISUP ou SCCP avait traité le message.

Trois noms pour trois questions

La nomenclature de M3UA ressemble d’abord à un problème de vocabulaire. Elle devient une question de routage lorsqu’un point code est réutilisé. Deux réseaux SS7 différents peuvent attribuer le même code à des nœuds distincts. Si une passerelle transporte les deux réseaux sur une association commune, le nombre seul ne désigne plus une destination unique. M3UA sépare donc le contexte du réseau, la règle de sélection du trafic et la valeur qui référence cette règle.

RFC 3332, publié en septembre 2002, définit une adaptation destinée au transport sur IP de signalisations MTP3-User comme ISUP ou SCCP. À l’ASP distant, M3UA expose les primitives attendues par ces utilisateurs de MTP3. Il ne devient pas lui-même la couche MTP3 de SS7. Une Signalling Gateway reçoit la signalisation du réseau, puis l’application distante traite la couche utilisateur au travers de l’adaptation. Le plan de contrôle doit indiquer à la fois quels messages vont où et dans quel contexte SS7 interpréter leurs champs.

Un Application Server est une entité logique qui dessert une Routing Key précise. La clé est la règle de sélection : un ensemble de paramètres SS7 qui définit la plage de trafic à traiter. Elle peut s’appuyer sur DPC, OPC ou SIO ; une application peut y ajouter des champs propres à la couche utilisateur, comme un circuit ISUP ou un sous-système SCCP. Ce ne sont que des exemples, pas une recette générale. Les champs pertinents dépendent du service et du réseau, et les plages peuvent être discontinues.

Le Routing Context n’est pas une version raccourcie de ces critères. C’est une valeur qui identifie la Routing Key. La fonction de distribution au SGP confronte les messages aux critères de la clé ; les messages de gestion utilisent le contexte associé pour désigner l’ensemble de trafic à activer, arrêter ou enregistrer. La clé est la règle, le contexte son identifiant, et l’Application Server le service dont cette règle sélectionne le trafic. Confondre le handle avec la règle fait perdre les critères de correspondance ; confondre la règle avec le service fait perdre le résultat de sa sélection.

Network Appearance était local, pas universel

Network Appearance répond à une autre question : dans quel réseau SS7 faut-il interpréter ce message ? Associé au point code, il identifie le nœud dans son contexte de réseau. C’est important lorsqu’une passerelle participe à plusieurs réseaux SS7 nationaux ou privés qui réutilisent un code de point. Sans la dimension réseau, une adresse apparemment précise peut encore désigner deux nœuds différents.

Mais Network Appearance n’est pas un numéro de réseau global. RFC 3332 en fait une référence locale coordonnée entre le Signalling Gateway Process et l’ASP. RFC 4666, révision publiée en 2006 qui remplace RFC 3332, explicite la conséquence : un même réseau SS7 peut recevoir des valeurs Network Appearance différentes selon le SGP. Comparer l’entier entre passerelles ne suffit donc pas ; il faut conserver la table de correspondance qui explique ce qu’il désigne dans chaque paire.

Le champ est facultatif dans certaines topologies bornées. Un gateway qui ne sert qu’un réseau SS7 peut s’en passer ; une association réservée à un seul contexte réseau aussi. Il peut être présent lorsqu’il faut distinguer plusieurs contextes sur une association partagée. L’absence du champ décrit alors la topologie provisionnée ; elle ne prouve pas que les réseaux auraient été fusionnés. Certains cas où une seule Routing Key est configurée permettent aussi d’omettre le Routing Context, puisque la configuration rend le choix non ambigu. Le protocole autorise une omission ; seul le dossier de configuration explique pourquoi elle est sûre.

Une association pouvait recouvrir plusieurs états d’application

La différence est aussi cruciale pendant un basculement. Un ASP est une instance de processus, pas le service lui-même. Il peut être configuré pour plusieurs Application Servers, et une association SCTP unique peut transporter le trafic de plusieurs AS. C’est pourquoi RFC 3332 maintient l’état de l’ASP pour chaque AS. ACTIVE n’est pas une propriété globale d’une socket ou d’une machine : c’est l’état du processus dans un service déterminé.

Les modes de trafic donnent un effet opérationnel à cette portée. Override peut sélectionner un ASP actif et laisser les autres en réserve ; Loadshare répartit le trafic entre plusieurs processus ; Broadcast l’envoie à chaque ASP admissible. L’algorithme convenable dépend de l’application. Le SGP doit donc conserver le lien entre clé, Routing Context, appartenance au service et état du processus au moment de choisir le destinataire. « ASP actif », sans AS ni contexte, est une affirmation incomplète. « Association SCTP établie » l’est encore davantage.

M3UA transporte aussi des indications de gestion réseau : une destination peut être inaccessible, de nouveau joignable, restreinte ou congestionnée. Une association démontre que les extrémités de transport peuvent communiquer. Elle ne prouve ni que le couple point code/Network Appearance a été interprété comme prévu, ni que le message a correspondu à une Routing Key autorisée, ni qu’un ASP était actif pour cet AS, ni qu’ISUP ou SCCP a terminé l’opération. Chaque assertion a besoin du reçu correspondant à sa couche.

Lire RFC 3332 avec son successeur

Le sujet historique est RFC 3332, et non l’affirmation que son texte serait encore l’édition courante. RFC 4666 l’a rendu obsolète en septembre 2006. La version révisée conserve les distinctions essentielles : Routing Key pour la sélection du trafic, Routing Context pour identifier cette clé, Network Appearance pour le contexte SS7 et avec portée locale. Le successeur permet de ne pas présenter un RFC obsolète comme norme actuelle tout en retraçant la persistance de ses frontières de conception.

Le registre SCTP de l’IANA attribue aujourd’hui l’identifiant de protocole de charge utile 3 à M3UA et cite RFC 4666. Le registre des services indique m3ua sur le port SCTP 2905. Ces entrées disent à l’ingénieur quels code point et port sont attribués. Elles ne démontrent pas qu’un opérateur utilise M3UA, qu’une mise en œuvre est conforme ou qu’une association donnée transportait un appel. RFC 9260 est aujourd’hui la spécification SCTP ; cela ne prouve pas que les installations M3UA l’aient adoptée.

RFC 3331, M2UA, est voisin mais distinct : il transporte la frontière utilisateur de MTP2 alors que le lien physique reste dans la passerelle. M3UA transporte les signalisations utilisateur de MTP3, potentiellement ISUP ou SCCP. IUA dans RFC 4233 et M2PA dans RFC 4165 ont encore leurs propres frontières d’adaptation. Une famille SIGTRAN ou un transport SCTP commun ne rend pas leurs noms ni leurs états équivalents.

Pour lire une affirmation M3UA, posons quatre questions séparées : quels paramètres SS7 sélectionnent le trafic ; quel Routing Context identifie cette sélection ; quel Network Appearance local donne un sens au point code pour cette paire SGP/ASP ; et quel état d’ASP, dans quel AS, autorise l’envoi ? Ce n’est qu’ensuite que l’association SCTP doit être jointe comme chemin de transport. La leçon durable de RFC 3332 est que la référence d’une règle, la règle, le contexte réseau et le lien qui transporte le message ne sont pas un seul objet.

Sources