Résumé

  • Le RFC 2386 cherchait des chemins à partir des ressources connues et des besoins du flux, mais précisait que le calcul de route ne réservait aucune de ces ressources.
  • Il accordait une grande liberté aux solutions internes d’un domaine tout en limitant l’échange interdomaines à des indications relativement stables ; chaque nœud gardait le pouvoir d’admettre ou de refuser le flux.

Une route possible n’était pas encore une route disponible

Le routage de meilleur effort répondait surtout à la question de la connectivité. Une métrique unique — nombre de sauts, poids administratif ou coût — suffisait souvent à choisir la route préférée. Un service assorti d’exigences de qualité posait une autre question. Le chemin devait-il offrir une bande passante résiduelle donnée ? Un délai maximal ? Une certaine variation du délai ? Le meilleur chemin ordinaire pouvait échouer là où une route secondaire aurait convenu.

Le RFC 2386 appela « routage fondé sur la QoS » la sélection d’un chemin à partir des exigences du flux et d’une connaissance des ressources. Sa formulation restait prudente : le calcul trouvait un chemin ayant de bonnes chances d’accommoder la demande. Il ne créait pas la capacité. Un protocole tel que RSVP pouvait demander et réserver des ressources, mais ne découvrait pas à lui seul le chemin adéquat. Le routeur, inversement, pouvait proposer ce chemin sans en réserver les ressources.

Cette séparation oblige à conserver plusieurs reçus. Il faut d’abord mesurer un état local, puis le représenter et le diffuser. Le destinataire calcule sur une vue déjà datée, filtrée ou agrégée. Il propose une route. Lors de l’établissement, chaque nœud confronte la demande à ses ressources présentes. Un contrôle d’admission supérieur peut encore refuser une route techniquement possible pour des raisons de politique, de priorité, de coût ou d’équité. La réservation modifie ensuite l’état des ressources ; l’observation du trafic dira seulement après coup si le service a été livré.

La carte était indispensable au choix. Elle n’était pas la preuve de l’acceptation.

Mesurer une ressource consommable changeait le système

La disponibilité d’une destination varie peu par rapport à la bande passante libre. Or une route choisie parce qu’elle semble vide cesse précisément de l’être quand les flux s’y déplacent. Si chaque nouvelle mesure provoque immédiatement une nouvelle décision, le trafic peut osciller entre des chemins concurrents. Le document associait ces mouvements à une consommation accrue du plan de contrôle, mais aussi à des variations de délai et de gigue pour les utilisateurs.

La fraîcheur avait donc un coût. Des annonces fréquentes mobilisaient bande passante et cycles de processeur. Des annonces rares laissaient vieillir la carte. Une quantification grossière réduisait le bruit et le volume des mises à jour, au prix de distinctions utiles à l’admission. Un filtre pouvait stabiliser la métrique tout en masquant une surcharge courte mais réelle.

Le seuil de mise à jour devenait ainsi une décision de stabilité. Le RFC définissait également l’épinglage de route : maintenir un flux sur son chemin pendant un certain temps, même si une alternative paraît légèrement meilleure. Cette continuité n’était pas une garantie éternelle ; elle empêchait seulement la carte mouvante de réécrire sans cesse une décision déjà admise.

Plus de précision signifiait plus d’état à perdre

Une décision pouvait porter sur la destination, sur la paire source-destination ou sur chaque flux. La granularité par flux offrait le meilleur ajustement aux exigences particulières, mais elle multipliait les entrées de routage.

Le risque ne se limitait pas à la mémoire. Si un routeur perdait l’état d’un flux et revenait à sa table ordinaire, tandis qu’un autre continuait à utiliser le chemin spécial, les paquets pouvaient boucler entre deux visions incompatibles. L’état détaillé devenait donc une dépendance d’exécution. Savoir calculer une route ne suffisait pas ; il fallait maintenir toutes les décisions de transfert qui lui donnaient corps.

Le réseau gagnait en finesse, mais chaque finesse ajoutait une nouvelle possibilité de désaccord. L’échec n’était plus seulement « aucune route ». Il pouvait être « la moitié du chemin se souvient d’une route que l’autre moitié a oubliée ».

L’agrégation payait l’échelle en incertitude

La hiérarchie permettait de résumer plusieurs liens et chemins internes sous une représentation compacte. Sans elle, la diffusion détaillée ne passerait pas à l’échelle ; avec elle, la précision diminuait.

Le RFC envisageait qu’un flux soit accepté sur la foi d’un résumé, puis qu’aucun chemin concret derrière ce résumé ne puisse satisfaire la demande. L’agrégat n’était pas nécessairement trompeur. Il avait simplement perdu le détail requis par la décision.

Le « crankback » offrait une correction : quand l’établissement se bloquait, il revenait vers un nœud antérieur capable d’essayer une autre route. Cette recherche dynamique rendait l’incertitude explicite. Elle ajoutait toutefois du temps d’établissement et pouvait dégrader les performances sous forte charge. Elle devait donc rester une procédure contrôlée, accompagnée d’admission, non une promesse de trouver indéfiniment une issue.

Deux vitesses de coordination

Le choix architectural majeur du RFC concernait la frontière entre systèmes autonomes. À l’intérieur d’un domaine, le texte encourageait la pluralité : calcul à la demande, routes provisionnées, état de liens, sondes ou autres mécanismes pouvaient évoluer séparément. Entre domaines, l’interaction devait rester simple, cohérente et stable.

Une image interdomaines très dynamique aurait mal passé à l’échelle. Elle aurait exposé des détails que les opérateurs pouvaient vouloir garder privés et transmis à distance une topologie déjà déformée par l’agrégation. Le document préférait des capacités issues de l’ingénierie du réseau, modifiées surtout par des événements exceptionnels tels qu’une panne ou une surcharge concentrée, plutôt que par l’arrivée de chaque flux sous la limite prévue.

Deux horloges coexistaient. Le domaine pouvait réagir vite à sa réalité interne. Ses voisins recevaient un énoncé plus lent de portée, de capacité aménagée et de politique. La couche commune coordonnait des attentes ; elle ne prétendait pas reproduire le réseau intérieur.

Cette retenue protégeait aussi l’autorité locale. L’annonce d’un domaine décrivait ce qu’il pensait pouvoir offrir sous certaines hypothèses. Le routeur d’entrée surveillait encore la demande agrégée et refusait, déclassait ou traitait autrement le surplus. Un calcul distant ne prenait pas possession des ressources parce qu’il avait reçu une métrique.

Le prix révélait l’absence d’une preuve finale

Le RFC imagina que le coût monétaire puisse participer au choix d’une route. Une offre de QoS avait une valeur et les coûts pouvaient se composer au fil des domaines. Mais il posa alors la question décisive : que facturer si la qualité promise n’avait pas été effectivement fournie ?

Une annonce attestait une capacité conçue. Une réservation attestait une allocation. Aucune ne mesurait à elle seule le délai, la perte, la gigue et le débit de bout en bout. Le prix pouvait donc circuler avec plus de certitude que la preuve du service.

La section sur la sécurité rencontrait la même limite. Une demande de ressources ne devait pas s’autoriser elle-même. Sans validation, politique et contrôle, des flux pouvaient épuiser les ressources et priver les autres usagers. Les besoins déclarés étaient une entrée ; l’autorité d’engager la ressource restait ailleurs.

Les mécanismes ultérieurs ont conservé la frontière

Le RFC 2205 avait défini RSVP comme protocole d’établissement de réservations initiées par les récepteurs. Les RFC 2210, 2211 et 2212 reliaient ce signalement aux services intégrés, au service à charge contrôlée et au service garanti. Le RFC 2676 documenta ensuite des mécanismes de routage QoS et des extensions OSPF. Les RFC 3272 et 3630 replacèrent plus tard les attributs de liens et le calcul dans l’ensemble plus vaste de l’ingénierie de trafic.

Ces textes ne démontrent pas un déploiement universel du cadre de 1998. Ils confirment une discipline fonctionnelle. Une annonce apporte des données au calcul. Le calcul propose. La signalisation demande. L’admission décide. La mesure vérifie. Les mécanismes s’assemblent parce qu’aucun ne peut honnêtement tenir lieu de tous les autres.

Le RFC 2386 résumait le routage adaptatif en deux opérations : recueillir l’état, puis calculer des routes à partir de cet état. Son legs se trouve dans les limites posées autour d’elles. L’état dépend de son instant de mesure ; l’annonce dépend de sa portée ; le calcul n’est qu’une hypothèse ; l’admission consulte le présent ; la réservation change la réalité ; le trafic observé tranche.

Le chemin ne devenait réel qu’aux endroits où la carte cessait d’avoir autorité.

Sources