Zusammenfassung

  • Der MPLS-STAMP-Entwurf stützt sich an beiden Enden auf lokal bereitgestellte Sitzungsparameter und Terminierungsmechanismen; STAMP-spezifische VCCV-Signalisierung liegt außerhalb seines Umfangs.
  • Eine erfolgreiche Antwort ist belastbarer Nachweis des Paketaustauschs, jedoch kein dauerhafter Beleg für eine gemeinsame Definition von Pfad, Modus, Uhr, Rate, Dienst und Verwendungszweck.

Die entscheidende Passage in draft-ietf-mpls-stamp-pw-21 steht nicht in einem Paketformat. Der Mechanismus, mit dem ein STAMP-Testpaket an einem LSP oder Pseudowire terminiert wird, wird an beiden Enden lokal bereitgestellt. Signalisierungserweiterungen für STAMP über den VCCV Control Channel eines PW behandelt das Dokument nicht. Für LSPs existiert diese VCCV-Signalisierung nicht; lokale Bereitstellung ist dort nach dem Entwurf derzeit die einzige gangbare Möglichkeit.

Revision 21 vom 10. September 2026 ergänzt außerdem ausdrücklich, dass die Verfahren für eine einzige administrative Netzdomaine gedacht sind. Das begrenzt die Architektur, löst aber die Nachweisfrage nicht. Ein Betreiber kann mehrere Teams, Controller, Hersteller und Änderungsfenster haben. Gemeinsame Zuständigkeit ist keine atomare Konfiguration.

Der SSID verweist auf lokalen Zustand

RFC 8762 beschreibt eine STAMP-Sitzung als bidirektionalen Paketfluss zwischen einem Sender und einem bestimmten Reflektor über einen Zeitraum. Konfiguration und Verwaltung bleiben außerhalb der Spezifikation. Als mögliche Werkzeuge nennt sie CLI, OSS/BSS, SNMP sowie NETCONF/YANG-basierte Controller. Der Reflektor arbeitet danach gemäß seinem Zustand: stateful oder stateless, authentifiziert oder unauthentifiziert.

RFC 8972 führt den STAMP Session Identifier ein. Vor Testbeginn muss ein unterstützender Reflektor mit sämtlichen Elementen versorgt sein, die eine Sitzung identifizieren; nicht passende Testpakete sind zu verwerfen. Wie diese Elemente bereitgestellt werden, bleibt offen. Der MPLS-Entwurf verlangt einen von null verschiedenen SSID in beiden Richtungen.

Bei Format-1 tragen Adresse, UDP-Zielport, SSID und lokale Parameter zur Identifikation bei. Format-2 enthält keinen IP/UDP-Header. Deshalb wird der SSID mit dem LSP- oder PW-Kontext der Hin- beziehungsweise Rückrichtung und den lokalen Parametern verknüpft. Der Wert im Paket ist damit ein Schlüssel zu einem lokalen Datensatz, nicht der Datensatz selbst.

Dass der Schlüssel an beiden Enden funktioniert, beweist noch keine semantische Gleichheit. Die eine Seite kann die Sitzung einem Kundendienst zuordnen, die andere einer Wartungssicht des Transports. Format und SSID können übereinstimmen, während Reflektormodus, Authentifizierung, TLVs, Taktquelle, Senderate oder Alarmschwelle abweichen. Die Quellen behaupten keinen solchen Vorfall. Sie zeigen nur zuverlässig, dass die Antwort diese Abweichung allein nicht ausschließen kann.

VCCV handelt einen engeren Gegenstand aus

Es wäre falsch zu sagen, ein Pseudowire signalisiere nichts. RFC 5085 definiert die Anzeige von Fähigkeiten für Control-Channel- und Connectivity-Verification-Typen. Die Provider Edges tauschen unterstützte Kombinationen aus, wählen einen gemeinsamen Typ und verwenden ihn, bis der PW neu signalisiert wird. RFC 7708 ergänzt den GAL-basierten Typ 4 und Regeln für die Auswahl unter mehreren Möglichkeiten.

Der MPLS-STAMP-Entwurf nutzt solche Mechanismen, um ein Testpaket aus dem gewöhnlichen Weiterleitungspfad herauszunehmen und der Kontrollverarbeitung zuzuführen. Genau ein Ausnahmeverfahren ist pro Sitzung wirksam. Danach folgt die Identifikation: Der G-ACh-Typ zeigt an, ob STAMP mit IP/UDP als Format-1 oder ohne diese Header als Format-2 folgt. Ausnahme und Identifikation sind getrennte Funktionen.

Die VCCV-Auswahl ist deshalb echter, aber begrenzter Nachweis. Sie kann eine gemeinsame Control-Channel-Fähigkeit belegen. Sie handelt nicht automatisch SSID, Headerformat, konkreten LSP/PW, Adressen und Ports, Authentifizierungs- und Zustandsmodus, TLVs, Paketgröße, Rate, Zeitquelle, Dienstbezug und erlaubte Folgeverwendung aus. Für diese Elemente bleibt der Entwurf beim lokalen Zustand.

Die präzise Aussage lautet also nicht: „Es gibt keine Vereinbarung.“ Es gibt mehrere Vereinbarungen mit verschiedenen Gegenständen. Die Governance-Lücke entsteht, wenn VCCV-Auswahl, STAMP-Antwort und Dienstzuordnung als ein einziger grüner Nachweis erscheinen.

Was eine Antwort tatsächlich trägt

Kommt ein korrekt geformtes Paket mit dem erwarteten SSID zurück, ist das wertvolle Evidenz. Ein Paket verließ den Sender, nutzte einen brauchbaren Weiterleitungskontext, wurde am Reflektor ausgenommen und identifiziert und fand unter hinreichend kompatiblem Zustand zurück. Je nach Modus und Prüfung lassen sich Verzögerung, Variation oder Verlust berechnen.

Die Antwort benennt nicht die Genehmigenden oder die Konfigurationsgenerationen. Sie beweist nicht, dass beide Enden denselben Dienst, denselben Diagnosezweck oder dieselbe SLA-Entscheidung meinten. Sie belegt weder eine gemeinsame Genauigkeitsgrenze der Uhren noch die Freigabe der Testrate, den MTU-Spielraum oder die Fortgeltung der Zuordnung nach einer einseitigen Änderung.

Auch die Annahme einer administrativen Domaine ersetzt den Nachweis nicht. Sie bestimmt, wer grundsätzlich kontrolliert, aber nicht, ob zwei Konfigurationsspeicher denselben Stand besitzen. Ein Unternehmen ist kein verteilter Commit-Algorithmus.

Die angemessene Reaktion besteht nicht darin, STAMP mit Organisationsdaten zu beladen. Interoperabilität profitiert von einem kleinen Protokollkern. Der umfassendere Beleg gehört in einen geschützten lokalen Datensatz, der mit der Paketspur verbunden ist, ohne sich als Paketnachweis auszugeben.

Ein bilateraler Konfigurationsbeleg

Ein bilateraler Messkonfigurationsbeleg beginnt mit Sender- und Reflektoridentität, administrativer Domaine, LSP oder PW und Richtung, Ausnahmeverfahren, STAMP-Format, G-ACh-Typ und SSID. Bei Format-1 kommen Adressen und Ports hinzu; bei Format-2 die zur Identifikation verwendeten Hin- und Rückwegkontexte.

Danach bindet er die Bedeutung: stateful oder stateless, authentifiziert oder nicht, TLV-Satz, Taktquelle und Synchronisationsnachweis, Paketgröße und MTU-Reserve, Senderate, angenommene Rückwegkapazität, zugeordneter Dienst, Beobachtungszweck und die Klasse der zulässigen Entscheidung. Diese Angaben müssen nicht in jedem Paket stehen; sie brauchen eine gemeinsame Identität.

Beide Enden liefern einen Hash oder unveränderlichen Versionsverweis ihrer Konfiguration. Der Beleg nennt Controller oder Bediener, den Prüfer der Kombination, Akzeptanztests, Ablaufzeit und Rücksetzbefugnis. Ändert sich nur eine Seite, entsteht ein neuer Beleg. Eine weiterlaufende SSID-Antwort erbt nicht stillschweigend die frühere Genehmigung.

Auch Evidenzstufen bleiben getrennt: gemeinsame VCCV-Fähigkeit, passende STAMP-Parameter, empfangene Antwort, Uhren innerhalb der Vorgabe, berechnete Metrik und erfülltes Dienstziel. Ein nachgelagertes System darf die nachgewiesene Stufe nutzen, nicht automatisch die nächste.

Dieser Beleg ist Daniel Kades Governance-Vorschlag. Er ist weder neues STAMP-Feld noch IETF-Anforderung oder IANA-Register.

Teilweise Übereinstimmung sieht besonders sauber aus

Eine vollständige Fehlkonfiguration ist oft erkennbar: Der Reflektor kann die Sitzung nicht identifizieren und verwirft. Schwieriger ist die Übereinstimmung, die gerade zum Antworten reicht.

Ein von stateful auf stateless umgestellter Reflektor kann weiter antworten, aber die mögliche Verlustinterpretation verändern. Ein Wechsel des Authentifizierungsmodus verändert die Vertrauensgrenze. Eine neue Pfadzuordnung kann den SSID behalten, während das Dashboard den alten Dienstnamen zeigt. Eine Uhr im Holdover liefert geordnete Zeitstempel, deren Unsicherheit für die beabsichtigte Entscheidung zu groß geworden sein kann.

Das sind Prüfszenarien, keine Feststellungen über Produkte oder Netze. Die Quellen enthalten keinen Zwischenfall und keine Verbreitungsstatistik. Ihre Aussage reicht dennoch: Paketerfolg ist kein Fingerabdruck der gesamten bilateralen Konfiguration.

Quellen

  1. MPLS-STAMP-Entwurf, Verlauf und API-Datensatz
  2. Revision 21 HTML, Text, XML und Vergleich 20–21
  3. IESG-Ballot, Shepherd Write-up und MPLS Working Group
  4. RFC 8762 und RFC 8972
  5. RFC 5085, RFC 7708 und RFC 5586
  6. RFC 7799, Minimum Initial Specification und The Policy Mirror