Résumé

  • RFC 3472 traduisait GMPLS dans les REQUEST, MAPPING et TLV de CR-LDP ; le sens montant pouvait devenir utilisable avant le retour des étiquettes aval.
  • Une REQUEST propagée, une Upstream Label valide ou les premiers paquets dans un sens constituaient donc un reçu partiel, pas la preuve d’un service bidirectionnel achevé.

Un chemin dit bidirectionnel suggère volontiers un objet qui naît d’un seul geste. RFC 3472 décrivait au contraire deux réalités qui pouvaient se former à des instants différents.

Publié en janvier 2003 sur la voie de normalisation, le texte donna aux fonctions générales de RFC 3471 une forme CR-LDP précise. Il définit les TLV de demande, étiquette, bande de longueurs d’onde, suggestion, ensemble admissible, protection, état administratif et interface. RSVP-TE reçut sa propre version dans RFC 3473.

La dissymétrie commençait dans REQUEST. La présence d’une Upstream Label demandait un LSP bidirectionnel. Cette étiquette devait déjà être valide pour l’acheminement au moment de l’envoi. Chaque nœud vérifiait son acceptabilité. Avant de propager REQUEST, un intermédiaire devait allouer son étiquette montante de sortie et établir le chemin de données interne reliant les segments locaux.

Quand la demande atteignait le terminateur, celui-ci pouvait aussitôt envoyer du trafic vers l’initiateur. Ce sens n’attendait pas nécessairement la fin de toute la procédure. Le sens opposé dépendait encore des Generalized Labels transportées en retour par MAPPING. Chaque valeur devait être acceptée et installée saut après saut.

Il existait ainsi un état partiel parfaitement conforme : le trafic remontait, mais le dernier MAPPING aval n’avait pas atteint l’entrée. Dire « la demande bidirectionnelle est arrivée » ne prouvait ni la pose des deux sens, ni la continuité physique, ni la réussite d’un échange applicatif.

La Generalized Label Request ajoutait d’autres contrôles distribués. L’entrée fixait le type d’encodage et le G-PID ; le type de commutation pouvait varier par saut. Chaque nœud évaluait l’interface entrante, ses propres capacités et l’interface sortante ou un tunnel. La politique locale décidait de la création ou de l’emploi d’une Forwarding Adjacency. Une REQUEST transmise ne résumait donc pas une vérification identique partout.

Le G-PID était normalement examiné au point de sortie, sauf cas PSC avec PHP. Le silence d’un transit amont ne valait pas validation anticipée de la charge cliente.

La Suggested Label restait une proposition. Ses erreurs étaient ignorées. Si l’aval renvoyait une autre valeur, l’amont devait se reconfigurer ou signaler un refus. L’entrée ne devait pas émettre de données sur la seule suggestion avant de recevoir l’étiquette correspondante. Préparer un matériel lent n’était pas exercer l’autorité d’allocation.

Les Label Sets distinguaient également admissibilité et disponibilité. Les TLV ajoutaient ou excluaient valeurs et plages ; leur absence signifiait que toutes étaient acceptables, non qu’elles étaient libres. Chaque nœud croisait l’ensemble reçu avec les ressources de son interface aval. Une intersection vide arrêtait la demande.

La comparaison portait sur des longueurs d’onde physiques. Deux liens pouvaient utiliser des nombres logiques différents pour la même réalité. Le nœud devait traduire vers une signification physique cohérente ou supprimer la valeur. Un équipement capable de conversion pouvait même retirer le Label Set avant de transmettre, rendant l’historique final incomplet sur les contraintes antérieures.

Dans une bande miroir, les étiquettes de début et de fin devaient être inversées. L’opération s’appliquait aux deux sens d’un tunnel bidirectionnel. Une plage de même taille ne prouvait pas que les longueurs d’onde conservaient le même ordre.

Explicit Label Control associait un Label ER-Hop à l’adresse ou à l’identifiant d’interface précédent. Ordre, bits de direction et duplication erronés déclenchaient une erreur de route. L’acquisition par la tête de chemin des informations nécessaires restait toutefois hors périmètre.

Avec des canaux de contrôle et de données séparés, les IF_ID nommaient les canaux et revenaient dans MAPPING. La perte de signalisation hors fibre ne devait pas interrompre les connexions optiques existantes. Réciproquement, le rétablissement de la session ne prouvait pas que le croisement optique ancien était correct.

CR-LDP ne possédait pas le mécanisme RSVP de notification rapide. RELEASE et WITHDRAW se propageaient autour du défaut et libéraient les ressources. La suppression invalidait les étiquettes des deux sens : un matériel qui continuait à transporter devenait un état résiduel, non une continuation autorisée.

RFC 3468 enregistra ensuite la décision IETF d’arrêter le développement normalisé de CR-LDP au profit de RSVP-TE. Ce choix institutionnel n’efface pas la mécanique ni ne démontre une disparition instantanée des implémentations.

Dans le cadre de Heng Lu, le code en fonctionnement sépare message et effet. La spécification minimale laisse la politique de tunnel à chaque opérateur. Les couches de réalité maintiennent admission, allocation, connexion interne, mapping, trafic directionnel et résultat applicatif distincts.

Le reçu honnête doit conserver l’ordre complet : REQUEST, validation et allocation à chaque saut, acceptation du terminateur, premier paquet montant, chaque MAPPING aval, trafic observé dans les deux sens, puis invalidation et retrait. « Bidirectionnel » ne devient une propriété du service qu’après accord de ces traces.

Sources