Résumé

  • Le RFC 9938 décrit un plan contrôleur DetNet capable de recevoir une demande, de calculer des chemins admissibles, d’en choisir un dit optimal et d’installer les comportements nécessaires. Or l’optimalité dépend d’un ordre préalablement autorisé entre délai, pertes, gigue, bande passante, protection, risques communs et coexistence avec les autres trafics.
  • Une preuve complète exige un reçu de propriété des contraintes : identité et durée de la demande, version des objectifs, personne habilitée à arbitrer, budget de ressources, engagements de chaque domaine, état des mesures, déclencheurs de réexamen, expiration des exceptions et responsable de la libération—sans publier la topologie ni le sens opérationnel du flux.

Une réservation qui survit à sa raison d’être

Le scénario le plus révélateur ne commence pas par une panne. Il commence par un service qui s’est terminé. Le flux n’est plus nécessaire, mais sa réservation subsiste. Les paquets d’un autre service se présentent ; le contrôleur ne peut pas leur accorder les ressources encore immobilisées. Tout fonctionne conformément à l’état installé, et c’est précisément le problème.

Le RFC 9055 décrit ce risque sous l’angle de la sécurité : un démontage retardé peut provoquer une fuite de ressources et empêcher l’allocation de nouveaux flux. On peut aussi lire ce cas comme une question de gouvernance. Qui avait fixé la durée ? Qui devait constater sa fin ? Qui pouvait prolonger l’exception ? À quel moment l’obligation de continuité s’est-elle transformée en occupation indue ?

Un algorithme ne répond pas à ces questions en recalculant plus vite. Il lui manque la règle qui rend la contrainte légitime.

Cette observation éclaire l’expression « chemin optimal ». Le mot semble décrire le résultat d’une formule. En réalité, il décrit d’abord une hiérarchie de valeurs. Le chemin qui minimise la latence n’est pas celui qui économise le plus de bande passante. Celui qui évite un groupe de risques communs peut mobiliser deux branches et des fonctions de réplication. Celui qui protège un flux déterministe peut réduire la marge laissée aux paquets non-DetNet.

Avant de lancer le calcul, une institution doit donc définir ce qui compte, ce qui est impératif, ce qui reste négociable et qui supporte le coût de l’arbitrage. Le contrôleur exécute cette politique ; il ne la rend pas légitime par son exécution.

Le cadre ne prétend pas résoudre ce partage des rôles

Le RFC 9938, publié en mars 2026, est un document IETF de catégorie Informational. Il rassemble les concepts et exigences du plan contrôleur de Deterministic Networking et pourrait servir de base à de futures spécifications de solution. Il précise qu’il ne fournit pas ces protocoles.

Cette limite est importante. Le document ne promet pas un contrôleur universel ni une méthode unique d’optimisation. Il décrit les fonctions dont une automatisation DetNet peut avoir besoin : création, modification et suppression dynamiques de flux, détermination de chemins explicites, réservation de bande passante et de mémoire tampon, discipline de file, agrégation, allocation d’étiquettes, fonctions de réplication-élimination-remise en ordre, collecte des capacités et surveillance du service.

Le terme « plan contrôleur » réunit en outre des fonctions souvent séparées entre plan de contrôle et plan de gestion. Les premières installent et maintiennent les flux. Les secondes configurent, observent les performances, détectent des anomalies et participent à l’administration. Cette agrégation architecturale ne signifie pas que toutes les décisions appartiennent à la même personne ou au même mandat.

Une demande peut venir d’une application via une API, d’un provisionnement statique, d’un contrôleur SDN ou d’un protocole distribué. Cela ouvre plusieurs chemins techniques pour exprimer l’intention. Cela ne répond pas à la question de savoir si chaque émetteur peut engager la même quantité de ressources, traverser les mêmes domaines ou dégrader les mêmes garanties.

Le cadre a raison de laisser ces politiques aux environnements qui l’emploient. L’erreur apparaîtrait plus tard, si un exploitant confondait la capacité d’accepter un message avec la preuve de l’autorité qui le fonde.

Une liste de paramètres n’est pas encore un arbitrage

Dans l’exemple centralisé du RFC 9938, le contrôleur recueille la topologie et les capacités, reçoit une demande d’établissement, calcule un ou plusieurs chemins valides, choisit le chemin optimal, puis configure les équipements. La séquence est claire. Le passage délicat se trouve entre la demande et le choix.

Le modèle d’information du RFC 9016 permet d’exprimer le profil d’un flux et le service attendu. Le RFC 9938 rappelle que la spécification de trafic représente un cas défavorable plutôt qu’une moyenne. Ces données sont indispensables à l’admission. Elles ne portent pas automatiquement le statut institutionnel de chacune de leurs valeurs.

Un délai maximal peut être une obligation contractuelle, une limite physique de l’application ou une préférence prudente ajoutée par défaut. Une exigence de deux chemins disjoints peut protéger une fonction critique ou provenir d’un modèle copié. Un budget de bande passante peut représenter un pic démontré ou une marge généreuse jamais réexaminée. Deux fichiers identiques peuvent donc exprimer des décisions très différentes selon la source et la date de leurs contraintes.

La distinction entre contrainte dure, préférence souple et indicateur de surveillance ne relève pas de la décoration. Si toutes les valeurs deviennent dures, le système refuse inutilement des chemins. Si toutes deviennent négociables, le service perd le sens de ses garanties. Si une mesure ancienne est traitée comme actuelle, le résultat peut être parfaitement reproductible et néanmoins inadapté au réseau du moment.

YANG, NETCONF, PCE ou BGP-LS peuvent transporter et appliquer des informations fiables. Aucun de ces mécanismes ne peut deviner pourquoi une valeur a été choisie ni qui avait le droit de l’imposer. Un champ correctement encodé reste une assertion ; il ne devient pas, par sa syntaxe, une délégation.

L’optimum d’un flux dépense les possibilités des autres

Le plan de transfert DetNet combine chemins explicites et allocation de ressources. Le RFC 8938 explique que des ressources peuvent être réservées afin d’éviter la contention, les pertes et la gigue pour un flux déterministe. Il indique aussi que le « meilleur » chemin peut viser la plus grande bande passante, la plus faible gigue ou plusieurs métriques, et qu’il n’est pas forcément le plus court.

Cette pluralité détruit l’idée d’un optimum absolu. On peut calculer un classement exact seulement après avoir défini la fonction de classement. Le choix engage alors des ressources qui cessent d’être librement disponibles.

La protection ajoute un exemple concret. La réplication peut envoyer plusieurs exemplaires sur des routes séparées afin qu’une défaillance n’interrompe pas le service. Le bénéfice est réel, mais la consommation aussi. Bandes passantes, files, mémoire et traitement sont sollicités sur plusieurs branches. Accorder ce niveau de protection à un flux peut empêcher un second flux d’obtenir le sien.

Le RFC 8655 insiste sur la coexistence. Un domaine peut consacrer une forte proportion de sa capacité aux flux DetNet, mais il doit éviter d’affamer le trafic non-DetNet. Il recommande de laisser suffisamment d’occasions de transmission aux autres paquets. Il traite comme une faute l’envoi de trafic déterministe vers un réseau qui n’a pas été provisionné pour le recevoir, en incluant parmi les formes de provisionnement une décision administrative sur la capacité disponible en aval.

Le mot administratif compte. La capacité n’est pas uniquement constatée ; elle est engagée. La gouvernance doit conserver la trace de l’acteur habilité à faire cet engagement, de la population protégée contre ses effets et de la durée pendant laquelle l’arbitrage reste valable.

Centralisé, distribué ou hybride : trois lieux de preuve

Le RFC 9938 présente trois familles d’architecture. Dans le mode distribué, l’information issue de l’interface utilisateur-réseau circule et les nœuds participent au calcul ou à la signalisation. Dans le mode centralisé, un contrôleur rassemble une vue plus globale et configure les équipements. Dans le mode hybride, le calcul central et la signalisation distribuée coopèrent.

Aucune forme n’annule le problème de mandat ; chacune le découpe autrement.

Dans un système distribué, le nœud d’entrée peut initier un chemin et chaque nœud admettre localement une réservation. Il n’existe pas nécessairement un journal central qui contienne la raison complète. Il faut alors pouvoir joindre la demande initiale, les décisions locales et le résultat de bout en bout sans prétendre que chaque nœud connaissait tout.

Dans un système centralisé, une seule identité logique peut produire le calcul et les configurations. Cette unité facilite la corrélation technique. Elle augmente aussi le risque de confondre puissance et autorité. Un contrôleur disposant d’un droit général de configuration peut servir plusieurs métiers, plusieurs classes de priorité et plusieurs propriétaires. Son certificat ne dit pas quelle demande doit l’emporter.

Dans un système hybride, le calcul peut être cohérent et la signalisation également valide, tout en reposant sur deux versions différentes de la topologie ou des contraintes. Une ressource peut être disponible au moment du calcul puis refusée pendant l’admission. Un nœud peut accepter un substitut que le calcul central n’avait pas qualifié. La preuve doit porter sur les versions, pas seulement sur la réussite de chaque protocole.

L’architecture choisit où se déroulent les actes. La politique doit préciser qui répond de leur cohérence.

Chaque domaine promet un segment, pas une abstraction globale

Le passage consacré aux environnements multidomaines est bref mais décisif. Plusieurs Controller Plane Functions peuvent devoir coopérer pour transformer la demande du Flow Management Entity en comportements par flux et par saut. Ils peuvent se découvrir, s’authentifier et négocier. Le plan applicatif peut aussi répartir lui-même certaines responsabilités.

L’authentification évite qu’un inconnu se présente comme contrôleur. Elle ne suffit pas à établir la portée du mandat du contrôleur reconnu. Un pair authentique peut être autorisé à demander une classe de service mais pas à doubler le budget, prolonger l’intervalle ou modifier la protection. Une négociation réussie peut définir un comportement local sans garantir que tous les domaines attribuent le même sens au délai, à la mesure ou au moment de libération.

Un reçu multidomaine utile doit donc être composable. Chaque opérateur peut conserver sa topologie et ses calendriers sensibles tout en attestant un sous-ensemble : version des contraintes acceptées, classe de ressources engagée, période, preuve d’activation, condition de réexamen et événement de libération. Le service de bout en bout peut vérifier l’enchaînement de ces engagements sans obtenir le tracé interne.

Cette approche respecte l’autonomie. Elle permet aussi la correction. Si un domaine retire un engagement, si une métrique devient périmée ou si une route cesse d’être disjointe, le reçu global doit changer d’état. Remplacer silencieusement le chemin peut maintenir les paquets tout en rompant la promesse qui justifiait la route initiale.

Une commande authentique peut excéder sa délégation

Le RFC 9055 analyse les menaces sur le plan contrôleur. La modification ou l’injection de messages peut détourner les chemins et les allocations. Un contrôleur compromis peut paraître légitime aux nœuds. L’usurpation peut modifier la bande passante, ajouter ou supprimer des extrémités, faire disparaître des flux ou en créer de faux jusqu’à l’épuisement des ressources.

Ces risques imposent authentification, intégrité, protection des messages et conception résistante. Ils montrent aussi pourquoi l’audit ne doit pas s’arrêter à « signature valide ».

Supposons que le contrôleur ne soit pas compromis. Son identité est correcte, son certificat actuel et sa commande intacte. La réservation peut tout de même être hors mandat : plafond dépassé, durée expirée, domaine non approuvé, duplication non autorisée ou objectif ancien. Changer la clé du contrôleur ne réparera pas cette erreur. Le calcul peut être fidèle et la commande authentique ; c’est la délégation particulière qui manque.

À l’inverse, consigner toutes les routes, horaires, quantités exactes et finalités industrielles créerait une ressource de reconnaissance. Le RFC 9055 avertit que le nombre de flux, leur bande passante et leur calendrier peuvent révéler une intention opérationnelle. La preuve de gouvernance doit donc être sélective : assez détaillée pour vérifier le mandat, pas assez pour reconstruire le système sensible.

La mesure doit avoir un propriétaire et une date

Le plan de gestion surveille les performances et la connectivité. Le RFC 9938 distingue la mesure active, qui injecte des paquets et peut perturber le délai ou le débit, de la mesure passive, préférable en exploitation. Le RFC 9551 approfondit l’OAM de DetNet.

L’origine d’une métrique fait partie de sa signification. Une valeur issue d’un essai de mise en service ne devrait pas devenir silencieusement la vérité permanente. Une observation passive trop ancienne peut être insuffisante pour une décision sensible. Une moyenne stable peut masquer une violation rare d’un maximum.

Le reçu doit relier chaque contrainte mesurée à sa fenêtre, sa méthode, sa fraîcheur et son seuil de confiance. Si la contrainte dépend de la disjonction de risques, il faut surveiller ce fait. Si une exception autorise temporairement une protection réduite, l’expiration doit provoquer une nouvelle décision. Si la suppression d’un flux échoue, l’occupation résiduelle doit être attribuée et corrigée.

La surveillance n’est pas un verdict posé après le calcul. Elle détermine quand le calcul cesse de représenter la décision approuvée.

Ce que prouve réellement le calcul

Avec des entrées figées, un calcul reproductible peut démontrer que certains candidats satisfaisaient les contraintes exprimées, qu’un algorithme déterminé les a classés de telle manière et que le chemin retenu arrivait en tête. Les preuves d’installation peuvent montrer quels nœuds ont reçu la configuration. L’OAM peut décrire le comportement pendant un intervalle.

Ces éléments ne prouvent pas à eux seuls :

  • que le demandeur possédait l’objectif du service ;
  • que la version utilisée était encore en vigueur ;
  • qu’une préférence souple n’a pas été transformée en obligation ;
  • que le coût en ressources respectait le plafond autorisé ;
  • que la réplication ou la mémoire supplémentaire était justifiée ;
  • que le plancher réservé au trafic non-DetNet a été respecté ;
  • que tous les domaines avaient accepté le même sens de bout en bout ;
  • qu’une dégradation avait une date de fin ;
  • que les ressources ont été libérées après la fin du mandat.

La précision du calcul ne doit pas être diminuée. Elle doit être replacée dans son domaine de preuve.

Le reçu de propriété des contraintes

Le contrôle complémentaire peut rester compact. Il commence par une empreinte stable de la demande, l’identité fonctionnelle du demandeur, le propriétaire du service, la frontière du Flow Management Entity et l’intervalle demandé. Il joint cette identité à une version des contraintes.

Pour chaque contrainte, il indique la source et le statut : dure, souple ou destinée à la surveillance. Il distingue une bande passante de pointe réservée d’une moyenne observée, une limite de délai d’un objectif, une disjonction obligatoire d’une préférence. Il conserve le plancher de coexistence qui protège les autres trafics.

Il nomme ensuite l’autorité de décision : qui peut classer les préférences, approuver un plafond, accepter un mode dégradé, engager un domaine supplémentaire et ordonner le démontage. Cette portée ne doit pas être déduite d’un compte administrateur général.

La partie calcul peut utiliser des empreintes : instantané topologique et fraîcheur, version de l’algorithme, ensemble de candidats, chemin retenu, raisons de rejet et incertitude. Le vérificateur n’a pas besoin de lire la topologie brute pour constater que le processus autorisé a été suivi.

Chaque domaine ajoute enfin un jeton d’engagement local et les informations de cycle de vie : activation, classe de ressources, période, fenêtre d’OAM, déclencheurs, exception, retour arrière, responsable de libération et état de correction. Une nouvelle preuve remplace l’ancienne par un lien explicite ; elle ne réécrit pas le passé.

Limites de preuve

Les RFC cités ne documentent ni panne réelle ni mauvaise décision d’un produit nommé. Ils ne mesurent pas l’adoption de DetNet, la rareté actuelle d’une capacité, la fréquence d’un contrôleur compromis ou la qualité d’un opérateur. Ils établissent un cadre, des modèles, des propriétés de sécurité et des considérations d’exploitation.

Le reçu proposé n’est pas une exigence de l’IETF. Il applique à l’optimisation une règle de responsabilité : séparer ce que le protocole peut démontrer de la décision institutionnelle qui lui donne un but.

Le conseil opérationnel tient en une phrase. Protéger le contrôleur, vérifier son calcul et observer le service restent indispensables. Mais aucun de ces actes ne dispense de conserver qui avait le droit de dire ce que « optimal » devait signifier.

Sources

  1. https://heng.lu/the-policy-mirror/
  2. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  3. https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
  4. https://www.rfc-editor.org/info/rfc9938/
  5. https://www.rfc-editor.org/rfc/rfc9938.html
  6. https://www.rfc-editor.org/rfc/rfc8655.html
  7. https://www.rfc-editor.org/rfc/rfc8938.html
  8. https://www.rfc-editor.org/rfc/rfc9016.html
  9. https://www.rfc-editor.org/rfc/rfc9055.html
  10. https://www.rfc-editor.org/rfc/rfc9551.html
  11. https://www.rfc-editor.org/rfc/rfc9633.html
  12. https://www.rfc-editor.org/rfc/rfc7426.html
  13. https://www.rfc-editor.org/rfc/rfc8283.html
  14. https://www.rfc-editor.org/rfc/rfc9552.html