Résumé

  • RFC 10014 recommande d’abandonner les expressions « OAM in-band » et « OAM out-of-band », dont le sens varie, au profit de trois axes explicites : actif/passif/hybride, chemin congruent ou non, traitement de transfert égal ou différent.
  • Un paquet de test dédié peut suivre les mêmes nœuds et liens que le flux observé tout en bénéficiant d’une priorité, d’une file, d’un ordonnancement, d’un façonnage ou d’une protection différents. Il prouve alors un chemin, pas l’expérience du client.
  • Une organisation responsable doit rattacher chaque résultat à un flux, une direction, une époque de configuration, une couche, un domaine de maintenance, une population de paquets, un mode de calcul, une autorité de décision et une vérification indépendante du service après action.

Le rapport mensuel ne montrait aucune panne. La session de contrôle quittait le même routeur d’accès que le trafic professionnel, parcourait le même cœur et atteignait le même point de sortie. Son délai restait sous le seuil. Pourtant, les transactions de l’application se figeaient plusieurs fois par jour.

Le dessin d’architecture était exact et la conclusion fausse. Les paquets de contrôle portaient une classe prioritaire ; les paquets clients entraient dans une file soumise à la congestion. Le parcours topologique était identique. Le traitement ne l’était pas. Dans le contrat, les deux avaient été réunis sous une expression rassurante : « in-band OAM ».

RFC 10014, publié en juin 2026 comme Best Current Practice de l’IETF, porte sur ce glissement. Son objet officiel est le vocabulaire qualifiant l’OAM. Son effet pratique est plus vaste : il détermine ce qu’une mesure peut légitimement affirmer lorsqu’elle alimente un SLA, une alarme, une automatisation ou la clôture d’un incident.

« Dans la bande » de quoi ?

Les expressions in-band et out-of-band viennent de la radio et de la téléphonie, où une bande ou un canal possède un sens concret. Dans un réseau de paquets, plusieurs frontières se superposent. Une information de mesure peut se trouver dans le paquet de données lui-même. Un paquet de test séparé peut suivre le même chemin. Il peut aussi recevoir le même traitement QoS. Ces situations ne sont pas synonymes.

RFC 10014 les répartit en trois critères.

Le premier décrit la participation au trafic. Une méthode active crée des paquets OAM dédiés. Une méthode passive observe des flux existants sans produire de paquets de test et sans modifier ceux qu’elle observe. Une méthode hybride combine des éléments actifs et passifs. L’OAM dans le paquet de données constitue un cas particulier de méthode hybride de type I : l’information de mesure accompagne le trafic qui transporte aussi les données.

Le deuxième critère décrit la topologie. Une OAM congruente au chemin emprunte exactement les mêmes nœuds et liens que le trafic observé. Une OAM non congruente ne garantit pas cette identité. La définition ne dit rien de la file choisie à l’intérieur de chaque nœud.

Le troisième critère concerne précisément ce traitement. Des paquets OAM à traitement égal reçoivent le même régime de transfert que les données : file, ordonnanceur, priorité, façonnage et autres mécanismes QoS pertinents. Avec un traitement différent, l’un de ces éléments peut diverger.

Il ne s’agit pas d’un classement de qualité. Une sonde active a l’avantage d’être disponible lorsque le service n’émet aucun trafic. L’observation passive préserve le comportement réel mais peut expliquer moins facilement la cause. Une méthode hybride rapproche les deux au prix de règles de sélection, de compteurs ou de marquages qu’il faut conserver. La bonne méthode dépend de la proposition à vérifier.

Le chemin partagé ne suffit pas à partager le destin

RFC 10014 prend VCCV comme exemple révélateur. Les messages de vérification d’un pseudowire ont été dits in-band parce qu’ils suivent le chemin du service. La nouvelle terminologie les décrit plus rigoureusement : actifs, congruents au chemin, mais susceptibles de recevoir un traitement différent. Un opérateur peut donc établir la continuité de ce chemin sans avoir mesuré la congestion ressentie par les données.

BFD illustre une autre raison légitime de différer. Ses paquets de contrôle peuvent être placés à haute priorité afin de détecter rapidement une rupture. Cette priorité sert la fonction de vivacité. Elle empêche toutefois de lire une session BFD stable comme une preuve de faible perte ou de faible délai pour une classe ordinaire.

Lorsque le chemin et le traitement sont tous deux équivalents, RFC 10014 reprend l’idée de partage du destin. Cette propriété renforce considérablement la valeur d’une observation réseau. Elle ne transforme pas pour autant un paquet synthétique en transaction réelle. Taille, rafales, chiffrement, état du transport, temporisation applicative et traitement métier peuvent encore différer.

La formulation correcte est donc toujours bornée : le résultat établit telle propriété, pour telle population, dans telle direction et pendant telle époque. Le mot « vert » n’a aucun objet tant que ces coordonnées n’existent pas.

Chaque famille de mesure choisit une population différente

Un écho MPLS est une méthode active. Le paquet construit teste une FEC, une pile de labels et un comportement précis du plan de données. Sa réussite peut être décisive pour ce cas sans représenter tous les choix d’entropie ou les gros flux de production.

La mesure MPLS de perte et de délai distingue elle-même plusieurs sémantiques. Une mesure inférée compte des messages de test générés. Une mesure directe transporte dans des messages OAM des compteurs tirés du trafic utilisateur. Le transport du résultat reste actif, mais l’observation sous-jacente devient passive : c’est une méthode hybride. Un même tableau intitulé « loss » ne doit pas effacer cette différence de dénominateur.

Avec RFC 9197, IOAM inscrit des données de parcours dans des paquets de données sélectionnés. Pour ces paquets et dans le domaine concerné, le couplage au chemin et au traitement est fort. La collecte ne prouve toutefois ni que tous les paquets ont été sélectionnés, ni que l’export est complet, ni que l’application a consommé le contenu, ni que chaque domaine autorisait l’insertion.

RFC 9341 applique un marquage alterné au trafic réel afin de mesurer perte et délai par blocs. Sa force vient de cette population de production. Son interprétation dépend encore de la définition du flux, des points d’observation, des frontières de bloc, des horloges, des compteurs et du réordonnancement.

Ces exemples interdisent deux raccourcis. Actif ne signifie pas artificiel au sens d’inutile ; passif ne signifie pas complet ; hybride ne signifie pas automatiquement fidèle. La question reste : la population mesurée est-elle celle sur laquelle la décision porte ?

La couche et le domaine limitent aussi la preuve

RFC 7276 présente l’OAM comme un ensemble de fonctions de détection, d’isolation et de signalement des pannes, ainsi que de suivi des performances. Il rappelle aussi la structure multicouche des réseaux. Un fournisseur peut surveiller son domaine MPLS entre deux PE tandis que le client mesure une liaison IP de bout en bout entre ses propres équipements.

Les deux résultats peuvent être exacts. Ils ne regardent pas les mêmes limites. Une continuité parfaite dans le cœur ne disculpe pas l’accès, le CPE, l’overlay, la passerelle chiffrante ou l’application. À l’inverse, un test client défaillant ne démontre pas une faute dans le cœur. Le domaine de maintenance doit accompagner le résultat jusque dans le rapport commercial.

La direction doit également rester visible. L’aller et le retour peuvent suivre des politiques, des nœuds et des files différents. Une moyenne aller-retour réunit alors deux distributions inconnues. Et la validité expire : un résultat observé avant une bascule de protection, un changement de file ou une nouvelle politique de routage décrit l’ancienne époque, pas la nouvelle.

Une plateforme OAM ne détient pas toutes les fonctions

RFC 6291 fixe le développement Operations, Administration, and Maintenance et détaille ce que ces composantes recouvrent. Les opérations maintiennent le réseau en activité et trouvent les problèmes. L’administration suit les ressources et leur usage. La maintenance facilite réparation, mise à niveau et prévention. Le provisionnement est lié, mais distinct.

Une sonde de continuité n’est donc pas, par son seul nom, un inventaire fiable, une autorité de réparation et un vérificateur de résultat. Pourtant, une suite logicielle peut observer un signal, lui attribuer un sens, déclencher un contrôleur puis considérer l’exécution de la commande comme la résolution de l’incident.

Il faut conserver cinq responsabilités. Le système de mesure garantit l’intégrité de l’observation. Le propriétaire du service décide de sa portée. Le propriétaire de l’automatisation définit seuil, suppression et rayon d’action. L’autorité de changement autorise l’acte. Le responsable du résultat vérifie que l’utilisateur ou le flux a réellement récupéré. Une interface commune ne les fusionne pas.

Construire un contrat de preuve

Le dossier d’une mesure commence par l’identité : service, locataire ou agrégat ; extrémités ; direction ; classe ; couche ; domaine ; flux, FEC ou règle d’échantillonnage ; version de configuration et époque de transfert. Il indique actif, passif, hybride ou dans le paquet. Pour une sonde dédiée, la congruence du chemin et l’égalité de traitement doivent être garanties, attendues, échantillonnées ou fausses — jamais implicites.

Viennent ensuite la mécanique : format, taille et fréquence des paquets ; population marquée ; compteurs et retours à zéro ; horloge ; points d’observation ; fenêtre ; formule ; seuil ; confiance ; données manquantes. Zéro perte sans durée ni dénominateur n’est pas une preuve reproductible.

La provenance relie version d’outil, identité du collecteur, authentification, intégrité, empreinte de configuration, source temporelle, contrôleur et règle de corrélation. Une valeur authentique peut encore concerner le mauvais flux ou la mauvaise époque.

Enfin, la décision reste séparée de son effet : action autorisée, objet, rayon, clé d’idempotence, approbation, retour arrière, résultat de commit et test indépendant du service. Une bascule techniquement réussie suivie de transactions toujours en échec est une automatisation terminée, pas un incident clos.