Zusammenfassung

  • Ein Server oder Zwischenknoten sendet AIS downstream in betroffene Client-LSPs. AIS ohne L-Flag meldet eine Störung, erklärt aber keinen Serverausfall; eine Schutzumschaltung kann weiterhin erwartet werden.
  • Das L-Flag darf erst nach einer Serverausfall-Erklärung gesetzt werden. Dann kann LDI als Client-LOC behandelt werden, sofern fast CC den Ausfall nicht bereits erkennt und das Signal deshalb lokal ignorierbar ist. LKR bedeutet administrative Sperre, nicht Fehler; sein L-Flag muss null sein und wird beim Empfang ignoriert.
  • Fault-Management-Nachrichten verwenden den G-ACh-FM-Codepunkt 0x0058 und keine ACh-TLV-Kopfzeile. Die MEP prüft Nachrichtentyp, Version und Identität.

Getrennte Zuständigkeiten

Der Server oder Zwischenknoten besitzt die Befugnis, eine Anzeige in den betroffenen Client-LSP einzuspeisen. Das beweist weder den Ausfall des Client-Dienstes noch schreibt es jede lokale Reaktion vor. Die Serverausfall-Erklärung autorisiert das L-Flag; die administrative Konfiguration trägt den Lock-Zustand; die empfangende MEP validiert Typ, Version, IF_ID beziehungsweise globale Identität und entscheidet über die lokale Behandlung. Diese Evidenzquellen dürfen nicht vermischt werden.

Der Refresh Timer liegt zwischen 1 und 20 Sekunden. Eine Nachricht wird sofort und zweimal weitere Male im Abstand von je einer Sekunde gesendet; solange die Bedingung besteht, folgen Sendungen im angekündigten Intervall. Endet der Refresh, wird die Bedingung nach 3,5-mal dem Timer gelöscht. Ein optionales Fast-Clear setzt R-Flag und wiederholt drei Clear-Nachrichten. Kommt währenddessen ein neuer Fehler, werden diese Clear-Wiederholungen beendet. R-Flag löscht nur einen Eintrag mit passendem Typ und IF_ID. Unbekannter Typ oder unbekannte Version werden ignoriert.

Praktischer Entscheidungsweg

  1. Prüfe FM-Kanal 0x0058, Nachrichtentyp, Version und das Fehlen einer ACh-TLV-Kopfzeile; verwerfe nicht valide Pakete.
  2. Vergleiche IF_ID und globale Identität mit LSP und lokaler MEP. Protokolliere L-Flag, R-Flag, Refresh-Wert und Timerzustand.
  3. Ordne ein: AIS ohne L-Flag ist Störungsanzeige, nicht Serverausfall; AIS mit L-Flag setzt eine erklärte Serverstörung voraus; LKR ist administrativer Lock mit L-Flag null.
  4. Vergleiche Server-/Zwischenknoten-Evidenz mit fast CC, Schutzstatus und Operator-Konfiguration. Alarmruhe allein beweist nichts.
  5. Erzeuge oder erneuere bei R-Flag null nur den passenden Zustand. Lösche bei R-Flag eins nur den passenden Typ und IF_ID; überwache 3,5×T und stoppe Fast-Clear bei neuem Fehler.

Nutzen, Kosten und Grenzen

Der mögliche Nutzen liegt in weniger kaskadierenden Client-Alarmen, der Unterscheidung geplanter Sperren von Fehlern und einer gezielteren Untersuchung der Serverebene. Dem stehen periodischer Refresh, Timer- und IF_ID-Zustand, hierarchische Weitergabe, optionale Clear-Semantik und Quellvalidierung gegenüber. MPLS-Sicherheitsannahmen erschweren Injektion, schließen sie aber nicht aus: Gefälschte FM-Nachrichten könnten Alarme unterdrücken oder Schutz auslösen. Zugriffsbeschränkung und Quellenprüfung sind daher erforderlich.

Fehlender Refresh räumt den Zustand schließlich auf. Ein nicht passendes R-Flag darf keinen anderen Zustand löschen. Hierarchische AIS-Weitergabe setzt das L-Flag nicht automatisch in jeder Ebene. RFC 5654 und RFC 5860 liefern Anforderungen für MPLS-TP und OAM; RFC 5921 beschreibt die Transportprofil-Architektur, RFC 6370 Identifikatoren und RFC 6371 OAM-Rahmen sowie Layer-Grenzen. Sie erweitern nicht die normative Rolle von RFC 6427. Die Quellen belegen weder Herstelleradoption, Verbreitung, gemessene Alarmreduktion noch kommerzielle oder kundenseitige Ergebnisse.

Quellen