Résumé

  • RFC 3033 attribuait des significations Internet aux champs Generic Identifier de Q.2941 et User-to-user Signaling de Q.2957, afin de distinguer identifiant de session, ressource et données de protocole transportées.
  • Un identifiant correct restait une entrée de coordination : la réussite du nouveau VC, l’interprétation côté appelé, la notification à la couche IP et le déplacement effectif exigeaient chacun leur propre preuve.

Le moment décisif n’est pas celui où le routeur sait enfin de quelle session il s’agit. C’est celui qui vient après. Le message SETUP peut contenir les deux adresses, le protocole et les deux ports. La désignation est sans ambiguïté. Mais rien dans cette seule désignation ne montre que le nouveau circuit virtuel existe, que la couche IP en a été informée ou qu’elle a cessé d’utiliser le circuit par défaut.

RFC 3033, publié en janvier 2001 comme Proposed Standard, portait un titre volontairement étroit : attribution d’un champ d’information et d’un identifiant de protocole dans deux mécanismes de signalisation B-ISDN. Le texte qualifiait cette attribution de cadre indispensable aux sessions longues et sensibles à la qualité sur ATM. Dans la même section, il prévenait qu’elle pouvait ne pas constituer le protocole complet permettant l’interopérabilité. La modestie du périmètre faisait partie du contrat.

Le scénario imposait une chronologie

Pour une session longue, le document part d’un trafic multiplexé sur un VC par défaut entre deux routeurs. Un routeur détecte la durée probable de la session et lance la création d’un nouveau VC. La formulation est conditionnelle : la session ne passe sur ce VC que si son établissement réussit.

Le côté appelé a encore du travail. Son entité de signalisation B-ISDN doit reconnaître que l’appel correspond à une session Internet et en avertir l’entité IP. C’est cette dernière qui déplace la session. L’identifiant rend possible l’accord sur le sujet de l’opération ; il ne détecte pas la session, ne crée pas le VC, ne livre pas la notification et ne modifie pas l’état de transfert.

Une chronologie d’incident doit donc conserver au moins trois jalons : identifiant reçu et compris, VC établi, session IP déplacée. La présence de paquets sur le nouveau chemin ajoute une quatrième observation. Les fusionner dans une colonne « succès » donnerait au premier message une autorité d’exécution qu’il n’a jamais eue.

Generic Identifier et UUS n’étaient pas deux emballages équivalents

Le Generic Identifier de Q.2941 servait à transférer des identifiants entre plans de contrôle. Un réseau ATM pouvait en examiner le contenu, et un élément pouvait contenir plusieurs identifiants typés. Le User-to-user Signaling de Q.2957 transportait des données utilisateur au moyen des plans de contrôle. Le réseau n’en vérifiait pas le contenu applicatif. Les règles d’exception et d’interfonctionnement différaient aussi. La limite était de 63 octets pour le premier, 133 pour le second.

Dans les deux cas, un transfert dit transparent ne certifiait que le traitement de signalisation prévu pour un élément sans erreur de codage. Il ne prouvait ni accord sémantique, ni identité de l’émetteur, ni autorisation, ni effet sur le plan de données. La transparence était une propriété du tuyau de contrôle, pas un verdict sur l’opération demandée.

Le type donnait un sens limité aux octets

RFC 3033 attribuait les valeurs d’application 0x03, 0x04, 0x05 et 0x06 à IPv4, ST2+, IPv6 et MPLS. Le type 0x01 signifiait Session ; 0x02, Resource. Une plage restait réservée aux attributions IANA et 0xFE aux expériences ou organisations.

Une session IPv4 était décrite par treize octets : adresses source et destination, protocole, ports source et destination. La version IPv6 en occupait trente-sept. Ces formes visaient les réservations explicites ; les associations avec jokers auraient nécessité un autre type. Le VCID MPLS de quatre octets était une ressource. L’étiquette de type empêchait donc de lire une ressource comme une session, mais elle n’indiquait pas si la ressource avait été obtenue.

Le document assumait plusieurs zones non définies. Il n’imposait pas d’ordre lorsque plusieurs identifiants apparaissaient, ne précisait pas le sens de plusieurs identifiants du même type et ne donnait pas de sémantique à un élément vide. Un CONNECT ou ADD PARTY ACK devait retourner au moins un Generic Identifier après une demande correspondante, mais la partie appelée n’était pas obligée de reprendre la même valeur. Cette règle rendait une négociation possible ; sa procédure détaillée restait hors spécification.

Même la survie du champ n’était pas garantie. Un réseau ATM ne prenant pas en charge Generic Identifier pouvait libérer l’appel, supprimer l’élément ou jeter le message. L’attribution d’un numéro rend une valeur interprétable lorsqu’elle arrive ; elle ne force pas tous les intermédiaires à la conserver.

Le message RSVP transporté n’était pas la réservation

Dans UUS, le discriminateur 0x06 désignait une application Internet, et la valeur 0x02 un message RSVP. RFC 3033 associait Resv à SETUP, ResvConf à CONNECT, et ResvErr ou ResvTear à RELEASE. L’information de réservation pouvait ainsi voyager avec la signalisation d’appel ATM.

Deux procédures étaient envisagées. Dans la première, RSVP passait par un VC existant et l’établissement de la session puis celui du VC se faisaient séquentiellement. Dans la seconde, le message RSVP entrait dans la signalisation B-ISDN, permettant des opérations simultanées. Cette simultanéité pouvait simplifier contrôle d’admission et temporisateurs, mais ne prenait pas en charge au moins le cas d’un PVC. Le texte exigeait donc de considérer les deux modèles.

Recevoir Resv dans SETUP ne signifie pas que l’admission a réussi. Recevoir CONNECT ne prouve pas, à lui seul, que chaque couche a installé le service demandé. Le message transporté, la décision RSVP, l’état du VC, le chemin des paquets et la qualité perçue appartiennent à des couches de réalité différentes.

Une attribution utile pouvait rester incomplète

RFC 3033 laissait ouverts l’agrégation de sessions, les identifiants génériques, le flow label IPv6 et les classes de trafic. Il réservait de l’espace IANA sans prétendre que des valeurs futures existaient déjà. Il indiquait qu’un numéro d’appel vérifié ou fourni par le réseau pourrait contribuer à l’authentification ; l’identifiant de session n’était pas, pour autant, un authentificateur.

La leçon historique est moins spectaculaire que l’ambition ATM de l’époque, mais plus durable. Un espace de noms permet à plusieurs systèmes de parler du même objet. Il ne leur donne pas automatiquement la même politique, la même machine d’état ni le même résultat. Nommer la session était une étape nécessaire. L’exécuter et l’observer restaient des tâches séparées.

Sources

Lu Heng n’a ni rédigé ni approuvé RFC 3033, les recommandations ITU-T ou les RFC contextuelles. Ses essais servent ici de cadres analytiques explicitement déclarés.