Résumé

  • Les TID et FID de RFC 9892 décrivent, dans l’espace local d’un modem, un ensemble de classification et ses flux. Ils ne constituent ni des identifiants globaux ni la preuve qu’une file, une fenêtre de crédit ou un traitement a été appliqué.
  • Le routeur doit valider l’ensemble complet, remplacer une ancienne version, résoudre les règles explicites, génériques et de priorité, puis laisser une extension négociée donner un usage au résultat. L’observation du plan de données vient encore après.

Après le remplacement d’un modem, le tableau de bord affichait toujours « TID 12 ». L’équipe en conclut que la politique de trafic n’avait pas changé. Le nombre était identique ; l’objet qu’il semblait désigner ne l’était plus.

RFC 9892 définit un élément de données de classification pour le Dynamic Link Exchange Protocol. Un modem peut regrouper plusieurs descriptions de trafic sous un Traffic Classification Identifier, puis associer chaque flux à un Flow Identifier porté par un sous-élément. Le routeur reçoit ainsi une description structurée de ce qu’il doit reconnaître dans les en-têtes.

La portée des identifiants tranche immédiatement le problème du tableau de bord. TID et FID sont locaux au modem. Deux modems peuvent employer le même nombre sans parler du même ensemble. Une corrélation durable doit donc inclure l’identité du modem, la session DLEP, la version complète du classificateur et l’extension qui l’utilise.

RFC 8175 situe cet échange sur la liaison locale entre un routeur et un modem. DLEP maintient une session, négocie les extensions pour cette session et décrit des destinations ou des caractéristiques de lien. Le protocole ne définit pas la signalisation radio sous-jacente. Un TID n’est donc ni une adresse de bout en bout ni une preuve transportable hors de son contexte.

La description est réutilisable parce qu’elle ne décide pas de l’usage

Le choix architectural de RFC 9892 est de séparer le « quoi reconnaître » du « quoi en faire ». Les formats de classification sont indépendants d’un mécanisme précis. Une extension de contrôle de flux peut les employer, mais une autre extension peut leur donner une autre fonction. Le document anticipe même de futurs types, par exemple un cinq-tuples IP.

Cette réutilisation empêche de lire classifié comme mis en file. Le classificateur fournit une sélection. L’extension apporte l’association avec une destination et la conséquence opérationnelle. Le routeur doit encore installer un état dans son plan de données. Enfin, un paquet réel doit correspondre à la règle, être admis, transmis et observé.

Le registre IANA des paramètres DLEP attribue le type 29 à la classification du trafic et enregistre les premiers sous-types Diffserv et Ethernet. Le registre coordonne des valeurs de protocole. Il ne révèle pas les extensions négociées dans une session, la configuration d’un appareil ou le traitement d’un paquet.

La distinction rejoint la primauté du code en fonctionnement de Heng Lu. Une spécification commune rend l’échange possible ; l’état exécuté permet d’établir ce qui s’est effectivement produit. Le registre et le message sont des marches de la preuve, non son sommet.

Une mise à jour remplace un ensemble

Le modem peut annoncer des classifications pendant l’initialisation et en envoyer de nouvelles dans un message de mise à jour. Si le routeur possède déjà le TID reçu, il doit remplacer les informations correspondantes et ajuster l’état associé selon les besoins.

Le verbe remplacer est décisif. Une base d’observation qui additionne chaque sous-élément reçu fabrique un classificateur fantôme, composé de règles anciennes et nouvelles. À l’inverse, une base qui écrase silencieusement la version précédente perd la cause d’un changement de trafic. Il faut conserver les deux vues : l’ensemble courant utilisé pour décider, et une succession horodatée permettant l’audit.

L’ordre des sous-éléments n’a pas de signification. Ni la position dans le message ni la valeur croissante d’un FID ne crée une priorité implicite. Les règles de sélection viennent du type de sous-élément et de la sémantique de l’extension.

Même le zéro possède deux sens contraires. Zéro sous-élément dans un élément de classification signifie qu’aucun trafic ne correspond au TID. Zéro DSCP dans un sous-élément Diffserv signifie un joker : il capture les DSCP qui n’ont pas de correspondance explicite. Une interface qui résume ces deux états par « défaut » détruit l’information nécessaire au contrôle.

Le principe de spécification initiale minimale et de décision future locale éclaire ce partage. Le format, les bornes et la validation doivent être communs. L’usage, la configuration et le risque restent chez ceux qui opèrent la session et supportent les conséquences.

Valider l’ensemble avant de choisir

Le sous-élément Diffserv associe un FID à une ou plusieurs valeurs DSCP. Le routeur doit valider les données avant de les employer. Chaque valeur DS doit être unique dans l’élément de classification complet, pas seulement à l’intérieur d’un fragment. Deux sous-éléments portant le même DSCP rendent donc l’ensemble erroné.

RFC 2474 définit le classificateur comme l’entité qui sélectionne les paquets à partir des en-têtes et de règles. La valeur DSCP est ensuite liée à un comportement par saut, souvent réalisé par une discipline de file. Plusieurs codepoints peuvent mener au même comportement, et certains ont une signification locale. Le codepoint n’est pas le service.

L’architecture Diffserv de RFC 2475 place aussi classification, conditionnement et comportement dans des domaines administrés. Une marque peut voyager ; la politique qui l’interprète reste locale. Promettre un résultat de bout en bout sur la seule présence d’un DSCP inverse cette relation.

Le sous-élément Ethernet ajoute le VLAN et les Priority Code Points. Un VLAN nul demande d’ignorer ce champ ; la valeur réservée ne peut être utilisée. Les correspondances explicites de VLAN passent avant la valeur par défaut. Surtout, si un paquet correspond à la fois à une règle Diffserv et à une règle Ethernet, RFC 9892 donne la priorité à l’information VLAN/PCP.

Il faut donc retenir toutes les correspondances candidates, le résultat de validation global, la distinction entre règle explicite et joker, puis la règle de priorité qui a choisi le FID final. Enregistrer seulement le DSCP rencontré produit une donnée vraie mais une décision fausse.

L’extension crée le prochain lien, pas le classificateur

RFC 9892 précise que ses formats ne sont utilisés que lorsqu’une extension l’exige. RFC 9894 en fournit un exemple avec la fenêtre de crédit sensible à Diffserv. Les pairs doivent annoncer l’extension pendant l’initialisation ; un participant ne doit pas émettre les éléments associés si son pair n’a pas déclaré le support. L’implémentation doit également prendre en charge les traitements de RFC 9892 et RFC 9893.

RFC 9893 ajoute l’association entre un TID, une destination DLEP et une fenêtre de crédit. Un TID qui ne figure pas dans l’élément d’association n’est pas utilisé par ce mécanisme. Des TID qui se chevauchent entre fenêtres constituent une erreur.

C’est ici que cette analyse se sépare de l’article antérieur consacré au crédit DLEP. Ce dernier examine pourquoi une autorisation d’envoyer ne prouve pas la remise sur le lien. Le présent article s’arrête avant : il faut d’abord établir quel ensemble était courant, quelle règle a gagné et quelle extension a transformé le FID en entrée de contrôle.

La chaîne complète comporte encore l’installation, la file ou fenêtre active, l’admission du paquet, la transmission sur le média, la réception distante et le résultat applicatif. Chaque transition a son propriétaire et son horodatage.

Un pair authentifié peut encore fournir une mauvaise règle

RFC 9892 décrit le risque d’un acteur se faisant passer pour un pair DLEP et injectant une autre classification. Une telle modification peut déplacer le trafic entre files et produire retard, congestion ou perte. Les protections de transport ou de couche 2 citées par RFC 8175 réduisent le risque d’usurpation.

Elles ne rendent pas automatiquement correcte la politique reçue. Un canal authentifié établit l’origine du message. Il ne prouve pas que l’ensemble correspond à l’intention, que le routeur l’a installé, ni que des contraintes locales n’ont pas changé le traitement.

La bonne preuve associe donc l’identité du pair et l’intégrité du message à des observations ultérieures : version acceptée, FID choisi, extension consommatrice, destination, état programmé, compteurs, transmission et réception.

Dans Les couches de réalité et le pouvoir symbolique, Heng Lu montre comment un libellé peut absorber des actes qu’il ne constate pas. Le mot classifié devient dangereux lorsqu’il signifie en même temps reçu, valide, installé, servi et livré. Garder les couches séparées protège à la fois l’interopérabilité et l’autonomie opérationnelle.

Le classificateur a donné un nom local au flux. Le traitement reste une décision, puis un fait, qui doivent être prouvés ailleurs.

Sources