Résumé

  • draft-many-teas-rsvp-power-00 propose cinq modes pour coordonner la veille et le réveil d’une ressource TE précisément identifiée. La révision 00 est un Internet-Draft individuel ; l’objet RSVP POWER et ses valeurs ne sont pas encore attribués.
  • La signalisation ne commande pas elle-même le matériel. Pour déclarer l’opération réussie, il faut relier l’accord des deux extrémités à l’action de chaque gestionnaire d’énergie, à l’état TE conservé, à un chemin de réveil indépendant et au retour observé du transfert.

Deux équipements viennent de s’entendre. Le premier a envoyé SleepPrepare, le second a répondu favorablement, puis GoSleepAck a clos l’échange. Sur le tableau de bord, la transaction est verte. Pourtant l’interface consomme toujours : un verrou local a refusé l’action physique.

Ce scénario ne contredit pas le protocole proposé dans Power Transition Framework for TE Resources, daté du 30 septembre 2026. Il révèle au contraire sa séparation architecturale. La signalisation coordonne les extrémités ; un gestionnaire d’énergie local, hors du périmètre du document, applique la transition matérielle. Le texte interdit de déclarer la réussite au seul motif qu’une demande de veille a été envoyée.

La prudence commence par le statut du document. La révision 00 est un brouillon individuel destiné au Standards Track, associé à TEAS et valable jusqu’au 3 avril 2027. Ce n’est ni un RFC, ni un consensus de groupe de travail, ni une preuve d’implémentation. La classe et le C-Type du nouvel objet POWER restent TBD.

Identifier le lien avant de modifier son état

Une transaction porte sur une seule ressource. Deux routeurs peuvent partager plusieurs liens parallèles, chacun avec ses réservations et son rôle de protection. L’arrivée d’un message sur une adjacence apparentée n’autorise donc pas l’équipement à choisir une interface voisine.

Dans la réalisation RSVP, un lien numéroté est désigné par l’adresse locale de l’émetteur et un index nul. Pour un lien non numéroté, l’identifiant de routeur et l’identifiant TE local forment un couple indivisible. Si le récepteur ne peut pas le résoudre sans ambiguïté, il doit refuser.

Le reçu d’exploitation doit conserver ce couple, le pair authentifié et l’interface locale résolue. « Le nœud A a demandé au nœud B » ne suffit pas à borner l’impact. L’identité de la ressource fait partie du mécanisme de sûreté.

Ready n’est pas Sleeping

Le modèle distingue Operating, Requisition, Ready, Pending et Sleeping. En Requisition, l’émetteur attend une décision. En Ready, les deux côtés sont prêts à poursuivre mais l’autorisation locale ou l’instruction finale manque encore. Pending commence après GoSleep. Sleeping désigne l’achèvement coordonné.

Ces états évitent une compression dangereuse. SleepPrepareAck signifie que le récepteur a reconnu la ressource et accepté de participer ; il ne dit pas que l’optique est éteinte. GoSleep autorise l’étape suivante ; il ne montre pas que les deux gestionnaires locaux ont agi. Même GoSleepAck doit être rapproché d’un constat matériel distinct.

Il faut donc deux journaux corrélés. Le premier décrit le message, le pair, le rôle, l’état attendu, l’identifiant de transaction et le délai. Le second décrit la décision du gestionnaire d’énergie et l’état matériel observé à chaque extrémité. Sans cette couture, « veille réussie » reste un libellé dont l’étendue est inconnue.

L’échec doit laisser la ressource éveillée

Le projet privilégie un échec conservateur. Ressource inconnue, capacité absente, relation de pair inutilisable, refus local, message mal formé, envoi échoué ou état inattendu : aucune de ces situations ne doit provoquer la mise hors tension. La ressource demeure ou revient en Operating.

Les phases SleepPrepare et GoSleep utilisent un délai de 180 secondes dans la réalisation RSVP. C’est un délai par défaut, pas un objectif de rétablissement mesuré. À expiration, l’état de transaction est supprimé, l’échec est signalé et la mise hors tension ne doit pas survenir par effet secondaire.

Si les deux extrémités lancent simultanément la même ressource, l’identifiant de nœud stable le plus élevé conserve le rôle Sender. L’autre annule sa tentative et devient Receiver. Cette règle ne fusionne pas deux liens parallèles. Elle rend la coordination déterministe sans décider si la veille est, au fond, opportune.

Conserver l’état ne signifie pas qu’il reste cohérent

Le lien peut dormir, mais son identité, son adressage, ses attributs TE et la distinction entre liens parallèles doivent survivre. Les LSP, chemins, réservations, labels et états de protection existants sont conservés ou réconciliés selon le protocole et la politique applicables. La veille n’est pas un teardown implicite réussi.

Cette obligation rend le retour possible ; elle ne le garantit pas. Une réservation conservée peut vieillir. Un moteur de calcul peut exclure la ressource tandis qu’un autre référentiel la croit encore disponible. Le nœud doit empêcher tout nouvel usage pendant l’indisponibilité et ne rendre la ressource à nouveau éligible qu’après le réveil et la disponibilité locale.

Le reçu de restauration doit donc dire ce qui a été gardé, retiré, modifié puis réinstallé. La réversibilité d’un objet de base de données n’est pas encore celle du service.

Le réveil ne peut pas dépendre du lien endormi

Chaque extrémité, une politique locale ou un besoin de service peut déclencher GoWakeup. La demande répétée est idempotente. Mais elle doit passer par une voie qui ne dépend pas du fonctionnement de la ressource endormie. Au moins un chemin de contrôle doit rester disponible.

Ce chemin mérite son propre test. Une route de gestion peut être distincte au niveau logique tout en partageant la même carte, le même conduit ou la même alimentation. Le brouillon ne prescrit pas une architecture hors bande ; il oblige l’opérateur à rendre cette dépendance explicite.

Enfin, la réception de GoWakeup ne clôt pas la reprise. Il faut observer le matériel prêt, l’adjacence ou la joignabilité rétablie, les réservations réconciliées, le retour dans la topologie TE et le passage du trafic. Un message de réveil est une intention livrée, pas un paquet transféré.

La chaîne de preuve devient ainsi lisible : version exacte de la spécification, politique approuvée, identité composite, éligibilité des deux côtés, préparation corrélée, instruction de veille, constats physiques, garde de l’état TE, voie de réveil indépendante, disponibilité locale, participation TE et transfert observé. La mesure d’énergie ou de carbone vient ensuite ; elle ne se déduit pas du protocole.

La doctrine de Lu Heng aide à garder la couche commune étroite. Une spécification initiale minimale peut normaliser l’identité, les messages, les rôles, les collisions et les retours sûrs. L’opérateur conserve la décision sur l’éligibilité, l’action physique et le niveau de preuve. L’adoption volontaire se voit dans le code en fonctionnement, pas dans la publication d’un brouillon.

Sources