Zusammenfassung

  • RFC 1595 ordnete Leistungsdaten Section, Line, Path und VT, Nah- oder Fernende sowie aktuellem oder abgeschlossenem 15-Minuten-Intervall zu. Ohne diese Koordinaten verlor die Zahl ihre Beobachtungsgrenze.
  • Nichtverfügbarkeit begann mit der ersten von zehn aufeinanderfolgenden SES. Überquerte die Folge den Intervallwechsel, konnten spätere GETs SES- und UAS-Werte der Vorperiode verändern.
  • RFC 2558 und RFC 3592 ließen Echtzeitwerte mit Rückkorrektur oder eine zehnstufige Verzögerungsleitung zu. Schnelligkeit und unveränderliche Erstausgabe waren verschiedene Entwürfe.

Ein historischer Datensatz wartete noch auf die Zukunft

Beginnt kurz vor dem Intervallende eine schwere Fehlerfolge, ist die abgelaufene Periode beim Umschalten bereits als Intervall 1 lesbar. Dem Agenten fehlen aber noch Beobachtungen, um zu wissen, ob zehn SES in Folge entstehen.

Mit der zehnten SES gilt Nichtverfügbarkeit ab der ersten Sekunde. Lag sie im alten Fenster, müssen dort bereits abgelegte Sekunden in UAS überführt werden. RFC 1595 warnte deshalb ausdrücklich, dass aufeinanderfolgende GETs zu Beginn des neuen Fensters unterschiedliche Path-, Line- oder VT-Werte für SES und UAS liefern können.

Die physische Vergangenheit änderte sich nicht. Erst ihre Zustandsklassifikation wurde entscheidbar. Ein Sammler, der den ersten Abruf ohne Abrufzeit und Version als endgültig speichert, entfernt genau diese Information.

Zehn Sekunden reichten zurück

Auf Line-, Path- und VT-Ebene beginnt Nichtverfügbarkeit mit zehn aufeinanderfolgenden SES rückwirkend bei der ersten; alle zehn zählen dazu. Verfügbarkeit kehrt mit zehn aufeinanderfolgenden Sekunden ohne SES zurück, die nicht als UAS zählen.

Während Verfügbarkeit laufen die jeweiligen Fehlerzähler. Während Nichtverfügbarkeit läuft auf der Ebene nur UAS. Die Wartezeit glättet also nicht bloß einen Alarm, sondern verteilt bereits beobachtete Sekunden auf verschiedene Konten. Der Zustandsautomat bleibt über die 15-Minuten-Grenze erhalten.

Jede Zahl gehörte zuerst zu einer Ebene

SONET/SDH-Geräte terminieren nicht überall alle Ebenen. Ein Regenerator kann nur Sections terminieren; Add-Drop-Multiplexer und digitale Kreuzverbinder terminieren Lines; Terminalmultiplexer können Paths und VT/VC einbeziehen. Die MIB bildete dies mit Interface-Einträgen und ihrem Stack ab.

Section-Verstöße kamen aus B1, Line aus B2, Path aus B3 und ein fließender VT aus V5. LOS, LOF, AIS, LOP und RDI hatten ebenfalls eigene Geltungsbereiche. Auch ifOperStatus=down war nur eine Projektion der jeweiligen Layerzustände und kein automatischer Ortsnachweis für das defekte Bauteil.

Nah- und Fernende waren getrennte Zeugen. Far-End-Path-Daten wurden aus der FEBE-Information im G1-Byte gewonnen. RFC 2558 verlangte, Fernendestatistik für eine Sekunde als abwesend zu markieren, wenn ein eingehender Defekt auf derselben oder einer unteren Ebene vorlag. Abwesend ist nicht null: Eine Null ersetzt fehlende Sicht fälschlich durch einen Sauberkeitsbeleg.

Früh korrigieren oder später stabil berichten

RFC 2558 beschrieb zwei Wege. Ein Agent mit Echtzeitaktualisierung musste ES, SES, SEFS, CV und UAS nachträglich anpassen können, sobald die Zehn-Sekunden-Folge entschieden war. Bei Grenzübertritt betraf das auch das vorige Intervall.

Alternativ liefen Sekundenbeobachtungen durch eine Leitung aus zehn Speicherstellen. Erst nach bekannter Klassifikation wurden die Zähler aktualisiert. Die erste Ausgabe blieb stabil, lag aber zehn Sekunden hinter der physischen Zeit. RFC 3592 bewahrte dieses Verfahren 2003.

Beide Formen können korrekt sein. Die schnelle braucht Versionierung; die stabile braucht eine ausgewiesene Latenz. Ein System, das sofortige und zugleich unveränderliche Werte verspricht, verbirgt den unvermeidlichen Aufwand.

RFC 2493 ergänzte Zeitablauf sowie gültige und ungültige Intervalle und trennte aktuelle, historische und optionale Summen. Nach Neustart oder Proxy-Lücke konnte die Historie unvollständig sein. 96 Intervalle waren eine Obergrenze von 24 Stunden; RFC 1595 forderte mindestens vier und nannte 32 als Vorgabe.

Der Trap bezog sich auf eine frühere Sekunde

Die Nachfolger ließen linkDown erst senden, wenn Nichtverfügbarkeit sicher feststand, datierten seine wirksame Zeit aber auf die erste UAS, ungefähr zehn Sekunden zuvor. Dasselbe galt für linkUp.

Sendezeit beantwortet, wann der Agent genug wusste. Wirksamkeitszeit beantwortet, wohin der Zustandsautomat den Übergang legt. Nur eine der beiden Zeiten zu behalten erzeugt entweder vermeintliche Soforterkenntnis oder einen verspäteten Ereignisbeginn.

Selbst „schwer“ brauchte Herkunft

RFC 2558 dokumentierte verschiedene SES-Schwellen aus mehreren Normen und führte sonetSESthresholdSet ein. Ein Agent musste nicht alle Sätze unterstützen; ein Wechsel machte zuvor gesammelte SES-Statistiken ungültig.

Ohne Schwellenherkunft kann eine Definitionsänderung wie bessere oder schlechtere Optik aussehen. Ebene, Ende, Fenster, Gültigkeit, Agentenepoche und Abrufzeit gehören zur Messung.

Lu Hengs Running-Code Primacy bindet das Symbol an ausgeführte Beobachtung. Minimum Initial Specification hält den gemeinsamen Vertrag dünn und lässt lokale Speicher- und Reaktionsentscheidungen sichtbar. Why BTW.Media Exists macht daraus eine redaktionelle Pflicht: Abwesenheit, Verzögerung und Revision berichten, bevor die erste Kurve zur Wirklichkeit erklärt wird.

Die Viertelstunde ordnete die Messung. Dokumentierte Endgültigkeit machte daraus belastbare Evidenz.

Quellen und Evidenzgrenzen

Technische Grundlage sind die RFC-Editor-Einträge und Texte zu RFC 1595 (Text), RFC 2558 (Text), RFC 3592 (Text) und RFC 2493 (Text). Die Lu-Heng-Texte liefern Interpretationsdisziplin, keine SONET-Fakten.

Die Dokumentfolge ist präzise datiert: RFC 1595 erschien im März 1994 auf dem Standards Track; RFC 2558 ersetzte sie im März 1999, und RFC 3592 ersetzte RFC 2558 im September 2003. Auch die Sicherheitsbehandlung änderte sich: RFC 1595 erörterte Sicherheit nicht, während RFC 2558 warnte, dass GET- und SET-Zugriffe sensible Konfigurations- und Steuerungsinformationen offenlegen könnten.

Die Quellen belegen keine konkrete Implementierung, Störung, Kundenauswirkung, Produktkonformität, Trap-Zustellung, Sammlerfunktion, Sicherheitslage oder Reparatur. Der Einstieg ist ein logisches Beispiel aus der Regel, keine Nachricht über einen Vorfall.