Résumé

  • RFC 2215 distinguait la valeur locale d’un élément de réseau de la valeur progressivement composée sur le chemin ; la caractérisation était, par principe, liée au prochain saut.
  • Une rupture se propageait par OU, le nombre de sauts augmentait, la bande passante et le MTU retenaient le minimum, tandis que la latence minimale s’additionnait jusqu’à une valeur indéterminée.
  • Le résultat décrivait un chemin sous conditions. Il ne prouvait ni réservation, ni admission, ni performance observée, ni livraison à l’application.

Un format commun ne produisait pas un sens commun

À l’arrivée d’un message de signalisation, un routeur pouvait recevoir plusieurs faits sur le chemin déjà parcouru. L’un indiquait qu’un élément ne savait pas fournir le service demandé. Un autre comptait les participants conformes. Deux autres décrivaient une ressource limitante et une latence accumulée.

RFC 2215 refusait de leur appliquer une opération unique. Une seule rupture suffit à invalider la continuité : elle exige un OU logique. Un participant doit ajouter une unité. Une ressource de goulot ne peut qu’être maintenue ou réduite. Un délai, lui, s’ajoute. L’algèbre appartenait donc à l’affirmation, pas à l’enveloppe qui la transportait.

Ces paramètres caractérisaient l’environnement de contrôle QoS avant qu’une demande précise n’ait nécessairement été admise. Ils pouvaient guider le choix d’un service. Ils ne constituaient pas le compte rendu d’un service déjà exécuté.

La provenance commençait par le prochain saut

Chaque paramètre possédait une valeur locale et une valeur composée. La première décrivait un élément ; la seconde réunissait le chemin antérieur et la contribution locale, puis repartait vers le nœud suivant. La composition pouvait avancer vers le récepteur ou remonter vers l’émetteur.

Le texte qualifiait ces valeurs de per-next-hop. Dans un média partagé ou un grand nuage, deux sorties pouvaient justifier deux valeurs. Réduire cette information à une propriété permanente de l’équipement ferait disparaître le choix de chemin dont elle dépendait. Une seule valeur n’était acceptable que sous une tolérance documentée.

Les identifiants des valeurs locales et composées étaient distincts. Cette séparation permettait d’inspecter ce qu’un nœud avait fourni et ce que le chemin affirmait à cet instant. Une fois les entrées perdues, un minimum ne révèle plus le goulot, une somme ne révèle plus ses termes et un drapeau ne localise pas la rupture.

La valeur par défaut restait une branche

Le numéro de service 1 représentait la valeur globale. Un service particulier pouvait annoncer une valeur de remplacement. La règle de priorité suivait la branche : une valeur propre au service rencontrait l’override local s’il existait, sinon la valeur globale locale. Une valeur globale arrivant sur un nœud doté d’un override créait une branche supplémentaire, sans supprimer la branche globale.

Le cas du MTU montre l’enjeu. Un routeur pouvait transporter 1 500 octets en acheminement ordinaire, mais une implémentation de Guaranteed Service être limitée à 250 octets. La seconde valeur ne redéfinissait pas le support physique ; elle fixait une limite plus stricte pour ce service. Fusionner les deux nombres détruirait l’une des deux vérités.

Une rupture ne s’effaçait plus

Le paramètre NON_IS_HOP prenait la valeur vraie lorsque l’élément ne fournissait pas le service pertinent, ou savait qu’une discontinuité existait. Sa forme composée utilisait le OU. Une fois le drapeau levé, aucun nœud ultérieur ne pouvait le remettre à faux.

Le calcul devait être conservateur. À l’entrée d’un tunnel, il fallait présumer l’absence de contrôle QoS à l’intérieur, sauf preuve contraire. Or le dispositif non conforme ne savait justement pas renseigner un champ qu’il ne comprenait pas. La détection pouvait donc appartenir au voisin, au protocole de signalisation ou à la configuration. Le drapeau n’était pas un aveu authentifié du nœud manquant.

Une rupture globale rendait les autres paramètres potentiellement inexacts. Une rupture propre à un service fragilisait les paramètres de ce service. RFC 2210 expliquait le transport de ce break bit dans ADSPEC ; la réussite du transport ne guérissait pas l’incertitude signalée.

Compter les participants ne comptait pas les absents

NUMBER_OF_IS_HOPS augmentait d’une unité à chaque élément averti. Il disait combien de contributeurs connus avaient participé. Il ne disait pas combien d’éléments physiques ou logiques existaient en tout.

Le compteur et le drapeau de rupture devaient être lus ensemble. Un nœud ignorant Integrated Services ne pouvait s’ajouter au compteur. Cinq contributeurs et un chemin de cinq sauts ne sont donc pas des propositions équivalentes. L’absence d’inscription ne devient pas une preuve d’absence.

La bande passante était le minimum d’estimations préalables

La valeur locale de bande passante devait tenir compte des ressources physiques, de l’administration et de la politique. La composition retenait le minimum. Le résultat identifiait la plus petite disponibilité annoncée, sans dire où elle se trouvait.

Mais l’entrée n’était pas une réservation. Le RFC exigeait cette estimation avant une demande QoS déterminée, quand la destination, le service et certaines politiques de réservation pouvaient être inconnus. Une surestimation importante restait admise lorsqu’une meilleure réponse était impossible. Un service restreint à une portion de la capacité pouvait publier un override plus faible.

Zéro signifiait « inconnu », non « aucune bande passante ». Comme le minimum de zéro et d’une valeur positive demeure zéro, l’ignorance survivait aux nœuds suivants. Une précision tardive n’avait pas le droit de blanchir la lacune antérieure.

La latence minimale finissait par saturer

La latence locale désignait le plus petit délai de propagation et de traitement, hors attente variable en file. Elle pouvait compléter le Guaranteed Service de RFC 2212, mais n’était ni une mesure ordinaire, ni sa borne C/R + D.

Un nuage à plusieurs issues devait idéalement produire une valeur par prochain saut. Une valeur commune devait retenir le plus petit chemin possible et risquait donc de sous-estimer le trajet réel. L’élément pouvait aussi répondre « indéterminé ».

Les microsecondes s’additionnaient, avec saturation à (2**32)-1. Ce nombre distingué signifiait que la vraie latence était inconnue : soit une contribution manquait, soit la plage numérique avait débordé. La somme bornée maintenait ce statut. Elle n’inventait pas une très grande mesure exacte.

Le MTU partageait le minimum, pas la même qualité de preuve

Le MTU local était la plus grande taille de paquet IP transportable sans fragmentation, en comptant les en-têtes IP et supérieurs mais pas les en-têtes de liaison. Le minimum donnait le plafond du chemin. Contrairement à la bande passante, chaque élément averti devait fournir une valeur correcte.

Un service pouvait réduire le MTU global, jamais l’augmenter. Pourtant, le résultat restait attaché à une route et à une branche de service. Il ne prouvait pas qu’un paquet avait été émis, que tous les tunnels avaient été décrits, que la route n’avait pas changé ou que la livraison avait réussi.

Le TSpec traçait une autre frontière

Le même RFC définissait le token-bucket TSpec, paramètre 127. Celui-ci décrivait le trafic attendu, mais les nœuds intermédiaires n’en exportaient pas une valeur locale à composer. Sa présence dans le document n’en faisait pas une cinquième algèbre de chemin.

Un contrat de trafic et une caractérisation pouvaient partager l’architecture tout en prouvant des faits différents. Un TSpec ne mesurait pas la conformité réelle et ne démontrait ni admission ni traitement.

Une caractérisation restait au milieu de la chaîne

RFC 1633 décrivait l’architecture, RFC 2205 RSVP, RFC 2210 le transport des objets, RFC 2211 et RFC 2212 les services, et RFC 2216 le modèle de spécification. Aucun de ces niveaux ne transformait automatiquement la caractérisation en résultat.

Une piste vérifiable conserve séparément l’identifiant, la branche globale ou spécifique, le prochain saut et l’époque de route, la source locale, la règle de composition, l’état inconnu, la demande, l’admission, l’état installé, les observations de paquets et l’effet applicatif. Le dernier nombre n’est pas la totalité de cette histoire.

Sources et limites

La source principale est RFC 2215, avec les notices du RFC Editor et de l’IETF Datatracker. RFC 2815 montre une application ultérieure aux réseaux IEEE 802 : MTU et ruptures devaient être exacts, tandis que la bande passante pouvait rester très approximative. Ces textes n’établissent ni déploiement actuel, ni produit, ni performance mesurée, ni incident.

Les essais de Heng Lu sur la primauté du code exécuté, la spécification minimale et la décision locale et les couches de réalité servent de grille éditoriale : une déclaration bien formée guide l’action, mais ne l’exécute pas. Cette grille n’est pas une causalité historique attribuée à RFC 2215.