Résumé

  • RFC 3038 distingue le label ATM local du VCID partagé dont deux ATM-LSR ont besoin pour associer le même circuit virtuel dans LDP.
  • En mode intrabande point à point, PROPOSE ne suffisait pas : un ACK apparié puis une requête LDP formaient la poignée de main à trois messages avant le mapping.

Le circuit avançait ; son label local changeait

Le projet MPLS de janvier 2001 voulait utiliser des commutateurs ATM comme routeurs de commutation par labels. Le matériel savait déjà transmettre des cellules à partir des champs VPI et VCI. Le problème était moins visible dans une ligne de configuration que dans le réseau lui-même : en règle générale, un commutateur ATM pouvait remplacer ces valeurs en faisant passer le circuit vers le prochain lien. Le chiffre vu par un voisin ne constituait donc pas nécessairement l’identité du circuit virtuel que LDP devait désigner dans un message de correspondance.

RFC 3038 ajoute un identifiant de connexion virtuelle, le VCID. Aux deux extrémités du VC concerné, la valeur devait être la même. Cela ne transforme pas le label de commutation local en identifiant universel et ne remplace pas VPI/VCI pour transmettre les cellules. Le VCID permet aux ATM-LSR adjacents de relier leur propre label entrant ou sortant à une relation commune, puis d’employer cette identité dans l’échange LDP.

La chronologie est essentielle : le texte part d’un VC déjà établi par signalisation ou par gestion. La notification ne crée pas le circuit ATM ; elle coordonne la façon dont les deux voisins le reconnaissent. Ensuite seulement viennent la requête et le mapping LDP. Installation du VC, attribution d’un label local, association au VCID, mapping distribué et circulation effective de paquets sont des étapes distinctes. Aucune ne prouve à elle seule la réception par une application.

Pourquoi l’accusé de réception ne concluait pas l’échange

Dans la procédure intrabande point à point, le nœud amont choisissait un VCID et envoyait VCID PROPOSE, accompagné d’un identifiant de message, sur le circuit nouvellement établi. Les deux côtés associaient le VCID aux labels locaux correspondants. Le nœud aval renvoyait ensuite un ACK contenant la valeur VCID et l’identifiant reçus. L’amont devait vérifier qu’ils correspondaient ; faute d’ACK attendu pendant le délai prévu, il renvoyait PROPOSE.

Puis l’amont envoyait une requête LDP portant l’identifiant de message. L’aval interprétait cette requête comme la preuve que l’amont avait bien reçu son ACK. Le protocole forme ainsi trois messages : PROPOSE, ACK, REQUEST. RFC 3038 justifie ce dernier tour parce que PROPOSE est transmis de façon non fiable. L’aval peut avoir envoyé un ACK sans savoir si son correspondant l’a vu. Jusqu’à l’arrivée de REQUEST, il devait écarter sur le VC tout paquet autre que PROPOSE.

Une fois l’échange terminé, LDP Mapping pouvait transporter le VCID dans son Label TLV. C’est une preuve de coordination du plan de contrôle entre voisins, non une observation de trafic utilisateur, une vérification de chaque commutateur sur un chemin plus long ou un reçu de livraison de service.

Des topologies différentes, des procédures différentes

Le texte n’impose pas la même notification partout. Une liaison transparente directe, dont VPI/VCI est déjà identique aux deux extrémités, n’en a pas besoin. Un VP peut utiliser la notification intrabande ou VPID ; dans le cas restreint où il n’existe qu’un seul VP vers le voisin, le VCI partagé peut suffire. Le PVC utilise l’intrabande. Pour un SVC, un champ assez grand dans le message de signalisation peut porter le VCID ; sinon RFC 3038 décrit un champ provisoire plus petit ou un échange intrabande.

La direction compte également. L’extrémité amont amorce la notification ; une VC bidirectionnelle requiert deux procédures, une dans chaque sens, tandis qu’une VC unidirectionnelle n’en requiert qu’une pour le sens autorisé. Il n’existe pas ici de nom global qui rendrait identiques toutes les associations locales du réseau ATM.

Le cas du petit champ illustre la garde temporaire d’un identifiant. La zone utilisateur du BLLI pouvait repérer provisoirement un circuit pendant la notification. Sa valeur ne devait pas être réutilisée pour une autre transaction inachevée avec le même voisin ; elle redevient disponible après établissement de l’association durable. En multipoint, BLLI est unique chez l’émetteur, pas chez le récepteur : celui-ci doit aussi reconnaître l’adresse ATM source. L’expiration du jeton provisoire dépend donc d’un événement observable, pas d’une supposition.

RFC 3038 définit aussi VPID pour identifier un chemin virtuel ; le VCID d’un VC peut ensuite combiner le VPID et le VCI, évitant une notification distincte pour chaque circuit. Ses séquences multipoint sont présentées comme un usage futur et le document précise que LDP ne prenait pas alors en charge la multidiffusion. Pour un commutateur sans VC-merge, l’ajout d’une feuille pouvait nécessiter une division temporaire du LSP afin d’envoyer une notification intrabande, avec des effets possibles sur les performances et la QoS. Ce sont des contraintes décrites par la norme, pas des mesures de terrain.

RFC 3033, publié le même mois, attribuait des identifiants typés aux messages de signalisation ATM pour les sessions et les ressources. Il s’agit d’un autre objet que le VCID de RFC 3038, qui relie les labels locaux de deux voisins LDP une fois le VC établi. RFC 3036 traite encore d’une autre couche : les éléments FEC. La précision historique tient justement à cette séparation.

La fiche RFC Editor classe aujourd’hui RFC 3038 comme Proposed Standard et indique que RFC 7274 la met à jour. Cette dernière porte sur l’allocation et le retrait des labels MPLS à usage spécial et sur l’ancienne terminologie « reserved label » ; elle n’efface pas la procédure VCID décrite ici. Aucun de ces textes ne nomme une implémentation déployée, ne donne de taux d’adoption ou ne publie d’essai d’interopérabilité. Le résultat documenté est plus étroit : quand le label ATM n’était local qu’à un saut, LDP devait établir une identité commune entre ses voisins et vérifier l’échange qui la créait.

Sources

Les essais de Heng Lu servent de cadres analytiques explicitement attribués ; Lu n’a ni écrit ni approuvé RFC 3038.