Résumé

  • RFC 3290 représente le traitement Diffserv d’un routeur par un graphe orienté acyclique d’éléments fonctionnels reliés : le système de gestion peut ainsi décrire classification, mesure, marquage, mise en file, ordonnancement ou abandon.
  • Ce graphe est volontairement un modèle d’information. Il facilite la description des comportements, sans imposer une implémentation ni prouver qu’un paquet a reçu le service promis.

Un codepoint ne fait qu’indiquer le début du parcours

Le DSCP est visible dans l’en-tête d’un paquet. À lui seul, ce champ de six bits ne révèle pourtant pas ce que fera ensuite un routeur donné. Il peut orienter un classificateur de comportement agrégé ; le trafic rencontre encore des filtres, des compteurs, des actions de marquage ou d’abandon, des files et des ordonnanceurs.

Le RFC 3290, Diffserv Informal Management Model, a rendu cette distinction explicite. Ce RFC de catégorie Information, publié en 2002, décrit le conditionnement du trafic et la mise en file au moyen d’un graphe orienté acyclique d’éléments fonctionnels. Un classificateur peut séparer un flux ; un compteur peut envoyer les paquets vers des sorties distinctes selon leur conformité ; les actions en aval peuvent marquer, compter, abandonner ou multiplexer ; les files et ordonnanceurs influent sur le départ et la perte.

L’unité d’analyse est donc la composition. Le DSCP peut aider un classificateur BA à choisir une branche, mais un autre classificateur peut examiner d’autres champs. Les sorties d’un compteur peuvent alimenter différentes décisions de marquage, de file ou d’abandon. Le traitement final dépend des fonctions reliées et de leurs paramètres, pas de la seule étiquette.

RFC 3290 regroupe également des éléments bas niveau en Traffic Conditioning Blocks (TCB). Les administrateurs peuvent raisonner sur ces blocs à l’entrée ou à la sortie d’une interface et les relier en série ou en parallèle. Le TCB est une commodité de gestion — une boîte noire logique dotée d’une entrée et d’une ou plusieurs sorties — et non l’affirmation que les routeurs partagent une architecture matérielle.

Une carte de gestion, pas un plan de silicium

Cette limite est la réserve essentielle du RFC. Le modèle est une abstraction destinée aux outils de configuration et de gestion, notamment SNMP ou d’autres interfaces de politique. Il ne vise pas à contraindre l’implémentation des routeurs. Une file logique ou un compteur ne correspond pas nécessairement à un composant matériel unique.

L’abstraction rend comparables des équipements différents, mais laisse des inconnues. Le cœur de routage de RFC 3290 est un interconnexion idéalisée ; le délai, la perte et la surcharge réels du fabric doivent être modélisés ailleurs. Les paramètres de file décrivent un comportement logique, pas les tampons physiques de l’appareil. Un graphe peut représenter le traitement configuré ; il ne prouve pas que le chemin de transfert l’a correctement installé ni ce qui s’est produit sous congestion.

La représentation des compteurs l’illustre bien. Dans l’architecture Diffserv, un compteur peut observer le trafic et envoyer un signal de contrôle à une action. RFC 3290 le dessine plutôt comme une bifurcation logique 1-vers-N : chaque sortie de conformité rejoint l’élément suivant. Les auteurs précisent que cette différence de représentation ne change pas sa fonction. Elle rend toutefois le parcours plus facile à composer — sans prétendre que le câblage du modèle est le circuit du routeur.

RFC 3444 distingue ensuite plus clairement les modèles d’information abstraits des modèles de données qui les encodent pour des protocoles de gestion précis. C’est la bonne lecture de RFC 3290 : un vocabulaire et une structure partagés, pas une prescription pour le moteur de traitement des paquets.

Ce que le graphe établit — et ce qu’il n’établit pas

Le graphe aide à examiner les relations prévues entre classification, conditionnement et mise en file, et à rattacher paramètres, compteurs et objets de gestion. Il rend aussi la composition d’une politique vérifiable : une branche « hors profil » n’a pas de sens opérationnel tant que l’élément suivant et le comportement final de file ou d’abandon ne sont pas connus.

Mais un graphe configuré n’est qu’un niveau de preuve. Pour établir un service effectivement rendu, il faut encore la configuration propre à l’équipement, le comportement de l’implémentation, les compteurs ou l’observation de paquets, ainsi que des mesures à la frontière du service. Un DSCP ne garantit pas la latence ; le nom d’un PHB ne mesure pas une file ; un modèle de gestion ne prouve pas qu’un ordonnanceur a fonctionné comme prévu en charge.

RFC 3290 reste utile sans devenir un dessin universel du routeur. Il décrit la logique située entre le marquage d’un paquet et son départ. Il ne réduit pas cette logique au marquage et ne transforme pas une configuration voulue en preuve de performance livrée.

Sources