Résumé

  • La RFC 3181 comparait la priorité de préemption d’un nouveau flux à la priorité de défense des réservations déjà admises. Après l’admission, la première valeur ne gouvernait plus le flux : sa propre priorité de défense répondait aux arrivées suivantes.
  • Une réservation multicast fusionnée obligeait à choisir quels rangs conserver. Lier le rang au niveau de service qui dominait la réservation limitait les distorsions ; prendre le rang maximal favorisait les passagers clandestins ; refuser l’hétérogénéité pouvait donner un droit de veto à un seul récepteur.
  • Un objet de politique ou une erreur de préemption attestait une décision signalée, non une réservation installée de bout en bout, un changement effectif du contrôle du trafic, le traitement des paquets ou la continuité de l’application.

La pénurie changeait la règle d’entrée

Publiée en octobre 2001 sur la voie de normalisation, la RFC 3181 remplaça la RFC 2751 et corrigea notamment l’attribution d’un code de type dans les données de politique RSVP. Son objet était le Signaled Preemption Priority Policy Element, utilisable avec RSVP et COPS. Ce statut établit une spécification ; il ne recense aucune mise en œuvre ni aucun opérateur.

Le problème n’apparaissait que lorsque toutes les demandes ne pouvaient pas tenir. Un contrôle fondé uniquement sur la capacité admettait les flux jusqu’à l’épuisement des ressources : l’ordre d’arrivée décidait alors indirectement. Le contrôle fondé sur la politique pouvait classer les demandes. Un nœud compatible pouvait refuser un nouvel arrivant de faible rang ou retirer une réservation plus faible pour faire place à une demande ultérieure de rang supérieur.

La préemption ne créait donc pas de bande passante. Elle déplaçait la pénurie. L’admission réussie du gagnant était simultanément la perte du perdant. Un compte rendu qui ne conservait que la nouvelle réservation transformait une redistribution en gain de capacité imaginaire.

L’élément devait rester simple, sans état propre et assez léger pour être interprété par un point de décision local. « Sans état » signifiait que sa lecture ne réclamait ni historique ni information extérieure. Cela ne supprimait pas l’histoire de l’exploitation : pour comprendre un service, il fallait encore conserver les admissions, les expulsions et l’évolution des ressources.

Le droit d’entrer et le droit de résister

Le format portait deux nombres. La Preemption Priority comparait le nouveau flux aux Defending Priorities des flux déjà admis. Plus la valeur était haute, plus le rang était élevé dans le contexte de politique applicable.

Dès que le flux était admis, sa priorité de préemption devenait sans objet. Sa priorité de défense prenait le relais face aux futurs candidats. Une même réservation possédait donc un rang d’entrée et un rang de survie. Les réduire à une colonne « priorité » détruisait le temps auquel chaque valeur s’appliquait.

Pour un flux donné, la première valeur devait être inférieure ou égale à la seconde. Un écart important pouvait stabiliser la réservation : elle avait du mal à évincer les autres, puis résistait mieux une fois admise. La règle cherchait un compromis entre la tyrannie du premier arrivé et une succession d’évictions.

Cette protection n’était pas éternelle. Une demande future mieux classée pouvait encore l’emporter, la capacité pouvait diminuer et un autre nœud pouvait appliquer une autre correspondance locale. La RFC définissait un ordre relatif, non une hiérarchie universelle entre entreprises, utilisateurs ou usages sociaux.

L’erreur de lecture devient nette dans le temps. « Admis à l’instant A » est un événement passé. « Encore protégé à l’instant B » est une comparaison présente. Le reçu du premier instant ne contient ni les concurrents ni la capacité du second.

La politique changeait de mains

Un Policy Decision Point pouvait condenser les règles pertinentes en un critère. Un Local Decision Point pouvait interpréter, transmettre ou fusionner l’élément dans un nœud qui ne disposait pas d’un décideur central. Un Policy Enforcement Point liait le résultat au contrôle du trafic et au contrôle d’admission.

Cette répartition formait une chaîne de garde. L’autorité de politique produisait le rang. Le décideur local appliquait la stratégie de fusion. Le point d’exécution modifiait un état local. RSVP transportait les objets ; COPS pouvait externaliser la décision. Aucun de ces acteurs n’observait à lui seul la réservation sur tout le chemin ni l’expérience finale de l’application.

La RFC 2750 décrit le conteneur de politique RSVP ; les RFC 2748 et 2749 apportent le contexte COPS et COPS-RSVP. Elles précisent les interfaces, pas l’issue. Recevoir un objet intègre ne prouve ni que la règle d’origine était juste, ni que tous les domaines interprétaient le rang de la même manière, ni que chaque ordonnanceur avait exécuté la décision.

La section de sécurité s’appuyait sur l’intégrité du Policy Data englobant et situait le mécanisme dans une zone de confiance, ou du moins une seule zone. L’enveloppe pouvait protéger les valeurs contre une modification non détectée. Elle ne certifiait pas la fraîcheur de la correspondance politique, la sagesse du choix ou l’effet produit après le point d’exécution.

La fusion prêtait le rang d’un récepteur à un autre

RSVP permettait la fusion de réservations. La RFC posa le cas d’un flux demandant une qualité élevée avec une priorité faible et d’un second demandant une qualité faible avec une priorité élevée. La réservation fusionnée devait fournir la qualité la plus élevée. Quel rang devait-elle porter ?

Adopter la priorité élevée pouvait offrir au premier flux un avantage qu’il n’avait pas acquis : sa qualité coûteuse héritait du rang du petit demandeur. Adopter la priorité faible pouvait priver le second de la protection légitime attachée à sa politique. Le texte montrait ainsi que le passager clandestin et le déni de service sont deux faces d’une même distorsion.

La première stratégie ne retenait que les éléments dont les flux contribuaient au niveau de qualité fusionné, puis prenait le rang le plus élevé parmi eux. Elle était recommandée parce que le demandeur qui déterminait le coût de la réservation déterminait aussi son rang. Elle réduisait un conflit ; elle ne prouvait pas l’absence d’abus.

La deuxième prenait simplement la priorité la plus haute de tous les participants. Elle était facile, mais non recommandée : une petite contribution hautement classée pouvait conférer son rang à une réservation plus coûteuse.

La troisième provoquait une erreur en présence de niveaux de qualité hétérogènes. Elle convenait seulement si l’homogénéité était coordonnée et imposée sur tout l’arbre multicast. Sa rigueur créait son propre levier : un seul récepteur incompatible pouvait faire échouer les autres.

Il n’existait pas de compression neutre entre stratégies. La RFC ne connaissait aucun algorithme capable de fusionner des éléments issus de stratégies différentes sans perdre une information utile à d’autres nœuds. Et lorsqu’une enveloppe d’intégrité protégeait l’objet, le décideur local ne devait pas le modifier. Résumer le rang supposait donc de connaître à la fois les contributeurs, la stratégie et la frontière de sécurité.

Le message de préemption ne racontait pas la suite

Le code PREEMPTION signalait qu’un flux auparavant admis avait été évincé. Le code HETEROGENEOUS signalait la rencontre d’une fusion incompatible. Dans le premier cas, une copie de l’élément du vainqueur repartait vers le décideur qui avait produit celui du perdant. Disposant des deux rangs, il pouvait tenter de rétablir le flux avec une valeur plus forte.

Ce retour rendait la compétition explicite. Il ne prouvait pas que l’application perdante avait reçu l’avis, cessé d’émettre, libéré toutes ses ressources ou récupéré proprement. Il ne prouvait pas non plus que le gagnant avait obtenu une réservation sur chaque nœud du chemin.

La tentative de rétablissement pouvait devenir une oscillation. Le document avertissait que la priorité, une réservation « tueuse » et l’état de blocage RSVP pouvaient produire une alternance d’éviction et de réadmission. Compter chaque admission comme un succès récompensait alors l’instabilité. Le temps de résidence et le nombre d’interruptions étaient plus révélateurs.

L’erreur d’hétérogénéité avait elle aussi un champ limité. Elle disait qu’une composition particulière violait la définition locale de l’homogénéité des FLOWSPEC. Elle n’affirmait pas qu’aucun autre chemin, aucun autre niveau de qualité ou aucune autre décision applicative n’était possible.

Le registre et les textes ultérieurs restaient des indices distincts

La RFC attribua la valeur de type de l’élément. Le registre IANA actuel peut confirmer cette coordination. Une ligne du registre ne voit pas si un routeur reconnaît la valeur, si un décideur l’émet, si le contrôle du trafic l’applique ou si l’application reçoit un service utile.

Les extensions RSVP-TE ultérieures et la RFC 6401 sur la priorité d’admission inscrivent le mécanisme dans une histoire plus longue. Elles ne prouvent aucune utilisation de la RFC 3181 et leurs comportements ne doivent pas être projetés sur l’élément de 2001.

Il en va de même du statut Standards Track. Les sources ne nomment aucun réseau actuel, aucune classe de trafic, aucun appel d’urgence, aucun taux d’admission ni aucun résultat d’application. La spécification décrit ce qui devait être comparé, pas ce qui s’est produit quelque part.

Un registre de décision devait conserver le perdant

Une trace vérifiable commence par le flux, la qualité demandée, l’origine de politique, le contexte d’intégrité et les deux priorités. Elle enregistre les nœuds et rôles qui interprètent ou fusionnent, la stratégie choisie, la capacité et les concurrents au moment de la décision, puis l’admission ou l’éviction.

En cas de fusion, elle conserve les récepteurs qui ont contribué à la qualité et les éléments qui ont participé au rang. En cas de préemption, elle relie le nouveau flux à la réservation perdante, à l’erreur renvoyée, au retrait dans le contrôle du trafic et à toute réadmission. Elle ne remplace pas les épisodes antérieurs par le dernier état.

La réservation de chemin, le traitement des paquets et la réaction de l’application viennent ensuite, comme observations indépendantes. Le rang guide un choix sous contrainte. Il ne crée pas la ressource, ne certifie pas l’exécution et ne parle pas au nom du service.

La distinction des deux priorités conserve ainsi une leçon rare : l’autorité qui ouvre une porte n’est pas forcément celle qui la garde ouverte. Une bonne preuve nomme le moment, les concurrents, le décideur, l’exécutant et la conséquence au lieu de transformer un nombre en promesse permanente.

Sources et limites

Le statut, les deux priorités, les rôles, les stratégies de fusion, les erreurs, l’enregistrement et la sécurité sont documentés dans le texte de la RFC 3181, sa notice RFC Editor, son édition HTML, son historique IETF et la recherche d’errata. La comparaison de version est limitée par le texte de la RFC 2751 et sa notice.

Les interfaces voisines viennent de RSVP, des extensions de contrôle de politique RSVP, de COPS et de COPS pour RSVP. Le contexte ultérieur est borné par RSVP-TE, la priorité d’admission RSVP et le registre IANA des paramètres RSVP.

La séparation analytique entre rang, exécution et résultat observé est informée par les essais de Lu Heng sur la primauté du code exécuté, les couches de réalité et la spécification initiale minimale. Les dix-sept sources ont été figées le 2 octobre 2026, heure de Shanghai.

Ces sources prouvent une spécification et son contexte, non son déploiement ni son résultat. Elles n’identifient aucune mise en œuvre actuelle, aucun fournisseur, opérateur, flux, incident, attaque, gain de capacité, traitement de paquets ou effet de service. Les valeurs sont relatives à une politique applicable, pas des rangs sociaux ou commerciaux universels. La chaîne de preuve est l’analyse éditoriale de Sofia Ren, non une déclaration de l’auteur de la RFC, de l’IETF, de l’IANA ou de Lu Heng.