Résumé

  • Le projet MPLS STAMP prévoit un état de session configuré localement aux deux extrémités et laisse hors de son périmètre la signalisation VCCV propre à STAMP.
  • Le retour d’un paquet établit un échange limité ; il ne consigne ni l’identité des deux configurations ni leur accord sur le service, le mode, l’horloge et l’usage de la mesure.

La phrase décisive du projet draft-ietf-mpls-stamp-pw-21 ne décrit ni un champ ni une valeur IANA. Elle précise que le mécanisme chargé de terminer le paquet de test est configuré localement aux deux bouts du LSP ou du pseudowire. Elle ajoute que les extensions de signalisation VCCV pour STAMP sur pseudowire restent hors sujet. Pour un LSP, en l’absence d’une telle signalisation, la configuration locale est aujourd’hui la seule option présentée comme viable.

Cette architecture est raisonnable. Un protocole de mesure n’a pas vocation à transporter le nom d’un client, la politique d’un contrat ou la chaîne d’approbation d’un opérateur. Mais la sobriété du paquet ne doit pas devenir une fiction documentaire. Deux équipements peuvent traiter le même échange sans produire, par cet échange, la preuve qu’ils partagent la même définition opérationnelle de la mesure.

Le paquet identifie une session, pas toute son intention

RFC 8762 définit une session STAMP comme un flux bidirectionnel entre un émetteur et un réflecteur pendant une durée donnée. La configuration et l’administration des deux fonctions sont explicitement laissées hors périmètre. Elles peuvent passer par une ligne de commande, un OSS/BSS, SNMP ou un contrôleur NETCONF/YANG. Le réflecteur se comporte ensuite selon cet état : stateless ou stateful, authentifié ou non authentifié.

RFC 8972 ajoute le SSID. Avant le démarrage, le réflecteur doit posséder tous les éléments qui identifient la session ; un paquet non conforme à cette identité doit être rejeté. Là encore, le moyen par lequel ces éléments sont fournis n’est pas normalisé. Le projet MPLS impose un SSID non nul dans les deux sens et l’articule avec le contexte propre au transport.

En Format-1, qui conserve IP et UDP, l’adresse pertinente, le port de destination, le SSID et les paramètres locaux concourent à l’identification. En Format-2, sans en-tête IP/UDP, le SSID est rapproché du contexte LSP ou pseudowire, dans le sens aller ou retour, puis des paramètres locaux. Le paquet apporte donc une clé de rapprochement. Il ne contient pas la totalité de l’enregistrement auquel cette clé renvoie.

Cette différence est structurante. Le même identifiant peut être associé, d’un côté, à une vue de maintenance du transport et, de l’autre, à un service client. Les extrémités peuvent partager le format tout en divergeant sur le mode du réflecteur. Elles peuvent utiliser des sources de temps différentes, des seuils d’alerte différents ou des budgets d’émission différents. Rien n’implique qu’une telle divergence existe dans un déploiement donné. La question est de savoir quelle preuve permettrait de l’écarter.

VCCV négocie une capacité plus étroite

Dire qu’un pseudowire ne signale rien serait faux. RFC 5085 organise l’annonce des capacités VCCV : types de canal de contrôle et types de vérification de connectivité. Les Provider Edges annoncent leurs combinaisons, en choisissent une compatible et la maintiennent jusqu’à une nouvelle signalisation du pseudowire. RFC 7708 complète ce dispositif avec le type 4 fondé sur le GAL et des règles de préférence.

Le projet MPLS STAMP réutilise ces mécanismes pour soustraire le paquet de test au chemin de transfert ordinaire et le remettre au plan de contrôle. Un seul mécanisme d’exception doit être actif pour une session. Le texte distingue également deux fonctions que l’on confond facilement : l’exception retire le paquet du chemin ; l’identification, grâce au type G-ACh, indique ensuite si le contenu suit le Format-1 ou le Format-2.

Ce choix VCCV négocié est une preuve réelle, mais partielle. Il ne suffit pas à établir la totalité des paramètres STAMP : SSID, format retenu, contexte LSP/PW, adresses et ports éventuels, mode d’authentification, état du réflecteur, TLV autorisés, taille, débit, source de temps ou service concerné. C’est précisément pour ces données que le projet parle de paramètres et de mécanismes configurés localement.

Il faut donc résister à deux simplifications opposées. La première serait d’affirmer qu’aucun accord n’existe sur le réseau ; la seconde, de transformer l’accord VCCV en certificat universel de cohérence de la mesure. L’architecture contient plusieurs accords, chacun avec son objet. La gouvernance échoue lorsque leurs périmètres sont fusionnés dans un simple voyant vert.

Ce que démontre réellement une réponse

Une réponse correctement formée avec le SSID attendu est une observation utile. Elle montre qu’un paquet a quitté l’émetteur, traversé un contexte de transfert utilisable, été intercepté et reconnu par le réflecteur, puis renvoyé dans des conditions suffisamment compatibles. Selon le mode et les contrôles appliqués, elle permet de calculer délai, variation ou perte.

Elle ne désigne pas l’auteur des configurations. Elle ne révèle pas leurs versions. Elle ne prouve pas que les deux côtés rattachaient la session au même pseudowire commercial, au même objectif de diagnostic ou au même engagement de service. Elle ne dit pas si les horloges respectaient l’enveloppe d’exactitude prévue, si le débit du test avait reçu l’autorisation attendue, ni si un changement ultérieur avait invalidé l’association.

La restriction désormais explicite à un domaine administratif ne remplace pas cette preuve. Un domaine peut comprendre plusieurs équipes, contrôleurs, fenêtres de changement et fournisseurs. L’unité de l’opérateur borne l’autorité externe ; elle ne crée pas une transaction atomique entre deux magasins de configuration.

La conclusion n’est pas que STAMP devrait porter tous ces attributs. Leur insertion dans le protocole alourdirait une spécification dont l’interopérabilité dépend justement d’un noyau restreint. Le bon emplacement est un document local protégé, relié à l’évidence réseau sans se faire passer pour elle.

Le reçu de configuration bilatérale

Un reçu bilatéral de configuration de mesure peut rester minimal. Son premier volet fixe l’identité des extrémités, le domaine administratif, le LSP ou le pseudowire, le sens, le mécanisme d’exception, le format STAMP, le type G-ACh et le SSID. Pour le Format-1, il ajoute adresses et ports ; pour le Format-2, il fixe les contextes aller et retour utilisés pour l’identification.

Le deuxième volet conserve le sens de la mesure : réflecteur stateful ou stateless, mode authentifié ou non, ensemble de TLV, source de temps et preuve de synchronisation, taille et marge MTU, cadence, capacité réservée au retour, service associé, objectif d’observation et catégorie de décision autorisée. Ces valeurs n’ont pas besoin de traverser le réseau à chaque paquet ; elles doivent seulement partager une identité immuable.

Chaque extrémité fournit une génération de configuration, représentée par un hachage ou une version non réinscriptible. Le reçu mentionne le contrôleur ou l’opérateur à l’origine de chaque état, la personne qui a validé la paire, les vecteurs d’essai et la date d’expiration. Toute modification d’un côté ouvre une nouvelle paire au lieu d’hériter silencieusement de l’ancienne approbation.

Enfin, le reçu sépare les niveaux de preuve. « Capacité VCCV commune » ne signifie pas « paramètres STAMP identiques ». « Réponse reçue » ne signifie pas « horloges conformes ». « Métrique calculée » ne signifie pas « objectif du service atteint ». Une application aval peut alors consommer le niveau effectivement établi, sans emprunter l’autorité d’un niveau supérieur.

Cette trace bilatérale relève ici de l’analyse de Daniel Kade. Elle n’ajoute aucun champ STAMP, aucun registre IANA et aucune obligation à l’IETF.

Le cas le plus trompeur est l’accord partiel

Une incompatibilité totale se voit souvent : le paquet ne correspond à aucune session et le réflecteur le rejette. L’accord partiel est plus délicat. Les identifiants suffisent au retour, tandis qu’un attribut absent du paquet a changé.

Un réflecteur passé de stateful à stateless peut continuer à répondre tout en modifiant l’inférence de perte disponible. Une rotation du mode de protection peut changer le niveau de confiance. Le rattachement à un nouveau chemin peut préserver le SSID tandis que le tableau de bord conserve l’ancien nom de service. Une horloge en holdover peut fournir des valeurs propres mais une incertitude devenue incompatible avec la décision attendue.

Il s’agit de scénarios de contrôle, pas d’incidents constatés. Les sources ne recensent ni panne, ni défaut de fournisseur, ni fréquence de déploiement. Elles suffisent toutefois à établir une limite logique : le succès du paquet n’est pas le hachage de toute la configuration qui lui donne sens.

Sources

  1. Projet MPLS STAMP, historique et fiche API
  2. Révision 21 en HTML, texte, XML et comparaison 20–21
  3. Bulletins IESG, rapport du shepherd et groupe MPLS
  4. RFC 8762 et RFC 8972
  5. RFC 5085, RFC 7708 et RFC 5586
  6. RFC 7799, Minimum Initial Specification et The Policy Mirror