Résumé

  • Une région d’agrégation pouvait masquer les messages RSVP de bout en bout aux routeurs intérieurs et transporter plusieurs réservations dans un agrégat associé à un DSCP. L’économie concernait l’état du cœur, pas la preuve d’admission de chaque flux.
  • Le désagrégateur choisissait l’agrégat, renvoyait le DSCP par DCLASS et ajoutait le token bucket du flux à sa comptabilité. L’agrégateur classait et marquait ensuite les paquets : aucune de ces étapes ne remplaçait les autres.
  • Le dimensionnement prédictif laissait volontairement une marge entre capacité réservée et somme utilisée. Un message RSVP-E2E-IGNORE mal dirigé pouvait en outre disparaître silencieusement. Il fallait donc joindre les reçus des deux bords aux observations du cœur et du trafic.

La précision par flux coûtait de la mémoire partout

RSVP savait décrire une demande individuelle, mais chaque demande imposait échange de messages, calcul et état à chaque routeur participant. Dans un réseau chargé, cette fidélité liait les ressources du cœur au nombre de conversations des extrémités.

La RFC 3175 changeait la répartition de l’information. Des réservations traversant le même point d’entrée et le même point de sortie pouvaient partager une réservation plus grande. Le premier routeur devenait agrégateur, le dernier désagrégateur ; entre eux, les routeurs n’avaient plus à reconstruire le dossier complet de chaque flux.

L’idée n’était pas d’abolir le service de bout en bout. Elle consistait à réduire l’état obligatoire dans la partie commune du réseau. La dette de précision restait aux bords, là où la demande individuelle pouvait être rapprochée du bloc partagé.

Le numéro 134 organisait une ignorance limitée

Pour empêcher les routeurs intérieurs de traiter un Path de bout en bout, l’agrégateur remplaçait le numéro de protocole RSVP par RSVP-E2E-IGNORE. Le registre IANA lui attribue la valeur 134. Le désagrégateur devait reconnaître le message à la sortie, restaurer RSVP et reprendre le dialogue de bout en bout.

Ce changement de champ ne faisait pas disparaître le flux ; il disait seulement quels routeurs ne devaient pas installer son état. La distinction était fragile. Si aucun désagrégateur correctement configuré ne reprenait le message, celui-ci pouvait traverser la région puis être ignoré par la destination. L’intérieur avait fait exactement ce qu’on lui demandait, tandis que la réservation échouait.

La réduction d’état exigeait donc un reçu à la frontière. Le silence du cœur était prévu. Le silence du désagrégateur ne l’était pas. Sans corrélation entre le Path entré et le Path récupéré, l’absence d’erreur ne prouvait rien.

Le DSCP indiquait une classe, non un droit acquis

Dans la région, les DSCP identifiaient le trafic couvert par un agrégat et les PHB indiquaient le traitement par saut. Plusieurs réservations Guaranteed Service pouvaient rejoindre une classe et des réservations Controlled Load une autre. La politique de mappage restait locale à l’opérateur.

La décision revenait au désagrégateur, qui voyait le Resv du récepteur et son type de service. Il communiquait le DSCP choisi dans DCLASS. L’agrégateur enregistrait l’association, retirait DCLASS du Resv envoyé vers l’amont et marquait les paquets correspondants.

Un bit de classe observé ne prouve pourtant ni l’identité du demandeur ni son admission. DCLASS atteste qu’un message portait un choix ; il ne montre pas que le classificateur a reconnu le bon trafic. Un DSCP correct ne montre pas que chaque ordonnanceur disposait de la ressource. Le traitement par saut ne montre pas le résultat reçu par l’application.

L’admission restait un calcul au bord de sortie

Lorsque l’agrégat avait assez de bande passante, le désagrégateur pouvait renvoyer le Resv de bout en bout et ajouter le token bucket à son état d’utilisation. Cette addition était le reçu que le grand bloc ne pouvait fournir seul.

L’existence d’un agrégat de grande taille ne signifiait pas qu’une nouvelle demande y entrait automatiquement. Il fallait identifier la bonne session, connaître les engagements déjà comptés, appliquer la politique et vérifier la marge. L’absence de Resv agrégé exigeait sa création ; une capacité insuffisante exigeait un agrandissement ou une réponse qui ne feignait pas l’admission.

Le cœur pouvait donc posséder un nombre d’états presque indépendant du nombre de flux, tandis que les bords conservaient une relation un-à-un. L’économie venait de cette asymétrie, non d’un effacement universel.

La prévision empêchait l’agrégat de suivre chaque mouvement

Redimensionner à chaque arrivée ou départ aurait réintroduit les coûts de signalisation. La RFC discutait des blocs supérieurs à la somme instantanée, révisés à intervalles plus espacés. Les cycles horaires et la tendance récente pouvaient alimenter l’estimation. Une granularité fine économisait de la capacité mais multipliait les changements ; une granularité large créait de la marge et du risque d’erreur.

Le document ne définissait pas un algorithme universel. Cette liberté reconnaissait les différences de trafic et d’objectifs. Elle obligeait cependant à séparer la prévision, la capacité configurée, la capacité encore admissible et la qualité observée. Un modèle statistique n’est pas une file d’attente. Une file configurée n’est pas une réservation individuelle. Une réservation acceptée n’est pas une livraison.

L’agrégation agrandissait aussi le rayon des fautes

Partager la classe réduisait l’isolation stricte : les rafales d’un flux pouvaient influencer un autre flux. La RFC citait des résultats favorables dans certains scénarios de délai, mais ces résultats ne décrivent pas une implantation inconnue. Il faudrait connaître la topologie, les files, le mélange de trafic et la méthode de mesure.

Une panne ou une capture de l’agrégat pouvait affecter de nombreux appels. Une sur-réservation pouvait priver d’autres classes. Un mauvais classificateur pouvait offrir le traitement protégé au mauvais trafic. Moins d’objets de contrôle signifiait davantage de conséquences par objet.

L’intégrité cryptographique demeurait elle aussi bornée. Agrégateur et désagrégateur devenaient voisins RSVP logiques pour les messages cachés, tandis que l’agrégat utilisait des relations saut par saut dans la région. Un digest valide prouvait la possession de la clé configurée et l’intégrité du message, non la justesse du mappage, la capacité ou la livraison.

Les extensions ultérieures montrent ce qui n’était pas comprimé

RFC 4804 adapta l’agrégation aux tunnels MPLS TE et DS-TE. RFC 4860 ajouta des agrégats génériques afin d’autoriser plusieurs réservations partageant source, destination et PHB, limite du modèle RFC 3175. RFC 5350 révisa les considérations IANA du Router Alert. Les registres conservent le protocole 134 et les C-Types IPv4/IPv6.

Ces traces prouvent une histoire normative. Elles ne constituent ni un inventaire d’équipements ni une mesure d’usage. L’enseignement durable est ailleurs : quand le réseau commun supprime un détail, l’autorité qui agit sur ce détail doit rester identifiable et son résultat vérifiable.

Les notes de Lu Heng sur le code en fonctionnement et les couches de réalité éclairent ce partage sans faire partie du RFC. Le minimum interopérable peut rester mince, mais la politique locale, l’état enregistré, l’exécution et le résultat économique ne deviennent pas une seule vérité. L’agrégation réduit l’état ; elle ne réduit pas le nombre de preuves nécessaires.

Sources et limites

Les preuves ont été gelées le 2 octobre 2026, heure d’Asie/Shanghai. Elles établissent le mécanisme de RFC 3175, les allocations IANA et l’évolution normative. Elles n’établissent aucune adoption, implantation nommée, économie d’état mesurée, performance actuelle, panne, conduite d’opérateur ou qualité applicative livrée.