Résumé

  • RFC 9533 crée une micro-session OWAMP ou TWAMP par membre physique d'un groupe d'agrégation ; l'adresse du faisceau et un quintuple IP ne prouvent pas que chaque lien a été mesuré.
  • Les identifiants de micro-session de l'émetteur et du réflecteur n'ont qu'une portée locale. Leur valeur devient probante seulement après corrélation avec le membre physique qui a réellement reçu le paquet.
  • Une mesure validée peut alimenter une politique de pilotage, sans démontrer que le trafic de production a suivi ce lien, qu'une commande a été installée ou que le service s'est amélioré.

L'agrégat protège la disponibilité et masque la différence

Un LAG réunit plusieurs liens physiques sous une seule interface logique. Cette abstraction augmente la capacité et permet de continuer lorsqu'un membre tombe. Elle rend cependant facile une conclusion trop large : puisque l'agrégat répond, tous ses chemins seraient sains. Dans un réseau étendu, deux membres du même faisceau peuvent suivre des transports différents et afficher des délais ou des pertes très différents.

La répartition est généralement déterminée par hachage. Une session active avec un quintuple fixe tombe donc sur un membre ; modifier ce quintuple peut explorer d'autres membres, mais sans inventaire la moyenne ne révèle pas lesquels ont été couverts. RFC 9533 remplace cette devinette par un ensemble explicite de micro-sessions, une par membre.

Les micro-sessions partagent les mêmes adresses IP source et destination. Elles peuvent avoir des ports UDP distincts, mais une paire commune est recommandée pour simplifier l'exploitation. L'identité utile n'est donc pas la seule enveloppe IP : c'est l'association conservée entre session et interface physique.

Une demande acceptée engage tout l'ensemble

Le client de contrôle utilise la commande 5 Request-OW-Micro-Sessions ou la commande 11 Request-TW-Micro-Sessions. Après acceptation, le serveur doit créer les sessions pour tous les membres du LAG par lequel la demande a été reçue. Les registres IANA confirment les numéros ; ils ne confirment ni l'acceptation par un équipement donné, ni l'exhaustivité de l'ensemble créé.

Cette exhaustivité doit être visible. Si l'inventaire annonce quatre membres et le système ne publie que trois résultats, calculer leur moyenne transforme une absence de preuve en bonne performance. Il faut distinguer ensemble demandé, ensemble accepté, sessions actives et échantillons valides. Le quatrième membre peut être lent, mais il peut aussi ne jamais avoir été testé.

Pour OWAMP, le récepteur utilise l'interface physique d'arrivée pour retrouver la micro-session. Sans session correspondante, il rejette le paquet. Ce comportement fait du port observé un élément du reçu, non une simple donnée de diagnostic.

Deux noms locaux pour deux réalités locales

TWAMP ajoute deux champs de 16 bits. Le Sender Micro-session ID désigne le membre côté émetteur et n'a besoin d'être unique que dans la session TWAMP de cet émetteur. Le Reflector Micro-session ID est unique dans la session côté réflecteur. Une base qui stocke le nombre sans l'équipement, la session et la période lui attribue une permanence que la norme ne promet pas.

L'émetteur peut ignorer d'abord l'identifiant distant et mettre le champ Reflector à zéro. Il peut ensuite apprendre la valeur par configuration ou par le paquet réfléchi ; RFC 9533 ne normalise pas ce mécanisme d'apprentissage. Zéro doit donc rester « valeur non fournie pour validation », et non devenir le nom fictif d'un lien.

À la réception, le réflecteur corrèle le paquet avec le membre physique d'entrée. Il rejette l'absence de session. Si l'identifiant Reflector est non nul, il vérifie qu'il correspond à ce membre et rejette toute divergence. La réponse recopie l'identifiant Sender et inscrit l'identifiant local du réflecteur.

Au retour, l'émetteur recommence avec le membre physique réellement observé. Il vérifie l'identifiant Sender recopié puis le comportement du réflecteur grâce au second champ. Le résultat de délai ou de perte n'est accepté qu'après ces vérifications. Le nombre est ainsi précédé d'une preuve bilatérale de contexte.

Ce que le reçu ne décide pas

Même validé, l'échange concerne une sonde. Un flux client peut être haché différemment. Le résultat ne prouve pas non plus qu'un contrôleur l'a lu, qu'une politique a sélectionné un autre membre, que l'équipement a appliqué le changement ou que l'expérience de service s'est améliorée.

RFC 8668 permet d'annoncer des attributs de membres pour le pilotage, mais une annonce n'est pas une observation. La chaîne responsable conserve l'inventaire, la création de session, les ports observés, la mesure, la version de politique, la décision, l'accusé d'installation et l'effet vu après changement.

RFC 9533 réutilise la sécurité d'OWAMP et de TWAMP et n'ajoute pas de protection nouvelle. Une authentification ne répare pas une correspondance périmée après remplacement d'une carte ou réutilisation d'un identifiant. L'intégrité du paquet et l'actualité de l'inventaire sont deux obligations distinctes.

Le registre minimal d'une mesure exploitable

Conserver pour chaque échantillon : LAG et version d'inventaire, deux extrémités, demande de contrôle et acceptation, nombre attendu de membres, session parente, deux identifiants, origine configurée ou apprise de l'identifiant distant, ports physiques d'émission et de réception, résultat des validations, cause des rejets, horodatage, estimation d'erreur, métrique et échéance de fraîcheur.

Trois états doivent rester séparés. Une dégradation de performance est un échantillon accepté hors seuil. Une défaillance de preuve est un rejet pour session ou identifiant incohérent. Un défaut de couverture est un membre attendu sans session utilisable. Leur attribuer la même couleur supprime l'information nécessaire à la correction.

Sources

Sources