Résumé

  • Un pair TALI 2.0 devait considérer l’autre extrémité comme une version 1.0 jusqu’à ce qu’un message moni identifie la version 2.0 ; les nouveaux opcodes dépendaient de cette preuve.
  • La RFC 3094 était une proposition Tekelec à statut Informational ; sa note de l’IESG indiquait explicitement qu’il s’agissait d’une alternative aux travaux SIGTRAN et que l’IETF n’avait pas évalué sa solidité technique ni son exhaustivité.

La frontière se situe avant même l’échange d’un message SS7. La RFC 3094 décrit le Transport Adapter Layer Interface (TALI), proposition de Tekelec pour faire circuler de la signalisation entre un réseau à commutation de circuits et un réseau IP. Une passerelle de signalisation pouvait transporter sur TCP/IP des messages SCCP, ISUP et MTP, ainsi que des fonctions de gestion et d’enregistrement dynamique des circuits. Le texte est détaillé : formats de messages, temporisateurs, états de pair et comportements distincts pour TALI 1.0 et 2.0. Mais une spécification détaillée reste une spécification.

Les premières pages de la RFC l’énoncent clairement.

La note de l’IESG présente TALI comme une alternative commerciale aux technologies sur la voie des standards que le groupe IETF SIGTRAN développait alors. Elle précise que l’IETF n’avait pas examiné la solidité technique ni l’exhaustivité de cette technologie et invite les utilisateurs potentiels à étudier SIGTRAN avant de choisir. Elle ne dit pas que l’IETF a jugé TALI défectueux, l’a rejeté ou a démontré son absence de déploiement. Elle borne l’examen réalisé et recommande une comparaison.

Dans TALI, le problème d’ingénierie le plus net est la compatibilité ascendante. La version 1.0 n’offrait pas de moyen simple d’identifier la version du pair. La version 2.0 réutilise le message moni (monitor) : un champ fixe de 12 octets contient l’étiquette de version, suivie de données libres pour l’implémentation. La taille totale des données moni reste limitée à 200 octets. Le message conserve aussi une fonction d’écho utilisable pour mesurer l’aller-retour ou à d’autres fins locales.

Cette étiquette détermine ce que le pair peut envoyer. À l’ouverture d’une connexion, une implémentation 2.0 initialise far_end_version à 1.0. Elle peut annoncer sa propre version, mais ne peut pas supposer que l’autre côté la prend en charge. Elle doit examiner un message moni entrant et reconnaître la chaîne de version. Si aucun message ne vient ou si l’étiquette est inconnue, le pair reste traité comme version 1.0.

Le drapeau de version conditionne trois nouveaux opcodes 2.0 : mgmt, xsrv et spcl. Une implémentation 1.0 les considérerait invalides et fermerait immédiatement la socket. Le nœud 2.0 doit donc attendre d’avoir identifié l’autre côté comme version 2.0 ou ultérieure avant de les envoyer. Face à un pair 1.0, il revient aux fonctions 1.0. La RFC décrit aussi comment un récepteur 1.0 peut ignorer les données supplémentaires de moni et poursuivre l’échange habituel de requête et d’accusé de réception. La compatibilité ne promet pas que chaque pair comprend toutes les fonctions ; elle fournit une règle pour conserver une connexion utilisable sans envoyer un opcode que le pair rejetterait.

Il s’agit d’une surface de contrôle concrète. L’implémentation locale annonce une version ; le pair distant fournit une indication ; la machine à états enregistre cette observation ; le verrou sur les opcodes décide si une capacité peut traverser la socket. Un numéro de version dans le document ou une configuration locale ne remplace pas la déclaration observée du pair.

L’histoire normative autour de TALI demande la même prudence. La RFC 2719 avait décrit l’architecture SIGTRAN. Des textes ultérieurs de la voie des standards ont spécifié des couches d’adaptation telles que M2UA, M3UA et SUA, tandis que SCTP est devenu un transport employé par ces travaux. La RFC 3094 évoque elle aussi une pile alternative sur SCTP. Ces documents prouvent l’existence de travaux parallèles ou postérieurs, mais pas que TALI a été remplacé, qu’un réseau précis a migré ou que deux implémentations ont interopéré.

Datée d’avril 2001, la RFC 3094 est classée Informational et dit ne pas définir de standard Internet. Publication, mécanismes décrits et limite d’examen sont trois faits différents. Ni la richesse de la machine à états ni l’avertissement de l’IESG ne tranche le déploiement ou la qualité technique. Ces conclusions exigeraient des traces d’implémentation, des tests, des dossiers d’exploitation ou du trafic réel—notamment pas le seul numéro RFC.

Sources