Zusammenfassung

  • RFC 3532 verlangt bei dynamischer Partitionierung, den bestehenden Zustand eines aktiven virtuellen Switching Elements zu erhalten. Eine proaktive Nachricht an jeden Controller ist aber nicht zwingend; die neue Grenze kann erst durch eine spätere Ablehnung und Ressourcenabfrage sichtbar werden.
  • Ein belastbarer Nachweis trennt Berechtigung, alte Zuteilung, laufende Nutzung, Freigabe oder Ablehnung, Einfrieren und Leerlaufen, Kenntnisweg, partitionsübergreifende Dienste und Anwendungsergebnis. „Neuzuteilung erfolgreich“ deckt diese Kette nicht ab.

Ein Neustart macht eine Grenze offensichtlich. Bei der statischen Neuaufteilung aus RFC 3532 trennen sich betroffene Controller, konfigurierter Zustand wird im Regelfall freigegeben, das virtuelle Switching Element geht außer Betrieb und muss danach wieder aufgebaut werden. Die dynamische Variante lässt die aktive Partition an Ort und Stelle und muss ihren bestehenden Zustand erhalten.

Damit verschwindet die sichtbare Unterbrechung, nicht aber die Veränderung. Die Kontrollverbindung kann bestehen bleiben, obwohl das Budget kleiner ist. Einträge können vorhanden sein, obwohl weniger Warteschlangen, Puffer, Verbindungen oder Bandbreite zur Verfügung stehen. Erhaltener Zustand ist eine präzise Eigenschaft; er ist weder gleichbleibende Kapazität noch ein Anwendungsergebnis.

RFC 3532 erschien im Mai 2003 als Informational und erklärt ausdrücklich, keinen Internetstandard festzulegen. Es ist ein Anforderungsdokument, kein vollständiges Protokoll. Der Schwerpunkt liegt auf der Partitionierung von GSMP-Switches. Für Nicht-GSMP-Switches und Weiterleiter mit Longest-Prefix-Match können die Anforderungen nötig sein, ohne ausreichend zu sein.

Die Ressource gehört dem SE, die Entscheidung dem PM, der Betrieb dem Controller

Das Switching Element, SE, vermittelt Pakete und stellt teilbare Ressourcen bereit. Eine Partition oder ein virtuelles SE besteht aus einem Anteil daran. Ein Controller betreibt die aktive Partition. Der Partition Manager, PM, bestimmt Anzahl und Ausstattung der virtuellen SEs.

Damit entstehen getrennte Beweisflächen. Der PM fordert eine Zuteilung, das SE setzt sie durch, der Controller verbraucht sie, und PM sowie Controller können eine Änderung im laufenden Betrieb aushandeln. Ein Datensatz „Kapazität geändert“ verliert Antragsteller, Vollstrecker, Nutzer und Empfänger der Information.

Die Rollen sind logisch. Sie können auf einer Maschine zusammenliegen oder verteilt sein. Logische Trennung beweist keine physische Isolation und keinen unabhängigen Fehlerbereich. Gemeinsame Hardware hebt die getrennten Befugnisse nicht auf. Ein Audit muss Rolle und konkreten Laufzeitakteur verbinden.

Als Beispiel beschreibt die RFC einen Eigentümer, der ein SE teilt und Dritten die Steuerung virtueller Elemente überlässt. Daraus folgt kein realer Mietvertrag. Vertraglicher Anspruch, Befugnis des PM, Betriebsrecht des Controllers und tatsächlich erzwungene Zuteilung sind vier Aussagen.

Ein Frozen Partition ist ein Abflusszustand

Das SE muss verhindern, dass ein Controller mehr als die aktuelle Zuteilung nutzt. Diese Regel vollstreckt die Grenze. Sie erlaubt nicht, bereits verwendete Ressourcen still zu zerstören, damit eine Verringerung erfolgreich aussieht.

Verlangt der PM die Freigabe von Ressourcen einer aktiven Partition und ist davon etwas in Gebrauch, muss das SE die Anforderung ablehnen. Die Ablehnung ist korrekt. Sie trennt ungenutzte Kapazität, die sofort wandern kann, von laufender Arbeit, die Koordination verlangt.

Danach sollte der PM die Partition einfrieren, den Controller zur Senkung der Nutzung auffordern oder beides tun. Die eingefrorene Partition gibt freie Ressourcen ab, lässt bestehende Verbindungen bestehen und gibt weitere Mittel zurück, sobald diese enden. Sie ist weder normal aktiv noch sofort gelöscht. Ihr Zustand hat eine Richtung: kein Wachstum, schrittweiser Abfluss.

Das verlangt mehr als ein Boolesches Feld. Der Nachweis braucht Beginn und Grund des Einfrierens, belegte Ressourcen, Abbaufortschritt, geschlossene Verbindungen und Zielbedingung. Auch während des Abflusses kann die Leistung anders sein; bestehende Verbindungen allein beweisen nicht unveränderte Warteschlangen oder Bandbreite.

Gibt der Controller nicht genug frei, kann der PM als letzte Maßnahme virtuell abschalten. Die Partition wird inaktiv und Controller werden getrennt. Das verhindert dauerhafte Blockade, ist aber störend. Eine am Ende freie Ressource macht den Weg dorthin nicht zu einer unterbrechungsfreien dynamischen Verringerung.

Zuteilungszeit und Kenntniszeit sind verschiedene Uhren

Ein Kontrollprotokoll kann proaktiv melden, dass Ressourcen neu zugeteilt wurden. Dieser Weg gibt dem Controller früh ein klares Signal. RFC 3532 schreibt ihn jedoch nicht für jedes Protokoll vor, weil reaktive Benachrichtigung zwingend ist.

Explizit reaktiv bedeutet: Eine spätere Controller-Anfrage scheitert mit einem Fehler, der auf neu zugeteilte Ressourcen hinweist. Implizit reaktiv bedeutet: Es kommt nur ein allgemeiner, unbekannter oder ressourcenbezogener Fehler. Dann muss der Controller verfügbare Ressourcen abfragen, um die Neuaufteilung als Ursache festzustellen.

Der PM kann den Controller auch direkt kontaktieren. Dafür braucht es einen eigenen Nachweis über Berechtigung, Versand, Empfang und Verarbeitung. Eine gesendete Nachricht beweist kein aktualisiertes Scheduling. Ein Fehler beweist keine richtige Interpretation. Eine SE-Abfrage beweist nicht, welche Entscheidung der Controller danach trifft.

Mindestens vier Zeitpunkte gehören in die Chronologie: neue Zuteilung, Signal beim Controller, Übernahme in dessen Modell und Beobachtung des Dienstes. Die Abstände können einer Nachrichtenlaufzeit, der Wartezeit bis zur nächsten Anfrage oder einer Diagnose nach einem unspezifischen Fehler entsprechen.

In dieser Lücke kann das SE die neue Grenze korrekt vollstrecken und der Controller zugleich folgerichtig nach seinem veralteten Modell handeln. Ohne Kausaltyp sieht das wie zufälliger Ressourcenmangel aus. Mit Kausaltyp lässt sich Zuteilungsfehler von verzögerter Kenntnis und falscher Anpassung unterscheiden.

Der Bestand des Switches liest nicht den Zustand des Controllers

Der PM muss Ressourcen, konfigurierte Partitionen und ihre Zuteilungen beim SE abfragen können. Für automatischen Austausch mit Controllern muss er über das SE deren Adressen bestimmen können; Kontrollprotokoll und Version können ebenfalls verfügbar sein.

Diese Inventur belegt, was das SE zu einem Zeitpunkt meldet, und zeigt, wen der PM ansprechen sollte. Sie belegt nicht, dass der Controller informiert ist, das neue Budget akzeptiert, unnötige Anfragen beendet oder den Dienst bewahrt hat.

Weichen Wunschzustand des PM und SE-Bericht voneinander ab, geht es um Anwendung oder Abgleich. Stimmen sie überein, während der Controller das alte Budget nutzt, geht es um Kenntnis oder Anpassung. Stimmen alle drei überein und Nutzer scheitern, liegt die Untersuchung im Datenpfad oder in der Anwendung. Eine einzige Meldung „nicht synchron“ verdeckt diese Ebenen.

Jede Abfrage besitzt einen Beobachtungszeitpunkt. SE, Partition, Ressourcenschema, Werte, Zeit und Antwortdigest müssen unveränderlich bleiben. Ein späterer Wert kann nicht rekonstruieren, welches Budget der Controller bei seiner abgelehnten Anfrage annahm.

Virtuelle Verbindungen erweitern die Wirkung ohne Flottenfreigabe

Ein SE kann Dienste von einem virtuellen SE zu einem anderen bereitstellen, etwa eine virtuelle Verbindung. Es muss solche partitionsübergreifenden Dienste offenlegen, und der PM muss sie konfigurieren können. Fügt die Konfiguration einen virtuellen Port hinzu oder entfernt ihn, soll das SE die angeschlossenen Controller benachrichtigen, wenn ihr Protokoll dies unterstützt.

Eine lokale Zuteilungsänderung kann folglich eine Abhängigkeit einer anderen Partition verändern. Diese Partition kann ihr eigenes Budget behalten und dennoch Port oder Kapazität eines virtuellen Dienstes verlieren. Nicht Ziel der Anforderung zu sein, beweist keine Unberührtheit im Ergebnis.

Die Prüfung braucht zwei Mengen. Repräsentative Partitionen außerhalb des ermittelten Impacts müssen Zuteilung und Prozessidentität behalten. Gleichzeitig sind Dienste über die geänderte Grenze hinweg zu erfassen und zu testen. Der erste Teil verhindert einen unnötigen Gesamtneustart, der zweite ein zu enges Verständnis realer Abhängigkeit.

Gemeinsames Gehäuse, Protokoll, PM oder Konfigurationsdatei reicht nicht, alle Partitionen als betroffen zu behandeln. Der Impact folgt geänderten Zuteilungen, Laufzeiteingaben, direkten Abhängigkeiten und nötigen Migrationen.

Befugnis ist kein Kapazitäts- oder Ergebnisnachweis

Nur ein autorisierter PM darf ein SE dynamisch neu partitionieren. Das SE braucht einen sicheren Prozess, in dem eine berechtigte Entität den steuernden PM auswählt, ausdrücklich oder über autorisierte Erkennung. Nur dieser PM oder sein autorisierter Agent darf Controller zu weniger Nutzung auffordern oder über mehr Ressourcen informieren.

Umgekehrt muss der PM feststellen, dass eine Ressourcenanforderung von einem Controller stammt, der für das angegebene virtuelle SE berechtigt ist. So kann ein Mandant nicht das Budget eines anderen umformen.

Authentisierung sagt, wer unter einem Vertrauensverfahren einen Nachweis vorlegte. Autorisierung sagt, ob diese Identität die Operation an dieser Partition ausführen darf. Beides beweist weder vertraglichen Anspruch noch sichere Kapazität, tatsächliche Umsetzung oder Ergebnis.

Auch die Auswahl des PM muss historisch feststehen. Wechselt die Zuständigkeit, darf ein heute gültiger Nachweis keine frühere unberechtigte Anforderung nachträglich legitimieren. Jede Anfrage wird an damalige Auswahl, Credentials, Policy-Version, Partition und Payload-Digest gebunden.

Spätere ForCES-Dokumente sind Kontext, kein rückwirkender Beleg

RFC 3654 und RFC 3746 beschrieben später Anforderungen und einen Rahmen zur Trennung von Forwarding und Control Element. RFC 5810 und RFC 5812 spezifizierten ForCES-Protokoll und Modell, RFC 7121 behandelte Hochverfügbarkeit.

Diese Entwicklung macht RFC 3532 nicht zum Standard, erzeugt keinen fehlenden Produktionsnachweis und belegt keinen ForCES-Einsatz. RFC 3654 und RFC 3746 sind Informational; RFC 5810, RFC 5812 und RFC 7121 sind Proposed Standard. Status, Datum und Umfang bleiben getrennt.

Bibliografie, Historie und Errata sichern Dokumentidentität. Sie beobachten keine laufende Partition. Protokollverwandtschaft ist keine Adoptionsmessung.

Eine Receipt-Kette bewahrt den Übergang

Am Anfang stehen SE, PM, Controller, Partition, physische Abbildung, PM-Auswahl, Credential, Policy-Version und Anfragedigest. Danach folgen deterministische Ressourcentypen, alte Zuteilung, gemessene Nutzung und Ziel.

Die SE-Entscheidung unterscheidet sofortige Freigabe ungenutzter Mittel, Ablehnung wegen Nutzung, Einfrieren, ausgehandelte Freigabe und virtuelles Abschalten. Sie dokumentiert erhaltenen Zustand und Vollstreckung der neuen Grenze.

Der Kenntnisnachweis nennt proaktive Meldung, expliziten Fehler, impliziten Fehler plus Abfrage oder direkte PM-Nachricht. Aktualisierte Modellversion und Wiederholung des Controllers werden verknüpft. Die erneute SE-Abfrage ergänzt, ersetzt aber nicht diesen Beleg.

Zuletzt werden partitionsübergreifende Dienste, unveränderte Partitionen, Datenpfad und Anwendung geprüft. Der PM belegt seinen Antrag, das SE seine Zuteilung, der Controller sein Modell, der Dienst sein Verhalten und die Anwendung das Nutzerergebnis.

Die kurze Aussage lautet nicht „Neupartitionierung erfolgreich“, sondern: „Der autorisierte Manager verschob diese ungenutzten Ressourcen zu diesem Zeitpunkt; das SE erhielt diese Zustände; der Controller erfuhr es über diesen Weg und übernahm dieses Modell; danach wurden diese Abhängigkeiten und Ergebnisse beobachtet.“ Unbekanntes bleibt offen.

Evidence boundary

Dieser Article nennt keine Implementierung, keinen Anbieter, Betreiber, SE, PM, Controller, Mandanten, Vertrag, Pool, Partition, Einsatz, Vorfall, Ausfall, Sicherheitsfall oder Kundenergebnis. Er berichtet keine aktuelle Nutzung, Kapazität, Auslastung, Verluste, Latenz oder Dienstgüte.

RFC 3532 wird als Informational-Anforderungsdokument vom Mai 2003 behandelt, nicht als Internetstandard oder vollständiges Protokoll. Seine deterministische Annahme wird nicht auf statistische Pools und Überbuchung übertragen. Spätere GSMP-, Megaco- und ForCES-Texte behalten eigenen Status und beweisen keine Konformität eines realen Systems.

Die offengelegten Notizen von Heng Lu dienen als redaktionelle Linse: Autorität an ihre kontrollierte Operation binden und Ergebnisse mit Running-Code-Evidenz schließen. Sie belegen weder IETF-Absicht noch Implementierungs- oder Einsatzfakten.

Die begrenzte Folgerung lautet: Eine aktive Partition kann ohne Neustart neu zugeteilt sein, während ihr Controller erst durch spätere Meldung, Fehler, Abfrage oder direkten Kontakt davon erfährt. Zustandserhalt und aktuelles Inventar sind nötig, aber kein Dienstergebnis.

Sources