Résumé

  • RFC 3332 plaçait la coupure au-dessus de MTP3 : la passerelle terminait MTP2 et MTP3, puis distribuait ISUP, SCCP et les autres usagers de MTP3 selon une clé de routage. Le Routing Context n’était que le nom compact de cette règle.
  • L’enregistrement de la clé, l’état ACTIVE d’un ASP et l’accessibilité d’une destination relevaient de preuves différentes. RFC 4666 a rendu RFC 3332 obsolète en 2006 ; le texte de 2002 éclaire une transition historique, pas l’autorité technique actuelle.

Une frontière déplacée d’un étage

La différence entre M2UA et M3UA tient à un étage d’architecture, mais cet étage change tout. Dans le modèle M2UA de RFC 3331, la ligne physique et MTP2 restent à la passerelle tandis que le MTP3 distant manipule leur interface. L’identifiant d’interface renvoie encore à un lien concret. Dans RFC 3332, la passerelle termine également MTP3. Elle ne remet plus un lien au contrôleur ; elle remet le service destiné aux usagers de MTP3.

La signalisation ISUP ou SCCP pouvait ainsi atteindre un processus applicatif sur IP sans que celui-ci possède une pile MTP3 locale reliée au réseau SS7. La passerelle présentait, vers le réseau traditionnel, un point de signalisation ; vers le domaine IP, elle devait savoir quelle application devait traiter chaque famille de messages. Cette seconde décision n’était pas fournie par la topologie seule.

La clé de routage remplissait ce vide. Elle associait un serveur applicatif logique à un ensemble de valeurs SS7 : octet d’information de service, code de destination, code d’origine, plage de circuits, ou combinaison incluant un sous-système SCCP. Le contexte de routage identifiait ensuite cette clé dans les messages. Ce raccourci rendait l’échange efficace, mais masquait la richesse de la politique qui lui donnait sens.

Une route devenait donc deux choses à la fois. Elle restait un chemin de réseau observé par MTP3, et elle devenait une règle administrative attribuant du trafic à une application. Confondre les deux revenait à prendre le plan de classement pour l’état réel du réseau.

La réponse positive ne disait pas « vous possédez cette route »

Le mécanisme de gestion des clés permettait à un ASP de proposer un enregistrement. La passerelle pouvait l’accepter et renvoyer un Routing Context. La preuve est précise : ce pair, à cet instant, a obtenu l’acceptation de cette proposition. Elle ne prouve ni la légitimité extérieure des codes de point, ni l’absence de chevauchement avec une autre clé, ni la bonne portée de la plage de circuits.

Network Appearance compliquait encore l’identité apparente. Un même code de point pouvait exister dans plusieurs réseaux SS7 ; la valeur d’apparence indiquait dans quel univers local l’interpréter. Elle empêchait une ambiguïté de contexte, mais ne créait pas un identifiant mondial et ne signait pas une propriété.

Pour auditer une décision, il faut donc conserver la clé complète, l’apparence réseau, la requête et la réponse d’enregistrement, le contexte attribué, la version de configuration et l’autorisation humaine ou automatisée. Un paquet portant le contexte 12 ne révèle pas, à lui seul, le territoire de signalisation que 12 devait représenter.

Le cas le plus trompeur est celui d’une clé trop large. Aucun paquet n’est nécessairement perdu. L’association SCTP fonctionne et le processus répond. La règle livre seulement des messages valides au mauvais service. Le succès du transport dissimule alors une faute de gouvernance.

ACTIVE ne voulait pas dire accessible

RFC 3332 entretenait plusieurs vérités parallèles. SCTP décrivait l’association de transport. Les états ASP-DOWN, ASP-INACTIVE et ASP-ACTIVE décrivaient la capacité d’un processus à servir un Application Server. Les modes Override, Loadshare et Broadcast organisaient la répartition entre processus. L’état d’une destination SS7 vivait ailleurs.

Les messages SSNM donnaient cette autre vision. DUNA signalait une destination indisponible, DAVA son retour, SCON une congestion, DUPU l’indisponibilité d’un usager, et DAUD demandait un état courant. Avec plusieurs passerelles, M3UA devait suivre chaque route séparément et dériver l’accessibilité globale présentée à l’usager de MTP3.

Il était donc normal qu’une association soit établie, qu’un ASP soit ACTIVE pour une clé et qu’une destination couverte par cette clé soit DUNA. Le premier état prouvait un chemin IP, le deuxième une éligibilité applicative, le troisième une observation du réseau SS7. Les réunir dans un voyant unique supprimait précisément l’information utile au diagnostic.

DAVA n’était pas davantage une quittance de résultat. Il indiquait que la destination paraissait disponible selon le point d’observation et le moment du rapport. Il ne disait pas qu’un appel ISUP avait abouti, qu’une transaction SCCP avait atteint son application finale, ni que la route resterait disponible. La preuve du résultat devait venir du protocole utilisateur.

La relève pouvait transporter un état ancien

La redondance M3UA permettait à plusieurs ASP de servir un même Application Server et à un ASP d’atteindre plusieurs SGP. Lorsqu’un processus tombait, un autre reprenait le contexte de routage. Mais le contexte stable ne garantissait pas que le remplaçant disposait d’une vision actuelle des destinations.

Une association survivante pouvait conduire à une passerelle dont les routes venaient de changer. Un ASP fraîchement activé pouvait ignorer une DUNA survenue pendant son absence. Une réponse d’audit pouvait devenir périmée avant même que les files d’attente soient relâchées. La reprise devait donc réconcilier l’appartenance à la clé, le mode de trafic, la route par SGP, la congestion et le redémarrage MTP3.

La répartition de charge amplifiait aussi une mauvaise règle. Une clé trop générale n’était plus exécutée par un seul processus mais par plusieurs. Le basculement préservait la disponibilité du logiciel et pouvait simultanément multiplier une attribution erronée. Le système avait repris ; sa connaissance du réseau, elle, n’était pas nécessairement réparée.

Lire une norme avec sa date d’expiration

RFC 3332 date de septembre 2002. RFC 4666, publié en septembre 2006, l’a explicitement rendu obsolète. Le premier texte reste essentiel pour comprendre la formation du modèle, mais une lecture opérationnelle contemporaine doit partir de son successeur. Le statut documentaire est lui-même une provenance.

RFC 2719 fournit le cadre SIGTRAN, RFC 9260 la spécification SCTP actuelle, RFC 3788 les considérations de sécurité, et RFC 4165 un contraste avec le modèle pair à pair M2PA. Les registres IANA conservent classes, paramètres et identifiants. Ils attestent une allocation, jamais un déploiement, un volume de trafic, une propriété de route ou une conformité.

La sécurité obéit à la même séparation. Protéger l’association ne valide pas le contenu administratif d’une clé. Un pair correctement authentifié peut demander une plage qu’il n’est pas autorisé à servir ; une configuration approuvée peut contenir une erreur. Identité, autorisation, sélection et disponibilité doivent garder leurs reçus propres.

Quatre reçus ferment mieux l’enquête

Le reçu de sélection contient la clé complète, l’apparence réseau, le contexte et la provenance de configuration. Le reçu applicatif contient association, état ASP/AS, mode de trafic et membre actif. Le reçu réseau contient la passerelle choisie, les états de route, les messages SSNM, les audits et la congestion. Le reçu de résultat contient enfin la réponse, l’erreur ou l’expiration ISUP/SCCP.

La clé répondait à « qui doit recevoir ce message ? ». Elle ne répondait ni à « la destination est-elle joignable ? » ni à « l’opération a-t-elle réussi ? ». RFC 3332 est historiquement précieux parce qu’il a rendu visibles ces questions différentes. Un tableau de bord qui les fusionne efface cette avancée.

Sources