Zusammenfassung

  • Der Ingress fordert den Lock mit einer Path-Nachricht an, in der A und Reflect im ADMIN_STATUS-Objekt gesetzt sind. Der Egress versucht, den LSP aus dem Clientbetrieb zu nehmen: Bei Erfolg sendet er Resv mit A gesetzt, bei Misserfolg OAM Problem / Lock Failure; nachfolgende Resv behalten A gelöscht.
  • Erst nach bestätigtem Lock adressiert der Ingress den Egress oder einen Zwischenknoten über RFC-7570-ERO-Hop-Attributes. Der Zielknoten prüft den A-Zustand und die ausdrückliche Identität des gewünschten Entities, bevor er Loopback versucht. Ohne Lock muss er ignorieren; ohne eindeutige Identität kann er ignorieren oder Bad EXPLICIT_ROUTE erzeugen.
  • Loopback ist Attribute-Flags-Bit 13 in Path und RRO Attributes, nicht das ADMIN_STATUS-A-Bit und kein OAM-Problemcode. Ein erfolgreicher Zielknoten kann das Loopback-Flag in RRO Hop Attributes melden, während A gesetzt bleibt.
  • Für den Exit löscht der Ingress das Loopback-Flag, lässt A aber gesetzt. Erst nach verifiziertem Exit darf Unlock angefordert werden. Während Loopback muss der Egress einen Unlock-Versuch ignorieren; Erfolg zeigt Resv mit gelöschtem A, Fehler OAM Problem / Unlock Failure.

Die Abfolge der verteilten Autorität

Der Ingress besitzt die Anforderungsmacht, aber nicht die Macht, den resultierenden Zustand allein herzustellen. Der Egress bestätigt den Entzug aus dem Clientbetrieb oder weist den Lock zurück. Der Zielknoten entscheidet anschließend selbst, ob er den ausdrücklich benannten Test ausführt. Der Name muss im ERO-Subobject unmittelbar vor den ERO Hop Attributes stehen. Bei IPv4- und IPv6-Präfixkennungen verlangt RFC 7571 Hostlängen von 32 beziehungsweise 128 Bit. Folgt davor ein Label-Subobject, bestimmt dessen U-Bit die Loopback-Richtung. Das sind exakte Validierungsregeln, keine universelle Aussage über jede Implementierung.

RFC 6435 liefert die funktionale Grundlage: Lock nimmt den Transportpfad aus dem Clientbetrieb, kann aber OAM und möglicherweise Testverkehr zulassen; Loopback führt empfangene Testdaten zurück, damit der Ursprung die Pfadintegrität prüft. RFC 7570 stellt den Hop-bezogenen Adressierungs- und Reporting-Träger bereit. Es definiert nicht den gesamten Lock–Loopback–Exit–Unlock-Autorisierungsablauf von RFC 7571. RFC 5420 behandelt die Verarbeitung optionaler und erforderlicher Attribute, RFC 3473 den ADMIN_STATUS-Rahmen und RFC 7260 die OAM-Problemgrundlage.

Nutzen, Kosten und Beweisgrenzen

Begünstigt werden OAM-Teams, die die Integrität eines Transportpfads bis zu einem benannten Knoten isolieren wollen, während Clientverkehr zurückgehalten und Testverkehr gezielt zurückgeführt wird. Dem stehen ein außer Betrieb genommener LSP, koordinationsbedürftige Zustandswechsel, getrennte Fehlerbilder für Lock, Loopback, Exit und Unlock sowie mögliche Offenlegung von Knoteninformationen über RRO gegenüber. Die Quellen belegen keine Anbieter, Betreiber, Einsätze, Vorfälle, Verbreitung, Dauer, Fehlerraten, Latenzen oder Kundenergebnisse.

Sie wählen auch kein Wartungsfenster, Testmuster, Abnahmekriterium oder kommerzielles Wiederherstellungsziel. Es gibt im Paket keine eigenständigen Anschuldigungen. Die gespeicherte Errata-Seite ist nur der eingefrorene Suchstand und beansprucht keine weitergehende Korrektur.

Konkrete Prüf-Fixtures

  1. Lock-Erfolg: Prüfe ADMIN_STATUS(A=1, Reflect=1) im Path, danach A=1 im Resv und A in folgenden Path-/Resv-Nachrichten.
  2. Lock-Fehler: Erwarte OAM Problem / Lock Failure und nachfolgende Resv mit A=0; ein Path mit A allein beweist keinen erfolgreichen Serviceentzug.
  3. Adressiertes Ziel: Prüfe das explizite ERO-Subobject unmittelbar vor ERO Hop Attributes, eine IPv4-Hostroute /32 oder IPv6-Hostroute /128 und, nach einem Label, die Richtung des U-Bits.
  4. Loopback-Erfolg: Prüfe Loopback-Bit 13 im Path und im RRO Hop Attributes mit A=1; das Bit ist nicht in Resv zu erwarten.
  5. Fehler und Exit: Prüfe OAM Problem / Loopback Failure oder Exit Loopback Failure. Bei erfolgreichem Exit muss das RRO-Flag verschwinden, während A=1 bleibt.
  6. Unlock: Erst nach bestätigtem Exit Path mit A=0 senden und Resv mit A=0 prüfen. Solange Loopback besteht, darf Unlock nicht vorgezogen werden.

Operator-Entscheidungsweg: Ist Lock durch Resv bestätigt? Wenn nein, stoppen. Sind Zieladresse und Entity explizit? Wenn nein, ERO korrigieren oder Ignorieren/Bad EXPLICIT_ROUTE akzeptieren. Zeigt RRO Loopback bei A=1? Wenn nein, Loopback-Fehler behandeln. Danach Flag löschen, Exit bestätigen, Unlock anfordern und Resv beobachten. Path, Resv, RRO und OAM Problem müssen korreliert werden; kein einzelnes Signal ersetzt die vollständige Zustandskette.

Quellen