RFC 3108 : quand « avant » pointait dans les deux sens

Résumé

Dans le SDP de RFC 3108, l’avant s’éloigne du nœud ATM décrit ; dans la signalisation du support, l’avant part du nœud qui lance l’établissement. Lors d’un établissement inversé, un même débit change donc de nom entre les couches.
eecid, valeur de quatre octets, reliait un contexte d’appel à la demande de support reçue plus tard. Cette clé locale ne constituait ni une identité, ni un nom mondial, ni la preuve d’un média fonctionnel.

Deux origines pour un même mot

Un ingénieur observe une passerelle et appelle « avant » le trafic qui s’en éloigne. Un autre observe l’établissement d’un circuit et donne le même nom au trajet qui part de l’émetteur de la requête. Tant que ce sont les mêmes équipements qui lancent appel et support, l’ambiguïté reste discrète. Dès que les rôles se séparent, les flèches se croisent.

RFC 3108, publié sur la Standards Track en mai 2001, appliquait la syntaxe SDP de RFC 2327 aux connexions ATM et AAL2. Il ajoutait des attributs pour les adresses, couches d’adaptation, débits, délais, pertes, types de support, canaux et choix de service. SIP, MGCP ou Megaco/H.248 pouvaient transporter ces descriptions dans leurs échanges de contrôle.

Mais le document décrivait surtout une frontière entre autorités. L’appel de service et le circuit qui le transportait ne suivaient pas nécessairement le même initiateur. Dans le cadre SDP de RFC 3108, la direction avant allait toujours du nœud ATM considéré vers l’extérieur ; l’arrière revenait vers ce nœud. La règle ne dépendait ni de l’origine de l’appel, ni de celle du support.

La signalisation ATM/AAL2 choisissait l’autre repère : l’avant allait de l’extrémité qui envoyait la demande d’établissement vers celle qui la recevait. Dans le modèle de support « backward », la passerelle à l’origine du service recevait justement la demande de circuit. Son débit de crête sortant était avant dans SDP, mais arrière dans la signalisation ATM. Copier le champ avec une fidélité parfaite revenait à le placer du mauvais côté.

La passerelle devait traduire. Cette obligation est plus importante historiquement que la liste des attributs, car elle montre qu’un terme ordinaire ne transporte pas avec lui son repère. Pour interpréter une direction, il fallait conserver le nœud décrit, l’origine de l’appel, l’origine de l’établissement et le protocole qui portait la valeur.

Une ligne valide ne prouvait pas une politique valide

Des lignes telles que atmQOSparms et atmTrfcDesc portaient un directionFlag valant f, b ou fb. Le drapeau était obligatoire, même si d’autres paramètres recevaient parce qu’ils étaient non précisés, implicites, sans objet ou connus ailleurs.

Ces lignes pouvaient décrire débit de pointe, débit soutenable, taille de rafale, variation de délai, délai de transit ou perte admissible. Une inversion n’était donc pas cosmétique. Elle pouvait réserver la capacité au mauvais sens ou appliquer une contrainte de qualité au flux opposé. Le parseur voyait une phrase correcte ; l’exploitation recevait un contrat inversé.

Le symbole $ ajoutait une délégation : dans certains champs, le destinataire devait sélectionner une valeur autorisée. Cela ne disait pas encore laquelle avait été installée. De même, n’avait pas une signification universelle. La grammaire établissait une possibilité d’interprétation ; seule la décision du destinataire, puis l’état de la passerelle, établissaient le choix effectif.

Il faut donc distinguer le texte reçu, sa traduction, l’admission locale et le résultat. Un audit qui ne garde que le SDP perd précisément l’endroit où une erreur directionnelle pouvait naître.

La petite clé qui faisait rejoindre deux chemins

Les chemins indépendants posaient une autre question. Un contrôleur pouvait créer un contexte d’appel dans une passerelle. Plus tard, une requête ATM arrivait directement de l’autre passerelle. Quel contexte fallait-il ouvrir ?

RFC 3108 utilisait eecid, end-to-end connection identifier, synonyme du bnc-id de quatre octets dans les environnements cités. Son but était strict : faire correspondre une demande d’établissement de support reçue à un contexte de commande d’appel, dans une relation un-à-un.

Dans l’établissement avant, la passerelle terminant l’appel choisissait la valeur, l’envoyait par SDP vers le côté d’origine, puis la recevait dans la demande de support lancée par ce côté. Dans l’établissement arrière, la passerelle d’origine de l’appel choisissait la valeur, la transmettait au côté terminal, puis la retrouvait dans la demande de support lancée par celui-ci.

Le nœud qui allait terminer la requête choisissait ainsi sa propre clé de recherche. L’unicité n’était requise que dans ce nœud, pas entre toutes les passerelles. L’assignant contrôlait la libération et la réutilisation ; le RFC recommandait de conserver la valeur jusqu’à la fin de la connexion.

Cette portée interdit d’en faire une identité. Une correspondance eecid ne prouvait ni l’abonné, ni l’authentification, ni l’existence d’un circuit. Elle disait seulement : cette requête appartient au contexte déjà reçu. L’échange setup/connect établissait ensuite un état de support. Les paquets et mesures dans les deux sens restaient nécessaires pour conclure au service.

Le RFC ne définissait pas non plus le codage universel de la clé dans la signalisation du support. Il indiquait des éléments d’information possibles, mais laissait chaque protocole de support gouverner son transport. La description et la requête pouvaient partager une valeur sans devenir un seul registre.

Décrire, établir, puis observer

Les scénarios du document séparent nettement les étapes. Les contrôleurs échangent l’information de service et commandent leurs passerelles. Une passerelle envoie ensuite la requête ATM contenant la clé à l’autre. Celle-ci retrouve le contexte et répond par connect. Le média ne peut emprunter le support qu’après cette suite.

Un SDP prouve ce qui a été décrit. Un acquittement de contrôle prouve qu’une instruction a été reçue. Une requête setup prouve une tentative ; connect prouve un état de circuit. Aucun ne prouve à lui seul le trafic bidirectionnel, le délai réel, la perte ou la qualité ressentie.

L’attribut chain préservait une autre séparation. Plusieurs descriptions SDP consécutives pouvaient être des alternatives, ou décrire des couches distinctes d’une même connexion, par exemple IP au-dessus d’ATM. chain signalait que la description suivante ou précédente appartenait à la même construction, sans forcer un objet monolithique. Relier deux descriptions ne signifiait pas que les deux couches fonctionnaient.

Les RFC ultérieurs doivent rester à leur date. RFC 3264 a formalisé offer/answer en 2002 ; RFC 4566 puis RFC 8866 ont révisé SDP. Cette continuité documentaire n’apporte ni recensement d’implémentations de RFC 3108, ni preuve que chaque échange de 2001 suivait le modèle postérieur.

La sécurité venait de l’enveloppe

RFC 3108 constatait que le chiffrement des supports ATM/AAL2 n’était pas conventionnalisé comme celui des charges RTP et que l’authentification de leur signalisation ne l’était pas davantage. La ligne SDP k= pouvait représenter une clé ou un moyen de l’obtenir ; sa présence n’établissait pas que le support était protégé.

Une description pouvait provenir d’un équipement situé chez un abonné et donc d’une zone non fiable. Le document s’en remettait aux protections du protocole encapsulant ou des couches inférieures. SIP, MGCP et Megaco pouvaient utiliser l’authentification IPsec, éventuellement le chiffrement. Cette capacité devait être vérifiée pour chaque échange au lieu d’être présumée.

La preuve complète réunirait séparément description originale, expéditeur, nœud de référence, rôles d’appel et de support, valeur avant et après traduction, allocateur et durée de eecid, requête et connect, association de sécurité, QoS installée, compteurs, paquets aller-retour et résultat applicatif.

L’héritage est une discipline de traduction

ATM peut sembler éloigné, mais le défaut décrit ne l’est pas. Les systèmes distribués réutilisent sans cesse des mots comme local, primaire, actif, propriétaire ou avant. Le mot traverse les interfaces ; son origine, elle, reste souvent cachée. Une valeur peut alors être authentique et correctement copiée tout en devenant fausse dans la couche suivante.

La passerelle de RFC 3108 ne pouvait choisir une autorité unique : chaque convention était légitime dans son domaine. Elle devait traduire, puis corréler les deux registres sans les confondre. Le fonctionnement observé restait une troisième réalité.

Les deux couches disaient « avant ». Leur désaccord portait sur l’endroit où commençait la flèche. Préserver ce repère était la condition pour passer d’une description valide à un support correctement établi, puis à un média réellement mesuré.

Les deux couches disaient « vers l’avant », mais regardaient en sens opposés : RFC 3108

Pourquoi c'est important

Résumé

Deux origines pour un même mot

Une ligne valide ne prouvait pas une politique valide

La petite clé qui faisait rejoindre deux chemins

Décrire, établir, puis observer

La sécurité venait de l’enveloppe

L’héritage est une discipline de traduction

Sources

Contexte approfondi du profil

Strategic Circle

Leadership Alliance

Briefing du Strategic Circle

Briefing Leadership Alliance