Zusammenfassung

  • RFC 1513 erweiterte RMON für Token Ring. dropEvents zählte erkannte Situationen, in denen der Probe Ressourcen fehlten, nicht die exakte Zahl verworfener Frames.
  • Soft-Error-Berichte konnten zuverlässig zugestellt und von einem promiscuous arbeitenden Probe doppelt gezählt werden. Melder, nächster Upstream-Nachbar, Stationsreihenfolge und Messintervall gehörten zur Aussage.
  • Messwert, Verlustschätzung, Schuldzuweisung, Berechtigung zur Stationskontrolle und beobachtetes Ergebnis waren getrennte Belege. Spätere RMON-2-Objekte benannten exakte Dropped-Frame-Zähler eigens.

Eine exakte Zahl für einen engeren Gegenstand

RFC 1271 verlagerte laufende Beobachtung in einen entfernten Probe und gliederte RMON in Statistik, Historie, Hosts, Matrizen, Filter, Capture und Events. Einige Link-Layer-Sichten waren Ethernet-spezifisch. RFC 1513 ergänzte im September 1993 IEEE 802.5 Token Ring samt Stations-, Reihenfolge-, Konfigurations- und Source-Routing-Gruppen.

Die entscheidende Grenze stand in der Beschreibung von tokenRingMLStatsDropEvents. Das Objekt stieg, wenn der Probe wegen Ressourcenmangels Pakete verwarf. Der Wert sei nicht notwendigerweise die Zahl der verworfenen Pakete, sondern nur die Zahl der erkannten Vorkommnisse.

Ein Vorkommnis konnte einen Frame oder einen langen Burst verbergen. Zwei Knappheitsphasen konnten völlig verschieden groß sein. Die Sonde wusste, wie oft sie ihren Engpass erkannt hatte; sie konnte aus diesem Zähler nicht nachträglich zählen, was unbeobachtet blieb.

Der Zähler war nicht ungenau. Ungenau wurde die Aussage erst, wenn aus „Ereignissen“ „Frames“ wurden.

Auch der Beobachter konnte ausfallen

RMON sparte Bandbreite, weil vor Ort klassifiziert und verdichtet wurde. Dafür besaß der Probe begrenzte CPU-, Puffer- und Tabellenressourcen. Bei Sättigung berichtete dropEvents ebenso über den Zeugen wie über den beobachteten Verkehr.

Die Semantik erschien in MAC-Statistik, Promiscuous-Statistik und historischen Intervallen. Ein Vergleich brauchte Interface, Data Source, Control Row, Owner, Status, Aktivierungszeit und Sampling-Fenster. Neustart, Neuerzeugung einer Zeile, Counter-Wrap oder Quellenwechsel konnten zwei Messreihen fälschlich verbinden.

RFC 4502 definierte später DroppedFrames als exakte Zahl von Frames, die aus einer Collection fielen – ausdrücklich anders als dropEvents. Eine stärkere Behauptung erhielt ein eigenes Messobjekt.

Zuverlässige Zustellung konnte doppelt zählen

RFC 1513 warnte, dass Soft-Error-Reports mit assured delivery gesendet werden konnten. Ein promiscuous lauschender Probe konnte manche Fehler zweimal erfassen. Zuverlässigkeit der Meldung war keine Einmaligkeit des zugrunde liegenden Ereignisses.

Erforderlich waren meldende Station, Fehlertyp, Zeitpunkt, Capture-Ort und nachvollziehbare Deduplizierung. Die Spezifikation belegt die Möglichkeit, nicht einen Fehler eines benannten Produkts. Ebenso beweist ein Nullwert ohne Kapazitäts- und Epochenkontext keine fehlerfreie Überwachung.

Ein Nachbar war noch keine Ursache

Die Buchungsregeln nutzten die Ringtopologie. Address-Copied-Fehler erhöhten den Eintrag des nächsten Upstream-Nachbarn der meldenden Station. Line- und Burst-Fehler erhöhten Melder und Nachbarn. Internal- und Abort-Fehler blieben beim Melder.

Das ordnete Hinweise, sprach aber kein Kausalurteil. Eine Station konnte erscheinen, weil sie meldete, benachbart war oder von der Regel als Ablageort gewählt wurde. Die Ring Station Order Group zeigte die Stationsreihenfolge, bewies aber weder eine unveränderte Topologie zum Fehlerzeitpunkt noch die Zustellung eines Frames.

Wenn ein Dashboard Stationsname und rote Zahl verbindet, wird aus einer Buchungsbeziehung leicht Schuld. RFC 1513 hielt Melder, Nachbar, Zählerziel und Ursache auseinander.

Schreibbar bedeutete nicht bevollmächtigt

Die Ring Station Configuration Group erlaubte aktives Entfernen oder Herunterladen von Konfiguration. Zugleich erklärte die RFC, dass der Access Level nur den protokollarischen Sinn von Lesen oder Schreiben bezeichnete und von administrativer Autorisierung unabhängig war.

read-write war kein Mandat. Ein steigendes dropEvents, eine Nachbarbuchung oder ein duplizierbarer Bericht rechtfertigte keine automatische Entfernung. Nötig waren Anfordereridentität, Autorisierungsentscheidung, Ziel, vorherige Reihenfolge, Befehl, Antwort, neuer Zustand und beobachtete Wirkung.

Source-Routing-Statistik blieb ebenfalls partiell, weil sie aus optionalen Angaben in Frames abgeleitet wurde. Eine Klassifikation auf einem Ring bewies keinen End-to-End-Pfad.

Was die Quellen tragen

Der RFC-Editor-Eintrag und der Datatracker belegen Veröffentlichung, Autorschaft, Abstammung und Status. RFC 1271, 1757, 2021, 2819, 3577 und 4502 zeigen die RMON-Familie.

Sie belegen keine konkrete Installation, Verluste, Störung, Herstellerfehler oder erfolgreiche Maßnahme. Historic ist kein Incident-Bericht. Auch die spätere Deprecation einzelner Token-Ring-RMON-2-Erweiterungen wegen zu weniger unabhängiger Interoperabilitätsnachweise beweist kein Versagen von RFC 1513 im Betrieb.

Running-Code Primacy verlangt Ausführung und Wirkung. Minimum Initial Specification hält die gemeinsame Semantik minimal und lokale Entscheidungen sichtbar. On Reality Layers verhindert, dass ein Symbol die Autorität der dargestellten Realität erbt.

42 konnte 42 erkannte Engpässe bedeuten. Ohne weitere Belege waren es weder 42 verlorene Frames noch 42 Ausfälle oder 42 Eingriffsvollmachten.

Quellen

  1. RFC 1513 – Information
  2. RFC 1513 – Text
  3. RFC 1513 – Datatracker
  4. RFC 1271 – Information
  5. RFC 1271 – Text
  6. RFC 1757 – Information
  7. RFC 1757 – Text
  8. RFC 2021 – Information
  9. RFC 2021 – Text
  10. RFC 2819 – Information
  11. RFC 2819 – Text
  12. RFC 3577 – Information
  13. RFC 3577 – Text
  14. RFC 4502 – Information
  15. RFC 4502 – Text
  16. Running-Code Primacy
  17. Minimum Initial Specification
  18. On Reality Layers