Résumé

  • La RFC 9892 est une spécification IETF sur le chemin des normes qui définit un Data Item DLEP extensible pour la classification du trafic, avec des sous-items Diffserv et Ethernet initiaux.
  • Un TID nomme un ensemble de classification local au modem ; les FID identifient les flux dans un sous-item. L’extension consommatrice fournit l’association à une destination et le sens opérationnel.
  • Un TID reçu initialise ou remplace les informations de classification associées. La validation des doublons porte sur l’ensemble du Data Item.
  • Un compte Diffserv nul sert de caractère générique pour les DSCP qui ne sont pas mappés autrement. Pour Ethernet, un compte PCP nul fournit une correspondance par défaut ; les VLAN explicites sont examinés en premier.
  • Lorsqu’un classificateur Ethernet et un classificateur Diffserv correspondent tous deux, VID/PCP Ethernet est prioritaire et son TID doit être utilisé.

La base DLEP identifie un point terminal, tandis que la RFC 9892 permet au modem de communiquer un regroupement plus riche d’identifiants du plan de données. Le TID appartient à l’espace de noms de classification local au modem ; ce n’est pas un nom de politique universel. Les FID ont pareillement un sens dans le sous-item concerné. Une extension qui consomme cette information doit l’associer à une destination et définir son usage opérationnel. La RFC 9892 ne fournit pas elle-même cette association.

Le remplacement est déterminant. La réception d’un TID initialise ou remplace les informations de classification qui lui sont associées, et le routeur met à jour l’état du plan de données selon les besoins. Une implémentation doit donc valider le Data Item Traffic Classification complet avant son activation. Pour Diffserv, les valeurs du champ DS sont regroupées au moyen de FID ; un compte nul constitue le joker pour les DSCP non mappés. Des valeurs DS Field dupliquées dans un même Data Item sont des erreurs.

Pour Ethernet, les valeurs VLAN/PCP sont regroupées par FID ; un compte PCP nul est un défaut, une correspondance VLAN explicite est prioritaire, et des priorités dupliquées dans un même Data Item sont des erreurs. Ces règles évitent qu’un item ambigu ne produise silencieusement deux résultats.

Ces formats n’ont aucun effet par eux-mêmes. Une autre extension DLEP négociée doit les exiger et les interpréter. La commande de fenêtre de crédit de la RFC 9893 est un exemple de consommateur, pas une obligation cachée de la RFC 9892. Ni le document de classification ni les documents Diffserv sur le champ et l’architecture ne définissent l’ordonnanceur du routeur, les poids de files, la politique d’admission ou l’algorithme de fenêtre de crédit. Le vocabulaire Diffserv décrit des marquages et des domaines, mais l’ensemble de sources n’établit pas que les DSCP soient fiables de bout en bout entre domaines administratifs.

Fixtures concrètes de vérification

Un opérateur peut tester un analyseur avec cinq fixtures. Premièrement, envoyer un TID contenant deux groupes DSCP distincts et vérifier que chaque FID est résolu une seule fois. Deuxièmement, répéter une valeur DS Field dans deux groupes et exiger le rejet du Data Item entier. Troisièmement, envoyer un item Ethernet avec une correspondance VID/PCP explicite et un défaut PCP nul, puis vérifier que le VLAN explicite gagne. Quatrièmement, présenter un paquet correspondant aux deux familles et vérifier la sélection du TID Ethernet.

Cinquièmement, remplacer un TID existant et vérifier que les anciens mappages sont retirés ou actualisés selon l’extension consommatrice, plutôt que fusionnés par inadvertance. Conserver l’item brut, le résultat de validation, la carte TID/FID active et la décision de l’extension.

Frontière de sécurité

Un pair malveillant qui modifie l’association classification-file peut provoquer délai, congestion ou pertes dans des classes de service. La RFC 9892 renvoie à la sécurité applicable du transport DLEP et de la couche liaison ; elle ne définit pas un nouveau modèle de confiance. Protéger et authentifier l’échange DLEP ne prouve pas qu’un marquage est sémantiquement honnête dans tous les domaines administratifs. Il faut donc distinguer l’origine authentifiée de la politique de classification effectivement digne de confiance.

Parcours de décision opérateur

  1. Confirmer qu’une extension consommatrice négociée exige et interprète explicitement le Data Item.
  2. Valider l’item complet : doublons DS Field ou priorité, jokers, remplacement et priorité Ethernet sur Diffserv.
  3. Relier l’état TID/FID local au modem à l’association de destination déclarée par l’extension ; ne pas attribuer au TID un sens global inventé.
  4. N’appliquer la politique réelle de file ou de crédit de l’extension qu’après avoir enregistré la version de classification acceptée.
  5. En cas de changement inattendu, isoler ou rétablir l’état selon la gouvernance locale, puis comparer la télémétrie des files avec la trace de mise à jour authentifiée.

Le dernier point relève de l’analyse de Theo March, pas d’une exigence de la RFC 9892 : une piste d’audit reliant mises à jour authentifiées, cartes actives, points de retour et télémétrie des files facilite l’enquête. Il en va de même pour la confiance accordée aux marquages entre domaines, qui doit rester une hypothèse opérationnelle explicite. La RFC 9892 fixe la frontière de l’échange ; l’extension consommatrice et l’implémentation locale décident de l’aval.

Sources