Résumé

  • RFC 2214 plaçait dans une table SNMP par interface le backlog C, le délai D, le slack et un RowStatus, tous déclarés read-create.
  • Cette ligne décrivait l’écart d’une implémentation au modèle fluide et une décision locale d’allocation ; elle ne démontrait ni le passage d’un flux, ni la persistance d’une réservation, ni le respect d’un délai mesuré.

Une promesse de temps semble plus crédible dès qu’elle reçoit quatre cases et des unités. Une case porte des octets, une autre des microsecondes, une troisième une marge, la dernière un statut. Dans RFC 2214, cette ligne est indexée par ifIndex et peut, en principe, être lue et créée par gestion. Tout paraît prêt pour conclure : l’interface est configurée, donc le délai est garanti.

La spécification n’autorise pas ce raccourci. Publiée en septembre 1997 par Fred Baker, John Krawczyk et Arun Sastry, elle n’invente pas le service garanti. RFC 2212 en décrit le comportement quantitatif. RFC 2214 expose seulement, dans la MIB Integrated Services, les attributs propres à l’interface qui permettent de gérer cette implémentation.

Le backlog n’était pas la longueur instantanée d’une file

intSrvGuaranteedIfBacklog exprime en octets l’écart créé par une implémentation réelle par rapport à un service strictement bit par bit. Pour une file pondérée et paquetisée, le texte donne comme exemple la taille maximale d’un paquet. Ce terme correspond à C, l’erreur dépendante du débit dans RFC 2212.

C intervient dans la borne après division par le débit réservé R. Cette forme traduit une propriété technique : certaines imperfections, telle la sérialisation d’un datagramme, coûtent un temps qui dépend du débit. La valeur ne mesure donc pas une file au moment de la lecture SNMP. Elle caractérise la manière dont l’implémentation s’éloigne du serveur fluide idéal.

L’erreur de lecture serait grave. Une jauge instantanée répond à « combien attend maintenant ? ». C répond à « quelle erreur dépendante du débit faut-il inclure dans le modèle ? ». Les deux peuvent être exprimées en octets sans produire la même preuve.

D décrivait un maximum local, pas le trajet observé

intSrvGuaranteedIfDelay porte D en microsecondes. RFC 2212 définit D comme l’erreur par élément indépendante du débit : la variation maximale de transit que R ne suffit pas à expliquer. RFC 2214 évoque le temps nécessaire pour passer de l’interface d’entrée au processeur puis à l’interface de sortie, ou le pire délai lié aux collisions sur Ethernet.

Cette valeur est souvent déterminée au démarrage ou par configuration. Elle n’est pas l’horodatage d’un paquet. Pour obtenir une grandeur de bout en bout, les éléments locaux doivent être composés en Ctot et Dtot sur le chemin réellement emprunté. RFC 2212 précise en outre ses conditions : trafic conforme, absence de panne et itinéraire inchangé pendant la vie du flux. La borne vise le délai de mise en file maximal, non le délai moyen ou minimal ; la latence du chemin reste à ajouter.

Une lecture de D dit donc ce que l’interface déclare. Elle ne prouve pas que le flux a rencontré cette interface, que tous les sauts ont fourni une valeur correcte, ni que la route n’a pas changé.

Le slack devait garder la mémoire d’un choix

Le troisième objet contient le mécanisme le plus politique au sens opérationnel : un choix de ressources. Si un élément consomme une quantité Si de slack pour réduire ce qu’il réserve au flux i, RFC 2214 exige qu’il conserve Si. Lors des refreshs suivants de cette réservation, il doit réutiliser la même valeur sans nouveau calcul afin de préserver la cohérence.

La marge part de la différence entre le délai requis et le délai maximal du système fluide : S = Dreq - (b/r + Ctot/r + Dtot). Un élément intermédiaire peut prendre s <= S. Selon l’ordonnanceur, il augmente alors une borne locale de délai ou diminue le débit réservé, tout en respectant les règles censées maintenir la borne globale.

Le slack n’est donc ni une bande passante libre ni un délai constaté. C’est la portion d’une marge que l’élément choisit de convertir en économie locale de ressources. Sa persistance évite qu’un refresh identique produise une nouvelle allocation et fasse dériver la réservation.

Mais la table RFC 2214 reste indexée par interface. Elle ne conserve pas, à elle seule, l’identité complète du flux, la négociation RSVP, les refreshs reçus ou le chemin. Pour auditer la cohérence promise, il faut relier la décision locale à ces autres traces.

Une écriture SNMP n’était pas une négociation RSVP

Les quatre objets sont read-create. Ce droit possible d’écriture agrandit la surface de contrôle. La section de sécurité formule la limite essentielle : un SET SNMP peut provoquer une réservation RSVP ou Integrated Services selon des règles différentes de celles d’une réservation négociée par RSVP.

Un retour réussi du SET ne devient donc pas le consentement du récepteur. Il ne démontre pas la continuité de l’état souple, l’admission d’un demandeur déterminé, l’activité du classificateur, le comportement de l’ordonnanceur ou la composition du chemin.

Le statut ne referme pas l’écart. RFC 2214 l’emploie pour les interfaces configurées pour le service garanti. Dans la convention RowStatus, active signifie que la ligne conceptuelle est disponible pour le dispositif géré. Le mot ne certifie aucun résultat au-delà de cette disponibilité locale.

L’apport historique de RFC 2214 est précisément cette séparation. C et D rendent explicite la distance entre l’idéal mathématique et l’équipement. Le slack rend visible un arbitrage local et impose que cet arbitrage survive aux refreshs. La MIB permet de gérer ces faits. La preuve d’un service, elle, exige encore le flux, le chemin, la composition, la conformité du trafic et l’observation.

Sources