Résumé

  • RFC 3387 constatait qu’un mécanisme de différenciation pouvait fonctionner avant que le réseau sache définir, autoriser, vérifier et facturer le service dont il était censé être l’instrument.
  • Le document répartissait les fonctions entre accès, cœur et frontières administratives, tout en avertissant qu’une gestion plus centralisée et des capacités premium pouvaient fragiliser le meilleur effort.

Un paquet marqué arrive sur une interface. Le classificateur le reconnaît, le compteur l’observe et l’ordonnanceur le fait partir avant un autre. On peut capturer ces événements. On peut même prouver que le routeur a respecté sa configuration locale. Mais le client n’a pas nécessairement reçu un service.

Il manque le droit d’utiliser la classe, l’engagement quantitatif, la capacité admise sur le trajet, la continuité de la signification chez les voisins, la méthode de mesure, la règle de facturation et la responsabilité en cas d’échec. C’est cet espace entre le paquet privilégié et la prestation vérifiable que RFC 3387 a exploré en septembre 2002.

Le texte, publié comme Informational par des auteurs du Service Management Research Group de l’IRTF, ne proposait aucun nouveau protocole. Il regardait un Internet où IntServ, DiffServ, la politique et l’ingénierie de trafic avançaient, tandis que le cadre de gestion capable d’en faire des services restait incomplet.

Le meilleur effort correspondait à une architecture historiquement simple et décentralisée. La différenciation changeait le contrat. Dès que certains paquets pouvaient recevoir davantage, il fallait expliquer ce « davantage » sans réduire le service à un bit, une file ou une réservation.

RFC 3387 distinguait la définition du service de son incarnation. La définition devait être sans ambiguïté et transposable sur les capacités du réseau. L’incarnation devait affecter de vraies ressources et des mécanismes de contrôle. Un modèle d’information décrivait l’intention ; il ne démontrait pas que la capacité existait, que la configuration avait été acceptée ou que le résultat avait été observé.

À l’accès, la chaîne commençait par l’admission, l’authentification et l’autorisation. Il fallait ensuite vérifier que le trafic restait dans les paramètres convenus, fournir des interfaces de facturation, signaler les fautes et permettre la remise en service ou la terminaison. Une autorisation sans admission pouvait accorder un droit impossible à réaliser ; une admission sans contrôle pouvait consommer les ressources des autres.

Dans le cœur, les fonctions étaient différentes : ingénierie de trafic, configuration des équipements, connaissance des ressources, détection et reprise sur panne. Le document envisageait un calcul plus central parce qu’une décision de trajet pouvait dépendre d’informations globales. Il ne transformait pas cette possibilité en nécessité. Il rappelait au contraire la question du coût architectural et du risque de déstabilisation.

Aux frontières, deux opérateurs concurrents devaient coopérer sans livrer leur réseau intérieur. Signalisation du service, mesure, comptabilité, vérification et transfert des données de facturation formaient des interfaces distinctes. Un accord bilatéral décrivait une frontière ; plusieurs accords alignés ne devenaient pas magiquement une garantie de bout en bout.

Le recours possible à un courtier de bande passante ou à un tiers de confiance répondait à ce problème pratique. Un intermédiaire pouvait rapprocher admission, validation ou paiement. Mais sa fonction ne lui donnait pas une autorité générale sur les domaines pairs. La preuve échangée devait rester plus étroite que le pouvoir de celui qui la transporte.

La facturation révélait les confusions. RFC 3387 demandait de la concevoir dès la naissance du service, en même temps que la sécurité. RFC 2975 permet de séparer la comptabilité, qui recueille des usages, de la tarification, qui applique une règle de prix, et de la facturation, qui formule une créance. Le paiement est encore un autre fait. Aucun compteur ne certifie seul les quatre étapes.

DiffServ fournissait des comportements par saut et du conditionnement aux frontières. RFC 3387 insistait : une classe garantie à chaque saut ne constitue pas, par elle-même, une garantie de bout en bout. Le client achète un résultat sur un trajet ; l’ordonnanceur ne voit que sa sortie locale.

Le même écart menace le trafic ordinaire. Une capacité réservée peut rester inutilisée tout en étant soustraite au meilleur effort. Un fournisseur peut avoir intérêt à rendre le service premium rare et visible. Le RFC ne mesurait pas une dégradation réelle ; il identifiait un conflit d’incitations que l’exploitation devait surveiller.

La primauté du code en fonctionnement, chez Lu Heng, fournit une limite utile. Le socle commun doit porter les règles déterministes indispensables à l’interopérabilité et à la vérification, pas le modèle commercial complet de chaque réseau. Une frontière peut exiger une identité, une autorisation, des paramètres et un reçu mesurable sans transformer un courtier ou un vérificateur en souverain.

RFC 3387 n’a pas achevé la gestion de service IP. Il a mieux fait pour l’histoire : il a refusé de confondre le premier mécanisme visible avec le produit final. La file savait différencier. Restait à définir le service, à engager les ressources, à assembler les domaines, à vérifier la promesse et à montrer qui supportait le coût.

Sources