Résumé

  • RFC 5133 est un Proposed Standard de décembre 2007 qui met à jour RFC 4233.
  • RFC 4129 avait attribué le type de gestion 5 à la demande d’état DLC de DUA.
  • RFC 4233 a ensuite attribué le même type 5 à la requête TEI d’IUA.
  • À classe et type identiques, l’en-tête ne permettait pas de distinguer les deux opérations.
  • RFC 5133 impose le type 8 à la requête TEI.
  • Le registre IANA actuel conserve le type 5 pour DLC Status Request et le type 8 pour TEI Query Request.
  • Le registre fixe le sens normatif ; il n’inventorie pas les versions effectivement installées.
  • Une association SCTP établie ne prouve ni la capacité RFC 5133 ni l’état actif de l’application IUA.
  • DUA peut utiliser son PPID 10, mais RFC 4129 autorise aussi le PPID IUA 1 dans certains déploiements mixtes.
  • SCTP n’interprète pas lui-même le PPID ; ce champ n’est donc ni une authentification ni une barrière sémantique.
  • ASSIGNED signifie que Q.921 considère le TEI attribué, non qu’un abonné ou un équipement est authentifié.
  • Une migration vérifiable sépare registre, build, configuration, transport, octets, décodeur, réponse, état de liaison et résultat.

Deux calendriers

Le registre a une date. Le parc en a des centaines. RFC 5133 peut définir sans ambiguïté ce qu’un émetteur conforme doit faire, tandis qu’un contrôleur ancien, une passerelle oubliée ou un analyseur embarqué continue à appliquer RFC 4233 tel qu’il l’avait compris avant la correction.

L’histoire technique commence avec RFC 3057, qui ne définissait pas de requête TEI. RFC 4129 a étendu IUA aux environnements DPNSS et DASS 2. Il a créé trois messages de gestion pour l’état des Data Link Connections : demande 5, confirmation 6, indication 7. RFC 4233 a ensuite ajouté la requête TEI et lui a donné, elle aussi, le type 5 dans la classe de gestion 0.

Il ne s’agissait pas de deux libellés voisins dans une documentation. Les mêmes coordonnées de l’en-tête commun désignaient deux actes différents. La réception de classe 0/type 5 ne suffisait plus à savoir si l’émetteur demandait l’état des DLC DUA ou la liste des TEI IUA. Toute « résolution » par le rôle présumé de la machine ajoutait une convention locale absente des octets.

RFC 5133 apporte la correction minimale : la requête TEI doit être codée avec le type 8. IANA réserve ce numéro. Cette décision rend à nouveau possible un décodeur déterministe. Elle ne distribue pas un nouveau logiciel et ne force pas les pairs à annoncer leur niveau de prise en charge.

Le registre ne téléadministre pas les binaires

La ligne IANA est une autorité sur l’espace de nombres. Elle répond à « quel sens le standard attribue-t-il à cette paire classe/type ? ». Elle ne répond pas à « que fait ce châssis cette nuit ? ». Confondre ces questions transforme une référence normative en inventaire fictif.

Une déclaration fournisseur apporte un indice sur une version. Une nomenclature logicielle relie éventuellement cette version à un nœud. Un test de build montre comment un artefact réagit. Une capture prouve quels octets ont franchi un point d’observation. Une trace du récepteur prouve quel chemin de code les a consommés. Une indication TEI prouve ce que la gestion Q.921 a déclaré dans ce contexte. Aucun de ces reçus ne remplace le précédent ou le suivant.

La tentation inverse serait de conclure que le registre est purement symbolique. Ce serait faux. Sans un type unique, même une capture parfaite ne porte pas assez d’information pour choisir entre les deux opérations. Le registre crée la condition de la preuve. Le déploiement fournit la preuve concrète.

Le PPID ne sauve pas un type ambigu

RFC 4129 recommande le Payload Protocol Identifier 10 pour DUA et le PPID 1 pour IUA. Cette séparation est utile. Elle peut aider le destinataire ou l’outil d’analyse à choisir le bon protocole supérieur.

Mais le texte permet également d’utiliser la valeur IUA pour DUA, notamment lorsque ISDN et DPNSS sont transportés sur la même association SCTP. Il précise que SCTP n’emploie pas directement le PPID ; certaines entités réseau peuvent s’en servir pour identifier le contenu d’un DATA chunk.

Une indication extérieure facultative ne peut donc pas réparer durablement une collision intérieure. Une configuration peut réutiliser le PPID 1 par conception. Un outil peut ne pas le conserver. Un récepteur peut déléguer trop tôt le décodage. Et le transport ne vérifie pas que la branche applicative choisie correspond au sens voulu.

La paire PPID 1 et type 8 constitue une observation forte d’une requête TEI IUA moderne. Elle ne prouve pourtant pas l’identité commerciale du pair, son autorisation, sa version complète, ni la réponse future. Le PPID décrit un contenu attendu ; il ne signe pas son auteur.

Une association saine peut transporter un désaccord

RFC 4233 distingue l’association SCTP, l’état de l’Application Server Process et l’activation du trafic. Un pair peut être joignable au niveau transport et rester ASP-INACTIVE. Le mappage entre identifiant d’interface et association ou flux est dynamique et peut devenir temporairement invalide pendant un basculement.

Le voyant « SCTP up » ne doit donc pas englober le contrat applicatif. Il confirme une association observée. Il ne confirme pas que type 8 est compris, que le bon serveur d’application est actif ou que l’interface visée est correctement mappée.

Lors d’une migration, il faut conserver l’identité de l’association, le flux, le PPID, la version d’en-tête, la classe, le type, la longueur, les octets du message et la décision du parseur. Les erreurs Unsupported Message Type, Unexpected Message et Protocol Error ont des significations distinctes. Le silence en a encore une autre : il peut être abandon, perte, absence d’observation ou panne en aval.

Une réponse positive exige plus qu’une absence d’erreur. Les indications TEI attendues doivent être reçues dans une fenêtre définie, reliées à l’interface correcte et évaluées pour leur complétude.

ASSIGNED n’est pas une identité

La requête TEI part de l’ASP vers la Signaling Gateway. Elle contient l’en-tête commun et l’en-tête IUA. RFC 4233 exige que la SG ignore le DLCI présent dans cet en-tête pour cette opération. Ce détail protège contre une inférence séduisante : un champ présent dans une structure n’est pas nécessairement pertinent pour chaque message qui la réutilise.

La réponse emploie ASSIGNED ou UNASSIGNED. Le premier signifie que le TEI est considéré comme attribué par Q.921. Le mot « considéré » et la mention de la couche fixent la frontière. L’état ne nomme pas un utilisateur, ne vérifie pas un numéro de série et ne garantit pas qu’un lien de données est établi maintenant.

L’information reste opérationnellement utile. Un ASP peut préparer le traitement de signalisation, décider de demander un établissement de liaison ou examiner un lien apparu pour un TEI inattendu. Mais ces actes sont ultérieurs. Pour déclarer un service, il faut encore observer la procédure d’établissement, l’état Q.921, la signalisation transportée et le résultat applicatif.

Le retour vers 5 n’est pas un simple retry

Un émetteur récent peut rencontrer un récepteur ancien qui rejette le type 8. Rejouer en type 5 paraît être une mesure de compatibilité. C’est pourtant un changement de sens potentiel. Dans un contexte DUA, type 5 signifie DLC Status Request. Si DUA partage le PPID IUA, le contexte extérieur ne fournit même plus une séparation certaine.

Une compatibilité héritée doit donc être nominative et temporaire : pair identifié, contexte IUA-only démontré, télémétrie par recours, tests négatifs, date de fin et interdiction sur les associations mixtes. Sans cela, le shim rend les tableaux verts et supprime l’incitation du dernier fournisseur à corriger son logiciel.

La migration doit tester les asymétries : nouveau vers nouveau, nouveau vers ancien, ancien vers nouveau, IUA seul, DUA seul, association combinée et basculement. Un bon test ne vérifie pas seulement la réussite attendue. Il vérifie que la combinaison ambiguë échoue ouvertement et n’atteint jamais le mauvais gestionnaire.

Limites des preuves disponibles

Les archives RFC établissent la chronologie, le statut et la modification normative. RFC 4129 établit les types DLC et les règles de PPID. RFC 4233 établit les en-têtes, états, erreurs et procédures TEI. IANA établit l’allocation actuelle. Les documents SCTP établissent le transport sous-jacent.

Ces sources ne décrivent pas la version d’un équipement nommé, un paquet d’incident, l’identité d’un terminal, la totalité d’une réponse ou le résultat d’un service. Dire cette absence n’affaiblit pas l’analyse. Cela transforme chaque inconnue en prochaine demande de preuve.

Sources