Résumé

  • RFC 9938 est un document IETF informatif qui assemble des concepts et exigences pour un futur plan de contrôleur DetNet ; il ne fournit pas les détails du protocole de la solution.
  • Une demande reçue, un calcul de chemin ou une commande envoyée à un équipement ne démontrent pas, à eux seuls, l'admission durable des ressources, le fonctionnement de PREOF, le respect mesuré des bornes ni le résultat pour le client.

Dans beaucoup d'organisations, le mot « contrôleur » fait déjà le travail rhétorique de « contrôle ». Une carte montre des nœuds, une interface affiche une demande, un calcul donne un chemin et des transactions de configuration sont parties. La tentation est de conclure que le service déterministe existe parce que son orchestration est visible.

RFC 9938 invite justement à ne pas faire ce raccourci. Publié en mars 2026 comme RFC IETF de catégorie Informational, A Framework for the Deterministic Networking (DetNet) Controller Plane rassemble les concepts et exigences dont une solution pourrait avoir besoin. Le texte précise qu'il ne fournit pas les détails de protocole d'une solution de plan de contrôleur ; ils relèvent de documents ultérieurs.

Un cadre est donc une carte des obligations, non un procès-verbal d'exécution. Il peut préciser ce qui doit être appris, réservé, configuré et surveillé. Il ne peut pas remplacer les preuves de ce qui a effectivement été accepté, maintenu et observé dans un réseau donné.

Le choix d'architecture ne clôt aucune chaîne de preuve

Le document présente trois familles : signalisation entièrement distribuée, contrôle entièrement centralisé de type SDN et architecture hybride. Dans l'exemple centralisé, un contrôleur recueille topologie et capacités DetNet, reçoit une demande d'établissement de flux par UNI, API ou interface nord, puis configure les nœuds, notamment avec NETCONF/YANG, DetNet YANG ou un contrôleur fondé sur PCE. Dans l'option distribuée, la signalisation porte l'information à travers le réseau. Dans l'option hybride, contrôleur et protocoles se partagent le travail.

Ces modèles sont des possibilités, pas une prescription universelle ni la trace d'un déploiement. Pour les combinaisons hybrides, RFC 9938 indique même que les extensions de protocole nécessaires restent du travail futur.

Il faut alors conserver la force exacte de chaque événement. Une demande reçue est un fait d'entrée. Un chemin calculé est le résultat d'un calcul sur une image de réseau et une politique déterminées. Une configuration envoyée est une instruction tentée. Aucun de ces faits ne prouve, à lui seul, que tous les nœuds concernés ont admis l'état, gardé les ressources jusqu'à l'échéance, appliqué la file attendue ou protégé le flux réellement transporté.

Les exigences montrent ce qu'il faut encore prouver

RFC 9938 demande le support de l'instanciation, de la modification et de la suppression dynamiques des flux DetNet. Cela peut impliquer chemins explicites, réservation de bande passante, de tampons ou d'autres ressources, disciplines de file, agrégation et traitement bidirectionnel. Le plan doit aussi couvrir les fonctions de réplication, élimination et remise en ordre de paquets — PREOF.

La grammaire compte : le RFC expose des exigences d'une solution. Une réservation calculée n'est pas une admission confirmée. Une admission initiale n'est pas une conservation après changement de topologie ou de politique. Un état de configuration n'est pas une mesure de trafic. Un ensemble de segments n'est pas la preuve que la réplication, l'élimination et l'ordre ont opéré pour les paquets et l'époque concernés.

Les domaines multiples rendent cette prudence indispensable. Les fonctions de contrôle devront collaborer, et les contrôleurs pourront devoir se découvrir, s'authentifier et négocier un comportement par saut. La frontière d'un autre opérateur n'est pas un blanc sur la carte : c'est une nouvelle preuve et une nouvelle autorité à relier.

Un reçu de service doit suivre le flux, pas seulement le contrôleur

Conservez un reçu pour la demande : identité du service, demandeur autorisé, extrémités, sens, classe de trafic et engagement demandé. Conservez un reçu pour la décision : version de topologie, algorithme, politique, chemin candidat et époque. Conservez un reçu d'admission : accusé de chaque nœud, ressource et file allouées, état de label ou d'encapsulation, rôle de protection et durée. Puis séparez la mesure — population, direction, méthode, horloge, intervalle — du résultat observé au point où la conséquence est supportée.

Cette séparation ne diminue pas le contrôleur ; elle rend sa valeur vérifiable. La primauté du code en fonctionnement de Heng Lu rappelle qu'un modèle, une intention et une vue centralisée ne doivent pas supplanter un état que les opérateurs peuvent vérifier localement. Les couches de réalité ne se remplacent pas : promesse, commande, état installé, mesure et résultat sont cinq questions distinctes.

Sources