Zusammenfassung
draft-many-teas-rsvp-power-00schlägt fünf Modi für Schlaf und Aufwecken einer eindeutig bezeichneten TE-Ressource vor. Revision 00 ist ein individueller Arbeitsentwurf; die Werte des RSVP-POWER-Objekts sind nicht zugeteilt.- Das Protokoll koordiniert Nachbarn, während lokale Power Manager die Hardware betätigen. Erfolg verlangt daher getrennte Belege für beide Enden, verwahrten TE-Zustand, einen unabhängigen Weckpfad und beobachtete Weiterleitung nach der Rückkehr.
Die Nachrichtenfolge sieht vollständig aus: SleepPrepare, Annahme, GoSleep, Bestätigung. Im Dashboard ist der Link grau. Im Gerät bleibt er aktiv, weil eine lokale Schutzbedingung die physische Aktion verweigerte.
Genau diese Trennung beschreibt Power Transition Framework for TE Resources vom 30. September 2026. Signalisierung stimmt die Endpunkte ab; ein lokaler Power Manager außerhalb des Dokumentumfangs führt die materielle Änderung aus. Deshalb darf eine Implementierung Erfolg nicht allein melden, weil sie einen Schlafantrag gesendet hat.
Revision 00 ist ein individueller, TEAS zugeordneter Internet-Draft mit beabsichtigtem Standards-Track-Status und Ablauf am 3. April 2027. Er ist weder RFC noch Arbeitsgruppenkonsens, IANA-Zuteilung oder Implementierungsbeleg. Klasse und C-Type des POWER-Objekts stehen auf TBD.
Ein Peer ist noch keine eindeutige Ressource
Zwischen zwei Routern können mehrere parallele Links mit verschiedenen Reservierungs- und Schutzrollen liegen. Eine Transaktion gilt daher für genau eine explizit identifizierte Ressource. Der Empfang über eine verwandte Adjazenz erlaubt keine Auswahl einer anderen Schnittstelle.
Für einen nummerierten Link nutzt RSVP die lokale Linkadresse des Senders und Index null. Ein unnummerierter Link wird durch Router-ID und lokalen TE-Link-Identifier bezeichnet. Das Paar ist unteilbar; ohne eindeutige Auflösung muss der Empfänger ablehnen.
Der Nachweis bewahrt dieses Paar, den authentisierten Peer und die lokal aufgelöste Schnittstelle. „A bat B um Energiesparen“ begrenzt bei vier parallelen Fasern keinen Wirkungsbereich. Identität ist hier eine Sicherheitsfunktion.
Ready ist kein Messwert der Hardware
Operating, Requisition, Ready, Pending und Sleeping sind verschiedene Aussagen. SleepPrepareAck führt zu Ready: Der Empfänger hat die Ressource erkannt und macht mit. Eine lokale Freigabe oder die letzte Anweisung kann noch fehlen. Erst nach GoSleep beginnt Pending.
Auch GoSleepAck muss mit lokaler Evidenz verbunden werden. Es kann einen erwarteten Protokollschritt des richtigen Peers bestätigen. Es misst keine Stromaufnahme und beweist nicht, dass beide Seiten denselben physischen Zustand erreicht haben.
Darum braucht der Vorgang zwei korrelierte Spuren. Die Protokollspur enthält Ressource, Peer, Rolle, erwarteten Modus, Message-ID und Timeout. Die Ausführungsspur enthält Entscheidung und beobachteten Hardwarezustand jedes Power Managers. Ohne diese Verbindung ist „Sleeping“ ein Etikett ohne bekannte Beweisreichweite.
Im Fehlerfall bleibt die Ressource wach
Unbekannte Ressource, fehlende Fähigkeit, unbrauchbare Peer-Beziehung, verweigerte lokale Autorisierung, fehlerhafte Nachricht, fehlgeschlagener Versand oder unerwarteter Zustand dürfen kein Abschalten verursachen. Die Ressource bleibt in Operating oder kehrt dorthin zurück.
Für Vorbereitung und Bestätigung nennt die RSVP-Ausprägung 180 Sekunden als Standardwartezeit. Das ist weder gemessene Dauer noch SLA. Beim Ablauf wird Transaktionszustand entfernt und ein Fehler gemeldet; der Timeout darf selbst keine physische Aktion auslösen.
Starten beide Enden dieselbe Ressource gleichzeitig, bleibt die Seite mit dem numerisch höheren stabilen Identifier Sender. Die andere bricht ihre Sender-Transaktion ab und wird Receiver. Verschiedene parallele Links sind keine Kollision. Die Regel ordnet das Protokoll, nicht die geschäftliche Entscheidung über Reservekapazität.
TE-Zustand muss den Schlaf überstehen
Link-Identität, Adressierung, TE-Attribute und Parallel-Link-Unterscheidung bleiben erhalten. Bestehende LSPs, Pfade, Reservierungen, Labels und Schutzinformationen werden nach Protokoll und Policy bewahrt oder abgeglichen. Schlaf gilt nicht als stillschweigend erfolgreicher Teardown.
Bewahrung garantiert keine Konsistenz. Eine Reservierung kann altern; eine Datenbank kann den Link ausschließen, während eine andere ihn noch anbietet. Neue Nutzung muss während der Nichtverfügbarkeit verhindert werden. Normale Eignung kehrt erst nach Wecken und lokaler Bereitschaft zurück.
Der Wiederherstellungsbeleg zeigt daher, was behalten, zurückgezogen, geändert und erneut eingesetzt wurde. Ein gespeichertes Objekt macht Rückkehr möglich, beweist aber keine Konvergenz verteilter Steuerzustände.
Der schlafende Link darf nicht seinen eigenen Wecker tragen
GoWakeup kann von beiden Enden, lokaler Policy oder einem Dienstbedarf ausgelöst werden und ist bei Wiederholung idempotent. Die Nachricht muss aber einen Pfad nutzen, der nicht von der schlafenden Ressource abhängt. Mindestens ein Control-Plane-Pfad bleibt erreichbar.
Die Bezeichnung „Management-Netz“ genügt nicht. Logisch getrennte Wege können Linecard, Leerrohr, optische Strecke oder Stromversorgung teilen. Der Entwurf schreibt keine Out-of-Band-Topologie vor, macht die Unabhängigkeit aber zur lokalen Nachweispflicht.
Mit dem Empfang von GoWakeup beginnt die Erholung erst. Hardwarebereitschaft, Adjazenz oder Erreichbarkeit, abgeglichene Reservierungen, TE-Teilnahme und tatsächlicher Verkehr müssen folgen. Zugestellte Wecknachricht und wiederhergestellte Weiterleitung sind nicht dasselbe Ereignis.
Die Beweiskette trennt genaue Revision, freigegebene Policy, Ressourcenidentität, bilaterale Eignung, Vorbereitung, Schlafanweisung, physische Belege, TE-Verwahrung, unabhängigen Weckpfad, lokale Bereitschaft, TE-Rückkehr und Forwarding. Energie- oder Kohlenstoffwirkung erfordert danach eigene Messung.
Lu Hengs Prinzip der minimalen Anfangsspezifikation passt: Die gemeinsame Schicht standardisiert Identität, Nachrichten, Rollen, Kollisionen und sicheres Scheitern. Eignung, physische Aktion und Dienstschwellen bleiben lokal. Freiwillige Adoption zeigt sich in laufendem Code und Resultaten, nicht in einer Veröffentlichung.
Quellen
- Aktueller Datatracker-Eintrag
- Versionsgeschichte
- Text von Revision 00
- XML von Revision 00
- ResourceNotify-Abhängigkeit für RSVP-TE
- RFC 2205: RSVP
- RFC 2961: RSVP Refresh Reduction
- RFC 3209: RSVP-TE
- RFC 9845: Management für grünere Netze
- Minimale Anfangsspezifikation, lokale Entscheidung und freiwillige Adoption
- Vorrang von Running Code
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten

