Résumé

  • RFC 3317 faisait remonter au serveur de politique les fonctions DiffServ prises en charge, leur profondeur d’enchaînement et les liaisons autorisées avant de construire le chemin de traitement.
  • Cette déclaration ne garantissait pas la faisabilité du graphe complet : l’équipement devait encore signaler l’échec d’une politique impossible, et son acceptation ne prouvait pas le service rendu aux paquets.

Une file d’attente peut exister sans pouvoir alimenter le bon ordonnanceur. Un classificateur et un compteur peuvent être présents sans être raccordables dans l’ordre souhaité. RFC 3317 partait de cette différence entre posséder des briques et savoir bâtir le chemin demandé.

Publié en 2003 comme document informatif, il définissait une Policy Information Base pour la qualité de service DiffServ. Le modèle plaçait les éléments fonctionnels du routeur dans une chaîne : classificateur, compteur, action, mécanisme de rejet, file et ordonnanceur. Une politique qui devait revenir à une catégorie déjà dépassée utilisait plusieurs blocs de conditionnement du trafic. Des pointeurs Next reliaient les éléments et transformaient la configuration en graphe orienté.

Ce graphe n’était pas une description physique du silicium. Il exprimait le traitement attendu. Un classificateur séparait les flux, un compteur comparait leur débit à un profil, une action pouvait marquer le DSCP, un algorithme décidait des rejets, puis les paquets entraient dans une file avant d’être servis. Les paramètres demeuraient dans des classes distinctes : plusieurs éléments pouvaient réutiliser un même profil de seau à jetons ou une même définition de débit. La structure disait où aller ; le paramètre disait avec quelles valeurs.

Cette séparation rendait l’ensemble extensible, mais elle créait aussi un risque. Un serveur pouvait assembler des objets tous valides et produire néanmoins un chemin irréalisable sur le matériel visé. RFC 3317 ne laissait donc pas le Policy Decision Point deviner la machine. Le Policy Enforcement Point devait d’abord lui communiquer les classes de provisionnement comprises, les types d’interface, les combinaisons de rôles et les ensembles de capacités valables à l’entrée ou à la sortie.

La déclaration allait au-delà d’un simple inventaire de fonctions. Elle pouvait indiquer les champs utilisables pour classifier, le traitement disponible pour les paquets hors profil, les algorithmes de rejet, le nombre de files, leur mémoire, les méthodes d’ordonnancement, le nombre d’entrées d’un ordonnanceur et les niveaux de débit maximal. Un contrôleur pouvait ainsi éviter de demander huit files à une interface qui n’en exposait que quatre.

Deux tables donnaient à cette négociation sa portée la plus intéressante. L’une fixait la profondeur maximale d’éléments fonctionnels consécutifs. L’autre indiquait quels types d’éléments pouvaient se suivre. Elles reconnaissaient qu’une capacité est aussi une propriété des relations. Posséder un compteur et un ordonnanceur ne prouve pas qu’un chemin direct puisse relier l’un à l’autre, ni que le processeur interne supporte une nouvelle étape après la profondeur annoncée.

Après cette remontée, le PDP pouvait envoyer une politique propre au domaine administratif, au type d’interface, au rôle et au sens du trafic. Une entrée de chemin désignait le premier élément. Son absence, ou la valeur explicite zeroDotZero, renvoyait au traitement IP normal de l’équipement. Le modèle raisonnait sur des catégories d’interfaces plutôt que sur chaque port concret : il gagnait en réutilisation ce qu’il perdait en précision locale.

Le texte posait lui-même la limite. Les classes de capacité ne fournissaient que des indications générales ; elles ne pouvaient pas décrire toutes les combinaisons possibles ou impossibles. Les ressources partagées, les contraintes internes et l’interaction entre plusieurs fonctions pouvaient encore invalider une politique apparemment conforme. Le PEP devait alors retourner un rapport d’échec. La capacité déclarée réduisait l’espace des erreurs ; elle ne supprimait pas le verdict d’installation.

Cette nuance sépare plusieurs preuves. La notification de capacité affirme ce que l’équipement dit généralement savoir faire. Le graphe exprime l’intention du serveur. La réponse COPS-PR décrit une transaction de provisionnement. Une lecture d’état peut montrer des lignes présentes. Il faut encore observer le traitement des paquets pour établir l’application effective, puis mesurer autre chose pour parler de qualité perçue par un client.

L’échange révélait aussi des informations sensibles. Les lignes à installer pouvaient représenter un contrat de service ou des filtres appliqués au trafic d’un client ; leur altération modifiait le comportement DiffServ. Les lignes de notification dévoilaient la forme et les limites du dispositif. Le document renvoyait à la protection IPsec entre PDP et PEP : falsifier l’inventaire pouvait conduire le serveur à construire la mauvaise politique, tandis que falsifier la politique pouvait redistribuer les ressources.

En 2016, l’IESG a classé RFC 3317, la PIB de cadre, COPS-PR et SPPI comme historiques. La justification mentionnait un déploiement limité et le déplacement des travaux de gestion vers NETCONF et YANG. Ce constat clôt le destin de cette famille technique ; il n’annule pas la question qu’elle rendait explicite.

Une politique centralisée ne vaut que si le système cible peut en réfuter la forme. L’intention doit rencontrer un modèle des limites, et ce modèle doit rester assez humble pour laisser place à un échec final. Sans ces deux niveaux, le contrôleur confond tôt ou tard une configuration imaginable avec une configuration exécutable.

Sources : RFC 3317, RFC 3318, RFC 3290, RFC 3084, RFC 3159, RFC 2475 et le changement de statut de l’IESG en 2016.