Résumé

  • La RFC 9546 place un en-tête d-ACH juste après le S-Label du service, mais attribue aux paquets OAM actifs un compteur circulaire indépendant de huit bits.
  • PREOF doit utiliser ce compteur pour le traitement OAM ; le texte normatif précise que le flux applicatif et l’OAM utilisent des espaces de numéros de séquence différents.
  • Une série OAM complète renseigne une session définie par le Node ID, le Level, le Session ID et le temps. Elle ne reconstitue ni les paquets de production ni le résultat de l’application.

Tout semblait confirmer le service. Les copies de test avaient traversé les fonctions de réplication, les doublons avaient été éliminés et l’ordre d’arrivée ne présentait aucun trou. Le voyant restait vert. Au même moment, le système de contrôle déclarait ne jamais avoir reçu un message soumis à une échéance stricte.

Le réflexe le plus coûteux aurait été de faire taire l’application au nom du test. Les deux trafics portaient le même S-Label ; ils étaient associés au même service DetNet. Mais association ne signifie pas identité comptable. La RFC 9546 inscrit cette limite dans le format même du paquet.

Un label commun ne fusionne pas deux registres

Dans la sous-couche de service DetNet, le S-Label sert à identifier un flux. Pour un paquet OAM actif sur le plan de données MPLS, la RFC exige que le DetNet Associated Channel Header, ou d-ACH, suive immédiatement ce label. Le nœud peut ainsi rattacher le test au bon contexte de service et lui appliquer les fonctions spéciales prévues.

Le d-ACH contient cependant son propre numéro de séquence. Lorsque PREOF traite un paquet OAM, il doit prendre ce champ comme source de séquencement. Le document ferme ensuite la porte à toute assimilation : le flux applicatif et l’OAM utilisent des espaces de numéros de séquence différents.

Si le paquet OAM 78 apparaît après le 77, l’observation démontre une continuité dans cette session de test. Elle ne dit pas quel paquet applicatif était en vol, quelle copie de production a été éliminée, si un paquet tardif a dépassé une fenêtre d’ordonnancement ou si le destinataire l’a exploité avant son échéance. Le nombre 78 n’est pas une clé de jointure avec le soixante-dix-huitième événement métier.

Le S-Label reste précieux : il répond à la question « quel service ce test concerne-t-il ? ». Il ne répond pas à « quel paquet de production ce test remplace-t-il ? ». Une plateforme qui conserve seulement le label et un compteur transforme silencieusement une relation en équivalence.

Les champs du d-ACH bornent la parole du test

Les quatre premiers bits du d-ACH valent 0001. Ils différencient ce paquet d’un paquet IP et d’un paquet de données DetNet. Viennent ensuite une version de quatre bits — la version zéro dans la RFC —, un numéro de séquence circulaire de huit bits, un Channel Type de seize bits, un Node ID de vingt bits, un Level de trois bits, cinq bits de drapeaux et un Session ID de quatre bits.

Cette structure est une grammaire de compétence. Le Node ID désigne le nœud DetNet à l’origine du paquet et doit être unique dans le domaine. La méthode de distribution reste hors du périmètre de la norme. La largeur du champ ne garantit donc ni une unicité mondiale ni un inventaire exact. L’opérateur doit pouvoir montrer quel domaine est concerné, quel équipement possédait la valeur pendant l’intervalle et comment une collision serait détectée.

Le Level crée une hiérarchie proche des niveaux de domaines de maintenance. Deux équipes peuvent observer le même service depuis des frontières différentes sans disposer de la même visibilité. Le Session ID distingue plusieurs sessions actives issues du même nœud au même niveau. Le Channel Type identifie le protocole transporté.

Un historique OAM crédible a donc pour clé le S-Label, le Node ID, le Level, le Session ID, le Channel Type, l’époque de configuration et le point d’observation. Le numéro de huit bits seul n’est pas une identité ; c’est une position dans un périmètre que le stockage ne doit pas supprimer.

Le retour à zéro exige une époque, pas une intuition

Le nœud d’origine doit fixer le numéro avant l’émission. La valeur initiale devrait être imprévisible et la stratégie habituelle consiste à l’incrémenter d’une unité pour chaque paquet OAM actif. D’autres stratégies restent possibles, notamment pour soumettre une fonction d’ordonnancement à un test négatif.

Après 255 vient 0. La RFC estime cet espace suffisant parce que les paquets OAM actifs sont émis beaucoup moins vite que ceux du flux applicatif. Cette conclusion appartient au modèle d’usage prévu. Elle n’autorise pas n’importe quelle fréquence d’essai, n’importe quelle durée de corrélation ni un algorithme qui ignorerait l’heure et les redémarrages.

Une suite 254, 255, 0, 1 peut être un retour circulaire normal. Elle peut aussi masquer le début d’une nouvelle session si l’époque a été perdue. Une répétition peut être un doublon, un redémarrage ou le résultat de deux sessions fusionnées après suppression de leur identifiant. Une lacune peut venir du réseau, du collecteur, du générateur ou d’un test volontaire de désordre.

Le tableau de bord ne doit donc pas remplacer les champs bruts par une simple couleur. Il faut garder le tuple d-ACH complet, le label, l’heure de réception, le point de capture, le profil de test et l’événement de configuration. Sans ces éléments, une preuve exploitable devient un souvenir décoratif.

PREOF décide dans l’espace qui lui est présenté

La réplication, l’élimination et l’ordonnancement peuvent augmenter la probabilité d’une livraison ponctuelle et ordonnée. Pourtant, chaque décision PREOF porte sur une histoire locale : les copies visibles, la fenêtre maintenue, les délais admis et la séquence fournie au traitement.

Pour l’OAM, cette séquence vient du d-ACH. Pour le trafic applicatif, elle appartient au contexte de données du flux. Un succès d’élimination OAM ne documente pas quelle copie applicative a survécu. Une série OAM remise en ordre ne prouve pas que le tampon du flux de production a conservé les mêmes paquets ou appliqué le même délai.

Même un partage de destin favorable ne fusionne pas les compteurs. Il augmente la pertinence de la comparaison, mais il ne crée pas les événements manquants. Et cette question se distingue de celle, déjà importante, de savoir si la sonde a emprunté le même membre ECMP, subi la même politique ou traversé la même encapsulation. Ici, même si l’équivalence de traitement est admise, les deux histoires restent séparées par construction.

Corréler sans usurper

Une architecture d’assurance peut conserver quatre reçus reliés. Le reçu d’association établit la présence du bon S-Label et la position valide du d-ACH. Le reçu de session fixe Node ID, Level, Session ID, Channel Type, époque et politique du test. Le reçu PREOF OAM décrit les réplications, éliminations et décisions d’ordre appliquées aux numéros OAM. Enfin, un registre distinct suit la séquence applicative jusqu’au récepteur et au résultat métier.

La corrélation reste légitime. Une rupture OAM et une rupture applicative dans le même intervalle peuvent déclencher une enquête. Deux changements après la même modification de configuration renforcent une hypothèse. Mais l’outil doit dire que deux observations bornées coïncident, non que le compteur de test prouve la livraison d’un paquet absent.

Cette discipline élargit le diagnostic. L’origine OAM a peut-être redémarré ; deux Node ID ont pu entrer en collision ; le collecteur a pu perdre une mesure ; la production a pu rencontrer un risque partagé invisible au test ; ou l’application a pu rejeter une donnée que le réseau avait bien remise. Aucun voyant unique ne possède l’autorité nécessaire pour départager ces scénarios.

Sources