Zusammenfassung
- Ein MS-PW lässt mindestens zwei zusammenhängende PW-Segmente wie einen Punkt-zu-Punkt-Dienst funktionieren; jedes S-PE beendet jedoch benachbarte PSN-Tunnel und schaltet Kontroll- und Datenebene weiter.
- Darum kann der Dienst durchgängig erscheinen, während Label, Admission, Richtungen, OAM, Überlastung, Schutz und Sicherheitsnachweise an unterschiedlichen Grenzen verwahrt werden.
Die Einheit liegt im Dienst, nicht in seiner Ausführung
Der Kunde soll die interne Segmentfolge nicht kennen müssen. Zwischen zwei Attachment Circuits erwartet er das Verhalten einer durchgehenden Leitung. RFC 5254 erhält dieses Versprechen auch dann, wenn der Weg mehrere Paketnetze, Tunnel oder Verwaltungsdomänen durchquert.
Doch „ein Pseudowire“ ist eine Aussage über das Produkt an den Endpunkten. Zwischen den T-PEs beenden S-PEs jeweils den vorangehenden PSN-Tunnel, beginnen den nächsten und verbinden den Kontroll- sowie den Datenzustand beider PW-Segmente. Jede solche Naht fügt eine Entscheidung, einen möglichen Fehlerort und einen neuen Verwahrer von Evidenz hinzu.
Ein einziges grünes Feld kann diese Arbeit zusammenfassen, aber nicht ersetzen. Es verrät nicht, welche Segmente zugelassen wurden, welche Tunnel sie trugen, ob beide Richtungen richtig verbunden waren, wo ein Defekt entstand oder ob Verkehr den entfernten Anschluss tatsächlich erreichte.
Die PW-Route ist nicht die Summe aller Tunnelrouten
RFC 5254 bezeichnet als PW-Route die geordnete Folge der S-PEs zwischen den T-PEs. Jedes PW-Segment liegt wiederum in einem PSN-Tunnel, dessen Route ausdrücklich gewählt oder lokal berechnet werden kann. Die Spezifikation lässt die Routenwahl dieser Tunnel bewusst außerhalb ihrer PW-Anforderungen.
Für die Nachweisführung ist diese Trennung entscheidend. Die S-PE-Folge beschreibt nicht den physischen oder labelgeschalteten Weg innerhalb jeder Domäne. Ein aktiver Tunnel beweist nicht die richtige Bindung des PW-Labels. Eine korrekte Bindung beweist noch keinen Verkehr in beiden Richtungen.
Auch der Aufbau hat verschiedene Autoritäten. Segmente können statisch, signalisiert entlang einer administrativ vorgegebenen Strecke oder dynamisch signalisiert entstehen. Ein statisches Label und ein dynamischer FEC hinterlassen unterschiedliche Entscheidungs- und Versionsspuren, obwohl der sichtbare Dienst gleich aussehen kann.
Ein signalisierter MS-PW gilt erst als erfolgreich, wenn alle Segmente eingerichtet sind. Diese Transaktionsgrenze verhindert einen falschen Teilerfolg. Sie belegt jedoch nur den Aufbauzeitpunkt. Nach Tunnelwechsel, Cross-Connect-Fehler, Queue-Ausfall oder Schutzumschaltung kann derselbe Status veraltet sein.
Admission ist eine Folge lokaler Urteile
Jedes S-PE ordnet ein PW-Segment einem geeigneten PSN-Tunnel zu. Signalisierte Attribute oder lokale Regeln können die Wahl bestimmen; Admission Control erfolgt für jedes Segment. Die Zustimmung einer Domäne verpflichtet die nächste nicht. Bandbreitenreservierung, Prioritätsdarstellung und Provisionierung können sich an jeder Grenze unterscheiden.
Ein belastbarer Datensatz bewahrt deshalb die Anforderung an jeder Naht, das gewählte Label oder den Identifikator, die Tunnelbindung, die verwendete Policy-Version und das Admission-Ergebnis. Fehlen diese Zwischenbelege, lässt sich ein globales up nach einer Änderung nicht mehr begründen.
Die Richtung gehört ebenfalls zum Beweis. Beide Richtungen enden zwar am selben PE-Paar, können aber andere Labels, Queues, Zähler und Fehler besitzen. Eine Richtung kann gestört sein, während die andere funktioniert. Wer sie in einem Booleschen Wert vereint, entfernt gerade die Asymmetrie, die eine Diagnose ermöglicht.
OAM muss zwei Maßstäbe gleichzeitig beherrschen
Multi-Segment-OAM soll mindestens die Fähigkeiten eines Single-Segment-Pseudowires bieten. RFC 5254 verlangt außerdem Segment- und End-to-End-Mechanismen, damit ein Fehler entdeckt und lokalisiert werden kann. Ein Messabschnitt kann T-PE zu T-PE, T-PE zu S-PE oder S-PE zu S-PE umfassen.
Die globale Prüfung zeigt, ob der zusammengesetzte Dienst funktioniert, bestimmt aber nicht zwingend das defekte Segment. Die lokale Prüfung grenzt die Naht ein, belegt jedoch nicht den gesamten Kundenpfad. Beide Perspektiven sind nötig, weil mehrere Ausführungsflächen ein einziges Ergebnis produzieren.
Alle beteiligten PEs müssen sich auf einen gemeinsamen OAM-Mechanismus verständigen. Das S-PE überträgt Tunneldefekte auf betroffene Pseudowires, bewahrt die Richtung der Meldung und reicht T-PE-zu-T-PE-OAM transparent weiter. Zugleich soll es als Segmentendpunkt beobachten. Das Durchreichen einer globalen Meldung und das Erzeugen einer lokalen Messung sind zwei getrennte Tatsachen.
Statische Segmente entgehen dieser Pflicht nicht. Ohne Signalisierungsnachbarschaft zwischen S-PEs muss In-Band-OAM Fehler des PW oder des Attachment Circuit weitergeben. Konfiguration dokumentiert Absicht, OAM dokumentiert Beobachtung, und Kundenverkehr dokumentiert das Ergebnis.
Eine Schutzentscheidung eröffnet einen neuen Nachweiszyklus
Schutz kann ein Segment, mehrere benachbarte Segmente oder den gesamten Weg umfassen. Ein Detektor kann eine Umschaltung auslösen, ohne zu beweisen, dass der Ersatzweg den Dienst zugelassen, beide Richtungen installiert und Verkehr übertragen hat.
RFC 7771 behandelt S-PE-Schutz für statische MS-PWs, RFC 8104 den schnellen Schutz an Pseudowire-Endpunkten. Beide machen dieselbe Kette sichtbar: Fehler feststellen, Ersatz auswählen, Zustand installieren, wiederhergestellte Weiterleitung messen. Schnelligkeit hebt diese Übergänge nicht auf.
Ein Incident-System, das bei „Schutz aktiv“ automatisch schließt, verwechselt Handlung und Wirkung. Nach dem Wechsel muss der neue Pfad erfasst, lokales sowie globales OAM wiederholt und echter Verkehr geprüft werden. Ein erfolgreicher Kontrollbefehl kann mit einer erfolglosen Wiederherstellung zusammenfallen.
Qualität überschreitet Domänengrenzen nicht durch Namensgleichheit
Domänen können unterschiedliche Tunneltechniken und CoS-Darstellungen verwenden. RFC 5254 fordert daher Abbildungen an administrativen Grenzen und Bindungen an Tunnel mit passenden Eigenschaften. Ein fortgeführter Dienstname garantiert nicht, dass Verzögerung, Verlust oder Priorität jede Übersetzung überstehen.
Überlastung ist zunächst lokal. Jede Domäne muss eine angemessene Kontrolle einsetzen; ein MS-PW soll keinen unprovisionierten Best-Effort-Pfad ohne Ersatzmechanismus queren. RFC 6073 hält fest, dass jedes Segment Überlastung selbst behandelt, auch wenn Informationsaustausch die End-to-End-Reaktion verbessern könnte.
Ein Setup-Beleg ist somit kein Leistungsbeleg. Delay, Jitter und Loss verlangen Performance-OAM und Verkehrsmessung. Eine fehlende Fehlermeldung bestätigt keine niedrige Latenz; ein Konnektivitätstest bestätigt kein SLA.
An Providergrenzen wechselt auch die Sicherheitsverantwortung
An einer Inter-Provider-Grenze akzeptiert eine Domäne das Label des Nachbarn nach lokalen Regeln. Diese Zulässigkeit beweist keine End-to-End-Authentizität. Eine Transitdomäne oder ein fehlerhaftes S-PE könnte PDUs einschleusen, umlenken, spiegeln oder übernehmen. Deshalb lässt RFC 5254 Mechanismen für eine durchgehende PDU-Authentizität zu.
Auch der Managementblick bleibt geteilt. Fernverwaltung über Domänen hinweg kann möglich oder aus Sicherheitsgründen gesperrt sein. Fehlende Sicht in einer Konsole bedeutet nicht fehlenden Zustand; gefüllte Felder beweisen nicht den Datenpfad. Auditierbarkeit braucht geschützte lokale Details und zugleich gemeinsame Korrelationskennungen, Zeitgrenzen und Generationen.
Ein reversibler Dienstnachweis beginnt bei den Attachment Circuits und den vorgesehenen T-PEs. Er nennt Aufbaumodell und S-PE-Folge. Für jedes Segment hält er Label, Tunnelbindung, Policy-Generation, Admission, gerichteten Cross-Connect, CoS-Abbildung, Schutz und Segment-OAM fest. Erst danach verbindet er diese Fakten mit End-to-End-OAM, Leistung, weitergeleitetem Verkehr und Kundenergebnis.
Lu Hengs Disziplin der Realitätsebenen liefert die Führungsregel dazu. Der zusammengesetzte Dienst ist real, aber seine Einheit gehört zur Dienstebene. Segmentannahme, Schaltzustand, Fehlerweitergabe und beobachtete Lieferung sind eigene Realitäten mit eigenen Verwaltern. Vertrauenswürdig bleibt die Abstraktion nur, wenn sie sich in die Belege zurückübersetzen lässt, die sie wahr gemacht haben.
Quellen
- RFC 5254: Requirements for Multi-Segment PWE3
- RFC-Editor-Eintrag zu RFC 5254
- IETF-Datatracker-Eintrag zu RFC 5254
- RFC 3985: PWE3 Architecture
- RFC 3916: Requirements for PWE3
- RFC 4447: Pseudowire Setup and Maintenance Using LDP
- RFC 5085: PWE3 VCCV
- RFC 5885: BFD for PWE3 VCCV
- RFC 5659: Multi-Segment PWE3 Architecture
- RFC 6073: Segmented Pseudowire
- RFC 6478: Pseudowire Status for Static Pseudowires
- RFC 7267: Dynamic Placement of Multi-Segment Pseudowires
- RFC 7771: S-PE Protection for Static MS-PWs
- RFC 8104: Pseudowire Endpoint Fast Failure Protection
- Lu Heng: Running-Code Primacy
- Lu Heng: On Reality Layers
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
